[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RFC] tcg plugin: Additional plugin interface
From: |
Aaron Lindsay |
Subject: |
Re: [RFC] tcg plugin: Additional plugin interface |
Date: |
Wed, 28 Apr 2021 09:41:16 -0400 |
On Apr 26 18:42, Alex Bennée wrote:
>
> 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 ;-).
I would love to be copied on any patches as well. I've wanted to look
into doing this properly for some time now, but have not made time.
-Aaron