Re: [Xen-devel] [PATCH] x86/HVM: support IOMMU-related Viridian CPUID bits

[Paul Durrant <Paul.Durrant@xxxxxxxxxx>]

> -----Original Message-----
> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
> Sent: 01 August 2014 16:20
> To: Paul Durrant
> Cc: Andrew Cooper; xen-devel; Keir (Xen.org)
> Subject: RE: [PATCH] x86/HVM: support IOMMU-related Viridian CPUID bits
> 
> >>> On 01.08.14 at 17:01, <Paul.Durrant@xxxxxxxxxx> wrote:
> > Maybe. The spec. certainly implies that no Xen guest is ever likely to do
> > anything useful with them though. I'm also concerned about these bits
> > suddenly becoming visible across a migrate.
> 
> Or disappear. But that's a problem with CPUID4A_MSR_BASED_APIC,
> CPUID6A_APIC_OVERLAY, and CPUID6A_MSR_BITMAPS too. Do you
> suggest we don't report any CPUID bits depending on some condition
> which may change across migration, until proper validation of feature
> parity of both hosts is in place?
> 

It's also a problem with the TSC/APIC frequency features too - a migration from 
one version of Xen to another can make them magically appear.
For 4A bits, I think we should make sure stuff shouldn't change after boot. For 
6A bits, having re-read the comment in the spec. it sounds like it may be ok:

"0x40000006: Implementation hardware features. Indicates which 
hardware-specific features have been detected and are currently in use by the 
hypervisor"

There's nothing to say they can't change, but then there's nothing to say they 
can.

I'm working on a patch to add reference TSC page support at the moment, which 
is dependent on invariant TSC, and the spec. does have provision for that 
feature disappearing on migrate... so maybe we are ok.

  paul




_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel