[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Possible issue with x86_emulate when writing results back to memory


  • To: Jan Beulich <JBeulich@xxxxxxxx>
  • From: Simon Graham <simon.graham@xxxxxxxxxx>
  • Date: Fri, 10 Jan 2014 15:57:49 +0000
  • Accept-language: en-US
  • Cc: Andrew Cooper <Andrew.Cooper3@xxxxxxxxxx>, xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Fri, 10 Jan 2014 15:57:53 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xen.org>
  • Thread-index: Ac711YmNMUOUVnlMTTS29ThyibIwTgXqECOAAApgbkD//7MDgIAAUXVAgAE3N4CAAFH2kA==
  • Thread-topic: [Xen-devel] Possible issue with x86_emulate when writing results back to memory

> >>> On 09.01.14 at 18:33, Simon Graham <simon.graham@xxxxxxxxxx> wrote:
> >> __hvm_copy() is probably too low to be thinking about this.  There are
> >> many things such as grant_copy() which do not want "hardware like" copy
> >> properties, preferring instead to have less overhead.
> >>
> >
> > Yeah... I'll rework the patch to do this...
> 
> Looking a little more closely, hvm_copy_{to,from}_guest_virt()
> are what you want to have the adjusted behavior. That way
> you'd in particular not touch the behavior of the more generic
> copying routines copy_{to,from}_user_hvm(). And adjusting
> the behavior would seem to be doable cleanly by adding e.g.
> HVMCOPY_atomic as a new flag, thus informing __hvm_copy()
> to not use memcpy().
> 

Thanks -- I was coming to the same conclusion slowly too! Although I think I 
might call it HVMCOPY_emulate rather than atomic since it's not the case that 
the entire copy is atomic...

Now I just have to figure out why the shadow code doesn't use the hvm copy_to_ 
routine...

> Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.