From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: Re: [PATCH] Fixing ATS enabling for device assignment Date: Wed, 19 May 2010 08:19:14 +0100 Message-ID: <4BF39F03020000780005E03B@vpn.id2.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Return-path: Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: weidong.han@intel.com Cc: xen-devel@lists.xensource.com, keir.fraser@eu.citrix.com List-Id: xen-devel@lists.xenproject.org >>> "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_mappi= ng(), 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). Further, if ATS gets enabled at boot time, why would you want to disable = it after de-assignment? Finally (only partially related) - why are {en,dis}able_ats_device() = architecture specific? PCI config space accesses really aren't I would = think. Jan