qemu-devel
[Top][All Lists]
Advanced

[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




reply via email to

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