Re: [Xen-devel] [PATCH 2/2] xen: add sysfs node for guest type
From: Andrew Cooper
Date: Mon May 22 2017 - 10:39:18 EST
On 22/05/17 15:35, Boris Ostrovsky wrote:
> On 05/22/2017 09:33 AM, Andrew Cooper wrote:
>> On 22/05/17 09:57, Juergen Gross wrote:
>>> Currently there is no reliable user interface inside a Xen guest to
>>> determine its type (e.g. HVM, PV or PVH). Instead of letting user mode
>>> try to determine this by various rather hacky mechanisms (parsing of
>>> boot messages before they are gone, trying to make use of known subtle
>>> differences in behavior of some instructions), add a sysfs node
>>> /sys/hypervisor/guest_type to explicitly deliver this information as
>>> it is known to the kernel.
>>>
>>> Signed-off-by: Juergen Gross <jgross@xxxxxxxx>
>>> ---
>>> Documentation/ABI/testing/sysfs-hypervisor | 13 +++++++++++++
>>> arch/arm/xen/enlighten.c | 3 +++
>>> arch/x86/xen/enlighten.c | 3 +++
>>> arch/x86/xen/enlighten_hvm.c | 6 ++++--
>>> arch/x86/xen/enlighten_pv.c | 1 +
>>> drivers/xen/sys-hypervisor.c | 17 +++++++++++++++++
>>> include/xen/xen.h | 2 ++
>>> 7 files changed, 43 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/Documentation/ABI/testing/sysfs-hypervisor b/Documentation/ABI/testing/sysfs-hypervisor
>>> index 443196f0aa1c..06850f74ebd4 100644
>>> --- a/Documentation/ABI/testing/sysfs-hypervisor
>>> +++ b/Documentation/ABI/testing/sysfs-hypervisor
>>> @@ -19,6 +19,19 @@ Contact: xen-devel@xxxxxxxxxxxxxxxxxxxx
>>> Description:
>>> Compiler which was used to build the Xen hypervisor
>>>
>>> +What: /sys/hypervisor/guest_type
>>> +Date: May 2017
>>> +KernelVersion: 4.12
>>> +Contact: xen-devel@xxxxxxxxxxxxxxxxxxxx
>>> +Description:
>>> + Type of guest:
>>> + "native": standard guest type on arm
>>> + "HVM": fully virtualized guest (x86)
>>> + "PV": paravirtualized guest (x86)
>>> + "PVH": fully virtualized guest without legacy emulation (x86)
>>> + "PVHVM": fully virtualized guest using paravirtualized
>>> + interfaces (e.g. interrupts, timers) (x86)
>> I'm not sure this is wise split. PVHVM is a spectrum which changes
>> dynamically, especially in the presence of hardware APIC support.
>>
>> I'd suggest guest type being straight PV or HVM (being the container
>> type), and a list of items (interrupts, timers, legacy emulation) which
>> are either using paravirt or native interfaces, or are not used at all.
> Can these be exposed via HVM CPUID leaf?
The HVM CPUID leaf provides information about the available options to
the kernel, but only Linux can make its mind up which interface to use.
~Andrew