From: Janosch Frank <frankja@linux.ibm.com>
To: David Gibson <david@gibson.dropbear.id.au>
Cc: "Thomas Huth" <thuth@redhat.com>,
brijesh.singh@amd.com, ehabkost@redhat.com, kvm@vger.kernel.org,
"Michael S. Tsirkin" <mst@redhat.com>,
qemu-devel@nongnu.org, "Cornelia Huck" <cohuck@redhat.com>,
"David Hildenbrand" <david@redhat.com>,
pair@us.ibm.com, dgilbert@redhat.com, pasic@linux.ibm.com,
"Christian Borntraeger" <borntraeger@de.ibm.com>,
qemu-s390x@nongnu.org, qemu-ppc@nongnu.org,
"Daniel P. Berrangé" <berrange@redhat.com>,
pbonzini@redhat.com, mdroth@linux.vnet.ibm.com,
"Richard Henderson" <rth@twiddle.net>
Subject: Re: [for-5.2 v4 10/10] s390: Recognize host-trust-limitation option
Date: Mon, 3 Aug 2020 10:07:42 +0200 [thread overview]
Message-ID: <d8168c58-7935-99e7-dfe5-d97f22766bf7@linux.ibm.com> (raw)
In-Reply-To: <20200803075459.GC7553@yekko.fritz.box>
[-- Attachment #1.1: Type: text/plain, Size: 2640 bytes --]
On 8/3/20 9:54 AM, David Gibson wrote:
> On Mon, Aug 03, 2020 at 09:49:42AM +0200, Janosch Frank wrote:
>> On 7/24/20 4:57 AM, David Gibson wrote:
>>> At least some s390 cpu models support "Protected Virtualization" (PV),
>>> a mechanism to protect guests from eavesdropping by a compromised
>>> hypervisor.
>>>
>>> This is similar in function to other mechanisms like AMD's SEV and
>>> POWER's PEF, which are controlled bythe "host-trust-limitation"
>>> machine option. s390 is a slightly special case, because we already
>>> supported PV, simply by using a CPU model with the required feature
>>> (S390_FEAT_UNPACK).
>>>
>>> To integrate this with the option used by other platforms, we
>>> implement the following compromise:
>>>
>>> - When the host-trust-limitation option is set, s390 will recognize
>>> it, verify that the CPU can support PV (failing if not) and set
>>> virtio default options necessary for encrypted or protected guests,
>>> as on other platforms. i.e. if host-trust-limitation is set, we
>>> will either create a guest capable of entering PV mode, or fail
>>> outright
>>>
>>> - If host-trust-limitation is not set, guest's might still be able to
>>> enter PV mode, if the CPU has the right model. This may be a
>>> little surprising, but shouldn't actually be harmful.
>>
>> As I already explained, they have to continue to work without any change
>> to the VM's configuration.
>
> Yes.. that's what I'm saying will happen.
>
>> Our users already expect PV to work without HTL. This feature is already
>> being used and the documentation has been online for a few months. I've
>> already heard enough complains because users found small errors in our
>> documentation. I'm not looking forward to complains because suddenly we
>> need to specify new command line arguments depending on the QEMU version.
>>
>> @Cornelia: QEMU is not my expertise, am I missing something here?
>
> What I'm saying here is that you don't need a new option. I'm only
> suggesting we make the new option the preferred way for future
> upstream releases. (the new option has the advantage that you *just*
> need to specify it, and any necessary virtio or other options to be
> compatible should be handled for you).
>
> But existing configurations should work as is (I'm not sure they do
> with the current patch, because I'm not familiar with the s390 code
> and have no means to test PV, but that can be sorted out before
> merge).
>
OK, should and might are two different things so I was a bit concerned.
That's fine then, thanks for the answer.
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2020-08-03 8:08 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-24 2:57 [for-5.2 v4 00/10] Generalize memory encryption models David Gibson
2020-07-24 2:57 ` [for-5.2 v4 01/10] host trust limitation: Introduce new host trust limitation interface David Gibson
2020-07-24 2:57 ` [for-5.2 v4 02/10] host trust limitation: Handle memory encryption via interface David Gibson
2020-07-24 2:57 ` [for-5.2 v4 03/10] host trust limitation: Move side effect out of machine_set_memory_encryption() David Gibson
2020-07-24 2:57 ` [for-5.2 v4 04/10] host trust limitation: Rework the "memory-encryption" property David Gibson
2020-07-24 2:57 ` [for-5.2 v4 05/10] host trust limitation: Decouple kvm_memcrypt_*() helpers from KVM David Gibson
2020-07-24 2:57 ` [for-5.2 v4 06/10] host trust limitation: Add Error ** to HostTrustLimitation::kvm_init David Gibson
2020-07-24 2:57 ` [for-5.2 v4 07/10] spapr: Add PEF based host trust limitation David Gibson
2020-07-24 2:57 ` [for-5.2 v4 08/10] spapr: PEF: block migration David Gibson
2020-07-27 15:01 ` Dr. David Alan Gilbert
2020-07-24 2:57 ` [for-5.2 v4 09/10] host trust limitation: Alter virtio default properties for protected guests David Gibson
2020-07-27 15:05 ` Dr. David Alan Gilbert
2020-08-13 7:43 ` Greg Kurz
2020-08-13 8:19 ` Greg Kurz
2020-09-07 15:10 ` Halil Pasic
2020-09-11 2:04 ` David Gibson
2020-09-11 13:49 ` Halil Pasic
2020-07-24 2:57 ` [for-5.2 v4 10/10] s390: Recognize host-trust-limitation option David Gibson
2020-07-27 15:50 ` Cornelia Huck
2020-08-03 7:40 ` Janosch Frank
2020-08-06 6:14 ` David Gibson
2020-08-06 7:18 ` David Hildenbrand
2020-08-03 7:49 ` Janosch Frank
2020-08-03 7:54 ` David Gibson
2020-08-03 8:07 ` Janosch Frank [this message]
2020-08-03 8:14 ` David Gibson
2020-08-03 8:33 ` Cornelia Huck
2020-09-07 15:22 ` Halil Pasic
2020-09-10 11:36 ` Cornelia Huck
2020-09-10 18:29 ` Halil Pasic
2020-09-11 0:07 ` David Gibson
2020-09-11 6:25 ` Greg Kurz
2020-09-11 12:45 ` Halil Pasic
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=d8168c58-7935-99e7-dfe5-d97f22766bf7@linux.ibm.com \
--to=frankja@linux.ibm.com \
--cc=berrange@redhat.com \
--cc=borntraeger@de.ibm.com \
--cc=brijesh.singh@amd.com \
--cc=cohuck@redhat.com \
--cc=david@gibson.dropbear.id.au \
--cc=david@redhat.com \
--cc=dgilbert@redhat.com \
--cc=ehabkost@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=mdroth@linux.vnet.ibm.com \
--cc=mst@redhat.com \
--cc=pair@us.ibm.com \
--cc=pasic@linux.ibm.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=qemu-ppc@nongnu.org \
--cc=qemu-s390x@nongnu.org \
--cc=rth@twiddle.net \
--cc=thuth@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).