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?




> --
> Cheers,
>
> David / dhildenb
>
>

Reply via email to