kvm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Tejun Heo <tj@kernel.org>
To: Vipin Sharma <vipinsh@google.com>
Cc: thomas.lendacky@amd.com, brijesh.singh@amd.com,
	jon.grimm@amd.com, eric.vantassell@amd.com, pbonzini@redhat.com,
	seanjc@google.com, hannes@cmpxchg.org, frankja@linux.ibm.com,
	borntraeger@de.ibm.com, corbet@lwn.net, joro@8bytes.org,
	vkuznets@redhat.com, wanpengli@tencent.com, jmattson@google.com,
	tglx@linutronix.de, mingo@redhat.com, bp@alien8.de,
	hpa@zytor.com, gingell@google.com, rientjes@google.com,
	dionnaglaze@google.com, kvm@vger.kernel.org, x86@kernel.org,
	cgroups@vger.kernel.org, linux-doc@vger.kernel.org,
Subject: Re: [Patch v4 1/2] cgroup: svm: Add Encryption ID controller
Date: Wed, 20 Jan 2021 18:32:56 -0500	[thread overview]
Message-ID: <YAi9qNqiBjGvXMoI@mtj.duckdns.org> (raw)
In-Reply-To: <YAi6RcbxTSMmNssw@google.com>


On Wed, Jan 20, 2021 at 03:18:29PM -0800, Vipin Sharma wrote:
> RDMA cgroup expose hardware details to users. In rdma.{max, current}
> interface files we can see actual hardware names. Only difference

No, what's shown is the device name followed by resources which are commonly
defined for all rdma devices. The format is the same as io controller
interface files.

> compared to Encryption ID cgroup is that latter is exposing that detail
> via file names.
> Will you prefer that encryption ID cgroup do things similar to RDMA
> cgroup? It can have 3 files

I don't know how many times I have to repeat the same point to get it
across. For any question about actual abstraction, you haven't provided any
kind of actual research or analysis and just keep pushing the same thing
over and over again. Maybe the situation is such that it makes sense to
change the rule but that needs substantial justifications. I've been asking
to see whether there are such justifications but all I've been getting are
empty answers. Until such discussions take place, please consider the series
nacked and please excuse if I don't respond promptly in this thread.

> > Attaching the interface to kvm side, most likely, instead of exposing the
> > feature through cgroup.
> I am little confused, do you mean moving files from the kernel/cgroup/
> to kvm related directories or you are recommending not to use cgroup at
> all?  I hope it is the former :)
> Only issue with this is that TDX is not limited to KVM, they have
> potential use cases for MKTME without KVM.

There are ways to integrate with cgroup through other interfaces - e.g. take
a look at how bpf works with cgroups. Here, it isn't ideal but may work out
if things actually require a lot of hardware dependent bits. There's also
RDT which exists outside of cgroup for similar reasons.



  reply	other threads:[~2021-01-21  0:48 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
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 [this message]
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

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YAi9qNqiBjGvXMoI@mtj.duckdns.org \
    --to=tj@kernel.org \
    --cc=borntraeger@de.ibm.com \
    --cc=bp@alien8.de \
    --cc=brijesh.singh@amd.com \
    --cc=cgroups@vger.kernel.org \
    --cc=corbet@lwn.net \
    --cc=dionnaglaze@google.com \
    --cc=eric.vantassell@amd.com \
    --cc=frankja@linux.ibm.com \
    --cc=gingell@google.com \
    --cc=hannes@cmpxchg.org \
    --cc=hpa@zytor.com \
    --cc=jmattson@google.com \
    --cc=jon.grimm@amd.com \
    --cc=joro@8bytes.org \
    --cc=kvm@vger.kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=rientjes@google.com \
    --cc=seanjc@google.com \
    --cc=tglx@linutronix.de \
    --cc=thomas.lendacky@amd.com \
    --cc=vipinsh@google.com \
    --cc=vkuznets@redhat.com \
    --cc=wanpengli@tencent.com \
    --cc=x86@kernel.org \


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