linux-kernel - Re: [Xen-devel] [PATCH 2/2] xen: add sysfs node for guest type

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <fab51758-56ad-1be1-94a3-5416b73e7091@citrix.com>
Date:   Mon, 22 May 2017 15:38:27 +0100
From:   Andrew Cooper <andrew.cooper3@...rix.com>
To:     Boris Ostrovsky <boris.ostrovsky@...cle.com>,
        Juergen Gross <jgross@...e.com>,
        <linux-kernel@...r.kernel.org>, <xen-devel@...ts.xenproject.org>
Subject: Re: [Xen-devel] [PATCH 2/2] xen: add sysfs node for guest type

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@...e.com>
>>> ---
>>>  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@...ts.xenproject.org
>>>  Description:
>>>  		Compiler which was used to build the Xen hypervisor
>>>  
>>> +What:		/sys/hypervisor/guest_type
>>> +Date:		May 2017
>>> +KernelVersion:	4.12
>>> +Contact:	xen-devel@...ts.xenproject.org
>>> +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