Re: [PATCH v3 3/6] vbus: add a "vbus-proxy" bus model forvbus_driver objects

[Ingo Molnar]

* Gregory Haskins <gregory.haskins@xxxxxxxxx> wrote:

> Ingo Molnar wrote:
> > * Gregory Haskins <ghaskins@xxxxxxxxxx> wrote:
> > 
> >> This will generally be used for hypervisors to publish any host-side
> >> virtual devices up to a guest.  The guest will have the opportunity
> >> to consume any devices present on the vbus-proxy as if they were
> >> platform devices, similar to existing buses like PCI.
> >>
> >> Signed-off-by: Gregory Haskins <ghaskins@xxxxxxxxxx>
> >> ---
> >>
> >>  MAINTAINERS                 |    6 ++
> >>  arch/x86/Kconfig            |    2 +
> >>  drivers/Makefile            |    1 
> >>  drivers/vbus/Kconfig        |   14 ++++
> >>  drivers/vbus/Makefile       |    3 +
> >>  drivers/vbus/bus-proxy.c    |  152 +++++++++++++++++++++++++++++++++++++++++++
> >>  include/linux/vbus_driver.h |   73 +++++++++++++++++++++
> >>  7 files changed, 251 insertions(+), 0 deletions(-)
> >>  create mode 100644 drivers/vbus/Kconfig
> >>  create mode 100644 drivers/vbus/Makefile
> >>  create mode 100644 drivers/vbus/bus-proxy.c
> >>  create mode 100644 include/linux/vbus_driver.h
> > 
> > Is there a consensus on this with the KVM folks? (i've added the KVM 
> > list to the Cc:)
> > 
> > 
> 
> Hi Ingo,
> 
> Avi can correct me if I am wrong, but the agreement that he and I 
> came to a few months ago was something to the effect of:
> 
> kvm will be neutral towards various external IO subsystems, and 
> instead provide various hooks (see irqfd, ioeventfd) to permit 
> these IO subsystems to interface with kvm.
> 
> AlacrityVM is one of the first projects to take advantage of that 
> interface.  AlacrityVM is kvm-core + vbus-core + 
> vbus-kvm-connector + vbus-enhanced qemu + guest drivers.  This 
> thread is part of the guest-drivers portion.  Note that it is 
> specific to alacrityvm, not kvm, which is why the kvm list was not 
> included in the conversation (also an agreement with Avi: 
> http://lkml.org/lkml/2009/8/6/231).

Well my own opinion is that the fracturing of the Linux internal 
driver space into diverging pieces of duplicate functionality 
(absent compelling technical reasons) is harmful.

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/