[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
On 07/12/2016 12:10 PM, Julien Grall wrote: > 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. The config file specifies resources provided by the host. How the guest views those resources is not important, I think. > > 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. Maybe this is something ARM-specific then. For x86 we will want to keep maxmem unchanged. -boris > > 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, > _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |