lkml.org 
[lkml]   [2009]   [Aug]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC PATCH v2 19/19] virtio: add a vbus transport
Gregory Haskins wrote:
> We add a new virtio transport for accessing backends located on vbus. This
> complements the existing transports for virtio-pci, virtio-s390, and
> virtio-lguest that already exist.
>
> Signed-off-by: Gregory Haskins <ghaskins@novell.com>

Very interesting...

I'm somewhat confused by what you're advocating vbus as. I'm trying to
figure out how we converge vbus and virtio and become one big happy
family :-)

What parts of it do you think are better than virtio? Should we forget
about venet and just focus on virtio-net on top of virtio-vbus assuming
that we can prove venet-tap/virtio-vbus/virtio-net is just as good as
venet-tap/vbus/venet?

If we can prove that an in-kernel virtio-net
backend/virtio-pci/virtio-net does just as well as
venet-tap/virtio-vbus/virtio-net does that mean that vbus is no longer
needed?

If you concede that the transport mechanisms can be identical, are you
really advocating the discovering and configuration mechanisms in vbus?
Is that what we should be focusing on? Do you care only about the host
mechanisms or do you also require the guest infrastructure to be present?

I think two paravirtual I/O frameworks for KVM is a bad thing. It
duplicates a ton of code and will very likely lead to user unhappiness.

Regards,

Anthony Liguori


\
 
 \ /
  Last update: 2009-08-09 18:43    [W:0.297 / U:0.804 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site