Allow byte reads of AHCI registers.

[neel]

Summary

This is needed to support Windows guests that use byte reads to access certain
AHCI registers (e.g. PxTFD.Status and PxTFD.Error).

Test Plan

Verified with the following guests:
FreeBSD 11.0 amd64 ahci-hd
FreeBSD 10.1 i386 ahci-hd
FreeBSD 10.1 amd64 ahci-cd
Centos 7 amd64 ahci-hd
Ubuntu 13.10 amd64 ahci-cd
OpenBSD 5.6 amd64 ahci-cd
OpenBSD 5.6 i386 ahci-hd ahci-cd
Windows 7 amd64 ahci-hd

[mav]

As I see, reading single byte at offset multiple to 4 this function still return 32-bit value, at next -- 24-bit, etc. Is this expected/acceptable behavior?

[grehan]

The PCI common code could probably enforce some of this (and others, such as unaligned or natural boundary crossings in accesses), but this is fine for now.

[neel]

In D2469#45441, @mav wrote:

As I see, reading single byte at offset multiple to 4 this function still return 32-bit value, at next -- 24-bit, etc. Is this expected/acceptable behavior?

I am not sure that I understand the comment but here is an explanation of how it behaves after the patch:

Assuming that the AHCI register at offset 0x20 contains the value 0xDEADBEEF.

regoff size return pci_ahci_read()
0x20 1 0x00000000DEADBEEF
0x21 1 0x0000000000DEADBE
0x22 1 0x000000000000DEAD
0x23 1 0x00000000000000DE

• least significant 8-bits used by instruction emulation

0x20 2 0x00000000DEADBEEF
0x22 2 0x000000000000DEAD

• least significant 16-bits used by instruction emulation

0x20 4 0x00000000DEADBEEF

• least significant 32-bits used by instruction emulation

[neel]

Assert that AHCI reads are naturally aligned and do not straddle a 32-bit
boundary.

[mav]

In D2469#45544, @neel wrote:

I am not sure that I understand the comment but here is an explanation of how it behaves after the patch:

I understand the behavior. Just was not sure what will trim extra bits. If all the consumers (instruction emulation code) do it correctly, then OK.

[markj]

This was committed in r282595.