qemu-block
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-block] PIO Setup FIS and Clairvoyance Registers


From: John Snow
Subject: [Qemu-block] PIO Setup FIS and Clairvoyance Registers
Date: Mon, 22 Jun 2015 20:31:44 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0

The PIO Setup FIS specification in the SATA 3.2 spec is an odd one for me:

It specifies that, due to the stringent timing of the ATA/PIO protocols
that the Setup FIS is always sent immediately prior to the Data FIS.

The Setup FIS in this case contains both the value of the register
before the data transfer, and the value of the register /after/.

This to me implies it must do this:

- Prepare the Setup FIS
- Prepare the Data FIS
- Amend the Setup FIS
- Send Setup, Then Data

Okay, that's fine for PIO reads ... but the specification also says it
should be sent for WRITES as well. How on earth do these fields get
written out for PIO writes?

SATA 3.2 section 10.5.11.3 "Transmission of PIO Setup by Device Prior to
a Data Transfer from Host to Device"

"The device includes in the FIS the values to be placed in the
Shadow Status register at the beginning of the PIO data payload transfer
and the value to be placed in the Shadow Status register at the end of
the data payload transfer."

Huh? I guess it's supposed to be an /anticipated/ register, or something
bonkers like that?

The weird thing is that the AHCI specification says that PIO write
commands can expect D2H register updates, presumably exactly because you
can't possibly know what the registers are /going to be/ before the
device actually receives the data to write.

I can't find any further information in the SATA or ATA specification
that gives a more direct hint on how on earth I'm supposed to generate
these future register values.

Any thoughts?

--js

(PS: Yup, I'm firing up the Q35 machine to try to see what real hardware
does, because this is super confusing. I just wanted to see if this made
a lick of sense to anyone with a little more device experience under
their belt. I'll probably try to get at this tomorrow and experiment for
this and a few other unsolved mysteries I have for AHCI.)




reply via email to

[Prev in Thread] Current Thread [Next in Thread]