From: David Hildenbrand <david@redhat.com>
To: Cornelia Huck <cohuck@redhat.com>
Cc: David Gibson <david@gibson.dropbear.id.au>,
qemu-devel@nongnu.org, brijesh.singh@amd.com, pair@us.ibm.com,
pbonzini@redhat.com, dgilbert@redhat.com, frankja@linux.ibm.com,
Marcel Apfelbaum <marcel.apfelbaum@gmail.com>,
kvm@vger.kernel.org, qemu-ppc@nongnu.org, mst@redhat.com,
mdroth@linux.vnet.ibm.com, Richard Henderson <rth@twiddle.net>,
pasic@linux.ibm.com, Eduardo Habkost <ehabkost@redhat.com>,
qemu-s390x@nongnu.org
Subject: Re: [PATCH v3 0/9] Generalize memory encryption models
Date: Fri, 19 Jun 2020 12:10:13 +0200 [thread overview]
Message-ID: <358d48e5-4c57-808b-50da-275f5e2a352c@redhat.com> (raw)
In-Reply-To: <20200619120530.256c36cb.cohuck@redhat.com>
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
WARNING: multiple messages have this Message-ID (diff)
From: David Hildenbrand <david@redhat.com>
To: Cornelia Huck <cohuck@redhat.com>
Cc: pair@us.ibm.com, brijesh.singh@amd.com, frankja@linux.ibm.com,
kvm@vger.kernel.org, mst@redhat.com, qemu-devel@nongnu.org,
Eduardo Habkost <ehabkost@redhat.com>,
dgilbert@redhat.com, pasic@linux.ibm.com, qemu-s390x@nongnu.org,
qemu-ppc@nongnu.org, pbonzini@redhat.com,
Richard Henderson <rth@twiddle.net>,
mdroth@linux.vnet.ibm.com,
David Gibson <david@gibson.dropbear.id.au>
Subject: Re: [PATCH v3 0/9] Generalize memory encryption models
Date: Fri, 19 Jun 2020 12:10:13 +0200 [thread overview]
Message-ID: <358d48e5-4c57-808b-50da-275f5e2a352c@redhat.com> (raw)
In-Reply-To: <20200619120530.256c36cb.cohuck@redhat.com>
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
next prev parent reply other threads:[~2020-06-19 10:10 UTC|newest]
Thread overview: 112+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-19 2:05 [PATCH v3 0/9] Generalize memory encryption models David Gibson
2020-06-19 2:05 ` David Gibson
2020-06-19 2:05 ` [PATCH v3 1/9] host trust limitation: Introduce new host trust limitation interface David Gibson
2020-06-19 2:05 ` David Gibson
2020-06-26 11:01 ` Dr. David Alan Gilbert
2020-06-26 11:01 ` Dr. David Alan Gilbert
2020-07-14 19:26 ` Richard Henderson
2020-07-14 19:26 ` Richard Henderson
2020-06-19 2:05 ` [PATCH v3 2/9] host trust limitation: Handle memory encryption via interface David Gibson
2020-06-19 2:05 ` David Gibson
2020-06-19 2:05 ` [PATCH v3 3/9] host trust limitation: Move side effect out of machine_set_memory_encryption() David Gibson
2020-06-19 2:05 ` David Gibson
2020-06-19 2:05 ` [PATCH v3 4/9] host trust limitation: Rework the "memory-encryption" property David Gibson
2020-06-19 2:05 ` David Gibson
2020-07-14 19:36 ` Richard Henderson
2020-07-14 19:36 ` Richard Henderson
2020-06-19 2:05 ` [PATCH v3 5/9] host trust limitation: Decouple kvm_memcrypt_*() helpers from KVM David Gibson
2020-06-19 2:05 ` David Gibson
2020-06-19 2:05 ` [PATCH v3 6/9] host trust limitation: Add Error ** to HostTrustLimitation::kvm_init David Gibson
2020-06-19 2:05 ` David Gibson
2020-06-19 2:06 ` [PATCH v3 7/9] spapr: Add PEF based host trust limitation David Gibson
2020-06-19 2:06 ` David Gibson
2020-06-19 2:06 ` [PATCH v3 8/9] spapr: PEF: block migration David Gibson
2020-06-19 2:06 ` David Gibson
2020-06-26 10:33 ` Dr. David Alan Gilbert
2020-06-26 10:33 ` Dr. David Alan Gilbert
2020-07-05 7:38 ` David Gibson
2020-07-05 7:38 ` David Gibson
2020-06-19 2:06 ` [PATCH v3 9/9] host trust limitation: Alter virtio default properties for protected guests David Gibson
2020-06-19 2:06 ` David Gibson
2020-06-19 10:12 ` Daniel P. Berrangé
2020-06-19 10:12 ` Daniel P. Berrangé
2020-06-19 11:46 ` Michael S. Tsirkin
2020-06-19 11:46 ` Michael S. Tsirkin
2020-06-19 11:47 ` Michael S. Tsirkin
2020-06-19 11:47 ` Michael S. Tsirkin
2020-06-19 12:16 ` Daniel P. Berrangé
2020-06-19 12:16 ` Daniel P. Berrangé
2020-06-19 20:04 ` Halil Pasic
2020-06-19 20:04 ` Halil Pasic
2020-06-24 7:55 ` Michael S. Tsirkin
2020-06-24 7:55 ` Michael S. Tsirkin
2020-06-25 4:57 ` David Gibson
2020-06-25 4:57 ` David Gibson
2020-06-25 5:02 ` David Gibson
2020-06-25 5:02 ` David Gibson
2020-06-19 14:45 ` David Gibson
2020-06-19 14:45 ` David Gibson
2020-06-19 15:05 ` Daniel P. Berrangé
2020-06-19 15:05 ` Daniel P. Berrangé
2020-06-20 8:24 ` David Gibson
2020-06-20 8:24 ` David Gibson
2020-06-22 9:09 ` Daniel P. Berrangé
2020-06-22 9:09 ` Daniel P. Berrangé
2020-06-25 5:06 ` David Gibson
2020-06-25 5:06 ` David Gibson
2020-06-19 2:42 ` [PATCH v3 0/9] Generalize memory encryption models no-reply
2020-06-19 2:42 ` no-reply
2020-06-19 8:28 ` David Hildenbrand
2020-06-19 8:28 ` David Hildenbrand
2020-06-19 9:45 ` Cornelia Huck
2020-06-19 9:45 ` Cornelia Huck
2020-06-19 9:56 ` David Hildenbrand
2020-06-19 9:56 ` David Hildenbrand
2020-06-19 10:05 ` Cornelia Huck
2020-06-19 10:05 ` Cornelia Huck
2020-06-19 10:10 ` David Hildenbrand [this message]
2020-06-19 10:10 ` David Hildenbrand
2020-06-22 12:02 ` Cornelia Huck
2020-06-22 12:02 ` Cornelia Huck
2020-06-25 5:25 ` David Gibson
2020-06-25 5:25 ` David Gibson
2020-06-25 7:06 ` David Hildenbrand
2020-06-25 7:06 ` David Hildenbrand
2020-06-26 4:42 ` David Gibson
2020-06-26 4:42 ` David Gibson
2020-06-26 6:53 ` David Hildenbrand
2020-06-26 6:53 ` David Hildenbrand
2020-06-26 9:01 ` Janosch Frank
2020-06-26 9:01 ` Janosch Frank
2020-06-26 9:32 ` Daniel P. Berrangé
2020-06-26 9:32 ` Daniel P. Berrangé
2020-06-26 9:49 ` Janosch Frank
2020-06-26 9:49 ` Janosch Frank
2020-06-26 10:29 ` Dr. David Alan Gilbert
2020-06-26 10:29 ` Dr. David Alan Gilbert
2020-06-26 10:58 ` Daniel P. Berrangé
2020-06-26 10:58 ` Daniel P. Berrangé
2020-06-26 12:49 ` Janosch Frank
2020-06-26 12:49 ` Janosch Frank
2020-07-01 11:59 ` Halil Pasic
2020-07-01 11:59 ` Halil Pasic
2020-06-19 9:48 ` David Gibson
2020-06-19 9:48 ` David Gibson
2020-06-19 10:04 ` David Hildenbrand
2020-06-19 10:04 ` David Hildenbrand
2020-06-25 5:42 ` David Gibson
2020-06-25 5:42 ` David Gibson
2020-06-25 6:59 ` David Hildenbrand
2020-06-25 6:59 ` David Hildenbrand
2020-06-25 9:49 ` Cornelia Huck
2020-06-25 9:49 ` Cornelia Huck
2020-06-22 14:27 ` Christian Borntraeger
2020-06-22 14:27 ` Christian Borntraeger
2020-06-24 7:06 ` Cornelia Huck
2020-06-24 7:06 ` Cornelia Huck
2020-06-25 5:47 ` David Gibson
2020-06-25 5:47 ` David Gibson
2020-06-25 5:48 ` David Gibson
2020-06-25 5:48 ` David Gibson
2020-06-25 5:44 ` David Gibson
2020-06-25 5:44 ` David Gibson
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=358d48e5-4c57-808b-50da-275f5e2a352c@redhat.com \
--to=david@redhat.com \
--cc=brijesh.singh@amd.com \
--cc=cohuck@redhat.com \
--cc=david@gibson.dropbear.id.au \
--cc=dgilbert@redhat.com \
--cc=ehabkost@redhat.com \
--cc=frankja@linux.ibm.com \
--cc=kvm@vger.kernel.org \
--cc=marcel.apfelbaum@gmail.com \
--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 \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.