From: Paolo Bonzini <pbonzini@redhat.com>
To: John Snow <jsnow@redhat.com>, qemu-devel@nongnu.org
Cc: qemu-block@nongnu.org
Subject: Re: [Qemu-devel] [PATCH 1/6] ahci: move PIO Setup FIS before transfer, fix it for ATAPI commands
Date: Wed, 6 Jun 2018 15:44:21 +0200 [thread overview]
Message-ID: <9d33d6f3-d30c-08c0-4f77-18cd81050354@redhat.com> (raw)
In-Reply-To: <21dce199-daac-1ac4-ba19-5b20f5898825@redhat.com>
On 05/06/2018 01:27, John Snow wrote:
>
>
> On 06/04/2018 11:50 AM, Paolo Bonzini wrote:
>> On 02/06/2018 03:22, John Snow wrote:
>>> - Status: Should be the status register after receiving the H2D Register
>>> update FIS, but prior to the data transfer, I think. "New value of the
>>> Status register of the Command Block for initiation of host data
>>> transfer."
>>> I think this is being set correctly after this patch.
>>>
>>> - Error: "Contains the new value of the Error register of the Command
>>> Block at the conclusion of all subsequent Data to Device frames."
>>>
>>> This is why we were sending out post-hoc PIO Setup FIS frames before,
>>> how would I know what the error register *will* be...? What?
>>
>> You don't, I guess. Zero?
>>
>
> Yeah, I don't mean to hold it up based on other arcane stuff, I was just
> briefly hoping that maybe you actually understood it so I could fix it
> once and for all...
>
>>> - LBA: Presumably unimportant for the purposes of receiving a command
>>> PACKET, as we won't be writing it to disk, but a buffer. The values
>>> can be reported dutifully.
>>>
>>> - Device: Just report the register value dutifully.
>>>
>>> - Count: Likely just relays 0, as the H2D REG FIS should have updated
>>> that to zero as part of the PACKET command, as per ATA8 ACS3 7.21.3.
>>> In any case, just report the register value dutifully.
>>>
>>> - E_Status: "Contains the new value of the Status register of the
>>> Command Block at the conclusion of the subsequent Data FIS."
>>>
>>> Again, how would I know...?
>>>
>>> - Transfer Count: Should be 12, as per what we specified in 0xA1
>>> IDENTIFY PACKET DEVICE, see core.c line 234. Your patch gets this
>>> correct, as we'll actually report the PIO FIS for the packet itself.
>>>
>>>
>>> What this patch does do, though, is change the context of the Status,
>>> Error and E_Status registers to something different. Everything else
>>> should be the same, but I'd feel better about taking this patch if I
>>> understood what exactly this FIS packet was supposed to convey, but I don't.
>>
>> At least Status and Transfer Count are correct after this patch. :/
>>
>> Paolo
>>
>
> How about ...
>
> https://github.com/jnsnow/qemu/commit/0657390a2639b7cb533ca8b514c49c0edd3f4483
Yes, it's sane.
Paolo
next prev parent reply other threads:[~2018-06-06 13:44 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-17 15:39 [Qemu-devel] [PATCH 0/6] atapi: change unlimited recursion to while loop Paolo Bonzini
2018-04-17 15:39 ` [Qemu-devel] [PATCH 1/6] ahci: move PIO Setup FIS before transfer, fix it for ATAPI commands Paolo Bonzini
2018-06-02 1:22 ` John Snow
2018-06-04 15:50 ` Paolo Bonzini
2018-06-04 23:27 ` John Snow
2018-06-06 13:44 ` Paolo Bonzini [this message]
2018-04-17 15:39 ` [Qemu-devel] [PATCH 2/6] ide: push end_transfer_func out of start_transfer callback, rename callback Paolo Bonzini
2018-06-02 0:24 ` John Snow
2018-06-04 15:48 ` Paolo Bonzini
2018-06-04 17:42 ` John Snow
2018-04-17 15:39 ` [Qemu-devel] [PATCH 3/6] ide: call ide_cmd_done from ide_transfer_stop Paolo Bonzini
2018-06-02 0:26 ` John Snow
2018-04-17 15:39 ` [Qemu-devel] [PATCH 4/6] ide: make ide_transfer_stop idempotent Paolo Bonzini
2018-06-02 0:28 ` John Snow
2018-04-17 15:39 ` [Qemu-devel] [PATCH 5/6] atapi: call ide_set_irq before ide_transfer_start Paolo Bonzini
2018-06-02 1:07 ` John Snow
2018-04-17 15:39 ` [Qemu-devel] [PATCH 6/6] ide: introduce ide_transfer_start_norecurse Paolo Bonzini
2018-06-02 1:17 ` John Snow
2018-06-04 15:51 ` 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=9d33d6f3-d30c-08c0-4f77-18cd81050354@redhat.com \
--to=pbonzini@redhat.com \
--cc=jsnow@redhat.com \
--cc=qemu-block@nongnu.org \
--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).