Re: [RFC PATCH v01] Xen PVSCSI drivers for pvops xen/stable-2.6.32.x kernel

[Olaf Hering <olaf@aepfle.de>]

On Fri, Jan 07, Ian Campbell wrote:

> On Fri, 2011-01-07 at 10:03 +0000, Nathanael Rensen wrote:
> > On 7 January 2011 06:35,  Pasi Kärkkäinen <pasik@iki.fi> wrote:
> > > Hello,
> > >
> > > http://pasik.reaktio.net/xen/patches/xen-pvscsi-drivers-linux-2.6.32.27-pvops-v01.diff
> > >
> > > This is the first version of Xen PVSCSI drivers, both the scsiback backend and
> > > scsifront frontend, ported from Novell SLES11SP1 2.6.32 Xenlinux kernel to
> > > pvops xen/stable-2.6.32.x branch.
> > >
> > > -- Pasi
> > 
> > That's great. Some comments based on my experience with pvusb:
> > 
> > 1) You've added GNTST_eagain into include/xen/interface/grant_table.h.
> > When porting the pvusb drivers I removed the "check and retry" loops
> > based on GNTST_eagain because I noticed that netback and blkback don't
> > do that. Looking at the grant_table code in xen-4.0-testing I don't
> > think GNTST_eagain is used now. Perhaps someone with knowledge of the
> > history of GNTST_eagain could help to clarify.
> 
> IIRC GNTST_eagain was added to the classic Xen trees but never forward
> ported to pvops.
> 
> It's part of the page sharing paging work (so dom0 can deal with a
> paged/shared guest rather than for paging of dom0 itself). I guess those
> don't work with pvops kernels? CC'ing the guys who are working on that
> stuff.

I have not tried the pvops kernel with xenpaging.

> (The presence of the use of msleep in the eagain case is a bit
> terrifying. Stripping it out for now and redoing it might not be a bad
> plan)

Right now the retry is required for xenpaging, otherwise the guests
filesystem will be corrupted.
In the long run the newly added waitqueue feature may be used to make
the page access transparent to the guest and dom0.


Olaf