Re: [Xen-devel] DESIGN: CPUID part 3

2017-06-12 Thread Jan Beulich
>>> On 12.06.17 at 16:02, wrote: > My original statement was "if the guest uses LBR/LER, then migration > needs to be restricted to hardware with an identical LBR format". > > You countered that, saying we could emulate LBR/LER as an alternative. > The implication

Re: [Xen-devel] DESIGN: CPUID part 3

2017-06-12 Thread Andrew Cooper
On 12/06/17 14:42, Jan Beulich wrote: On 12.06.17 at 15:36, wrote: >> On 12/06/17 14:29, Jan Beulich wrote: >> On 12.06.17 at 15:07, wrote: On 08/06/17 14:47, Jan Beulich wrote: On 08.06.17 at 15:12,

Re: [Xen-devel] DESIGN: CPUID part 3

2017-06-12 Thread Jan Beulich
>>> On 12.06.17 at 15:36, wrote: > On 12/06/17 14:29, Jan Beulich wrote: > On 12.06.17 at 15:07, wrote: >>> On 08/06/17 14:47, Jan Beulich wrote: >>> On 08.06.17 at 15:12, wrote: > The `disable_migrate`

Re: [Xen-devel] DESIGN: CPUID part 3

2017-06-12 Thread Andrew Cooper
On 12/06/17 14:29, Jan Beulich wrote: On 12.06.17 at 15:07, wrote: >> On 08/06/17 14:47, Jan Beulich wrote: >> On 08.06.17 at 15:12, wrote: The `disable_migrate` field shall be dropped. The concept of migrateability

Re: [Xen-devel] DESIGN: CPUID part 3

2017-06-12 Thread Jan Beulich
>>> On 12.06.17 at 15:07, wrote: > On 08/06/17 14:47, Jan Beulich wrote: > On 08.06.17 at 15:12, wrote: >>> The `disable_migrate` field shall be dropped. The concept of migrateability >>> is not boolean; it is a large spectrum, all of

Re: [Xen-devel] DESIGN: CPUID part 3

2017-06-12 Thread Andrew Cooper
On 09/06/17 13:24, Anshul Makkar wrote: > On 08/06/2017 14:12, Andrew Cooper wrote: >> Presented herewith is the a plan for the final part of CPUID work, which >> primarily covers better Xen/Toolstack interaction for configuring the >> guests >> CPUID policy. >> >> A PDF version of this document

Re: [Xen-devel] DESIGN: CPUID part 3

2017-06-12 Thread Andrew Cooper
On 08/06/17 14:47, Jan Beulich wrote: On 08.06.17 at 15:12, wrote: >> # Proposal >> >> First and foremost, split the current **max\_policy** notion into separate >> **max** and **default** policies. This allows for the provision of features >> which are unused by

Re: [Xen-devel] DESIGN: CPUID part 3

2017-06-09 Thread Anshul Makkar
On 08/06/2017 14:12, Andrew Cooper wrote: Presented herewith is the a plan for the final part of CPUID work, which primarily covers better Xen/Toolstack interaction for configuring the guests CPUID policy. A PDF version of this document is available from:

Re: [Xen-devel] DESIGN: CPUID part 3

2017-06-08 Thread Jan Beulich
>>> On 08.06.17 at 15:12, wrote: > # Proposal > > First and foremost, split the current **max\_policy** notion into separate > **max** and **default** policies. This allows for the provision of features > which are unused by default, but may be opted in to, both at

[Xen-devel] DESIGN: CPUID part 3

2017-06-08 Thread Andrew Cooper
Presented herewith is the a plan for the final part of CPUID work, which primarily covers better Xen/Toolstack interaction for configuring the guests CPUID policy. A PDF version of this document is available from: http://xenbits.xen.org/people/andrewcoop/cpuid-part-3.pdf There are a number of