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

[Julien Grall <julien.grall@xxxxxxxxxx>]

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

> 
>> 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.

I will use "may be required".

> 
>> than asking them to take care of the arch-specific domain configuration, let
>> the current function (xc_domain_create) to chose a default configuration and
> 
> s/to//
> 
>> introduce a new one (xc_domain_create_config).
>>
>> This patch also drop the previously DOMCTL arm_configure_domain introduced
> 
> "drops the previously introduced DOMCTL arm...".
> 
>> in Xen 4.5, as it has been made useless.
>>
>> Signed-off-by: Julien Grall <julien.grall@xxxxxxxxxx>
>> Cc: Daniel De Graaf <dgdegra@xxxxxxxxxxxxx>
>> Cc: Ian Jackson <ian.jackson@xxxxxxxxxxxxx>
>> Cc: Wei Liu <wei.liu2@xxxxxxxxxx>
>> Cc: Stefano Stabellini <stefano.stabellini@xxxxxxxxxx>
>> Cc: Keir Fraser <keir@xxxxxxx>
>> Cc: Jan Beulich <jbeulich@xxxxxxxx>
>> Cc: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
>> Cc: George Dunlap <george.dunlap@xxxxxxxxxxxxx>
>>
>> ---
>>     This is a follow-up of 
>> http://lists.xen.org/archives/html/xen-devel/2014-11/msg00522.html
>>
>>     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.


> 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 we have to do is moving this internal information to the global
structure... That wouldn't be too bad because sooner or later we will
have to let the user choose between vGICv2 and vGICv3.

Regards,

-- 
Julien Grall

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