>>> On 16.11.15 at 19:33, <andrew.coop...@citrix.com> wrote:
> On 16/11/15 12:18, Jan Beulich wrote:
>>>>> On 06.11.15 at 17:05, <roger....@citrix.com> 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?
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
