Re: [RFC PATCH 00/17] virtual-bus

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

 



Gregory Haskins wrote:
vbus (if I understand it right) is a whole package of things:

- a way to enumerate, discover, and manage devices

Yes
That part duplicates PCI

Yes, but the important thing to point out is it doesn't *replace* PCI. It simply an alternative.

Does it offer substantial benefits over PCI?  If not, it's just extra code.

Note that virtio is not tied to PCI, so "vbus is generic" doesn't count.

and it would be pretty hard to convince me we need to move to
something new

But thats just it.  You don't *need* to move.  The two can coexist side
by side peacefully.  "vbus" just ends up being another device that may
or may not be present, and that may or may not have devices on it.  In
fact, during all this testing I was booting my guest with "eth0" as
virtio-net, and "eth1" as venet.  The both worked totally fine and
harmoniously.  The guest simply discovers if vbus is supported via a
cpuid feature bit and dynamically adds it if present.

I meant, move the development effort, testing, installed base, Windows drivers.

.  virtio-pci (a) works,
And it will continue to work

So why add something new?

(b) works on Windows.

virtio will continue to work on windows, as well.  And if one of my
customers wants vbus support on windows and is willing to pay us to
develop it, we can support *it* there as well.

I don't want to develop and support both virtio and vbus. And I certainly don't want to depend on your customers.

- a different way of doing interrupts
Yeah, but this is ok.  And I am not against doing that mod we talked
about earlier where I replace dynirq with a pci shim to represent the
vbus.  Question about that: does userspace support emulation of MSI
interrupts?

Yes, this is new. See the interrupt routing stuff I mentioned. It's probably only in kvm.git, not even in 2.6.30.

I would probably prefer it if I could keep the vbus IRQ (or
IRQs when I support MQ) from being shared.  It seems registering the
vbus as an MSI device would be more conducive to avoiding this.

I still think you want one MSI per device rather than one MSI per vbus, to avoid scaling problems on large guest. After Herbert's let loose on the code, one MSI per queue.


- a different ring layout, and splitting notifications from the ring
Again, virtio will continue to work.  And if we cannot find a way to
collapse virtio and ioq together in a way that everyone agrees on, there
is no harm in having two.  I have no problem saying I will maintain
IOQ.  There is plenty of precedent for multiple ways to do the same thing.

IMO we should just steal whatever makes ioq better, and credit you in some file no one reads. We get backwards compatibility, Windows support, continuity, etc.

I don't see the huge win here

- placing the host part in the host kernel

Nothing vbus-specific here.

Well, it depends on what you want.  Do you want a implementation that is
virtio-net, kvm, and pci specific while being hardcoded in?

No. virtio is already not kvm or pci specific. Definitely all the pci emulation parts will remain in user space.

  What
happens when someone wants to access it but doesnt support pci?  What if
something like lguest wants to use it too?  What if you want
virtio-block next?  This is one extreme.

It works out well on the guest side, so it can work on the host side. We have virtio bindings for pci, s390, and of course lguest. virtio itself is agnostic to all of these. The main difference from vbus is that it's guest-only, but could easily be extended to the host side if we break down and do things in the kernel.


--
error compiling committee.c: too many arguments to function

--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux