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

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





On 10/03/2017 04:56 AM, Roger Pau Monné wrote:
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.

Right, I understand that. I was simply trying to say that PVH-specific entry point is likely to stay for us to continue booting PVH guests directly.

-boris

-boris

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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.