Re: [Qemu-devel] [PATCH v4 00/54] plugins for TCG

[Alex Bennée]

Markus Armbruster <address@hidden> writes:

> Alex Bennée <address@hidden> writes:
>
>> Hi,
>>
>> This is the latest iteration of the plugins series. The main changes
>> from the last version are:
>>
>>   - dropped passing of haddr to plugins
>>
>> This makes the code for handling the plugins less invasive in the
>> softmmu path at the cost of offloading processing to the plugin if it
>> wants the value. We rely on the fact that the TLB is per vCPU so a
>> helper can just trigger a re-query of the TLB to get the final
>> address.
>>
>> Part of that change involved embedding the MMU index in the meminfo
>> field for tracing. I see there are some other patches on the list for
>> messing with TCGMemOp so there might be a clash coming up.
>>
>>   - translator_ld goes direct to softmmu/user functions
>>
>> I also mark the [SOFTMMU_]CODE_ACCESS helpers as deprecated. There is
>> more work to be done to clean up all the current uses of code access
>> helpers but ideally the only thing that should be peaking at code is
>> the translator loop itself. However a bunch of helpers have taken to
>> using code loading functions to peak at the instruction just executed
>> to figure out what to do. Once those have been fixed then we can
>> remove those helpers.
>>
>> Other more minor fixes can be found documented bellow the --- in the
>> individual patches.
>>
>> This series also includes the semihosting patches as they are a
>> pre-requisite for the translator_ld patches for ARM.
>>
>> Once the tree opens up for development again I hope to get the
>> semihosting and trivial clean-up patches merged quickly so the patch
>> count for the plugins patches proper can be reduced a bit.
>
> Next time, please explain briefly what TCG plugins are about right in
> your cover letter.  I had to go hunting for this.  Found "[PATCH v4
> 11/54] docs/devel: add plugins.rst design document".

I'll provide a better overview in my next cover letter.

> Please advise why TCG plugins don't undermine the GPL.  Any proposal to
> add a plugin interface needs to do that.

I'm not sure what we can say about this apart from "ask your lawyer".
I'm certainly not proposing we add any sort of language about what
should and shouldn't be allowed to use the plugin interface. I find it
hard to see how anyone could argue code written to interface with the
plugin API couldn't be considered a derived work.

There are two use cases I have in mind:

The first is FLOSS developers writing interesting tools that can take
advantage of QEMU's control of the system to do experiments that are
tricky with other setups (Valgrind is limited to same-arch, Dynamo/Pin
are user-space only). I want these experiments to be easy to do without
having to keep hacking and re-hacking QEMU's core code. I would hope
QEMU developers would up-stream theirs into the QEMU source tree but I
can imagine academics will have open source code that will only ever sit
in their paper's repository.

The other is users who currently maintain hacked up internal copies of
QEMU as a test bed for whatever piece of silicon they are brewing behind
closed doors. This code would never be distributed (hence never be a GPL
issue) and is generally kept private because it's IP sensitive
(e.g: experimenting with different cache models). If we can provide an
interface that allows them to keep their experiments private and
separate from changes to the core code then maybe apart from making
their lives a bit easier we will see some non-IP sensitive contributions
come back to the upstream. I live in hope ;-)

--
Alex Bennée