Thanks for your quick response. On Mon, Mar 30, 2020 at 9:15 AM Alex Bennée <alex.ben...@linaro.org> wrote:
> > Lukas Straub <lukasstra...@web.de> writes: > > >> My question is, how do I access the guest memory and registers from the > >> plugin callback function? The API seems to indicate that it is possible, > >> since the callback registering requires you to say if you will access > them, > >> and if it's RW or just read. > > Currently we document what plugins can do in docs/devel/tcg-plugins.rst: > > TCG plugins are unable to change the system state only monitor it > passively. However they can do this down to an individual instruction > granularity including potentially subscribing to all load and store > operations. > > This was a conscious decision to avoid plugins being used as an end-run > around the GPL to implement proprietary out-of-tree extensions. > > That is not to say we might relax the rules in the future - it was a > topic of discussion at the maintainers summit and we wanted to document > some guidelines around interfacing with QEMU so people didn't get the > wrong idea about what these APIs provide (c.f. multi-process qemu and > vhost-user which could also be abused in similar ways). > I understand restricting the API so that the system state cannot be changed, only inspected. I should have been more specific in my question. I am attempting to create a plugin that tracks all memory accesses, so I can emulate cache behavior. The reason I would like to read the registers, is because many load/store instructions depend on register values, which I can only be sure of at run-time. Some of the concepts you mentioned I am not very familiar with; I am simply emulating an ARM A9 processor in bare-metal mode, to give you a point of reference of my use case. > Indeed Emilio's original tree did contain these more invasive hooks and > while we deliberate upstream it will hopefully not be as hard to > maintain a light out-of-tree fork should you need such functionality now. > Could you please point me towards this tree? I haven't run across it yet in my investigating of all of this. > >> Are there any examples of using this part of the API? I realize this is > a > >> very new part of Qemu functionality. > > So far the examples represent the totality of the API that has been > exercised and I'm keen we add more as new extensions to the API are > added. As to the specific question about accessing register values that > is exactly down to the newness of the API. > > Register access is a tricky problem because of the fact that QEMU > supports so many guest architectures. I wasn't keen on slapping in a > functional but ugly API that hard-coded values like gdb register ids so > I left it out for the time being. I'd happily accept patches to add that > functionality assuming it meets the projects quality and taste > guidelines. > > Some approaches we could take include: > > - hook into tcg_global_*_new and allow plugin to introspect registers > - hook into gdbstub in some way > > The first approach elides over the fact that a lot of registers aren't > actually known to the TCG - pretty much all vector registers tend to be > loaded into anonymous TCG temps as we go. Maybe this could just be fixed > by just providing a few more registrations functions at the start even > if the TCG itself wouldn't use that knowledge. > > The gdbstub provides a lot more visibility of register state and for > some architectures this can be quite comprehensive - for example in > system mode you can access pretty much every ARM co-processor register. > However the gdb interface is a little clunky as there are a lot of magic > register id numbers and the canonical way to enumerate this is to chew > through a bunch of XML that each target generates (see > gdb_register_coprocessor). I'm not keen on exposing that pile of XML via > the register interface. Maybe there is scope to improve our internal > APIs so the enumeration of registers can be handled by helpers that > record mappings and ids and generate the XML for the gdbstub centrally? > > There may be other approaches we could take and I'm open to suggestions. > I'd be happy to look into ways to implement this functionality. However, I just started using Qemu this year, so these things sound like they would have a steep learning curve for me. The gdbstub approach seems like it would provide the most introspection ability. What would you suggest as a starting point for looking into this? All of this being said, if you think my project is too complicated, to implement a cache emulator with TCG plugins, then I could always try just hacking together some custom helper functions. > -- > Alex Bennée > Thanks
