From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [RFC PATCH 0/9] PV device infrastructure v2 Date: Wed, 15 Aug 2007 06:58:30 +0300 Message-ID: <46C279E6.40004@qumranet.com> References: <20070814233352.11895.55788.stgit@ghaskins-t60p.haskins.net> <46C269EE.10807@qumranet.com> <1187149634.4165.151.camel@ghaskins-t60p.haskins.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org To: Gregory Haskins Return-path: In-Reply-To: <1187149634.4165.151.camel-5CR4LY5GPkvLDviKLk5550HKjMygAv58XqFh9Ls21Oc@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org Errors-To: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org List-Id: kvm.vger.kernel.org Gregory Haskins wrote: > >> If so, be aware that virtio is (a) mostly done (b) very well done. >> > > I would very much like to help make virtio work, which is really where I > was going with this. My design is a little bit different so I was > submitting it in case there was any ideas worth salvaging to be picked > up by the official project. (I tried to explain this in the v1 > announcement so I apologize if anyone, particularly Rusty, felt > slighted....it was not my intention) > Alternative implementation ideas should of course not slight anyone but instead be welcomed. > >> Can you describe what you are trying to achieve that virtio doesn't do? >> >> > > To be perfectly honest, I have never been able to find an implementation > of virtio (I looked and even asked Rusty directly via email but never > found/heard anything back) so I don't know exactly what its capabilities > are. My impressions from reading Rusty's email proposals are that there > are certainly similarities to the virtio interface and the ioq interface > in concept. Where they seem to differ is that the concept of the ring > is more exposed in IOQ via the iterator idiom instead of the sg-buffer > idiom. > Yes. virtio adapts the driver interface to an API can drive a shared memory queue more easily, while you actually provide the queue protocol (and ABI). > At the time I first saw the virtio proposals, I couldn't quite wrap my > head around how I could do things like "zero copy" + deferred pointer > reaping, which was a design goal of mine. So I kept up with the IOQ > design for the interim to at least demonstrate where I was trying to go. > Perhaps it will be a useful innovation and the virtio interface design > will pick up some of my ideas. Perhaps virtio deals with it already. > Or perhaps no one will think its a good idea and it gets pushed > to /dev/null ;) I am not sure what the answer will be. > > But in any case, I was also trying to go beyond the shared-ring > interface design. For instance, the series also provides: > > *) a system for efficiently discovering/communicating with PV backend > devices that was not laden with legacy interfaces like PCI. (I am in > the process of converting over to use bus_register as Dor suggested). > > *) generalization of as much of the shared-memory code as possible so it > could be reused (for instance, both guest and host can use the same IOQ > interface, and the code itself will largely work with any hypervisor, or > even non-hypervisor shared-memory systems, like RDMA/AMP). > > Again, perhaps virtio will cover all these areas too. Without having > seen it I am not really sure where the overlap exists, but perhaps there > will be at least some aspects of my series that are useful. That is why > I submitted it. Ideally I can hook up with whomever is working on the > implementation (sounds like Dor?) and we can crank something out > together. :) > virtio seems to have more modest goals: - make it easier to write guest/host (or guest/guest) transports, but not actually provide them - limited to guest only (and Linux only) - no discovery/hotplug (yet?) since it wants to be hypervisor agnostic, it cannot specify an ABI (as some already have ABIs, for example Xen). -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/