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

[Balamuruhan S]

On 8/9/19 10:19 AM, David Gibson wrote:
> 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.

right, with python interface what I could think of is,

1. we don't have to patch up every experimental interactions and recompile.
2. we can easily feed in invalid data type to see the behavior for 
negative/error
   scenarios.
3. Similar to qtest and acceptance test we can use this to cover many scenarios.
4. Ease the CI and maintenance to have test/code separately.

>