[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20210312145904.4071a9d6@jacob-builder>
Date: Fri, 12 Mar 2021 14:59:04 -0800
From: Jacob Pan <jacob.jun.pan@...el.com>
To: Vipin Sharma <vipinsh@...gle.com>
Cc: Tejun Heo <tj@...nel.org>, mkoutny@...e.com, rdunlap@...radead.org,
thomas.lendacky@....com, brijesh.singh@....com, jon.grimm@....com,
eric.vantassell@....com, pbonzini@...hat.com, hannes@...xchg.org,
frankja@...ux.ibm.com, borntraeger@...ibm.com, corbet@....net,
seanjc@...gle.com, vkuznets@...hat.com, wanpengli@...cent.com,
jmattson@...gle.com, joro@...tes.org, tglx@...utronix.de,
mingo@...hat.com, bp@...en8.de, hpa@...or.com, gingell@...gle.com,
rientjes@...gle.com, dionnaglaze@...gle.com, kvm@...r.kernel.org,
x86@...nel.org, cgroups@...r.kernel.org, linux-doc@...r.kernel.org,
linux-kernel@...r.kernel.org, "Tian, Kevin" <kevin.tian@...el.com>,
"Liu, Yi L" <yi.l.liu@...el.com>,
"Raj, Ashok" <ashok.raj@...el.com>,
Alex Williamson <alex.williamson@...hat.com>,
Jason Gunthorpe <jgg@...dia.com>,
Jacob Pan <jacob.jun.pan@...ux.intel.com>,
jacob.jun.pan@...el.com,
"jean-philippe@...aro.org" <jean-philippe@...aro.org>
Subject: Re: [RFC v2 2/2] cgroup: sev: Miscellaneous cgroup documentation.
Hi Vipin,
On Fri, 12 Mar 2021 13:15:14 -0800, Vipin Sharma <vipinsh@...gle.com> wrote:
> On Fri, Mar 12, 2021 at 12:58:21PM -0800, Jacob Pan wrote:
> > Hi Vipin & Tejun,
> >
> > Sorry for the late reply, I sent from a different email address than I
> > intended. Please see my comments inline.
> >
> >
> > On Thu, 4 Mar 2021 03:51:16 -0500, Tejun Heo <tj@...nel.org> wrote:
> >
> > > Hello,
> > >
> > > On Wed, Mar 03, 2021 at 10:22:03PM -0800, Vipin Sharma wrote:
> > > > > I am trying to see if IOASIDs cgroup can also fit in this misc
> > > > > controller as yet another resource type.
> > > > > https://lore.kernel.org/linux-iommu/20210303131726.7a8cb169@jacob-builder/T/#u
> > > > > However, unlike sev IOASIDs need to be migrated if the process is
> > > > > moved to another cgroup. i.e. charge the destination and uncharge
> > > > > the source.
> > > > >
> > > > > Do you think this behavior can be achieved by differentiating
> > > > > resource types? i.e. add attach callbacks for certain types.
> > > > > Having a single misc interface seems cleaner than creating
> > > > > another controller.
> > > >
> > > > I think it makes sense to add support for migration for the
> > > > resources which need it. Resources like SEV, SEV-ES will not
> > > > participate in migration and won't stop can_attach() to succeed,
> > > > other resources which need migration will allow or stop based on
> > > > their limits and capacity in the destination.
> > >
> > Sounds good. Perhaps some capability/feature flags for each resource
> > such that different behavior can be accommodated?
> > Could you please include me in your future posting? I will rebase on
> > yours.
>
> Hi Jacob
>
> Based on Tejun's response, I will not add charge migration support in
> misc controller.
>
Sounds good. I need some confirmation on whether migration is a must have
for VMs allocated IOASIDs.
Our primary goal is to limit the amount of IOASIDs that VMs can allocate.
If a VM is migrated to a different cgroup, I think we need to
charge/uncharge the destination/source cgroup in order enforce the limit. I
am not an expert here, any feedback would be appreciated.
> I can definitly add you in my future posting, if you still wanna use it
> without charge migration support.
>
Yes, please. I got your v3 already, so just future patches.
> Thanks
> Vipin
Thanks,
Jacob
Powered by blists - more mailing lists