qemu-devel
[Top][All Lists]
Advanced

[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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]