From: Cornelia Huck <cohuck@redhat.com>
To: David Hildenbrand <david@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: Thu, 25 Jun 2020 11:49:58 +0200 [thread overview]
Message-ID: <20200625114958.6d1981fe.cohuck@redhat.com> (raw)
In-Reply-To: <778050eb-c6b2-e471-1945-598520fdc894@redhat.com>
On Thu, 25 Jun 2020 08:59:00 +0200
David Hildenbrand <david@redhat.com> wrote:
> >>>> How do upper layers actually figure out if memory encryption etc is
> >>>> available? on s390x, it's simply via the expanded host CPU model.
> >>>
> >>> Haven't really tackled that yet. But one way that works for multiple
> >>> systems has got to be better than a separate one for each, right?
> >>
> >> I think that's an important piece. Especially once multiple different
> >> approaches are theoretically available one wants to sense from upper layers.
> >
> > Fair point.
> >
> > So... IIRC there's a general way of looking at available properties
> > for any object, including the machine. So we can probe for
> > availability of the "host-trust-limitation" property itself easily
> > enough.
>
> You can have a look at how it's currently probed by libvirt in
>
> https://www.redhat.com/archives/libvir-list/2020-June/msg00518.html
>
> For now, the s390x check consists of
> - checking if /sys/firmware/uv is available
> - checking if the kernel cmdline contains 'prot_virt=1'
>
> The sev check is
> - checking if /sys/module/kvm_amd/parameters/sev contains the
> value '1'
> - checking if /dev/sev
>
> So at least libvirt does not sense via the CPU model on s390x yet.
It checks for 158 (which is apparently 'host supports secure
execution'). IIUC, only 161 ('unpack facility') is relevant for the
guest... does that also show up on the host? (I guess it does, as it
describes an ultravisor feature, IIUC.) If it is always implied,
libvirt probably does not need an extra check.
next prev parent reply other threads:[~2020-06-25 9:50 UTC|newest]
Thread overview: 56+ 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 ` [PATCH v3 1/9] host trust limitation: Introduce new host trust limitation interface David Gibson
2020-06-26 11:01 ` Dr. David Alan Gilbert
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 ` [PATCH v3 3/9] host trust limitation: Move side effect out of machine_set_memory_encryption() David Gibson
2020-06-19 2:05 ` [PATCH v3 4/9] host trust limitation: Rework the "memory-encryption" property David Gibson
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 ` [PATCH v3 6/9] host trust limitation: Add Error ** to HostTrustLimitation::kvm_init 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 ` [PATCH v3 8/9] spapr: PEF: block migration David Gibson
2020-06-26 10:33 ` Dr. David Alan Gilbert
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 10:12 ` Daniel P. Berrangé
2020-06-19 11:46 ` Michael S. Tsirkin
2020-06-19 11:47 ` Michael S. Tsirkin
2020-06-19 12:16 ` Daniel P. Berrangé
2020-06-19 20:04 ` Halil Pasic
2020-06-24 7:55 ` Michael S. Tsirkin
2020-06-25 4:57 ` David Gibson
2020-06-25 5:02 ` David Gibson
2020-06-19 14:45 ` David Gibson
2020-06-19 15:05 ` Daniel P. Berrangé
2020-06-20 8:24 ` David Gibson
2020-06-22 9:09 ` Daniel P. Berrangé
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 8:28 ` David Hildenbrand
2020-06-19 9:45 ` Cornelia Huck
2020-06-19 9:56 ` David Hildenbrand
2020-06-19 10:05 ` Cornelia Huck
2020-06-19 10:10 ` David Hildenbrand
2020-06-22 12:02 ` Cornelia Huck
2020-06-25 5:25 ` David Gibson
2020-06-25 7:06 ` David Hildenbrand
2020-06-26 4:42 ` David Gibson
2020-06-26 6:53 ` David Hildenbrand
2020-06-26 9:01 ` Janosch Frank
2020-06-26 9:32 ` Daniel P. Berrangé
2020-06-26 9:49 ` Janosch Frank
2020-06-26 10:29 ` Dr. David Alan Gilbert
2020-06-26 10:58 ` Daniel P. Berrangé
2020-06-26 12:49 ` Janosch Frank
2020-07-01 11:59 ` Halil Pasic
2020-06-19 9:48 ` David Gibson
2020-06-19 10:04 ` David Hildenbrand
2020-06-25 5:42 ` David Gibson
2020-06-25 6:59 ` David Hildenbrand
2020-06-25 9:49 ` Cornelia Huck [this message]
2020-06-22 14:27 ` Christian Borntraeger
2020-06-24 7:06 ` Cornelia Huck
2020-06-25 5:47 ` David Gibson
2020-06-25 5:48 ` 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=20200625114958.6d1981fe.cohuck@redhat.com \
--to=cohuck@redhat.com \
--cc=brijesh.singh@amd.com \
--cc=david@gibson.dropbear.id.au \
--cc=david@redhat.com \
--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 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).