Re: [Xen-devel] [PATCH v2 01/20] x86: make hvm_{get/set}_param accessible

[Jan Beulich <JBeulich@xxxxxxxx>]

(re-sending, as I still don't see the mail having appeared on the list)

On 23.12.2019 15:55, Tamas K Lengyel wrote:
> On Mon, Dec 23, 2019 at 2:37 AM Jan Beulich <jbeulich@xxxxxxxx> wrote:
>>
>> On 20.12.2019 18:32, Andrew Cooper wrote:
>>> On 20/12/2019 17:27, Tamas K Lengyel wrote:
>>>> On Fri, Dec 20, 2019 at 9:47 AM Jan Beulich <jbeulich@xxxxxxxx> wrote:
>>>>> On 18.12.2019 20:40, Tamas K Lengyel wrote:
>>>>>> Currently the hvm parameters are only accessible via the HVMOP 
>>>>>> hypercalls. By
>>>>>> exposing hvm_{get/set}_param it will be possible for VM forking to copy 
>>>>>> the
>>>>>> parameters directly into the clone domain.
>>>>> Having peeked ahead at patch 17, where this gets used, I wonder why
>>>>> you want a pair of one-by-one functions, rather than a copy-all one.
>>>>> This then wouldn't require exposure of the functions you touch here.
>>>> Well, provided there is no such function in existence today it was
>>>> just easier to use what's already available. I still wouldn't want to
>>>> implement a one-shot function like that because this same code-path is
>>>> shared by the save-restore operations on the toolstack side, so at
>>>> least I have a reasonable assumption that it won't break on me in the
>>>> future.
>>>
>>> In particular, a number of the set operations are distinctly
>>> non-trivial.
>>
>> How is trivial or not related to there being one function doing
>> the looping wanted here vs the looping being done by the caller
>> around the two per-entity calls?
> 
> I don't really get why would it matter where the looping is being
> done? Even if I were to add a single function to do this, it would do
> the same looping and just call the now internally kept get/set params
> functions.

The difference (to me) is what level of control gets exposed outside
of the file. For example I also dislike external code doing this
somewhat odd (but necessary as per your communication with Andrew)
checking against zero values. Such are implementation details which
would better not be scatter around.

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