Re: [Xen-devel] Xen PVH support in grub2

[Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>]

On Tue, Nov 07, 2017 at 11:10:29AM -0500, Boris Ostrovsky wrote:
> On 11/07/2017 02:42 AM, Juergen Gross wrote:
> > On 06/11/17 17:42, Boris Ostrovsky wrote:
> >> On 11/06/2017 10:05 AM, Juergen Gross wrote:
> >>> 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.
> >> Someone needs to do what xen_prepare_pvh() does.
> > As the loader is filling in the memory map information 
> 
> That's the thing that I thought may need to be done by us (setting
> commandline too) . But I haven't looked at Xen support in grub so maybe
> it's already there.
> 
> > the only thing
> > remaining would be setting xen_pvh. And this could be delayed as my test
> > have shown, so we only need to detect the PVH case from inside the
> > kernel. One possibility would be the flags in the ACPI FADT table as
> > Roger mentioned, another idea would be a flag in zeropage set by the
> > loader.
> >
> >> And, for 64-bit, we also may need to build early pagetables since
> >> startup_64() (unlike startup_32()) expects paging to be on. (I don't
> >> know whether this is already part of standard FW codepath)
> > This would be done the same way as for a native kernel.
> 
> This is done by Linux trampoline code. AFAIK grub loads kernel in realmode.

Adding in Maran who is looking at re-using PVH for qemu launching
the kernels.

> 
> 
> -boris
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> https://lists.xen.org/xen-devel