From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:50922)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <pbonzini@redhat.com>) id 1WAgWG-0007Zy-Lb
	for qemu-devel@nongnu.org; Tue, 04 Feb 2014 08:58:38 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <pbonzini@redhat.com>) id 1WAgWA-0007Ru-IT
	for qemu-devel@nongnu.org; Tue, 04 Feb 2014 08:58:32 -0500
Message-ID: <52F0E883.1020704@redhat.com>
Date: Tue, 04 Feb 2014 14:17:55 +0100
From: Paolo Bonzini <pbonzini@redhat.com>
MIME-Version: 1.0
References: <246b6975027245a0bc428eb33808390d@CO1PR05MB490.namprd05.prod.outlook.com>
	<52EFFFC1.7040303@ilande.co.uk>
	<94B55321-62FD-4F57-8A91-4B77E1B74E19@suse.de>
	<7FC332AA-AB7D-47F2-84D2-CD66DCAE3277@suse.de>
	<FE28D331-E10A-4161-9D1B-2AEA95ADAF7F@suse.de>
	<CAFEAcA_6YZ5pa86n-3x+RMOBUzDknipRii8x3t3pnLbeMi=9_g@mail.gmail.com>
	<AB25BFF7-7DD3-4066-9511-E017DD87C1A6@suse.de>
In-Reply-To: <AB25BFF7-7DD3-4066-9511-E017DD87C1A6@suse.de>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] [Qemu-ppc] standard test image not booting with
 qemu-system-ppc
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Alexander Graf <agraf@suse.de>, Peter Maydell <peter.maydell@linaro.org>
Cc: Nitin Srivastava <nitins@juniper.net>, Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>, Stefano Stabellini <stefano.stabellini@eu.citrix.com>, Michael Tokarev <mjt@tls.msk.ru>, qemu-devel <qemu-devel@nongnu.org>, "qemu-ppc@nongnu.org" <qemu-ppc@nongnu.org>, Anthony PERARD <anthony.perard@citrix.com>

Il 04/02/2014 08:55, Alexander Graf ha scritto:
>> With this change, the
>> memory system is now refusing to allow an access of size
>> 2 through, because it's greater than the region length. So
> 
> Ouch. Yes, for ioport reads/writes we definitely have to only cap the port range, not the length.

We can do it in general for MMIO.  Something like this?

diff --git a/exec.c b/exec.c
index 9ad0a4b..9a1eef3 100644
--- a/exec.c
+++ b/exec.c
@@ -325,7 +325,7 @@ address_space_translate_internal(AddressSpaceDispatch *d, hwaddr addr, hwaddr *x
                                  hwaddr *plen, bool resolve_subpage)
 {
     MemoryRegionSection *section;
-    Int128 diff, diff_page;
+    Int128 diff;
 
     section = address_space_lookup_region(d, addr, resolve_subpage);
     /* Compute offset within MemoryRegionSection */
@@ -334,9 +334,7 @@ address_space_translate_internal(AddressSpaceDispatch *d, hwaddr addr, hwaddr *x
     /* Compute offset within MemoryRegion */
     *xlat = addr + section->offset_within_region;
 
-    diff_page = int128_make64(((addr & TARGET_PAGE_MASK) + TARGET_PAGE_SIZE) - addr);
     diff = int128_sub(section->mr->size, int128_make64(addr));
-    diff = int128_min(diff, diff_page);
     *plen = int128_get64(int128_min(diff, int128_make64(*plen)));
     return section;
 }
@@ -370,6 +368,11 @@ MemoryRegion *address_space_translate(AddressSpace *as, hwaddr addr,
         as = iotlb.target_as;
     }
 
+    if (memory_access_is_direct(mr, is_write)) {
+        hwaddr page = (addr & TARGET_PAGE_MASK) + TARGET_PAGE_SIZE - addr;
+        len = MIN(page, len);
+    }
+
     *plen = len;
     *xlat = addr;
     return mr;


Stefano, Anthony, can you test it on Xen?

I wouldn't mind sticking a "xen_enabled()" in there, and/or a comment to document
why we do it.

Paolo