From: Tejun Heo <firstname.lastname@example.org>
To: Vipin Sharma <email@example.com>
Cc: firstname.lastname@example.org, email@example.com,
firstname.lastname@example.org, email@example.com, firstname.lastname@example.org,
email@example.com, firstname.lastname@example.org, email@example.com,
firstname.lastname@example.org, email@example.com, firstname.lastname@example.org,
email@example.com, firstname.lastname@example.org, email@example.com,
firstname.lastname@example.org, email@example.com, firstname.lastname@example.org,
email@example.com, firstname.lastname@example.org, email@example.com,
firstname.lastname@example.org, email@example.com, firstname.lastname@example.org,
Subject: Re: [Patch v4 1/2] cgroup: svm: Add Encryption ID controller
Date: Tue, 19 Jan 2021 10:51:24 -0500 [thread overview]
Message-ID: <YAb//EYCkZ7wnl6D@mtj.duckdns.org> (raw)
On Fri, Jan 15, 2021 at 08:32:19PM -0800, Vipin Sharma wrote:
> SEV-ES has stronger memory encryption gurantees compared to SEV, apart
> from encrypting the application memory it also encrypts register state
> among other things. In a single host ASIDs can be distributed between
> these two types by BIOS settings.
> Currently, Google Cloud has Confidential VM machines offering using SEV.
> ASIDs are not compatible between SEV and SEV-ES, so a VM running on SEV
> cannot run on SEV-ES and vice versa
> There are use cases for both types of VMs getting used in future.
Can you please elaborate? I skimmed through the amd manual and it seemed to
say that SEV-ES ASIDs are superset of SEV but !SEV-ES ASIDs. What's the use
case for mixing those two?
> > > > > Other ID types can be easily added in the controller in the same way.
> > > >
> > > > I'm not sure this is necessarily a good thing.
> > >
> > > This is to just say that when Intel and PowerPC changes are ready it
> > > won't be difficult for them to add their controller.
> > I'm not really enthused about having per-hardware-type control knobs. None
> > of other controllers behave that way. Unless it can be abstracted into
> > something common, I'm likely to object.
> There was a discussion in Patch v1 and consensus was to have individual
> files because it makes kernel implementation extremely simple.
I'm very reluctant to ack vendor specific interfaces for a few reasons but
most importantly because they usually indicate abstraction and/or the
underlying feature not being sufficiently developed and they tend to become
baggages after a while. So, here are my suggestions:
* If there can be a shared abstraction which hopefully makes intuitive
sense, that'd be ideal. It doesn't have to be one knob but it shouldn't be
something arbitrary to specific vendors.
* If we aren't there yet and vendor-specific interface is a must, attach
that part to an interface which is already vendor-aware.
> This information is not available anywhere else in the system. Only
> other way to get this value is to use CPUID instruction (0x8000001F) of
> the processor. Which also has disdvantage if sev module in kernel
> doesn't use all of the available ASIDs for its work (right now it uses
> all) then there will be a mismatch between what user get through their
> code and what is actually getting used in the kernel by sev.
> In cgroup v2, I didn't see current files for other cgroups in root
> folder that is why I didn't show that file in root folder.
> Will you be fine if I show two files in the root, something like:
> In non root folder, it will be:
> I still prefer encids.sev.stat, as it won't repeat same information in
> each cgroup but let me know what you think.
Yeah, this will be a first and I was mostly wondering about the same number
appearing under different files / names on root and !root cgroups. I'm
leaning more towards capacity/current but let me think about it a bit more.
next prev parent reply other threads:[~2021-01-19 15:56 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-08 1:28 [Patch v4 0/2] cgroup: KVM: New Encryption IDs cgroup controller Vipin Sharma
2021-01-08 1:28 ` [Patch v4 1/2] cgroup: svm: Add Encryption ID controller Vipin Sharma
2021-01-13 15:19 ` Brijesh Singh
2021-01-15 20:59 ` Tejun Heo
2021-01-15 22:18 ` Vipin Sharma
2021-01-16 3:43 ` Tejun Heo
2021-01-16 4:32 ` Vipin Sharma
2021-01-19 15:51 ` Tejun Heo [this message]
2021-01-20 7:13 ` Vipin Sharma
2021-01-20 16:40 ` Tejun Heo
2021-01-20 23:18 ` Vipin Sharma
2021-01-20 23:32 ` Tejun Heo
2021-01-22 0:09 ` Vipin Sharma
2021-01-21 14:55 ` Tom Lendacky
2021-01-21 15:55 ` Tejun Heo
2021-01-21 23:12 ` Tom Lendacky
2021-01-22 1:25 ` Sean Christopherson
2021-01-26 20:49 ` David Rientjes
2021-01-26 22:01 ` Tejun Heo
2021-01-26 22:02 ` Tejun Heo
2021-01-27 1:11 ` Vipin Sharma
2021-01-27 14:10 ` Tejun Heo
2021-01-08 1:28 ` [Patch v4 2/2] cgroup: svm: Encryption IDs cgroup documentation Vipin Sharma
2021-01-15 21:00 ` Tejun Heo
2021-01-15 21:41 ` Vipin Sharma
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:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* 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).