On 6/17/22 13:32, Igor Mammedov wrote: > On Fri, 17 Jun 2022 13:18:38 +0100 > Joao Martins <joao.m.mart...@oracle.com> wrote: >> On 6/16/22 15:23, Igor Mammedov wrote: >>> On Fri, 20 May 2022 11:45:31 +0100 >>> Joao Martins <joao.m.mart...@oracle.com> wrote: >>>> + hwaddr above_4g_mem_start, >>>> + uint64_t pci_hole64_size) >>>> +{ >>>> + PCMachineClass *pcmc = PC_MACHINE_GET_CLASS(pcms); >>>> + X86MachineState *x86ms = X86_MACHINE(pcms); >>>> + MachineState *machine = MACHINE(pcms); >>>> + ram_addr_t device_mem_size = 0; >>>> + hwaddr base; >>>> + >>>> + if (!x86ms->above_4g_mem_size) { >>>> + /* >>>> + * 32-bit pci hole goes from >>>> + * end-of-low-ram (@below_4g_mem_size) to IOAPIC. >>>> + */ >>>> + return IO_APIC_DEFAULT_ADDRESS - 1; >>> >>> lack of above_4g_mem, doesn't mean absence of device_mem_size or anything >>> else >>> that's located above it. >>> >> >> True. But the intent is to fix 32-bit boundaries as one of the qtests was >> failing >> otherwise. We won't hit the 1T hole, hence a nop. > > I don't get the reasoning, can you clarify it pls? >
I was trying to say that what lead me here was a couple of qtests failures (from v3->v4). I was doing this before based on pci_hole64. phys-bits=32 was for example one of the test failures, and pci-hole64 sits above what 32-bit can reference. >> Unless we plan on using >> pc_max_used_gpa() for something else other than this. > > Even if '!above_4g_mem_sizem', we can still have hotpluggable memory region > present and that can hit 1Tb. The same goes for pci64_hole if it's configured > large enough on CLI. > So hotpluggable memory seems to assume it sits above 4g mem. pci_hole64 likewise as it uses similar computations as hotplug. Unless I am misunderstanding something here. > Looks like guesstimate we could use is taking pci64_hole_end as max used GPA > I think this was what I had before (v3[0]) and did not work. Let me revisit this edge case again. [0] https://lore.kernel.org/all/20220223184455.9057-5-joao.m.mart...@oracle.com/