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

[Tamas K Lengyel <tamas.k.lengyel@xxxxxxxxx>]

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.

Tamas

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