pvSCSI question - can a gref describe more than one page?

pvSCSI question - can a gref describe more than one page?

[James Harper]

Porting the pvSCSI backend driver to the pvops kernel is turning out to
be a bit harder than first thought, mostly because all the Linux
routines that might be useful are written with the assumption that they
would be passed a mapped buffer and they would then build an sg list out
of that. pvSCSI already has an sg list, and all the routines that it
makes use of have been deprecated since 2.6.18 (all the comments on the
patches that remove the routines are like "nobody uses this anymore".
D'oh.)

The big complication appears to be that pvSCSI seems to think that an
individual sg element can span a page, and so has to muck around
splitting it into page-sized chunks. My assumption is that this is
because the code in pvSCSI was cut&pasted from somewhere else.

Can a single grant entry ever describe more than one page?

Thanks

James

Re: pvSCSI question - can a gref describe more than one page?

[Jeremy Fitzhardinge]

On 03/09/2010 07:18 PM, James Harper wrote:
> Porting the pvSCSI backend driver to the pvops kernel is turning out to
> be a bit harder than first thought, mostly because all the Linux
> routines that might be useful are written with the assumption that they
> would be passed a mapped buffer and they would then build an sg list out
> of that. pvSCSI already has an sg list, and all the routines that it
> makes use of have been deprecated since 2.6.18 (all the comments on the
> patches that remove the routines are like "nobody uses this anymore".
> D'oh.)
>
> The big complication appears to be that pvSCSI seems to think that an
> individual sg element can span a page, and so has to muck around
> splitting it into page-sized chunks. My assumption is that this is
> because the code in pvSCSI was cut&pasted from somewhere else.
>    

In general its a bug if an sg entry crosses a page boundary.  We define 
BIOVEC_PHYS_MERGEABLE so that we avoid doing any cross-page merges 
(unless, I think, the underlying mfns are actually contiguous).  Does 
that help?

     J

RE: pvSCSI question - can a gref describe more than one page?

[James Harper]

> 
> On 03/09/2010 07:18 PM, James Harper wrote:
> > Porting the pvSCSI backend driver to the pvops kernel is turning out
to
> > be a bit harder than first thought, mostly because all the Linux
> > routines that might be useful are written with the assumption that
they
> > would be passed a mapped buffer and they would then build an sg list
out
> > of that. pvSCSI already has an sg list, and all the routines that it
> > makes use of have been deprecated since 2.6.18 (all the comments on
the
> > patches that remove the routines are like "nobody uses this
anymore".
> > D'oh.)
> >
> > The big complication appears to be that pvSCSI seems to think that
an
> > individual sg element can span a page, and so has to muck around
> > splitting it into page-sized chunks. My assumption is that this is
> > because the code in pvSCSI was cut&pasted from somewhere else.
> >
> 
> In general its a bug if an sg entry crosses a page boundary.  We
define
> BIOVEC_PHYS_MERGEABLE so that we avoid doing any cross-page merges
> (unless, I think, the underlying mfns are actually contiguous).  Does
> that help?
> 

So a single gref can only describe a single page right? If that
assumption is correct then I think I'm good.

The code compiles now and doesn't crash Dom0 or anything, but my windows
pvSCSI driver crashes because the gref is still in use when it gets it
back... so still some bugs to fix.

James

Re: pvSCSI question - can a gref describe more than one page?

[Pasi Kärkkäinen]

On Thu, Mar 11, 2010 at 09:17:55AM +1100, James Harper wrote:
> > 
> > On 03/09/2010 07:18 PM, James Harper wrote:
> > > Porting the pvSCSI backend driver to the pvops kernel is turning out
> to
> > > be a bit harder than first thought, mostly because all the Linux
> > > routines that might be useful are written with the assumption that
> they
> > > would be passed a mapped buffer and they would then build an sg list
> out
> > > of that. pvSCSI already has an sg list, and all the routines that it
> > > makes use of have been deprecated since 2.6.18 (all the comments on
> the
> > > patches that remove the routines are like "nobody uses this
> anymore".
> > > D'oh.)
> > >
> > > The big complication appears to be that pvSCSI seems to think that
> an
> > > individual sg element can span a page, and so has to muck around
> > > splitting it into page-sized chunks. My assumption is that this is
> > > because the code in pvSCSI was cut&pasted from somewhere else.
> > >
> > 
> > In general its a bug if an sg entry crosses a page boundary.  We
> define
> > BIOVEC_PHYS_MERGEABLE so that we avoid doing any cross-page merges
> > (unless, I think, the underlying mfns are actually contiguous).  Does
> > that help?
> > 
> 
> So a single gref can only describe a single page right? If that
> assumption is correct then I think I'm good.
> 
> The code compiles now and doesn't crash Dom0 or anything, but my windows
> pvSCSI driver crashes because the gref is still in use when it gets it
> back... so still some bugs to fix.
> 

Btw it seems Novell has pvscsi backend/frontend in their SLES11 SP1 2.6.32 kernel tree..
if you want to take a look for the pvops port.

-- Pasi