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

[Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>]

On 07/12/2016 11:13 AM, Wei Liu wrote:
> On Tue, Jul 12, 2016 at 11:08:47AM -0400, 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?
> Hmm... I would like to think a bit more about this. But before dwelling
> on this too much...
>
>> 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.
>>
> This is an interesting point. If there is already such resolution I will
> be happy to follow it.
>
> Any reference?

The last one (that I can find) is
   
https://lists.xenproject.org/archives/html/xen-devel/2016-07/msg00821.html

(conveniently in the same thread is the one we have been using to talk
about licensing)

-boris



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