[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC] New device API
From: |
Zachary Amsden |
Subject: |
Re: [Qemu-devel] [RFC] New device API |
Date: |
Fri, 08 May 2009 15:21:41 -1000 |
User-agent: |
Thunderbird 2.0.0.19 (X11/20090317) |
Anthony Liguori wrote:
> This is where the current API fails miserably. You cannot have a PCI
> device calling the CPU MMIO registration functions directly because
> there is no sane way to deal with endianness conversion. Instead, the
> IO region registration has to go through the PCI bus.
Right, being an x86 bigot for years has isolated me from these horrors.
> As Paul said, I don't think it's worth trying to make the same devices
> work on top of multiple busses. I think it's asking for trouble.
> Instead, for devices that can connect to multiple busses (like ne2k),
> they can have separate register_pci_device() and register_isa_device()
> calls and then just internally abstract their chipset functions. Then
> it just requires a small big of ISA and PCI glue code to support both
> device types.
Hmm, not sure how I made it sound like devices should work on unnatural
busses. I simply meant there are some devices that can have ISA and PCI
implementation, and when that is possible, it makes sense to have that
as a static configuration choice.
>> 1) Static per-device configuration choices, such as feature enable /
>> disable, framebuffer size, PCI vs. ISA bus representation. These are
>> fixed choices over the lifetime on the VM. In the above, they would be
>> represented as DeviceProperty configuration strings.
>>
>
> Yes. I think this is important too. But when we introduce this, we
> need to make sure the devices pre-register what strings they support and
> provide human consumable descriptions of what those knobs do.
> Basically, we should be able to auto extract a hardware documentation
> file from the device that describes in detail all of the supported knobs.
Yes, I keep falling back to some sort of DEVICETYPE{NNN}.PARAM = "VALUE"
scheme, sort of like .vmx config files. However, they failed horribly
in not complaining about unparsed parameters; silently ignoring config
data is wrong, and pre-registration should be required, as it stops both
silent typo failures and collision.
>> 2) Dynamic per-device data. Things such as PCI bus numbers, IRQs or
>> MMIO addresses. These are dynamic and change, but have fixed, defined
>> layouts. They may have to be stored in an intermediate representation
>> (a configuration file or wire protocol) for suspend / resume or
>> migration. In the above, it would be possible to write handlers for
>> suspend / resume that operate on a generic device representation,
>> knowing to call specific handlers for PCI, etc. Would certainly
>> mitigate a lot of bug potential in the dangerous intersection of ad-hoc
>> device growth and complex migration / suspend code.
>>
>
> For the most part, I think the device should be unaware of these
> things. It never needs to see it's devfn. It should preregister what
> lnks it supports and whether it supports MSI, but it should never know
> what IRQs that actually gets routed to.
Ideally, but I think in practice the line will blur.. unless you have a
completely ideal bus abstraction, there will still be the need to fill
in reads from configuration space and associated device specific side
effects.
> We really have three types of things and it's not entirely clear to me how to
> name them. What we're currently calling devices are emulated hardware.
> Additionally, we have host drivers that provide backend functionality. This
> would include things like SDL, VNC, the tap VLAN driver. We also need
> something like a host device. This would be the front-end functionality that
> connects to the host driver backend.
> A device registers its creation function in it's module_init(). This
> creation function will then register the fact that it's a PCI device and will
> basic information about itself in that registration. A PCI device can be
> instantiated via a device configuration file and when that happens, the
> device will create a host device for whatever functionality it supports. For
> a NIC, this would be a NetworkHostDevice or something like that. This
> NetworkHostDevice would have some link to the device itself (via an id,
> handle, whatever). A user can then create a NetworkHostDriver and attach the
> NetworkHostDevice to that driver and you then have a functional emulated NIC.
This sounds pretty much ideal, I would say, but the details are really
in "will create a host device for whatever functionality". Is there a
plan to lay out frontend APIs(1) for the various types of devices
(sound, pointer, net, SCSI) so we can have modularized host driver backends?
(1) With APIs being flexible, I don't mean a fixed link-type module, I
mean well-modularized code that makes the 5 architectures x 50 devices x
4 bus models x 3 host implementations less of a problem than it
currently is.
Zach
- Re: [Qemu-devel] [RFC] New device API, (continued)
- Re: [Qemu-devel] [RFC] New device API, Anthony Liguori, 2009/05/09
- Re: [Qemu-devel] [RFC] New device API, malc, 2009/05/09
- Re: [Qemu-devel] [RFC] New device API, Anthony Liguori, 2009/05/09
- Re: [Qemu-devel] [RFC] New device API, Andreas Färber, 2009/05/10
- Re: [Qemu-devel] [RFC] New device API, malc, 2009/05/10
- Re: [Qemu-devel] [RFC] New device API, Anthony Liguori, 2009/05/09
Re: [Qemu-devel] [RFC] New device API, Edgar E. Iglesias, 2009/05/05
Re: [Qemu-devel] [RFC] New device API, Zachary Amsden, 2009/05/07
Re: [Qemu-devel] [RFC] New device API, Marcelo Tosatti, 2009/05/08