Re: Difficulties to access guest memory in TCG plugins

Re: Difficulties to access guest memory in TCG plugins

[Philippe Mathieu-Daudé]

Cc'ing the maintainer: Alex.

On 6/23/21 5:08 PM, Kevin Mambu wrote:
> Hi, everyone,
> I need to put in place a plugin which is able to modify memory for a
> specific project, and until now I managed to do so using
> cpu_memory_rw_debug().
> However, the function happens to fail at times, and when looking at the
> source code of cpu_memory_rw_debug() on elixir, the issue seems to be
> either the memory being locked by another part of QEMU code or some kind
> of page fault.
> My prior researches tend to put the blame on the RCU lock mechanism, and
> I was wondering if there was another, fail-safe, function I could use to
> access guest memory from my plug-in ?
> 
> Thank you in advance,
> 
> *Kévin Mambu*
> Sent with ProtonMail <https://protonmail.com/> Secure Email.
> 

Re: Difficulties to access guest memory in TCG plugins

[Alex Bennée]

Philippe Mathieu-Daudé <f4bug@amsat.org> writes:

> Cc'ing the maintainer: Alex.
>
> On 6/23/21 5:08 PM, Kevin Mambu wrote:
>> Hi, everyone,
>> I need to put in place a plugin which is able to modify memory for a
>> specific project, and until now I managed to do so using
>> cpu_memory_rw_debug().

Out of interest what is your use-case for this? The project has very
deliberately avoided adding such an API for writing memory for plugins
to avoid people attempting to bypass the GPL by doing things in plugins.

>> However, the function happens to fail at times, and when looking at the
>> source code of cpu_memory_rw_debug() on elixir, the issue seems to be
>> either the memory being locked by another part of QEMU code or some kind
>> of page fault.
>> My prior researches tend to put the blame on the RCU lock mechanism, and
>> I was wondering if there was another, fail-safe, function I could use to
>> access guest memory from my plug-in ?

I'm not surprised. If you look at tlb_plugin_lookup you'll see the
existing introspection code has to jump through some hoops to avoid race
conditions that can cause updates to the internal TLB status. If we
wanted to support reading values from memory that's probably doable -
but for writing it would be hard to do in an idempotent way.

>> 
>> Thank you in advance,
>> 
>> *Kévin Mambu*
>> Sent with ProtonMail <https://protonmail.com/> Secure Email.
>> 


-- 
Alex Bennée

Re: Difficulties to access guest memory in TCG plugins

[Kevin Mambu]

Thank you for you answer.

> Out of interest what is your use-case for this? The project has very
>
> deliberately avoided adding such an API for writing memory for plugins
>
> to avoid people attempting to bypass the GPL by doing things in plugins.
>

In the scope of my Ph. D subject, I want to model a DMA-like mechanism for quick prototyping and evaluation, the plugin emulates an MMIO with Control/Status Registers. I am actually able to pass parameters to the Control/Status Registers through store instruction without any issue. Only the data transfer between two guest memory regions fails at times.

> I'm not surprised. If you look at tlb_plugin_lookup you'll see the
>
> existing introspection code has to jump through some hoops to avoid race
>
> conditions that can cause updates to the internal TLB status. If we
>
> wanted to support reading values from memory that's probably doable -
>
> but for writing it would be hard to do in an idempotent way.
>

I understand, thank you for the clarification. As an alternative, I was thinking about allocating memory in the plug-in for it to redirect guest memory accesses into. This would certainly add significant overhead at execution time, but at least race conditions would be consistently avoided. Could you, please, tell me your opinion on the matter ?

Thank you,

Kévin Mambu
e: kevin.mambu@pm.me
m: +33 6 52 59 96 97
  

Re: Difficulties to access guest memory in TCG plugins

[Peter Maydell]

On Fri, 25 Jun 2021 at 10:25, Kevin Mambu <kevin.mambu@pm.me> wrote:
> In the scope of my Ph. D subject, I want to model a DMA-like mechanism for quick prototyping and evaluation, the plugin emulates an MMIO with Control/Status Registers. I am actually able to pass parameters to the Control/Status Registers through store instruction without any issue. Only the data transfer between two guest memory regions fails at times.

This really isn't what the plugin API is intended for -- it's meant
for tracing and similar sorts of "track what the guest is doing" activities.
If you want to model an MMIO device, you're better off just writing a device
model like any of the others in QEMU, I think: the APIs for doing that
are much more well-proven and there's plenty of examples in the tree
of DMA and other devices.

-- PMM

Re: Difficulties to access guest memory in TCG plugins

[Kevin Mambu]

> This really isn't what the plugin API is intended for -- it's meant
>
> for tracing and similar sorts of "track what the guest is doing" activities.
>
> If you want to model an MMIO device, you're better off just writing a device
>
> model like any of the others in QEMU, I think: the APIs for doing that
>
> are much more well-proven and there's plenty of examples in the tree
>
> of DMA and other devices.
>

Thank you for your response. Indeed, it seems that trying to circumvent the functionalities offered by the Plug-in API will not allow me to properly achieve the modeling of my device. As of now I have a pretty tight schedule but in the near future, I will implement my MMIO device using the appropriate API ; I found the source code of the QEMU educational PCI device.

Thanks for your help, everyone :)

Kévin Mambu