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 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).