Marcel Apfelbaum <marcel@xxxxxxxxxx> writes: > On 11/24/2016 05:41 PM, Markus Armbruster wrote: >> Marcel Apfelbaum <marcel@xxxxxxxxxx> writes: >> >>> On 11/24/2016 03:34 PM, Markus Armbruster wrote: >>>> Eduardo Habkost <ehabkost@xxxxxxxxxx> writes: >>>> >>>>> 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 >>>>> >>> >>> [...] >>> >>>> Our decision to have hybrid PCI/PCIe devices and buses breeds >>>> considerable complexity. I wish we had avoided them, but I believe it's >>>> too late to change now. >>>> >>>>>> This still does not solve the problem that some devices makes >>>>>> sense only on a specific arch. >>>> >>> >>> Hi Markus, >>> >>>> Examples? >>>> >>> >>> One quick example would be that we don't want to see >>> Intel's IOH 3420 PCIe Root Port in an ARM machine, >>> or a pxb on a Q35 machine (in this case we want pxb-pcie) >> >> Such a device would be weird. But would it be wrong? > > Define wrong :) I do: > Wrong enough for >> QEMU to reject it? > > QEMU accepts them and they even function correctly as far as I know. > >> Unless QEMU rejects it, there's no reason not to >> list it as pluggable. >> > > This is the gray area I can't argue. I do think that Eduardo's > work may present an opportunity to change QEMU's mantra: > "everything goes as long as it works" to "here is what this configuration supports". I guess you argument is that in reality, the devices you quoted are always part of specific chipsets, so "we dont want to see" them elsewhere. If I understand you correctly, there are two cases you don't want to see elsewhere: (1) The real PCI device only ever exists as function of another device. (2) The real PCI device only ever exists on certain boards. We accept these devices elsewhere due to the way we model them. Because we conflate PCI functions and devices, we can't model (1) correctly. I think the appropriate solution would be modelling functions separate from devices, then provide the functions in question only as part of the devices where you want to see them, by making them not user-pluggable. Because we model a board's chipset as a set of independent devices instead of a composite device, we can't model (2) correctly. I think the appropriate solution to (2) is modelling composite chipset devices, then provide the devices in question only as part of the chipset devices where you want to see them, by making them not user-pluggable. Adding a bunch of special types to QOM so that introspection claims "you can't plug that thing" (even though you actually could) would be an inappropriate solution. As long as you can plug them, QEMU should be honest about it, even if we think you shouldn't plug them. "Can't" is mechanism. "Shouldn't" is policy. Baking policy into introspection by making it lie doesn't strike me as a good idea. [...] -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
