Re: [RFC v2 2/2] cgroup: sev: Miscellaneous cgroup documentation.

From: Tejun Heo <tj@kernel.org>
To: Jacob Pan <jacob.jun.pan@intel.com>
Cc: Vipin Sharma <vipinsh@google.com>,
	mkoutny@suse.com, rdunlap@infradead.org, thomas.lendacky@amd.com,
	brijesh.singh@amd.com, jon.grimm@amd.com,
	eric.vantassell@amd.com, pbonzini@redhat.com, hannes@cmpxchg.org,
	frankja@linux.ibm.com, borntraeger@de.ibm.com, corbet@lwn.net,
	seanjc@google.com, vkuznets@redhat.com, wanpengli@tencent.com,
	jmattson@google.com, joro@8bytes.org, 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, linux-kernel@vger.kernel.org, "Tian,
	Kevin" <kevin.tian@intel.com>, "Liu, Yi L" <yi.l.liu@intel.com>,
	"Raj, Ashok" <ashok.raj@intel.com>,
	Alex Williamson <alex.williamson@redhat.com>,
	Jason Gunthorpe <jgg@nvidia.com>,
	Jacob Pan <jacob.jun.pan@linux.intel.com>,
	"jean-philippe@linaro.org" <jean-philippe@linaro.org>
Subject: Re: [RFC v2 2/2] cgroup: sev: Miscellaneous cgroup documentation.
Date: Mon, 15 Mar 2021 18:19:35 -0400	[thread overview]
Message-ID: <YE/ddx5+ToNsgUF0@slm.duckdns.org> (raw)
In-Reply-To: <20210315151155.383a7e6e@jacob-builder>

Hello,

On Mon, Mar 15, 2021 at 03:11:55PM -0700, Jacob Pan wrote:
> > Migration itself doesn't have restrictions but all resources are
> > distributed on the same hierarchy, so the controllers are supposed to
> > follow the same conventions that can be implemented by all controllers.
> > 
> Got it, I guess that is the behavior required by the unified hierarchy.
> Cgroup v1 would be ok? But I am guessing we are not extending on v1?

A new cgroup1 only controller is unlikely to be accpeted.

> The IOASIDs are programmed into devices to generate DMA requests tagged
> with them. The IOMMU has a per device IOASID table with each entry has two
> pointers:
>  - the PGD of the guest process.
>  - the PGD of the host process
> 
> The result of this 2 stage/nested translation is that we can share virtual
> address (SVA) between guest process and DMA. The host process needs to
> allocate multiple IOASIDs since one IOASID is needed for each guest process
> who wants SVA.
> 
> The DMA binding among device-IOMMU-process is setup via a series of user
> APIs (e.g. via VFIO).
> 
> If a process calls fork(), the children does not inherit the IOASIDs and
> their bindings. Children who wish to use SVA has to call those APIs to
> establish the binding for themselves.
> 
> Therefore, if a host process allocates 10 IOASIDs then does a
> fork()/clone(), it cannot charge 10 IOASIDs in the new cgroup. i.e. the 10
> IOASIDs stays with the process wherever it goes.
> 
> I feel this fit in the domain model, true?

I still don't get where migration is coming into the picture. Who's
migrating where?

Thanks.

-- 
tejun