From mboxrd@z Thu Jan 1 00:00:00 1970 From: Juergen Gross Subject: Re: [PATCH v8 01/21] xen/x86: add bitmap of enabled emulated devices Date: Tue, 17 Nov 2015 10:58:40 +0100 Message-ID: <564AFA50.9070600@suse.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> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Zyd2N-0003d0-Ee for xen-devel@lists.xenproject.org; Tue, 17 Nov 2015 09:58:55 +0000 In-Reply-To: <564B048802000078000B59B5@prv-mh.provo.novell.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: Jan Beulich , Andrew Cooper 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 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). Juergen