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

[Niklas Cassel]

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).

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.


Kind regards,
Niklas