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

[Balamuruhan S]

On 8/8/19 3:55 PM, Stefan Hajnoczi wrote:
> On Wed, Aug 07, 2019 at 12:44:39PM +0530, Balamuruhan S wrote:
>> 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).
>> 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.
>>
>> Some changes are required in PowerPC skiboot tree to test these changes since
>> the memory region is disabled currently for Qemu emulated PowerNV host,
>> https://github.com/balamuruhans/skiboot/commit/a655514d2a730e0372a2faee277d1cf01f71a524
> Although writing Python is quick and easy, carefully wiring up the
> Python C API for it is not.  In practice you lose much of the benefit of
> Python if you need to study the Python C API every time you wish to do
> some quick scripting :(.

Initially as you said to wire Python C API it needs study and care, but
once the framework reach to a stability we can use it for easy scripting
using it seamlessly.

>
> It must be possible to compile out the Python integration code.  If the
> Python integration code remains in the device model then the QEMU binary
> has a dependency on libpython, which is undesirable when this feature is
> not in use.

if we can keep it conditional during configure, so that by default qemu
binary will not depend on libpython. If user needs to use this feature
then python 3 based libpython and python-config are necessary.

>
> Assuming this feature can be compiled out, I think it should have a
> chance to prove its usefulness and gain users.  Documentation and an
> active maintainer are essential.

yes, hope that community will find its usefulness as it helped us to
test, study behavior of firmware/kernel and find bugs that is hard
to find otherwise.

Agreed that it would need proper documentation and active maintainer.

>
> Stefan