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?
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. -boris _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
