On Mon, 18 Sept, 2023, 3:41 pm Ani Sinha, <anisi...@redhat.com> wrote:
> > > On Mon, 18 Sept, 2023, 3:39 pm David Hildenbrand, <da...@redhat.com> > wrote: > >> On 18.09.23 12:07, Ani Sinha wrote: >> > >> > >> > On Mon, 18 Sept, 2023, 3:03 pm David Hildenbrand, <da...@redhat.com >> > <mailto:da...@redhat.com>> wrote: >> > >> > >> >> > >>>> /* >> > >>>> * The 64bit pci hole starts after "above 4G RAM" and >> > >>>> * potentially the space reserved for memory hotplug. >> > >>>> */ >> > >>>> >> > >>>> There is the >> > >>>> ROUND_UP(hole64_start, 1 * GiB); >> > >>>> in there that is not really required for the !hole64 case. It >> > >>>> shouldn't matter much in practice I think (besides an aligned >> > value >> > >>>> showing up in the error message). >> > >>>> >> > >>>> We could factor out most of that calculation into a >> > >>>> separate function, skipping that alignment to make that >> > >>>> clearer. >> > >>> Yeah this whole memory segmentation is quite complicated and >> > might benefit from a qemu doc or a refactoring. >> > >> >> > >> Absolutely. Do you have time to work on that (including the >> > updated fix?). >> > > >> > > Other than the fix you proposed I am not sure if we need to fix >> > anything else atm. Seems physical address space bound checks are >> > already in place. >> > > Re: doc, maybe. I will add it to my TODO list. >> > >> > Will you send a proper patch, ideally not using >> pc_pci_hole64_start() >> > but instead the same logic without the final alignment to 1 GiB? >> > >> > >> > I'll send. No problem. Could you answer my other question please ? >> >> Sorry, which one did I miss > > Ok hopefully my last question. I am still confused on something. Does the above mean that the hole64 will actually start from an address that is beyond maxram? Like basically if you added all of ram_below_4G, ram_above_4G, hot plug_mem and pci_hole64 then can it exceed maxram? I think it will. Does this not an issue? >>
