Re: [PATCH v2 09/17] staging/lirc_serial: Remove TSC-based timing

Hi Mauro, etc: Are you okay with this change landing in the tip tree? --Andy On Fri, Jun 12, 2015 at 4:44 PM, Andy Lutomirski l...@kernel.org wrote: It wasn't compiled in by default. I suspect that the driver was and still is broken, though -- it's calling udelay with a parameter that's

[PATCH v3 09/18] staging/lirc_serial: Remove TSC-based timing

-by: Andy Lutomirski l...@kernel.org --- drivers/staging/media/lirc/lirc_serial.c | 63 ++-- 1 file changed, 4 insertions(+), 59 deletions(-) diff --git a/drivers/staging/media/lirc/lirc_serial.c b/drivers/staging/media/lirc/lirc_serial.c index dc7984455c3a

[PATCH v2 09/17] staging/lirc_serial: Remove TSC-based timing

-by: Andy Lutomirski l...@kernel.org --- drivers/staging/media/lirc/lirc_serial.c | 63 ++-- 1 file changed, 4 insertions(+), 59 deletions(-) diff --git a/drivers/staging/media/lirc/lirc_serial.c b/drivers/staging/media/lirc/lirc_serial.c index dc7984455c3a

[PATCH 09/17] staging/lirc_serial: Remove TSC-based timing

-by: Andy Lutomirski l...@kernel.org --- drivers/staging/media/lirc/lirc_serial.c | 63 ++-- 1 file changed, 4 insertions(+), 59 deletions(-) diff --git a/drivers/staging/media/lirc/lirc_serial.c b/drivers/staging/media/lirc/lirc_serial.c index dc7984455c3a

Re: [PATCH 0/6] Intel Secure Guard Extensions

t is cleared. > > I think I prepare a new version of the patches and point it directly > to arch/x86. Thanks. Please cc me as well. --Andy > >> And staging code is self-contained, putting files in arch/* isn't ok for >> it, which kind of implies that you should ge

Re: [PATCH 0/6] Intel Secure Guard Extensions

On Tue, Apr 26, 2016 at 2:52 PM, Pavel Machek wrote: > On Tue 2016-04-26 21:59:52, One Thousand Gnomes wrote: >> > But... that will mean that my ssh will need to be SGX-aware, and that >> > I will not be able to switch to AMD machine in future. ... or to other >> > Intel machine for

Re: [PATCH 0/6] Intel Secure Guard Extensions

On Apr 26, 2016 1:11 PM, "Pavel Machek" wrote: > > Hi! > > > >> >> The firmware uses PRMRR registers to reserve an area of physical > > >> >> memory > > >> >> called Enclave Page Cache (EPC). There is a hardware unit in the > > >> >> processor called Memory Encryption Engine. The

Re: [PATCH 0/6] Intel Secure Guard Extensions

On Apr 27, 2016 1:18 AM, "Ingo Molnar" <mi...@kernel.org> wrote: > > > * Andy Lutomirski <l...@amacapital.net> wrote: > > > > What new syscalls would be needed for ssh to get all this support? > > > > This patchset or similar, plus some use

Re: [PATCH 0/6] Intel Secure Guard Extensions

On Tue, Apr 26, 2016 at 12:00 PM, Pavel Machek wrote: > On Mon 2016-04-25 20:34:07, Jarkko Sakkinen wrote: >> Intel(R) SGX is a set of CPU instructions that can be used by >> applications to set aside private regions of code and data. The code >> outside the enclave is disallowed

Re: [PATCH 0/6] Intel Secure Guard Extensions

On May 13, 2016 2:42 AM, "Dr. Greg Wettstein" <g...@enjellic.com> wrote: > > On Sun, May 08, 2016 at 06:32:10PM -0700, Andy Lutomirski wrote: > > Good morning, running behind on e-mail this week but wanted to get > some reflections out on Andy's well taken commen

Re: [PATCH 0/6] Intel Secure Guard Extensions

On Fri, May 6, 2016 at 4:23 AM, Jarkko Sakkinen <jarkko.sakki...@linux.intel.com> wrote: > On Wed, Apr 27, 2016 at 10:18:05AM +0200, Ingo Molnar wrote: >> >> * Andy Lutomirski <l...@amacapital.net> wrote: >> >> > > What new syscalls wo

Re: [PATCH 0/6] Intel Secure Guard Extensions

On May 8, 2016 2:59 AM, "Dr. Greg Wettstein" wrote: > > > This now means the security of SGX on 'unlocked' platforms, at least > from a trust perspective, will be dependent on using TXT so as to > provide a hardware root of trust on which to base the SGX trust model. Can you

Re: [PATCH 0/6] Intel Secure Guard Extensions

On Tue, Apr 26, 2016 at 12:41 PM, Pavel Machek <pa...@ucw.cz> wrote: > On Tue 2016-04-26 12:05:48, Andy Lutomirski wrote: >> On Tue, Apr 26, 2016 at 12:00 PM, Pavel Machek <pa...@ucw.cz> wrote: >> > On Mon 2016-04-25 20:34:07, Jarkko Sakkinen wrote: >> >>

Re: [PATCH RFC 2/2] x86/vdso: Add VCLOCK_HVCLOCK vDSO clock read method

On Wed, Feb 8, 2017 at 9:07 AM, Vitaly Kuznetsov wrote: > Hyper-V TSC page clocksource is suitable for vDSO, however, the protocol > defined by the hypervisor is different from VCLOCK_PVCLOCK. Implement the > required support re-using pvclock_page VVAR as VCLOCK_PVCLOCK is

Re: [PATCH v2 0/3] x86/vdso: Add Hyper-V TSC page clocksource support

On Fri, Feb 17, 2017 at 2:14 AM, Vitaly Kuznetsov wrote: > Thomas Gleixner writes: > >> On Wed, 15 Feb 2017, Vitaly Kuznetsov wrote: >>> Actually, we already have an implementation of TSC page update in KVM >>> (see arch/x86/kvm/hyperv.c,

Re: [PATCH 2/2] x86/vdso: Add VCLOCK_HVCLOCK vDSO clock read method

On Thu, Feb 9, 2017 at 12:45 PM, KY Srinivasan <k...@microsoft.com> wrote: > > >> -Original Message- >> From: Thomas Gleixner [mailto:t...@linutronix.de] >> Sent: Thursday, February 9, 2017 9:08 AM >> To: Vitaly Kuznetsov <vkuzn...@redhat.com>

Re: [PATCH v2 0/3] x86/vdso: Add Hyper-V TSC page clocksource support

mov%rsp,%rbp >0x8102ca96 <+54>:and$0xfff0,%rsp >0x8102ca9a <+58>:callq *0x81c36330 >0x8102caa1 <+65>:leaveq >0x8102caa2 <+66>:retq > 0xffff8102caa3 <+67>:s

Re: [PATCH 2/2] x86/vdso: Add VCLOCK_HVCLOCK vDSO clock read method

On Sun, Feb 12, 2017 at 11:49 PM, Dexuan Cui wrote: >> From: Thomas Gleixner [mailto:t...@linutronix.de] >> Sent: Saturday, February 11, 2017 02:02 >> ... >> That's important if the stuff happens cross CPU. If the update happens on >> the same CPU then this is a different

Re: [PATCH v3 08/10] x86/hyper-v: use hypercall for remote TLB flush

On Thu, Jul 13, 2017 at 5:46 AM, Vitaly Kuznetsov <vkuzn...@redhat.com> wrote: > Andy Lutomirski <l...@kernel.org> writes: > >> On Tue, May 23, 2017 at 5:36 AM, Vitaly Kuznetsov <vkuzn...@redhat.com> >> wrote: >>> Andy Lutomirski <l...@kerne

Re: [PATCH v3 08/10] x86/hyper-v: use hypercall for remote TLB flush

On Tue, May 23, 2017 at 5:36 AM, Vitaly Kuznetsov <vkuzn...@redhat.com> wrote: > Andy Lutomirski <l...@kernel.org> writes: > >> >> Also, can you share the benchmark you used for these patches? > > I didn't do much while writing the patchset, mostly I was run

Re: [PATCH v3 04/10] x86/hyper-v: fast hypercall implementation

On Mon, May 22, 2017 at 3:44 AM, Vitaly Kuznetsov <vkuzn...@redhat.com> wrote: > Andy Lutomirski <l...@kernel.org> writes: > >> On 05/19/2017 07:09 AM, Vitaly Kuznetsov wrote: >>> Hyper-V supports 'fast' hypercalls when all parameters are passed through >>&

Re: [PATCH v3 08/10] x86/hyper-v: use hypercall for remote TLB flush

On Mon, May 22, 2017 at 3:43 AM, Vitaly Kuznetsov <vkuzn...@redhat.com> wrote: > Andy Lutomirski <l...@kernel.org> writes: > >> On 05/19/2017 07:09 AM, Vitaly Kuznetsov wrote: >>> Hyper-V host can suggest us to use hypercall for doing remote TLB flush, >>>

Re: [PATCH v3 04/10] x86/hyper-v: fast hypercall implementation

On 05/19/2017 07:09 AM, Vitaly Kuznetsov wrote: Hyper-V supports 'fast' hypercalls when all parameters are passed through registers. Implement an inline version of a simpliest of these calls: hypercall with one 8-byte input and no output. Proper hypercall input interface (struct

Re: [PATCH v3 08/10] x86/hyper-v: use hypercall for remote TLB flush

On 05/19/2017 07:09 AM, Vitaly Kuznetsov wrote: Hyper-V host can suggest us to use hypercall for doing remote TLB flush, this is supposed to work faster than IPIs. Implementation details: to do HvFlushVirtualAddress{Space,List} hypercalls we need to put the input somewhere in memory and we

Re: [patch 00/11] x86/vdso: Cleanups, simmplifications and CLOCK_TAI support

On Thu, Oct 11, 2018 at 3:28 PM Marcelo Tosatti wrote: > > On Tue, Oct 09, 2018 at 01:09:42PM -0700, Andy Lutomirski wrote: > > On Tue, Oct 9, 2018 at 8:28 AM Marcelo Tosatti wrote: > > > > > > On Mon, Oct 08, 2018 at 10:38:22AM -0700, Andy Lutomirski wrote: >

Re: [patch 00/11] x86/vdso: Cleanups, simmplifications and CLOCK_TAI support

On Thu, Oct 4, 2018 at 9:43 AM Marcelo Tosatti wrote: > > On Wed, Oct 03, 2018 at 03:32:08PM -0700, Andy Lutomirski wrote: > > On Wed, Oct 3, 2018 at 12:01 PM Marcelo Tosatti wrote: > > > > > > On Tue, Oct 02, 2018 at 10:15:49PM -0700, Andy Lutomirski wrote: > &

Re: [patch 00/11] x86/vdso: Cleanups, simmplifications and CLOCK_TAI support

e base, which at the end all together gain a few > cycles performance or at least stay on par with todays code. The resulting > performance depends heavily on the micro architecture and the compiler. tglx, please consider this whole series Acked-by: Andy Lutomirski Please feel free to pu

Re: [patch 00/11] x86/vdso: Cleanups, simmplifications and CLOCK_TAI support

> On Oct 4, 2018, at 12:31 PM, Peter Zijlstra wrote: > > On Thu, Oct 04, 2018 at 07:00:45AM -0700, Andy Lutomirski wrote: >>> On Oct 4, 2018, at 1:11 AM, Peter Zijlstra wrote: >>> >>>> On Thu, Oct 04, 2018 at 09:54:45AM +0200, Vitaly Kuznetsov wrote:

Re: [patch 00/11] x86/vdso: Cleanups, simmplifications and CLOCK_TAI support

> On Oct 3, 2018, at 5:01 AM, Vitaly Kuznetsov wrote: > > Andy Lutomirski writes: > >>> On Oct 3, 2018, at 2:22 AM, Vitaly Kuznetsov wrote: >>> >>> Andy Lutomirski writes: >>> >>>> Hi Vitaly, Paolo, Radim, etc., >>

Re: [patch 00/11] x86/vdso: Cleanups, simmplifications and CLOCK_TAI support

On Wed, Oct 3, 2018 at 8:10 AM Thomas Gleixner wrote: > > On Wed, 3 Oct 2018, Andy Lutomirski wrote: > > > On Oct 3, 2018, at 5:01 AM, Vitaly Kuznetsov wrote: > > > Not all Hyper-V hosts support reenlightenment notifications (and, if I'm > > > not mistaken, you

Re: [patch 00/11] x86/vdso: Cleanups, simmplifications and CLOCK_TAI support

For better or for worse, I'm trying to understand this code. So far, I've come up with this patch: https://git.kernel.org/pub/scm/linux/kernel/git/luto/linux.git/commit/?h=x86/vdso-tglx=14fd71e12b1c4492a06f368f75041f263e6862bf Is it correct, or am I missing some subtlety?

Re: [patch 00/11] x86/vdso: Cleanups, simmplifications and CLOCK_TAI support

Hi Vitaly, Paolo, Radim, etc., On Fri, Sep 14, 2018 at 5:52 AM Thomas Gleixner wrote: > > Matt attempted to add CLOCK_TAI support to the VDSO clock_gettime() > implementation, which extended the clockid switch case and added yet > another slightly different copy of the same code. > > Especially

Re: [patch 00/11] x86/vdso: Cleanups, simmplifications and CLOCK_TAI support

On Wed, Oct 3, 2018 at 12:01 PM Marcelo Tosatti wrote: > > On Tue, Oct 02, 2018 at 10:15:49PM -0700, Andy Lutomirski wrote: > > Hi Vitaly, Paolo, Radim, etc., > > > > On Fri, Sep 14, 2018 at 5:52 AM Thomas Gleixner wrote: > > > > > > Matt atte

Re: [patch 00/11] x86/vdso: Cleanups, simmplifications and CLOCK_TAI support

> On Oct 4, 2018, at 1:11 AM, Peter Zijlstra wrote: > >> On Thu, Oct 04, 2018 at 09:54:45AM +0200, Vitaly Kuznetsov wrote: >> I was hoping to hear this from you :-) If I am to suggest how we can >> move forward I'd propose: >> - Check if pure TSC can be used on SkyLake+ systems (where TSC

Re: [patch 00/11] x86/vdso: Cleanups, simmplifications and CLOCK_TAI support

> On Oct 4, 2018, at 5:00 AM, Paolo Bonzini wrote: > >> On 04/10/2018 09:54, Vitaly Kuznetsov wrote: >> - Check if pure TSC can be used on SkyLake+ systems (where TSC scaling >> is supported). > > Not if you want to migrate to pre-Skylake systems. > >> - Check if non-masterclock mode is still

Re: [patch 00/11] x86/vdso: Cleanups, simmplifications and CLOCK_TAI support

> On Oct 3, 2018, at 2:22 AM, Vitaly Kuznetsov wrote: > > Andy Lutomirski writes: > >> Hi Vitaly, Paolo, Radim, etc., >> >>> On Fri, Sep 14, 2018 at 5:52 AM Thomas Gleixner wrote: >>> >>> Matt attempted to add CLOCK_TAI support to

Re: [patch 00/11] x86/vdso: Cleanups, simmplifications and CLOCK_TAI support

On Sat, Oct 6, 2018 at 1:29 PM Marcelo Tosatti wrote: > > On Thu, Oct 04, 2018 at 03:15:32PM -0700, Andy Lutomirski wrote: > > For better or for worse, I'm trying to understand this code. So far, > > I've come up with this patch: > > > > https://git.kernel.org

Re: [patch 00/11] x86/vdso: Cleanups, simmplifications and CLOCK_TAI support

On Mon, Oct 8, 2018 at 8:27 AM Marcelo Tosatti wrote: > > On Sat, Oct 06, 2018 at 03:28:05PM -0700, Andy Lutomirski wrote: > > On Sat, Oct 6, 2018 at 1:29 PM Marcelo Tosatti wrote: > > > > > > On Thu, Oct 04, 2018 at 03:15:32PM -0700, Andy Lutomirski wrote: > &

Re: [patch 00/11] x86/vdso: Cleanups, simmplifications and CLOCK_TAI support

On Tue, Oct 9, 2018 at 8:28 AM Marcelo Tosatti wrote: > > On Mon, Oct 08, 2018 at 10:38:22AM -0700, Andy Lutomirski wrote: > > On Mon, Oct 8, 2018 at 8:27 AM Marcelo Tosatti wrote: > > I read the comment three more times and even dug through the git > > history. I

Re: [patch 09/11] x86/vdso: Simplify the invalid vclock case

> On Sep 27, 2018, at 7:36 AM, Thomas Gleixner wrote: > >> On Wed, 19 Sep 2018, Thomas Gleixner wrote: >> On Tue, 18 Sep 2018, Andy Lutomirski wrote: >>>> On Sep 18, 2018, at 3:46 PM, Thomas Gleixner wrote: >>>>> On Tue, 18 Sep 2018, Andy Luto

Re: [patch 11/11] x66/vdso: Add CLOCK_TAI support

> On Sep 14, 2018, at 7:27 AM, Thomas Gleixner wrote: > > On Fri, 14 Sep 2018, Andy Lutomirski wrote: >>> On Sep 14, 2018, at 5:50 AM, Thomas Gleixner wrote: >>> >>> With the storage array in place it's now trivial to support CLOCK_TAI in >>

Re: [patch 11/11] x66/vdso: Add CLOCK_TAI support

> On Sep 14, 2018, at 5:50 AM, Thomas Gleixner wrote: > > With the storage array in place it's now trivial to support CLOCK_TAI in > the vdso. Instead of extending the array to accomodate CLOCK_TAI, make use > of the fact that: > > - CLOCK ids are set in stone > - CLOCK_THREAD_CPUTIME is

Re: [patch 09/11] x86/vdso: Simplify the invalid vclock case

On Fri, Sep 14, 2018 at 5:50 AM, Thomas Gleixner wrote: > The code flow for the vclocks is convoluted as it requires the vclocks > which can be invalidated separately from the vsyscall_gtod_data sequence to > store the fact in a separate variable. That's inefficient. > > notrace static int

Re: [patch 09/11] x86/vdso: Simplify the invalid vclock case

> On Sep 18, 2018, at 3:46 PM, Thomas Gleixner wrote: > > On Tue, 18 Sep 2018, Andy Lutomirski wrote: >>> On Sep 18, 2018, at 12:52 AM, Thomas Gleixner wrote: >>> >>>>> On Mon, 17 Sep 2018, John Stultz wrote: >>>>> On Mon, Sep 17,

Re: [patch 09/11] x86/vdso: Simplify the invalid vclock case

> On Sep 18, 2018, at 12:52 AM, Thomas Gleixner wrote: > >> On Mon, 17 Sep 2018, John Stultz wrote: >>> On Mon, Sep 17, 2018 at 12:25 PM, Andy Lutomirski wrote: >>> Also, I'm not entirely convinced that this "last" thing is needed at >>> al

Re: pidfd design

On Mon, Mar 25, 2019 at 4:45 PM Christian Brauner wrote: > > On Mon, Mar 25, 2019 at 04:42:14PM -0700, Andy Lutomirski wrote: > > On Mon, Mar 25, 2019 at 1:23 PM Daniel Colascione wrote: > > > > > > On Mon, Mar 25, 2019 at 1:14 PM Jann Horn wrote: > > > &g

Re: pidfd design

On Mon, Mar 25, 2019 at 1:23 PM Daniel Colascione wrote: > > On Mon, Mar 25, 2019 at 1:14 PM Jann Horn wrote: > > > > On Mon, Mar 25, 2019 at 8:44 PM Andy Lutomirski wrote: > > One ioctl on procfs roots to translate pidfds into that procfs, > > subject to bot

Re: pidfd design

On Mon, Mar 25, 2019 at 5:12 PM Christian Brauner wrote: > > On Mon, Mar 25, 2019 at 05:00:17PM -0700, Andy Lutomirski wrote: > > On Mon, Mar 25, 2019 at 4:45 PM Christian Brauner > > wrote: > > > > > > On Mon, Mar 25, 2019 at 04:42:14PM -0700, Andy Luto

Re: pidfd design

On Wed, Mar 20, 2019 at 11:52 AM Christian Brauner wrote: > > You're misunderstanding. Again, I said in my previous mails it should > accept pidfds optionally as arguments, yes. But I don't want it to > return the status fds that you previously wanted pidfd_wait() to return. > I really want to

Re: pidfd design

On Wed, Mar 20, 2019 at 12:40 PM Daniel Colascione wrote: > > On Wed, Mar 20, 2019 at 12:14 PM Christian Brauner > wrote: > > > > On Wed, Mar 20, 2019 at 11:58:57AM -0700, Andy Lutomirski wrote: > > > On Wed, Mar 20, 2019 at 11:52 AM Christian Brauner >