[Ksummit-2012-discuss] PCI breakout session

Benjamin Herrenschmidt benh at kernel.crashing.org
Mon Jun 18 23:02:16 UTC 2012

On Mon, 2012-06-18 at 14:35 -0700, H. Peter Anvin wrote:

> It makes sense to use it for emulated PCI on x86, because in the virtual
> environment I/O space references effectively become native hypercalls --
> they are *very* efficient.  Just like the S390 people like to use their
> channel interfaces for the same purpose, using I/O space makes a ton of
> sense on x86.

Except that in the grand scheme of things, any IO or MMIO is slow and
the right thing to do is to design your interface protocol to limit it's
use to cases where the performance difference doesn't matter.

In the case of virtio, quite a bit can be done to limit the need to
"ring" the mailbox, for example using NAPI-like timers on the qemu side
etc... so that the IO/MMIO is only used when not in a performance
critical situation.

> And no, it's not just "a hackish workaround".  It's a useful repurposing
> of a legacy interface.

Of a platform specific and horribly limited legacy interface (let's not
even getting into the hell of exposing it to userspace) etc.... nah,
really, kill it :-)

In any case, I don't think the original idea of being able to
dynamically move around BARs of exising active devices to make room for
new hotplugged ones is going to fly, especially if the only
justification is that :) I'd say in that case, pay the price for MMIO in
order to keep your sanity.

Reducing the granularity of IOs can help a bit more, by allowing to
create domains with a tiny IO space, it means you can simply add
emulated host bridges (domains) for new virtio devices (or block of 7
virtio devices) and not have to worry about fragmentation if those
domains are created with a fixed size IO window, conveniently chosen to
just fit the needs of virtio.

Still, the proposed solution so far isn't worth not switching to MMIO.


More information about the Ksummit-2012-discuss mailing list