[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] Re: [PATCH v2 4/5] exec.c: refactor cpu_physical_memory_map
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. Ah, I see what you mean now. It breaks on current HEAD, but not on my last xen-next branch which already included that patch, so I'd assume it's something different that came in later. Alex _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |