From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dor Laor Subject: Re: [PATCH 0/6] virtio with config abstraction and ring implementation Date: Thu, 20 Sep 2007 15:43:54 +0200 Message-ID: <46F2791A.8070601@qumranet.com> References: <1190289808.7262.223.camel@localhost.localdomain> Reply-To: dor.laor-atKUWr5tajBWk0Htik3J/w@public.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1663211302==" Cc: kvm-devel , lguest , virtualization To: Rusty Russell Return-path: In-Reply-To: <1190289808.7262.223.camel-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@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 This is a multi-part message in MIME format. --===============1663211302== Content-Type: multipart/alternative; boundary="------------020400040408010003010806" This is a multi-part message in MIME format. --------------020400040408010003010806 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Rusty Russell wrote: > > Hi all, > > This patch series attempts to come closer to unifying kvm and > lguest's > usage of virtio. As these two are the first implementations we've seen, > I hope making them closer will make future ones closer too. > > Drivers now unpack their own configuration: their probe() > methods are > uniform. The configuration mechanism is extensible and can be backed by > PCI, a string of bytes, or something else. > > I've abstracted out the lguest ring buffer code into a common > library. > The format has changed slightly (mainly because I had an epiphany about > inter-guest I/O). > > I also implemented a console (lguest needs one). > > Finally, there is a working lguest implementation. Unfortunately, > lguest is being refactored for non-i386 ports, so the virtio patches sit > at the end of the (quite long) for-2.6.24 patchqueue. Nonetheless, they > can be found at http://lguest.ozlabs.org/patches (click on bz2 to get > the series). > > Cheers! > Rusty. > Superb job, it saved me the burden of try to merge the in-house virtio_backend. I like the separation of the ring code, the improved descriptors and the notify too. Regarding the pci config space, I rather see config_ops type of operations to let the 390/xen/other implementations jump on our wagon. Maybe change the offset/len type into a handle pointer and function pointers. The best would be to let them comment on that. I glimpsed over xen netfront.c and I think that the config space can be used without too many hassles Dor. --------------020400040408010003010806 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Rusty Russell wrote:
[PATCH 0/6] virtio with config abstraction and ring implementation

Hi all,

        This patch series attempts to come closer to unifying kvm and lguest's
usage of virtio.  As these two are the first implementations we've seen,
I hope making them closer will make future ones closer too.

        Drivers now unpack their own configuration: their probe() methods are
uniform.  The configuration mechanism is extensible and can be backed by
PCI, a string of bytes, or something else.

        I've abstracted out the lguest ring buffer code into a common library.
The format has changed slightly (mainly because I had an epiphany about
inter-guest I/O).

        I also implemented a console (lguest needs one).

        Finally, there is a working lguest implementation.  Unfortunately,
lguest is being refactored for non-i386 ports, so the virtio patches sit
at the end of the (quite long) for-2.6.24 patchqueue.  Nonetheless, they
can be found at http://lguest.ozlabs.org/patches (click on bz2 to get
the series).

Cheers!
Rusty.

Superb job, it saved me the burden of try to merge the in-house virtio_backend.

I like the separation of the ring code, the improved descriptors and the notify too.
Regarding the pci config space, I rather see config_ops type of operations to let
the 390/xen/other implementations jump on our wagon.

Maybe change the offset/len type into a handle pointer and function pointers.
The best would be to let them comment on that. I glimpsed over xen netfront.c and I think that
the config space can be used without too many hassles
Dor.

--------------020400040408010003010806-- --===============1663211302== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ --===============1663211302== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ kvm-devel mailing list kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org https://lists.sourceforge.net/lists/listinfo/kvm-devel --===============1663211302==--