From mboxrd@z Thu Jan 1 00:00:00 1970 From: Razvan Cojocaru Subject: Re: [PATCH] xen: Disable RAM-to-RAM copy in hvmemul_rep_movs() when mem_access_emulate_enabled Date: Tue, 05 May 2015 14:27:04 +0300 Message-ID: <5548A908.6030704@bitdefender.com> References: <1430820082-15790-1-git-send-email-rcojocaru@bitdefender.com> <5548B6340200007800076984@mail.emea.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <5548B6340200007800076984@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 Cc: andrew.cooper3@citrix.com, keir@xen.org, xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org On 05/05/2015 01:23 PM, Jan Beulich wrote: >>>> On 05.05.15 at 12:01, wrote: >> The mem_access client might want to use hvm_emulate_one_no_write(), >> in which case the RAM-to-RAM copy code in hvmemul_rep_movs() would >> lead to an unwanted (and unexpected) write operation. > > I don't follow: hvm_emulate_one_no_write() uses > hvm_emulate_ops_no_write, which in turn uses > hvmemul_rep_movs_discard(). What unwanted writes are you > talking about? And if it was needed, why would > hvmemul_rep_stos() not require a similar tweak? You're right, my mistake. I'm testing a few patches meant for the a new series, and one of them introduces a third kind of emulation, and the problem is only there - the nowrite case is fine, as you rightly pointed out. Sorry for the false alarm. On the bright side, this just saved a bit of back-and-forth when the series is submitted. Thanks, Razvan