qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
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 --]

  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).