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

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



On 03/11/17 13:17, Roger Pau Monné wrote:
> On Fri, Nov 03, 2017 at 01:00:46PM +0100, Juergen Gross wrote:
>> On 29/09/17 17:51, 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.
>>
>> Looking more thoroughly into the Linux boot code I think this could
>> work for Linux, too. But only if we can tell PVH from HVM in the guest.
>> How would you do that in FreeBSD? Via flags in the boot params? This
>> would the have to be done in the boot loader (e.g. grub or OVMF).
> 
> My plan was not to differentiate between HVM and PVH, but rather to
> make use of the ACPI information in order to decide which devices are
> available and which are not inside of a PVH guest.
> 
> For example in the FADT "IA-PC Boot Architecture Flags" field for PVH
> we already set "VGA Not Present" and "CMOS RTC Not Present". There
> might be other flags/fields that must be set, but I would like to
> avoid having a CPUID bit or similar saying "PVH", because then Xen
> will be tied to always providing the same set of devices in PVH
> containers.

I looked through the xen_pvh_domain() use cases in the Linux kernel
again.

Maybe we can really manage to not need differentiating PVH from HVM
until ACPI table scan. We'd need another hook for Xen, but this should
be easy as KVM already has a hook where we'd need one. So this can be
made more general and we are fine.

I even think we can drop some of the PVH tests, as the PVH-specific
handling (e.g. for grant table initialization) should work for HVM, too.


Juergen

_______________________________________________
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®.