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.
next prev 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).