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

Re: [Xen-devel] [RFC] When to use "domain creation flag" or "HVM param"?



At 15:33 +0000 on 26 Feb (1424961188), Julien Grall wrote:
> Hi,
> 
> On 26/02/15 11:09, Lars Kurth wrote:
> > Tim, Andrew, Jan,
> > it seems as if we are slowly coming to some conclusion on this thread. If
> > I am mistaken, I am wondering whether it would make sense to have an IRC
> > meeting with all the involved stake-holders and report back to the list.
> 
> I'm not sure where I should answer...
> 
> We have a similar problem on ARM where we have arch-specific information
> (GIC version, number of interrupts) which changes between each domain.
> 
> On Xen 4.5, we took the approach to create a separate DOMCTL for passing
> information. It has to be called before any VCPUs is created
> (DOMCTL_set_max_vcpus) and make the code more complicate to handle
> because we have to defer some domain initialization.
> 
> I took another approach for Xen 4.6 based on Jan suggestion [1]. A v3 as
> been send recently [2] and we had some discussion about what is the best
> approach.

This line (adding these immutable config options at create time) seems
like a good one to me.

For migration, we'd need a hypercall that lets the Xen tools extract
the correct values to pass to the receiving Xen.  Xen would fill in
the actual values used for anything (like this GIC option) that
was set to 'default' or 'don't care' on the initial create op.

Andrew Cooper had some reasons why we might want to split this into a
bare create op (which might do no more than allocate a domid) and a
set-config op that would take these and all other immutable flags.
I'm not wild for that but could be convinced either way -- I'll let
him fill in the details.

Cheers,

Tim.

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


 


Rackspace

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