From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: [PATCH v6 2/4] x86/hvm: Treat non-instruction fetch nested page faults also as read violations Date: Thu, 14 Aug 2014 17:49:52 +0100 Message-ID: <53ECE8B0.50405@citrix.com> References: <1407768526-29112-1-git-send-email-tamas.lengyel@zentific.com> <1407768526-29112-2-git-send-email-tamas.lengyel@zentific.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4937597623361209867==" Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: "Tian, Kevin" , Tamas Lengyel Cc: "ian.campbell@citrix.com" , "stefano.stabellini@eu.citrix.com" , "Dong, Eddie" , "ian.jackson@eu.citrix.com" , "xen-devel@lists.xen.org" , "JBeulich@suse.com" , "Aravind.Gopalakrishnan@amd.com" , "Nakajima, Jun" , "boris.ostrovsky@oracle.com" , "suravee.suthikulpanit@amd.com" List-Id: xen-devel@lists.xenproject.org --===============4937597623361209867== Content-Type: multipart/alternative; boundary="------------000401080905020601040407" --------------000401080905020601040407 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit On 14/08/14 17:43, Tian, Kevin wrote: > > but doing so just moves from one incomplete solution (where > read-modify-write is not treated as read-violation) to another > incomplete solution (where all writes are treated read-violation). If > there's actual usage relying on accurate read-violation information, > either solution doesn't work. So I don't see the value of this change. > I would agree. Anything using this information will have to have detailed knowledge of what the hardware is capable of reporting, to understand the information it has to hand. I think Xen should faithfully pass on what hardware reports. It will be more useful to the consumer than blurring the details like this. ~Andrew --------------000401080905020601040407 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit
On 14/08/14 17:43, Tian, Kevin wrote:

but doing so just moves from one incomplete solution (where read-modify-write is not treated as read-violation) to another incomplete solution (where all writes are treated read-violation). If there’s actual usage relying on accurate read-violation information, either solution doesn’t work. So I don’t see the value of this change.


I would agree.  Anything using this information will have to have detailed knowledge of what the hardware is capable of reporting, to understand the information it has to hand.

I think Xen should faithfully pass on what hardware reports.  It will be more useful to the consumer than blurring the details like this.

~Andrew --------------000401080905020601040407-- --===============4937597623361209867== 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 --===============4937597623361209867==--