From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:44652) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c9qQv-0002cj-IC for qemu-devel@nongnu.org; Thu, 24 Nov 2016 04:35:13 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c9qQr-0008Ds-IX for qemu-devel@nongnu.org; Thu, 24 Nov 2016 04:35:09 -0500 Received: from mx1.redhat.com ([209.132.183.28]:35044) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1c9qQr-0008Cf-9B for qemu-devel@nongnu.org; Thu, 24 Nov 2016 04:35:05 -0500 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id B6B08C05B1EF for ; Thu, 24 Nov 2016 09:35:02 +0000 (UTC) References: <1479777133-23567-1-git-send-email-ehabkost@redhat.com> <47c2fb2a-7785-b7b9-bf7d-5743cbc5f4be@redhat.com> <20161123173515.GB27297@thinpad.lan.raisama.net> From: Marcel Apfelbaum Message-ID: <187c7468-250c-116e-f0dd-8c207134269e@redhat.com> Date: Thu, 24 Nov 2016 11:34:59 +0200 MIME-Version: 1.0 In-Reply-To: <20161123173515.GB27297@thinpad.lan.raisama.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC 00/15] qmp: Report supported device types on 'query-machines' List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eduardo Habkost Cc: qemu-devel@nongnu.org, Markus Armbruster , "Michael S. Tsirkin" , libvir-list@redhat.com, Laine Stump On 11/23/2016 07:35 PM, Eduardo Habkost wrote: > On Wed, Nov 23, 2016 at 06:43:16PM +0200, Marcel Apfelbaum wrote: >> On 11/22/2016 03:11 AM, Eduardo Habkost wrote: >>> The Problem >>> =========== >>> >>> Currently management software has no way to find out which device >>> types can be plugged in a machine, unless the machine is already >>> initialized. >>> >> >> Hi Eduardo, >> Thank you for this interesting series. I think this is a problem >> worth addressing. >> [...] >>> >>> PCI vs PCIe >>> ----------- >>> >>> Machines with PCIe buses will report INTERFACE_PCIE_DEVICE on >>> supported-device-types. >>> >>> Machines with legacy PCI buses will report TYPE_PCI_DEVICE on >>> supported-device-types. >>> >>> The problem with the current approach is that PCIe devices are >>> TYPE_PCI_DEVICE subclasses. The allows PCI device classes to >>> indicate they are PCIe-capable, but there's no obvious way to >>> indicate that a device is PCIe-only. This needs to be addressed >>> in a future version of this series. >>> >>> Suggestions are welcome. >> >> >> As we talked offline, I personally like an interface IPCIType >> with a field having 3 possible values {pci/pcie/hybrid} >> >> To understand how hybrid works we need some rules, like >> "pci on pci bus/pcie on pcie bus" >> "pcie on a non-root pcie bus/pcie otherwise >> >> I don't think we'll have a lot of rules, simple boolean fields >> for the interface should be enough. > > What you propose makes sense, the only difference is that the > boolean fields would be just interface names that can be used as > the "implements" argument on qom-list-types. > > e.g.: > > * Hybrid PCI device-types would implement both "legacy-pci-device" and > "pcie-device" interfaces. > * PCIe-only device-types would implement only the "pcie-device" > interface. > * Legacy-PCI-only device-types would implement only the > "legacy-pci-device" interface. > > Then, the bus instances would have a 'accepted-device-types' > field: > > * A legacy PCI bus would accept only "legacy-pci-device" devices. > * A PCIe-only bus would accept only "pcie-device" devices. > * A PCIe bus that accepts legacy PCI devices (the root bus?) > would accept both "legacy-pci-device" and "pcie-device" > devices. > > Then, query-machines would return the list of bus instances that > machine init creates, containing the bus ID, bus type, and > accepted-device-types. > > Does that make sense? > Sure, the described approach solves the problem. >> >> This still does not solve the problem that some devices makes >> sense only on a specific arch. > > Right now, we can simply compile out arch-specific devices that > can never be plugged in a QEMU binary. But if we still want them > compiled in for some reason, we can categorize them on a > different type/interface name, and the corresponding machine-type > would tell management that their buses accept only the > arch-specific type/interface name. > Adding an Interface for each arch could work, yes. >> >>> >>> Incomplete bus lists on some machines >>> ------------------------------------- >>> >>> With this series, not all machines classes are changed to add the >>> full list of device types on the 'supported-device-types'. To >>> allow the code to be updated gradually, qmp-machine-info.py has a >>> STRICT_ARCHES variable, that will make the test code require a >>> complete device type list only on some architectures. >>> >>> Out of scope: Configurable buses >>> -------------------------------- >>> >>> There's no way to map machine options like "usb=on|off" to >>> device-types or buses. I plan to propose a new interface that >>> allows machine options to be mapped to buses/device-types later. >>> >>> Out of scope: Deciding where to plug devices >>> -------------------------------------------- >>> >>> Once management software discovers which devices can be plugged >>> to a machine, it still has to discover or define where devices >>> can/should/will be plugged. This is out of the scope of this >>> series. >>> >> >> That's a pitty :( >> I was hoping this series will solve this issue. But if it prepares >> the grounds for it is also a good step . > > The bus ID will be in the scope of v2. > Thanks, Marcel >> >> >> >> Thanks, >> Marcel >> [...]