From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: [PATCH 0/5] x86: EPT/MTRR interaction adjustments and cleanup Date: Fri, 07 Mar 2014 09:08:59 +0000 Message-ID: <53198CAB.5070704@gmail.com> References: <530C7CAB020000780011F121@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1998681309337975172==" Return-path: Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1WLqm8-0006FG-Nj for xen-devel@lists.xenproject.org; Fri, 07 Mar 2014 09:09:04 +0000 Received: by mail-bk0-f53.google.com with SMTP id r7so835414bkg.26 for ; Fri, 07 Mar 2014 01:09:02 -0800 (PST) In-Reply-To: <530C7CAB020000780011F121@nat28.tlf.novell.com> 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: Keir Fraser , Eddie Dong , Dongxiao Xu , Jun Nakajima , Yang Z Zhang , xen-devel List-Id: xen-devel@lists.xenproject.org This is a multi-part message in MIME format. --===============1998681309337975172== Content-Type: multipart/alternative; boundary="------------090005030205080304040907" This is a multi-part message in MIME format. --------------090005030205080304040907 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Jan Beulich wrote: > > 1: x86/hvm: refine the judgment on IDENT_PT for EMT > 2: x86/HVM: fix memory type merging in epte_get_entry_emt() > 3: x86/HVM: consolidate passthrough handling in epte_get_entry_emt() > 4: x86/HVM: use manifest constants / enumerators for memory types > 5: x86/HVM: adjust data definitions in mtrr.c > > With this series in place (or actually the first three patches thereof, > as the rest is cleanup), apart from the need to fully drop the > dependency on HVM_PARAM_IDENT_PT (see the discussion started > at > http://lists.xenproject.org/archives/html/xen-devel/2014-02/msg02150.html) > the other main question is whether the dependency on iommu_snoop > is really correct: I don't see why the IOMMU's snooping capability > would affect the cachability of memory accesses - especially in the > GPU passthrough case, RAM pages may need mapping as UC/WC > if the GPU is permitted direct access to them - uniformly using WB > here seems to be calling for problems. > > Signed-off-by: Jan Beulich Acked-by: Keir Fraser --------------090005030205080304040907 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Jan Beulich wrote:

1: x86/hvm: refine the judgment on IDENT_PT for EMT
2: x86/HVM: fix memory type merging in epte_get_entry_emt()
3: x86/HVM: consolidate passthrough handling in epte_get_entry_emt()
4: x86/HVM: use manifest constants / enumerators for memory types
5: x86/HVM: adjust data definitions in mtrr.c

With this series in place (or actually the first three patches thereof,
as the rest is cleanup), apart from the need to fully drop the
dependency on HVM_PARAM_IDENT_PT (see the discussion started
at http://lists.xenproject.org/archives/html/xen-devel/2014-02/msg02150.html)
the other main question is whether the dependency on iommu_snoop
is really correct: I don't see why the IOMMU's snooping capability
would affect the cachability of memory accesses - especially in the
GPU passthrough case, RAM pages may need mapping as UC/WC
if the GPU is permitted direct access to them - uniformly using WB
here seems to be calling for problems.

Signed-off-by: Jan Beulich<jbeulich@suse.com>


Acked-by: Keir Fraser <keir@xen.org>
--------------090005030205080304040907-- --===============1998681309337975172== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============1998681309337975172==--