Hi, Thomas,
> On Wed, Jan 27, 2021 2:16 PM, Thomas Gleixner wrote:
> On Tue, Nov 24 2020 at 20:52, Fenghua Yu wrote:
>
> > A bus lock is acquired though either split locked access to writeback
> > (WB) memory or any locked access to non-WB memory. This is typically
> > >1000 cycles slower than an
Hi, Shuah,
> This patch set has several miscellaneous fixes to resctrl selftest tool that
> are
> easily visible to user. V1 had fixes to CAT test and CMT test but they were
> dropped in V2 because having them here made the patchset humongous. So,
> changes to CAT test and CMT test will be posted
Hi, Dear maintainers,
> A bus lock [1] is acquired through either split locked access to writeback
> (WB)
> memory or any locked access to non-WB memory. This is typically >1000
> cycles slower than an atomic operation within a cache line. It also disrupts
> performance on other cores.
...
> Ch
Hi, Randy,
> >>> + for bus lock detection. 0 < N <= HZ/2 and
> >>> + N is approximate. Only applied to non-root
> >>> + users.
> >>
> >> Sorry, but I don't know what this means. I think it's the "and N is
> >> appropriat
Hi, Randy,
> > + ratelimit:N -
> > + Set rate limit to N bus locks per second
> > + for bus lock detection. 0 < N <= HZ/2 and
> > + N is approximate. Only applied to non-root
> > +
Hi, Peter,
> > #DB for bus lock is enabled by bus lock detection bit 2 in DEBUGCTL
> > MSR while #AC for split lock is enabled by split lock detection bit 29
> > in TEST_CTRL MSR.
> >
> > Delivery of #DB for bus lock in userspace clears DR6[11]. To avoid
> > confusion in identifying #DB, #DB handl
Hi, Peter,
> On Sun, Nov 08, 2020 at 04:29:16AM +, Fenghua Yu wrote:
> > split_lock_detect=
> > #AC for split lock #DB for bus lock
> >
> > off Do nothing Do nothing
> >
> > warnKernel OOPs Warn once per
Hi, Sean,
> > A bus lock [1] is acquired either through split locked access to
> > writeback (WB) memory or by using locks to uncacheable (UC) memory
> > (e.g. direct device
>
> Does SLD not detect the lock to UC memory?
The statement might not be accurate. Split Lock Detection doesn't detect bu
> On Tuesday, June 11, 2019 3:28 PM, Fenghua Yu wrote:
> On Tue, Jun 11, 2019 at 09:47:02PM +0200, Borislav Petkov wrote:
> > On Tue, Jun 11, 2019 at 11:19:20AM -0700, Fenghua Yu wrote:
> > > So can I re-organize word 11 and 12 as follows?
> > >
> > > 1. Change word 11 to host scattered features.
>
> On Thursday, May 30, 2019 2:11 PM Andy Lutomirski [mailto:l...@kernel.org]
> wrote:
> On Fri, May 24, 2019 at 5:05 PM Fenghua Yu wrote:
> >
> > C0.2 state in umwait and tpause instructions can be enabled or
> > disabled on a processor through IA32_UMWAIT_CONTROL MSR register.
> >
> > By default
> On Friday, May 10, 2019 10:40 AM
> Andre Przywara [mailto:andre.przyw...@arm.com] wrote:
> To: Yu, Fenghua
> Cc: Thomas Gleixner ; Ingo Molnar
> ; Borislav Petkov ; H Peter Anvin
> ; Luck, Tony ; Chatre, Reinette
> ; Shankar, Ravi V ;
> Shen, Xiaochen ; Pathan, Arshi
>On Friday, May 10, 2019 10:36 AM
>Andre Przywara [mailto:andre.przyw...@arm.com] wrote:
> On Sat, 9 Feb 2019 18:50:29 -0800
> Fenghua Yu wrote:
>
> Hi Fenghua, Babu,
>
> > With more and more resctrl features are being added by Intel, AMD and
> > ARM, a test tool is becoming more and more usefu
> From: Andre Przywara [mailto:andre.przyw...@arm.com]
> On Sat, 9 Feb 2019 18:50:31 -0800
> Fenghua Yu wrote:
>
> Hi,
>
> some comments inline.
>
> > From: Sai Praneeth Prakhya
> >
> > The basic resctrl file system operations and data are added for future
> > usage by resctrl selftest tool.
> From: Borislav Petkov [mailto:b...@alien8.de]
> On Sat, Feb 09, 2019 at 06:50:31PM -0800, Fenghua Yu wrote:
> > From: Sai Praneeth Prakhya
> >
> > The basic resctrl file system operations and data are added for future
> > usage by resctrl selftest tool.
> >
> > Signed-off-by: Sai Praneeth Prakhy
> From: Hansen, Dave
> On 3/1/19 6:44 PM, Fenghua Yu wrote:
> > diff --git a/arch/x86/include/asm/cpufeatures.h
> b/arch/x86/include/asm/cpufeatures.h
> > index 6d6122524711..350eeccd0ce9 100644
> > --- a/arch/x86/include/asm/cpufeatures.h
> > +++ b/arch/x86/include/asm/cpufeatures.h
> > @@ -349,6
> From: Fenghua Yu [mailto:fenghua...@intel.com]
> On Wed, Feb 20, 2019 at 10:37:27PM -0800, Andy Lutomirski wrote:
> Or to simplify the situation, how about we still use zero as global max wait
> time (i.e. no limitation for global wait time) as implemented in this patch
> set? User can still chan
> From: Ingo Molnar [mailto:mingo.kernel@gmail.com] On Behalf Of Ingo Molnar
> > On Mon, Feb 11, 2019 at 11:53:39AM +0100, Ingo Molnar wrote:
> > > > + do_trap(trapnr, signr, str, regs, error_code,
> > > > BUS_ADRALN,
> NULL);
> > > > + }
> > > > +}
> > >
> > > Is there any
> From: Peter Zijlstra [mailto:pet...@infradead.org]
> On Tue, Feb 12, 2019 at 02:51:00PM +0100, Thomas Gleixner wrote:
> > On Tue, 12 Feb 2019, Peter Zijlstra wrote:
> >
> > > On Mon, Feb 11, 2019 at 11:16:43AM -0800, Fenghua Yu wrote:
> > > > 4. The feature can be disabled by kernel option
> > >
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> On 17/01/2019 00:00, Andy Lutomirski wrote:
> > On Wed, Jan 16, 2019 at 1:24 PM Fenghua Yu
> wrote:
> >> IA32_UMWAIT_CONTROL[31:2] determines the maximum time in TSC-
> quanta
> >> that processor can stay in C0.1 or C0.2.
> >>
> >> The max
> From: Moger, Babu [mailto:babu.mo...@amd.com]
> > F: Documentation/x86/intel_rdt*
>
> This patch does not apply cleanly. We have changed the above names from
> intel_rdt to resctrl now. You need to re-base again.
That's right. Will rebase this patch.
Thanks.
-Fenghua
> From: Moger, Babu [mailto:babu.mo...@amd.com]
> for (int i = 0; i < argc; i++) {
>^
> resctrl_tests.c:39:56: note: previous declaration of 'i' was here
> int res, c, core_id = 1, span = 250, argc_new = argc, i, no_of_bits = 5;
>
> From: Thomas Gleixner [mailto:t...@linutronix.de]
> On Tue, 16 Jan 2018, Joseph Salisbury wrote:
> > On 01/16/2018 08:32 AM, Shankar, Ravi V wrote:
> > > Vikas on vacation until end of the month. Fenghua will look into
> > > this issue.
> > >
> > > On Jan 16, 2018, at 5:09 AM, Thomas Gleixner >
> > When L2 CDP is enabled, the schemata will have the two resources in
> > this format:
> > L2DATA:l2id0=;l2id1=;
> > L2CODE:l2id0=;l2id1=;
>
> Hi,
>
> What do the represent?
The represents CBM (Cache Bit Mask) values in the schemata, similar to all
others (L2
> On Tuesday, October 31, 2017 11:33 AM, Borislav Petkov wrote:
> On Tue, Oct 31, 2017 at 06:25:55PM +0000, Yu, Fenghua wrote:
> > We may need to send a patch to fix a few legacy names that don't match
> > exactly specs, e.g. AVX512VBMI as you mentioned.
>
> Or we
> On Tuesday, October 31, 2017 11:03 AM, Yu, Fenghua wrote
> > On Tuesday, October 31, 2017 3:06 AM, Borislav Petkov wrote:
> > On Mon, Oct 30, 2017 at 06:20:29PM -0700, Gayatri Kammela wrote:
> > > #define X86_FEATURE_AVX512VBMI (16*32+ 1) /* AVX512 Vector Bit
>
> On Tuesday, October 31, 2017 3:06 AM, Borislav Petkov wrote:
> On Mon, Oct 30, 2017 at 06:20:29PM -0700, Gayatri Kammela wrote:
> > #define X86_FEATURE_AVX512VBMI (16*32+ 1) /* AVX512 Vector Bit
> Manipulation instructions*/
>
> So we have previous AVX512 feature bits which do not separate AVX
> From: Chatre, Reinette on Friday, October 20, 2017 2:17 AM
> Subject: [PATCH 3/3] x86/intel_rdt: Fix potential deadlock during resctrl
> mount
Acked-by: Fenghua Yu
> From: Chatre, Reinette on Friday, October 20, 2017 2:17 AM
> Subject: [PATCH 2/3] x86/intel_rdt: Fix potential deadlock during resctrl
> unmount
>
Acked-by: Fenghua Yu
> From: Sergey Senozhatsky [mailto:sergey.senozhatsky.w...@gmail.com]
> On (09/07/17 16:05), Luck, Tony wrote:
> +static inline bool __mod_text_address(struct module *mod,
> + unsigned long addr) {
> + /* Make sure it's within the text section. */
> +
> From: Andi Kleen [mailto:a...@firstfloor.org]
> "Luck, Tony" writes:
> > 9) Measure per logical CPU (pick active RMID in same precedence for
> task/cpu as CAT picks CLOSID)
> > 10) Put multiple CPUs into a group
>
> I'm not sure this is a real requirement. It's just an optimization, right? If
> From: Thomas Gleixner [mailto:t...@linutronix.de]
> On Tue, 17 Jan 2017, Shivappa Vikas wrote:
> > On Tue, 17 Jan 2017, Thomas Gleixner wrote:
> > > On Fri, 6 Jan 2017, Vikas Shivappa wrote:
> > > > - Issue(1): Inaccurate data for per package data, systemwide. Just
> > > > prints zeros or arbitra
> From: Arnd Bergmann [mailto:a...@arndb.de]
> The newly introduced rdt_mount function returns an unintialized pointer if
> rdtgroup_create_info_dir() fails:
>
> arch/x86/kernel/cpu/intel_rdt_rdtgroup.c: In function ‘rdt_mount’:
> arch/x86/kernel/cpu/intel_rdt_rdtgroup.c:710:9: error: ‘dentry’ may
> Gentlemen!
>
> After more than two years of tinkering and real engineering, we finaly have
> skinned the CAT!
Yeah! We made it!
>
> That was the most amazing review journey I ever made as a maintainer. Just
> a few statistics:
>
> Design variants: 6
>
> 6 different approaches for a user s
> > > I wonder whether this is the proper abstraction level. We might as
> > > well do the following:
> > >
> > > rdtresources[] = {
> > > {
> > > .name = "L3",
> > > },
> > > {
> > > .name = "L3Data",
> > > },
> > > {
> > > .name = "L3Code",
> > > },
> > >
> From: Thomas Gleixner [mailto:t...@linutronix.de]
> Sent: Thursday, September 08, 2016 2:54 AM
>
> On Thu, 8 Sep 2016, Fenghua Yu wrote:
> > +extern struct static_key rdt_enable_key; void
> > +__intel_rdt_sched_in(void *dummy);
> > +
> > struct clos_cbm_table {
> > unsigned long cbm;
> >
> > Hmm, I don't know how applications are going to use the interface.
> > Nobody knows it right now. But we do have some candicate workloads
> > which want to configure the cache partition at runtime, so it's not
> > just a boot time stuff. I'm wondering why we have such limitation. The
> > framew
> From: Borislav Petkov [mailto:b...@suse.de]
> On Thu, Sep 08, 2016 at 02:57:01AM -0700, Fenghua Yu wrote:
> > From: Vikas Shivappa
> >
> > This patch includes CPUID enumeration routines for Cache allocation
> > and new values to track resources to the cpuinfo_x86 structure.
> >
> > Cache allocat
> On Thu, 8 Sep 2016, Fenghua Yu wrote:
> > + cpuid_count(0x0010, 1, &eax, &ebx, &ecx,
> &edx);
> > + c->x86_l3_max_closid = edx + 1;
> > + c->x86_l3_max_cbm_len = eax + 1;
>
> According to the SDM:
>
> EAX Bits 4:0: Length of the ca
> From: Thomas Gleixner [mailto:t...@linutronix.de]
> Sent: Tuesday, July 19, 2016 5:32 AM
> On Thu, 14 Jul 2016, Luck, Tony wrote:
> > So the core part of __intel_rdt_sched_in() will look like:
> >
> > rdtgrp = root_rdtgroup;
> That can be done simpler. The default cpu_rdtgroup
>
> > +static inline void intel_rdt_cpu_start(int cpu) {
> > + struct intel_pqr_state *state = &per_cpu(pqr_state, cpu);
> > +
> > + state->closid = 0;
> > + mutex_lock(&rdt_group_mutex);
> > + if (rdt_cpumask_update(cpu))
> > + smp_call_function_single(cpu, c
> From: David Carrillo-Cisneros [mailto:davi...@google.com]
> > +static int get_res_type(char **res, enum resource_type *res_type) {
> > + char *tok;
> > +
> > + tok = strsep(res, ":");
> > + if (tok == NULL)
> > + return -EINVAL;
> > +
> > + if (!strcmp(tok, "
> From: Thomas Gleixner [mailto:t...@linutronix.de]
> Sent: Wednesday, July 13, 2016 11:11 PM
> On Wed, 13 Jul 2016, David Carrillo-Cisneros wrote:
> > > +static void free_cache_resource(struct cache_resource *l) {
> > > + kfree(l->cbm);
> > > + kfree(l->cbm2);
> > > + kfree(l->cl
> From: Thomas Gleixner [mailto:t...@linutronix.de]
> Sent: Wednesday, July 13, 2016 2:03 PM
> On Wed, 13 Jul 2016, Yu, Fenghua wrote:
> > On Wed, July 2016, Thomas Gleixner wrote
> > > On Tue, 12 Jul 2016, Fenghua Yu wrote:
> > > > +void rdtgroup
> From: Thomas Gleixner [mailto:t...@linutronix.de]
> Sent: Wednesday, July 13, 2016 2:10 PM
> On Wed, 13 Jul 2016, Yu, Fenghua wrote:
> > Here is why this patch behaves like this:
> >
> > This patch and actually first 12 patches are directly from last year's
>
> From: Thomas Gleixner [mailto:t...@linutronix.de]
> Sent: Wednesday, July 13, 2016 3:26 AM
> On Tue, 12 Jul 2016, Fenghua Yu wrote:
>
> Subject: Define CONFIG_INTEL_RDT
>
> That does not qualify as a proper patch subject
>
> > From: Vikas Shivappa
> >
> > CONFIG_INTEL_RDT is defined.
>
> Tha
> From: Thomas Gleixner [mailto:t...@linutronix.de]
> Sent: Wednesday, July 13, 2016 5:56 AM
> On Tue, 12 Jul 2016, Fenghua Yu wrote:
> > From: Fenghua Yu
> >
> > rg_list is linked list to connect to other tasks in a rdtgroup.
>
> Can you please prefix that member proper, e.g. rdt_group_list
The
> From: Thomas Gleixner [mailto:t...@linutronix.de]
> Sent: Wednesday, July 13, 2016 6:07 AM
> To: Yu, Fenghua
> Cc: Ingo Molnar ; Anvin, H Peter
> ; Luck, Tony ; Tejun Heo
> ; Borislav Petkov ; Stephane Eranian
> ; Peter Zijlstra ; Marcelo
> Tosatti ; David Carrillo-Cisn
> From: Ingo Molnar [mailto:mingo.kernel@gmail.com] On Behalf Of Ingo
> Molnar
> Sent: Friday, July 08, 2016 1:42 AM
> * Fenghua Yu wrote:
>
> > From: Fenghua Yu
> >
> > Add an ABI document entry for
> /sys/devices/system/cpu/cpu*/cache/index*/id.
> >
> > Signed-off-by: Fenghua Yu
> > ---
>
> From: Borislav Petkov [mailto:b...@suse.de]
> Sent: Thursday, July 07, 2016 9:21 AM
> On Wed, Jul 06, 2016 at 03:07:15PM -0700, Fenghua Yu wrote:
> > From: Fenghua Yu
> >
> > This patch set introduces cache id to identify a cache in platform. It
> > can be useful in such areas as Cach Allocation
> From: Borislav Petkov [mailto:b...@suse.de]
> Sent: Friday, July 01, 2016 11:36 AM
> To: Yu, Fenghua
> Cc: Luck, Tony ; Thomas Gleixner
> ; Ingo Molnar ; Anvin, H Peter
> ; Peter Zijlstra ;
> Stephane Eranian ; Shankar, Ravi V
> ; Vikas Shivappa
> ; linux-kernel k
> From: Borislav Petkov [mailto:b...@suse.de]
> Sent: Friday, July 01, 2016 11:40 AM
> On Fri, Jul 01, 2016 at 06:32:19PM +0000, Yu, Fenghua wrote:
> > We has prefix "L3" or "L2" in the syntax, id is for that level in each
> > line.b
>
> Give me a
> From: Borislav Petkov [mailto:b...@suse.de]
> Sent: Friday, July 01, 2016 11:29 AM
> To: Luck, Tony
> Cc: Yu, Fenghua ; Thomas Gleixner
> ; Ingo Molnar ; Anvin, H Peter
> ; Peter Zijlstra ;
> Stephane Eranian ; Shankar, Ravi V
> ; Vikas Shivappa
> ; linux-kernel k
> From: Borislav Petkov [mailto:b...@suse.de]
> Sent: Friday, July 01, 2016 10:28 AM
> To: Luck, Tony
> Cc: Yu, Fenghua ; Thomas Gleixner
> ; Ingo Molnar ; Anvin, H Peter
> ; Peter Zijlstra ;
> Stephane Eranian ; Shankar, Ravi V
> ; Vikas Shivappa
> ; linux-kernel k
> From: Dey, Megha
> Sent: Thursday, May 19, 2016 5:43 PM
> To: herb...@gondor.apana.org.au
> Cc: tim.c.c...@linux.intel.com; da...@davemloft.net; linux-
> cry...@vger.kernel.org; linux-kernel@vger.kernel.org; Dey, Megha
> ; Yu, Fenghua ; Megha
> Dey
> Subject: [P
> From: Borislav Petkov [mailto:b...@suse.de]
> Sent: Wednesday, May 11, 2016 10:21 AM
> To: Yu, Yu-cheng
> Cc: linux-kernel@vger.kernel.org; x...@kernel.org; H. Peter Anvin
> ; Thomas Gleixner ; Ingo Molnar
> ; Dave Hansen ; Andy
> Lutomirski ; Prakhya, Sai Praneeth
>
> From: Herbert Xu [mailto:herb...@gondor.apana.org.au]
> Sent: Tuesday, April 05, 2016 5:04 AM
> To: megha@linux.intel.com
> Cc: da...@davemloft.net; linux-cry...@vger.kernel.org; linux-
> ker...@vger.kernel.org; tim.c.c...@linux.intel.com; Yu, Fenghua
> ; Dey, Megha
>
> From: megha@linux.intel.com [mailto:megha@linux.intel.com]
> Sent: Thursday, March 24, 2016 1:26 PM
> To: herb...@gondor.apana.org.au; da...@davemloft.net
> Cc: linux-cry...@vger.kernel.org; linux-kernel@vger.kernel.org;
> tim.c.c...@linux.intel.com; Yu, Fenghua ; Megha
&
> From: Richard Weinberger [mailto:richard.weinber...@gmail.com]
> Sent: Saturday, January 02, 2016 2:54 PM
> On Mon, Dec 21, 2015 at 6:05 PM, Marcelo Tosatti
> wrote:
> > OK cool hopefully that makes it clear to Fenghua Yu what must be
> > changed in the patchset.
> >
> >> - http://lkml.iu.edu/h
> From: Thomas Gleixner [mailto:t...@linutronix.de]
> Sent: Wednesday, November 18, 2015 10:25 AM
> Folks!
>
> After rereading the mail flood on CAT and staring into the SDM for a while, I
> think we all should sit back and look at it from scratch again w/o our
> preconceptions - I certainly had t
> From: Marcelo Tosatti [mailto:mtosa...@redhat.com]
> Sent: Wednesday, November 18, 2015 1:27 PM
> To: Yu, Fenghua
> Cc: H Peter Anvin ; Ingo Molnar ;
> Thomas Gleixner ; Peter Zijlstra
> ; linux-kernel ; x86
> ; Vikas Shivappa
> Subject: Re: [PATCH V15 11/11] x86,
> From: Marcelo Tosatti [mailto:mtosa...@redhat.com]
> Sent: Wednesday, November 18, 2015 2:15 PM
> To: Yu, Fenghua
> Cc: H Peter Anvin ; Ingo Molnar ;
> Thomas Gleixner ; Peter Zijlstra
> ; linux-kernel ; x86
> ; Vikas Shivappa
> Subject: Re: [PATCH V15 11/11] x86,
> From: Thomas Gleixner [mailto:t...@linutronix.de]
> Sent: Sunday, October 11, 2015 12:50 PM
> To: Yu, Fenghua
> Cc: H Peter Anvin; Ingo Molnar; Peter Zijlstra; linux-kernel; x86; Vikas
> Shivappa; Marcelo Tosatti
> Subject: Re: [PATCH V15 00/11] x86: Intel Cache Allocation Te
> From: Thomas Gleixner [mailto:t...@linutronix.de]
> Sent: Sunday, October 11, 2015 12:52 PM
> To: Yu, Fenghua
> Cc: H Peter Anvin; Ingo Molnar; Peter Zijlstra; linux-kernel; x86; Vikas
> Shivappa; Marcelo Tosatti
> Subject: Re: [PATCH V2 0/5] x86: Intel Code Data Prioritizati
> From: Dave Hansen [mailto:d...@sr71.net]
> Sent: Wednesday, June 03, 2015 12:55 PM
> To: LKML; Yu, Fenghua; John Stultz; the arch/x86 maintainers
> Subject: hangs in verify_pmtmr_rate()
>
> I'm seeing boot hangs when trying to boot a 32-bit 4.1.0-rc5 kernel on some
>
> From: Wu, Fengguang
> Sent: Saturday, May 09, 2015 5:29 AM
> To: Hansen, Dave
> 0day kernel testing robot got the below dmesg and the first bad commit is
>
> https://github.com/hansendc/linux.git github-mpx
>
> commit 4d90fc49c73730c09d7afd515f9c4e08d30229bd
> [1.096425] Kernel panic - not
> Here is another warning bisected to the same commit.
>
> https://github.com/hansendc/linux.git github-mpx commit
> 4d90fc49c73730c09d7afd515f9c4e08d30229bd ("x86/xsaves: Define and use
> user_xstate_size for xstate size in signal context")
> [6.210858] WARNING: CPU: 3 PID: 168 at arch/x86/
> From: Wu, Fengguang
> Sent: Saturday, May 09, 2015 5:31 AM
> To: Hansen, Dave
> Just in case this information will help: this patch adds one more warning
> message.
>
> https://github.com/hansendc/linux.git github-mpx
>
> commit 3701f7533ba43e0aec12bf2dffd49855499fa524
> [3.058044] WARNING:
> From: Ingo Molnar [mailto:mingo.kernel@gmail.com] On Behalf Of Ingo
> Molnar
> Sent: Tuesday, May 05, 2015 10:58 AM
> To: linux-kernel@vger.kernel.org
> Cc: Andy Lutomirski; Borislav Petkov; Dave Hansen; Yu, Fenghua; H. Peter
> Anvin; Linus Torvalds; Oleg Nesterov; Thomas
> From: Dave Hansen [mailto:dave.han...@linux.intel.com]
> Sent: Tuesday, May 05, 2015 12:52 PM
> To: Ingo Molnar; linux-kernel@vger.kernel.org
> Cc: Andy Lutomirski; Borislav Petkov; Yu, Fenghua; H. Peter Anvin; Linus
> Torvalds; Oleg Nesterov; Thomas Gleixner
> Subject: Re: [
> From: Ingo Molnar [mailto:mingo.kernel@gmail.com] On Behalf Of Ingo
> Molnar
> Sent: Tuesday, May 05, 2015 10:51 AM
> To: linux-kernel@vger.kernel.org
> Cc: Andy Lutomirski; Borislav Petkov; Dave Hansen; Yu, Fenghua; H. Peter
> Anvin; Linus Torvalds; Oleg Nesterov; Thomas
> From: Hansen, Dave
> Sent: Tuesday, April 28, 2015 3:09 PM
> To: Yu, Fenghua; H. Peter Anvin; Ingo Molnar; Thomas Gleixner; Mallick, Asit
> K; Williamson, Glenn P
> Cc: linux-kernel; x86
> Subject: Re: [PATCH Bugfix v2 2/4] x86/xsaves: Define and use
> user_xstate_size for
> From: Hansen, Dave
> Sent: Wednesday, April 22, 2015 5:35 PM
> On 04/22/2015 05:06 PM, Yu, Fenghua wrote:
> > We need to copy ALL of supported xstates to user. Using xstate_bv only
> > copies partial xstates that are in non-init status.
> >
> > Xstate_bv only
> From: Hansen, Dave
> Sent: Wednesday, April 22, 2015 5:21 PM
> To: Yu, Fenghua; H. Peter Anvin; Ingo Molnar; Thomas Gleixner; Mallick, Asit
> K; Williamson, Glenn P
> Cc: linux-kernel; x86
> Subject: Re: [PATCH Bugfix v2 2/4] x86/xsaves: Define and use
> user_xstate_si
> From: Hansen, Dave
> Sent: Wednesday, April 22, 2015 12:34 PM
> To: Yu, Fenghua; H. Peter Anvin; Ingo Molnar; Thomas Gleixner; Mallick, Asit
> K; Williamson, Glenn P
> Cc: linux-kernel; x86
> Subject: Re: [PATCH Bugfix v2 2/4] x86/xsaves: Define and use
> user_xstate_si
> From: Dave Hansen [mailto:d...@sr71.net]
> Sent: Wednesday, April 22, 2015 12:33 PM
> To: Yu, Fenghua; linux-kernel@vger.kernel.org
> Cc: x...@kernel.org; t...@linutronix.de; dave.han...@linux.intel.com;
> o...@redhat.com; b...@alien8.de; r...@redhat.com; sbsid...
id...@gmail.com; l...@amacapital.net;
> mi...@redhat.com; h...@zytor.com; Yu, Fenghua
> Subject: [PATCH 02/17] x86, mpx: use new tsk_get_xsave_addr()
>
>
> From: Dave Hansen
>
> The MPX registers (bndcsr/bndcfgu/bndstatus) are not directly accessible via
> normal instructions. They esse
> From: Hansen, Dave
> Sent: Wednesday, April 22, 2015 11:45 AM
> To: Yu, Fenghua; H. Peter Anvin; Ingo Molnar; Thomas Gleixner; Mallick, Asit
> K; Williamson, Glenn P
> Cc: linux-kernel; x86
> Subject: Re: [PATCH Bugfix v2 2/4] x86/xsaves: Define and use
> user_xstate_si
> From: Thomas Gleixner [mailto:t...@linutronix.de]
> Sent: Tuesday, April 21, 2015 2:17 AM
> On Sat, 18 Apr 2015, Fenghua Yu wrote:
>
> > From: Fenghua Yu
> >
> > When enumerating xstate offsets and sizes from cpuid (eax=0x0d,
> > ecx>=2), it's possible that state m is not implemented while stat
> From: Hansen, Dave
> Sent: Thursday, March 26, 2015 3:44 PM
> On 03/26/2015 03:37 PM, Yu, Fenghua wrote:
> >> > void sighup(int sig, siginfo_t *info, void *ctxt) {
> >> > struct ucontext *uctxt = ctxt;
> >> > struct sigcontext *sctxt = (void*)&
> From: Oleg Nesterov [mailto:o...@redhat.com]
> Sent: Thursday, March 05, 2015 10:22 AM
>
> On 03/05, Oleg Nesterov wrote:
> >
>
> Does it trigger something else on your machine?
>
> Oleg.
>
> #include
> #include
> #include
> #include
>
> void sighup(int sig, siginfo_t *info, void *ctxt)
> From: Hansen, Dave
> On 03/02/2015 04:09 PM, Yu, Fenghua wrote:
> > Xsaves has been tested by QA since 3.17 with or without MPX. I'm not
> > aware of reported issues.
> >
> > But MPX is the only code to call the get_xsave_addr kernel API.
> > Though it ha
> From: Hansen, Dave
> Sent: Monday, March 02, 2015 4:00 PM
>
> Hi Fenghua,
>
> I was testing some new MPX code, and realized that MPX had stopped
> working completely. The prctl() failed to turn it on, which I tracked down
> to a
> 0 in "BNDCSR" where we expected to see an enable bit.
>
> I r
> Sent: Thursday, December 18, 2014 9:26 AM
> To: Yu, Fenghua; Thomas Gleixner; H. Peter Anvin; Ingo Molnar; Williamson,
> Glenn P
> Cc: linux-kernel; x86
> Subject: Re: [PATCH v2] X86-32: Allocate 256 bytes for pgd in PAE paging
>
> On 12/17/2014 01:47 PM, Fenghua Yu wrote:
> From: Borislav Petkov [mailto:b...@alien8.de]
> > What I did claim is that it is going to be a far more user-friendly
> > stop gap than the "boot from rescue media" option.
>
> Ok, we have it now and we can use it if needed. All is good.
Quoted comment from commit 65cef1311d5d212fd3d48a43678536
> From: Andy Lutomirski [mailto:l...@amacapital.net]
> On 05/26/2014 10:01 AM, Fenghua Yu wrote:
> > From: Fenghua Yu
> >
> > With ever growing extended state registers (xstate) on x86 processors,
> kernel
> > needs to cope with issue of growing memory space occupied by xstate.
> The xsave
> > are
> From: Ingo Molnar [mailto:mingo.kernel@gmail.com] On Behalf Of Ingo
> Molnar
> Sent: Thursday, December 05, 2013 12:55 AM
>
>
> * Fenghua Yu wrote:
>
> > From: Fenghua Yu
> >
> > Since erratum AVR31 in "Intel Atom Processor C2000 Product Family
> > Specification Update" is published, I a
> -Original Message-
> From: Prarit Bhargava [mailto:pra...@redhat.com]
>
> Second try at this ...
>
> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=64791
>
> When a cpu is downed on a system, the irqs on the cpu are assigned to
> other cpus. It is possible, however, that when
> Ingo Molnar [mailto:mingo.kernel@gmail.com] wrote:
> Friday, October 25, 2013 3:58 AM
>
> * Fenghua Yu wrote:
>
> > From: Fenghua Yu
> >
> > In reboot and crash path, when shutdown local APIC, I/O APIC is still
> active.
> > This may cause issues because external interrupts can still come
> From: Borislav Petkov [mailto:b...@alien8.de]
> Sent: Thursday, August 08, 2013 11:29 AM
> On Thu, Aug 08, 2013 at 12:02:38PM +0200, Borislav Petkov wrote:
> > On Wed, Aug 07, 2013 at 07:22:39PM -0700, H. Peter Anvin wrote:
> > > How much does this matter?
> >
> > I know what you're asking :-)
>
> From: Borislav Petkov [mailto:b...@alien8.de]
> Sent: Thursday, August 08, 2013 10:49 AM
> On Wed, Aug 07, 2013 at 11:34:01PM +0000, Yu, Fenghua wrote:
> > > This check won't work when CPU0 is hot added. So we need to find a
> > > better way to fix this.
> &
> From: Yu, Fenghua
> Sent: Wednesday, August 07, 2013 3:46 PM
>
> > From: Borislav Petkov [mailto:b...@alien8.de]
> > Sent: Wednesday, July 24, 2013 6:33 AM
> > On Tue, Jul 23, 2013 at 11:00:26PM +0200, Torsten Kaiser wrote:
> > > Extract common checks an
> From: Borislav Petkov [mailto:b...@alien8.de]
> Sent: Wednesday, July 24, 2013 6:33 AM
> On Tue, Jul 23, 2013 at 11:00:26PM +0200, Torsten Kaiser wrote:
> > Extract common checks and initialisations from load_ucode_ap() and
> > save_microcode_in_initrd_amd() to load_microcode_amd_early().
> > loa
> From: Jacob Shin [mailto:jacob.s...@amd.com]
> Add support for early microcode patch loading on AMD.
>
> Signed-off-by: Jacob Shin
> ---
> arch/x86/Kconfig | 16 +-
> arch/x86/include/asm/microcode.h |1 -
> arch/x86/include/asm/microcode_amd.h | 17 ++
>
> From: Jacob Shin [mailto:jacob.s...@amd.com]
> The following patchset adds early microcode patch loading support on
> AMD systems, on top of the framework introduced by:
> https://lkml.org/lkml/2012/12/21/193
>
Could you please change Documentation/x86/early-microcode.txt for AMD? At least
p
> From: Konrad Rzeszutek Wilk [mailto:konrad.w...@oracle.com]
>
> This can easily be triggered if a new CPU is added (via
> ACPI hotplug mechanism) and from user-space do:
>
> echo 1 > /sys/devices/system/cpu/cpu3/online
>
> (or wait for UDEV to do it) on a newly appeared CPU.
>
> The deadlock
> From: Thomas Renninger [mailto:tr...@suse.de]
> Sent: Thursday, April 11, 2013 12:32 AM
> On Wednesday, April 10, 2013 05:47:25 PM Yu, Fenghua wrote:
> > > -Original Message-
> > > From: Thomas Renninger [mailto:tr...@suse.de]
> > > Sent: Wednesday,
> -Original Message-
> From: Thomas Renninger [mailto:tr...@suse.de]
> Sent: Wednesday, April 10, 2013 12:41 AM
> Hello,
>
> On Wednesday, April 10, 2013 01:34:33 PM Tang Chen wrote:
> > On 04/05/2013 07:46 AM, Yinghai Lu wrote:
> > > Use common get_ramdisk_image() to get ramdisk start phy
> From: Shaun Ruffell [mailto:sruff...@digium.com]
> On Wed, Mar 20, 2013 at 04:32:14PM +0000, Yu, Fenghua wrote:
> > > From: Shaun Ruffell [mailto:sruff...@digium.com]
> > > On Tue, Mar 19, 2013 at 10:12:39PM +, Yu, Fenghua wrote:
> > > > > From
> From: Shaun Ruffell [mailto:sruff...@digium.com]
> On Tue, Mar 19, 2013 at 10:12:39PM +0000, Yu, Fenghua wrote:
> > > From: Tetsuo Handa [mailto:penguin-ker...@i-love.sakura.ne.jp]
> > > H. Peter Anvin wrote:
> Hi Fenghua,
>
> I ran into the same issue on a
> From: yhlu.ker...@gmail.com [mailto:yhlu.ker...@gmail.com] On Behalf Of
> Yinghai Lu
> On Tue, Mar 19, 2013 at 8:04 AM, Fenghua Yu
> wrote:
> > From: Fenghua Yu
> >
> > In 32-bit, __pa_symbol() in CONFIG_DEBUG_VIRTUAL accesses kernel data
> (e.g.
> > max_low_pfn) that haven't been setup yet in
1 - 100 of 145 matches
Mail list logo
