From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1M2mjC-0007Nw-Ed for qemu-devel@nongnu.org; Sat, 09 May 2009 09:36:34 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1M2mj5-0007Nf-NC for qemu-devel@nongnu.org; Sat, 09 May 2009 09:36:33 -0400 Received: from [199.232.76.173] (port=54907 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1M2mj5-0007Nc-L0 for qemu-devel@nongnu.org; Sat, 09 May 2009 09:36:27 -0400 Received: from an-out-0708.google.com ([209.85.132.245]:34786) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1M2mj5-0004lx-9W for qemu-devel@nongnu.org; Sat, 09 May 2009 09:36:27 -0400 Received: by an-out-0708.google.com with SMTP id d11so1094909and.37 for ; Sat, 09 May 2009 06:36:26 -0700 (PDT) Message-ID: <4A0586D7.5010008@codemonkey.ws> Date: Sat, 09 May 2009 08:36:23 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] [RFC] New device API References: <200905051231.09759.paul@codesourcery.com> <4A0390DC.2010908@redhat.com> <4A0437E0.7080800@codemonkey.ws> <4A04DAA5.4040505@redhat.com> In-Reply-To: <4A04DAA5.4040505@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Zachary Amsden Cc: Paul Brook , qemu-devel@nongnu.org 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