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

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

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


Xen-devel mailing list



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