Re: [PATCH] ata: libata-core: Add BRIDGE_OK quirk for QEMU drives

[Pedro Falcato]

On Wed, Mar 04, 2026 at 10:21:03AM +0100, Niklas Cassel wrote:
> Hello Pedro,
> 
> On Tue, Mar 03, 2026 at 06:33:37PM +0000, Pedro Falcato wrote:
> > Currently, whenever you boot with a QEMU drive over an AHCI interface,
> > you get:
> > [    1.632121] ata1.00: applying bridge limits
> > 
> > This happens due to the kernel not believing the given drive is SATA,
> > since word 93 of IDENTIFY (ATA_ID_HW_CONFIG) is non-zero. The result is
> > a pretty severe limit in max_hw_sectors_kb, which limits our IO sizes.
> > 
> > QEMU shares IDENTIFY data between PATA/SATA drives (and the corresponding
> > emulation of IDE/AHCI) but does not, in any way, emulate any of these
> > real hardware details. There is no PATA drive and no SATA cable.
> > 
> > As such, add a BRIDGE_OK quirk for QEMU HARDDISK. This results in the
> > max_hw_sectors being limited solely by the controller interface's limits.
> > Which, for AHCI controllers, takes it from 128KB to 32767KB.
> > 
> > Signed-off-by: Pedro Falcato <pfalcato@xxxxxxx>
> > ---
> > Note: This may be ok for stable, but I'll leave it up to you. There is
> > obviously no Fixes: here that doesn't go back 20 years.
> >  drivers/ata/libata-core.c | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
> > index d61846f03edc..70703432063a 100644
> > --- a/drivers/ata/libata-core.c
> > +++ b/drivers/ata/libata-core.c
> > @@ -4231,6 +4231,7 @@ static const struct ata_dev_quirks_entry __ata_dev_quirks[] = {
> >  	/* Devices that do not need bridging limits applied */
> >  	{ "MTRON MSP-SATA*",		NULL,	ATA_QUIRK_BRIDGE_OK },
> >  	{ "BUFFALO HD-QSU2/R5",		NULL,	ATA_QUIRK_BRIDGE_OK },
> > +	{ "QEMU HARDDISK",		NULL,	ATA_QUIRK_BRIDGE_OK },
> >  
> >  	/* Devices which aren't very happy with higher link speeds */
> >  	{ "WD My Book",			NULL,	ATA_QUIRK_1_5_GBPS },
> > -- 
> > 2.53.0
> > 
> 
> I think you should just fix QEMU.
> 
> Quirks are added for devices where we will never get a firmware update.
> 
> QEMU if FLOSS. QEMU has stable releases just like the kernel.
> 
> Why should the kernel carry this extra code just because of an issue in
> another FLOSS project?
> 
> 
> The fix in QEMU should be trivial.
> The argument in the commit log does not make sense, as QEMU already
> protects certain SATA only features with if (s->ncq_queues):
> https://github.com/qemu/qemu/blob/v10.2.1/hw/ide/core.c#L181
> 
> PATA does not support NCQ, so you could use that guard also to set the bit
> in word 93.
> 
> 
> That said, I understand that certain distros will might not ship with the
> latest QEMU stable release, so we could carry a quirk even for QEMU just to
> be nice to the distros, but not an unconditional quirk (FW version == NULL).

Yeah, that's why I went for the quirk, it seeemed more far reaching than just
patching QEMU.

So, does this look better?

diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index d61846f03edc..c57e35ccc092 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -4231,6 +4231,7 @@ static const struct ata_dev_quirks_entry __ata_dev_quirks[] = {
        /* Devices that do not need bridging limits applied */
        { "MTRON MSP-SATA*",            NULL,   ATA_QUIRK_BRIDGE_OK },
        { "BUFFALO HD-QSU2/R5",         NULL,   ATA_QUIRK_BRIDGE_OK },
+       { "QEMU HARDDISK",              "2.5+", ATA_QUIRK_BRIDGE_OK },
 
        /* Devices which aren't very happy with higher link speeds */
        { "WD My Book",                 NULL,   ATA_QUIRK_1_5_GBPS },

and I then patch QEMU to provide a correct word 93. Sounds good?
(note: the quirk above does not cover QEMU older than 2.5 I believe, but we
probably don't care about that, it's already 10+ years old...)

> 
> In my QEMU I have:
> $ lsblk -o MODEL,REV
> MODEL          REV
> QEMU HARDDISK 2.5+
> 
> Which comes from:
> include/qemu/hw-version.h: * Starting on QEMU 2.5, qemu_hw_version() returns "2.5+" by default
> 
> The comment in include/qemu/hw-version.h says that the version should not be
> increased, but QEMU already overloads this value if dev->version is set:
> https://github.com/qemu/qemu/blob/v10.2.1/hw/ide/core.c#L2660-L2664
> 
> So I suggest that you also send a patch to sets a default value to
> dev->version:
> https://github.com/qemu/qemu/blob/v10.2.1/hw/ide/ide-dev.c#L125-L127
> to some default value larger than 2.5+, unless an explicit value was
> provided by the user.

Yep, this is reasonable, thanks for the suggestion.

-- 
Pedro