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

[Ian Campbell <ian.campbell@citrix.com>]

On Fri, 2015-02-20 at 16:09 +0000, Julien Grall wrote:
> Hi Ian,
> 
> On 20/02/15 15:15, Ian Campbell wrote:
> > On Tue, 2015-01-13 at 14:25 +0000, Julien Grall wrote:
> >> On ARM the virtual GIC may differ between each guest (emulated GIC version,
> >> number of SPIs...). Those informations are already known at the domain creation
> > 
> > "This information is already known at domain creation..."
> > 
> >> and can never change.
> >>
> >> For now only the gic_version is set. In long run, there will be more parameters
> > 
> > "In the long run".
> > 
> >> such as the number of SPIs. All will be required to be set at the same time.
> >>
> >> A new arch-specific structure arch_domainconfig has been created, the x86
> >> one doesn't have any specific configuration, a dummy structure
> >> (C-spec compliant) has been created to factorize the code on the toolstack.
> > 
> > I'm not sure what you mean by factorize here.
> 
> There is an arch-specific function where

... truncated sentence?

> 
> > 
> >> Some external tools (qemu, xenstore) may require to create a domain. Rather
> > 
> > "may be required" perhaps? I'm not 100% sure what you are trying to say.
> 
> I meant some external tools (such as qemu, xenstore) needs to create
> domain. So we have to keep the old xc_domain_create.

FWIW libxc does not have a stable interface...

xenstore we could just update in lockstep since it is in the same tree.
(I suppose you are thinking of the stubdom launcher helper).

qemu -- well, I suppose if it is easy to keep it working we might as
well, although I'm not sure it's actually used/maintained (maybe this is
a good way to find out :-P).

> >>     TODO: What about migration? For now the configuration lives in internal
> >>     libxl structure. We need a way to pass the domain configuration to the
> >>     other end.
> > 
> > Things like the GIC version and number of SPIs would normally end up
> > being encoded in the hvm save records, i.e. the blob which Xen provides
> > to the toolstack to be included in the save stream. That would then be
> > alongside the actual related interrupt architectural state etc (e.g.
> > pending, active, masked etc).
> > 
> > That's problematic here because you can't pass that blob to the create
> > function and the toolstack cannot really parse the blob to figure out
> > the details to pass.
> 
> I was thinking to pass those information the same way we do to know the
> domain is a PVH/HVM...
> 
> AFAICT they are required in order to create the domain.

IIRC you said on Friday that you spoke with Andy Cooper and thought
about adding new records to the migration v2 format to allow such things
to be part of the migration stream (with requirements on the ordering).

> > Looking back at msg00522.html it does seem like migration is a good
> > motivation for doing it as a separate hypercall as you originally did,
> > so initial create would be
> > 	DOMCTL_create
> > 	DOMCTL_set_the_variables
> > and restore would be
> > 	DOMCTL_create
> > 	DOMCTL_restore_from_blob
> > 
> > In both cases this needn't preclude requiring the call to be made before
> > unpause or that it is only called exactly once.
> > 
> > Write once HVM params would be another option here.
> > 
> > Jan, do you find any of that convincing as to the need for doing this
> > outside the the create domctl? Based on msg00522 is seems you would
> > prefer some HVM params over a new domctl?
> 
> The problem with HVM params is we need to wait until every HVM
> parameters is set and we have to do it before vCPU are initialized.
> 
> The problem with a new DOMCTL is it make the code more complicate in the
> hypervisor as it require some kind of synchronization to know if
> everything as been correctly initialized.
> 
> > 
> >>     I'm not sure if we should care of this right now as migration doesn't
> >>     yet exists on ARM.
> > 
> > It's a domctl so we aren't exactly painting ourselves into a corner, but
> > it would be good to have some idea that we aren't going down a blind
> > alley at least. Especially if the way out of the alley is to come back
> > to where we are now...
> > 
> > (There doesn't seem much point in looking at the code until we conclude
> > the approach is correct, so I haven't)
> 
> I believe that the migration can be taken in different way without
> modifying the current approach.

What I meant was if that when implementing migration we end up back
where we started before this patch, because that approach turns out to
be the right one, then it's all a bit of a waste of time, so we should
try and understand at least to the level required to have a good feeling
we won't be doing that.

Ian.