This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


[Xen-devel] Re: [PATCH v2 4/5] exec.c: refactor cpu_physical_memory_map

To: Alexander Graf <agraf@xxxxxxx>
Subject: [Xen-devel] Re: [PATCH v2 4/5] exec.c: refactor cpu_physical_memory_map
From: Jan Kiszka <jan.kiszka@xxxxxx>
Date: Tue, 12 Jul 2011 09:15:27 +0200
Cc: Stefan BOSAK <stefan.bosak@xxxxxxxxx>, xen-devel Devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, "qemu-devel@xxxxxxxxxxxxxxxxxxxx Developers" <qemu-devel@xxxxxxxxxx>, Anthony Liguori <anthony@xxxxxxxxxxxxx>, Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>
Delivery-date: Tue, 12 Jul 2011 00:16:05 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <E667DF64-CA57-42E8-B565-887CCF79C8B8@xxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <alpine.DEB.2.00.1105191830010.12963@kaball-desktop> <1305826546-19059-4-git-send-email-stefano.stabellini@xxxxxxxxxxxxx> <4E1B767E.7010606@xxxxxx> <E667DF64-CA57-42E8-B565-887CCF79C8B8@xxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv: Gecko/20080226 SUSE/ Thunderbird/ Mnenhy/
On 2011-07-12 08:28, Alexander Graf wrote:
> On 12.07.2011, at 00:17, Jan Kiszka wrote:
>> On 2011-05-19 19:35, stefano.stabellini@xxxxxxxxxxxxx wrote:
>>> From: Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>
>>> Introduce qemu_ram_ptr_length that takes an address and a size as
>>> parameters rather than just an address.
>>> Refactor cpu_physical_memory_map so that we call qemu_ram_ptr_length only
>>> once rather than calling qemu_get_ram_ptr one time per page.
>>> This is not only more efficient but also tries to simplify the logic of
>>> the function.
>>> Currently we are relying on the fact that all the pages are mapped
>>> contiguously in qemu's address space: we have a check to make sure that
>>> the virtual address returned by qemu_get_ram_ptr from the second call on
>>> is consecutive. Now we are making this more explicit replacing all the
>>> calls to qemu_get_ram_ptr with a single call to qemu_ram_ptr_length
>>> passing a size argument.
>> This breaks cpu_physical_memory_map for >4G addresses on PC.
>> Effectively, it doesn't account for the PCI gap, ie. that the RAM block
>> is actually mapped in two chunks into the guest physical memory. One
>> outcome is that QEMU aborts when we try to process an address that is
>> now "outside" RAM. Simple to reproduce with a virtio NIC and 5G guest
>> memory, even without KVM.
> Yeah, that's what happens when you read mails too early in the morning :). 
> The xen branch didn't get pulled yet, so upstream is missing the following 
> patch:
> commit f221e5ac378feea71d9857ddaa40f829c511742f
> Author: Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>
> Date:   Mon Jun 27 18:26:06 2011 +0100
>     qemu_ram_ptr_length: take ram_addr_t as arguments
>     qemu_ram_ptr_length should take ram_addr_t as argument rather than
>     target_phys_addr_t because is doing comparisons with RAMBlock addresses.
>     cpu_physical_memory_map should create a ram_addr_t address to pass to
>     qemu_ram_ptr_length from PhysPageDesc phys_offset.
>     Remove code after abort() in qemu_ram_ptr_length.
>     Changes in v2:
>     - handle 0 size in qemu_ram_ptr_length;
>     - rename addr1 to raddr;
>     - initialize raddr to ULONG_MAX.
>     Signed-off-by: Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>
>     Reviewed-by: Peter Maydell <peter.maydell@xxxxxxxxxx>
>     Signed-off-by: Alexander Graf <agraf@xxxxxxx>

Maybe subject or changlog can reflect what this all fixes?

> Anthony?

Am I the only one under the impression that too many patches are in
limbo ATM?


Attachment: signature.asc
Description: OpenPGP digital signature

Xen-devel mailing list