From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Tian, Kevin" Subject: Re: [PATCH 2/4 v2] x86/EPT: refine direct MMIO checking when determining EMT Date: Mon, 28 Apr 2014 12:02:09 +0000 Message-ID: References: <53579447020000780000B2A9@nat28.tlf.novell.com> <5357989A020000780000B2E6@nat28.tlf.novell.com> <535A6BB4020000780000C485@nat28.tlf.novell.com> <535E2C64020000780000CAFE@nat28.tlf.novell.com> <535E40C4020000780000CC71@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1WekGf-000756-6y for xen-devel@lists.xenproject.org; Mon, 28 Apr 2014 12:02:41 +0000 In-Reply-To: <535E40C4020000780000CC71@nat28.tlf.novell.com> Content-Language: en-US List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich Cc: xen-devel , KeirFraser , "Dong, Eddie" , "Nakajima, Jun" , Tim Deegan List-Id: xen-devel@lists.xenproject.org > From: Jan Beulich [mailto:JBeulich@suse.com] > Sent: Monday, April 28, 2014 5:52 PM > > >>> On 28.04.14 at 11:06, wrote: > >> From: Jan Beulich [mailto:JBeulich@suse.com] > >> Sent: Monday, April 28, 2014 4:25 PM > >> > >> >>> On 28.04.14 at 09:59, wrote: > >> >> From: Jan Beulich [mailto:JBeulich@suse.com] > >> >> @@ -810,10 +811,7 @@ int epte_get_entry_emt(struct domain *d, > >> >> return -1; > >> >> } > >> >> > >> >> - if ( !iommu_enabled || > >> >> - (rangeset_is_empty(d->iomem_caps) && > >> >> - rangeset_is_empty(d->arch.ioport_caps) && > >> >> - !has_arch_pdevs(d)) ) > >> >> + if ( !need_iommu(d) && !cache_flush_permitted(d) ) > >> > > >> > &&->|| > >> > >> No, specifically not - we shouldn't force WB in either case. > >> > > > > well, I gave original comments with the impression that it's a cleanup patch > > instead of fixing anything, e.g. iommu_enabled->need_iommu, and > open-coding > > to cache_flush_permitted. Based on that thought, && changes original > meaning. > > > > so you actually fix the conditions here. I didn't follow up latest advance > > in device > > assignment recently. Could you elaborate in which situation I/O resources > > are > > assigned while iommu is not required? > > It's not so much a question of "required": IOMMU setup only > happens when a PCI device gets assigned to a guest. It specifically > does not happen (and would make no sense, because the IOMMU > concepts are PCI device based) when a raw MMIO or port range gets > assigned. While the latter is insecure, I don't think we currently do > anything to disallow this, and hence we shouldn't break it here. > Got it. Acked-by: Kevin Tian