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

[Anthony Liguori <anthony@codemonkey.ws>]

Zachary Amsden wrote:
> Anthony Liguori wrote:
>
>   
>> 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.
>   

Exactly.

  

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

Perhaps, but I want to get away from any assumption that we're saying 
PCI device 00:01:04.4 is connected to IRQ 10 in a configuration file.  
How a PCI LNK gets routed to an actual IRQ depends on a lot of things 
and to support something like this, you'd need rather sophisticated 
autogeneration of ACPI, dynamic allocation of number of LNKs, etc.  PCI 
devices internally determine how many LNKs they use.  In the config 
file, we should merely be saying create PCI device 00:01:04.4 with 
vendor ID X and device ID Y.  Then we should be able to add device 
specific configuration bits (for virtio-net, for instance, we may say 
how large the queue size is).

Details of interrupt routing, BAR location, etc. are out of scope IMHO.

>> 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?
>   

Yes, and I don't think we're that far away from that today.  I think the 
block driver API is shaping up nicely.  We've almost got an ideal API.  
It'll be a bit more work to remove all of the legacy aspects of the API.

The networking API needs a revamp but I think there's general consensus 
on how to do that.  DisplayState is getting good too but it needs input 
support too.  Also, we have to improve how the TextConsole and 
multiplexing work today to be implemented as proper DisplayState 
layering instead of the hackery that exists today.

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

Yes, I think that's what we're aiming for here.

Regards,

Anthony Liguori