From: Marcel Apfelbaum <marcel@redhat.com>
To: Markus Armbruster <armbru@redhat.com>
Cc: qemu-devel@nongnu.org, pbonzini@redhat.com, mst@redhat.com
Subject: Re: [Qemu-devel] [PATCH RFC 0/3] qdev: order devices by priority before creating them
Date: Tue, 10 May 2016 14:05:20 +0300 [thread overview]
Message-ID: <5731C070.2010709@redhat.com> (raw)
In-Reply-To: <8737pqfhac.fsf@dusky.pond.sub.org>
On 05/10/2016 11:28 AM, Markus Armbruster wrote:
> Marcel Apfelbaum <marcel@redhat.com> writes:
>
>> This series aims to allow more devices to be used with '-device'
>> by sorting the devices based on a predefined creation order flag
>> before creating them.
>>
>> Devices like IOMMU need to be created before others, so they can leverage
>> the DeviceCreationPriority flag introduced by the first patch to DeviceClass.
>>
>> The second patch sorts the devices by their DeviceCreationPriority
>> before creating them.
>>
>> Finally, the last patch demonstrates how it can be used to ensure
>> the creation of host-bridges before the pci-bridges and pci-bridges before
>> the others.
>>
>> I preferred to combine all the priorities into a single enum
>> to better manage the creation order.
>>
>> This is an RFC because I only wanted to know if it seems like the right way to go.
>> Comments are appreciated,
>
Hi Markus,
Thanks for looking into this.
> Can you explain why requiring the user to specify -device in a sane
> order isn't good enough?
>
Point taken, the truth is I didn't like the 'order' restriction in the first place.
If the device creation depends on the id of some other devices (e.g we need the bus id to plug a device into it),
for IOMMU devices it gets a little tricky. You can add the IOMMU device before other PCI devices but it will not
work (because some internal implementation). This is why we added using -machine pc,iommu=on.
I suppose we have other examples as well. This is not user friendly IMO.
To solve the specific IOMMU problem we can check that there are no PCI devices created yet,
but I am not sure is a better approach and is strictly related to this device.
The goal is to be able to add more devices with -device and I thought this kind of creation in steps may help.
Thanks,
Marcel
next prev parent reply other threads:[~2016-05-10 11:05 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-09 17:47 [Qemu-devel] [PATCH RFC 0/3] qdev: order devices by priority before creating them Marcel Apfelbaum
2016-05-09 17:47 ` [Qemu-devel] [PATCH RFC 1/3] qdev: add device creation priority flag Marcel Apfelbaum
2016-05-09 17:47 ` [Qemu-devel] [PATCH RFC 2/3] vl.c: create devices by their " Marcel Apfelbaum
2016-05-09 17:47 ` [Qemu-devel] [PATCH RFC 3/3] hw/pci-bridge: add the corresponding " Marcel Apfelbaum
2016-05-10 8:28 ` [Qemu-devel] [PATCH RFC 0/3] qdev: order devices by priority before creating them Markus Armbruster
2016-05-10 11:05 ` Marcel Apfelbaum [this message]
2016-05-11 7:51 ` Markus Armbruster
2016-05-15 11:23 ` Marcel Apfelbaum
2016-05-10 15:36 ` Michael S. Tsirkin
2016-05-10 17:13 ` Paolo Bonzini
2016-05-11 13:55 ` Michael S. Tsirkin
2016-05-11 15:09 ` Paolo Bonzini
2016-05-11 15:19 ` Michael S. Tsirkin
2016-05-11 15:25 ` Paolo Bonzini
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=5731C070.2010709@redhat.com \
--to=marcel@redhat.com \
--cc=armbru@redhat.com \
--cc=mst@redhat.com \
--cc=pbonzini@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.