>> I think, you could if you would expand "best X" to something like
>>
>> -cpu X,all-features=off,featX=on,featY=on ...
>>
>> The "all-features" part would need a better name as discussed. Such a
>> model would always have a defined feature set (all listed features) ==
>> static. The list could ge
On Thu, Dec 05, 2019 at 03:48:47PM +0100, David Hildenbrand wrote:
> On 05.12.19 15:35, Eduardo Habkost wrote:
> > On Mon, Dec 02, 2019 at 10:15:12AM +0100, David Hildenbrand wrote:
> >>
> Say the user has the option to select a model (zEC12, z13, z14), upper
> layers always want to have
On 05.12.19 15:35, Eduardo Habkost wrote:
> On Mon, Dec 02, 2019 at 10:15:12AM +0100, David Hildenbrand wrote:
>>
Say the user has the option to select a model (zEC12, z13, z14), upper
layers always want to have a model that includes all backported security
features. While the host m
On Mon, Dec 02, 2019 at 10:15:12AM +0100, David Hildenbrand wrote:
>
> >> Say the user has the option to select a model (zEC12, z13, z14), upper
> >> layers always want to have a model that includes all backported security
> >> features. While the host model can do that, CPU definitions can't. You
>> Say the user has the option to select a model (zEC12, z13, z14), upper
>> layers always want to have a model that includes all backported security
>> features. While the host model can do that, CPU definitions can't. You
>> can't change default models within a QEMU release, or for older releas
On Tue, Nov 26, 2019 at 03:07:32PM +0100, David Hildenbrand wrote:
> On 26.11.19 13:59, Christian Borntraeger wrote:
> > re-adding ccs from the cover-letter
> >
> On 25.11.19 18:20, David Hildenbrand wrote:
>
> As soon as dynamic feature groups are used, the CPU model becomes
>
On 26.11.19 13:59, Christian Borntraeger wrote:
> re-adding ccs from the cover-letter
>
On 25.11.19 18:20, David Hildenbrand wrote:
As soon as dynamic feature groups are used, the CPU model becomes
migration-unsafe. Upper layers can expand these models to migration-safe
an
re-adding ccs from the cover-letter
>>> On 25.11.19 18:20, David Hildenbrand wrote:
>>>
>>> As soon as dynamic feature groups are used, the CPU model becomes
>>> migration-unsafe. Upper layers can expand these models to migration-safe
>>> and static variants, allowing them to be migrated.
>>
>> I
> Am 26.11.2019 um 08:54 schrieb Christian Borntraeger :
>
>
>
>> On 25.11.19 18:20, David Hildenbrand wrote:
>>
>> As soon as dynamic feature groups are used, the CPU model becomes
>> migration-unsafe. Upper layers can expand these models to migration-safe
>> and static variants, allowing
On 25.11.19 18:20, David Hildenbrand wrote:
>
> As soon as dynamic feature groups are used, the CPU model becomes
> migration-unsafe. Upper layers can expand these models to migration-safe
> and static variants, allowing them to be migrated.
I really dislike that. I am trying to get rid of the
For a specific CPU model, we have a lot of feature variability depending on
- The microcode version of the HW
- The hypervisor we're running on (LPAR vs. KVM vs. z/VM)
- The hypervisor version we're running on
- The KVM version
- KVM module parameters (especially, "nested=1")
- The accelerator
Our
11 matches
Mail list logo
