[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH] x86/HVM: support IOMMU-related Viridian CPUID bits
> -----Original Message----- > From: dunlapg@xxxxxxxxx [mailto:dunlapg@xxxxxxxxx] On Behalf Of > George Dunlap > Sent: 04 August 2014 17:30 > To: Jan Beulich > Cc: Paul Durrant; Andrew Cooper; Keir (Xen.org); xen-devel > Subject: Re: [Xen-devel] [PATCH] x86/HVM: support IOMMU-related Viridian > CPUID bits > > On Fri, Aug 1, 2014 at 10:57 AM, Jan Beulich <JBeulich@xxxxxxxx> wrote: > >>>> On 01.08.14 at 16:42, <Paul.Durrant@xxxxxxxxxx> wrote: > >>> -----Original Message----- > >>> From: Jan Beulich [mailto:JBeulich@xxxxxxxx] > >>> Sent: 01 August 2014 15:16 > >>> 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 15:58, <Paul.Durrant@xxxxxxxxxx> wrote: > >>> >> -----Original Message----- > >>> >> From: Jan Beulich [mailto:JBeulich@xxxxxxxx] > >>> >> Sent: 01 August 2014 14:49 > >>> >> To: xen-devel > >>> >> Cc: Andrew Cooper; Paul Durrant; Keir (Xen.org) > >>> >> Subject: [PATCH] x86/HVM: support IOMMU-related Viridian CPUID > bits > >>> >> > >>> >> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> > >>> > > >>> > Whilst this patch is technically fine, is it of any real use? From my > >>> > reading of the Hypervisor Top Level Functional Spec (v4.0a) these bits > are > >>> > only of relevance to the root partition. > >>> > >>> I'm not that familiar with Hyper-V concepts, so I'm not sure what "root > >>> partition" refers to. If it was what I imagined (the host OS instance), > >>> then these bits clearly couldn't be meant for it, as it only sees the > >>> native CPUID output. > >>> > >> > >> I'm not sure that's true. I think Hyper-V runs its root partition (i.e. > >> control domain) in a VM container and so it doesn't see native CPUID > either. > >> Anyway, what is the benefit of adding these two bits in Xen's viridian > code? > >> Have they actually been observed to make a difference to a Windows > guest? > > > > Not that I know of. It just seems odd not to populate bits we can > > populate, simply _assuming_ that the Windows guys would not have > > added them without reason (i.e. _they_ know they can do whatever > > it is better with that knowledge). > > Does Hyper-V actually expose these bits to non-root partitions (i.e., > the viridian equivalent of domUs)? > I guess someone would have to try it. The spec. is not clear. The features are documented to only be useful to the 'root partition', although from looking at the 'access denied' error documentation for interrupt remapping... it says the partition must possess the CpuManagement privilege. Privileges are advertised to the partitions via CPUID:40000003:EBX (CpuManagement being bit 12), and Xen has that register hardcoded to 0. So, I guess there's probably no harm in setting the bits but I doubt they are of any value since we never give any guest privilege to use them. Paul > -George _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |