From: Markus Armbruster <armbru@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: kwolf@redhat.com, Peter Maydell <peter.maydell@linaro.org>,
qemu-block@nongnu.org, "Michael S . Tsirkin" <mst@redhat.com>,
qemu-devel@nongnu.org, Alexander Graf <agraf@suse.de>,
David Gibson <david@gibson.dropbear.id.au>
Subject: Re: [Qemu-devel] [PATCH 6/6] hw/i386/i386: Stop auto-creating lsi53c895a SCSI HBAs
Date: Tue, 24 Jan 2017 18:20:23 +0100 [thread overview]
Message-ID: <87fuk82x48.fsf@dusky.pond.sub.org> (raw)
In-Reply-To: <4cd45561-60e9-2cd2-e317-880ba9eb2f86@redhat.com> (Paolo Bonzini's message of "Tue, 24 Jan 2017 14:01:38 +0100")
Paolo Bonzini <pbonzini@redhat.com> writes:
> On 24/01/2017 13:56, Markus Armbruster wrote:
>> 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.
>
> Yes, of course.
>
>> What about realview and versatile auto-creating lsi53c895a?
>
> That should go.
Peter, do you agree?
>> What about pseries auto-creating spapr-vscsi?
>
> That should stay I think. The discriminant being that spapr-vscsi
> devices actually are likely to have drivers in the guests.
Okay.
>> 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?
>
> I need --verbose for this, sorry.
No problem! Let me explain how SCSI auto-creation works, and how it
differs from the other interface types. Actually, let me start with the
other ones.
When a machine supports some if=T, T other than scsi or none, its
initialization code retrieves the drives of interface type T with
supported bus and unit numbers, creates suitable frontends, and wires
them up. We commonly don't bother to check whether there are drives
with unsupported bus and unit numbers.
Example: within terrier_init(), spitz_microdrive_attach() runs and calls
drive_get(IF_IDE, 0, 0). If it gets something back, it creates a
dscm1xxxx device model.
Example: pc_q35_init() calls ide_drive_get() to retrieve the IF_IDE
drives with bus=0..5, unit=0. It creates ide-cd or ide-hd device models
for the ones it gets back.
Example: within machvirt_init(), create_one_flash() runs two times and
calls drive_get_next(IF_PFLASH) to retrieve bus=0, unit=0..1. It
creates cfi.pflash01 device models unconditionally, and backs them with
the drives it gets back, if any. I hate the drive_get_next() interface,
because it uses execution order to encode unit numbers.
if=scsi works differently.
SCSI HBA device models commonly call scsi_bus_legacy_handle_cmdline()
during realize() for their SCSI bus(es). A SCSI bus gets assigned a bus
number on creation, counting up from zero. The SCSI HBA device model
declares the maximum unit number it supports (SCSIBusInfo member
max_target). scsi_bus_legacy_handle_cmdline() calls drive_get(IF_SCSI,
bus->busnr, unit) to retrieve the IF_SCSI drives, and creates
scsi-generic or scsi-disk device models.
When a machine has an onboard SCSI HBA whose realize() calls
scsi_bus_legacy_handle_cmdline(), then machine initialization code
doesn't have to do anything to support if=scsi.
Example: mips_jazz_init() simply calls esp_init(), which then adopts the
if=scsi,bus=0,unit=0..7. Note that blockdev.c rejects unit>7.
Example: sun4m_hw_init() does the same, but also checks for and rejects
drives with bus>0. This check becomes redundant when we make orphaned
drives an error.
A few machines don't have onboard SCSI HBA, but their initialization
code creates N default ones, where N is the largest bus number of any
if=scsi drive. Again, nothing else needs to be done to create the
actual SCSI devices.
Example: before my patch, PC machine initialization calls
pc_pci_device_init(), which creates lsi53c895a device models in a loop.
If a machine doesn't create default SCSI HBAs, the user can do it
himself with -device, and as long as the HBA's realize() calls
scsi_bus_legacy_handle_cmdline(), if=scsi works.
Example: after my patch, PC machine initialization doesn't create SCSI
HBAs. Options "-drive media=cdrom,if=scsi,bus=1 -device
megasas,id=scsi0 -device megasas,id=scsi1" create two megasas device
models, and one scsi-disk device model plugged into the second one.
My question is: do we want to deprecate "-device of a SCSI HBA
auto-creates SCSI devices for the HBA's bus number(s), with unit numbers
up to max_target"?
For all machine types, or just for PC?
If for all machine types, we need work a little harder for if=scsi in
machine initialization, exactly like we do for the other interface
types.
Clear as mud now?
next prev parent reply other threads:[~2017-01-24 17:20 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
2017-01-24 13:01 ` Paolo Bonzini
2017-01-24 17:20 ` Markus Armbruster [this message]
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=87fuk82x48.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.