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

[Damien Le Moal <dlemoal@kernel.org>]

On 3/4/26 03:33, 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.

It would be nice to fix that in QEMU.

> 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@suse.de>
> ---
> 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 },

Until we spend the time to improve QEMU ATA emulation, I think this is OK.

Reviewed-by: Damien Le Moal <dlemoal@kernel.org>

I think adding a Cc-stable here makes sense too. Niklas, can you do that when
applying ?

>  
>  	/* Devices which aren't very happy with higher link speeds */
>  	{ "WD My Book",			NULL,	ATA_QUIRK_1_5_GBPS },


-- 
Damien Le Moal
Western Digital Research