[Qemu-devel] Interest in hardware plugin functionality

[Qemu-devel] Interest in hardware plugin functionality

[Andre Pech]

[-- Attachment #1: Type: text/plain, Size: 1498 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 1614 bytes --]

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

[Michael Renzmann]

Hi.

On Mon, 2006-01-09 at 17:38 -0800, Andre Pech wrote:
> I change a hardware simulation, I instead patched qemu to support
> dynamically loading hardware plugin files at run time.
> [...]
> 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.

That would be a very nice feature to see in qemu.

Bye, Mike

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

[Lennert Buytenhek]

On Mon, Jan 09, 2006 at 05:38:58PM -0800, Andre Pech wrote:

> 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 think the biggest problem would be that a lot of operating systems
don't support hotplug PCI.


--L

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

[Andre Pech]

[-- Attachment #1: Type: text/plain, Size: 1619 bytes --]

This functionality is not strictly for hotplugging. Maybe my use of the term
hardware plugin was misleading. The patch adds the ability to pass a .so
file compiled against qemu's header files to qemu on the command line. This
.so file is dlopened and registers itself as hardware appropriately, all
before the operating system actually boots.
I could envision adding the ability to have a qemu monitor command to
similarly open such a file in order to hotplug a hardware device, but
obviously this would be limited to the hardware types that the operating
system supports hotplugging for.
Andre

On 1/10/06, Lennert Buytenhek <buytenh@wantstofly.org> wrote:
>
> On Mon, Jan 09, 2006 at 05:38:58PM -0800, Andre Pech wrote:
>
> > 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 think the biggest problem would be that a lot of operating systems
> don't support hotplug PCI.
>
>
> --L
>
>
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
>

[-- Attachment #2: Type: text/html, Size: 2046 bytes --]

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

[Jan Marten Simons]

Lennert Buytenhek wrote:

>I think the biggest problem would be that a lot of operating systems
>don't support hotplug PCI.
>
>  
>
I think Michael's idea was rather to select the hardware to use during 
qemu startup rather then to change it while the system is up and 
runnning. Therefore hotplugging would not be an issue.

To give some feedback as well, I like the idea of dynamic hardware as 
qemu can become even more versatile than it is right now.

With regards,
Jan

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

[Anthony Liguori]

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).

Regards,

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
>Qemu-devel@nongnu.org
>http://lists.nongnu.org/mailman/listinfo/qemu-devel
>  
>

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

[Andre Pech]

[-- Attachment #1: Type: text/plain, Size: 4371 bytes --]

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.

Thanks
Andre

On 1/10/06, Anthony Liguori <aliguori@us.ibm.com> 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).
>
> Regards,
>
> 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
> >Qemu-devel@nongnu.org
> >http://lists.nongnu.org/mailman/listinfo/qemu-devel
> >
> >
>
>
>
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
>

[-- Attachment #2: Type: text/html, Size: 5091 bytes --]