Re: [PATCH v3 0/9] Generalize memory encryption models

[David Hildenbrand]

On 19.06.20 12:05, Cornelia Huck wrote:
> On Fri, 19 Jun 2020 11:56:49 +0200
> David Hildenbrand <david@redhat.com> wrote:
> 
>>>>> For now this series covers just AMD SEV and POWER PEF.  I'm hoping it
>>>>> can be extended to cover the Intel and s390 mechanisms as well,
>>>>> though.    
>>>>
>>>> The only approach on s390x to not glue command line properties to the
>>>> cpu model would be to remove the CPU model feature and replace it by the
>>>> command line parameter. But that would, of course, be an incompatible 
>>>> break.  
>>>
>>> Yuck.
>>>
>>> We still need to provide the cpu feature to the *guest* in any case, no?  
>>
>> Yeah, but that could be wired up internally. Wouldn't consider it clean,
>> though (I second the "overengineered" above).
> 
> Could an internally wired-up cpu feature be introspected? Also, what

Nope. It would just be e.g., a "machine feature" indicated to the guest
via the STFL interface/instruction. I was tackling the introspect part
when asking David how to sense from upper layers. It would have to be
sense via a different interface as it would not longer be modeled as
part of CPU features in QEMU.

> happens if new cpu features are introduced that have a dependency on or
> a conflict with this one?

Conflict: bail out in QEMU when incompatible options are specified.
Dependency: warn and continue/fixup (e.g., mask off?)

Not clean I think.

-- 
Thanks,

David / dhildenb