On 12/22/09 2:57 AM, Ingo Molnar wrote: > > * Gregory Haskins <gregory.haskins@xxxxxxxxx> wrote: > >> On 12/18/09 4:51 PM, Ingo Molnar wrote: >>> >>> * Gregory Haskins <gregory.haskins@xxxxxxxxx> 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
Attachment:
signature.asc
Description: OpenPGP digital signature
