[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Interest in hardware plugin functionality

From: Andre Pech
Subject: Re: [Qemu-devel] Interest in hardware plugin functionality
Date: Tue, 10 Jan 2006 16:14:10 -0800

I've only implemented this functionality for the pc system emulator for PCI hardware plugin devices, since that's all I need it for at the moment. There's obviously more to be done to implement this in a nice way across all architectures for all hardware types, which I'm very interested in doing if a maintainer is interested in helping get this into the mainline.

The patch to implement this subset of the functionality is actually really small, but is more of a hack for what I need as opposed to a polished solution, so I think it's probably more useful if I just explain what it does. The patch does the following:
- Installs the qemu header files to a sensible place, like /usr/include/qemu, so that hardware plugin files can be compiled against them
- Exposes the PCI interface by adding a function pci_get_bus which returns the pci bus struct
- Adds a call to dlopen towards the end of pc_init1 which dynamically opens hw plugin files which were passed in on the command line.

That's all that was necessary to get things to work. The hardware plugin files are written in cpp, leveraging static constructors to register the PCI device with the PCI bus when the files are dlopened.

In the general case, I envision having to do something similar for all hardware types - expose a sensible interface for plugin hardware to be able to access the appropriate data structures, and structure things in a way that the changes can be as architecture-independent as possible. I hadn't started down the path of turning all devices into plugins, although this could certainly be done.

I'd be interested to hear more on what sort of issues you ran into in trying to implement this yourself, as I'm not exactly sure what strange dependencies you're referring to.


On 1/10/06, Anthony Liguori <address@hidden> wrote:
Can you post the patch somewhere?

I've looked into this myself in the past and some devices are more
easily abstracted than others because of some strange dependencies.  I'm
curious to see what devices you've turned into plugins and how you've
solved these problems (I assume that you would make all the current
devices plugins and not just allow for custom device plugins).


Anthony Liguori

Andre Pech wrote:

> Hi,
> I have been using qemu to simulate various types of custom hardware
> for testing purposes. Rather than having to recompile qemu every time
> I change a hardware simulation, I instead patched qemu to support
> dynamically loading hardware plugin files at run time. The basic idea
> is that you can specify .so files to load on the command line when you
> boot qemu. These files will be dlopened by qemu at run time, and will
> register themselves as hardware to the appropriate hardware controller
> (ie a PCI device hardware plugin registers itself with the PCI bus).
> I was hoping to get people's reactions to / interest in this sort of
> feature. Currently I have patched qemu to work for my own purposes,
> which required having to hack around some issues I ran into. These
> hacks do not require major changes in how qemu works, but are rather
> structural changes. For example, the qemu header file naming structure
> does not lend itself to being installed to somewhere like
> /usr/include/qemu, and would need some changing. This includes
> changing 'include " config.h"' to include 'include "qemu/config.h"' due
> to the common use of config.h by other packages, as well as working
> through the issues of how to structure things for building qemu
> hardware plugins against multiple architecture types.
> I am more than willing to put all the effort into turning this into a
> nice patch, if there is a maintainer interested in helping me shepherd
> this into the mainline.
> Thanks,
> Andre Pech
>Qemu-devel mailing list
> address@hidden

Qemu-devel mailing list

reply via email to

[Prev in Thread] Current Thread [Next in Thread]