[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH RFC 0/3] qdev: order devices by priority before

From: Marcel Apfelbaum
Subject: Re: [Qemu-devel] [PATCH RFC 0/3] qdev: order devices by priority before creating them
Date: Sun, 15 May 2016 14:23:08 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0

On 05/11/2016 10:51 AM, Markus Armbruster wrote:
Marcel Apfelbaum <address@hidden> writes:

On 05/10/2016 11:28 AM, Markus Armbruster wrote:
Marcel Apfelbaum <address@hidden> 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 
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.

Hi Markus,

In my opinion, there are two sane ways to do command line options.

One is to make order relevant, and process them strictly left to right.

The other is to do the right thing regardless of order.  This requires
some kind of dependency tracking if there are any.

I personally like this way more, however I confess I do not aim to solve this
globally, my scope is making more user friendly the stuff I work with.

QEMU, of course, does neither: we process them in left to right unless
we don't, and users juggle them until the errors go away.

And this is why I thought, we have some case the order is important,
some cases it is not. Adding one more case to "order not important" set
looks like a little win.

I'm afraid this patch adds to "unless we don't" without covering much
ground towards "do the right thing regardless of order".  Static
priorities are a rather crude approximation of dependencies.  Is it the
best we can do for user now?

As stated above, I am perfectly aware the static priorities angle does not
solve all the problems, but it helps and may be a good step in the right 

The static priorities can make sense, the host bridge needs to be created before
the other pci bridges, which should also be created before the devices itself.

IOMMU can also leverage static priorities, it needs to be created after the 
host bridge,
but before anything else.

I am sure we can think of other cases those will help too. To answer your 
no, is not the best we can do, but maybe it worth it.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]