All of lore.kernel.org
 help / color / mirror / Atom feed
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?

  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.