[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RFC] tcg plugin: Additional plugin interface
From: |
Alex Bennée |
Subject: |
Re: [RFC] tcg plugin: Additional plugin interface |
Date: |
Mon, 26 Apr 2021 18:42:51 +0100 |
User-agent: |
mu4e 1.5.12; emacs 28.0.50 |
Min-Yih Hsu <minyihh@uci.edu> writes:
> Hi Alex,
>
>> On Apr 23, 2021, at 8:44 AM, Alex Bennée <alex.bennee@linaro.org> wrote:
>>
>>
>> Min-Yih Hsu <minyihh@uci.edu> writes:
>>
>>> Hi Alex and QEMU developers,
>>>
>>> Recently I was working with the TCG plugin. I found that
>>> `qemu_plugin_cb_flags` seems to reserve the functionality to
>>> read / write CPU register state, I'm wondering if you can share some
>>> roadmap or thoughts on this feature?
>>
>> I think reading the CPU register state is certainly on the roadmap,
>> writing registers presents a more philosophical question of if it opens
>> the way to people attempting a GPL bypass via plugins. However reading
>> registers would certainly be a worthwhile addition to the API.
>
> Interesting…I’ve never thought about this problem before.
>
>>
>>> Personally I see reading the CPU register state as (kind of) low-hanging
>>> fruit. The most straightforward way to implement
>>> it will be adding another function that can be called by insn_exec
>>> callbacks to read (v)CPU register values. What do you
>>> think about this?
>>
>> It depends on your definition of low hanging fruit ;-)
>>
>> Yes the implementation would be a simple helper which could be called
>> from a callback - I don't think we need to limit it to just insn_exec. I
>> think the challenge is proving a non-ugly API that works cleanly across
>> all the architectures. I'm not keen on exposing arbitrary gdb register
>> IDs to the plugins.
>>
>> There has been some discussion previously on the list which is probably
>> worth reviewing:
>>
>> Date: Mon, 7 Dec 2020 16:03:24 -0500
>> From: Aaron Lindsay <aaron@os.amperecomputing.com>
>> Subject: Plugin Register Accesses
>> Message-ID: <X86YnHhHMpQBr2/G@strawberry.localdomain>
>>
>> But in short I think we need a new subsystem in QEMU where frontends can
>> register registers (sic) and then provide a common API for various
>> users. This common subsystem would then be the source of data for:
>>
>> - plugins
>> - gdbstub
>> - monitor (info registers)
>> - -d LOG_CPU logging
>>
>> If you are interested in tackling such a project I'm certainly happy to
>> provide pointers and review.
>
> Thank you! Yeah I’m definitely going to scratch a prototype for this
> register reading plugin interface. I’ll take a look at related email
> discussions.
Awesome - please CC me on any patches you come up with (as well as
qemu-devel of course ;-).
>
> Best,
> -Min
>
>>
>>>
>>> Thank you
>>> -Min
>>
>>
>> --
>> Alex Bennée
--
Alex Bennée