Message-ID: <4B3103B4.4070708@gmail.com>
Date:	Tue, 22 Dec 2009 12:36:52 -0500
From:	Gregory Haskins <gregory.haskins@...il.com>
To:	Ingo Molnar <mingo@...e.hu>
CC:	Avi Kivity <avi@...hat.com>, kvm@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>,
	torvalds@...ux-foundation.org,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	netdev@...r.kernel.org,
	"alacrityvm-devel@...ts.sourceforge.net" 
	<alacrityvm-devel@...ts.sourceforge.net>
Subject: Re: [GIT PULL] AlacrityVM guest drivers for 2.6.33

On 12/22/09 2:57 AM, Ingo Molnar wrote:
> 
> * Gregory Haskins <gregory.haskins@...il.com> wrote:
> 
>> On 12/18/09 4:51 PM, Ingo Molnar wrote:
>>>
>>> * Gregory Haskins <gregory.haskins@...il.com> wrote:
>>>
>>>> Hi Linus,
>>>>
>>>> Please pull AlacrityVM guest support for 2.6.33 from:
>>>>
>>>> git://git.kernel.org/pub/scm/linux/kernel/git/ghaskins/alacrityvm/linux-2.6.git
>>>> for-linus
>>>>
>>>> All of these patches have stewed in linux-next for quite a while now:
>>>>
>>>> Gregory Haskins (26):
>>>
>>> I think it would be fair to point out that these patches have been objected to 
>>> by the KVM folks quite extensively,
>>
>> Actually, these patches have nothing to do with the KVM folks. [...]
> 
> That claim is curious to me - the AlacrityVM host

It's quite simple, really.  These drivers support accessing vbus, and
vbus is hypervisor agnostic.  In fact, vbus isn't necessarily even
hypervisor related.  It may be used anywhere where a Linux kernel is the
"io backend", which includes hypervisors like AlacrityVM, but also
userspace apps, and interconnected physical systems as well.

The vbus-core on the backend, and the drivers on the frontend operate
completely independent of the underlying hypervisor.  A glue piece
called a "connector" ties them together, and any "hypervisor" specific
details are encapsulated in the connector module.  In this case, the
connector surfaces to the guest side as a pci-bridge, so even that is
not hypervisor specific per se.  It will work with any pci-bridge that
exposes a compatible ABI, which conceivably could be actual hardware.

The AlacrityVM project just so happens to be the primary consumer, and
is therefore the most convenient way to package them up at the moment.

> is 90% based on KVM code, so 
> how can it not be about KVM? I just checked, most of the changes that 
> AlacrityVM host does to KVM is in adding the host side interfaces for these 
> guest drivers:
> 
>  virt/kvm/Kconfig          |   11 +
>  virt/kvm/coalesced_mmio.c |   65 +++---
>  virt/kvm/coalesced_mmio.h |    1 +
>  virt/kvm/eventfd.c        |  599 +++++++++++++++++++++++++++++++++++++++++++++
>  virt/kvm/ioapic.c         |  118 +++++++--
>  virt/kvm/ioapic.h         |    5 +
>  virt/kvm/iodev.h          |   55 +++--
>  virt/kvm/irq_comm.c       |  267 ++++++++++++++-------
>  virt/kvm/kvm_main.c       |  127 ++++++++--
>  virt/kvm/xinterface.c     |  587 ++++++++++++++++++++++++++++++++++++++++++++
>  10 files changed, 1649 insertions(+), 186 deletions(-)
> 
>  [ stat for virt/kvm/ taken as of today, AlacrityVM host tree commit 84afcc7 ]
> 
> So as far as kernel code modifications of AlacrityVM goes, it's very much 
> about KVM.

I think you are confused.  Even if we entertained the notion that the
host side diffstat were somehow relevant here, you are probably
comparing the kvm.git backports that are in my tree.  The only real KVM
specific change that is in my tree is the 587 lines for the xinterface.c
module, which is about ~4%, not 90%.  Also note that I have pushed this
xinterface logic upstream already, but it just hasn't been accepted yet.

If I wanted to be extremely generous, you could include the entire "KVM
connector" code that bridges vbus-core to kvm-core, but even that tops
out at a total of ~17% of the changes in my tree.  So I am still not
seeing the 90% nor how it is relevant.

> 
>> [...]  You are perhaps confusing this with the hypervisor-side discussion, 
>> of which there is indeed much disagreement.
> 
> Are the guest drivers living in a vacuum? The whole purpose of the AlacrityVM 
> guest drivers is to ... enable AlacrityVM support, right?

More specifically, the purpose of the drivers, like any driver, is to
enable support for the underlying device in which it is related to.  In
this case, the devices are vbus based devices.  Of those, AlacrityVM is
the only available platform that exposes them.  However, that is a
maturity/adoption detail, not a technical limitation.  Simply
implementing a new connector would bridge these drivers to other
environments as well.  There are community members working on these as
we speak, as a matter of fact.

> So how can it be not about KVM?

Because AlacrityVM is a hypervisor that supports VBUS for PV IO, and KVM
is not.  In addition, the presence of these drivers in no way alters,
interferes with, or diminishes features found in KVM today.  So it is,
and never will be about KVM until upstream KVM decides that they want to
support VBUS based PV-IO.

If you want to talk about the host side, then I have +587 lines that
hang in the balance that affect KVM, yes.  But that isn't what $subject
was about.

> 
> Gregory, it would be nice if you worked _much_ harder with the KVM folks 
> before giving up.

I think the 5+ months that I politely tried to convince the KVM folks
that this was a good idea was pretty generous of my employer.  The KVM
maintainers have ultimately made it clear they are not interested in
directly supporting this concept (which is their prerogative), but are
perhaps willing to support the peripheral logic needed to allow it to
easily interface with KVM.  I can accept that, and thus AlacrityVM was born.

Note that upstream KVM are also only a subset of the mindshare needed
for this project anyway, since most of the core is independent of KVM.
Perhaps the KVM folks will reconsider if/when other community members
start to see the merit in the work.  Perhaps not.  It's out of my
control at this point.

> It's not like there's much valid technical disagreement that 
> i can identify in any of the threads

While I am sorry to hear that, it should be noted that this doesn't mean
that your perception is accurate, either.  It was quite a long and
fragmented set of threads over those 5+ months, so absorbing the gist of
the vision from casual observation is not likely trivial.

> - the strongest one i could identify was: 
> "I want to fork KVM so please let me do it, nobody is harmed, choice is good".

Everyone is of course entitled to an opinion, but I would respectfully
disagree with your statement (as I did last time you made the same
claim, as well).  I have now, nor ever, wanted a fork.  But I also
believe in the work I am doing, so I won't roll over and die just
because a certain group doesn't share the vision per se either, sorry.
I get the impression that you would not either if you were in a similar
situation, so perhaps you can respect that.

Kind Regards,
-Greg


Download attachment "signature.asc" of type "application/pgp-signature" (268 bytes)

Powered by blists - more mailing lists