Re: [Xen-devel] [PATCH] Fixing ATS enabling for device assignment

[Weidong Han <weidong.han@xxxxxxxxx>]

Jan Beulich wrote:
> > > > "Han, Weidong"  05/19/10 4:37 AM >>>
> > > >         
> > Currently, Xen only enables ATS in Xen booting. When a ATS capable device is 
> > assigned to guest, ATS is actually not enabled because FLR before assignment 
> > causes it to be disabled. Thus ATS cannot be used in guest. This patch enables 
> > ATS in domain_context_mapping. This ensures ATS is enabled in assignment 
> > because FLR is earlier than domain_context_mapping call. Therefore ATS can be 
> > used in guest. This patch also implements disable_ats_device to disable ATS 
> > when the device is deassigned from a domain.
> >     
> Hmm, this looks inconsistent to me: Iirc FLR is being done from the tools, so 
> unless it is technically impossible to do FLR after domain_context_mapping(), 
> the patch creates a hypervisor dependency on the tools (if nothing else, a 
> latent bug - to be introduced the moment operation ordering changes in the 
> tools).
>   
It doesn't depend on FLR from tools. It just ensures ATS is enabled for 
device assignment in guest. If ATS is already enabled, enable_ats_device 
won't re-enable it.
> Further, if ATS gets enabled at boot time, why would you want to disable it 
> after de-assignment?
>   
ATS enabled devices will be added to ats_devices list. disabling ATS 
will remove a device from that list and avoid leak. If ATS is enabled on 
a VF, and it's destroyed by removing PF driver, disable_ats_device will 
be invoked to remove it from the list.
Regards,
Weidong
> Finally (only partially related) - why are {en,dis}able_ats_device() 
> architecture specific? PCI config space accesses really aren't I would think
>   
> Jan
>   

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel