On 01.06.20 05:04, Benjamin Herrenschmidt wrote:
On Thu, 2020-05-28 at 15:12 +0200, Greg KH wrote:
So at runtime, after all is booted and up and going, you just ripped
cores out from under someone's feet? :)
And the code really handles writing to that value while the module is
already
On Mon, Jun 01, 2020 at 12:47:12PM +1000, Benjamin Herrenschmidt wrote:
> On Tue, 2020-05-26 at 08:51 +0200, Greg KH wrote:
> >
> > And get them to sign off on it too, showing they agree with the design
> > decisions here :)
>
> Isn't it generally frowned upon to publish a patch with internal
On Thu, 2020-05-28 at 15:12 +0200, Greg KH wrote:
> So at runtime, after all is booted and up and going, you just ripped
> cores out from under someone's feet? :)
>
> And the code really handles writing to that value while the module is
> already loaded and up and running? At a quick glance, it
On Wed, 2020-05-27 at 00:24 +0200, Greg KH wrote:
> > Would you want random users to get the ability to hot unplug CPUs from your
> > system? At unlimited quantity? I don't :).
>
> A random user, no, but one with admin rights, why not? They can do that
> already today on your system, this isn't
On Tue, 2020-05-26 at 14:44 +0200, Alexander Graf wrote:
> So I really don't think an ioctl would be a great user experience. Same
> for a sysfs file - although that's probably slightly better than the ioctl.
What would be wrong with a sysfs file ?
Another way to approach that makes sense from
On Tue, 2020-05-26 at 08:51 +0200, Greg KH wrote:
>
> And get them to sign off on it too, showing they agree with the design
> decisions here :)
Isn't it generally frowned upon to publish a patch with internal sign-
off's on it already ? Or do you mean for us to publicly sign off once
we have
On 28/05/2020 16:12, Greg KH wrote:
On Thu, May 28, 2020 at 03:01:36PM +0200, Alexander Graf wrote:
On 27.05.20 00:24, Greg KH wrote:
On Tue, May 26, 2020 at 03:44:30PM +0200, Alexander Graf wrote:
On 26.05.20 15:17, Greg KH wrote:
On Tue, May 26, 2020 at 02:44:18PM +0200, Alexander
On Thu, May 28, 2020 at 03:01:36PM +0200, Alexander Graf wrote:
>
>
> On 27.05.20 00:24, Greg KH wrote:
> >
> > On Tue, May 26, 2020 at 03:44:30PM +0200, Alexander Graf wrote:
> > >
> > >
> > > On 26.05.20 15:17, Greg KH wrote:
> > > >
> > > > On Tue, May 26, 2020 at 02:44:18PM +0200,
On 27.05.20 00:24, Greg KH wrote:
On Tue, May 26, 2020 at 03:44:30PM +0200, Alexander Graf wrote:
On 26.05.20 15:17, Greg KH wrote:
On Tue, May 26, 2020 at 02:44:18PM +0200, Alexander Graf wrote:
On 26.05.20 14:33, Greg KH wrote:
On Tue, May 26, 2020 at 01:42:41PM +0200, Alexander
On Tue, May 26, 2020 at 03:44:30PM +0200, Alexander Graf wrote:
>
>
> On 26.05.20 15:17, Greg KH wrote:
> >
> > On Tue, May 26, 2020 at 02:44:18PM +0200, Alexander Graf wrote:
> > >
> > >
> > > On 26.05.20 14:33, Greg KH wrote:
> > > >
> > > > On Tue, May 26, 2020 at 01:42:41PM +0200,
On 26.05.20 15:17, Greg KH wrote:
On Tue, May 26, 2020 at 02:44:18PM +0200, Alexander Graf wrote:
On 26.05.20 14:33, Greg KH wrote:
On Tue, May 26, 2020 at 01:42:41PM +0200, Alexander Graf wrote:
On 26.05.20 08:51, Greg KH wrote:
On Tue, May 26, 2020 at 01:13:23AM +0300, Andra
On 26/05/2020 15:33, Greg KH wrote:
On Tue, May 26, 2020 at 01:42:41PM +0200, Alexander Graf wrote:
On 26.05.20 08:51, Greg KH wrote:
On Tue, May 26, 2020 at 01:13:23AM +0300, Andra Paraschiv wrote:
+#define NE "nitro_enclaves: "
Again, no need for this.
+#define NE_DEV_NAME
On Tue, May 26, 2020 at 02:44:18PM +0200, Alexander Graf wrote:
>
>
> On 26.05.20 14:33, Greg KH wrote:
> >
> > On Tue, May 26, 2020 at 01:42:41PM +0200, Alexander Graf wrote:
> > >
> > >
> > > On 26.05.20 08:51, Greg KH wrote:
> > > >
> > > > On Tue, May 26, 2020 at 01:13:23AM +0300, Andra
On 26.05.20 14:33, Greg KH wrote:
On Tue, May 26, 2020 at 01:42:41PM +0200, Alexander Graf wrote:
On 26.05.20 08:51, Greg KH wrote:
On Tue, May 26, 2020 at 01:13:23AM +0300, Andra Paraschiv wrote:
+#define NE "nitro_enclaves: "
Again, no need for this.
+#define NE_DEV_NAME
On Tue, May 26, 2020 at 01:42:41PM +0200, Alexander Graf wrote:
>
>
> On 26.05.20 08:51, Greg KH wrote:
> >
> > On Tue, May 26, 2020 at 01:13:23AM +0300, Andra Paraschiv wrote:
> > > +#define NE "nitro_enclaves: "
> >
> > Again, no need for this.
> >
> > > +#define NE_DEV_NAME
On 26.05.20 08:51, Greg KH wrote:
On Tue, May 26, 2020 at 01:13:23AM +0300, Andra Paraschiv wrote:
+#define NE "nitro_enclaves: "
Again, no need for this.
+#define NE_DEV_NAME "nitro_enclaves"
KBUILD_MODNAME?
+#define NE_IMAGE_LOAD_OFFSET (8 * 1024UL * 1024UL)
+
+static char
On Tue, May 26, 2020 at 01:13:23AM +0300, Andra Paraschiv wrote:
> +#define NE "nitro_enclaves: "
Again, no need for this.
> +#define NE_DEV_NAME "nitro_enclaves"
KBUILD_MODNAME?
> +#define NE_IMAGE_LOAD_OFFSET (8 * 1024UL * 1024UL)
> +
> +static char *ne_cpus;
> +module_param(ne_cpus, charp,
The Nitro Enclaves driver provides an ioctl interface to the user space
for enclave lifetime management e.g. enclave creation / termination and
setting enclave resources such as memory and CPU.
This ioctl interface is mapped to a Nitro Enclaves misc device.
Signed-off-by: Andra Paraschiv
---
18 matches
Mail list logo
