From: Peter Maydell <peter.maydell@linaro.org>
To: Hanna Czenczek <hreitz@redhat.com>
Cc: Kevin Wolf <kwolf@redhat.com>,
qemu-block@nongnu.org, qemu-devel@nongnu.org
Subject: Re: [PATCH for-9.0?] usb-storage: Fix BlockConf defaults
Date: Tue, 16 Apr 2024 13:11:19 +0100 [thread overview]
Message-ID: <CAFEAcA-k4p3dW8rmY-hXwFt-MtRgpjMVN2NOtap5AwvbC9cckA@mail.gmail.com> (raw)
In-Reply-To: <95399e0a-9ec6-4751-a4a3-83e44dedf8a4@redhat.com>
On Tue, 16 Apr 2024 at 10:26, Hanna Czenczek <hreitz@redhat.com> wrote:
>
> On 12.04.24 16:42, Kevin Wolf wrote:
> > Commit 30896374 started to pass the full BlockConf from usb-storage to
> > scsi-disk, while previously only a few select properties would be
> > forwarded. This enables the user to set more properties, e.g. the block
> > size, that are actually taking effect.
> >
> > However, now the calls to blkconf_apply_backend_options() and
> > blkconf_blocksizes() in usb_msd_storage_realize() that modify some of
> > these properties take effect, too, instead of being silently ignored.
> > This means at least that the block sizes get an unconditional default of
> > 512 bytes before the configuration is passed to scsi-disk.
> >
> > Before commit 30896374, the property wouldn't be set for scsi-disk and
> > therefore the device dependent defaults would apply - 512 for scsi-hd,
> > but 2048 for scsi-cd. The latter default has now become 512, too, which
> > makes at least Windows 11 installation fail when installing from
> > usb-storage.
> >
> > Fix this by simply not calling these functions any more in usb-storage
> > and passing BlockConf on unmodified (except for the BlockBackend). The
> > same functions are called by the SCSI code anyway and it sets the right
> > defaults for the actual media type.
> >
> > Fixes: 308963746169 ('scsi: Don't ignore most usb-storage properties')
> > Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2260
> > Reported-by: Jonas Svensson
> > Signed-off-by: Kevin Wolf <kwolf@redhat.com>
> > ---
> > Considering this a candidate for 9.0 given that we're already having an
> > rc4, it's a regression from 8.2 and breaks installing Windows from USB
> >
> > hw/usb/dev-storage-classic.c | 9 ---------
> > 1 file changed, 9 deletions(-)
>
> Reviewed-by: Hanna Czenczek <hreitz@redhat.com>
Thanks; I've now applied this to git directly (following
discussion with Kevin on IRC.)
-- PMM
prev parent reply other threads:[~2024-04-16 12:12 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-12 14:42 [PATCH for-9.0?] usb-storage: Fix BlockConf defaults Kevin Wolf
2024-04-16 9:26 ` Hanna Czenczek
2024-04-16 12:11 ` Peter Maydell [this message]
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=CAFEAcA-k4p3dW8rmY-hXwFt-MtRgpjMVN2NOtap5AwvbC9cckA@mail.gmail.com \
--to=peter.maydell@linaro.org \
--cc=hreitz@redhat.com \
--cc=kwolf@redhat.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).