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
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
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
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
>
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 see
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:
>
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
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:
> &
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.
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&id=14fd71e12b1c4492a06f368f75041f263e6862bf
Is it correct, or am I missing some subtlety?
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
> 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:
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:
> &
> 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
> 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 scali
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
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,
> 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.,
>>
> 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
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 t
> 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
> 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, 2018
> 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
>>>
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 do_hr
> 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
>&g
> 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 never
On Thu, Jul 13, 2017 at 5:46 AM, Vitaly Kuznetsov wrote:
> Andy Lutomirski writes:
>
>> On Tue, May 23, 2017 at 5:36 AM, Vitaly Kuznetsov
>> wrote:
>>> Andy Lutomirski writes:
>>>
>>>>
>>>> Also, can you share the benchmark you us
On Tue, May 23, 2017 at 5:36 AM, Vitaly Kuznetsov wrote:
> Andy Lutomirski writes:
>
>>
>> Also, can you share the benchmark you used for these patches?
>
> I didn't do much while writing the patchset, mostly I was running the
> attached dumb trasher (32 pthreads
On Mon, May 22, 2017 at 3:44 AM, Vitaly Kuznetsov wrote:
> Andy Lutomirski writes:
>
>> On 05/19/2017 07:09 AM, Vitaly Kuznetsov wrote:
>>> Hyper-V supports 'fast' hypercalls when all parameters are passed through
>>> registers. Implement an inli
On Mon, May 22, 2017 at 3:43 AM, Vitaly Kuznetsov wrote:
> Andy Lutomirski 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,
>>> this is supposed to work faster than IPIs.
>
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 don't
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 hv_hypercall_inp
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, kvm_hv_setup_tsc_page()) and the update does
>>> the follo
2ca9a <+58>:callq *0x81c36330
>0x8102caa1 <+65>:leaveq
>0x8102caa2 <+66>:retq
>0x8102caa3 <+67>:shl$0x20,%rdx
>0x8102caa7 <+71>:or %rdx,%rax
>0x8102caaa <+74>:
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 story and as there are V
On Thu, Feb 9, 2017 at 12:45 PM, KY Srinivasan wrote:
>
>
>> -Original Message-
>> From: Thomas Gleixner [mailto:t...@linutronix.de]
>> Sent: Thursday, February 9, 2017 9:08 AM
>> To: Vitaly Kuznetsov
>> Cc: x...@kernel.org; Andy Lutomirski ;
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 mutually
> exclusive wit
On May 13, 2016 2:42 AM, "Dr. Greg Wettstein" 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 comments and concerns.
>
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 explain what you mean
On Fri, May 6, 2016 at 4:23 AM, Jarkko Sakkinen
wrote:
> On Wed, Apr 27, 2016 at 10:18:05AM +0200, Ingo Molnar wrote:
>>
>> * Andy Lutomirski wrote:
>>
>> > > What new syscalls would be needed for ssh to get all this support?
>> >
>> > This patc
On Apr 27, 2016 1:18 AM, "Ingo Molnar" wrote:
>
>
> * Andy Lutomirski wrote:
>
> > > What new syscalls would be needed for ssh to get all this support?
> >
> > This patchset or similar, plus some user code and an enclave to use.
> >
> > S
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 that matter, r
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 MEE encrypts and
On Tue, Apr 26, 2016 at 12:41 PM, Pavel Machek wrote:
> On Tue 2016-04-26 12:05:48, Andy Lutomirski wrote:
>> 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 in
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 to access the me
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 get this merged correctly.
>>
>> I
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 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
>
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 derived from loops_per_jiffy.
Cc: Jarod Wilson
Cc: de...@driverdev.osuosl.org
Cc: Greg Kroah-Hartman
Signed-off-by: Andy Lutomirski
---
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 derived from loops_per_jiffy.
Cc: Jarod Wilson
Cc: de...@driverdev.osuosl.org
Cc: Greg Kroah-Hartman
Signed-off-by: Andy Lutomirski
---
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 derived from loops_per_jiffy.
Cc: Jarod Wilson
Cc: de...@driverdev.osuosl.org
Cc: Greg Kroah-Hartman
Signed-off-by: Andy Lutomirski
---
50 matches
Mail list logo
