From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:46455) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bJwtM-0000Vm-En for qemu-devel@nongnu.org; Mon, 04 Jul 2016 01:58:01 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bJwtI-0003WG-AX for qemu-devel@nongnu.org; Mon, 04 Jul 2016 01:57:59 -0400 Received: from mout.web.de ([217.72.192.78]:52634) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bJwtI-0003W0-00 for qemu-devel@nongnu.org; Mon, 04 Jul 2016 01:57:56 -0400 References: <1465993312-18119-1-git-send-email-davidkiarie4@gmail.com> <1465993312-18119-4-git-send-email-davidkiarie4@gmail.com> <576AF3E2.4060108@web.de> <5779F708.7060704@web.de> From: Jan Kiszka Message-ID: <5779FADC.50300@web.de> Date: Mon, 4 Jul 2016 07:57:48 +0200 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="WLDIME4K9s0k9PItB848FBFKDvup2fefx" Subject: Re: [Qemu-devel] [V12 3/4] hw/i386: Introduce AMD IOMMU List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: David Kiarie Cc: QEMU Developers , Marcel Apfelbaum , "Michael S. Tsirkin" , Peter Xu , alex.williamson@redhat.com, Valentine Sinitsyn , Eduardo Habkost This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --WLDIME4K9s0k9PItB848FBFKDvup2fefx From: Jan Kiszka To: David Kiarie Cc: QEMU Developers , Marcel Apfelbaum , "Michael S. Tsirkin" , Peter Xu , alex.williamson@redhat.com, Valentine Sinitsyn , Eduardo Habkost Message-ID: <5779FADC.50300@web.de> Subject: Re: [V12 3/4] hw/i386: Introduce AMD IOMMU References: <1465993312-18119-1-git-send-email-davidkiarie4@gmail.com> <1465993312-18119-4-git-send-email-davidkiarie4@gmail.com> <576AF3E2.4060108@web.de> <5779F708.7060704@web.de> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 2016-07-04 07:49, David Kiarie wrote: >>>>> +/* FIXME: something might go wrong if System Software writes in ch= unks >>>>> + * of one byte but linux writes in chunks of 4 bytes so currently = it >>>>> + * works correctly with linux but will definitely be busted if sof= tware >>>>> + * reads/writes 8 bytes >>>> >>>> What does the spec tell us about non-dword accesses? If they aren't >>>> allowed, filter them out completely at the beginning. >>> >>> Non-dword accesses are allowed. Spec 2.62 >>> >>> ".... Accesses must be aligned to the size of the access and the size= >>> in bytes must be a power >>> of two. Software may use accesses as small as one byte..... " >>> >>> Linux uses dword accesses though but even in this case a change in th= e >>> order of access whereby the high part of the register is accessed >>> first then the lower accessed could cause a problem (??) >> >> I do not get yet what makes it tricky to support all allowed access >> sizes. You are just missing byte access, and that will easy to add onc= e >> the size dispatching is done in a single function like suggested below= =2E >=20 > It is tricky because I need to ready some values that may span across > 1,2,4-byte boundaries and I don't have a way to tell that software is > done writing. The current logic is based on the assumption that > software writes the low bytes first which is mostly the case but might > not always be the case. According to the spec, software is allowed to read or write any byte, word, dword and qword, provided it is naturally aligned. Just model that access, nothing more. If a high-word/byte access triggers some side effect, than that is what it does (and probably a reason why Linux avoids it). Jan --WLDIME4K9s0k9PItB848FBFKDvup2fefx Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAld5+twACgkQitSsb3rl5xRv6gCgieF/eYYIaveCI/14xEk1eBH6 Zh8An0IWfMeREaKWULOo3vZTySsnMw4z =vTVy -----END PGP SIGNATURE----- --WLDIME4K9s0k9PItB848FBFKDvup2fefx--