[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH] x86/HVM: support IOMMU-related Viridian CPUID bits
>>> 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). Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |