Re: [PATCH 0/7] Do not read from descriptor ring

On 6/3/21 10:53 PM, Jason Wang wrote: > Hi: > > The virtio driver should not trust the device. This beame more urgent > for the case of encrtpyed VM or VDUSE[1]. In both cases, technology > like swiotlb/IOMMU is used to prevent the poking/mangling of memory > from the device. But this is not

Re: [PATCH v1 1/8] virtio: Force only split mode with protected guest

On 6/3/21 4:32 PM, Andi Kleen wrote: > >> We do not need an increasing pile of kludges > > Do you mean disabling features is a kludge? > > If yes I disagree with that characterization. > > >> to make TDX and SEV “secure”.  We need the actual loaded driver to be >> secure.  The virtio

Re: [PATCH v1 1/8] virtio: Force only split mode with protected guest

On Thu, Jun 3, 2021, at 12:53 PM, Andi Kleen wrote: > > > Tell that to every crypto downgrade attack ever. > > That's exactly what this patch addresses. > > > > > I see two credible solutions: > > > > 1. Actually harden the virtio driver. > That's exactly what this patchkit, and the

Re: [PATCH v1 1/8] virtio: Force only split mode with protected guest

On Thu, Jun 3, 2021, at 11:00 AM, Andi Kleen wrote: > > On 6/3/2021 10:33 AM, Andy Lutomirski wrote: > > On 6/2/21 5:41 PM, Andi Kleen wrote: > >> Only allow split mode when in a protected guest. Followon > >> patches harden the split mode code paths, and we don

Re: [PATCH v1 1/8] virtio: Force only split mode with protected guest

On 6/2/21 5:41 PM, Andi Kleen wrote: > Only allow split mode when in a protected guest. Followon > patches harden the split mode code paths, and we don't want > an malicious host to force anything else. Also disallow > indirect mode for similar reasons. I read this as "the virtio driver is buggy.

Re: [PATCH 2/3] x86/sev-es: Check if regs->sp is trusted before adjusting #VC IST stack

On Thu, Feb 18, 2021 at 11:21 AM Joerg Roedel wrote: > > On Thu, Feb 18, 2021 at 09:49:06AM -0800, Andy Lutomirski wrote: > > I don't understand what this means. The whole entry mechanism on x86 > > is structured so that we call a C function *and return from that C > >

Re: [PATCH 2/3] x86/sev-es: Check if regs->sp is trusted before adjusting #VC IST stack

On Thu, Feb 18, 2021 at 3:25 AM Joerg Roedel wrote: > > Hi Andy, > > On Wed, Feb 17, 2021 at 10:09:46AM -0800, Andy Lutomirski wrote: > > Can you get rid of the linked list hack while you're at it? This code > > is unnecessarily convoluted right now, and it seems to be j

Re: [PATCH 2/3] x86/sev-es: Check if regs->sp is trusted before adjusting #VC IST stack

s to look if the regs->sp > value is trusted, meaning it was not set by user-space. Extend the > check to not use regs->sp when the NMI interrupted user-space code or > the SYSCALL gap. > > Reported-by: Andy Lutomirski > Fixes: 315562c9af3d5 ("x86/sev-es: Adjust #V

Re: [PATCH v2 05/12] x86: rework arch_local_irq_restore() to not use popf

> On Nov 22, 2020, at 9:22 PM, Jürgen Groß wrote: > > On 22.11.20 22:44, Andy Lutomirski wrote: >>> On Sat, Nov 21, 2020 at 10:55 PM Jürgen Groß wrote: >>> >>> On 20.11.20 12:59, Peter Zijlstra wrote: >>>> On Fri, Nov 20, 2020 at 12:4

Re: [PATCH v2 05/12] x86: rework arch_local_irq_restore() to not use popf

On Sat, Nov 21, 2020 at 10:55 PM Jürgen Groß wrote: > > On 20.11.20 12:59, Peter Zijlstra wrote: > > On Fri, Nov 20, 2020 at 12:46:23PM +0100, Juergen Gross wrote: > >> +static __always_inline void arch_local_irq_restore(unsigned long flags) > >> +{ > >> +if (!arch_irqs_disabled_flags(flags))

Re: [PATCH 4/4] x86/xen: drop USERGS_SYSRET64 paravirt call

On Mon, Nov 16, 2020 at 7:23 AM Juergen Gross wrote: > > USERGS_SYSRET64 is used to return from a syscall via sysret, but > a Xen PV guest will nevertheless use the iret hypercall, as there > is no sysret PV hypercall defined. > > So instead of testing all the prerequisites for doing a sysret and

Re: [PATCH 4/4] x86/xen: drop USERGS_SYSRET64 paravirt call

nants. > > Signed-off-by: Juergen Gross Acked-by: Andy Lutomirski FWIW, you've lost the VGCF_in_syscall optimization. Let me see if I can give it back to you better. > --- > arch/x86/entry/entry_64.S | 22 +- > arch/x86/include/asm/irqflags.h |

Re: [PATCH 3/4] x86/pv: switch SWAPGS to ALTERNATIVE

6_FEATURE_XENPV. > > There are several instances using the PV-aware SWAPGS macro in paths > which are never executed in a Xen PV guest. Replace those with the > plain swapgs instruction. For SWAPGS_UNSAFE_STACK the same applies. Acked-by: Andy Lutomirski ___

Re: [PATCH] drivers/virt: vmgenid: add vm generation id driver

On Sun, Oct 18, 2020 at 8:59 AM Michael S. Tsirkin wrote: > > On Sun, Oct 18, 2020 at 08:54:36AM -0700, Andy Lutomirski wrote: > > On Sun, Oct 18, 2020 at 8:52 AM Michael S. Tsirkin wrote: > > > > > > On Sat, Oct 17, 2020 at 03:24:08PM +0200, Jason A. Donenfel

Re: [PATCH] drivers/virt: vmgenid: add vm generation id driver

On Sun, Oct 18, 2020 at 8:52 AM Michael S. Tsirkin wrote: > > On Sat, Oct 17, 2020 at 03:24:08PM +0200, Jason A. Donenfeld wrote: > > 4c. The guest kernel maintains an array of physical addresses that are > > MADV_WIPEONFORK. The hypervisor knows about this array and its > > location through

Re: [PATCH] drivers/virt: vmgenid: add vm generation id driver

On Fri, Oct 16, 2020 at 6:40 PM Jann Horn wrote: > > [adding some more people who are interested in RNG stuff: Andy, Jason, > Theodore, Willy Tarreau, Eric Biggers. also linux-api@, because this > concerns some pretty fundamental API stuff related to RNG usage] > > On Fri, Oct 16, 2020 at 4:33 PM

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

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, Peter Zijlstra wrote: > >>> If SNP is the sole reason #VC needs to be IST, then I'd

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

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 > >

Re: [PATCH] Allow RDTSC and RDTSCP from userspace

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 before IST gets shifted > > #VC > > > > Kaboom. > > &

Re: [PATCH] Allow RDTSC and RDTSCP from userspace

> On Apr 25, 2020, at 12:10 PM, Joerg Roedel wrote: > > On Sat, Apr 25, 2020 at 11:15:35AM -0700, Andy Lutomirski wrote: >> shift_ist is gross. What's it for? If it's not needed, I'd rather >> not use it, and I eventually want to get rid of it for #DB as well. >

Re: [PATCH] Allow RDTSC and RDTSCP from userspace

On Sat, Apr 25, 2020 at 5:49 AM Joerg Roedel wrote: > > Hi Dave, > > On Fri, Apr 24, 2020 at 03:53:09PM -0700, Dave Hansen wrote: > > Ahh, so any instruction that can have an instruction intercept set > > potentially needs to be able to tolerate a #VC? Those instruction > > intercepts are under

Re: [PATCH 70/70] x86/sev-es: Add NMI state tracking

On Thu, Mar 19, 2020 at 12:26 PM Joerg Roedel wrote: > > On Thu, Mar 19, 2020 at 11:40:39AM -0700, Andy Lutomirski wrote: > > > Nope. A nested NMI will reset the interrupted NMI's return frame to > > cause it to run again when it's done. I don't think this will have >

Re: [PATCH 41/70] x86/sev-es: Add Runtime #VC Exception Handler

On Thu, Mar 19, 2020 at 9:24 AM Joerg Roedel wrote: > > On Thu, Mar 19, 2020 at 08:44:03AM -0700, Andy Lutomirski wrote: > > On Thu, Mar 19, 2020 at 2:14 AM Joerg Roedel wrote: > > > > > > From: Tom Lendacky > > > > > > Add the handler for #VC

Re: [PATCH 70/70] x86/sev-es: Add NMI state tracking

On Thu, Mar 19, 2020 at 9:07 AM Joerg Roedel wrote: > > Hi Andy, > > On Thu, Mar 19, 2020 at 08:35:59AM -0700, Andy Lutomirski wrote: > > On Thu, Mar 19, 2020 at 2:14 AM Joerg Roedel wrote: > > > > > > From: Joerg Roedel > > > > > > Keep NMI

Re: [PATCH 42/70] x86/sev-es: Support nested #VC exceptions

On Thu, Mar 19, 2020 at 2:14 AM Joerg Roedel wrote: > > From: Joerg Roedel > > Handle #VC exceptions that happen while the GHCB is in use. This can > happen when an NMI happens in the #VC exception handler and the NMI > handler causes a #VC exception itself. Save the contents of the GHCB > when

Re: [PATCH 41/70] x86/sev-es: Add Runtime #VC Exception Handler

On Thu, Mar 19, 2020 at 2:14 AM Joerg Roedel wrote: > > From: Tom Lendacky > > Add the handler for #VC exceptions invoked at runtime. If I read this correctly, this does not use IST. If that's true, I don't see how this can possibly work. There at least two nasty cases that come to mind: 1.

Re: [PATCH 70/70] x86/sev-es: Add NMI state tracking

On Thu, Mar 19, 2020 at 2:14 AM Joerg Roedel wrote: > > From: Joerg Roedel > > Keep NMI state in SEV-ES code so the kernel can re-enable NMIs for the > vCPU when it reaches IRET. IIRC I suggested just re-enabling NMI in C from do_nmi(). What was wrong with that approach? > +#ifdef

Re: [PATCH 38/62] x86/sev-es: Handle instruction fetches from user-space

On Fri, Mar 13, 2020 at 2:12 AM Joerg Roedel wrote: > > On Wed, Feb 12, 2020 at 01:42:48PM -0800, Andy Lutomirski wrote: > > I realize that this is a somewhat arbitrary point in the series to > > complain about this, but: the kernel already has infrastructure to >

Re: [PATCH 38/62] x86/sev-es: Handle instruction fetches from user-space

On Tue, Feb 11, 2020 at 5:53 AM Joerg Roedel wrote: > > From: Joerg Roedel > > When a #VC exception is triggered by user-space the instruction > decoder needs to read the instruction bytes from user addresses. > Enhance es_fetch_insn_byte() to safely fetch kernel and user > instruction bytes. I

Re: [PATCH 23/62] x86/idt: Move IDT to data segment

> On Feb 12, 2020, at 3:55 AM, Joerg Roedel wrote: > > On Tue, Feb 11, 2020 at 02:41:25PM -0800, Andy Lutomirski wrote: >>> On Tue, Feb 11, 2020 at 5:53 AM Joerg Roedel wrote: >>> >>> From: Joerg Roedel >>> >>> With SEV-ES

Re: [PATCH 14/62] x86/boot/compressed/64: Add stage1 #VC handler

> On Feb 12, 2020, at 3:38 AM, Joerg Roedel wrote: > > On Tue, Feb 11, 2020 at 02:23:22PM -0800, Andy Lutomirski wrote: >>> On Tue, Feb 11, 2020 at 5:53 AM Joerg Roedel wrote: >>> +void __init no_ghcb_vc_handler(struct pt_regs *regs) >> >> Isn't

Re: [RFC PATCH 00/62] Linux as SEV-ES Guest Support

> On Feb 11, 2020, at 5:53 AM, Joerg Roedel wrote: > > >* Putting some NMI-load on the guest will make it crash usually > within a minute Suppose you do CPUID or some MMIO and get #VC. You fill in the GHCB to ask for help. Some time between when you start filling it out and when

Re: [PATCH 50/62] x86/sev-es: Handle VMMCALL Events

> On Feb 11, 2020, at 5:53 AM, Joerg Roedel wrote: > > From: Tom Lendacky > > Implement a handler for #VC exceptions caused by VMMCALL instructions. > This patch is only a starting point, VMMCALL emulation under SEV-ES > needs further hypervisor-specific changes to provide additional state.

Re: [PATCH 46/62] x86/sev-es: Handle INVD Events

> On Feb 11, 2020, at 5:53 AM, Joerg Roedel wrote: > > From: Tom Lendacky > > Implement a handler for #VC exceptions caused by INVD instructions. Uh, what? Surely the #VC code can have a catch-all OOPS path for things like this. Linux should never ever do INVD.

Re: [PATCH 62/62] x86/sev-es: Add NMI state tracking

On Tue, Feb 11, 2020 at 5:53 AM Joerg Roedel wrote: > > From: Joerg Roedel > > Keep NMI state in SEV-ES code so the kernel can re-enable NMIs for the > vCPU when it reaches IRET. This patch is overcomplicated IMO. Just do the magic incantation in C from do_nmi or from here: /*

Re: [PATCH 39/62] x86/sev-es: Harden runtime #VC handler for exceptions from user-space

On Tue, Feb 11, 2020 at 5:53 AM Joerg Roedel wrote: > > From: Joerg Roedel > > Send SIGBUS to the user-space process that caused the #VC exception > instead of killing the machine. Also ratelimit the error messages so > that user-space can't flood the kernel log. What would cause this? CPUID?

Re: [PATCH 35/62] x86/sev-es: Setup per-cpu GHCBs for the runtime handler

On Tue, Feb 11, 2020 at 5:53 AM Joerg Roedel wrote: > > From: Tom Lendacky > > The runtime handler needs a GHCB per CPU. Set them up and map them > unencrypted. > > Signed-off-by: Tom Lendacky > Signed-off-by: Joerg Roedel > --- > arch/x86/include/asm/mem_encrypt.h | 2 ++ >

Re: [PATCH 30/62] x86/head/64: Move early exception dispatch to C code

On Tue, Feb 11, 2020 at 5:53 AM Joerg Roedel wrote: > > From: Joerg Roedel > > Move the assembly coded dispatch between page-faults and all other > exceptions to C code to make it easier to maintain and extend. > > Signed-off-by: Joerg Roedel > --- > arch/x86/kernel/head64.c | 20

Re: [PATCH 23/62] x86/idt: Move IDT to data segment

On Tue, Feb 11, 2020 at 5:53 AM Joerg Roedel wrote: > > From: Joerg Roedel > > With SEV-ES, exception handling is needed very early, even before the > kernel has cleared the bss segment. In order to prevent clearing the > currently used IDT, move the IDT to the data segment. Ugh. At the very

Re: [PATCH 25/62] x86/head/64: Install boot GDT

On Tue, Feb 11, 2020 at 5:53 AM Joerg Roedel wrote: > > From: Joerg Roedel > > Handling exceptions during boot requires a working GDT. The kernel GDT > is not yet ready for use, so install a temporary boot GDT. > > Signed-off-by: Joerg Roedel > --- > arch/x86/kernel/head_64.S | 26

Re: [PATCH 19/62] x86/sev-es: Add support for handling IOIO exceptions

On Tue, Feb 11, 2020 at 5:53 AM Joerg Roedel wrote: > > From: Tom Lendacky > > Add support for decoding and handling #VC exceptions for IOIO events. > > Signed-off-by: Tom Lendacky > [ jroe...@suse.de: Adapted code to #VC handling framework ] > Co-developed-by: Joerg Roedel > Signed-off-by:

Re: [PATCH 18/62] x86/boot/compressed/64: Setup GHCB Based VC Exception handler

On Tue, Feb 11, 2020 at 5:53 AM Joerg Roedel wrote: > > From: Joerg Roedel > > Install an exception handler for #VC exception that uses a GHCB. Also > add the infrastructure for handling different exit-codes by decoding > the instruction that caused the exception and error handling. > > diff

Re: [PATCH 14/62] x86/boot/compressed/64: Add stage1 #VC handler

On Tue, Feb 11, 2020 at 5:53 AM Joerg Roedel wrote: > > From: Joerg Roedel > > Add the first handler for #VC exceptions. At stage 1 there is no GHCB > yet becaue we might still be on the EFI page table and thus can't map > memory unencrypted. > > The stage 1 handler is limited to the MSR based

Re: [PATCH 08/62] x86/boot/compressed/64: Add IDT Infrastructure

On Tue, Feb 11, 2020 at 5:53 AM Joerg Roedel wrote: > > From: Joerg Roedel > > Add code needed to setup an IDT in the early pre-decompression > boot-code. The IDT is loaded first in startup_64, which is after > EfiExitBootServices() has been called, and later reloaded when the > kernel image has

Re: [PATCH 07/62] x86/boot/compressed/64: Disable red-zone usage

. This area is known as the red zone. > > This is not compatible with exception handling, so disable it for the > pre-decompression boot code. Acked-by: Andy Lutomirski I admit that I thought we already supported exceptions this early. At least I seem to remember writing this

Re: [RFC PATCH 00/62] Linux as SEV-ES Guest Support

On Tue, Feb 11, 2020 at 7:43 AM Joerg Roedel wrote: > > On Tue, Feb 11, 2020 at 03:50:08PM +0100, Peter Zijlstra wrote: > > > Oh gawd; so instead of improving the whole NMI situation, AMD went and > > made it worse still ?!? > > Well, depends on how you want to see it. Under SEV-ES an IRET will

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

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 infrastructure for functionality which is used > >> exclusively in __{save,restore}_processor_state() on the

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

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 days. Xen on x86 requires 64-bit support and

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

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 used > > exclusively in __{save,restore}_processor_state() on the suspend/resume > > path. > > > > cr8 is an alias of APIC_TASKPRI, and

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

On Tue, Jun 25, 2019 at 8:48 PM Nadav Amit wrote: > > > On Jun 25, 2019, at 8:36 PM, Andy Lutomirski wrote: > > > > On Wed, Jun 12, 2019 at 11:49 PM Nadav Amit wrote: > >> To improve TLB shootdown performance, flush the remote and local TLBs > >>

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

On Wed, Jun 12, 2019 at 11:49 PM Nadav Amit wrote: > > To improve TLB shootdown performance, flush the remote and local TLBs > concurrently. Introduce flush_tlb_multi() that does so. The current > flush_tlb_others() interface is kept, since paravirtual interfaces need > to be adapted first before

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 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 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 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

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

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 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

> 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 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 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 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

> 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 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

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 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 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: [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 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 v1 06/27] x86/entry/64: Adapt assembly for PIE support

> On Oct 20, 2017, at 5:20 PM, Ingo Molnar wrote: > > > * Thomas Garnier wrote: > */ - cmpq$.Lentry_SYSCALL_64_after_fastpath_call, (%rsp) + leaq.Lentry_SYSCALL_64_after_fastpath_call(%rip), %r11 + cmpq

Re: [PATCH v1 06/27] x86/entry/64: Adapt assembly for PIE support

> On Oct 20, 2017, at 5:20 PM, Ingo Molnar wrote: > > > * Thomas Garnier wrote: > */ - cmpq$.Lentry_SYSCALL_64_after_fastpath_call, (%rsp) + leaq.Lentry_SYSCALL_64_after_fastpath_call(%rip), %r11 + cmpq

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 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 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 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 2/2] vring: Force use of DMA API for ARM-based systems

the vring code to use the DMA API to establish translations, >> > otherwise all transactions will result in fatal faults and termination. >> > >> > Given that ARM-based systems only see an SMMU if one is really present >> > (the topology is all described by

Re: [RFC PATCH] vring: Force use of DMA API for ARM-based systems

On Fri, Jan 6, 2017 at 10:32 AM, Robin Murphy wrote: > On 06/01/17 17:48, Jean-Philippe Brucker wrote: >> Hi Will, >> >> On 20/12/16 15:14, Will Deacon wrote: >>> Booting Linux on an ARM fastmodel containing an SMMU emulation results >>> in an unexpected I/O page fault from

[PATCH] virtio-net: Fix DMA-from-the-stack in virtnet_set_mac_address()

Reported-by: zbys...@in.waw.pl Signed-off-by: Andy Lutomirski <l...@kernel.org> --- Very lightly tested. drivers/net/virtio_net.c | 19 ++- 1 file changed, 14 insertions(+), 5 deletions(-) diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c index 7276d5a95

Re: [PATCH 2/2] virtio_ring: fix complaint by sparse

break; >>> vring_unmap_one(vq, [i]); >>> -i = vq->vring.desc[i].next; >>> +i = virtio16_to_cpu(_vq->vdev, vq->vring.desc[i].next); >>> } >>> >>> vq->vq.nu

[PATCH] virtio_console: Stop doing DMA on the stack

directions using picocom aimed at /dev/hvc0. Signed-off-by: Andy Lutomirski <l...@kernel.org> --- Hi all- This is currently broken in tip:x86/asm. If you (Amit) like this patch, would it make sense for Ingo to add it to -tip? Thanks, Andy drivers/char/virtio_console.

DMA from stack in virtio_net and virtio_console

virtio_net does DMA on the stack when it calls sg_init_one in virtio_set_queues, virtnet_vlan_rx_add_vid, and virtnet_vlan_rx_kill_vid. Michael, I think these are examples we missed somehow when fixing these issues earlier on. virtio_console does it here: sg_init_one(sg, , sizeof(cpkt)); This

Re: [PATCH V2 RFC] fixup! virtio: convert to use DMA api

On Wed, Apr 27, 2016 at 7:54 AM, Michael S. Tsirkin <m...@redhat.com> wrote: > On Wed, Apr 27, 2016 at 07:43:07AM -0700, Andy Lutomirski wrote: >> On Wed, Apr 27, 2016 at 7:38 AM, Michael S. Tsirkin <m...@redhat.com> wrote: >> > On Wed, Apr 27, 2016 at 07:31:43A

Re: [PATCH V2 RFC] fixup! virtio: convert to use DMA api

On Wed, Apr 27, 2016 at 7:38 AM, Michael S. Tsirkin <m...@redhat.com> wrote: > On Wed, Apr 27, 2016 at 07:31:43AM -0700, Andy Lutomirski wrote: >> On Wed, Apr 27, 2016 at 7:23 AM, Joerg Roedel <j...@8bytes.org> wrote: >> > On Wed, Apr 27, 2016 at 04:37:04PM +

Re: [PATCH V2 RFC] fixup! virtio: convert to use DMA api

On Wed, Apr 27, 2016 at 7:23 AM, Joerg Roedel wrote: > On Wed, Apr 27, 2016 at 04:37:04PM +0300, Michael S. Tsirkin wrote: >> One correction: it's a feature of the device in the system. >> There could be a mix of devices bypassing and not >> bypassing the IOMMU. > > No, it really

Re: [PATCH RFC] fixup! virtio: convert to use DMA api

On Apr 20, 2016 6:14 AM, "Michael S. Tsirkin" <m...@redhat.com> wrote: > > On Tue, Apr 19, 2016 at 02:07:01PM -0700, Andy Lutomirski wrote: > > On Tue, Apr 19, 2016 at 1:54 PM, Michael S. Tsirkin <m...@redhat.com> wrote: > > > On Tue, Apr 19, 2016

Re: [PATCH RFC] fixup! virtio: convert to use DMA api

On Tue, Apr 19, 2016 at 1:54 PM, Michael S. Tsirkin <m...@redhat.com> wrote: > On Tue, Apr 19, 2016 at 01:27:29PM -0700, Andy Lutomirski wrote: >> On Tue, Apr 19, 2016 at 1:16 PM, Michael S. Tsirkin <m...@redhat.com> wrote: >> > On Tue, Apr 19, 2016 at 11:01:38A

Re: [PATCH RFC] fixup! virtio: convert to use DMA api

On Tue, Apr 19, 2016 at 1:16 PM, Michael S. Tsirkin <m...@redhat.com> wrote: > On Tue, Apr 19, 2016 at 11:01:38AM -0700, Andy Lutomirski wrote: >> On Tue, Apr 19, 2016 at 10:49 AM, Michael S. Tsirkin <m...@redhat.com> wrote: >> > On Tue, Apr 19, 2016 at 12:26:44P

Re: [PATCH RFC] fixup! virtio: convert to use DMA api

On Tue, Apr 19, 2016 at 10:49 AM, Michael S. Tsirkin wrote: > On Tue, Apr 19, 2016 at 12:26:44PM -0400, David Woodhouse wrote: >> On Tue, 2016-04-19 at 19:20 +0300, Michael S. Tsirkin wrote: >> > >> > > I thought that PLATFORM served that purpose. Woudn't the host >> > >

Re: [PATCH RFC] fixup! virtio: convert to use DMA api

On Tue, Apr 19, 2016 at 9:09 AM, Michael S. Tsirkin <m...@redhat.com> wrote: > On Tue, Apr 19, 2016 at 09:02:14AM -0700, Andy Lutomirski wrote: >> On Tue, Apr 19, 2016 at 3:27 AM, Michael S. Tsirkin <m...@redhat.com> wrote: >> > On Mon, Apr 18, 2016 at 12:24:15P

Re: [PATCH RFC] fixup! virtio: convert to use DMA api

On Tue, Apr 19, 2016 at 3:27 AM, Michael S. Tsirkin <m...@redhat.com> wrote: > On Mon, Apr 18, 2016 at 12:24:15PM -0700, Andy Lutomirski wrote: >> On Mon, Apr 18, 2016 at 11:29 AM, David Woodhouse <dw...@infradead.org> >> wrote: >> > For x86, you *can* ena

Re: [PATCH RFC] fixup! virtio: convert to use DMA api

On Apr 19, 2016 2:13 AM, "Michael S. Tsirkin" wrote: > > > I guess you are right in that we should split this part out. > What I wanted is really the combination > PASSTHROUGH && !PLATFORM so that we can say "ok we don't > need to guess, this device actually bypasses the IOMMU".

Re: [PATCH RFC] fixup! virtio: convert to use DMA api

On Mon, Apr 18, 2016 at 11:29 AM, David Woodhouse wrote: > For x86, you *can* enable virtio-behind-IOMMU if your DMAR tables tell > the truth, and even legacy kernels ought to cope with that. > FSVO 'ought to' where I suspect some of them will actually crash with a > NULL

Re: [PATCH v7 0/9] virtio DMA API, yet again

On Tue, Feb 2, 2016 at 9:46 PM, Andy Lutomirski <l...@kernel.org> wrote: > This switches virtio to use the DMA API on Xen and if requested by > module option. Michael, any update on this? --Andy ___ Virtualization mailing list Vi

Re: [PATCH v7 9/9] vring: Use the DMA API on Xen

On Wed, Feb 3, 2016 at 1:49 AM, David Vrabel <david.vra...@citrix.com> wrote: > On 03/02/16 05:46, Andy Lutomirski wrote: >> Signed-off-by: Andy Lutomirski <l...@kernel.org> > > You forgot the previous Reviewed-by tags. Whoops. If I send another version, they'll be th

Re: [PATCH v7 5/9] virtio_ring: Support DMA APIs

On Feb 3, 2016 5:52 AM, "Michael S. Tsirkin" <m...@redhat.com> wrote: > > On Tue, Feb 02, 2016 at 09:46:36PM -0800, Andy Lutomirski wrote: > > virtio_ring currently sends the device (usually a hypervisor) > > physical addresses of its I/O buffers. This is okay w

Re: [PATCH v6 6/9] virtio: Add improved queue allocation API

On Tue, Feb 2, 2016 at 3:25 AM, Michael S. Tsirkin <m...@redhat.com> wrote: > On Mon, Feb 01, 2016 at 10:00:56AM -0800, Andy Lutomirski wrote: >> This leaves vring_new_virtqueue alone for compatbility, but it >> adds two new improved APIs: >> >> vring_create_virt

  1   2   3   >