Re: [Xen-devel] [PATCH v2 10/17] tools/libxl: Plumb a restore boolean down into libxl__build_pre()

[Ian Jackson <ian.jackson@xxxxxxxxxx>]

Andrew Cooper writes ("Re: [PATCH v2 10/17] tools/libxl: Plumb a restore 
boolean down into libxl__build_pre()"):
> On 24/02/2020 17:39, Ian Jackson wrote:
> > Maybe it would be better to pass this via libxl__domain_build_state
> > rather than as an additional parameter ?
> 
> Well - I tried a similar approach the first time around, and it broke
> stubdoms so badly it needed reverting.
> 
> (Untrim the commit details)
> 
> > v2:
> >  * New.  This is c/s aacc1430064 "tools/libxl: Plumb domain_create_state 
> > down
> >    into libxl__build_pre()" take-2, without any collateral damage to 
> > stubdoms.
> 
> The actual information we want is in libxl__domain_create_state
> (specifically, restore_fd >= -1).  I first tried plumbing dcs down, to
> avoid stashing the same information in two different structures at
> different times.
> 
> Sadly, plumbing dcs didn't work because it is common between the real
> domain and the stubdom (and this lead to the stubdom getting no settings
> at all).  What we want to do is only influence the CPUID construction of
> the main domain (which may be migrating in), whereas the stubdom always
> wants fresh settings.

Right.  Thanks for the explanation, which make sense to me.

> I could duplicate it into dbs, and at a guess that would probably work,
> but isn't it taking a bad problem and making it worse?

I think that is fine.

Conceptually I think it's like this:

These structs take place of huge lists of parameters.  When we create
a service domain, we need to pass a new list of parameters
(_build_state), we also pass some of the original ones
(_create_state).  If we are talking about parameters that need to be
different for a service domain, they should be in _build_state; even
if the main domain's version is effectively a copy of something in
_create_state.

So I think adding a "restoring" or "restore" boolean to dbs is
probably right.

Thanks,
Ian.

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