Re: [Qemu-devel] Re: [PATCH] Patches from PyQemu project

[Anthony Liguori]

On Tue, 2007-09-04 at 14:57 -0500, Brian Johnson wrote:
> Anthony Liguori wrote:
> > With things like KVM making it relatively simple to do CPU emulation, if
> > QEMU's device emulation was available as a library (even a GPL library),
> > it would be pretty easy to do interesting things without forking QEMU
> > which is what everyone seems to be doing these days.
> 
> Yes -- it would be valuable to have QEMU's devices available as a 
> separate library(ies), with a simple, well-defined API.  Some of us use 
> other CPU emulators (yes, yes, I know we should emulate all 
> architectures under qemu, but that's not always easy :) and would love 
> to use qemu's device emulations.
> 
> > My initial thought is to make the libraries at the individual device
> > level.
> 
> It would be good to have a general mechanism for bus providers, 

Well, I'm not much for over generalizing.  My current approach would be
incremental, start by focusing on a target like i386, and make the
devices into libraries.  The libraries should not be independently
loadable by another process.

I think two types of abstractions will become apparently.  The first is
how the devices communicate with the VM and covers things like
register_ioport_{read,write}, generating interrupts, etc.  QEMU already
has some nice abstractions here so this is pretty straight forward.  My
thinking is that we'll be able to have one set of APIs to cover this.

The second type of abstraction is the functionality the individual
devices provide.  This is covered by things like the BlockDriverState
interface.  Again, QEMU does a pretty good job at abstracting this
today.

Regards,

Anthony Liguori

> interrupts, APICs, chipsets, etc. as well, so we could emulate fancier 
> architectures than a simple PC (or simple Sparc/MIPS/ARM/etc. box.)  For 
> instance, I'd like to emulate multiple PCIe host bridges, each with an 
> APIC and multiple cards, which might contain PCI-to-PCI bridges.  And 
> I'd like to emulate NUMA systems with many memory controllers and a 
> complex memory map, with multiple sets of chipset registers.  I don't 
> expect qemu to do this off the shelf, but I'd like to avoid hardcoding 
> PC assumptions into the device libraries, so I can code the fancy 
> machines myself and use the I/O as-is.
> 
> Any more thoughts on how to structure the libraries?
> 
> Brian J. Johnson
> 
>