From: Paolo Bonzini <pbonzini@redhat.com>
To: Igor Mammedov <imammedo@redhat.com>,
David Gibson <david@gibson.dropbear.id.au>
Cc: qemu-devel@nongnu.org, qemu-ppc@nongnu.org, ehabkost@redhat.com,
bharata@linux.vnet.ibm.com
Subject: Re: [Qemu-devel] [PATCH] dimm: Correct type of MemoryHotplugState->base
Date: Fri, 22 Jan 2016 15:21:05 +0100 [thread overview]
Message-ID: <56A23AD1.20202@redhat.com> (raw)
In-Reply-To: <20160122110225.2f9ae2d1@nial.brq.redhat.com>
On 22/01/2016 11:02, Igor Mammedov wrote:
> On Thu, 21 Jan 2016 12:37:51 +1100
> David Gibson <david@gibson.dropbear.id.au> wrote:
>
>> The 'base' field of MemoryHotplugState is ram_addr_t, which indicates that
>> it exists in the abstract address space of RAM regions.
>>
>> However, the actual usage of this field indicates that it is a concrete
>> physical address (it's passed as an offset to memory_region_add_subgregion
>> for example).
>>
>> So, correct its type to 'hwaddr'.
>>
>> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
>> ---
>> include/hw/mem/pc-dimm.h | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/include/hw/mem/pc-dimm.h b/include/hw/mem/pc-dimm.h
>> index d83bf30..218dfb0 100644
>> --- a/include/hw/mem/pc-dimm.h
>> +++ b/include/hw/mem/pc-dimm.h
>> @@ -77,7 +77,7 @@ typedef struct PCDIMMDeviceClass {
>> * @mr: hotplug memory address space container
>> */
>> typedef struct MemoryHotplugState {
>> - ram_addr_t base;
>> + hwaddr base;
>> MemoryRegion mr;
>> } MemoryHotplugState;
>>
>
> I agree with this fix but that's not the only place where
> ram_addr_t needs to be replaced with hwaddr.
> For example type of MachineState.[max]ram_size fields needs
> to be changed as well. Because QEMU builds without CONFIG_XEN_BACKEND
> on 32-bit hosts are broken since ram_addr_t is 32-bits there
> while some targets assume and use it as 64-bit one.
But on a 32-bit system without CONFIG_XEN_BACKEND you cannot allocate
more than 4G anyway, so the choice of ram_addr_t is understandable in
that case.
On the other hand, on a 32-bit system without CONFIG_XEN_BACKEND you
definitely can place 128M of hot plugged memory between say 4096MB and
4224MB.
Paolo
next prev parent reply other threads:[~2016-01-22 14:21 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-21 1:37 [Qemu-devel] [PATCH] dimm: Correct type of MemoryHotplugState->base David Gibson
2016-01-22 10:02 ` Igor Mammedov
2016-01-22 14:21 ` Paolo Bonzini [this message]
2016-01-22 14:32 ` Igor Mammedov
2016-02-01 2:33 ` David Gibson
2016-02-02 17:37 ` Eduardo Habkost
2016-02-03 5:08 ` David Gibson
2016-02-03 18:26 ` Eduardo Habkost
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=56A23AD1.20202@redhat.com \
--to=pbonzini@redhat.com \
--cc=bharata@linux.vnet.ibm.com \
--cc=david@gibson.dropbear.id.au \
--cc=ehabkost@redhat.com \
--cc=imammedo@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=qemu-ppc@nongnu.org \
/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.