From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:46276) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z4dVg-0001tI-2x for qemu-devel@nongnu.org; Mon, 15 Jun 2015 19:09:45 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z4dVe-0007j5-Tw for qemu-devel@nongnu.org; Mon, 15 Jun 2015 19:09:44 -0400 Message-ID: <557F5B2D.4090408@redhat.com> Date: Mon, 15 Jun 2015 19:09:33 -0400 From: John Snow MIME-Version: 1.0 References: <1434406965-30883-1-git-send-email-jsnow@redhat.com> <1434406965-30883-2-git-send-email-jsnow@redhat.com> <557F57CF.2090102@redhat.com> In-Reply-To: <557F57CF.2090102@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH 1/4] ahci: Do not ignore memory access read size List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eric Blake , qemu-block@nongnu.org Cc: kwolf@redhat.com, qemu-devel@nongnu.org, stefanha@redhat.com On 06/15/2015 06:55 PM, Eric Blake wrote: > On 06/15/2015 04:22 PM, John Snow wrote: >> The only guidance the AHCI specification gives on memory access is: >> "Register accesses shall have a maximum size of 64-bits; 64-bit access >> must not cross an 8-byte alignment boundary." >> >> In practice, a real Q35/ICH9 responds to 1, 2, 4 and 8 byte reads >> regardless of alignment. Windows 7 can also be observed making 1 byte >> reads to the middle of 32 bit registers. >> >> Introduce a wrapper to supper unaligned accesses to AHCI. >=20 > s/supper/support/ Wow, I guess I'm hungry. >=20 >> This wrapper will support aligned 8 byte reads, but will make >> no effort to support unaligned 8 byte reads, which although they >> will work on real hardware, are not guaranteed to work and do >> not appear to be used by either Windows or Linux. >> >> Signed-off-by: John Snow >> --- >> hw/ide/ahci.c | 21 +++++++++++++++++++-- >> 1 file changed, 19 insertions(+), 2 deletions(-) >> >> diff --git a/hw/ide/ahci.c b/hw/ide/ahci.c >> index 9e5d862..55779fb 100644 >> --- a/hw/ide/ahci.c >> +++ b/hw/ide/ahci.c >> @@ -331,8 +331,7 @@ static void ahci_port_write(AHCIState *s, int por= t, int offset, uint32_t val) >> } >> } >> =20 >> -static uint64_t ahci_mem_read(void *opaque, hwaddr addr, >> - unsigned size) >> +static uint64_t ahci_mem_read_32(void *opaque, hwaddr addr) >> { >> AHCIState *s =3D opaque; >> uint32_t val =3D 0; >> @@ -368,6 +367,24 @@ static uint64_t ahci_mem_read(void *opaque, hwadd= r addr, >> } >> =20 >> =20 >> +static uint64_t ahci_mem_read(void *opaque, hwaddr addr, unsigned siz= e) >> +{ >> + hwaddr aligned =3D addr & ~0x3; >> + int ofst =3D addr - aligned; >> + uint64_t lo =3D ahci_mem_read_32(opaque, aligned); >> + uint64_t hi; >> + >> + /* if 1/2/4 byte read does not cross 4 byte boundary */ >> + if (ofst + size <=3D 4) { >> + return lo >> (ofst * 8); >> + } >=20 > At this point, we could assert(size > 1). >=20 Sure. I guess in that light my comment above is a little wacky -- 1 byte reads can't cross the boundary ;) >> + >> + /* If the 64bit read is unaligned, we will produce undefined >> + * results. AHCI does not support unaligned 64bit reads. */ >> + hi =3D ahci_mem_read_32(opaque, aligned + 4); >> + return (hi << 32) | lo; >=20 > This makes no effort to support an unaligned 2 byte (16bit) or 4 byte > (32bit) read that crosses 4-byte boundary. Is that intentional? I kno= w > it is intentional that you don't care about unaligned 64bit reads; > conversely, while your commit message mentioned Windows doing 1-byte > reads in the middle of 32-bit registers, you didn't mention whether > Windows does unaligned 2- or 4-byte reads. So either the comment shoul= d > be broadened, or the code needs further tuning. >=20 Good catch. I have not observed any OS making 2 or 4 byte accesses across the register boundary, and cannot think of a reason why you would want to, though the AHCI spec technically doesn't discount your ability to do so and it does work on a real Q35. I can do this: return (hi << 32 | lo) >> (ofst * 8); which will give us unaligned 2 and 4 byte reads, but will really get very wacky for unaligned 8 byte reads -- which you really should probably not be doing anyway.