From: Markus Armbruster <armbru@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: kwolf@redhat.com, Peter Maydell <peter.maydell@linaro.org>,
qemu-devel@nongnu.org, qemu-block@nongnu.org,
"Michael S . Tsirkin" <mst@redhat.com>,
David Gibson <david@gibson.dropbear.id.au>,
Alexander Graf <agraf@suse.de>
Subject: Re: [Qemu-devel] [PATCH 6/6] hw/i386/i386: Stop auto-creating lsi53c895a SCSI HBAs
Date: Tue, 24 Jan 2017 13:56:14 +0100 [thread overview]
Message-ID: <87r33saa6p.fsf@dusky.pond.sub.org> (raw)
In-Reply-To: <3512807d-d04e-50fa-9fcf-d1d5ba8ac350@redhat.com> (Paolo Bonzini's message of "Tue, 24 Jan 2017 12:17:40 +0100")
Cc'ing in sPAPR maintainers...
Paolo Bonzini <pbonzini@redhat.com> writes:
> On 23/01/2017 20:16, Markus Armbruster wrote:
>>> Could we change
>>> those messages to errors
>>
>> Fine with me, but when it comes to arguing for backward compatibility of
>> our byzantine command line, I'm kind of like a lethargic public defender
>> with an overly deep relationship to Bourbon. "Your honor, sure capital
>> punishment is called for? Yes? Okay then."
>>
>> I vaguely recall discussing the topic with Peter (cc'ed). If memory
>> serves, one concern was breaking usage of -device with -drive lacking
>> if=... Works fine (no warning) with machines that don't pick up drives
>> with their default block interface type, i.e. most of them. But PATCH 3
>> changes their default to if=none, so that usage wouldn't actually break.
>
> I think that tips the scale in favor of having errors.
I can add a patch to make it an error when I respin.
>> What would break is -device with -drive if=T, where T is not none and
>> not picked up by the board. Such usage is certainly questionable[*],
>> but it's questionable enough for us to break it?
>>
>>> and then drop PC if=scsi support altogether?
>>
>> Different backward compatibility question: here we break usage of
>> if=scsi with PC machine types. Legacy way to do things, but it's
>> documented in qemu.1. Are we happy to break it?
>
> That usage is wrong after this patch, since it mentions
> qemu-system-i386.
You're right, I better fix that.
> So it's documented, but almost useless and the
> example is not exactly correct. Let's deprecate it in 2.9 and remove in
> 2.10.
Let me spell things out a bit more, to make sure we all agree on what
exactly we want to deprecate.
After this series, -drive if=scsi works for the following machine types:
* magnum pica61 LX SPARCClassic SPARCbook SS-10 SS-20 SS-4 SS-5 SS-600MP
Voyager
The machine has an onboard SCSI HBA, which adopts the drives with
bus=0.. Drives with non-zero bus numbers stay orphaned. This is
exactly how other interface types work.
Except when additional HBAs get cold-plugged somehow, non-zero bus
numbers can work; see below.
* realview-eb realview-eb-mpcore versatileab versatilepb
These create N lsi53c895a SCSI HBAs, where N is the largest value of
bus. If N is too large, machine initialization fails with a "no
slot/function available for lsi53c895a, all in use" error.
This is just like the PC machine types work before this patch.
* pseries-*
Likewise, except create spapr-vscsi SCSI HBAs. Large N make machine
initialization s-l-o-w. I tried to find out whether and how it fails
when N is too large, but I lost patience.
Additionally, -drive if=scsi works when you cold-plug certain SCSI HBAs,
independent of machine type. The HBAs get assigned bus numbers in order
of creation, and adopt the drives with their bus number. Drives with
bus numbers not so assigned stay orphaned.
* SCSI HBAs supporting if=scsi: am53c974 dc390 esp lsi53c810 lsi53c895a
megasas megasas-gen2 mptsas1068 spapr-vscsi virtio-scsi-device
* Not supporting it: pvscsi usb-storage usb-bot usb-uas
So, what do we want to deprecate?
I think the onboard SCSI HBA adopting if=scsi drives should stay,
because it matches what we do for other interface types. Unless we
wanted to deprecate interface types other than none entirely.
What about realview and versatile auto-creating lsi53c895a?
What about pseries auto-creating spapr-vscsi?
What about cold-plug of HBAs auto-creating SCSI devices? You proposed
deprecating it for PC types, but it's currently independent of the
machine type. Deprecate it for all types? If not, add a flag to
MachineClass so we can deprecate it just for PC types?
next prev parent reply other threads:[~2017-01-24 12:56 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-23 9:48 [Qemu-devel] [PATCH 0/6] More sensible default for -drive interface type Markus Armbruster
2017-01-23 9:48 ` [Qemu-devel] [PATCH 1/6] hw: Default -drive to if=ide explicitly where it works Markus Armbruster
2017-01-23 9:48 ` [Qemu-arm] [PATCH 2/6] hw/arm/cubieboard hw/arm/xlnx-ep108: Fix units_per_default_bus Markus Armbruster
2017-01-23 9:48 ` [Qemu-devel] " Markus Armbruster
2017-01-23 9:48 ` [Qemu-arm] [PATCH 3/6] hw: Default -drive to if=none instead of ide when ide cannot work Markus Armbruster
2017-01-23 9:48 ` Markus Armbruster
2017-01-23 9:48 ` [Qemu-devel] " Markus Armbruster
2017-01-23 12:24 ` Artyom Tarasenko
2017-01-23 9:48 ` [Qemu-arm] [PATCH 4/6] hw: Default -drive to if=none instead of scsi when scsi " Markus Armbruster
2017-01-23 9:48 ` [Qemu-devel] " Markus Armbruster
2017-01-23 9:48 ` [Qemu-arm] [PATCH 5/6] hw/arm/highbank: Default -drive to if=ide instead of if=scsi Markus Armbruster
2017-01-23 9:48 ` [Qemu-devel] " Markus Armbruster
2017-01-23 9:48 ` [Qemu-devel] [PATCH 6/6] hw/i386/i386: Stop auto-creating lsi53c895a SCSI HBAs Markus Armbruster
2017-01-23 16:48 ` Paolo Bonzini
2017-01-23 19:16 ` Markus Armbruster
2017-01-24 11:17 ` Paolo Bonzini
2017-01-24 12:56 ` Markus Armbruster [this message]
2017-01-24 13:01 ` Paolo Bonzini
2017-01-24 17:20 ` Markus Armbruster
2017-01-24 17:24 ` Peter Maydell
2017-01-24 17:40 ` Paolo Bonzini
2017-01-24 17:58 ` Peter Maydell
2017-01-24 18:43 ` Markus Armbruster
2017-01-25 16:45 ` Markus Armbruster
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87r33saa6p.fsf@dusky.pond.sub.org \
--to=armbru@redhat.com \
--cc=agraf@suse.de \
--cc=david@gibson.dropbear.id.au \
--cc=kwolf@redhat.com \
--cc=mst@redhat.com \
--cc=pbonzini@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.