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

[Alexander Graf <agraf@xxxxxxx>]

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.

Do you have some reliable test case? I can't seem to reproduce the issue. It 
works just fine for me with -m 10G, virtio nic and disk, polluting all the 
guest page cache.


Alex


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel