Re: [Xen-devel] ATS and dependent features

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 29.11.12 at 10:19, "Zhang, Xiantao" <xiantao.zhang@xxxxxxxxx> wrote:

> 
>> -----Original Message-----
>> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
>> Sent: Thursday, November 29, 2012 4:01 PM
>> To: Zhang, Xiantao
>> Cc: xen-devel
>> Subject: RE: ATS and dependent features
>> 
>> >>> On 29.11.12 at 02:07, "Zhang, Xiantao" <xiantao.zhang@xxxxxxxxx>
>> wrote:
>> > ATS should be a host feature controlled by iommu, and I don't think
>> > dom0 can control  it from Xen's architecture.
>> 
>> "Can" or "should"? Because from all I can tell it currently clearly does.
> 
> I mean Xen shouldn't  allow these capabilities can be detected by dom0.  If 
> it does, we need to fix it. 

It sort of hides it - all callers sit in the kernel's IOMMU code, and
IOMMU detection is being prevented. So it looks like the code is
simply dead when running on top of Xen.

>> >   Perhaps we need to forbid dom0 controlling these features.
>> 
>> That's what I was trying to find out. How to properly do that with pv-ops I
>> don't know; in our forward ported kernels I can simply make the respective
>> config options conditional upon !XEN. 
> 
> As to the clean solution, Xen should intercept all the accesses to the 
> device's PCI config space from dom0, and emulates the related registers.

Why? That would e.g. make lspci completely unreliable.

Jan


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