Re: [Xen-devel] Inconsistent use of set_context_data()?

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 05.10.16 at 14:29, <JBeulich@xxxxxxxx> wrote:
>>>> On 05.10.16 at 14:22, <rcojocaru@xxxxxxxxxxxxxxx> wrote:
>>> what's the point of this being used by hvmemul_read() and
>>> hvmemul_cmpxchg(), but (namely but not limited to) not by
>>> hvmemul_write()?
>> 
>> To do introspection work, we sometimes need to modify the guest memory,
>> and there are cases, namely during hibernate / resume of Windows guests,
>> when we need to serve the "old" version of that memory to the current
>> instruction reading from it for the process to work reliably.
>> 
>> The design choice here has been that the introspection application is
>> smart enough to handle writes (after all, it is the one managing the
>> buffer sent via vm_event reply), so it is intended behaviour.
> 
> Well - the confusing thing is that for cmpxchg it's the value to be
> written which gets altered, not the value to be compared against,
> i.e. it acts as if set_context_data() was also intended to be
> present in hvmemul_write().

And note how this is the only case where caller supplied data gets
modified - after all at least the p_new pointer should really be const
(for p_old one might argue that upon failure the old value could be
passed back to the caller). And if that altering of caller data was
intended, then there's at least one case where it doesn't take
effect right now: protmode_load_seg()'s updating of the accessed
bit or-s in a_flag into the local copy instead of using new_desc_b.

IOW - I don't really understand what (consistent) behavior is
expected here.

Jan


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