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

[Razvan Cojocaru <rcojocaru@xxxxxxxxxxxxxxx>]

On 10/05/2016 04:02 PM, Jan Beulich wrote:
>>>> On 05.10.16 at 14:53, <rcojocaru@xxxxxxxxxxxxxxx> wrote:
>> On 10/05/2016 03:47 PM, Jan Beulich wrote:
>>>>>> On 05.10.16 at 14:44, <rcojocaru@xxxxxxxxxxxxxxx> wrote:
>>>> On 10/05/2016 03:29 PM, Jan Beulich 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().
>>>>
>>>> That's an accident, in hvmemul_cmpxchg() p_old is not being used at all
>>>> so IIRC I've simply latched onto p_new. All we're interested in are
>>>> reads from the supplied buffer overriding the guest's actual memory.
>>>
>>> So am I to understand you'll submit a patch replacing p_old with
>>> p_new there (which would have the same effect as simply deleting
>>> that code, except for the doc aspect)?
>>
>> Yes, I'll get on that. I'll also const-ify the p_new pointer unless
>> there are objections.
> 
> You won't be able to - that's where I started actually.

You're right - just found out the hard way. I'll just submit the smaller
patch then in a moment.


Thanks,
Razvan

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