Xen devel - Mar 2010 - pvSCSI question - can a gref describe more than one page?

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


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

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

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

> 
> 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

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

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


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel