Re: [Qemu-discuss] Hardware component emulation

[Federico Vaga]

On Sunday, 17 July 2016 18:56:25 CEST Peter Maydell wrote:
> On 16 July 2016 at 23:38, Federico Vaga <address@hidden> wrote:
> > I'm super new to qemu and I would like to understand more about the
> > hardware components emulation. I surfed for some hours on the internet
> > but I cannot find much help.
> > By looking at the source code in the 'hw' directory of the qemu git
> > repository I can vaguely guess how it works but I would like to see some
> > explainations: a manual.
> 
> Sorry, we don't really have much internals documentation. The
> source code is the most accurate reference. 

It's a pity :(
If we end up to use QEMU maybe I will write a couple of lines :)

> Most devices are
> fairly straightforward: they implement one (occasionally more)
> MemoryRegion, which corresponds to a bank of registers that
> will be mapped into the emulated system's address maps. And
> they provide also some interrupt (irq) lines and perhaps some
> input or output GPIO lines.

What device would you suggest to look at?

> > Then a question. Are these hardware modules dynamically loadable by qemu
> > as
> > external modules? I mean, can I compile a hardware component out of the
> > qemu tree and load it in the qemu I get from the distro? In other words:
> > I would like to have something like Linux kernel modules (.ko) that I
> > attach to qemu when I launch it.
> 
> No, we don't have devices as modules. We do have some module
> support, but this is intended primarily to allow distributions
> to split out parts of QEMU which have dependencies on
> external shared libraries, so that users who don't need
> (for instance) the glusterfs support can just not install
> the optional QEMU modules rather than having to pull in
> a lot of dependent packages for a feature they're not using.
> Our modules code (deliberately) does not support loading a
> module from one compile into a QEMU built with another
> compile -- there is no stable API/ABI within QEMU.  So
> loading a separate module into a distro-supplied QEMU will
> not work.

I see.
Does it make sense to have it at some point in the future?

-- 
Federico Vaga