[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v2 16/17] libxc/xc_dom_arm: Copy ACPI tables to guest space
Hello, On 12/07/2016 16:08, 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?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 don't think this was the conclusion of the thread. IHMO, "maxmem" is the amount of RAM a guest could effectively use. Whilst the ACPI tables will be in the DIMM from the host point of view. From a guest point of view it will be a ROM. It will affect some others part of the guest if we don't increment the "maxmem" requested by the user. For ARM the ACPI blob will be exposed at a specific address that is outside of the guest RAM (see the guest memory layout in public/arch-arm.h). We chose this solution over putting in the RAM because the ACPI tables are not easily relocatable (compare to the device tree, initrd and kernel) so we could not take advantage of superpage in both stage-2 (hypervisor) and stage-1 (kernel) page table. To give you a concrete example. When the user requests 1 gigabytes of memory, Xen will try to allocate a 1 gigabytes superpage. If few kilobytes is removed from this 1 gigabytes, then we would have to use 2MB superpage which will impact both performance and memory usage. So I think we should take into account the size of the ACPI blob in libxl and not reduce the memory requested by the user. Regards, -- Julien Grall _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |