qemu-ppc
[Top][All Lists]
Advanced

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

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


From: David Hildenbrand
Subject: Re: [PATCH v3 0/9] Generalize memory encryption models
Date: Fri, 19 Jun 2020 11:56:49 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0

>> "host-trust-limitation"  sounds like "I am the hypervisor, I configure
>> limited trust into myself". Also, "untrusted-host" would be a little bit
>> nicer (I think trust is a black/white thing).
>>
>> However, once we have multiple options to protect a guest (memory
>> encryption, unmapping guest pages ,...) the name will no longer really
>> suffice to configure QEMU, no?
> 
> Hm... we could have a property that accepts bits indicating where the
> actual limitation lies. Different parts of the code could then make
> more fine-grained decisions of what needs to be done. Feels a bit
> overengineered today; but maybe there's already stuff with different
> semantics in the pipeline somewhere?
> 
>>
>>> 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).
-- 
Thanks,

David / dhildenb




reply via email to

[Prev in Thread] Current Thread [Next in Thread]