[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Xen PVH support in grub2
On 06/11/17 15:51, Boris Ostrovsky wrote: > On 11/06/2017 02:16 AM, Juergen Gross wrote: >> On 03/11/17 20:00, Boris Ostrovsky wrote: >>> On 11/03/2017 02:40 PM, Juergen Gross wrote: >>>> On 03/11/17 19:35, Boris Ostrovsky wrote: >>>>> On 11/03/2017 02:23 PM, Juergen Gross wrote: >>>>>> On 03/11/17 19:19, Boris Ostrovsky wrote: >>>>>>> On 11/03/2017 02:05 PM, Juergen Gross wrote: >>>>>>>> So again the question: how to tell whether we are PVH or HVM in >>>>>>>> init_hypervisor_platform()? ACPi tables are scanned way later... >>>>>>> Can we make grub/OVMF append a boot option? >>>>>>> >>>>>>> Or set setup_header.hardware_subarch to something? We already have >>>>>>> X86_SUBARCH_XEN but it is only used by PV. Or we might be able to use >>>>>>> hardware_subarch_data (will need to get a buy-in from x86 maintainers, I >>>>>>> think). >>>>>> But wouldn't this break the idea to reuse the native boot paths in >>>>>> grub/OVMF without further modifications? >>>>> WDYM? We will have to have some sort of a plugin in either one to build >>>>> the zeropage anyway. So we'd set hardware_subarch there, in addition to >>>>> other things like setting memory and such. >>>> But isn't the zeropage already being built? I admit that setting subarch >>>> isn't a big deal, but using another entry with a passed-through pvh >>>> start struct isn't either... >>> I don't follow, sorry. My understanding is that zeropage will be built >>> by PVH-enlightened grub so part of this process would be setting the >>> subarch bit. >> My reasoning was based on Roger's remark: >> >> "OTOH if Linux is capable of booting from the native entry point inside >> of a PVH container, we would only have to port OVMF and grub in order >> to work inside of a PVH container, leaving the rest of the logic >> untouched." > > Right, and in my mind porting OVMF/grub includes creating proper zeropage. Aah, okay. I reasoned on the assumption to just enable OVMF/grub to run in PVH environment without touching the parts setting up anything for the new kernel. > BTW, another option might be to "type_of_loader = (9 << 4) | 0", which > is what init_pvh_bootparams() does. In fact, whatever is done in the > firmware should probably match what that routine does. So it wouldn't be possible any longer to tell whether the kernel has been booted directly or via grub. I don't like this. The loader type is accessible via sysfs after all. Juergen _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |