qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Jan Kiszka <jan.kiszka@web.de>
To: Alexander Graf <agraf@suse.de>
Cc: Stefan BOSAK <stefan.bosak@feikar.sk>,
	xen-devel Devel <xen-devel@lists.xensource.com>,
	"qemu-devel@nongnu.orgDevelopers Developers"
	<qemu-devel@nongnu.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Qemu-devel] [PATCH v2 4/5] exec.c: refactor cpu_physical_memory_map
Date: Tue, 12 Jul 2011 09:15:27 +0200	[thread overview]
Message-ID: <4E1BF48F.9060302@web.de> (raw)
In-Reply-To: <E667DF64-CA57-42E8-B565-887CCF79C8B8@suse.de>

[-- Attachment #1: Type: text/plain, Size: 2697 bytes --]

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@eu.citrix.com 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.
>>> 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@eu.citrix.com>
> 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@eu.citrix.com>
>     Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
>     Signed-off-by: Alexander Graf <agraf@suse.de>

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?

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

  reply	other threads:[~2011-07-12  7:15 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-05-19 17:34 [Qemu-devel] [PATCH v2 0/5] xen mapcache fixes and improvements Stefano Stabellini
2011-05-19 17:35 ` [Qemu-devel] [PATCH v2 1/5] xen: fix qemu_map_cache with size != MCACHE_BUCKET_SIZE stefano.stabellini
2011-05-19 17:35 ` [Qemu-devel] [PATCH v2 2/5] xen: remove qemu_map_cache_unlock stefano.stabellini
2011-05-19 17:35 ` [Qemu-devel] [PATCH v2 3/5] xen: remove xen_map_block and xen_unmap_block stefano.stabellini
2011-05-19 17:35 ` [Qemu-devel] [PATCH v2 4/5] exec.c: refactor cpu_physical_memory_map stefano.stabellini
2011-07-11 22:17   ` Jan Kiszka
2011-07-12  6:14     ` Alexander Graf
2011-07-12  6:21     ` Alexander Graf
2011-07-12  6:28     ` Alexander Graf
2011-07-12  7:15       ` Jan Kiszka [this message]
2011-07-12  7:18         ` Paolo Bonzini
2011-07-12  7:48           ` Markus Armbruster
2011-07-22  5:42   ` Liu Yu-B13201
2011-07-22  5:59     ` Alexander Graf
2011-07-22  6:14       ` Liu Yu-B13201
2011-05-19 17:35 ` [Qemu-devel] [PATCH v2 5/5] xen: mapcache performance improvements stefano.stabellini
2011-05-27 23:30 ` [Qemu-devel] [PATCH v2 0/5] xen mapcache fixes and improvements Alexander Graf

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=4E1BF48F.9060302@web.de \
    --to=jan.kiszka@web.de \
    --cc=agraf@suse.de \
    --cc=qemu-devel@nongnu.org \
    --cc=stefan.bosak@feikar.sk \
    --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).