| Message ID | 1441761736-32030-1-git-send-email-david@gibson.dropbear.id.au |
|---|---|
| State | New |
| Headers | show |
This series failed automatic testing, see attachment for the full log and below for the tail. (If you see a false alarm or anything unclear, please reply and help us improve!) Started by an SCM change Building in workspace /var/lib/jenkins/jobs/qemu/workspace > git rev-parse --is-inside-work-tree # timeout=10 Fetching changes from the remote Git repository > git config remote.origin.url https://github.com/famz/qemu-patchew # timeout=10 Fetching upstream changes from https://github.com/famz/qemu-patchew > git --version # timeout=10 > git -c core.askpass=true fetch --tags --progress https://github.com/famz/qemu-patchew +refs/heads/*:refs/remotes/origin/* Seen 442 remote branches Checking out Revision 6f7c15d485f7f8daf1a3b39df03415b676cd721e (origin/<1441761736-32030-1-git-send-email-david@gibson.dropbear.id.au>) > git config core.sparsecheckout # timeout=10 > git checkout -f 6f7c15d485f7f8daf1a3b39df03415b676cd721e Using 'Changelog to branch' strategy. No emails were triggered. [workspace] $ /bin/sh -xe /tmp/hudson5690229581019177586.sh + git log --reverse --oneline origin/master.. 6f7c15d spapr: Reduce advertised max LUNs for spapr_vscsi + sudo docker run -t --net=none --rm -v /var/lib/jenkins/jobs/qemu/workspace:/tmp/qemu-build --name patchew-tester patchew-tester /usr/local/bin/qemu-build.sh /tmp/qemu-build Error response from daemon: Conflict. The name "patchew-tester" is already in use by container 4f39610cd778. You have to delete (or rename) that container to be able to reuse that name. Build step 'Execute shell' marked build as failure Email was triggered for: Failure - Any Sending email for trigger: Failure - Any
On Wed, 09/09 11:39, Patchew Jenkins wrote: > This series failed automatic testing, see attachment for the full log and below for the tail. > (If you see a false alarm or anything unclear, please reply and help us improve!) > > Started by an SCM change > Building in workspace /var/lib/jenkins/jobs/qemu/workspace > > git rev-parse --is-inside-work-tree # timeout=10 > Fetching changes from the remote Git repository > > git config remote.origin.url https://github.com/famz/qemu-patchew # timeout=10 > Fetching upstream changes from https://github.com/famz/qemu-patchew > > git --version # timeout=10 > > git -c core.askpass=true fetch --tags --progress https://github.com/famz/qemu-patchew +refs/heads/*:refs/remotes/origin/* > Seen 442 remote branches > Checking out Revision 6f7c15d485f7f8daf1a3b39df03415b676cd721e (origin/<1441761736-32030-1-git-send-email-david@gibson.dropbear.id.au>) > > git config core.sparsecheckout # timeout=10 > > git checkout -f 6f7c15d485f7f8daf1a3b39df03415b676cd721e > Using 'Changelog to branch' strategy. > No emails were triggered. > [workspace] $ /bin/sh -xe /tmp/hudson5690229581019177586.sh > + git log --reverse --oneline origin/master.. > 6f7c15d spapr: Reduce advertised max LUNs for spapr_vscsi > + sudo docker run -t --net=none --rm -v /var/lib/jenkins/jobs/qemu/workspace:/tmp/qemu-build --name patchew-tester patchew-tester /usr/local/bin/qemu-build.sh /tmp/qemu-build > Error response from daemon: Conflict. The name "patchew-tester" is already in use by container 4f39610cd778. You have to delete (or rename) that container to be able to reuse that name. Never mind, the build machine has a problem spawning tester instance. It's being fixed. Fam
On 09/09/15 03:22, David Gibson wrote: > The implementation of the PAPR paravirtual SCSI adapter currently > allows up to 32 LUNs (max_lun == 31). However the adapter isn't really > designed to support lots of devices - the PowerVM implementation only > ever puts one disk per vSCSI controller. Do you know how many LUNs are advertised by PowerVM? > More specifically, the Linux guest side vscsi driver (the only one we > really care about) is hardcoded to allow a maximum of 8 LUNs. So what about changing the vscsi driver in Linux instead to support more LUNs? Thomas
On Wed, Sep 09, 2015 at 08:25:34AM +0200, Thomas Huth wrote: > On 09/09/15 03:22, David Gibson wrote: > > The implementation of the PAPR paravirtual SCSI adapter currently > > allows up to 32 LUNs (max_lun == 31). However the adapter isn't really > > designed to support lots of devices - the PowerVM implementation only > > ever puts one disk per vSCSI controller. > > Do you know how many LUNs are advertised by PowerVM? Well, what do you mean by "advertised". AFAIK from the point of view of the guest, the number of LUNs is advertised per-target, not per controller. When I say "advertised" here, I'm meaning what the controller advertises to the qemu SCSI core, and thereby to the option parsing code. > > More specifically, the Linux guest side vscsi driver (the only one we > > really care about) is hardcoded to allow a maximum of 8 LUNs. > > So what about changing the vscsi driver in Linux instead to support more > LUNs? Doesn't help for existing guests. Basically what I'm trying to achieve is for qemu to reject up-front configurations that are unlikely to actually work in the guest.
On 09/09/15 09:19, David Gibson wrote: > On Wed, Sep 09, 2015 at 08:25:34AM +0200, Thomas Huth wrote: >> On 09/09/15 03:22, David Gibson wrote: >>> The implementation of the PAPR paravirtual SCSI adapter currently >>> allows up to 32 LUNs (max_lun == 31). However the adapter isn't really >>> designed to support lots of devices - the PowerVM implementation only >>> ever puts one disk per vSCSI controller. >> >> Do you know how many LUNs are advertised by PowerVM? > > Well, what do you mean by "advertised". AFAIK from the point of view > of the guest, the number of LUNs is advertised per-target, not per > controller. I mean, what's the highest LUN number that can be seen by a guest under PowerVM? Is it always using only one LUN per controller, or is there a way to change the amount of LUNs? (Sorry if I ask dumb questions ... I do not have much experience with PowerVM yet) >>> More specifically, the Linux guest side vscsi driver (the only one we >>> really care about) is hardcoded to allow a maximum of 8 LUNs. >> >> So what about changing the vscsi driver in Linux instead to support more >> LUNs? > > Doesn't help for existing guests. Basically what I'm trying to > achieve is for qemu to reject up-front configurations that are > unlikely to actually work in the guest. I just wonder whether it makes sense to change the guest instead. In the future, if we ever have guests that support more LUNs than 8 (maybe some non-Linux guests like FreeBSD?), we've got to change QEMU back again... OTOH, since this is just a one-line fix, it's likely ok to limit this to 8 now - it's easy to revert if we ever need to, so I'm fine with that change, I just wanted to discuss the other possibilites. Thomas
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 09/09/2015 09:29, Thomas Huth wrote: >> Doesn't help for existing guests. Basically what I'm trying to >> achieve is for qemu to reject up-front configurations that are >> unlikely to actually work in the guest. > > I just wonder whether it makes sense to change the guest instead. I agree; perhaps it's a one-liner. The patch is simple, but I wonder if it is really a case of "if it hurts, don't do it". Paolo -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJV8CGFAAoJEL/70l94x66DhAYH/jlUe5xCT6YS5uiYQukrPrVC rjJAzqLUUdKh62GHR62wKkylVds9YtFYlkLGLbaXUDO0uVlgvyr4BrPZ8xeKcfPg 3yMtoFIZr3rLdsY1Bbjk/ReyY5uU9fRvU8WHCSXeCsWqMUmFpMm7HdnbCdh+3mCW bNUUuBorxCQMI+2ra8FNLCc/wMmw4M4M0uUtcGYOwxUkfcjPbQyqWFOtbj3Q2Mo9 CrGjW8u48ZFgiPMtHPI+hetZQBrMltoqokCl0Ca2DuWRK8pmSERDS7NqlNfzWDiL /dyKkznPuWB4jox/NyeMpXmPMSgrwcSg3YvBv8My3EOiIcPp8b+nGCTLCkmbjzw= =3vF9 -----END PGP SIGNATURE-----
On Wed, Sep 09, 2015 at 09:29:18AM +0200, Thomas Huth wrote: > On 09/09/15 09:19, David Gibson wrote: > > On Wed, Sep 09, 2015 at 08:25:34AM +0200, Thomas Huth wrote: > >> On 09/09/15 03:22, David Gibson wrote: > >>> The implementation of the PAPR paravirtual SCSI adapter currently > >>> allows up to 32 LUNs (max_lun == 31). However the adapter isn't really > >>> designed to support lots of devices - the PowerVM implementation only > >>> ever puts one disk per vSCSI controller. > >> > >> Do you know how many LUNs are advertised by PowerVM? > > > > Well, what do you mean by "advertised". AFAIK from the point of view > > of the guest, the number of LUNs is advertised per-target, not per > > controller. > > I mean, what's the highest LUN number that can be seen by a guest under > PowerVM? Is it always using only one LUN per controller, or is there a > way to change the amount of LUNs? (Sorry if I ask dumb questions ... I > do not have much experience with PowerVM yet) Um.. I'm not sure, I have very little experience with PowerVM too. I think with PowerVM it's usually real SCSI devices being passed through, rather than disk images, so presumably the SCSI target itself reports however many LUNs it has. There may be a limitation in PowerVM, or in the AIX VIO server I think it typically backends onto, but I don't know what it is. Since that limit has been in the guest side driver forever, presumbly no-one has hit LUNs > 8 in practice. > >>> More specifically, the Linux guest side vscsi driver (the only one we > >>> really care about) is hardcoded to allow a maximum of 8 LUNs. > >> > >> So what about changing the vscsi driver in Linux instead to support more > >> LUNs? > > > > Doesn't help for existing guests. Basically what I'm trying to > > achieve is for qemu to reject up-front configurations that are > > unlikely to actually work in the guest. > > I just wonder whether it makes sense to change the guest instead. In the > future, if we ever have guests that support more LUNs than 8 (maybe some > non-Linux guests like FreeBSD?), we've got to change QEMU back again... > OTOH, since this is just a one-line fix, it's likely ok to limit this to > 8 now - it's easy to revert if we ever need to, so I'm fine with that > change, I just wanted to discuss the other possibilites. Remember that the spapr-vscsi device exists pretty much entirely to make transition simpler for existing PowerVM guests. New guests (Linux or otherwise) intended to run under KVM should be using virtio-blk or virtio-scsi.
On 10/09/15 03:24, David Gibson wrote: > On Wed, Sep 09, 2015 at 09:29:18AM +0200, Thomas Huth wrote: >> On 09/09/15 09:19, David Gibson wrote: >>> On Wed, Sep 09, 2015 at 08:25:34AM +0200, Thomas Huth wrote: >>>> On 09/09/15 03:22, David Gibson wrote: >>>>> The implementation of the PAPR paravirtual SCSI adapter currently >>>>> allows up to 32 LUNs (max_lun == 31). However the adapter isn't really >>>>> designed to support lots of devices - the PowerVM implementation only >>>>> ever puts one disk per vSCSI controller. >>>> >>>> Do you know how many LUNs are advertised by PowerVM? >>> >>> Well, what do you mean by "advertised". AFAIK from the point of view >>> of the guest, the number of LUNs is advertised per-target, not per >>> controller. >> >> I mean, what's the highest LUN number that can be seen by a guest under >> PowerVM? Is it always using only one LUN per controller, or is there a >> way to change the amount of LUNs? (Sorry if I ask dumb questions ... I >> do not have much experience with PowerVM yet) > > Um.. I'm not sure, I have very little experience with PowerVM too. I > think with PowerVM it's usually real SCSI devices being passed > through, rather than disk images, so presumably the SCSI target itself > reports however many LUNs it has. There may be a limitation in > PowerVM, or in the AIX VIO server I think it typically backends onto, > but I don't know what it is. > > Since that limit has been in the guest side driver forever, presumbly > no-one has hit LUNs > 8 in practice. > >>>>> More specifically, the Linux guest side vscsi driver (the only one we >>>>> really care about) is hardcoded to allow a maximum of 8 LUNs. >>>> >>>> So what about changing the vscsi driver in Linux instead to support more >>>> LUNs? >>> >>> Doesn't help for existing guests. Basically what I'm trying to >>> achieve is for qemu to reject up-front configurations that are >>> unlikely to actually work in the guest. >> >> I just wonder whether it makes sense to change the guest instead. In the >> future, if we ever have guests that support more LUNs than 8 (maybe some >> non-Linux guests like FreeBSD?), we've got to change QEMU back again... >> OTOH, since this is just a one-line fix, it's likely ok to limit this to >> 8 now - it's easy to revert if we ever need to, so I'm fine with that >> change, I just wanted to discuss the other possibilites. > > Remember that the spapr-vscsi device exists pretty much entirely to > make transition simpler for existing PowerVM guests. New guests > (Linux or otherwise) intended to run under KVM should be using > virtio-blk or virtio-scsi. FWIW, I had a quick look at FreeBSD sources here: https://svnweb.freebsd.org/base/stable/10/sys/powerpc/pseries/phyp_vscsi.c?revision=259204&view=markup ... and as far as I can see, they do not limit the LUNs to 8. (I only spotted a "cpi->max_lun = ~(lun_id_t)(0);" in there). So there indeed might also be older guests that support more than 8 LUNs. Thomas
On Thu, Sep 10, 2015 at 08:12:47AM +0200, Thomas Huth wrote: > On 10/09/15 03:24, David Gibson wrote: > > On Wed, Sep 09, 2015 at 09:29:18AM +0200, Thomas Huth wrote: > >> On 09/09/15 09:19, David Gibson wrote: > >>> On Wed, Sep 09, 2015 at 08:25:34AM +0200, Thomas Huth wrote: > >>>> On 09/09/15 03:22, David Gibson wrote: > >>>>> The implementation of the PAPR paravirtual SCSI adapter currently > >>>>> allows up to 32 LUNs (max_lun == 31). However the adapter isn't really > >>>>> designed to support lots of devices - the PowerVM implementation only > >>>>> ever puts one disk per vSCSI controller. > >>>> > >>>> Do you know how many LUNs are advertised by PowerVM? > >>> > >>> Well, what do you mean by "advertised". AFAIK from the point of view > >>> of the guest, the number of LUNs is advertised per-target, not per > >>> controller. > >> > >> I mean, what's the highest LUN number that can be seen by a guest under > >> PowerVM? Is it always using only one LUN per controller, or is there a > >> way to change the amount of LUNs? (Sorry if I ask dumb questions ... I > >> do not have much experience with PowerVM yet) > > > > Um.. I'm not sure, I have very little experience with PowerVM too. I > > think with PowerVM it's usually real SCSI devices being passed > > through, rather than disk images, so presumably the SCSI target itself > > reports however many LUNs it has. There may be a limitation in > > PowerVM, or in the AIX VIO server I think it typically backends onto, > > but I don't know what it is. > > > > Since that limit has been in the guest side driver forever, presumbly > > no-one has hit LUNs > 8 in practice. > > > >>>>> More specifically, the Linux guest side vscsi driver (the only one we > >>>>> really care about) is hardcoded to allow a maximum of 8 LUNs. > >>>> > >>>> So what about changing the vscsi driver in Linux instead to support more > >>>> LUNs? > >>> > >>> Doesn't help for existing guests. Basically what I'm trying to > >>> achieve is for qemu to reject up-front configurations that are > >>> unlikely to actually work in the guest. > >> > >> I just wonder whether it makes sense to change the guest instead. In the > >> future, if we ever have guests that support more LUNs than 8 (maybe some > >> non-Linux guests like FreeBSD?), we've got to change QEMU back again... > >> OTOH, since this is just a one-line fix, it's likely ok to limit this to > >> 8 now - it's easy to revert if we ever need to, so I'm fine with that > >> change, I just wanted to discuss the other possibilites. > > > > Remember that the spapr-vscsi device exists pretty much entirely to > > make transition simpler for existing PowerVM guests. New guests > > (Linux or otherwise) intended to run under KVM should be using > > virtio-blk or virtio-scsi. > > FWIW, I had a quick look at FreeBSD sources here: > > https://svnweb.freebsd.org/base/stable/10/sys/powerpc/pseries/phyp_vscsi.c?revision=259204&view=markup > > ... and as far as I can see, they do not limit the LUNs to 8. > (I only spotted a "cpi->max_lun = ~(lun_id_t)(0);" in there). > So there indeed might also be older guests that support more than 8 LUNs. Fair enough, you've convinced me. I still think it makes sense downstream only, though.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/09/2015 08:48, David Gibson wrote: > On Thu, Sep 10, 2015 at 08:12:47AM +0200, Thomas Huth wrote: >> On 10/09/15 03:24, David Gibson wrote: >>> On Wed, Sep 09, 2015 at 09:29:18AM +0200, Thomas Huth wrote: >>>> On 09/09/15 09:19, David Gibson wrote: >>>>> On Wed, Sep 09, 2015 at 08:25:34AM +0200, Thomas Huth >>>>> wrote: >>>>>> On 09/09/15 03:22, David Gibson wrote: >>>>>>> The implementation of the PAPR paravirtual SCSI adapter >>>>>>> currently allows up to 32 LUNs (max_lun == 31). >>>>>>> However the adapter isn't really designed to support >>>>>>> lots of devices - the PowerVM implementation only ever >>>>>>> puts one disk per vSCSI controller. >>>>>> >>>>>> Do you know how many LUNs are advertised by PowerVM? >>>>> >>>>> Well, what do you mean by "advertised". AFAIK from the >>>>> point of view of the guest, the number of LUNs is >>>>> advertised per-target, not per controller. >>>> >>>> I mean, what's the highest LUN number that can be seen by a >>>> guest under PowerVM? Is it always using only one LUN per >>>> controller, or is there a way to change the amount of LUNs? >>>> (Sorry if I ask dumb questions ... I do not have much >>>> experience with PowerVM yet) >>> >>> Um.. I'm not sure, I have very little experience with PowerVM >>> too. I think with PowerVM it's usually real SCSI devices being >>> passed through, rather than disk images, so presumably the SCSI >>> target itself reports however many LUNs it has. There may be a >>> limitation in PowerVM, or in the AIX VIO server I think it >>> typically backends onto, but I don't know what it is. >>> >>> Since that limit has been in the guest side driver forever, >>> presumbly no-one has hit LUNs > 8 in practice. >>> >>>>>>> More specifically, the Linux guest side vscsi driver >>>>>>> (the only one we really care about) is hardcoded to >>>>>>> allow a maximum of 8 LUNs. >>>>>> >>>>>> So what about changing the vscsi driver in Linux instead >>>>>> to support more LUNs? >>>>> >>>>> Doesn't help for existing guests. Basically what I'm >>>>> trying to achieve is for qemu to reject up-front >>>>> configurations that are unlikely to actually work in the >>>>> guest. >>>> >>>> I just wonder whether it makes sense to change the guest >>>> instead. In the future, if we ever have guests that support >>>> more LUNs than 8 (maybe some non-Linux guests like FreeBSD?), >>>> we've got to change QEMU back again... OTOH, since this is >>>> just a one-line fix, it's likely ok to limit this to 8 now - >>>> it's easy to revert if we ever need to, so I'm fine with >>>> that change, I just wanted to discuss the other >>>> possibilites. >>> >>> Remember that the spapr-vscsi device exists pretty much >>> entirely to make transition simpler for existing PowerVM >>> guests. New guests (Linux or otherwise) intended to run under >>> KVM should be using virtio-blk or virtio-scsi. >> >> FWIW, I had a quick look at FreeBSD sources here: >> >> https://svnweb.freebsd.org/base/stable/10/sys/powerpc/pseries/phyp_vs csi.c?revision=259204&view=markup >> >> >> ... and as far as I can see, they do not limit the LUNs to 8. >> (I only spotted a "cpi->max_lun = ~(lun_id_t)(0);" in there). So >> there indeed might also be older guests that support more than 8 >> LUNs. > > Fair enough, you've convinced me. > > I still think it makes sense downstream only, though. > I agree with that. I've sent a patch series to the kernel ML to display current limits and to allow to change max_lun. Laurent -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlXxXB0ACgkQNKT2yavzbFPcNwCg8nyxLkZWx4MInpRTi2U98u3e YgsAoNUsTQBAUXkdS5Cu1u5HINh8FEa8 =AaRF -----END PGP SIGNATURE-----
diff --git a/hw/scsi/spapr_vscsi.c b/hw/scsi/spapr_vscsi.c index 891424f..bb1dd6f 100644 --- a/hw/scsi/spapr_vscsi.c +++ b/hw/scsi/spapr_vscsi.c @@ -1192,7 +1192,7 @@ static const struct SCSIBusInfo vscsi_scsi_info = { .tcq = true, .max_channel = 7, /* logical unit addressing format */ .max_target = 63, - .max_lun = 31, + .max_lun = 7, .transfer_data = vscsi_transfer_data, .complete = vscsi_command_complete,
The implementation of the PAPR paravirtual SCSI adapter currently allows up to 32 LUNs (max_lun == 31). However the adapter isn't really designed to support lots of devices - the PowerVM implementation only ever puts one disk per vSCSI controller. More specifically, the Linux guest side vscsi driver (the only one we really care about) is hardcoded to allow a maximum of 8 LUNs. So, reduce the number of LUNs on the qemu side to 8, so we don't falsely advertise that more LUNs can work. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> --- hw/scsi/spapr_vscsi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)