From: Peter Maydell <peter.maydell@linaro.org>
To: Alexander Graf <agraf@suse.de>
Cc: "xen-devel@lists.xensource.com Devel"
<xen-devel@lists.xensource.com>,
"qemu-devel@nongnu.org Developers" <qemu-devel@nongnu.org>,
Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Qemu-devel] [PATCH 06/11] exec.c: refactor cpu_physical_memory_map
Date: Thu, 23 Jun 2011 18:08:12 +0100 [thread overview]
Message-ID: <BANLkTikhygNpXrC=TaGuxWgiQsV0g7wUTQ@mail.gmail.com> (raw)
In-Reply-To: <1308454790-13750-6-git-send-email-agraf@suse.de>
On 19 June 2011 04:39, Alexander Graf <agraf@suse.de> wrote:
> From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
>
> 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().
> + 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().
-- PMM
next prev parent reply other threads:[~2011-06-23 17:08 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-06-19 2:57 [Qemu-devel] [PULL] Xen Patch Queue Alexander Graf
2011-06-19 3:39 ` [Qemu-devel] [PATCH 01/11] xen: Add xc_domain_add_to_physmap to xen_interface Alexander Graf
2011-06-19 3:39 ` [Qemu-devel] [PATCH 02/11] xen: Introduce VGA sync dirty bitmap support Alexander Graf
2011-06-19 3:39 ` [Qemu-devel] [PATCH 03/11] xen: fix qemu_map_cache with size != MCACHE_BUCKET_SIZE Alexander Graf
2011-06-19 3:39 ` [Qemu-devel] [PATCH 04/11] xen: remove qemu_map_cache_unlock Alexander Graf
2011-06-19 3:39 ` [Qemu-devel] [PATCH 05/11] xen: remove xen_map_block and xen_unmap_block Alexander Graf
2011-06-19 3:39 ` [Qemu-devel] [PATCH 06/11] exec.c: refactor cpu_physical_memory_map Alexander Graf
2011-06-23 17:08 ` Peter Maydell [this message]
2011-06-23 17:56 ` Stefano Stabellini
2011-06-23 18:20 ` Peter Maydell
2011-06-24 11:08 ` Stefano Stabellini
2011-06-19 3:39 ` [Qemu-devel] [PATCH 07/11] xen: mapcache performance improvements Alexander Graf
2011-06-19 3:39 ` [Qemu-devel] [PATCH 08/11] cirrus_vga: reset lfb_addr after a pci config write if the BAR is unmapped Alexander Graf
2011-06-19 3:39 ` [Qemu-devel] [PATCH 09/11] xen: only track the linear framebuffer Alexander Graf
2011-06-19 3:39 ` [Qemu-devel] [PATCH 10/11] xen: fix interrupt routing Alexander Graf
2011-06-19 3:39 ` [Qemu-devel] [PATCH 11/11] xen: Add the Xen platform pci device Alexander Graf
2011-06-22 12:57 ` [Qemu-devel] [PULL] Xen Patch Queue Anthony Liguori
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='BANLkTikhygNpXrC=TaGuxWgiQsV0g7wUTQ@mail.gmail.com' \
--to=peter.maydell@linaro.org \
--cc=agraf@suse.de \
--cc=qemu-devel@nongnu.org \
--cc=stefano.stabellini@eu.citrix.com \
--cc=xen-devel@lists.xensource.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).