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

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

[Pedro Falcato]

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@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 },
 
 	/* Devices which aren't very happy with higher link speeds */
 	{ "WD My Book",			NULL,	ATA_QUIRK_1_5_GBPS },
-- 
2.53.0

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

[Damien Le Moal]

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

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@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 },
>  
>  	/* 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

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@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 },
> >  
> >  	/* 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

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

[Niklas Cassel]

Hello Pedro,

On Wed, Mar 04, 2026 at 11:23:01AM +0000, Pedro Falcato wrote:

(snip)

> 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 },

Yes, I would prefer that.

When booting a device that has quirks applied, we will get prints in dmesg
showing which quirks were applied.

It would be nice if we could avoid applying quirks for QEMU when (sometime
in the future) a newer version of QEMU is available that does the right
thing.


Kind regards,
Niklas

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

[Pedro Falcato]

On Wed, Mar 04, 2026 at 01:08:35PM +0100, Niklas Cassel wrote:
> Hello Pedro,
> 
> On Wed, Mar 04, 2026 at 11:23:01AM +0000, Pedro Falcato wrote:
> 
> (snip)
> 
> > 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 },
> 
> Yes, I would prefer that.
> 
> When booting a device that has quirks applied, we will get prints in dmesg
> showing which quirks were applied.

Yeah, makes sense. Can you use this diff and add Cc: stable when applying,
or do you want me to send a v2?

> 
> It would be nice if we could avoid applying quirks for QEMU when (sometime
> in the future) a newer version of QEMU is available that does the right
> thing.

On it :)

Thanks!
-- 
Pedro

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

[Niklas Cassel]

On Wed, Mar 04, 2026 at 07:34:29PM +0000, Pedro Falcato wrote:
> On Wed, Mar 04, 2026 at 01:08:35PM +0100, Niklas Cassel wrote:
> > Hello Pedro,
> > 
> > On Wed, Mar 04, 2026 at 11:23:01AM +0000, Pedro Falcato wrote:
> > 
> > (snip)
> > 
> > > 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 },
> > 
> > Yes, I would prefer that.
> > 
> > When booting a device that has quirks applied, we will get prints in dmesg
> > showing which quirks were applied.
> 
> Yeah, makes sense. Can you use this diff and add Cc: stable when applying,
> or do you want me to send a v2?

Please send a V2 without the text:
"QEMU shares IDENTIFY data between PATA/SATA drives"

I don't think this is 100% true, as we can see that the QEMU AHCI emulation
e.g. sets s->ncq_queues in ahci.c:
https://github.com/qemu/qemu/blob/v10.2.1/hw/ide/ahci.c#L632

So the identify data is already different for PATA/SATA drives IMO.


Kind regards,
Niklas