qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Richard Henderson <richard.henderson@linaro.org>
To: "Philippe Mathieu-Daudé" <f4bug@amsat.org>,
	"Peter Maydell" <peter.maydell@linaro.org>
Cc: "Aleksandar Rikalo" <aleksandar.rikalo@syrmia.com>,
	"David Hildenbrand" <david@redhat.com>,
	"Cornelia Huck" <cohuck@redhat.com>,
	"QEMU Developers" <qemu-devel@nongnu.org>,
	"Beniamino Galvani" <b.galvani@gmail.com>,
	qemu-s390x <qemu-s390x@nongnu.org>,
	qemu-arm <qemu-arm@nongnu.org>,
	"Hervé Poussineau" <hpoussin@reactos.org>,
	"Gerd Hoffmann" <kraxel@redhat.com>,
	"Paolo Bonzini" <pbonzini@redhat.com>,
	"Richard Henderson" <rth@twiddle.net>
Subject: Re: [PATCH 5/6] exec: Restrict 32-bit CPUs to 32-bit address space
Date: Mon, 1 Jun 2020 17:01:52 -0700	[thread overview]
Message-ID: <eddd2573-84cc-dcd3-09b0-85c6ba989721@linaro.org> (raw)
In-Reply-To: <2e78619d-543b-55b7-f241-7652274fcf4a@amsat.org>

On 6/1/20 1:09 AM, Philippe Mathieu-Daudé wrote:
> On 5/31/20 9:09 PM, Peter Maydell wrote:
>> On Sun, 31 May 2020 at 18:54, Philippe Mathieu-Daudé <f4bug@amsat.org> wrote:
>>>
>>> It is pointless to have 32-bit CPUs see a 64-bit address
>>> space, when they can only address the 32 lower bits.
>>>
>>> Only create CPU address space with a size it can address.
>>> This makes HMP 'info mtree' command easier to understand
>>> (on 32-bit CPUs).
>>
>>> diff --git a/exec.c b/exec.c
>>> index 5162f0d12f..d6809a9447 100644
>>> --- a/exec.c
>>> +++ b/exec.c
>>> @@ -2962,9 +2962,17 @@ static void tcg_commit(MemoryListener *listener)
>>>
>>>  static void memory_map_init(void)
>>>  {
>>> +    uint64_t system_memory_size;
>>> +
>>> +#if TARGET_LONG_BITS >= 64
>>> +    system_memory_size = UINT64_MAX;
>>> +#else
>>> +    system_memory_size = 1ULL << TARGET_LONG_BITS;
>>> +#endif
>>
>> TARGET_LONG_BITS is a description of the CPU's virtual
>> address size; but the size of the system_memory memory
>> region is related to the CPU's physical address size[*].
> 
> OK I misunderstood it was the physical size, not virtual.

It is the physical size.

In the armv7 case, the lpae page table entry maps a 32-bit virtual address to a
40-bit physical address.  The i686 page table extensions do something similar.

See TARGET_PHYS_ADDR_SPACE_BITS.


r~


  parent reply	other threads:[~2020-06-02  0:03 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-31 17:54 [PATCH 0/6] exec/memory: Rework some address and access size limits Philippe Mathieu-Daudé
2020-05-31 17:54 ` [PATCH 1/6] target/s390x/mmu_helper: Use address_space_rw() in place Philippe Mathieu-Daudé
2020-06-02  7:11   ` David Hildenbrand
2020-05-31 17:54 ` [PATCH 2/6] hw/dma/rc4030: Use DMA address space to do DMA accesses Philippe Mathieu-Daudé
2020-05-31 17:54 ` [PATCH 3/6] hw/sd/allwinner-sdhost: Do DMA accesses via DMA address space Philippe Mathieu-Daudé
2020-05-31 19:31   ` Philippe Mathieu-Daudé
2020-05-31 17:54 ` [PATCH 4/6] exec/cpu-common: Do not restrict CPU to 32-bit memory access maximum Philippe Mathieu-Daudé
2020-05-31 19:41   ` Peter Maydell
2020-06-01  7:30     ` Philippe Mathieu-Daudé
2020-05-31 17:54 ` [PATCH 5/6] exec: Restrict 32-bit CPUs to 32-bit address space Philippe Mathieu-Daudé
2020-05-31 19:09   ` Peter Maydell
2020-06-01  8:09     ` Philippe Mathieu-Daudé
2020-06-01 10:45       ` Peter Maydell
2020-06-02  0:01       ` Richard Henderson [this message]
2020-05-31 17:54 ` [RFC PATCH 6/6] memory: Use CPU register size as default access_size_max Philippe Mathieu-Daudé
2020-05-31 19:14   ` Peter Maydell
2020-06-01  8:13     ` Philippe Mathieu-Daudé
2020-05-31 18:31 ` [PATCH 0/6] exec/memory: Rework some address and access size limits no-reply

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=eddd2573-84cc-dcd3-09b0-85c6ba989721@linaro.org \
    --to=richard.henderson@linaro.org \
    --cc=aleksandar.rikalo@syrmia.com \
    --cc=b.galvani@gmail.com \
    --cc=cohuck@redhat.com \
    --cc=david@redhat.com \
    --cc=f4bug@amsat.org \
    --cc=hpoussin@reactos.org \
    --cc=kraxel@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-arm@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-s390x@nongnu.org \
    --cc=rth@twiddle.net \
    /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).