Re: [PATCH v2 16/17] libxc/xc_dom_arm: Copy ACPI tables to guest space

[Boris Ostrovsky <boris.ostrovsky@oracle.com>]

On 07/13/2016 11:22 AM, Julien Grall wrote:
> Hello,
>
> On 12/07/2016 17:58, Boris Ostrovsky wrote:
>> On 07/12/2016 12:10 PM, Julien Grall wrote:
>>> 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.
>
> This would need to be clarified. For instance special pages (Xenstore,
> Console...) are RAM from the host point of view but not taken into
> account in the "maxmem" provided by the user. For my understanding,
> some kB of the slack is used for that.


Are these pages part of guest's address space?


>
>>
>>>
>>> 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.
>
> I don't think what I described in my previous mail is ARM-specific.
> The pressure will be more important on the TLBs, if Xen does not use
> superpage in the stage 2 page tables (i.e EPT for x86) no matter the
> architecture.
>
> IHMO, this seems to be a bigger drawback compare to add few more
> kilobytes to maxmem in the toolstack for the ACPI blob. You will loose
> them when creating the intermediate page table in any case.


Why not have the guest ask for more memory in the config file then?

(OK, I can see that they can't ask for a few KB since we have MB
resolution but they can ask for an extra 1MB)


>
> May I ask why you want to keep maxmem unchanged on x86?

Only to keep resource accounting fair. The guest may decide to use
memory reserved for ACPI as a regular memory.



-boris



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel