Re: [Xen-devel] [PATCH 3/3] x86/xen: use guest_late_init to detect Xen PVH guest

[Juergen Gross <jgross@suse.com>]

On 08/11/17 13:58, Jan Beulich wrote:
>>>> On 08.11.17 at 13:45, <jgross@suse.com> wrote:
>> On 08/11/17 13:31, Jan Beulich wrote:
>>>>>> On 08.11.17 at 12:55, <jgross@suse.com> wrote:
>>>> On 08/11/17 12:18, Jan Beulich wrote:
>>>>>>>> On 08.11.17 at 10:07, <jgross@suse.com> wrote:
>>>>>> In case we are booted via the default boot entry by a generic loader
>>>>>> like grub or OVMF it is necessary to distinguish between a HVM guest
>>>>>> with a device model supporting legacy devices and a PVH guest without
>>>>>> device model.
>>>>>>
>>>>>> PVH guests will always have x86_platform.legacy.no_vga set and
>>>>>> x86_platform.legacy.rtc cleared, while both won't be true for HVM
>>>>>> guests.
>>>>>>
>>>>>> Test for both conditions in the guest_late_init hook and set xen_pvh
>>>>>> to true if they are met.
>>>>>
>>>>> This sounds pretty fragile to me: I can't see a reason why a proper
>>>>> HVM guest couldn't come without VGA and RTC. That's not possible
>>>>> today, agreed, but certainly an option down the road if virtualization
>>>>> follows bare metal's road towards being legacy free.
>>>>
>>>> From guest's perspective: what is the difference between a legacy free
>>>> HVM domain and PVH? In the end the need for differentiating is to avoid
>>>> access to legacy features in PVH as those would require a device model.
>>>
>>> My point is that "legacy free" would likely be reached over time (and
>>> even once fully reached, hybrid configurations would be possible).
>>> I.e. there could be a setup with PIC, but with neither VGA nor RTC.
>>> That's still not PVH then. Nor do all legacy features require a device
>>> model in the first place - some of them are being emulated entirely
>>> in the hypervisor.
>>>
>>> Furthermore, PVH absolutely requires guest awareness afaict, while
>>> legacy-free pure HVM guests (with an OS only aware of the possible
>>> absence of legacy devices) would still be possible.
>>
>> Hmm, where else do you expect PVH awareness to be required? Maybe for
>> vcpu hotplugging, but this could easily be solved by adding a Xenstore
>> entry containing the required information. Is there any other problem to
>> be expected before Xenstore access is possible?
> 
> Let me ask the question the other way around: What's all the PVH
> specific code for under arch/x86/xen/ if there's no difference? One

Most of it is for early boot when coming through the PVH specific
boot entry.

> thing I seem to remember is that getting hold of the ACPI tables
> is different between PVH and HVM. Iirc the distinct PVH entry point
> is (in part) for that purpose. In the end - with that separate entry
> point - it is not really clear to me why any "detection" needs to be
> done in the first place: You'd know which mode you're in by knowing
> which entry point path you've taken.

Its all in the commit message: I am trying to enable a boot loader to
use the default kernel boot entry for PVH. This will reduce the needed
modifications in the loader.

Regarding ACPI tables: current PVH implementation in Linux kernel
seems not to make use of the special information presented in the boot
information block.


Juergen