Re: [Xen-devel] [RFC] When to use "domain creation flag" or "HVM param"?
On 24/02/15 10:31, Jan Beulich wrote: On 24.02.15 at 11:24, wrote: >> At 15:08 -0500 on 23 Feb (1424700515), Don Slutz wrote: >>> Currently Jan Beulich is not happy with the addition of a new domain >>> creation flag. Andrew Cooper is not happy with a HVM param. I am stuck >>> in the middle. >> I prefer a new flag, for anything that's fixed for the life of the >> domain. We've already had too many bugs where HVM params changed >> when people thought they wouldn't. >> >> Jan, is your objection that we'll run out of XEN_DOMCTL_CDF_* bits? I >> think we can add more flag fields to DOMCTL_createdomain (or a v2) if >> that becomes a problem. > In a couple of years we may end up with an x86-CPUID-like mess > of hundreds of flags. And apart from that scalability issue I also > dislike the gross mixing of arch specific and generic flags here. > Perhaps the already arch-specific XEN_DOMCTL_configure_domain > would be the better route then if HVM params are being disliked? Given some recent consideration to the problem of domain architectural state (x86 cpuid policy, arm gic/spi), a (set of?) configuration hypercalls valid only during domain construction would perhaps be the best way to proceed. Extending createdomain itself is incompatible with XSM disaggregation and having the architectural state in the migration stream. The vmware backdoor is however slightly more complicated, in that it also involves qemu. What would be the effects be for a domain where Xen believes the backdoor is active, but qemu is not running appropriately? ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC] When to use "domain creation flag" or "HVM param"?
On 02/24/15 05:50, Andrew Cooper wrote: > On 24/02/15 10:31, Jan Beulich wrote: > On 24.02.15 at 11:24, wrote: >>> At 15:08 -0500 on 23 Feb (1424700515), Don Slutz wrote: Currently Jan Beulich is not happy with the addition of a new domain creation flag. Andrew Cooper is not happy with a HVM param. I am stuck in the middle. > The vmware backdoor is however slightly more complicated, in that it > also involves qemu. What would be the effects be for a domain where Xen > believes the backdoor is active, but qemu is not running appropriately? > Right now for a QEMU that does not support vmport=on as a machine property, QEMU will terminate and the domain will not be created. If QEMU is started without this and Xen then activates the backdoor, QEMU will act like any other unsupported ioport access. This does mean that you will lose the use of a mouse under current Xorg GUI. I have not tried to hot-plug the vmport and vmmouse devices in QEMU. That may take some changes to work. -Don Slutz > ~Andrew > ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC] When to use "domain creation flag" or "HVM param"?
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. Regards Lars On 26/02/2015 10:52, "Tim Deegan" wrote: >At 10:50 + on 24 Feb (1424771408), Andrew Cooper wrote: >> On 24/02/15 10:31, Jan Beulich wrote: >> On 24.02.15 at 11:24, wrote: >> >> At 15:08 -0500 on 23 Feb (1424700515), Don Slutz wrote: >> >>> Currently Jan Beulich is not happy with the addition of a new domain >> >>> creation flag. Andrew Cooper is not happy with a HVM param. I am >>stuck >> >>> in the middle. >> >> I prefer a new flag, for anything that's fixed for the life of the >> >> domain. We've already had too many bugs where HVM params changed >> >> when people thought they wouldn't. >> >> >> >> Jan, is your objection that we'll run out of XEN_DOMCTL_CDF_* bits? >>I >> >> think we can add more flag fields to DOMCTL_createdomain (or a v2) if >> >> that becomes a problem. >> > In a couple of years we may end up with an x86-CPUID-like mess >> > of hundreds of flags. And apart from that scalability issue I also >> > dislike the gross mixing of arch specific and generic flags here. >> > Perhaps the already arch-specific XEN_DOMCTL_configure_domain >> > would be the better route then if HVM params are being disliked? >> >> Given some recent consideration to the problem of domain architectural >> state (x86 cpuid policy, arm gic/spi), a (set of?) configuration >> hypercalls valid only during domain construction would perhaps be the >> best way to proceed. > >That sounds like you're also arguing for using HVM params then. :) > >The nice thing about having a single set of flags at creation time is >that it avoids any worrying about what order the flag-setting and the >init of VM state happens in (e.g. turning on a feature after vcpus are >already assigned means extra code to update them; having the features >be settable in any order means handling all O(N^2) interactions). > >> Extending createdomain itself is incompatible with XSM disaggregation > >Hrm. Possibly, but I think that might be splitting hairs. >A privileged VM creation component will already have to check its >arguments (e.g. memory size, #vcpus, boot image) against some policy. > >> and having the architectural state in the migration stream. > >Not at all -- since these flags are immutable, you can trivially send >them before any other state. If a toolstack can't remember what it >did, we could add a what-were-the-creation-flags domctl. > >Tim. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC] When to use "domain creation flag" or "HVM param"?
At 10:50 + on 24 Feb (1424771408), Andrew Cooper wrote: > On 24/02/15 10:31, Jan Beulich wrote: > On 24.02.15 at 11:24, wrote: > >> At 15:08 -0500 on 23 Feb (1424700515), Don Slutz wrote: > >>> Currently Jan Beulich is not happy with the addition of a new domain > >>> creation flag. Andrew Cooper is not happy with a HVM param. I am stuck > >>> in the middle. > >> I prefer a new flag, for anything that's fixed for the life of the > >> domain. We've already had too many bugs where HVM params changed > >> when people thought they wouldn't. > >> > >> Jan, is your objection that we'll run out of XEN_DOMCTL_CDF_* bits? I > >> think we can add more flag fields to DOMCTL_createdomain (or a v2) if > >> that becomes a problem. > > In a couple of years we may end up with an x86-CPUID-like mess > > of hundreds of flags. And apart from that scalability issue I also > > dislike the gross mixing of arch specific and generic flags here. > > Perhaps the already arch-specific XEN_DOMCTL_configure_domain > > would be the better route then if HVM params are being disliked? > > Given some recent consideration to the problem of domain architectural > state (x86 cpuid policy, arm gic/spi), a (set of?) configuration > hypercalls valid only during domain construction would perhaps be the > best way to proceed. That sounds like you're also arguing for using HVM params then. :) The nice thing about having a single set of flags at creation time is that it avoids any worrying about what order the flag-setting and the init of VM state happens in (e.g. turning on a feature after vcpus are already assigned means extra code to update them; having the features be settable in any order means handling all O(N^2) interactions). > Extending createdomain itself is incompatible with XSM disaggregation Hrm. Possibly, but I think that might be splitting hairs. A privileged VM creation component will already have to check its arguments (e.g. memory size, #vcpus, boot image) against some policy. > and having the architectural state in the migration stream. Not at all -- since these flags are immutable, you can trivially send them before any other state. If a toolstack can't remember what it did, we could add a what-were-the-creation-flags domctl. Tim. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC] When to use "domain creation flag" or "HVM param"?
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. I hope this will help to sort out a good approach for both ARM and x86. Regards, [1] http://lists.xen.org/archives/html/xen-devel/2014-11/msg00522.html [2] http://lists.xen.org/archives/html/xen-devel/2015-01/msg01184.html -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC] When to use "domain creation flag" or "HVM param"?
At 15:33 + 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@lists.xen.org http://lists.xen.org/xen-devel
