Linux Virtualization - Jun 2013 - [PATCH RFC] virtio-pci: new config layout: using memory BAR

On Wed, 2013-06-05 at 16:53 -0500, Anthony Liguori wrote:
> Existing PowerPC remaps PIO to MMAP so it works fine today.
> 
> Future platforms may not do this but future platforms can use a
> different device.  They certainly won't be able to use the existing
> drivers anyway.
> 
> Ben, am I wrong here?
Well, we do remap PIO, though it's ugly and annoying so we'd rather
avoid it alltogether :-)

Our latest HW PHBs don't support PIO at all, so while we can still
support it in the virtual ones in the guest for ever, it's becoming
pretty clear that PIO is on the way out ...
> >> > 	- we won't be able to drop IO BAR from virtio
> >> 
> >> An IO BAR is useless if it means we can't have more than 12
devices.
> >
> >
> > It's not useless. A smart BIOS can enable devices one by one as
> > it tries to boot from them.
> 
> A smart BIOS can also use MMIO to program virtio.
Indeed :-)

I see no reason why not providing both access path though. Have the PIO
BAR there for compatibility/legacy/BIOS/x86 purposes and *also* have the
MMIO window which I'd be happy to favor on power.

We could even put somewhere in there a feature bit set by qemu to
indicate whether it thinks PIO or MMIO is faster on a given platform if
you really think that's worth it (I don't).

Cheers,
Ben.

Benjamin Herrenschmidt <benh at kernel.crashing.org> writes:
> On Wed, 2013-06-05 at 16:53 -0500, Anthony Liguori wrote:
>
>> A smart BIOS can also use MMIO to program virtio.
>
> Indeed :-)
>
> I see no reason why not providing both access path though. Have the PIO
> BAR there for compatibility/legacy/BIOS/x86 purposes and *also* have the
> MMIO window which I'd be happy to favor on power.
>
> We could even put somewhere in there a feature bit set by qemu to
> indicate whether it thinks PIO or MMIO is faster on a given platform if
> you really think that's worth it (I don't).
That's okay, but what I'm most concerned about is compatibility.

A virtio PCI device that's a "native endpoint" needs to have a
different
device ID than one that is a "legacy endpoint".  The current drivers
have no hope of working (well) with virtio PCI devices exposed as native
endpoints.

I don't care if the native PCI endpoint also has a PIO bar.  But it
seems silly (and confusing) to me to make that layout be the "legacy"
layout verses a straight mirror of the new layout if we're already
changing the device ID.

In addition, it doesn't seem at all necessary to have an MMIO bar to the
legacy device.  If the reason you want MMIO is to avoid using PIO, then
you break existing drivers because they assume PIO.  If you are breaking
existing drivers then you should change the device ID.

If strictly speaking it's just that MMIO is a bit faster, I'm not sure
that complexity is worth it without seeing performance numbers first.

Regards,

Anthony Liguori
>
> Cheers,
> Ben.
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

On Wed, 2013-06-05 at 17:53 -0500, Anthony Liguori
wrote:
> If strictly speaking it's just that MMIO is a bit faster, I'm not
sure
> that complexity is worth it without seeing performance numbers first.
You mean PIO. I agree with all your points here. The only thing I
saw as an option would be to add a PIO BAR that is an exact mirror
of the MMIO BAR if and only if:

 - PIO is indeed significantly faster on platforms we care about

and/or

 - There is significant simplification in things like BIOSes in
   using PIO over MMIO

I personally don't care and would chose to use MMIO always including in
firmware on ppc.

Cheers,
Ben.