[Top][All Lists]

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

Re: Configuration vs. compat hints [was Re: [Qemu-devel] [PATCHv3 03/13]

From: Avi Kivity
Subject: Re: Configuration vs. compat hints [was Re: [Qemu-devel] [PATCHv3 03/13] qemu: add routines to manage PCI capabilities]
Date: Mon, 15 Jun 2009 16:42:56 +0300
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1b3pre) Gecko/20090513 Fedora/3.0-2.3.beta2.fc11 Lightning/1.0pre Thunderbird/3.0b2

On 06/15/2009 04:23 PM, Anthony Liguori wrote:
Avi Kivity wrote:
On 06/15/2009 03:52 PM, Anthony Liguori wrote:
Avi Kivity wrote:
On 06/15/2009 03:41 PM, Michael S. Tsirkin wrote:
We should just tell the user which slots are open.
This might be tricky if the config is passed in with the command line

qemu -show-available-pci-slots

Why does the user care?

Let QEMU allocate the PCI slot, then query it to see what slot it assigned and remember that.

It's a roundabout way of doing things.

Having libvirt do PCI slot allocation scares me. It assumes we can return a whitelist of available slots, and then let libvirt just randomly assign things. There's knowledge though in slot assignment that's board-specific. For instance, depending on how many LNK lines you have, you may want to put things in slots in such a way to optimize interrupt balancing or something like that.

How would qemu know which slots to optimize for?

In practice, I don't see that as a real problem. We should (a) add an ioapic and four more pci links (b) recommend that slots be assigned in ascending order, and everything works.

I don't see your concern about libvirt allocating slots. If a human can plug a card into a slot, so can libvirt. Doing an interactive back-and-forth (equivalent to plugging a card while blindfolded, then looking to see which slot we hit) is certainly more difficult.

Some platforms have quirks about expecting a particular slot to have a particular device. It's still an optimal device but it has to be in that slot. You can't really express that via an available slot list.

I'll be surprised if we ever measure different dma speeds on different slots in the qemu virtual pci bus. If we do, we'll find a way to express them:

  $ qemu -print-pci
  slot 0:01: available 33MHz
  slot 0:02: available 33MHz
  slot 0:03: available 66MHz

I feel a little silly typing this.

error compiling committee.c: too many arguments to function

reply via email to

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