From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: Re: [PATCH 2/4 v2] x86/EPT: refine direct MMIO checking when determining EMT Date: Mon, 28 Apr 2014 10:51:32 +0100 Message-ID: <535E40C4020000780000CC71@nat28.tlf.novell.com> References: <53579447020000780000B2A9@nat28.tlf.novell.com> <5357989A020000780000B2E6@nat28.tlf.novell.com> <535A6BB4020000780000C485@nat28.tlf.novell.com> <535E2C64020000780000CAFE@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1WeiDq-00028t-8C for xen-devel@lists.xenproject.org; Mon, 28 Apr 2014 09:51:38 +0000 In-Reply-To: Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Kevin Tian Cc: xen-devel , KeirFraser , Eddie Dong , Jun Nakajima , Tim Deegan List-Id: xen-devel@lists.xenproject.org >>> 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. Jan