RE: [Qemu-devel] Unified device model

[Stanislav Shwartsman]

Hi again,
 
>>It is not a secret that all open source emulators (QEMU, Bochs, Xen) use
>>the same emulated devices and mostly copy-paste their emulation one from
>>another.

>While from my understanding Xen uses qemu's hardware emulation for it's VT
>support, this is not really true otherwise.

>The devices emulated by qemu and bochs are quite similar, but the code 
>looks completely different (appears to be a ground-up rewrite).

I am talking about the device models only. Inside CPU emulation QEMU, Bochs
and Xen are completely different, but they use the same devices for full
system emulation and they most likely want to move forward together. The
devices system of QEMU and Bochs become outdate, it is required to add ACPI
compliance and emulate new modern ACPI compatible devices, currently
emulated i440FX already not so represent the real life and most of the
modern OSes already have no support for it.

 
>> I don't know who originally wrote the device models but now Bochs and
>> QEMU maintain two similar implementations of the same devices.
>> If one of the teams fixes the implementation or add functionality,
>> another team mostly copy-paste the changes to their model.

>I don't know how well Bochs and qemu keep in touch with each other. I've 
>never seen a Bochs developer announce themselves here, though.

So may we should ;)
At least I see the code changes from Bochs migrating to QEMU and vise versa
when I am looking into the code.

>>Xen project forked from QEMU and want to stay in touch with Bochs and QEMU
>>device models and contribute the changes to make the model better.

>Not true. Xen is completely independent. Unless you are refering to the
>hardware emulation - which I believe is qemu's stuff.

I know that it is completely independent project. But their device models
could be called separate project Xen-HWEMU and it is fork from QEMU.

>>I am wondering about making unified device models architecture for open
>>source simulators.
>>The device models will be used in QEMU, Bochs, Xen and other open source
>>simulators which would use the device models.

>I would support this idea, if it was possible.

Why not ?
You always could consider to add simple modules C++ to QEMU or build C++
device -> C device interface bridge ...
I don't know all the possibilities, but I am sure there are more.

>>I know about two professional teams working in simulation which would like
>>to use these device models in their simulator and 
>>could enrich the device library with new devices device interfaces, for
>>example with AGP and 3D graphics.
>>Bochs is already in middle of definition of new true pluginable devices
>>architecture. 

>This is welcome news.

Currently we are thinking about making user-plugin PCI devices and when
later user-plugin for any device. The C++ hierarchy for now might be:
bx_devmodel_c - bx_pcidev_c - bx_user_pcidev_c

The plans are to take one of the Bochs PCI devices and convert it into
user-level plugin which should not be compiled with Bochs and even not known
at compile time, but loaded at runtime if selected in runtime config file.
When any other device models could be added, even with closed-sources and
commercial licenses.

>The primary reason given for not making a plugin API for qemu hardware
>emulationis that qemu isn't stable enough - the code changes too often to
>support a stable API.

>Still, it might be easier to add support for plugins based on an external
>API, rather than trying to keep a qemu plugin API consistent.

Ok, I didn't knew that QEMU is so unstable. But at least there are several
trivial requirements from plugin architecture which you could mention here
and I am still not thought about it. I know, basically I am writing the
definition in my idle time and Volker supporting me. But it is not enough
...

Thanks,
Stanislav