qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Paolo Bonzini <pbonzini@redhat.com>
To: John Snow <jsnow@redhat.com>, Gerd Hoffmann <kraxel@redhat.com>,
	qemu-devel@nongnu.org
Cc: f4bug@amsat.org
Subject: Re: [Qemu-devel] regression: sata cdrom boot broken
Date: Thu, 21 Jun 2018 12:50:08 +0200	[thread overview]
Message-ID: <79d04e9f-df54-16ac-3c66-09424f515635@redhat.com> (raw)
In-Reply-To: <d1756dd7-a838-6977-0847-3a4bd5c93689@redhat.com>

On 20/06/2018 22:28, John Snow wrote:
> 
> ...Oh. So the PIO Setup FIS ... gets generated before the data is sent,
> but we don't copy it to the HBA memory buffers and notify the client
> until afterwards, but this is per-DRQ, I think, and not per-IDE command.

No, the copy happens before: "When a PIO setup FIS arrives from the
device, the HBA copies it to the PSFIS area of this structure".

However, the interrupt happens after the data is received too (and
whether it happens is decided per-FIS, i.e. per-DRQ).

>> Putting things together, there are two bugs in QEMU;
>>
>> - the PIO Setup interrupt must be generated at the end of data transfer
>>
> Oops.
> 
>> - the PIO Setup interrupt must not be generated for the ATAPI command
>> transfer
>>
> Oops again. I ought to have stopped you but I was long aware that the
> PIO Setup FIS ought to be generated "before" the transfer. I suppose
> what we were doing was more correct, though.

Not really, it's half and half and in fact the second of these two bugs
was very much preexisting.

Certainly it was wrong to generate the interrupt after the callback was
invoked, i.e. per command rather than per-DRQ.  This was the important
part of the original patch series because it is what made the recursion
not a tail recursion.

It's really hard to review this stuff since you have to find all the
tidbits across the AHCI and SATA (and sometimes ATA command set) specs.
If anything the blame goes to both of us for not testing the CD-ROM boot
case, rather than to you for missing it during the code review!

And on the bright side, it's still a win:

- it's possible to fix the bug without jeopardizing the whole READ CD series

- we've learnt more of the interactions between the AHCI and SATA specs

- the bug was discovered quickly enough

Paolo

  reply	other threads:[~2018-06-21 10:50 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-20 11:07 [Qemu-devel] regression: sata cdrom boot broken Gerd Hoffmann
2018-06-20 12:18 ` Paolo Bonzini
2018-06-20 20:28   ` John Snow
2018-06-21 10:50     ` Paolo Bonzini [this message]
2018-06-20 18:15 ` Thomas Huth
2018-06-21 11:22   ` Paolo Bonzini

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=79d04e9f-df54-16ac-3c66-09424f515635@redhat.com \
    --to=pbonzini@redhat.com \
    --cc=f4bug@amsat.org \
    --cc=jsnow@redhat.com \
    --cc=kraxel@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).