set_phys_to_machine not exported?

set_phys_to_machine not exported?

[James Harper]

I'm trying to compile pvscsi out-of-tree, and I'm getting an error that set_phys_to_machine is not defined when I try to load the module (with the warning to that effect at compile time too). This used to work fine in pvops.

It seems that netfront uses that symbol in a module so I'm confused as to why pvscsi can't... any suggestions? Is it one of the virtues of netfront being an in-tree driver?

Is there another call I can use instead or does that symbol need to be exported?

Thanks

James

Re: set_phys_to_machine not exported?

[Konrad Rzeszutek Wilk]

On Fri, Dec 30, 2011 at 12:06:58PM +0000, James Harper wrote:
> I'm trying to compile pvscsi out-of-tree, and I'm getting an error that set_phys_to_machine is not defined when I try to load the module (with the warning to that effect at compile time too). This used to work fine in pvops.

Which tree are you using? The devel/xen-scsi-1.0 ?

Or the #testing one?

What do you mean: "This used to work fine in pvops" ? Can you be more
specific please.
> 
> It seems that netfront uses that symbol in a module so I'm confused as to why pvscsi can't... any suggestions? Is it one of the virtues of netfront being an in-tree driver?

> 
> Is there another call I can use instead or does that symbol need to be exported?

That is the only one?
> 
> Thanks
> 
> James
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

Re: set_phys_to_machine not exported?

[James Harper]

> 
> On Fri, Dec 30, 2011 at 12:06:58PM +0000, James Harper wrote:
> > I'm trying to compile pvscsi out-of-tree, and I'm getting an error that
> set_phys_to_machine is not defined when I try to load the module (with the
> warning to that effect at compile time too). This used to work fine in pvops.
> 
> Which tree are you using? The devel/xen-scsi-1.0 ?
> 
> Or the #testing one?
> 
> What do you mean: "This used to work fine in pvops" ? Can you be more
> specific please.

Quite a while ago I grabbed scsiback out of 2.6.18 and patched it up so it compiled against jeremy's 2.6.32 tree (out-of-tree build though). That worked fine, and I didn't need scsifront as gplpv is the front end.

Now I'm trying to do the same against 3.0.1 (just compiling against the debian kernel-headers) and it builds fine after a bit more patching but set_phys_to_machine isn't exported.

> >
> > Is there another call I can use instead or does that symbol need to be
> exported?
> 
> That is the only one?

Comparing with blkback from 3.0.1, it uses m2p_add_override instead I think... should that work if I make the same changes to scsiback?

Or maybe someone else already has scsiback working against 3.x.x?

Thanks

James

Re: set_phys_to_machine not exported?

[Konrad Rzeszutek Wilk]

On Tue, Jan 03, 2012 at 08:10:52PM +0000, James Harper wrote:
> > 
> > On Fri, Dec 30, 2011 at 12:06:58PM +0000, James Harper wrote:
> > > I'm trying to compile pvscsi out-of-tree, and I'm getting an error that
> > set_phys_to_machine is not defined when I try to load the module (with the
> > warning to that effect at compile time too). This used to work fine in pvops.
> > 
> > Which tree are you using? The devel/xen-scsi-1.0 ?
> > 
> > Or the #testing one?
> > 
> > What do you mean: "This used to work fine in pvops" ? Can you be more
> > specific please.
> 
> Quite a while ago I grabbed scsiback out of 2.6.18 and patched it up so it compiled against jeremy's 2.6.32 tree (out-of-tree build though). That worked fine, and I didn't need scsifront as gplpv is the front end.

Ah, you are using the Windows Xen SCSI driver. Cool. Excited to know it works
that well.

> 
> Now I'm trying to do the same against 3.0.1 (just compiling against the debian kernel-headers) and it builds fine after a bit more patching but set_phys_to_machine isn't exported.
> 
> > >
> > > Is there another call I can use instead or does that symbol need to be
> > exported?
> > 
> > That is the only one?
> 
> Comparing with blkback from 3.0.1, it uses m2p_add_override instead I think... should that work if I make the same changes to scsiback?
> 
> Or maybe someone else already has scsiback working against 3.x.x?

I do. Try the #testing branch or the #devel/xen-scsi-1.0 (but you should merge it against the 3.1 kernel
otherwise it won't compile b/c one argument changed - but you could alter it yourself if you are
using the 3.0 tree).

Git tree: git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git

They also moved - to drivers/scsi.
> 
> Thanks
> 
> James
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

Re: set_phys_to_machine not exported?

[James Harper]

> > Or maybe someone else already has scsiback working against 3.x.x?
> 
> I do. Try the #testing branch or the #devel/xen-scsi-1.0 (but you should
> merge it against the 3.1 kernel otherwise it won't compile b/c one argument
> changed - but you could alter it yourself if you are using the 3.0 tree).
> 
> Git tree: git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
> 
> They also moved - to drivers/scsi.

My git-foo is a bit rusty. Having cloned the tree, how do I check out the remote branch?

James

Re: set_phys_to_machine not exported?

[Konrad Rzeszutek Wilk]

On Tue, Jan 03, 2012 at 11:44:53PM +0000, James Harper wrote:
> > > Or maybe someone else already has scsiback working against 3.x.x?
> > 
> > I do. Try the #testing branch or the #devel/xen-scsi-1.0 (but you should
> > merge it against the 3.1 kernel otherwise it won't compile b/c one argument
> > changed - but you could alter it yourself if you are using the 3.0 tree).
> > 
> > Git tree: git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
> > 
> > They also moved - to drivers/scsi.
> 
> My git-foo is a bit rusty. Having cloned the tree, how do I check out the remote branch?

git checkout origin/testing

> 
> James

Re: set_phys_to_machine not exported?

[James Harper]

> >
> > Quite a while ago I grabbed scsiback out of 2.6.18 and patched it up so it
> > compiled against jeremy's 2.6.32 tree (out-of-tree build though). That
> > worked fine, and I didn't need scsifront as gplpv is the front end.
> 
> Ah, you are using the Windows Xen SCSI driver. Cool. Excited to know it
> works that well.

Yes I do restores from tape to Windows VM's using Symantec Backup Exec IDR.

> >
> > Or maybe someone else already has scsiback working against 3.x.x?
> 
> I do. Try the #testing branch or the #devel/xen-scsi-1.0 (but you should
> merge it against the 3.1 kernel otherwise it won't compile b/c one argument
> changed - but you could alter it yourself if you are using the 3.0 tree).
> 

What is the changed argument? I see a couple of #defines that aren't present in 3.1.0 (GNTST_eagain and DEFINE_XENBUS_DRIVER), but having built it I'm now getting a crash when I try and load the module.

Also, there are some includes in vscsiif.h that are unnecessary as they are included by common.h... do you think they could be removed?

James

Re: set_phys_to_machine not exported?

[James Harper]

> > Or maybe someone else already has scsiback working against 3.x.x?
> 
> I do. Try the #testing branch or the #devel/xen-scsi-1.0 (but you should
> merge it against the 3.1 kernel otherwise it won't compile b/c one argument
> changed - but you could alter it yourself if you are using the 3.0 tree).
> 
> Git tree: git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
> 

Okay I have it compiling and loading now (that xenbus init macro obviously isn't for the Debian 3.1.0 kernel I'm running...) but I can't attach a scsi device - it just hangs for a while then says hotplug didn't work.

Any suggestions? Would it be expected to work against the Xen 4.0.4-rc1-pre I'm running now?

Thanks

James

Re: set_phys_to_machine not exported?

[James Harper]

> Okay I have it compiling and loading now (that xenbus init macro obviously
> isn't for the Debian 3.1.0 kernel I'm running...) but I can't attach a scsi device -
> it just hangs for a while then says hotplug didn't work.
> 
> Any suggestions? Would it be expected to work against the Xen 4.0.4-rc1-pre
> I'm running now?
> 

Loading and detecting properly now (see email about the choice of shell in the vscsi script), and appears to be restoring with the following patch:

--- ../konrad/xen/drivers/scsi/xen-scsiback/emulate.c   2012-01-04 10:51:36.090985303 +1100
+++ emulate.c   2012-01-04 13:28:23.288336520 +1100
@@ -401,8 +401,8 @@
        NO_EMULATE(INQUIRY);               /*0x12*/
        /*NO_EMULATE(RECOVER_BUFFERED_DATA); *//*0x14*/
        NO_EMULATE(MODE_SELECT);           /*0x15*/ /* st */
-       /*NO_EMULATE(RESERVE);               *//*0x16*/
-       /*NO_EMULATE(RELEASE);               *//*0x17*/
+       NO_EMULATE(RESERVE);               /*0x16*/
+       NO_EMULATE(RELEASE);               /*0x17*/
        /*NO_EMULATE(COPY);                  *//*0x18*/
        NO_EMULATE(ERASE);                 /*0x19*/ /* st */
        NO_EMULATE(MODE_SENSE);            /*0x1a*/ /* st */

James

Re: set_phys_to_machine not exported?

[Jan Beulich]

>>> On 04.01.12 at 04:44, James Harper <james.harper@bendigoit.com.au> wrote:
>>  Okay I have it compiling and loading now (that xenbus init macro obviously
>> isn't for the Debian 3.1.0 kernel I'm running...) but I can't attach a scsi 
> device -
>> it just hangs for a while then says hotplug didn't work.
>> 
>> Any suggestions? Would it be expected to work against the Xen 4.0.4-rc1-pre
>> I'm running now?
>> 
> 
> Loading and detecting properly now (see email about the choice of shell in 
> the vscsi script), and appears to be restoring with the following patch:
> 
> --- ../konrad/xen/drivers/scsi/xen-scsiback/emulate.c   2012-01-04 
> 10:51:36.090985303 +1100
> +++ emulate.c   2012-01-04 13:28:23.288336520 +1100
> @@ -401,8 +401,8 @@
>         NO_EMULATE(INQUIRY);               /*0x12*/
>         /*NO_EMULATE(RECOVER_BUFFERED_DATA); *//*0x14*/
>         NO_EMULATE(MODE_SELECT);           /*0x15*/ /* st */
> -       /*NO_EMULATE(RESERVE);               *//*0x16*/
> -       /*NO_EMULATE(RELEASE);               *//*0x17*/
> +       NO_EMULATE(RESERVE);               /*0x16*/
> +       NO_EMULATE(RELEASE);               /*0x17*/

These don't appear to be generated anywhere in the Linux tree,
even though several drivers implement their handing. Am I then to
understand that it's Windows which is actually making use of them?
If so, is there a way to know what other commands Linux doesn't
use may still need enabling in the emulation table for Windows' sake?

Jan

>         /*NO_EMULATE(COPY);                  *//*0x18*/
>         NO_EMULATE(ERASE);                 /*0x19*/ /* st */
>         NO_EMULATE(MODE_SENSE);            /*0x1a*/ /* st */
> 
> James
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com 
> http://lists.xensource.com/xen-devel 

Re: set_phys_to_machine not exported?

[James Harper]

> > +       NO_EMULATE(RESERVE);               /*0x16*/
> > +       NO_EMULATE(RELEASE);               /*0x17*/
> 
> These don't appear to be generated anywhere in the Linux tree, even
> though several drivers implement their handing. Am I then to understand
> that it's Windows which is actually making use of them?

Backup Exec under Windows tries to RESERVE my LTO3 drive and refuses to touch it if it can't. I guess if the device reports or is known to support RESERVE/RELEASE then it would be expected to be implemented.

> If so, is there a way to know what other commands Linux doesn't use may
> still need enabling in the emulation table for Windows' sake?
> 

This is stretching my memory a bit, but the very first incantation of pvscsi was at the per-device level. Then someone mentioned that it would be great to be able to map individual LUN's instead of entire devices. This obviously requires all sorts of emulation and remapping of commands which I think is where the EMULATE stuff came from. I can't quite remember but I suspect there might have been some confusion as to what a LUN actually was.

IMHO the per-LUN idea sounds good in theory but would be really hard to implement as you'd potentially need to decode and re-encode every single reported page of data to adjust the LUN numbers, and probably breaks various aspects of the scsi spec (doesn't the spec require that LUN 0 exist?).

So if you are mapping through entire devices I don't know that much really needs emulating and we could just uncomment the lot so they just pass straight through... I wonder if anyone actually needs the per-lun passthrough and even if they think they need it, if it would actually work?

James

Re: set_phys_to_machine not exported?

[Konrad Rzeszutek Wilk]

On Wed, Jan 04, 2012 at 03:44:32AM +0000, James Harper wrote:
> > Okay I have it compiling and loading now (that xenbus init macro obviously
> > isn't for the Debian 3.1.0 kernel I'm running...) but I can't attach a scsi device -
> > it just hangs for a while then says hotplug didn't work.
> > 
> > Any suggestions? Would it be expected to work against the Xen 4.0.4-rc1-pre
> > I'm running now?
> > 
> 
> Loading and detecting properly now (see email about the choice of shell in the vscsi script), and appears to be restoring with the following patch:

OK. Can you post this along with a SOB and an explanation of what this patch
does please?

> 
> --- ../konrad/xen/drivers/scsi/xen-scsiback/emulate.c   2012-01-04 10:51:36.090985303 +1100
> +++ emulate.c   2012-01-04 13:28:23.288336520 +1100
> @@ -401,8 +401,8 @@
>         NO_EMULATE(INQUIRY);               /*0x12*/
>         /*NO_EMULATE(RECOVER_BUFFERED_DATA); *//*0x14*/
>         NO_EMULATE(MODE_SELECT);           /*0x15*/ /* st */
> -       /*NO_EMULATE(RESERVE);               *//*0x16*/
> -       /*NO_EMULATE(RELEASE);               *//*0x17*/
> +       NO_EMULATE(RESERVE);               /*0x16*/
> +       NO_EMULATE(RELEASE);               /*0x17*/
>         /*NO_EMULATE(COPY);                  *//*0x18*/
>         NO_EMULATE(ERASE);                 /*0x19*/ /* st */
>         NO_EMULATE(MODE_SENSE);            /*0x1a*/ /* st */
> 
> James

Re: set_phys_to_machine not exported?

[Konrad Rzeszutek Wilk]

On Wed, Jan 04, 2012 at 01:50:03AM +0000, James Harper wrote:
> > > Or maybe someone else already has scsiback working against 3.x.x?
> > 
> > I do. Try the #testing branch or the #devel/xen-scsi-1.0 (but you should
> > merge it against the 3.1 kernel otherwise it won't compile b/c one argument
> > changed - but you could alter it yourself if you are using the 3.0 tree).
> > 
> > Git tree: git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
> > 
> 
> Okay I have it compiling and loading now (that xenbus init macro obviously isn't for the Debian 3.1.0 kernel I'm running...) but I can't attach a scsi device - it just hangs for a while then says hotplug didn't work.

Oh, that is Jan's one. Yeah that wouldn't work very well.
> 
> Any suggestions? Would it be expected to work against the Xen 4.0.4-rc1-pre I'm running now?

I've been using 4.1. But 4.0.x ought to work..
> 
> Thanks
> 
> James
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel