linux-kernel - Re: [PATCH 0/2] dm mpath: Interface for explicit probing of active paths

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CABgObfavvrMiVKp2boCJ9fp5PwOrhmNaicY1_kJjN_D27af2uw@mail.gmail.com>
Date: Tue, 13 May 2025 17:43:52 +0200
From: Paolo Bonzini <pbonzini@...hat.com>
To: Kevin Wolf <kwolf@...hat.com>
Cc: Christoph Hellwig <hch@...radead.org>, Martin Wilck <mwilck@...e.com>, dm-devel@...ts.linux.dev, 
	Hanna Czenczek <hreitz@...hat.com>, Mikulas Patocka <mpatocka@...hat.com>, snitzer@...nel.org, 
	Ben Marzinski <bmarzins@...hat.com>, 
	"Kernel Mailing List, Linux" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 0/2] dm mpath: Interface for explicit probing of active paths

Il mar 13 mag 2025, 11:29 Kevin Wolf <kwolf@...hat.com> ha scritto:
> QEMU's scsi-block device actually started off using normal I/O for reads
> and writes and using SG_IO only for things that aren't covered by normal
> I/O. But then those had to be changed to SG_IO, too, so that the guest
> would actually see the full SCSI status. Things the commit message
> mentions are unit attention codes and handling RESERVATION CONFLICT
> correctly (which made me unsure above if the more specific interface for
> reservations could actually be used to fully get rid of SG_IO). For more
> context, I'm adding Paolo who actually made that change back then. He
> may remember the concrete bug(s) this fixed.

The original reason to avoid SG_IO for reads and writes was purely
performance (using the host scheduler), but it turned out to be a bad
idea.

RESERVATION CONFLICT indeed was one of the reasons why I moved QEMU
away from SG_IO. It has since been fixed, because these days Linux
uses EBADE for it and likewise there are errno values for some other
statuses or sense codes, but it helps more in general to have the
precise SCSI status and sense data. Having the real status and sense
for example lets QEMU decide which errors to pass to the guest and
which should be handled in the host (for example by pausing the VM).
Some HBAs also have equivalents of Linux's host_status, and passing
that down also makes for more accurate pass through.

Also, specifically for reservations, I also didn't like the idea that
a guest command could be split in multiple host commands and the
reservation conflict would appear in the middle due to a concurrent PR
OUT command. To be honest I don't know how physical disks and
controllers handle that, but I didn't want to make it worse.

Thanks,

Paolo

> So if you want the guest device to behave mostly the same as your host
> device, I don't really see any way around SCSI passthrough and therefore
> SG_IO.
>
> Kevin
>