Hi Vipin, On Fri, 12 Mar 2021 13:15:14 -0800, Vipin Sharma <vipinsh@xxxxxxxxxx> 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@xxxxxxxxxx> 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
