[tip: x86/core] x86/cpu: Comment Skylake server stepping too

2021-04-10 Thread tip-bot2 for Andrew Cooper
The following commit has been merged into the x86/core branch of tip: Commit-ID: 99cb64de36d5c9397a664808b92943e35bdce25e Gitweb: https://git.kernel.org/tip/99cb64de36d5c9397a664808b92943e35bdce25e Author:Andrew Cooper AuthorDate:Fri, 09 Apr 2021 13:10:27 +01:00 Committer

[PATCH] x86/cpu: Comment Skylake server stepping too

2021-04-09 Thread Andrew Cooper
Further to commit 53375a5a218e ("x86/cpu: Resort and comment Intel models"), CascadeLake and CooperLake are steppings of Skylake, and make up the 1st to 3rd generation "Xeon Scalable Processor" line. Signed-off-by: Andrew Cooper --- CC: Peter Zijlstra CC: Tony Luck CC

Re: Why does glibc use AVX-512?

2021-03-26 Thread Andrew Cooper
On 26/03/2021 19:47, Andy Lutomirski wrote: > On Fri, Mar 26, 2021 at 12:34 PM Florian Weimer wrote: >> * Andy Lutomirski: >> > AVX-512 cleared, and programs need to explicitly request enablement. > This would allow programs to opt into not saving/restoring across > signals or to

Re: [RFC PATCH] x86/retpolines: Prevent speculation after RET

2021-02-19 Thread Andrew Cooper
On 19/02/2021 08:15, Peter Zijlstra wrote: > On Thu, Feb 18, 2021 at 08:11:38PM +0100, Borislav Petkov wrote: >> On Thu, Feb 18, 2021 at 08:02:31PM +0100, Peter Zijlstra wrote: >>> On Thu, Feb 18, 2021 at 07:46:39PM +0100, Borislav Petkov wrote: Both vendors speculate after a near RET in some

Re: [PATCH 6/7] xen/evtch: use smp barriers for user event ring

2021-02-08 Thread Andrew Cooper
On 08/02/2021 10:36, Jan Beulich wrote: > On 08.02.2021 11:23, Andrew Cooper wrote: >> On 08/02/2021 09:50, Jan Beulich wrote: >>> On 08.02.2021 10:44, Andrew Cooper wrote: >>>> On 06/02/2021 10:49, Juergen Gross wrote: >>>>> The ring buffer for use

Re: [PATCH 6/7] xen/evtch: use smp barriers for user event ring

2021-02-08 Thread Andrew Cooper
On 08/02/2021 10:25, Jürgen Groß wrote: > On 08.02.21 11:23, Andrew Cooper wrote: >> On 08/02/2021 09:50, Jan Beulich wrote: >>> On 08.02.2021 10:44, Andrew Cooper wrote: >>>> On 06/02/2021 10:49, Juergen Gross wrote: >>>>> The ring buffer for use

Re: [PATCH 6/7] xen/evtch: use smp barriers for user event ring

2021-02-08 Thread Andrew Cooper
On 08/02/2021 09:50, Jan Beulich wrote: > On 08.02.2021 10:44, Andrew Cooper wrote: >> On 06/02/2021 10:49, Juergen Gross wrote: >>> The ring buffer for user events is used in the local system only, so >>> smp barriers are fine for ensuring consistency. >>

Re: [PATCH 6/7] xen/evtch: use smp barriers for user event ring

2021-02-08 Thread Andrew Cooper
On 06/02/2021 10:49, Juergen Gross wrote: > The ring buffer for user events is used in the local system only, so > smp barriers are fine for ensuring consistency. > > Reported-by: Andrew Cooper > Signed-off-by: Juergen Gross These need to be virt_* to not break in UP bui

Re: [RFC][PATCH 2/2] x86: add extra serialization for non-serializing MSRs

2021-02-05 Thread Andrew Cooper
On 05/02/2021 10:02, Peter Zijlstra wrote: > On Thu, Feb 04, 2021 at 04:11:12PM -0800, Andy Lutomirski wrote: >> I'm wondering if a more mild violation is possible: >> >> Initialize *addr = 0. >> >> mov $1, (addr) >> wrmsr >> >> remote cpu's IDT vector: >> >> mov (addr), %rax >> %rax == 0! >> >>

Re: [RFC][PATCH 2/2] x86: add extra serialization for non-serializing MSRs

2021-02-04 Thread Andrew Cooper
On 05/03/2020 17:47, Dave Hansen wrote: > Jan Kiszka reported that the x2apic_wrmsr_fence() function uses a > plain "mfence" while the Intel SDM (10.12.3 MSR Access in x2APIC > Mode) calls for "mfence;lfence". > > Short summary: we have special MSRs that have weaker ordering > than all the rest.

Re: [RFC 03/20] mm/mprotect: do not flush on permission promotion

2021-02-01 Thread Andrew Cooper
On 01/02/2021 05:58, Nadav Amit wrote: >> On Jan 31, 2021, at 4:10 AM, Andrew Cooper wrote: >> >> On 31/01/2021 01:07, Andy Lutomirski wrote: >>> Adding Andrew Cooper, who has a distressingly extensive understanding >>> of the x86 PTE magic. >> Pretty s

Re: [RFC 03/20] mm/mprotect: do not flush on permission promotion

2021-01-31 Thread Andrew Cooper
On 31/01/2021 01:07, Andy Lutomirski wrote: > Adding Andrew Cooper, who has a distressingly extensive understanding > of the x86 PTE magic. Pretty sure it is all learning things the hard way... > On Sat, Jan 30, 2021 at 4:16 PM Nadav Amit wrote: >> diff --git a/mm/mprotect.c

Re: [RFC 03/20] mm/mprotect: do not flush on permission promotion

2021-01-31 Thread Andrew Cooper
On 31/01/2021 02:59, Andy Lutomirski wrote: diff --git a/arch/x86/include/asm/tlbflush.h b/arch/x86/include/asm/tlbflush.h index 8c87a2e0b660..a617dc0a9b06 100644 --- a/arch/x86/include/asm/tlbflush.h +++ b/arch/x86/include/asm/tlbflush.h @@ -255,6 +255,50 @@ static

Re: [PATCH] x86/debug: 'Fix' ptrace dr6 output

2021-01-28 Thread Andrew Cooper
On 28/01/2021 18:20, Peter Zijlstra wrote: > --- a/arch/x86/kernel/hw_breakpoint.c > +++ b/arch/x86/kernel/hw_breakpoint.c > @@ -496,9 +496,32 @@ static int hw_breakpoint_handler(struct > dr6_p = (unsigned long *)ERR_PTR(args->err); > dr6 = *dr6_p; > > - /* If it's a single step,

Re: [PATCH v2] x86/xen: avoid warning in Xen pv guest with CONFIG_AMD_MEM_ENCRYPT enabled

2021-01-27 Thread Andrew Cooper
On 27/01/2021 13:59, Jürgen Groß wrote: > On 27.01.21 12:23, Andrew Cooper wrote: >> On 27/01/2021 10:26, Jürgen Groß wrote: >>> On 27.01.21 10:43, Andrew Cooper wrote: >>>> On 27/01/2021 09:38, Juergen Gross wrote: >>>>> diff --git a/arch/x86/xen/enlig

Re: [PATCH v2] x86/xen: avoid warning in Xen pv guest with CONFIG_AMD_MEM_ENCRYPT enabled

2021-01-27 Thread Andrew Cooper
On 27/01/2021 10:26, Jürgen Groß wrote: > On 27.01.21 10:43, Andrew Cooper wrote: >> On 27/01/2021 09:38, Juergen Gross wrote: >>> diff --git a/arch/x86/xen/enlighten_pv.c b/arch/x86/xen/enlighten_pv.c >>> index 4409306364dc..ca5ac10fcbf7 100644 >>> --- a/arch/x

Re: [PATCH v2] x86/xen: avoid warning in Xen pv guest with CONFIG_AMD_MEM_ENCRYPT enabled

2021-01-27 Thread Andrew Cooper
On 27/01/2021 09:38, Juergen Gross wrote: > diff --git a/arch/x86/xen/enlighten_pv.c b/arch/x86/xen/enlighten_pv.c > index 4409306364dc..ca5ac10fcbf7 100644 > --- a/arch/x86/xen/enlighten_pv.c > +++ b/arch/x86/xen/enlighten_pv.c > @@ -583,6 +583,12 @@ DEFINE_IDTENTRY_RAW(xenpv_exc_debug) >

Re: [PATCH] x86/xen: avoid warning in Xen pv guest with CONFIG_AMD_MEM_ENCRYPT enabled

2021-01-25 Thread Andrew Cooper
On 25/01/2021 14:00, Juergen Gross wrote: > diff --git a/arch/x86/xen/enlighten_pv.c b/arch/x86/xen/enlighten_pv.c > index 4409306364dc..82948251f57b 100644 > --- a/arch/x86/xen/enlighten_pv.c > +++ b/arch/x86/xen/enlighten_pv.c > @@ -583,6 +583,14 @@ DEFINE_IDTENTRY_RAW(xenpv_exc_debug) >

Re: [PATCH 17/21] x86/acpi: Convert indirect jump to retpoline

2021-01-14 Thread Andrew Cooper
On 14/01/2021 23:47, Josh Poimboeuf wrote: > On Thu, Jan 14, 2021 at 10:59:39PM +0000, Andrew Cooper wrote: >> On 14/01/2021 19:40, Josh Poimboeuf wrote: >>> It's kernel policy to not have (unannotated) indirect jumps because of >>> Spectre v2. This one's probably har

Re: [PATCH 17/21] x86/acpi: Convert indirect jump to retpoline

2021-01-14 Thread Andrew Cooper
On 14/01/2021 19:40, Josh Poimboeuf wrote: > It's kernel policy to not have (unannotated) indirect jumps because of > Spectre v2. This one's probably harmless, but better safe than sorry. > Convert it to a retpoline. > > Cc: "Rafael J. Wysocki" > Cc: Len Brown > Cc: Pavel Machek >

Re: [PATCH v2] xen/privcmd: allow fetching resource sizes

2021-01-12 Thread Andrew Cooper
Pau Monné >> Cc: sta...@vger.kernel.org # >= 4.18 > > Reviewed-by: Juergen Gross Tested-by: Andrew Cooper

Re: [PATCH] xen/privcmd: allow fetching resource sizes

2021-01-11 Thread Andrew Cooper
On 11/01/2021 22:09, boris.ostrov...@oracle.com wrote: > On 1/11/21 10:29 AM, Roger Pau Monne wrote: >> >> +xdata.domid = kdata.dom; >> +xdata.type = kdata.type; >> +xdata.id = kdata.id; >> + >> +if (!kdata.addr && !kdata.num) { > > I think we should not allow only one of them to

Re: [PATCH v2] xen/xenbus: make xs_talkv() interruptible

2020-12-17 Thread Andrew Cooper
On 16/12/2020 08:21, Jürgen Groß wrote: > On 15.12.20 21:59, Andrew Cooper wrote: >> On 15/12/2020 11:10, Juergen Gross wrote: >>> In case a process waits for any Xenstore action in the xenbus driver >>> it should be interruptible by signals. >>> >>>

Re: [PATCH v2] xen/xenbus: make xs_talkv() interruptible

2020-12-15 Thread Andrew Cooper
On 15/12/2020 11:10, Juergen Gross wrote: > In case a process waits for any Xenstore action in the xenbus driver > it should be interruptible by signals. > > Signed-off-by: Juergen Gross > --- > V2: > - don't special case SIGKILL as libxenstore is handling -EINTR fine > --- >

Re: [patch 27/30] xen/events: Only force affinity mask for percpu interrupts

2020-12-11 Thread Andrew Cooper
On 11/12/2020 21:27, Thomas Gleixner wrote: > On Fri, Dec 11 2020 at 09:29, boris ostrovsky wrote: > >> On 12/11/20 7:37 AM, Thomas Gleixner wrote: >>> On Fri, Dec 11 2020 at 13:10, Jürgen Groß wrote: On 11.12.20 00:20, boris.ostrov...@oracle.com wrote: > On 12/10/20 2:26 PM, Thomas

Re: [PATCH] x86/cpu: correct values for GDT_ENTRY_INIT

2020-11-26 Thread Andrew Cooper
On 26/11/2020 19:15, Andy Lutomirski wrote: > On Thu, Nov 26, 2020 at 11:07 AM Lukas Bulwahn > wrote: >> On Thu, Nov 26, 2020 at 6:16 PM Andrew Cooper >> wrote: >>> On 26/11/2020 11:54, Lukas Bulwahn wrote: >>>> Commit 1e5de18278e6 ("x86:

Re: [PATCH] x86/cpu: correct values for GDT_ENTRY_INIT

2020-11-26 Thread Andrew Cooper
On 26/11/2020 11:54, Lukas Bulwahn wrote: > Commit 1e5de18278e6 ("x86: Introduce GDT_ENTRY_INIT()") unintentionally > transformed a few 0x values to 0xf (note: five times "f" instead of > four) as part of the refactoring. The transformation in that change is correct. Segment bases are 20

Re: WARNING: can't access registers at asm_common_interrupt

2020-11-11 Thread Andrew Cooper
On 11/11/2020 20:15, Josh Poimboeuf wrote: > On Wed, Nov 11, 2020 at 09:07:30PM +0100, Peter Zijlstra wrote: >> On Wed, Nov 11, 2020 at 01:59:00PM -0600, Josh Poimboeuf wrote: >>> On Wed, Nov 11, 2020 at 08:42:06PM +0100, Peter Zijlstra wrote: > Would objtool have an easier time coping if this

Re: WARNING: can't access registers at asm_common_interrupt

2020-11-11 Thread Andrew Cooper
On 11/11/2020 18:13, Josh Poimboeuf wrote: > On Wed, Nov 11, 2020 at 06:47:36PM +0100, Peter Zijlstra wrote: >> This is PARAVIRT_XXL only, which is a Xen special. My preference, as >> always, is to kill it... Sadly the Xen people have a different opinion. > That would be s nice... then we

Re: [PATCH 2/2] xen: Kconfig: nest Xen guest options

2020-10-15 Thread Andrew Cooper
On 15/10/2020 13:37, boris.ostrov...@oracle.com wrote: > On 10/14/20 1:53 PM, Jason Andryuk wrote: >> +config XEN_512GB >> +bool "Limit Xen pv-domain memory to 512GB" >> +depends on XEN_PV && X86_64 > > Why is X86_64 needed here? >512G support was implemented using a direct-mapped P2M,

Re: [SUSPECTED SPAM][PATCH 0/2] Remove Xen PVH dependency on PCI

2020-10-14 Thread Andrew Cooper
On 14/10/2020 18:53, Jason Andryuk wrote: > A Xen PVH domain doesn't have a PCI bus or devices, [*] Yet. > so it doesn't need PCI support built in. Untangling the dependences is a good thing, but eventually we plan to put an optional PCI bus back in, e.g. for SRIOV usecases. ~Andrew

Re: How should we handle illegal task FPU state?

2020-10-01 Thread Andrew Cooper
On 01/10/2020 21:58, Sean Christopherson wrote: > On Thu, Oct 01, 2020 at 01:32:04PM -0700, Yu, Yu-cheng wrote: >> On 10/1/2020 10:43 AM, Andy Lutomirski wrote: >>> The question is: what do we do about it? We have two basic choices, I >>> think. >>> >>> a) Decide that the saved FPU for a task

Re: How should we handle illegal task FPU state?

2020-10-01 Thread Andrew Cooper
On 01/10/2020 18:43, Andy Lutomirski wrote: > Our current handling of illegal task FPU state is currently rather > simplistic. We basically ignore the issue with this extable code: > > /* > * Handler for when we fail to restore a task's FPU state. We should never > get > * here because the

Re: [PATCH v38 21/24] x86/vdso: Implement a vDSO for Intel SGX enclave call

2020-09-29 Thread Andrew Cooper
On 29/09/2020 15:10, Dave Hansen wrote: > On 9/28/20 4:38 PM, Andrew Cooper wrote: >>>> CET=y, BUG_SPECTRE_V2=y: does not exist >>>> CET=n, BUG_SPECTRE_V2=y: vulnerable, use retpoline >>>> CET=y, BUG_SPECTRE_V2=n: no retpoline, not vulnerable >

Re: [PATCH v38 21/24] x86/vdso: Implement a vDSO for Intel SGX enclave call

2020-09-28 Thread Andrew Cooper
On 28/09/2020 21:42, Jarkko Sakkinen wrote: > On Mon, Sep 28, 2020 at 05:44:35PM +0100, Andrew Cooper wrote: >> On 28/09/2020 01:58, Jarkko Sakkinen wrote: >>> On Fri, Sep 25, 2020 at 07:23:59PM +0100, Andrew Cooper wrote: >>>> On 15/09/2020 12:28, Jarkko Sakkinen

Re: [PATCH v38 21/24] x86/vdso: Implement a vDSO for Intel SGX enclave call

2020-09-28 Thread Andrew Cooper
On 28/09/2020 23:41, Andy Lutomirski wrote: > On Mon, Sep 28, 2020 at 3:18 PM Dave Hansen wrote: >> On 9/28/20 3:06 PM, H.J. Lu wrote: I'm open to do either solution. My thinking was to initially do things vsgx.S local (i.e. consider ALTERNATIVE post upstreaming) and use the above

Re: [PATCH v38 21/24] x86/vdso: Implement a vDSO for Intel SGX enclave call

2020-09-28 Thread Andrew Cooper
On 28/09/2020 01:58, Jarkko Sakkinen wrote: > On Fri, Sep 25, 2020 at 07:23:59PM +0100, Andrew Cooper wrote: >> On 15/09/2020 12:28, Jarkko Sakkinen wrote: >>> diff --git a/arch/x86/entry/vdso/vsgx_enter_enclave.S >>> b/arch/x86/entry/vdso/vsgx_enter_enclave.S >>

Re: [PATCH v38 21/24] x86/vdso: Implement a vDSO for Intel SGX enclave call

2020-09-25 Thread Andrew Cooper
On 15/09/2020 12:28, Jarkko Sakkinen wrote: > diff --git a/arch/x86/entry/vdso/vsgx_enter_enclave.S > b/arch/x86/entry/vdso/vsgx_enter_enclave.S > new file mode 100644 > index ..adbd59d41517 > --- /dev/null > +++ b/arch/x86/entry/vdso/vsgx_enter_enclave.S > @@ -0,0 +1,157 @@ >

Re: [PATCH v3] x86/uaccess: Use pointer masking to limit uaccess speculation

2020-09-14 Thread Andrew Cooper
On 14/09/2020 20:27, Josh Poimboeuf wrote: > On Mon, Sep 14, 2020 at 09:21:56PM +0200, Borislav Petkov wrote: >> On Mon, Sep 14, 2020 at 11:48:55AM -0700, Dan Williams wrote: Err, stupid question: can this macro then be folded into access_ok() so that you don't have to touch so many

Re: [PATCH 01/13] x86/entry: Fix AC assertion

2020-09-02 Thread Andrew Cooper
On 02/09/2020 16:58, Brian Gerst wrote: > On Wed, Sep 2, 2020 at 9:38 AM Peter Zijlstra wrote: >> From: Peter Zijlstra >> >> The WARN added in commit 3c73b81a9164 ("x86/entry, selftests: Further >> improve user entry sanity checks") unconditionally triggers on my IVB >> machine because it does

[PATCH] docs/ia64: Drop obsolete Xen documentation

2020-08-27 Thread Andrew Cooper
While the xensource.com URLs referenced still exist, neither the Xen or Linux 2.6.18 fork have been touched since 2009, 11 years ago. Other URLs are dead. IA64 support was removed in Xen 4.2, in 2012. Relegate this piece of documentation to source history. Signed-off-by: Andrew Cooper --- CC

Re: TDX #VE in SYSCALL gap (was: [RFD] x86: Curing the exception and syscall trainwreck in hardware)

2020-08-25 Thread Andrew Cooper
On 25/08/2020 18:35, Luck, Tony wrote: >>> Or malicious hypervisor action, and that's a problem. >>> >>> Suppose the hypervisor remaps a GPA used in the SYSCALL gap (e.g. the >>> actual SYSCALL text or the first memory it accesses -- I don't have a >>> TDX spec so I don't know the details). > Is

Re: [PATCH] x86/entry: Fix AC assertion

2020-08-24 Thread Andrew Cooper
On 24/08/2020 16:21, pet...@infradead.org wrote: > On Mon, Aug 24, 2020 at 03:22:06PM +0100, Andrew Cooper wrote: >> On 24/08/2020 11:14, pet...@infradead.org wrote: >>> The WARN added in commit 3c73b81a9164 ("x86/entry, selftests: Further >>> improve user entry

Re: [PATCH] x86/entry: Fix AC assertion

2020-08-24 Thread Andrew Cooper
On 24/08/2020 11:14, pet...@infradead.org wrote: > The WARN added in commit 3c73b81a9164 ("x86/entry, selftests: Further > improve user entry sanity checks") unconditionally triggers on my IVB > machine because it does not support SMAP. > > For !SMAP hardware we patch out CLAC/STAC instructions

Re: [PATCH v2 5/8] x86/debug: Simplify #DB signal code

2020-08-24 Thread Andrew Cooper
On 24/08/2020 12:05, pet...@infradead.org wrote: > On Sun, Aug 23, 2020 at 04:09:42PM -0700, Andy Lutomirski wrote: >> On Fri, Aug 21, 2020 at 3:21 AM Peter Zijlstra wrote: >>> Get rid of the two variables, avoid computing si_code when not needed >>> and be consistent about which dr6 value is

Re: [PATCH v3 4/4] xen: add helpers to allocate unpopulated memory

2020-07-28 Thread Andrew Cooper
On 28/07/2020 17:59, Roger Pau Monné wrote: > On Tue, Jul 28, 2020 at 05:48:23PM +0100, Julien Grall wrote: >> Hi, >> >> On 27/07/2020 10:13, Roger Pau Monne wrote: >>> To be used in order to create foreign mappings. This is based on the >>> ZONE_DEVICE facility which is used by persistent memory

Re: [PATCH 3/3] memory: introduce an option to force onlining of hotplug memory

2020-07-23 Thread Andrew Cooper
On 23/07/2020 16:10, Jürgen Groß wrote: > On 23.07.20 15:59, Roger Pau Monné wrote: >> On Thu, Jul 23, 2020 at 03:22:49PM +0200, David Hildenbrand wrote: >>> On 23.07.20 14:23, Roger Pau Monné wrote: On Thu, Jul 23, 2020 at 01:37:03PM +0200, David Hildenbrand wrote: > On 23.07.20 10:45,

Re: [PATCH entry v2 5/6] x86/ldt: Disable 16-bit segments on Xen PV

2020-07-03 Thread Andrew Cooper
On 03/07/2020 18:02, Andy Lutomirski wrote: > Xen PV doesn't implement ESPFIX64, so they don't work right. Disable > them. Also print a warning the first time anyone tries to use a > 16-bit segment on a Xen PV guest that would otherwise allow it > to help people diagnose this change in behavior.

Re: FSGSBASE seems to be busted on Xen PV

2020-07-03 Thread Andrew Cooper
On 03/07/2020 18:10, Andy Lutomirski wrote: > Hi Xen folks- > > I did some testing of the upcoming Linux FSGSBASE support on Xen PV, > and I found what appears to be some significant bugs in the Xen > context switching code. These bugs are causing Linux selftest > failures, and they could easily

Re: [PATCH v2 1/4] x86/xen: remove 32-bit Xen PV guest support

2020-07-02 Thread Andrew Cooper
On 02/07/2020 23:59, Boris Ostrovsky wrote: > On 7/1/20 7:06 AM, Juergen Gross wrote: >> >> -#ifdef CONFIG_X86_PAE >> -static void xen_set_pte_atomic(pte_t *ptep, pte_t pte) >> -{ >> -trace_xen_mmu_set_pte_atomic(ptep, pte); >> -__xen_set_pte(ptep, pte); > > Probably not for this series

Re: [PATCH fsgsbase v2 4/4] x86/fsgsbase: Fix Xen PV support

2020-06-29 Thread Andrew Cooper
On 29/06/2020 06:17, Jürgen Groß wrote: > On 26.06.20 19:24, Andy Lutomirski wrote: >> On Xen PV, SWAPGS doesn't work.  Teach __rdfsbase_inactive() and >> __wrgsbase_inactive() to use rdmsrl()/wrmsrl() on Xen PV.  The Xen >> pvop code will understand this and issue the correct hypercalls. >> >>

Re: Should SEV-ES #VC use IST? (Re: [PATCH] Allow RDTSC and RDTSCP from userspace)

2020-06-23 Thread Andrew Cooper
On 23/06/2020 19:26, Andy Lutomirski wrote: > On Tue, Jun 23, 2020 at 8:23 AM Andrew Cooper > wrote: >> On 23/06/2020 14:03, Peter Zijlstra wrote: >>> On Tue, Jun 23, 2020 at 02:12:37PM +0200, Joerg Roedel wrote: >>>> On Tue, Jun 23, 2020 at 01:50:14PM +0200, P

Re: Should SEV-ES #VC use IST? (Re: [PATCH] Allow RDTSC and RDTSCP from userspace)

2020-06-23 Thread Andrew Cooper
On 23/06/2020 16:23, Peter Zijlstra wrote: > On Tue, Jun 23, 2020 at 04:59:14PM +0200, Joerg Roedel wrote: >> On Tue, Jun 23, 2020 at 04:53:44PM +0200, Peter Zijlstra wrote: >>> +noinstr void idtentry_validate_ist(struct pt_regs *regs) >>> +{ >>> + if ((regs->sp & ~(EXCEPTION_STKSZ-1)) == >>> +

Re: Should SEV-ES #VC use IST? (Re: [PATCH] Allow RDTSC and RDTSCP from userspace)

2020-06-23 Thread Andrew Cooper
On 23/06/2020 16:16, Peter Zijlstra wrote: > On Tue, Jun 23, 2020 at 04:49:40PM +0200, Joerg Roedel wrote: >>> We're talking about the 3rd case where the only reason things 'work' is >>> because we'll have to panic(): >>> >>> - #MC >> Okay, #MC is special and can only be handled on a best-effort

Re: Should SEV-ES #VC use IST? (Re: [PATCH] Allow RDTSC and RDTSCP from userspace)

2020-06-23 Thread Andrew Cooper
On 23/06/2020 14:03, Peter Zijlstra wrote: > On Tue, Jun 23, 2020 at 02:12:37PM +0200, Joerg Roedel wrote: >> On Tue, Jun 23, 2020 at 01:50:14PM +0200, Peter Zijlstra wrote: >>> If SNP is the sole reason #VC needs to be IST, then I'd strongly urge >>> you to only make it IST if/when you try and

Re: Should SEV-ES #VC use IST? (Re: [PATCH] Allow RDTSC and RDTSCP from userspace)

2020-06-23 Thread Andrew Cooper
On 23/06/2020 13:47, Peter Zijlstra wrote: > On Tue, Jun 23, 2020 at 12:51:03PM +0100, Andrew Cooper wrote: > >> There are cases which are definitely non-recoverable. >> >> For both ES and SNP, a malicious hypervisor can mess with the guest >> physmap to make the t

Re: Should SEV-ES #VC use IST? (Re: [PATCH] Allow RDTSC and RDTSCP from userspace)

2020-06-23 Thread Andrew Cooper
On 23/06/2020 12:30, Joerg Roedel wrote: > On Tue, Jun 23, 2020 at 01:07:06PM +0200, Peter Zijlstra wrote: >> On Tue, Apr 28, 2020 at 09:55:12AM +0200, Joerg Roedel wrote: >> So what happens if this #VC triggers on the first access to the #VC >> stack, because the malicious host has craftily

Re: 5.7.0 / BUG: kernel NULL pointer dereference / setup_cpu_watcher

2020-06-05 Thread Andrew Cooper
On 05/06/2020 09:36, Christian Kujau wrote: > Hi, > > I'm running a small Xen PVH domain and upgrading from vanilla 5.6.0 to > > > Note: that "Xen Platform PCI: unrecognised magic value" on the top appears > in 5.6 kernels as well, but no ill effects so far. > >

Re: [patch V9 00/39] x86/entry: Rework leftovers (was part V)

2020-06-03 Thread Andrew Cooper
On 22/05/2020 22:17, Peter Zijlstra wrote: > On Fri, May 22, 2020 at 08:20:15AM +0100, Andrew Cooper wrote: >> Apologies for opening a related can of worms. >> >> The new debug_enter() has propagated a pre-existing issue forward, >> ultimately caused by bad advice in the

Re: [PATCH 02/14] x86/hw_breakpoint: Prevent data breakpoints on direct GDT

2020-05-30 Thread Andrew Cooper
On 29/05/2020 22:27, Peter Zijlstra wrote: > From: Lai Jiangshan > > A data breakpoint on the GDT is terrifying and should be avoided. > The GDT on CPU entry area is already protected. The direct GDT > should be also protected, although it is seldom used and only > used for short time. While I

Re: [PATCH 1/6] x86/entry: Introduce local_db_{save,restore}()

2020-05-28 Thread Andrew Cooper
On 28/05/2020 22:15, Peter Zijlstra wrote: > On Thu, May 28, 2020 at 09:52:30PM +0100, Andrew Cooper wrote: >> On 28/05/2020 21:19, Peter Zijlstra wrote: >>> --- a/arch/x86/include/asm/debugreg.h >>> +++ b/arch/x86/include/asm/debugreg.h >>> @@

Re: [PATCH 1/6] x86/entry: Introduce local_db_{save,restore}()

2020-05-28 Thread Andrew Cooper
On 28/05/2020 21:19, Peter Zijlstra wrote: > --- a/arch/x86/include/asm/debugreg.h > +++ b/arch/x86/include/asm/debugreg.h > @@ -113,6 +113,31 @@ static inline void debug_stack_usage_inc > static inline void debug_stack_usage_dec(void) { } > #endif /* X86_64 */ > > +static __always_inline void

Re: Possibility of conflicting memory types in lazier TLB mode?

2020-05-27 Thread Andrew Cooper
On 27/05/2020 01:09, Andy Lutomirski wrote: > [cc Andrew Cooper and Dave Hansen] > > On Fri, May 15, 2020 at 7:35 PM Nicholas Piggin wrote: >> Excerpts from Rik van Riel's message of May 16, 2020 5:24 am: >>> On Fri, 2020-05-15 at 16:50 +1000, Nicholas Piggin wr

Re: [PATCH v10 01/26] Documentation/x86: Add CET description

2020-05-22 Thread Andrew Cooper
On 22/05/2020 17:49, Peter Zijlstra wrote: > On Sat, May 16, 2020 at 03:09:22PM +0100, Andrew Cooper wrote: > >> Sadly, the same is not true for kernel shadow stacks. >> >> SSP is 0 after SYSCALL, SYSENTER and CLRSSBSY, and you've got to be >> careful to re-establish

Re: [patch V9 00/39] x86/entry: Rework leftovers (was part V)

2020-05-22 Thread Andrew Cooper
On 21/05/2020 21:05, Thomas Gleixner wrote: > Folks! > > This is V9 of the rework series. V7 and V8 were never posted but I used the > version numbers for tags while fixing up 0day complaints. The last posted > version was V6 which can be found here: > >

Re: [patch V6 10/37] x86/entry: Switch XEN/PV hypercall entry to IDTENTRY

2020-05-20 Thread Andrew Cooper
On 20/05/2020 09:06, Jürgen Groß wrote: > On 19.05.20 21:44, Andy Lutomirski wrote: >> On Tue, May 19, 2020 at 11:58 AM Thomas Gleixner >> wrote: >>> >>> Andy Lutomirski writes: B: Turn this thing around.  Specifically, in the one and only case we care about, we know pretty much

Re: [PATCH v10 01/26] Documentation/x86: Add CET description

2020-05-16 Thread Andrew Cooper
On 16/05/2020 03:37, H.J. Lu wrote: > On Fri, May 15, 2020 at 5:13 PM Andrew Cooper > wrote: >> Finally seeing as the question was asked but not answered, it is >> actually quite easy to figure out whether shadow stacks are enabled in >> the current thread. &g

Re: [PATCH v10 01/26] Documentation/x86: Add CET description

2020-05-15 Thread Andrew Cooper
On 15/05/2020 23:43, Dave Hansen wrote: > On 5/15/20 2:33 PM, Yu-cheng Yu wrote: >> On Fri, 2020-05-15 at 11:39 -0700, Dave Hansen wrote: >>> On 5/12/20 4:20 PM, Yu-cheng Yu wrote: >>> Can a binary compiled with CET run without CET? >> Yes, but a few details: >> >> - The shadow stack is

Re: Should SEV-ES #VC use IST? (Re: [PATCH] Allow RDTSC and RDTSCP from userspace)

2020-04-28 Thread Andrew Cooper
On 28/04/2020 08:55, Joerg Roedel wrote: > On Mon, Apr 27, 2020 at 10:37:41AM -0700, Andy Lutomirski wrote: >> I have a somewhat serious question: should we use IST for #VC at all? >> As I understand it, Rome and Naples make it mandatory for hypervisors >> to intercept #DB, which means that, due

Re: [Xen-devel] [PATCH] ARM: xen: unexport HYPERVISOR_platform_op function

2019-09-06 Thread Andrew Cooper
On 06/09/2019 17:00, Arnd Bergmann wrote: > On Fri, Sep 6, 2019 at 5:55 PM Andrew Cooper > wrote: >> On 06/09/2019 16:39, Arnd Bergmann wrote: >>> HYPERVISOR_platform_op() is an inline function and should not >>> be exported. Since commit 15bfc2348d54 (

Re: [Xen-devel] [PATCH] ARM: xen: unexport HYPERVISOR_platform_op function

2019-09-06 Thread Andrew Cooper
On 06/09/2019 16:39, Arnd Bergmann wrote: > HYPERVISOR_platform_op() is an inline function and should not > be exported. Since commit 15bfc2348d54 ("modpost: check for > static EXPORT_SYMBOL* functions"), this causes a warning: > > WARNING: "HYPERVISOR_platform_op" [vmlinux] is a static

Re: [Xen-devel] [PATCH 09/11] swiotlb-xen: simplify cache maintainance

2019-09-06 Thread Andrew Cooper
On 06/09/2019 15:01, Christoph Hellwig wrote: > On Fri, Sep 06, 2019 at 09:52:12AM -0400, Boris Ostrovsky wrote: >> We need nop definitions of these two for x86. >> >> Everything builds now but that's probably because the calls are under >> 'if (!dev_is_dma_coherent(dev))' which is always false so

Re: [Xen-devel] [PATCH -tip 0/2] x86: Prohibit kprobes on XEN_EMULATE_PREFIX

2019-09-05 Thread Andrew Cooper
On 05/09/2019 14:09, Masami Hiramatsu wrote: > On Thu, 5 Sep 2019 20:32:24 +0900 > Masami Hiramatsu wrote: > >> On Thu, 5 Sep 2019 08:54:17 +0100 >> Andrew Cooper wrote: >> >>> On 05/09/2019 02:49, Masami Hiramatsu wrote: >>>> On Wed, 4 S

Re: [Xen-devel] [PATCH -tip 0/2] x86: Prohibit kprobes on XEN_EMULATE_PREFIX

2019-09-05 Thread Andrew Cooper
On 05/09/2019 10:26, Peter Zijlstra wrote: > On Thu, Sep 05, 2019 at 09:53:32AM +0100, Andrew Cooper wrote: >> On 05/09/2019 09:26, Peter Zijlstra wrote: >>> On Thu, Sep 05, 2019 at 08:54:17AM +0100, Andrew Cooper wrote: >>> >>>> I don't know if you've spotte

Re: [Xen-devel] [PATCH -tip 0/2] x86: Prohibit kprobes on XEN_EMULATE_PREFIX

2019-09-05 Thread Andrew Cooper
On 05/09/2019 09:26, Peter Zijlstra wrote: > On Thu, Sep 05, 2019 at 08:54:17AM +0100, Andrew Cooper wrote: > >> I don't know if you've spotted, but the prefix is a ud2a instruction >> followed by 'xen' in ascii. >> >> The KVM version was added in c/s 6c86eedc20

Re: [Xen-devel] [PATCH -tip 0/2] x86: Prohibit kprobes on XEN_EMULATE_PREFIX

2019-09-05 Thread Andrew Cooper
On 05/09/2019 02:49, Masami Hiramatsu wrote: > On Wed, 4 Sep 2019 12:54:55 +0100 > Andrew Cooper wrote: > >> On 04/09/2019 12:45, Masami Hiramatsu wrote: >>> Hi, >>> >>> These patches allow x86 instruction decoder to decode >>> xen-cpuid whi

Re: [Xen-devel] [PATCH -tip 0/2] x86: Prohibit kprobes on XEN_EMULATE_PREFIX

2019-09-04 Thread Andrew Cooper
On 04/09/2019 12:45, Masami Hiramatsu wrote: > Hi, > > These patches allow x86 instruction decoder to decode > xen-cpuid which has XEN_EMULATE_PREFIX, and prohibit > kprobes to probe on it. > > Josh reported that the objtool can not decode such special > prefixed instructions, and I found that we

[tip:x86/apic] x86/paravirt: Drop {read,write}_cr8() hooks

2019-07-22 Thread tip-bot for Andrew Cooper
Commit-ID: 83b584d9c6a1494170abd3a8b24f41939b23d625 Gitweb: https://git.kernel.org/tip/83b584d9c6a1494170abd3a8b24f41939b23d625 Author: Andrew Cooper AuthorDate: Mon, 15 Jul 2019 16:16:41 +0100 Committer: Thomas Gleixner CommitDate: Mon, 22 Jul 2019 10:12:33 +0200 x86/paravirt: Drop

Re: [PATCH v2] x86/paravirt: Drop {read,write}_cr8() hooks

2019-07-19 Thread Andrew Cooper
On 16/07/2019 01:05, Andy Lutomirski wrote: > On Mon, Jul 15, 2019 at 4:30 PM Andrew Cooper > wrote: >> On 15/07/2019 19:17, Nadav Amit wrote: >>>> On Jul 15, 2019, at 8:16 AM, Andrew Cooper >>>> wrote: >>>> >>>> There is a lot of inf

Re: [Xen-devel] [PATCH 1/2] xen/gntdev: replace global limit of mapped pages by limit per call

2019-07-18 Thread Andrew Cooper
On 18/07/2019 07:52, Juergen Gross wrote: > Today there is a global limit of pages mapped via /dev/xen/gntdev set > to 1 million pages per default. The Xen default limit even for dom0 is 1024 pages * 16 entries per page, which is far lower than this limit. > There is no reason why that limit is

Re: [PATCH v2] x86/paravirt: Drop {read,write}_cr8() hooks

2019-07-15 Thread Andrew Cooper
On 15/07/2019 19:17, Nadav Amit wrote: >> On Jul 15, 2019, at 8:16 AM, Andrew Cooper wrote: >> >> There is a lot of infrastructure for functionality which is used >> exclusively in __{save,restore}_processor_state() on the suspend/resume >> path. >>

Re: [Xen-devel] [PATCH 0/2] Remove 32-bit Xen PV guest support

2019-07-15 Thread Andrew Cooper
On 15/07/2019 18:28, Andy Lutomirski wrote: > On Mon, Jul 15, 2019 at 9:34 AM Andi Kleen wrote: >> Juergen Gross writes: >> >>> The long term plan has been to replace Xen PV guests by PVH. The first >>> victim of that plan are now 32-bit PV guests, as those are used only >>> rather seldom these

[PATCH v2] x86/paravirt: Drop {read,write}_cr8() hooks

2019-07-15 Thread Andrew Cooper
of the Local APIC state isn't a clever thing to be doing. Delete the suspend/resume cr8 handling, which shrinks the size of struct saved_context, and allows for the removal of both PVOPS. Signed-off-by: Andrew Cooper --- CC: x...@kernel.org CC: virtualizat...@lists.linux-foundation.org CC: Borislav

[PATCH] x86/paravirt: Drop {read,write}_cr8() hooks

2019-07-15 Thread Andrew Cooper
, which allows for the removal of both PVOPS. Signed-off-by: Andrew Cooper --- CC: x...@kernel.org CC: virtualizat...@lists.linux-foundation.org CC: Borislav Petkov CC: Peter Zijlstra CC: Andy Lutomirski CC: Nadav Amit CC: Stephane Eranian CC: Feng Tang CC: Juergen Gross CC: Boris Ostrovsky

Re: [PATCH] x86/apic: Initialize TPR to block interrupts 16-31

2019-07-15 Thread Andrew Cooper
chance that a certain class of device malfunctions crashes the >> kernel in hard-to-debug ways. >> >> Cc: Nadav Amit >> Cc: Stephane Eranian >> Cc: Feng Tang >> Suggested-by: Andrew Cooper >> Signed-off-by: Andy Lutomirski >> --- >> arch

Re: [Xen-devel] [PATCH v2] xen/pv: Fix a boot up hang revealed by int3 self test

2019-07-15 Thread Andrew Cooper
On 15/07/2019 07:54, Jan Beulich wrote: > On 15.07.2019 07:05, Zhenzhong Duan wrote: >> On 2019/7/12 22:06, Andrew Cooper wrote: >>> On 11/07/2019 03:15, Zhenzhong Duan wrote: >>>> Commit 7457c0da024b ("x86/alternatives: Add int3_emulate_call() >>>&

Re: [Xen-devel] [PATCH v2] xen/pv: Fix a boot up hang revealed by int3 self test

2019-07-12 Thread Andrew Cooper
On 11/07/2019 03:15, Zhenzhong Duan wrote: > Commit 7457c0da024b ("x86/alternatives: Add int3_emulate_call() > selftest") is used to ensure there is a gap setup in exception stack > which could be used for inserting call return address. > > This gap is missed in XEN PV int3 exception entry path,

Re: [patch V2 04/25] x86/apic: Make apic_pending_intr_clear() more robust

2019-07-05 Thread Andrew Cooper
On 05/07/2019 21:49, Paolo Bonzini wrote: > On 05/07/19 22:25, Thomas Gleixner wrote: >> In practice, this makes Linux vulnerable to CVE-2011-1898 / XSA-3, which >> I'm disappointed to see wasn't shared with other software vendors at the >> time. > Oh, that brings back memories. At the time I was

Re: [patch V2 04/25] x86/apic: Make apic_pending_intr_clear() more robust

2019-07-05 Thread Andrew Cooper
On 05/07/2019 20:19, Nadav Amit wrote: >> On Jul 5, 2019, at 8:47 AM, Andrew Cooper wrote: >> >> On 04/07/2019 16:51, Thomas Gleixner wrote: >>> 2) The loop termination logic is interesting at best. >>> >>> If the machine has no TSC or cpu_kh

Re: [patch V2 04/25] x86/apic: Make apic_pending_intr_clear() more robust

2019-07-05 Thread Andrew Cooper
On 05/07/2019 20:06, Andy Lutomirski wrote: > On Fri, Jul 5, 2019 at 8:47 AM Andrew Cooper > wrote: >> On 04/07/2019 16:51, Thomas Gleixner wrote: >>> 2) The loop termination logic is interesting at best. >>> >>> If the machine has no TSC

Re: [patch V2 04/25] x86/apic: Make apic_pending_intr_clear() more robust

2019-07-05 Thread Andrew Cooper
On 04/07/2019 16:51, Thomas Gleixner wrote: > 2) The loop termination logic is interesting at best. > > If the machine has no TSC or cpu_khz is not known yet it tries 1 > million times to ack stale IRR/ISR bits. What? > > With TSC it uses the TSC to calculate the loop termination.

Re: [Xen-devel] [PATCH v2 4/9] x86/mm/tlb: Flush remote and local TLBs concurrently

2019-07-03 Thread Andrew Cooper
On 03/07/2019 18:02, Nadav Amit wrote: >> On Jul 3, 2019, at 7:04 AM, Juergen Gross wrote: >> >> On 03.07.19 01:51, Nadav Amit wrote: >>> To improve TLB shootdown performance, flush the remote and local TLBs >>> concurrently. Introduce flush_tlb_multi() that does so. Introduce >>> paravirtual

Re: [Xen-devel] [RFC PATCH 04/16] x86/xen: hypercall support for xenhost_t

2019-06-14 Thread Andrew Cooper
On 14/06/2019 08:35, Juergen Gross wrote: > On 14.06.19 09:20, Ankur Arora wrote: >> On 2019-06-12 2:15 p.m., Andrew Cooper wrote: >>> On 09/05/2019 18:25, Ankur Arora wrote: >>>> Allow for different hypercall implementations for different xenhost >>>>

Re: [Xen-devel] [RFC PATCH 02/16] x86/xen: cpuid support in xenhost_t

2019-06-12 Thread Andrew Cooper
On 09/05/2019 18:25, Ankur Arora wrote: > xen_cpuid_base() is used to probe and setup features early in a > guest's lifetime. > > We want this to behave differently depending on xenhost->type: for > instance, local xenhosts cannot intercept the cpuid instruction at all. > > Add op (*cpuid_base)()

Re: [Xen-devel] [RFC PATCH 04/16] x86/xen: hypercall support for xenhost_t

2019-06-12 Thread Andrew Cooper
On 09/05/2019 18:25, Ankur Arora wrote: > Allow for different hypercall implementations for different xenhost types. > Nested xenhost, which has two underlying xenhosts, can use both > simultaneously. > > The hypercall macros (HYPERVISOR_*) implicitly use the default xenhost.x > A new macro

Re: [Xen-devel] [PATCH v2 1/2] KVM: Start populating /sys/hypervisor with KVM entries

2019-05-16 Thread Andrew Cooper
On 16/05/2019 14:50, Alexander Graf wrote: > On 14.05.19 08:16, Filippo Sironi wrote: >> Start populating /sys/hypervisor with KVM entries when we're running on >> KVM. This is to replicate functionality that's available when we're >> running on Xen. >> >> Start with /sys/hypervisor/uuid, which

Re: [RFC][PATCH] tracing/x86: Save CR2 before tracing irqsoff on error_entry

2019-03-21 Thread Andrew Cooper
a gradual "let's stop >>> supporting xyz under PV, because it causes pain and isn't worth it". >> So Juergen recently introduced PARAVIRT_XXL, which are exactly those >> bits of PV we can get rid of. >> >> This paravirt-me-harder config does indeed inclu

Re: [Xen-devel] xen: Can't insert balloon page into VM userspace (WAS Re: [linux-linus bisection] complete test-arm64-arm64-xl-xsm)

2019-03-12 Thread Andrew Cooper
On 12/03/2019 17:18, David Hildenbrand wrote: > On 12.03.19 18:14, Matthew Wilcox wrote: >> On Tue, Mar 12, 2019 at 05:05:39PM +, Julien Grall wrote: >>> On 3/12/19 3:59 PM, Julien Grall wrote: It looks like all the arm test for linus [1] and next [2] tree are now failing. x86 seems

Re: [Xen-devel] [PATCH] xen-netback: fix occasional leak of grant ref mappings under memory pressure

2019-02-28 Thread Andrew Cooper
On 28/02/2019 02:03, Igor Druzhinin wrote: > Zero-copy callback flag is not yet set on frag list skb at the moment > xenvif_handle_frag_list() returns -ENOMEM. This eventually results in > leaking grant ref mappings since xenvif_zerocopy_callback() is never > called for these fragments. Those

Re: [Xen-devel] xen/evtchn and forced threaded irq

2019-02-26 Thread Andrew Cooper
On 26/02/2019 09:14, Roger Pau Monné wrote: > On Mon, Feb 25, 2019 at 01:55:42PM +, Julien Grall wrote: >> Hi Oleksandr, >> >> On 25/02/2019 13:24, Oleksandr Andrushchenko wrote: >>> On 2/22/19 3:33 PM, Julien Grall wrote: Hi, On 22/02/2019 12:38, Oleksandr Andrushchenko wrote:

  1   2   3   4   5   6   >