Re: [PATCH v2] TCG plugin API extension to read guest memory content by an address

[Alex Bennée]

Mikhail Tyutin <m.tyutin@yadro.com> writes:

>> Not sure what happened with the formatting of this patch, I think there
>> is an html part getting in the way.
> I guess line ends were messed up somewhere on my side. Will try to figure out 
> the root cause.
>
>
>> > +    qemu_plugin_vcpu_read_phys_mem(vcpuIndex, vaddr, memContent,
>> > size);
>> 
>> So the problem with this approach is the memory value you read here may not 
>> be
>> the same as the value that was read by the instruction. This could
>> because of a few reasons:
>> 
>>   - an mmio write changes underlying memory layout
>>   - another thread changes memory after the access
>> 
>> I think a better way to get this information would be to register a new
>> type of call-back which can duplicate the value in the store/load and
>> pass it directly to the callback. It might even be worth just fixing up
>> the existing callback and breaking compatibility rather than having two
>> callback types?
>> 
>> We didn't do this originally as we were being cautious about any
>> attempts to use plugins to workaround the GPL for doing HW emulation -
>> however I don't think adding the memory values to the callbacks greatly
>> increases that risk.
>> 
>> --
>> Alex Bennée
>> Virtualisation Tech Lead @ Linaro
>
> Do you mean concurrent access to the same memory block by multiple
> threads?

Yes - although we also see MMU changes updating a mapping for a given
vaddr -> phys address.

>
> I think , for guest threads/cores if we observe mismatch of memory content 
> read by a plugin and instruction
> itself, then it should clearly indicate that guest software has true data 
> race problem sitting somewhere
> in its code. Otherwise other threads would wait on a synchronization object 
> to let current thread
> perform both memory operations (plugin callback + instruction).

Other threads don't pause at all (unless you do something in the plugin
to force that)

> On the other hand, concurrent access
> using atomic operation will indeed cause either plugin or instruction to read 
> invalid memory content.
>
> Isn’t it the same problem as we face in case of GDB attached to running Qemu 
> instance (gdbserver) and
> asking it to read some memory? How is it solved there?

Yes and it's not solved except usually most interactions with the guest
during debugging are while the system is paused.

-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro