[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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.