Re: [Qemu-devel] [RFC] New device API

[Zachary Amsden <zamsden@redhat.com>]

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