From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:51429) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VAR6K-0001Ml-Vv for qemu-devel@nongnu.org; Fri, 16 Aug 2013 16:58:33 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VAR6F-0007YR-Qj for qemu-devel@nongnu.org; Fri, 16 Aug 2013 16:58:28 -0400 Message-ID: <520E9302.1080201@redhat.com> Date: Fri, 16 Aug 2013 23:00:50 +0200 From: Laszlo Ersek MIME-Version: 1.0 References: <20130816155430.16354.31104.stgit@bling.home> In-Reply-To: <20130816155430.16354.31104.stgit@bling.home> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v3] exec: Fix non-power-of-2 sized accesses List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alex Williamson Cc: rth@twiddle.net, qemu-devel@nongnu.org, qemu-stable@nongnu.org On 08/16/13 18:00, Alex Williamson wrote: > Since commit 23326164 we align access sizes to match the alignment of > the address, but we don't align the access size itself. This means we > let illegal access sizes (ex. 3) slip through if the address is > sufficiently aligned (ex. 4). This results in an abort which would be > easy for a guest to trigger. Account for aligning the access size. > > Signed-off-by: Alex Williamson > Cc: qemu-stable@nongnu.org > --- > > v3: Highest power of 2, not lowest > v2: Remove unnecessary loop condition > > exec.c | 7 +++++++ > 1 file changed, 7 insertions(+) > > diff --git a/exec.c b/exec.c > index 3ca9381..8c90cef 100644 > --- a/exec.c > +++ b/exec.c > @@ -1924,6 +1924,13 @@ static int memory_access_size(MemoryRegion *mr, unsigned l, hwaddr addr) > } > } > > + /* Size must be a power of 2 */ > + if (l & (l - 1)) { > + while (!(l & access_size_max) && l & (access_size_max - 1)) { > + access_size_max >>= 1; > + } > + } > + > /* Don't attempt accesses larger than the maximum. */ > if (l > access_size_max) { > l = access_size_max; > Apologies, but I'm now totally confused. Suppose that the new code is reached with (access_size_max == 4). Now, l==9 and l==3 will enter the loop just the same, both shifting "access_size_max" right at least once, even though 9 is greater than 4, and 3 is less than 4. Is that OK? What's the goal here? Sorry for being dense... Thanks, Laszlo