Re: [Qemu-devel] [RFC PATCH 0/6] Enhancing Qemu MMIO emulation with scripting interface

From: David Gibson <david@gibson.dropbear.id.au>
To: "Cédric Le Goater" <clg@kaod.org>
Cc: Peter Maydell <peter.maydell@linaro.org>,
	maddy@linux.vnet.ibm.com, qemu-devel@nongnu.org,
	Balamuruhan S <bala24@linux.ibm.com>,
	anju@linux.vnet.ibm.com, hari@linux.vnet.ibm.com,
	pbonzini@redhat.com
Subject: Re: [Qemu-devel] [RFC PATCH 0/6] Enhancing Qemu MMIO emulation with scripting interface
Date: Fri, 9 Aug 2019 14:49:23 +1000	[thread overview]
Message-ID: <20190809044923.GO5465@umbus.fritz.box> (raw)
In-Reply-To: <9cbb8079-d606-ab69-a5b3-93226888108a@kaod.org>

[-- Attachment #1: Type: text/plain, Size: 2083 bytes --]

On Wed, Aug 07, 2019 at 10:15:48AM +0200, Cédric Le Goater wrote:
> On 07/08/2019 09:14, Balamuruhan S wrote:
> > Hi All,
> > 
> > This is a proposal to extend mmio callbacks in Qemu with scripting interface
> > that is prototyped with python in this implementation. It gives ability to
> > feed runtime data through callbacks without recompiling Qemu in generic way.
> > This patchset adds library that provides APIs for Qemu to talk with python
> > scripts placed in path -module-path and how existing xscom can be extended
> > with python interface infrastructure.
> > 
> > We have also added an hacky emulation for memory region (OCC common area and HOMER)
> > which is shared between core and un-core engine (ideally this should be via
> > sram device) to showcase the effectiveness of having the scripting interface
> > (uncore engine taken for discussion here is powerpc specificed called OCC).
> 
> We should try to merge this part first. It is useful as it is after some
> cleanups.
> 
> > Having scripting interface helps to emulate/test different uncore-core
> > interactions including uncore engine failure or hang. It also helps in feeding
> > randomized data at byte level access. This patchset is primarily to extend mmio
> > callbacks with scripting interface and to demonstrate effectiveness it.
> 
> It is already possible to feed device models with external data using QMP or
> external agents using a chardev backend transport. What are the benefits
> of using the embedded python approach ?  

Yeah, I also think this needs better justification.

In particular what's the case that Python makes this significantly
easier than hacking up experimental interactions with C.  I mean you
already have to understand POWER9 internals to work with this, right,
so I wouldn't expect Python's greater accessibility to be a big
concern here.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]