Re: [Xen-devel] [PATCH v3 01/24] xen: Extend DOMCTL createdomain to support arch configuration

[Ian Campbell <ian.campbell@xxxxxxxxxx>]

On Mon, 2015-02-23 at 15:48 +0000, Andrew Cooper wrote:
> GIC version and SPIs should absolutely be part of the migration stream. 
> They are domain architectural state.

Of course, the question is where.

They could be part of the Xen hvmsave blob for the GIC (i.e. along with
the other GIC architectural state such as which interrupts are currently
active,pending,masked etc).

Or they could be part of a new migration v2 record for such things.

Or they could be part of the hvm params migration record.

Or they could be part of the libxl json cfg blob, (but I think that
option is a bad one).

> I have a similar issue with my plans for cpuid improvements in x86, and
> was going to introduce a domain architectural state near the head of the
> migration stream.  (There is currently a chicken & egg problem in x86
> with the hvm params, the cpu state and the cpuid policy.  In Xen, we
> currently check the cpu state for plausibility because it is not
> currently possible to load the policy before xc_domain_restore() is
> complete.)
> 
> 
> At first glance, extending createdomian would look like a sensible
> action to ensure that these bits of state get set appropriately.  A
> consequence would be that the createdomain hypercall must move down into
> xc_domain_restore(), which causes problems in the XSM case (where the
> permissions are along the lines of "sub builder $X is permitted to issue
> hypercalls on domid $Y).
> 
> An alternative is instead to move more of domain construction into the
> xc_domain_restore(), so architectural state from the stream can be used
> to construct the domain.  (For x86 cpuid, I believe I need to set part
> of the architectural state before the set_max_vcpus hypercall, and I
> certainly need to propagate maxphysaddr from the source before I can
> validate any memory frames in the stream.)
> 
> This would result in a leaning towards separate hypercalls.
> 
> ~Andrew
> _



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel