qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] hw/i386/pc: fix max_used_gpa for 32-bit systems


From: David Hildenbrand
Subject: Re: [PATCH] hw/i386/pc: fix max_used_gpa for 32-bit systems
Date: Tue, 19 Sep 2023 09:42:54 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0

On 19.09.23 08:18, Ani Sinha wrote:
On Tue, Sep 19, 2023 at 9:53 AM Ani Sinha <anisinha@redhat.com> wrote:

On Tue, Sep 19, 2023 at 9:20 AM Ani Sinha <anisinha@redhat.com> wrote:

On Mon, Sep 18, 2023 at 9:28 PM David Hildenbrand <david@redhat.com> wrote:

On 18.09.23 17:56, Ani Sinha wrote:
On Mon, Sep 18, 2023 at 8:59 PM David Hildenbrand <david@redhat.com> wrote:

On 18.09.23 17:22, Ani Sinha wrote:
On Mon, Sep 18, 2023 at 7:25 PM Ani Sinha <anisinha@redhat.com> wrote:

32-bit systems do not have a reserved memory for hole64 but they may have a
reserved memory space for memory hotplug. Since, hole64 starts after the
reserved hotplug memory, the unaligned hole64 start address gives us the
end address for this memory hotplug region that the processor may use.
Fix this. This ensures that the physical address space bound checking works
correctly for 32-bit systems as well.

This patch breaks some unit tests. I am not sure why it did not catch
it when I tested it before sending.
Will have to resend after fixing the tests.

Probably because they supply more memory than the system can actually
handle? (e.g., -m 4g on 32bit)?

cxl tests are failing for example.

$ ./qemu-system-i386 -display none -machine q35,cxl=on
qemu-system-i386: Address space limit 0xffffffff < 0x1000fffff
phys-bits too low (32)

also another thing is:

./qemu-system-i386 -machine pc -m 128
works but ...

$ ./qemu-system-i386 -machine pc -m 128,slots=3,maxmem=1G
qemu-system-i386: Address space limit 0xffffffff < 0x1f7ffffff
phys-bits too low (32)

or

$ ./qemu-system-i386 -machine pc-i440fx-8.2 -accel kvm -m 128,slots=3,maxmem=1G
qemu-system-i386: Address space limit 0xffffffff < 0x1f7ffffff
phys-bits too low (32)

but of course after the compat knob older pc machines work fine using
the old logic :

$ ./qemu-system-i386 -machine pc-i440fx-8.1 -accel kvm -m 128,slots=3,maxmem=1G
VNC server running on ::1:5900
^Cqemu-system-i386: terminating on signal 2

I dpn't know if we always need to do this but this code adds 1 GiB per
slot for device memory :

     if (pcmc->enforce_aligned_dimm) {
          /* size device region assuming 1G page max alignment per slot */
          size += (1 * GiB) * machine->ram_slots;
      }

For a 32-bit machine that is a lot of memory consumed in just alignment.

Let's look at an example when we get rid of all alignment stuff.

$ ./qemu-system-i386 -machine pc-i440fx-8.2 -m 512M,slots=1,maxmem=1G
above 4G start: 0x100000000,above 4G size: 0x0
qemu-system-i386: Address space limit 0xffffffff < 0x11ffffffe
phys-bits too low (32)

So basically, above_4g_start = 4GiB. size = 0.
Then it is adding the device memory which is 1GiB - 0.5 GiB = 0.5 GiB.
So the  0x11ffffffe is exactly 4.5 GiB.

Anything above 4 GiB is beyond 32 bits.


It's not worth worrying about memory devices for 32bit at all. For example Linux doesn't support memory hotplug on any 32bit system (not even with PAE and friends).

--
Cheers,

David / dhildenb




reply via email to

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