[PATCH] ide: Set IDENTIFY word 93 to 0 on SATA drives

[PATCH] ide: Set IDENTIFY word 93 to 0 on SATA drives

[Pedro Falcato]

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/20260303183337.1013474-1-pfalcato@suse.de/
Cc: qemu-stable@nongnu.org
Suggsted-by: Niklas Cassel <cassel@kernel.org>
Signed-off-by: Pedro Falcato <pfalcato@suse.de>
---
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.
 
 hw/ide/core.c | 12 ++++++++++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/hw/ide/core.c b/hw/ide/core.c
index b45abf067b20..89f62f301e94 100644
--- a/hw/ide/core.c
+++ b/hw/ide/core.c
@@ -211,7 +211,15 @@ static void ide_identify(IDEState *s)
         put_le16(p + 87, (1 << 14) | 0);
     }
     put_le16(p + 88, 0x3f | (1 << 13)); /* udma5 set and supported */
-    put_le16(p + 93, 1 | (1 << 14) | 0x2000);
+    if (s->ncq_queues) {
+        /*
+         * This is SATA, which is required by the spec to return 0 for this
+         * field.
+         */
+        put_le16(p + 93, 0);
+    } else {
+        put_le16(p + 93, 1 | (1 << 14) | 0x2000);
+    }
     /* *(p + 100) := nb_sectors       -- see ide_identify_size */
     /* *(p + 101) := nb_sectors >> 16 -- see ide_identify_size */
     /* *(p + 102) := nb_sectors >> 32 -- see ide_identify_size */
@@ -2660,7 +2668,7 @@ int ide_init_drive(IDEState *s, IDEDevice *dev, IDEDriveKind kind, Error **errp)
     if (dev->version) {
         pstrcpy(s->version, sizeof(s->version), dev->version);
     } else {
-        pstrcpy(s->version, sizeof(s->version), qemu_hw_version());
+        pstrcpy(s->version, sizeof(s->version), "11.0");
     }
 
     ide_reset(s);
-- 
2.53.0

Re: [PATCH] ide: Set IDENTIFY word 93 to 0 on SATA drives

[Daniel P. Berrangé]

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/20260303183337.1013474-1-pfalcato@suse.de/
> Cc: qemu-stable@nongnu.org
> Suggsted-by: Niklas Cassel <cassel@kernel.org>
> Signed-off-by: Pedro Falcato <pfalcato@suse.de>
> ---
> 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.

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.

>  hw/ide/core.c | 12 ++++++++++--
>  1 file changed, 10 insertions(+), 2 deletions(-)
> 
> diff --git a/hw/ide/core.c b/hw/ide/core.c
> index b45abf067b20..89f62f301e94 100644
> --- a/hw/ide/core.c
> +++ b/hw/ide/core.c
> @@ -211,7 +211,15 @@ static void ide_identify(IDEState *s)
>          put_le16(p + 87, (1 << 14) | 0);
>      }
>      put_le16(p + 88, 0x3f | (1 << 13)); /* udma5 set and supported */
> -    put_le16(p + 93, 1 | (1 << 14) | 0x2000);
> +    if (s->ncq_queues) {
> +        /*
> +         * This is SATA, which is required by the spec to return 0 for this
> +         * field.
> +         */
> +        put_le16(p + 93, 0);
> +    } else {
> +        put_le16(p + 93, 1 | (1 << 14) | 0x2000);
> +    }
>      /* *(p + 100) := nb_sectors       -- see ide_identify_size */
>      /* *(p + 101) := nb_sectors >> 16 -- see ide_identify_size */
>      /* *(p + 102) := nb_sectors >> 32 -- see ide_identify_size */
> @@ -2660,7 +2668,7 @@ int ide_init_drive(IDEState *s, IDEDevice *dev, IDEDriveKind kind, Error **errp)
>      if (dev->version) {
>          pstrcpy(s->version, sizeof(s->version), dev->version);
>      } else {
> -        pstrcpy(s->version, sizeof(s->version), qemu_hw_version());
> +        pstrcpy(s->version, sizeof(s->version), "11.0");
>      }
>  
>      ide_reset(s);
> -- 
> 2.53.0
> 
> 

With regards,
Daniel
-- 
|: https://berrange.com       ~~        https://hachyderm.io/@berrange :|
|: https://libvirt.org          ~~          https://entangle-photo.org :|
|: https://pixelfed.art/berrange   ~~    https://fstop138.berrange.com :|

Re: [PATCH] ide: Set IDENTIFY word 93 to 0 on SATA drives

[Daniel P. Berrangé]

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/20260303183337.1013474-1-pfalcato@suse.de/
> > Cc: qemu-stable@nongnu.org
> > Suggsted-by: Niklas Cassel <cassel@kernel.org>
> > Signed-off-by: Pedro Falcato <pfalcato@suse.de>
> > ---
> > 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.
> 
> 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.

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
the case, then the version could be changed at the same time.

> 
> >  hw/ide/core.c | 12 ++++++++++--
> >  1 file changed, 10 insertions(+), 2 deletions(-)
> > 
> > diff --git a/hw/ide/core.c b/hw/ide/core.c
> > index b45abf067b20..89f62f301e94 100644
> > --- a/hw/ide/core.c
> > +++ b/hw/ide/core.c
> > @@ -211,7 +211,15 @@ static void ide_identify(IDEState *s)
> >          put_le16(p + 87, (1 << 14) | 0);
> >      }
> >      put_le16(p + 88, 0x3f | (1 << 13)); /* udma5 set and supported */
> > -    put_le16(p + 93, 1 | (1 << 14) | 0x2000);
> > +    if (s->ncq_queues) {
> > +        /*
> > +         * This is SATA, which is required by the spec to return 0 for this
> > +         * field.
> > +         */
> > +        put_le16(p + 93, 0);
> > +    } else {
> > +        put_le16(p + 93, 1 | (1 << 14) | 0x2000);
> > +    }
> >      /* *(p + 100) := nb_sectors       -- see ide_identify_size */
> >      /* *(p + 101) := nb_sectors >> 16 -- see ide_identify_size */
> >      /* *(p + 102) := nb_sectors >> 32 -- see ide_identify_size */
> > @@ -2660,7 +2668,7 @@ int ide_init_drive(IDEState *s, IDEDevice *dev, IDEDriveKind kind, Error **errp)
> >      if (dev->version) {
> >          pstrcpy(s->version, sizeof(s->version), dev->version);
> >      } else {
> > -        pstrcpy(s->version, sizeof(s->version), qemu_hw_version());
> > +        pstrcpy(s->version, sizeof(s->version), "11.0");
> >      }
> >  
> >      ide_reset(s);
> > -- 
> > 2.53.0
> > 
> > 
> 
> With regards,
> Daniel
> -- 
> |: https://berrange.com       ~~        https://hachyderm.io/@berrange :|
> |: https://libvirt.org          ~~          https://entangle-photo.org :|
> |: https://pixelfed.art/berrange   ~~    https://fstop138.berrange.com :|
> 
> 

With regards,
Daniel
-- 
|: https://berrange.com       ~~        https://hachyderm.io/@berrange :|
|: https://libvirt.org          ~~          https://entangle-photo.org :|
|: https://pixelfed.art/berrange   ~~    https://fstop138.berrange.com :|

Re: [PATCH] ide: Set IDENTIFY word 93 to 0 on SATA drives

[Pedro Falcato]

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/20260303183337.1013474-1-pfalcato@suse.de/
> > > Cc: qemu-stable@nongnu.org
> > > Suggsted-by: Niklas Cassel <cassel@kernel.org>
> > > Signed-off-by: Pedro Falcato <pfalcato@suse.de>
> > > ---
> > > 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

Re: [PATCH] ide: Set IDENTIFY word 93 to 0 on SATA drives

[BALATON Zoltan]

On Wed, 18 Mar 2026, 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).

AHCI is not the only SATA controller emulated but the only one setting 
ncq_queues so that's not a good way to identify SATA in general. Maybe 
there should be something else that SATA controllers could set which you 
test for here but I don't know what would be the best way for that. It 
seems a drive is SATA if it's connected to a SATA controller so maybe the 
bus should have a field set to say it's a SATA bus?

As for ABI and behaviour change, usually if you change something that 
would make a Windows guest detect new hardware then that should be 
introduced with new machine version with compatibity kept for older 
machine versions. I don't know if that applies to replacing IDE drives 
with SATA drives but seems likely.

Regards,
BALATON Zoltan

> 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/20260303183337.1013474-1-pfalcato@suse.de/
> Cc: qemu-stable@nongnu.org
> Suggsted-by: Niklas Cassel <cassel@kernel.org>
> Signed-off-by: Pedro Falcato <pfalcato@suse.de>
> ---
> 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.
>
> hw/ide/core.c | 12 ++++++++++--
> 1 file changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/hw/ide/core.c b/hw/ide/core.c
> index b45abf067b20..89f62f301e94 100644
> --- a/hw/ide/core.c
> +++ b/hw/ide/core.c
> @@ -211,7 +211,15 @@ static void ide_identify(IDEState *s)
>         put_le16(p + 87, (1 << 14) | 0);
>     }
>     put_le16(p + 88, 0x3f | (1 << 13)); /* udma5 set and supported */
> -    put_le16(p + 93, 1 | (1 << 14) | 0x2000);
> +    if (s->ncq_queues) {
> +        /*
> +         * This is SATA, which is required by the spec to return 0 for this
> +         * field.
> +         */
> +        put_le16(p + 93, 0);
> +    } else {
> +        put_le16(p + 93, 1 | (1 << 14) | 0x2000);
> +    }
>     /* *(p + 100) := nb_sectors       -- see ide_identify_size */
>     /* *(p + 101) := nb_sectors >> 16 -- see ide_identify_size */
>     /* *(p + 102) := nb_sectors >> 32 -- see ide_identify_size */
> @@ -2660,7 +2668,7 @@ int ide_init_drive(IDEState *s, IDEDevice *dev, IDEDriveKind kind, Error **errp)
>     if (dev->version) {
>         pstrcpy(s->version, sizeof(s->version), dev->version);
>     } else {
> -        pstrcpy(s->version, sizeof(s->version), qemu_hw_version());
> +        pstrcpy(s->version, sizeof(s->version), "11.0");
>     }
>
>     ide_reset(s);
>

Re: [PATCH] ide: Set IDENTIFY word 93 to 0 on SATA drives

[Daniel P. Berrangé]

On Wed, Mar 18, 2026 at 05:24:58PM +0000, Pedro Falcato wrote:
> 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/20260303183337.1013474-1-pfalcato@suse.de/
> > > > Cc: qemu-stable@nongnu.org
> > > > Suggsted-by: Niklas Cassel <cassel@kernel.org>
> > > > Signed-off-by: Pedro Falcato <pfalcato@suse.de>
> > > > ---
> > > > 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?

QEMU  can save/restore the state of a running VM to disk, or through
Live migration between hosts, transfer state across two QEMU's. If
those two processes are running different QEMU releases, we need to
ensure the guest visible virtual hardware doesn't change its behaviour.
Guest OS are liable to misbehave if hardware changes behaviour while the
OS is running.

In QEMU we have machine types "pc" ( "i440fx") and "q35" which encode
which have versions associated with them. These are intended to encode
settings which ensure QEMU exposes consistent guest hardware features.

IOW, the machine 'pc-i440fx-10.0.0'  should operate the same regardless
of whether it is run from QEMU 10.0.0, or a later  QEMU 10.1.0.

Behaviour changes would only be introduced ina  newer 'pc-i440fx-10.1.0'

We generally refer to this overall situation as "fixed guest ABI" or
"fixed machine type ABI".

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

Yes, I meant, we would be changing what features QEMU exposes to the
guest, and that changes the guest behaviour

> > 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?

Yes, something along those lines. We're about to make the QEMU 11.0.0
release, in a feew weeks and are in freeze now. We can take bug fix
patches in freeze, so 11.0 is still a possibility.

We might want a specific bool property 'x-sata-identify-fix'  to control
enablement of the fix that is added to hw_compat, parallel to the
version change.

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

IIUC, we didn't want the version in the hardware to unconditionally
change every time the QEMU version changed. So back in the 2.5 release
we fixed the version at 2.5, such that future changes would need an
explicit decision. I think it is likely Ok to change the version
number to 11


With regards,
Daniel
-- 
|: https://berrange.com       ~~        https://hachyderm.io/@berrange :|
|: https://libvirt.org          ~~          https://entangle-photo.org :|
|: https://pixelfed.art/berrange   ~~    https://fstop138.berrange.com :|

Re: [PATCH] ide: Set IDENTIFY word 93 to 0 on SATA drives

[Paolo Bonzini]

On 3/18/26 21:13, BALATON Zoltan wrote:
> On Wed, 18 Mar 2026, 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).
> 
> AHCI is not the only SATA controller emulated but the only one setting 
> ncq_queues so that's not a good way to identify SATA in general. Maybe 
> there should be something else that SATA controllers could set which you 
> test for here but I don't know what would be the best way for that. It 
> seems a drive is SATA if it's connected to a SATA controller so maybe 
> the bus should have a field set to say it's a SATA bus?

That makes sense - the other SATA controller being hw/ide/sii3112.c, for 
Pedro.

> As for ABI and behaviour change, usually if you change something that 
> would make a Windows guest detect new hardware then that should be 
> introduced with new machine version with compatibity kept for older 
> machine versions. I don't know if that applies to replacing IDE drives 
> with SATA drives but seems likely.

This is probably not an issue for a random value in IDENTIFY data, but 
yeah it's best to add a compatibility property.  Then it should be easy 
to also keep the version constant like this:

     IDEBus *bus = DO_UPCAST(IDEBus, qbus, dev->qdev.parent_bus);

     if (dev->version) {
         pstrcpy(s->version, sizeof(s->version), dev->version);
     } else if (!dev->has_sata_word93 && bus->sata) {
         pstrcpy(s->version, sizeof(s->version), "11.0+");
     } else {
         pstrcpy(s->version, sizeof(s->version), QEMU_HW_VERSION);
     }

Paolo