[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH v4 06/18] x86/mem_sharing: define mem_sharing_domain to hold some scattered variables



On 16.01.2020 17:05, Tamas K Lengyel wrote:
> On Thu, Jan 16, 2020 at 8:23 AM Jan Beulich <jbeulich@xxxxxxxx> wrote:
>>
>> On 08.01.2020 18:14, Tamas K Lengyel wrote:
>>> Create struct mem_sharing_domain under hvm_domain and move mem sharing
>>> variables into it from p2m_domain and hvm_domain.
>>>
>>> Expose the mem_sharing_enabled macro to be used consistently across Xen.
>>>
>>> Remove some duplicate calls to mem_sharing_enabled in mem_sharing.c
>>>
>>> Signed-off-by: Tamas K Lengyel <tamas.lengyel@xxxxxxxxx>
>>
>> Acked-by: Jan Beulich <jbeulich@xxxxxxxx>
>> with one question:
>>
>>> @@ -192,6 +192,10 @@ struct hvm_domain {
>>>          struct vmx_domain vmx;
>>>          struct svm_domain svm;
>>>      };
>>> +
>>> +#ifdef CONFIG_MEM_SHARING
>>> +    struct mem_sharing_domain mem_sharing;
>>> +#endif
>>
>> Are you intending to add fields to this new struct? If so,
>> should the field here become a pointer, and the structure
>> allocated only when actually needed?
>>
> 
> At the moment there are no additional variables planned to be added.
> If/when we do we can consider turning this into a pointer, at which
> point we can also get rid of the "enabled" field and turn the
> mem_sharing_enabled macro into a NULL-pointer check instead. For now I
> wouldn't bother because its not like we save much by doing so.

Thanks for clarifying.

Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel

 


Rackspace

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