[Qemu-devel] [PATCH] spapr: Reduce advertised max LUNs for spapr_vscsi

[Qemu-devel] [PATCH] spapr: Reduce advertised max LUNs for spapr_vscsi

[David Gibson]

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

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

[Qemu-devel] [PATCHEW] Series failed testing

[Patchew Jenkins]

[-- Attachment #1: Type: text/plain, Size: 1655 bytes --]

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


[-- Attachment #2: build.log --]
[-- Type: application/octet-stream, Size: 1533 bytes --]

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
Sending email to: famz@redhat.com qemu-devel@nongnu.org

Re: [Qemu-devel] [PATCHEW] Series failed testing

[Fam Zheng]

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

Re: [Qemu-devel] [PATCH] spapr: Reduce advertised max LUNs for spapr_vscsi

[Thomas Huth]

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

Re: [Qemu-devel] [PATCH] spapr: Reduce advertised max LUNs for spapr_vscsi

[David Gibson]

[-- Attachment #1: Type: text/plain, Size: 1329 bytes --]

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.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: [Qemu-devel] [PATCH] spapr: Reduce advertised max LUNs for spapr_vscsi

[Thomas Huth]

[-- Attachment #1: Type: text/plain, Size: 1761 bytes --]

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



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [Qemu-devel] [PATCH] spapr: Reduce advertised max LUNs for spapr_vscsi

[Paolo Bonzini]

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

Re: [Qemu-devel] [PATCH] spapr: Reduce advertised max LUNs for spapr_vscsi

[David Gibson]

[-- Attachment #1: Type: text/plain, Size: 2787 bytes --]

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.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: [Qemu-devel] [PATCH] spapr: Reduce advertised max LUNs for spapr_vscsi

[Thomas Huth]

[-- Attachment #1: Type: text/plain, Size: 3051 bytes --]

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



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [Qemu-devel] [PATCH] spapr: Reduce advertised max LUNs for spapr_vscsi

[David Gibson]

[-- Attachment #1: Type: text/plain, Size: 3508 bytes --]

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.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: [Qemu-devel] [PATCH] spapr: Reduce advertised max LUNs for spapr_vscsi

[Laurent Vivier]

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