grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Roger Pau Monné
Subject: Re: [Xen-devel] Xen PVH support in grub2
Date: Tue, 3 Oct 2017 09:56:58 +0100
User-agent: NeoMutt/20170912 (1.9.0)

On Fri, Sep 29, 2017 at 05:22:25PM +0000, Boris Ostrovsky wrote:
> On 09/29/2017 01:07 PM, Roger Pau Monné wrote:
> > On Fri, Sep 29, 2017 at 05:02:48PM +0000, Boris Ostrovsky wrote:
> >> On 09/29/2017 11:51 AM, Roger Pau Monné wrote:
> >>> On Fri, Sep 29, 2017 at 03:33:58PM +0000, Juergen Gross wrote:
> >>>> On 29/09/17 17:24, Roger Pau Monné wrote:
> >>>>> On Fri, Sep 29, 2017 at 02:46:53PM +0000, Juergen Gross wrote:
> >>>>> Then, I also wonder whether it would make sense for this grub to load
> >>>>> the kernel using the PVH entry point or the native entry point. Would
> >>>>> it be possible to boot a Linux kernel up to the point where cpuid can
> >>>>> be used inside of a PVH container?
> >>>> I don't think today's Linux allows that. This has been discussed
> >>>> very thoroughly at the time Boris added PVH V2 support to the kernel.
> >>> OK, I'm not going to insist on that, but my plans for FreeBSD is to
> >>> make the native entry point capable of booting inside of a PVH
> >>> container up to the point where cpuid (or whatever method) can be used
> >>> to detect the environment.
> >>>
> >>> Do you recall what's preventing the native entry point from booting
> >>> inside of a PVH container? If certain emulated devices not present are
> >>> needed at early boot we could look into either replacing them with
> >>> other options available inside of a PVH container, or as a last resort
> >>> making them available on a PVH container.
> >> Very much IIRC one of the reasons was the fact that zeropage
> >> (bootparams) needed to be properly formatted. And the hypercall page
> >> needs to be set up.
> > But in this case bootparams is going to be setup by grub, so it should
> > be fine (just like it's done on bare metal).
> 
> Yes, I think so.
> 
> >
> > Couldn't the hypercall page be setup at some point during early boot?
> > Not sure if setting it up at the same point HVM does would be fine for
> > PVH?
> 
> Probably --- I think the only reason we set it early is because we need
> to call XENMEM_memory_map to set bootparams. One other thing I noticed
> is that we need to set acpi_irq_model before hypervisor is discovered
> (can't remember why) but I suppose this can be worked around.
> 
> Having said that --- since for direct boot we still need to go via
> PVH-specific entry point I am not sure how much we will gain by having
> grub avoid it.

Being able to boot inside of a PVH container using the native entry
point would prevent us from having to add PVH loader specific code to
each firmware we plan to support in PVH mode.

If Linux must be started using the PVH entry point in order to run
inside of a PVH container, it means we would have to add a PVH loader
to OVFM and grub at least.

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.

Thanks, Roger.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]