[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Xen-devel] Re: [Qemu-devel] [PATCH 06/11] exec.c: refactor cpu_physical_memory_map



On Thu, 23 Jun 2011, Peter Maydell wrote:
> On 19 June 2011 04:39, Alexander Graf <agraf@xxxxxxx> 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.
> 
> This change breaks cpu_physical_memory_map() in the case where
> the passed in physical memory address corresponds to a RAM block
> which has been mapped in at multiple physical addresses. Specifically,
> for Versatile Express this means we abort() when framebuffer_update_display()
> calls cpu_physical_memory_map() for an address which is in the second
> mapped area.
> 
> > +/* Return a host pointer to guest's ram. Similar to qemu_get_ram_ptr
> > + * but takes a size argument */
> > +void *qemu_ram_ptr_length(target_phys_addr_t addr, target_phys_addr_t 
> > *size)
> 
> qemu_get_ram_ptr() takes a ramaddr_t, not a target_phys_addr_t;
> so should this, because we're just looking through the ram_list
> without doing physaddr to ramaddr translation.
> 
> Conceptually size should also be a ram_addr_t*, although if you
> do that you can't just pass the plen pointer through to it.
> 
> The old implementation of cpu_physical_memory_map() worked
> because it created the address to pass to qemu_get_ram_ptr()
> from the p->phys_offset it got from phys_page_find(). The
> new implementation needs to do something similar, not just pass
> a target_phys_addr_t to qemu_ram_ptr_length().
> 

Thanks for the detailed explanation of the problem, I think I understand
what I have to do to fix.
However I would like to have a repro of the bug before sending any
patches, so that I am sure that the solution works correctly.
However I am not very familiar with ARM emulation in Qemu: could you
please let me know which target I have to compile, which machine I have
to emulate and what other steps do I have to take in order to see this
issue?
Many thanks in advance.


> > +        fprintf(stderr, "Bad ram offset %" PRIx64 "\n", (uint64_t)addr);
> > +        abort();
> > +
> > +        *size = 0;
> > +        return NULL;
> 
> There doesn't seem much point in having code following an abort().
 
right, I'll remove it

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.