From: Marcel Apfelbaum <marcel@redhat.com>
To: Markus Armbruster <armbru@redhat.com>
Cc: Eduardo Habkost <ehabkost@redhat.com>,
libvir-list@redhat.com, qemu-devel@nongnu.org,
Laine Stump <laine@redhat.com>,
"Michael S. Tsirkin" <mst@redhat.com>
Subject: Re: [Qemu-devel] [RFC 00/15] qmp: Report supported device types on 'query-machines'
Date: Thu, 24 Nov 2016 18:31:19 +0200 [thread overview]
Message-ID: <120cce2b-742c-bdaf-8b6d-3df3bc652a89@redhat.com> (raw)
In-Reply-To: <878ts8ans3.fsf@dusky.pond.sub.org>
On 11/24/2016 05:41 PM, Markus Armbruster wrote:
> Marcel Apfelbaum <marcel@redhat.com> writes:
>
>> On 11/24/2016 03:34 PM, Markus Armbruster wrote:
>>> Eduardo Habkost <ehabkost@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 :)
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".
Thanks,
Marcel
>> I do believe there are other examples, I'll try to think of more.
>>
>> Thanks,
>> Marcel
>>
>> [...]
next prev parent reply other threads:[~2016-11-24 16:31 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-22 1:11 [Qemu-devel] [RFC 00/15] qmp: Report supported device types on 'query-machines' Eduardo Habkost
2016-11-22 1:11 ` [Qemu-devel] [RFC 01/15] qemu.py: Make logging optional Eduardo Habkost
2016-11-22 1:12 ` [Qemu-devel] [RFC 02/15] qtest.py: Support QTEST_LOG environment variable Eduardo Habkost
2016-11-22 1:12 ` [Qemu-devel] [RFC 03/15] qtest.py: make logging optional Eduardo Habkost
2016-11-22 1:12 ` [Qemu-devel] [RFC 04/15] qtest.py: Make 'binary' parameter optional Eduardo Habkost
2016-11-22 1:12 ` [Qemu-devel] [RFC 05/15] tests: Add rules to non-gtester qtest test cases Eduardo Habkost
2016-11-22 13:34 ` Eduardo Habkost
2016-11-22 1:12 ` [Qemu-devel] [RFC 06/15] qdev: Add device_type field to BusClass Eduardo Habkost
2016-11-24 16:48 ` Cornelia Huck
2016-11-24 17:37 ` Eduardo Habkost
2016-11-22 1:12 ` [Qemu-devel] [RFC 07/15] machine: Add MachineClass::default_buses field Eduardo Habkost
2016-11-22 1:12 ` [Qemu-devel] [RFC 08/15] qmp: Add 'supported-device-types' field to 'query-machines' Eduardo Habkost
2016-11-22 1:12 ` [Qemu-devel] [RFC 09/15] pci: Introduce INTERFACE_PCIE_DEVICE interface name Eduardo Habkost
2016-11-22 1:12 ` [Qemu-devel] [RFC 10/15] pc: Initialize default bus lists Eduardo Habkost
2016-11-22 1:12 ` [Qemu-devel] [RFC 11/15] s390x: " Eduardo Habkost
2016-12-05 15:24 ` David Hildenbrand
2016-12-05 16:03 ` Cornelia Huck
2016-12-05 16:38 ` Eduardo Habkost
2016-11-22 1:12 ` [Qemu-devel] [RFC 12/15] arm: " Eduardo Habkost
2016-11-22 1:12 ` [Qemu-devel] [RFC 13/15] mips: " Eduardo Habkost
2016-11-22 1:12 ` [Qemu-devel] [RFC 14/15] ppc: " Eduardo Habkost
2016-11-23 3:42 ` Alexey Kardashevskiy
2016-11-22 1:12 ` [Qemu-devel] [RFC 15/15] qdev: Add device_class_set_bus_type() function Eduardo Habkost
2016-11-22 1:34 ` [Qemu-devel] [RFC 00/15] qmp: Report supported device types on 'query-machines' no-reply
2016-11-22 1:36 ` no-reply
2016-11-22 8:18 ` David Hildenbrand
2016-11-22 13:09 ` Eduardo Habkost
2016-11-22 22:34 ` Eduardo Habkost
2016-11-23 17:10 ` [Qemu-devel] -nodefaults and available buses (was Re: [RFC 00/15] qmp: Report supported device types on 'query-machines') Eduardo Habkost
2016-11-24 1:51 ` David Gibson
2016-11-24 16:30 ` Cornelia Huck
2016-11-24 17:42 ` Eduardo Habkost
2016-11-24 13:39 ` Markus Armbruster
2016-11-23 16:43 ` [Qemu-devel] [RFC 00/15] qmp: Report supported device types on 'query-machines' Marcel Apfelbaum
2016-11-23 17:35 ` Eduardo Habkost
2016-11-24 9:34 ` Marcel Apfelbaum
2016-11-24 13:34 ` Markus Armbruster
2016-11-24 14:12 ` Eduardo Habkost
2016-11-24 14:55 ` Markus Armbruster
2016-11-24 14:22 ` Marcel Apfelbaum
2016-11-24 15:41 ` Markus Armbruster
2016-11-24 16:31 ` Marcel Apfelbaum [this message]
2016-11-25 8:03 ` Markus Armbruster
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=120cce2b-742c-bdaf-8b6d-3df3bc652a89@redhat.com \
--to=marcel@redhat.com \
--cc=armbru@redhat.com \
--cc=ehabkost@redhat.com \
--cc=laine@redhat.com \
--cc=libvir-list@redhat.com \
--cc=mst@redhat.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).