From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1ItKtE-0000xW-Dk for qemu-devel@nongnu.org; Sat, 17 Nov 2007 05:27:04 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1ItKtC-0000x9-VA for qemu-devel@nongnu.org; Sat, 17 Nov 2007 05:27:04 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ItKtC-0000x6-NB for qemu-devel@nongnu.org; Sat, 17 Nov 2007 05:27:02 -0500 Received: from honiara.magic.fr ([195.154.193.36]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1ItKtC-00043q-IA for qemu-devel@nongnu.org; Sat, 17 Nov 2007 05:27:02 -0500 Received: from [192.168.0.2] (ppp-36.net-123.static.magiconline.fr [80.118.184.36]) by honiara.magic.fr (8.13.1/8.13.1) with ESMTP id lAHAQtcE008814 for ; Sat, 17 Nov 2007 11:26:57 +0100 Subject: Re: [Qemu-devel] qemu softmmu_template.h From: "J. Mayer" In-Reply-To: References: <1195293653.5335.27.camel@rapid> Content-Type: text/plain Date: Sat, 17 Nov 2007 11:26:52 +0100 Message-Id: <1195295212.5335.36.camel@rapid> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org On Sat, 2007-11-17 at 11:14 +0100, andrzej zaborowski wrote: > On 17/11/2007, J. Mayer wrote: > > > > On Sat, 2007-11-17 at 09:53 +0000, Andrzej Zaborowski wrote: > > > CVSROOT: /sources/qemu > > > Module name: qemu > > > Changes by: Andrzej Zaborowski 07/11/17 09:53:42 > > > > > > Modified files: > > > . : softmmu_template.h > > > > > > Log message: > > > Check permissions for the last byte first in unaligned slow_st accesses (patch from TeLeMan). > > > > > > CVSWeb URLs: > > > http://cvs.savannah.gnu.org/viewcvs/qemu/softmmu_template.h?cvsroot=qemu&r1=1.19&r2=1.20 > > > > > > > Has it been checked that it's legal for all architectures and cannot > > have any nasty side effect to do accesses in the reverse order ? Real > > hardware do not ever seem to do this... > > For real hardware the store is a single operation. For PowerPC, at least, only aligned stores are defined as atomic. It's absolutely legal for an implementation to split all non-atomic accesses into smaller aligned accesses. And I guess it is the same for all architecture that can do unaligned accesses. > Logically it shouldn't have any side effects, but if it does then it > would rather mean that other code for that architecture is (also) > broken, I believe. > > I've only tested ARM, mips, x86 and x86_64 before committing, so > please test. I figured that the patch won't get any comments on the > mailing list if it isn't merged. I don't think it's so easy to test because it may be very hard to trigger the cases that would have side effects, which are target dependent. I then am very curious to know how you did check that there is no problem with this patch.... I have to admit I did not notice this patch, or I would have commented it before (my fault). -- J. Mayer Never organized