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

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)

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)

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)

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)

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)

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: Should SEV-ES #VC use IST? (Re: [PATCH] Allow RDTSC and RDTSCP from userspace)

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: Should SEV-ES #VC use IST? (Re: [PATCH] Allow RDTSC and RDTSCP from userspace)

On 27/04/2020 18:37, Andy Lutomirski wrote: > On Sat, Apr 25, 2020 at 3:10 PM Andy Lutomirski wrote: >> On Sat, Apr 25, 2020 at 1:23 PM Joerg Roedel wrote: >>> On Sat, Apr 25, 2020 at 12:47:31PM -0700, Andy Lutomirski wrote: I assume the race you mean is: #VC Immediate NMI

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

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: [PATCH v2] x86/paravirt: Drop {read,write}_cr8() hooks

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

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

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: virtualization@lists.linux-foundation.org CC: Borislav

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

On 15/07/2019 15:52, Juergen Gross wrote: > On 15.07.19 16:26, Andy Lutomirski wrote: >> On Mon, Jul 15, 2019 at 6:23 AM Juergen Gross wrote: >>> >>> On 15.07.19 15:00, Andrew Cooper wrote: >>>> There is a lot of infrastructure for functionality which is u

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

, which allows for the removal of both PVOPS. Signed-off-by: Andrew Cooper --- CC: x...@kernel.org CC: virtualization@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: [Xen-devel] [PATCH v2 4/9] x86/mm/tlb: Flush remote and local TLBs concurrently

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] [PATCH 11/13] x86/paravirt: Add paravirt alternatives infrastructure

On 12/10/17 20:11, Boris Ostrovsky wrote: > On 10/06/2017 10:32 AM, Josh Poimboeuf wrote: >> On Thu, Oct 05, 2017 at 04:35:03PM -0400, Boris Ostrovsky wrote: #ifdef CONFIG_PARAVIRT +/* + * Paravirt alternatives are applied much earlier than normal alternatives. + * They

Re: [Xen-devel] [PATCH v2] x86/paravirt: Don't make vcpu_is_preempted() a callee-save function

On 14/02/17 14:46, Waiman Long wrote: > On 02/14/2017 04:39 AM, Peter Zijlstra wrote: >> On Mon, Feb 13, 2017 at 05:34:01PM -0500, Waiman Long wrote: >>> It is the address of _time that will exceed the 32-bit limit. >> That seems extremely unlikely. That would mean we have more than 4G >> worth of

Re: [Xen-devel] new barrier type for paravirt (was Re: [PATCH] virtio_ring: use smp_store_mb)

On 20/12/15 09:25, Michael S. Tsirkin wrote: > On Thu, Dec 17, 2015 at 03:39:10PM +0100, Peter Zijlstra wrote: >> On Thu, Dec 17, 2015 at 04:33:44PM +0200, Michael S. Tsirkin wrote: >>> On Thu, Dec 17, 2015 at 02:57:26PM +0100, Peter Zijlstra wrote: You could of course go fix that instead of

Re: [Xen-devel] [PATCH v2 0/3] Fix and cleanup for 32-bit PV sysexit

On 19/11/15 22:07, Andy Lutomirski wrote: > On Thu, Nov 19, 2015 at 1:55 PM, Boris Ostrovsky > wrote: >> The first patch fixes Xen PV regression introduced by 32-bit rewrite. Unlike >> the >> earlier version it uses ALTERNATIVE instruction and avoids using xen_sysexit

Re: [Xen-devel] [RFC] Hypervisor RNG and enumeration

On 29/10/14 05:19, Andy Lutomirski wrote: Here's a draft CommonHV spec. It's also on github: https://github.com/amluto/CommonHV So far, this provides a two-way RNG interface, a way to detect it, and a way to detect other hypervisor leaves. The latter is because, after both the enormous

Re: [Xen-devel] [GIT PULL] x86/mm changes for v3.9-rc1

On 22/02/13 17:53, Yinghai Lu wrote: On Fri, Feb 22, 2013 at 9:24 AM, Konrad Rzeszutek Wilk konrad.w...@oracle.com wrote: On Fri, Feb 22, 2013 at 11:55:31AM -0500, Konrad Rzeszutek Wilk wrote: On Thu, Feb 21, 2013 at 04:34:06PM -0800, H. Peter Anvin wrote: Hi Linus, This is a huge set of

Re: [Xen-devel] [PATCH v3 00/11] xen: Initial kexec/kdump implementation

On 07/01/13 10:25, Ian Campbell wrote: On Fri, 2013-01-04 at 19:11 +, Konrad Rzeszutek Wilk wrote: On Fri, Jan 04, 2013 at 06:07:51PM +0100, Daniel Kiper wrote: Because current KEXEC_CMD_kexec_load does not load kernel image and other things into Xen memory. It means that it should live

Re: [Xen-devel] [PATCH v3 00/11] xen: Initial kexec/kdump implementation

On 27/12/12 18:02, Eric W. Biederman wrote: Andrew Cooperandrew.coop...@citrix.com writes: On 27/12/2012 07:53, Eric W. Biederman wrote: The syscall ABI still has the wrong semantics. Aka totally unmaintainable and umergeable. The concept of domU support is also strange. What does domU

Re: [PATCH v2 01/11] kexec: introduce kexec_ops struct

. -hpa I agree that regular guests should not be using the kexec/kdump. However, this patch series is required for allowing a pvops kernel to be a crash kernel for Xen, which is very important from dom0/Xen's point of view. -- Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer T: +44 (0

Re: [PATCH v2 01/11] kexec: introduce kexec_ops struct

On 22/11/2012 17:47, H. Peter Anvin wrote: The other thing that should be considered here is how utterly preposterous the notion of doing in-guest crash dumping is in a system that contains a hypervisor. The reason for kdump is that on bare metal there are no other options, but in a