[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RFC] mem: Fix mem region size when is UINT64_MAX
From: |
Peter Maydell |
Subject: |
Re: [RFC] mem: Fix mem region size when is UINT64_MAX |
Date: |
Tue, 24 Oct 2023 14:21:57 +0100 |
On Tue, 24 Oct 2023 at 13:31, Antonio Caggiano
<quic_acaggian@quicinc.com> wrote:
>
>
>
> On 24/10/2023 14:00, Peter Maydell wrote:
> > On Tue, 24 Oct 2023 at 11:49, Antonio Caggiano
> > <quic_acaggian@quicinc.com> wrote:
> > Given that we don't run into this upstream, this leaves me
> > suspecting that the underlying problem is that a memory
> > region this big shouldn't be being registered to KVM in the
> > first place. Certainly the gpex PCI controller works fine
> > on the arm64 virt board under KVM, so maybe your board code
> > is doing something odd when it wires it up?
> I think so, we use a MMIO system_memory, effectively using
> memory_region_init_io() instead of memory_region_init(). This is for
> registering our callbacks with a MemoryRegionOps.
>
> So, for a MMIO memory type, UINT64_MAX means "real" size rather than
> "all of the 64 bit address space"?
For a memory region, in the creation APIs that take a uint64_t
size argument:
* size 0 is (I think) not valid
* 1..UINT64_MAX-1 mean "size is that many bytes"
* UINT64_MAX means "size is 2^64 bytes"
* there is no way to ask for (2^64)-1 bytes
I am confused about why you say your system_memory is an
MMIO region with callbacks, though. The system_memory MR
is expected to be a pure "container" region, which has
no callbacks and simply is a place where we add other
subregions (which might be RAM, or IO, or whatever).
thanks
-- PMM