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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 10.01.14 at 16:57, Simon Graham <simon.graham@xxxxxxxxxx> wrote:
>> >>> 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...

I'd read "atomic" here as "as atomic as possible". "emulate" is bad
imo because the function may be used for other purposes too.

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

Perhaps because it doesn't work on virtual addresses (page tables
always hold physical ones)? Maybe it could use
hvm_copy_{to,from}_guest_phys(), but I would assume those
routines didn't exist yet when the shadow code was written. Tim
may know further details...

Jan


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