All of lore.kernel.org
 help / color / mirror / Atom feed
* Re: Difficulties to access guest memory in TCG plugins
       [not found] <o1Yk83q9b8fPEPYKowd-FS7TM3GAByNtQScLqBwokjniIxwBv-rLo3gQU5MAjLDZGJn9hOGiPudeSXvp3TS-QxouCtlVqHbsnGqXf8dKs_k=@protonmail.com>
@ 2021-06-24  8:14 ` Philippe Mathieu-Daudé
  2021-06-24 19:41   ` Alex Bennée
  0 siblings, 1 reply; 5+ messages in thread
From: Philippe Mathieu-Daudé @ 2021-06-24  8:14 UTC (permalink / raw)
  To: Kevin Mambu, Alex Bennée; +Cc: qemu-devel, qemu-discuss

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.
> 



^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Difficulties to access guest memory in TCG plugins
  2021-06-24  8:14 ` Difficulties to access guest memory in TCG plugins Philippe Mathieu-Daudé
@ 2021-06-24 19:41   ` Alex Bennée
  2021-06-25  9:18     ` Kevin Mambu
  0 siblings, 1 reply; 5+ messages in thread
From: Alex Bennée @ 2021-06-24 19:41 UTC (permalink / raw)
  To: Philippe Mathieu-Daudé; +Cc: Kevin Mambu, qemu-devel, qemu-discuss


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


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Difficulties to access guest memory in TCG plugins
  2021-06-24 19:41   ` Alex Bennée
@ 2021-06-25  9:18     ` Kevin Mambu
  2021-06-25  9:27       ` Peter Maydell
  0 siblings, 1 reply; 5+ messages in thread
From: Kevin Mambu @ 2021-06-25  9:18 UTC (permalink / raw)
  To: Alex Bennée; +Cc: Philippe Mathieu-Daudé, qemu-devel, qemu-discuss

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
  



^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Difficulties to access guest memory in TCG plugins
  2021-06-25  9:18     ` Kevin Mambu
@ 2021-06-25  9:27       ` Peter Maydell
  2021-06-25 11:41         ` Kevin Mambu
  0 siblings, 1 reply; 5+ messages in thread
From: Peter Maydell @ 2021-06-25  9:27 UTC (permalink / raw)
  To: Kevin Mambu
  Cc: qemu-discuss, Alex Bennée, Philippe Mathieu-Daudé, qemu-devel

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


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Difficulties to access guest memory in TCG plugins
  2021-06-25  9:27       ` Peter Maydell
@ 2021-06-25 11:41         ` Kevin Mambu
  0 siblings, 0 replies; 5+ messages in thread
From: Kevin Mambu @ 2021-06-25 11:41 UTC (permalink / raw)
  To: Peter Maydell
  Cc: qemu-discuss, Alex Bennée, Philippe Mathieu-Daudé, qemu-devel

> 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



^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2021-06-25 13:06 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <o1Yk83q9b8fPEPYKowd-FS7TM3GAByNtQScLqBwokjniIxwBv-rLo3gQU5MAjLDZGJn9hOGiPudeSXvp3TS-QxouCtlVqHbsnGqXf8dKs_k=@protonmail.com>
2021-06-24  8:14 ` Difficulties to access guest memory in TCG plugins Philippe Mathieu-Daudé
2021-06-24 19:41   ` Alex Bennée
2021-06-25  9:18     ` Kevin Mambu
2021-06-25  9:27       ` Peter Maydell
2021-06-25 11:41         ` Kevin Mambu

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.