From: "Andreas Färber" <afaerber@suse.de>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: qiaonuohan@cn.fujitsu.com, qemu-devel@nongnu.org, lcapitulino@redhat.com
Subject: Re: [Qemu-devel] [PATCH qom-cpu v4 17/18] memory_mapping: Use hwaddr type for MemoryMapping virt_addr field
Date: Sun, 09 Jun 2013 19:25:32 +0200 [thread overview]
Message-ID: <51B4BA8C.3070601@suse.de> (raw)
In-Reply-To: <CAFEAcA88A-J8FpEKg4ofsmB4rEGRKP8V5OasGZ7LM+_aARYpdQ@mail.gmail.com>
Am 09.06.2013 19:17, schrieb Peter Maydell:
> On 9 June 2013 17:10, Andreas Färber <afaerber@suse.de> wrote:
>> The memory mapping API uses hwaddr, so use it in the struct, too.
>> This avoids a header dependency on target_ulong type.
>
>> --- a/include/sysemu/memory_mapping.h
>> +++ b/include/sysemu/memory_mapping.h
>> @@ -20,7 +20,7 @@
>> /* The physical and virtual address in the memory mapping are contiguous. */
>> typedef struct MemoryMapping {
>> hwaddr phys_addr;
>> - target_ulong virt_addr;
>> + hwaddr virt_addr;
>> ram_addr_t length;
>
> This seems kind of odd given that HACKING specifically
> says that target_ulong is for virtual addresses and hwaddr
> for physical addresses. And in fact all the places that call
> memory_mapping_list_add_merge_sorted() actually pass a
> target_ulong as the virt_addr parameter, so maybe what we
> should be fixing is the function prototype?
Maybe. The benefit with going with the overwhelming use of hwaddr is
that memory_mapping.o can be compiled once for all targets, saving
compilation time.
The benefit of target_ulong would be saving a few bytes for 32-bit
targets at runtime.
> Incidentally that use of ram_addr_t for length looks
> kind of suspicious to me; it should probably be a hwaddr.
Looking at it strictly from a CPU and build perspective I'll happily
leave further code cleanups to someone else. :) Somewhere there's also a
misspelling of "memory" left to fix.
Andreas
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
next prev parent reply other threads:[~2013-06-09 17:25 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-09 16:10 [Qemu-devel] [PATCH qom-cpu v4 00/18] dump: Build cleanups, redone Andreas Färber
2013-06-09 16:10 ` [Qemu-devel] [PATCH qom-cpu v4 01/18] dump: Move stubs into libqemustub.a Andreas Färber
2013-06-09 16:10 ` [Qemu-devel] [PATCH qom-cpu v4 02/18] pc: Fix crash when attempting to hotplug CPU with negative ID Andreas Färber
2013-06-09 16:10 ` [Qemu-devel] [PATCH qom-cpu v4 03/18] pc: Create pc-*-1.6 machine-types Andreas Färber
2013-06-09 16:10 ` [Qemu-devel] [PATCH qom-cpu v4 04/18] target-i386: Update model values on Conroe/Penryn/Nehalem CPU models Andreas Färber
2013-06-09 16:10 ` [Qemu-devel] [PATCH qom-cpu v4 05/18] target-i386: Set level=4 on Conroe/Penryn/Nehalem Andreas Färber
2013-06-09 16:10 ` [Qemu-devel] [PATCH qom-cpu v4 06/18] target-i386: cpu: Fix potential buffer overrun in get_register_name_32() Andreas Färber
2013-06-09 16:10 ` [Qemu-devel] [PATCH qom-cpu v4 07/18] cpu: Turn cpu_paging_enabled() into a CPUState hook Andreas Färber
2013-06-11 8:06 ` Jens Freimann
2013-06-11 14:52 ` Luiz Capitulino
2013-06-09 16:10 ` [Qemu-devel] [PATCH qom-cpu v4 08/18] memory_mapping: Move MemoryMappingList typedef to qemu/typedefs.h Andreas Färber
2013-06-09 16:10 ` [Qemu-devel] [PATCH qom-cpu v4 09/18] cpu: Turn cpu_get_memory_mapping() into a CPUState hook Andreas Färber
2013-06-11 9:20 ` Jens Freimann
2013-06-11 14:56 ` Luiz Capitulino
2013-06-11 16:03 ` Andreas Färber
2013-06-09 16:10 ` [Qemu-devel] [PATCH qom-cpu v4 10/18] memory_mapping: Drop qemu_get_memory_mapping() stub Andreas Färber
2013-06-09 16:10 ` [Qemu-devel] [PATCH qom-cpu v4 11/18] dump: Drop qmp_dump_guest_memory() stub and build for all targets Andreas Färber
2013-06-09 16:10 ` [Qemu-devel] [PATCH qom-cpu v4 12/18] cpu: Change default for CPUClass::get_paging_enabled() Andreas Färber
2013-06-11 9:00 ` Jens Freimann
2013-06-11 15:01 ` Luiz Capitulino
2013-06-09 16:10 ` [Qemu-devel] [PATCH qom-cpu v4 13/18] memory_mapping: Cleanup qemu_get_guest_memory_mapping() Andreas Färber
2013-06-11 15:52 ` Luiz Capitulino
2013-06-11 17:47 ` Andreas Färber
2013-06-09 16:10 ` [Qemu-devel] [PATCH qom-cpu v4 14/18] dump: Abstract dump_init() with cpu_synchronize_all_states() Andreas Färber
2013-06-11 15:55 ` Luiz Capitulino
2013-06-11 17:46 ` Andreas Färber
2013-06-09 16:10 ` [Qemu-devel] [PATCH qom-cpu v4 15/18] dump: Abstract dump_init() further with qemu_for_each_cpu() Andreas Färber
2013-06-11 15:55 ` Luiz Capitulino
2013-06-09 16:10 ` [Qemu-devel] [PATCH qom-cpu v4 16/18] dump: Abstract write_elf{64, 32}_notes() " Andreas Färber
2013-06-09 16:10 ` [Qemu-devel] [PATCH qom-cpu v4 17/18] memory_mapping: Use hwaddr type for MemoryMapping virt_addr field Andreas Färber
2013-06-09 17:17 ` Peter Maydell
2013-06-09 17:25 ` Andreas Färber [this message]
2013-06-09 16:10 ` [Qemu-devel] [PATCH qom-cpu v4 18/18] memory_mapping: Build only once Andreas Färber
2013-06-09 17:29 ` Peter Maydell
2013-06-09 17:36 ` Andreas Färber
2013-06-09 16:19 ` [Qemu-devel] [PATCH qom-cpu v4 00/18] dump: Build cleanups, redone Andreas Färber
2013-06-11 16:54 ` Andreas Färber
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=51B4BA8C.3070601@suse.de \
--to=afaerber@suse.de \
--cc=lcapitulino@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=qiaonuohan@cn.fujitsu.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.