On 07/12/2016 11:13 AM, Wei Liu wrote: > On Tue, Jul 12, 2016 at 11:08:47AM -0400, Boris Ostrovsky wrote: >> On 07/12/2016 10:57 AM, Shannon Zhao wrote: >>> On 2016年07月12日 22:50, Wei Liu wrote: >>>> On Tue, Jul 12, 2016 at 10:42:07PM +0800, Shannon Zhao wrote: >>>>>>>>>>>>>>>>>>>>>>>> Does it mean we would need to update the slack to take >>>>>>>>>>>>>>>>>>>>>>>> into account the ACPI >>>>>>>>>>>>>>>>>>>>>>>> blob? >>>>>>>>>>>>>>>> Yes, we need to take into account the ACPI blob. Probably not >>>>>>>>>>>>>>>> in the >>>>>>>>>>>>>>>> slack but directly in mam_memkb. >>>>>>>>>>>> Sorry, I'm not sure understand this. I found the b_info->max_memkb >>>>>>>>>>>> but >>>>>>>>>>>> didn't find the slack you said. And how to fix this? Update >>>>>>>>>>>> b_info->max_memkb or the slack? >>>>>>>> Can you calculate the size of your payload and add that to max_memkb? >>>>>>>> >>>>>> Yeah, but the size will be changed if we change the tables in the future >>>>>> and this also should consider x86, right? >>>> That could easily be solved by introducing a function to calculate the >>>> size, right? >>> Oh, I'm not familiar with this. Let's clarify on this. It can add the >>> size to max_memkb after generating the ACPI tables and before loading >>> the tables to guest space and it doesn't have to add the size at >>> libxl__domain_build_info_setdefault(), right? > Hmm... I would like to think a bit more about this. But before dwelling > on this too much... > >> This was discussed before: ACPI tables are part of RAM whose size is >> specified by the config file (and is reflected in max_memkb I believe). >> It may not be presented to the guest as RAM (i.e. on x86 it is labeled >> by BIOS (or whoever) as a dedicated type in e820) but it still resides >> in DIMMs. >> >> I believe we should not increase memory resources for ACPI tables. >> > This is an interesting point. If there is already such resolution I will > be happy to follow it. > > Any reference?
The last one (that I can find) is https://lists.xenproject.org/archives/html/xen-devel/2016-07/msg00821.html (conveniently in the same thread is the one we have been using to talk about licensing) -boris _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
