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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 08.11.17 at 13:45, <jgross@xxxxxxxx> wrote:
> On 08/11/17 13:31, Jan Beulich wrote:
>>>>> On 08.11.17 at 12:55, <jgross@xxxxxxxx> wrote:
>>> On 08/11/17 12:18, Jan Beulich wrote:
>>>>>>> On 08.11.17 at 10:07, <jgross@xxxxxxxx> 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
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.

Jan


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