From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: [PATCH v8 01/21] xen/x86: add bitmap of enabled emulated devices Date: Tue, 17 Nov 2015 10:30:27 +0000 Message-ID: <564B01C3.1040909@citrix.com> References: <1446825955-11842-1-git-send-email-roger.pau@citrix.com> <1446825955-11842-2-git-send-email-roger.pau@citrix.com> <5649D78C02000078000B535D@prv-mh.provo.novell.com> <564A2168.7050402@citrix.com> <564B048802000078000B59B5@prv-mh.provo.novell.com> <564AFA50.9070600@suse.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZydXA-000816-Ik for xen-devel@lists.xenproject.org; Tue, 17 Nov 2015 10:30:44 +0000 In-Reply-To: <564AFA50.9070600@suse.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Juergen Gross , Jan Beulich Cc: Wei Liu , Ian Campbell , Stefano Stabellini , George Dunlap , Ian Jackson , xen-devel@lists.xenproject.org, Roger Pau Monne List-Id: xen-devel@lists.xenproject.org On 17/11/15 09:58, Juergen Gross wrote: > On 17/11/15 10:42, Jan Beulich wrote: >>>>> On 16.11.15 at 19:33, wrote: >>> On 16/11/15 12:18, Jan Beulich wrote: >>>>>>> On 06.11.15 at 17:05, wrote: >>>>> --- a/xen/include/public/arch-x86/xen.h >>>>> +++ b/xen/include/public/arch-x86/xen.h >>>>> @@ -265,7 +265,31 @@ typedef struct arch_shared_info arch_shared_info_t; >>>>> * XEN_DOMCTL_INTERFACE_VERSION. >>>>> */ >>>>> struct xen_arch_domainconfig { >>>>> - char dummy; >>>>> +#define _XEN_X86_EMU_LAPIC 0 >>>>> +#define XEN_X86_EMU_LAPIC (1U<<_XEN_X86_EMU_LAPIC) >>>>> +#define _XEN_X86_EMU_HPET 1 >>>>> +#define XEN_X86_EMU_HPET (1U<<_XEN_X86_EMU_HPET) >>>>> +#define _XEN_X86_EMU_PM 2 >>>>> +#define XEN_X86_EMU_PM (1U<<_XEN_X86_EMU_PM) >>>>> +#define _XEN_X86_EMU_RTC 3 >>>>> +#define XEN_X86_EMU_RTC (1U<<_XEN_X86_EMU_RTC) >>>>> +#define _XEN_X86_EMU_IOAPIC 4 >>>>> +#define XEN_X86_EMU_IOAPIC (1U<<_XEN_X86_EMU_IOAPIC) >>>>> +#define _XEN_X86_EMU_PIC 5 >>>>> +#define XEN_X86_EMU_PIC (1U<<_XEN_X86_EMU_PIC) >>>>> +#define _XEN_X86_EMU_VGA 6 >>>>> +#define XEN_X86_EMU_VGA (1U<<_XEN_X86_EMU_VGA) >>>>> +#define _XEN_X86_EMU_IOMMU 7 >>>>> +#define XEN_X86_EMU_IOMMU (1U<<_XEN_X86_EMU_IOMMU) >>>>> +#define _XEN_X86_EMU_PIT 8 >>>>> +#define XEN_X86_EMU_PIT (1U<<_XEN_X86_EMU_PIT) >>>> While only used for a domctl (so far), I still think we should aim at >>>> making this a complete set (i.e. preempt future additions to the >>>> set if at all possible). I say this because - having looked again - I'm >>>> missing things like MTRR, PAT, and 8254 here. >>> Use (or not) of MTRR and PAT should be controlled exclusively via the >>> guests cpuid policy. Unlike the above bits, they are architectural >>> components of the CPU itself, rather than external devices on the >>> motherboard. >> For MTRR - yes, agreed. But what CPUID bit do I not recall that allows >> identifying PAT availability? > INTEL SDM Vol. 3 11.12.1: > > An operating system or executive can detect the availability of the PAT > by executing the CPUID instruction with a value of 1 in the EAX > register. Support for the PAT is indicated by the PAT flag (bit 16 of > the values returned to EDX register). Indeed. X86_FEATURE_PAT. ~Andrew