On Tue, Nov 24, 2020 at 12:18:45PM -0800, David Rientjes wrote:
> On Tue, 24 Nov 2020, Vipin Sharma wrote:
>
> > > > Looping Janosch and Christian back into the thread.
> > > >
> > > > I interpret this suggestion as
> > > > encryption.{sev,sev_es,keyids}.{max,current,events} for AMD and Intel
> > >
> > > I think it makes sense to use encryption_ids instead of simply encryption, that
> > > way it's clear the cgroup is accounting ids as opposed to restricting what
> > > techs can be used on yes/no basis.
> > >
>
> Agreed.
>
> > > > offerings, which was my thought on this as well.
> > > >
> > > > Certainly the kernel could provide a single interface for all of these and
> > > > key value pairs depending on the underlying encryption technology but it
> > > > seems to only introduce additional complexity in the kernel in string
> > > > parsing that can otherwise be avoided. I think we all agree that a single
> > > > interface for all encryption keys or one-value-per-file could be done in
> > > > the kernel and handled by any userspace agent that is configuring these
> > > > values.
> > > >
> > > > I think Vipin is adding a root level file that describes how many keys we
> > > > have available on the platform for each technology. So I think this comes
> > > > down to, for example, a single encryption.max file vs
> > > > encryption.{sev,sev_es,keyid}.max. SEV and SEV-ES ASIDs are provisioned
> > >
> > > Are you suggesting that the cgroup omit "current" and "events"? I agree there's
> > > no need to enumerate platform total, but not knowing how many of the allowed IDs
> > > have been allocated seems problematic.
> > >
> >
> > We will be showing encryption_ids.{sev,sev_es}.{max,current}
> > I am inclined to not provide "events" as I am not using it, let me know
> > if this file is required, I can provide it then.
> >
> > I will provide an encryption_ids.{sev,sev_es}.stat file, which shows
> > total available ids on the platform. This one will be useful for
> > scheduling jobs in the cloud infrastructure based on total supported
> > capacity.
> >
>
> Makes sense. I assume the stat file is only at the cgroup root level
> since it would otherwise be duplicating its contents in every cgroup under
> it. Probably not very helpful for child cgroup to see stat = 509 ASIDs
> but max = 100 :)
Yes, only at root.
