All of lore.kernel.org
 help / color / mirror / Atom feed
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Alexander Graf <graf@amazon.de>, Greg KH <gregkh@linuxfoundation.org>
Cc: Andra Paraschiv <andraprs@amazon.com>,
	linux-kernel@vger.kernel.org,
	Anthony Liguori <aliguori@amazon.com>,
	Colm MacCarthaigh <colmmacc@amazon.com>,
	Bjoern Doebel <doebel@amazon.de>,
	David Woodhouse <dwmw@amazon.co.uk>,
	Frank van der Linden <fllinden@amazon.com>,
	Martin Pohlack <mpohlack@amazon.de>, Matt Wilson <msw@amazon.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Balbir Singh <sblbir@amazon.com>,
	Stefano Garzarella <sgarzare@redhat.com>,
	Stefan Hajnoczi <stefanha@redhat.com>,
	Stewart Smith <trawets@amazon.com>,
	Uwe Dannowski <uwed@amazon.de>,
	kvm@vger.kernel.org, ne-devel-upstream@amazon.com
Subject: Re: [PATCH v3 07/18] nitro_enclaves: Init misc device providing the ioctl interface
Date: Mon, 01 Jun 2020 12:51:16 +1000	[thread overview]
Message-ID: <f256a37a89db56fcad229a1cfea11b8636b13829.camel@kernel.crashing.org> (raw)
In-Reply-To: <59007eb9-fad3-9655-a856-f5989fa9fdb3@amazon.de>

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 a kernel perspective is
to have the user first offline the CPUs, then "donate" them to the
driver via a sysfs file.

> Other options I can think of:
> 
>    * sysctl (for modules?)

Why would that be any good ? If anything sysctl's are even more awkward
in my book :)

>    * module parameter (as implemented here)
>    * proc file (deprecated FWIW)

Yeah no.

> The key is the tenant split: Admin sets the pool up, user consumes. This 
> setup should happen (early) on boot, so that system services can spawn 
> enclaves.

Right and you can have some init script or udev rule that sets that up
from a sys admin produced config file at boot upon detection of the
enclave PCI device for example.

> > module parameters are a major pain, you know this :)
> 
> I think in this case it's the least painful option ;). But I'm really 
> happy to hear about an actually good alternative to it. Right now, I 
> just can't think of any.

Cheers,
Ben.



  parent reply	other threads:[~2020-06-01  2:51 UTC|newest]

Thread overview: 58+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-25 22:13 [PATCH v3 00/18] Add support for Nitro Enclaves Andra Paraschiv
2020-05-25 22:13 ` [PATCH v3 01/18] nitro_enclaves: Add ioctl interface definition Andra Paraschiv
2020-05-27  8:49   ` Stefan Hajnoczi
2020-05-28 18:05     ` Paraschiv, Andra-Irina
2020-06-01  3:02     ` Benjamin Herrenschmidt
2020-06-01  7:20       ` Paraschiv, Andra-Irina
2020-06-05  8:15         ` Stefan Hajnoczi
2020-06-05 15:39           ` Paraschiv, Andra-Irina
2020-05-25 22:13 ` [PATCH v3 02/18] nitro_enclaves: Define the PCI device interface Andra Paraschiv
2020-05-26  6:44   ` Greg KH
2020-05-26 17:01     ` Paraschiv, Andra-Irina
2020-05-26 22:21       ` Greg KH
2020-05-28 16:37         ` Paraschiv, Andra-Irina
2020-06-01  2:59         ` Benjamin Herrenschmidt
2020-06-01  7:07           ` Paraschiv, Andra-Irina
2020-06-01  2:53       ` Benjamin Herrenschmidt
2020-05-25 22:13 ` [PATCH v3 03/18] nitro_enclaves: Define enclave info for internal bookkeeping Andra Paraschiv
2020-05-26  6:46   ` Greg KH
2020-05-26 17:20     ` Paraschiv, Andra-Irina
2020-05-25 22:13 ` [PATCH v3 04/18] nitro_enclaves: Init PCI device driver Andra Paraschiv
2020-05-26  6:48   ` Greg KH
2020-05-26 18:35     ` Paraschiv, Andra-Irina
2020-05-26 22:19       ` Greg KH
2020-05-28 16:26         ` Paraschiv, Andra-Irina
2020-06-01  2:55       ` Benjamin Herrenschmidt
2020-06-01  6:42         ` Paraschiv, Andra-Irina
2020-05-25 22:13 ` [PATCH v3 05/18] nitro_enclaves: Handle PCI device command requests Andra Paraschiv
2020-05-25 22:13 ` [PATCH v3 06/18] nitro_enclaves: Handle out-of-band PCI device events Andra Paraschiv
2020-05-25 22:13 ` [PATCH v3 07/18] nitro_enclaves: Init misc device providing the ioctl interface Andra Paraschiv
2020-05-26  6:51   ` Greg KH
2020-05-26 11:42     ` Alexander Graf
2020-05-26 12:33       ` Greg KH
2020-05-26 12:44         ` Alexander Graf
2020-05-26 13:17           ` Greg KH
2020-05-26 13:44             ` Alexander Graf
2020-05-26 22:24               ` Greg KH
2020-05-28 13:01                 ` Alexander Graf
2020-05-28 13:12                   ` Greg KH
2020-05-28 17:06                     ` Paraschiv, Andra-Irina
2020-06-01  3:04                     ` Benjamin Herrenschmidt
2020-06-09 10:47                       ` Alexander Graf
2020-06-01  3:01                 ` Benjamin Herrenschmidt
2020-06-01  2:51           ` Benjamin Herrenschmidt [this message]
2020-05-26 13:40         ` Paraschiv, Andra-Irina
2020-06-01  2:47     ` Benjamin Herrenschmidt
2020-06-01  5:48       ` Greg KH
2020-05-25 22:13 ` [PATCH v3 08/18] nitro_enclaves: Add logic for enclave vm creation Andra Paraschiv
2020-05-25 22:13 ` [PATCH v3 09/18] nitro_enclaves: Add logic for enclave vcpu creation Andra Paraschiv
2020-05-25 22:13 ` [PATCH v3 10/18] nitro_enclaves: Add logic for enclave image load metadata Andra Paraschiv
2020-05-25 22:13 ` [PATCH v3 11/18] nitro_enclaves: Add logic for enclave memory region set Andra Paraschiv
2020-05-25 22:13 ` [PATCH v3 12/18] nitro_enclaves: Add logic for enclave start Andra Paraschiv
2020-05-25 22:13 ` [PATCH v3 13/18] nitro_enclaves: Add logic for enclave termination Andra Paraschiv
2020-05-25 22:13 ` [PATCH v3 14/18] nitro_enclaves: Add Kconfig for the Nitro Enclaves driver Andra Paraschiv
2020-05-25 22:13 ` [PATCH v3 15/18] nitro_enclaves: Add Makefile " Andra Paraschiv
2020-05-25 22:13 ` [PATCH v3 16/18] nitro_enclaves: Add sample for ioctl interface usage Andra Paraschiv
2020-05-26  6:52   ` Greg KH
2020-05-25 22:13 ` [PATCH v3 17/18] nitro_enclaves: Add overview documentation Andra Paraschiv
2020-05-25 22:13 ` [PATCH v3 18/18] MAINTAINERS: Add entry for the Nitro Enclaves driver Andra Paraschiv

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=f256a37a89db56fcad229a1cfea11b8636b13829.camel@kernel.crashing.org \
    --to=benh@kernel.crashing.org \
    --cc=aliguori@amazon.com \
    --cc=andraprs@amazon.com \
    --cc=colmmacc@amazon.com \
    --cc=doebel@amazon.de \
    --cc=dwmw@amazon.co.uk \
    --cc=fllinden@amazon.com \
    --cc=graf@amazon.de \
    --cc=gregkh@linuxfoundation.org \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mpohlack@amazon.de \
    --cc=msw@amazon.com \
    --cc=ne-devel-upstream@amazon.com \
    --cc=pbonzini@redhat.com \
    --cc=sblbir@amazon.com \
    --cc=sgarzare@redhat.com \
    --cc=stefanha@redhat.com \
    --cc=trawets@amazon.com \
    --cc=uwed@amazon.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.