From mboxrd@z Thu Jan 1 00:00:00 1970 From: Boris Ostrovsky Subject: Re: [PATCH v6 2/4] x86/hvm: Treat non-instruction fetch nested page faults also as read violations Date: Fri, 15 Aug 2014 10:31:10 -0400 Message-ID: <53EE19AE.1010000@oracle.com> References: <1407768526-29112-1-git-send-email-tamas.lengyel@zentific.com> <1407768526-29112-2-git-send-email-tamas.lengyel@zentific.com> <53ECE8B0.50405@citrix.com> <53ED2C9D02000078000BA7E4@mail.emea.novell.com> <53ED4D6E02000078000BA7FC@mail.emea.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <53ED4D6E02000078000BA7FC@mail.emea.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 , Kevin Tian Cc: "ian.campbell@citrix.com" , "stefano.stabellini@eu.citrix.com" , Jun Nakajima , Andrew Cooper , "ian.jackson@eu.citrix.com" , "xen-devel@lists.xen.org" , Eddie Dong , "Aravind.Gopalakrishnan@amd.com" , "suravee.suthikulpanit@amd.com" , Tamas Lengyel List-Id: xen-devel@lists.xenproject.org On 08/14/2014 06:59 PM, Jan Beulich wrote: >>>> On 15.08.14 at 00:34, wrote: >>> From: Jan Beulich [mailto:JBeulich@suse.com] >>> Sent: Thursday, August 14, 2014 1:40 PM >>> >>>>>> On 14.08.14 at 18:49, wrote: >>>> 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. >>> Not if it's unreliable. Plus on x86 elsewhere write access implies >>> read access anyway. If you look at the draft patch I had sent >>> Tamas (which I intend to rebase on his series), you'll see that >>> there the change here is actually strictly needed. >>> >> I think you're mixing the behavior and policy here. from behavior p.o.v, >> we should keep whatever hardware reports, which describes the behavior >> of the instruction causing violation whether it's a write operation or read >> operation. From policy p.o.v, you may treat a write operation as read >> operation in specific code paths (if access==read || access ==write). > No - the hardware specifically does _not_ guarantee to report the > actual characteristics of a read-modify-write instruction. Or at least > that's what your documentation warns about. And to be on the safe > side, treating all writes as also being reads is the better option than > to mistakenly treat r-m-w as just w. Is this specific to VMX or does SVM have the same problem (I am not aware of this but I might be wrong). Because if it doesn't then I think Tamas' [PATCH v6 2/4] should have SVM report actual bits. If, OTOH, you need both return same results for consistency then I wonder whether we could move this up the stack into HVM common code. -boris