Re: [libvirt] [Qemu-devel] [RFC 00/15] qmp: Report supported device types on 'query-machines'
Marcel Apfelbaum <marcel(a)redhat.com> writes:
On 11/24/2016 05:41 PM, Markus Armbruster wrote:
> Marcel Apfelbaum <marcel(a)redhat.com> writes:
>
>> On 11/24/2016 03:34 PM, Markus Armbruster wrote:
>>> Eduardo Habkost <ehabkost(a)redhat.com> 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.
[...]