On Wed, Mar 18, 2026 at 04:58:25PM +0000, Daniel P. Berrangé wrote: > On Wed, Mar 18, 2026 at 04:54:45PM +0000, Daniel P. Berrangé wrote: > > On Wed, Mar 18, 2026 at 04:29:51PM +0000, Pedro Falcato wrote: > > > According to the ATA Command Set specification (and the SATA specification > > > too), SATA drives are supposed to set word 93 (which for PATA holds > > > hardware > > > reset results) to 0. As such, clear it when ncq_queues > 0 (which is only > > > true > > > for SATA drives). > > > > > > Doing so fixes a quirk in Linux where it thinks the AHCI QEMU drive is > > > PATA > > > over a SATA bridge, and thus limits maximum transfer sizes for individual > > > IOs > > > with a: > > > [ 1.632121] ata1.00: applying bridge limits > > > > > > While at it, bump the device's firmware revision for IDENTIFY. This makes > > > it > > > so Linux can avoid enabling a quirk for fixed QEMU releases. > > > > > > Link: > > > https://lore.kernel.org/linux-ide/[email protected]/ > > > Cc: [email protected] > > > Suggsted-by: Niklas Cassel <[email protected]> > > > Signed-off-by: Pedro Falcato <[email protected]> > > > --- > > > Note: I understand the version bump is vaguely controversial (particularly > > > exposing the QEMU version in the string) but I don't have a much better > > > idea. Logically, bumping it to 11.0 for stable releases doesn't make much > > > sense. > > > > Bumping the version string changes guest ABI, so such a change should > > normally be tied to a new machine type version, not unconditionally > > changed. That would also in turn make it unsuitable for QEMU stable > > release branches which don't take changes which affect machine type > > ABI. > >
I don't understand (I don't usually hack on QEMU). What do you mean with guest ABI and machine type ABI? > > IMHO Linux should just assume any actively maintained distro that > > cares about this problem will fix their QEMU releases and not try > > to add a version specific workaround. The compromise we reached in Linux was to apply this quirk workaround *only* for 2.5+ versioned firmware revision. Many stable distributions out there (e.g debian, enterprise) would not see this QEMU fix for years. Particularly if it is not QEMU stable material. > > Having said that, possibly the functional fix itself might need to > be tied to the machine type too, given that it is triggering a > behavioural change in the emulation and guest driver ? If that's There is no behavioural change on QEMU's side. QEMU has always been able to perform IO up to the controller interface's limit. Yes, it does change Linux's behavior. > the case, then the version could be changed at the same time. I was skimming through https://www.qemu.org/docs/master/devel/migration/compatibility.html. So tying this to the machine type would mean (if I am not mistaken, but do correct me if I'm wrong) setting the device version (or an equivalent device property) in hw_compat_10_2 (in our case, since it's the last QEMU release). Is this correct? I am OK with this idea, especially since the quirk patch is already propagating through Linux upstream stable branches. So it should be ok to just apply this permanent fix for the latest QEMU release. My only other concern would be how to expose firmware versions in a proper way. >From my reading, it is clear that QEMU does not want to expose versions to guests. Perhaps some versioning scheme like "2.6.<revision>" or maybe even "2.5+<revision>" could be maximally backwards compatible whilst not exposing too much to the guest. -- Pedro
