qemu-block
[Top][All Lists]
Advanced

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

Re: [Qemu-block] [PATCH 14/16] ahci: Do not map cmd_fis to generate resp


From: John Snow
Subject: Re: [Qemu-block] [PATCH 14/16] ahci: Do not map cmd_fis to generate response
Date: Fri, 26 Jun 2015 13:31:12 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256



On 06/26/2015 11:59 AM, Stefan Hajnoczi wrote:
> On Mon, Jun 22, 2015 at 08:21:13PM -0400, John Snow wrote:
>> @@ -744,8 +722,8 @@ static void ahci_write_fis_pio(AHCIDevice
>> *ad, uint16_t len) pio_fis[9] = s->hob_lcyl; pio_fis[10] =
>> s->hob_hcyl; pio_fis[11] = 0; -    pio_fis[12] = cmd_fis[12]; -
>> pio_fis[13] = cmd_fis[13]; +    pio_fis[12] = s->nsector & 0xFF; 
>> +    pio_fis[13] = (s->nsector >> 8) & 0xFF;
> 
> hw/ide/core.c decreases s->nsector until it reaches 0 and the
> request ends.
> 
> Will the values reported back to the guest be correct if we use 
> s->nsector?
> 

See the commit message for justification of this one. Ultimately, it
doesn't matter what gets put in here (for data transfer commands) --
but getting RID of the cmd_fis mapping is a strong positive.

The field is supposed to contain the contents of the sector count
register at the conclusion of the command. The spec says that for data
transfer commands, this value is useless/uninteresting (it can be
zero-filled, or filled with garbage, etc)

However, for some special purpose commands, the sector count register
is required to hold a value that has some special meaning. I don't
think we currently support any of those, but for the future -- this
part of the FIS generation code will work correctly regardless.

So this patch is mainly about getting rid of the cmd_fis mapping and
putting something nominally correct in its place.

- --js
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJVjYxgAAoJEH3vgQaq/DkOYiMQAIUetgDGGd8QvntbT147pifE
f8vLqV1TDZL2cmorplUT8K5BFPEOiSFn3GIa2K4sVmfZy9L7r/Q8SUn/WtV0AeLD
/OkU7l25JIz62cSKpZZpfJcKsw9iBjRoeltxM1AfiS+GpUIMRxxORUEsgswEJQzn
CPLkOOE+ME1Bh9qq6/kYj0+gPLwC2UjoW2xny1A5pizwdf4VlJl9jyM5DWMdtryW
Qcd/djxK2CAXsvpMYNQnnjF7JDp+nkGaXct+hTQEUZRWbUv02+KOt9StBfBh+Dq1
njYq6pgUfvvbjOzccHTzgeaUlCCI6mP+ng0ksjG2HW9LI8QyV9whtPB/Rc2ORfhz
R1zTw5JW6fsAVnbfkxBC7OFJBZB4WfmJWEdIPUmrmLgpxaBDi9jOK+bqYXeTTpXv
bgdFJN2BAWXW1F4UCSjDaVUAL1FYG5vjxw+MbbWGcdHTFPT6z3OZVxe1AST7SS3j
xuqIVMaxBeskQgUJiwOBFSFkTMTpWPIfRLY1MLk9yqXuwQpg7NtQncbho3wCj1cC
nxpjDjWRAB3a2odjCocA9RN6uBNeKq2WbmFzU6bODgjOHRFUPfP/s3qz43PPQGxa
+VQZaQahOnvVIGWnerXMyl+LT/0tLhsBUZDeRoNbR3MMMprw3yxozP1BM1bQ4bWx
brUOjknDPIwWfjfIpUID
=SaS/
-----END PGP SIGNATURE-----



reply via email to

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