From: Brijesh Singh <brijesh.singh@amd.com> To: Arnd Bergmann <arnd@arndb.de>, David Laight <David.Laight@aculab.com> Cc: brijesh.singh@amd.com, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, "x86@kernel.org" <x86@kernel.org>, "linux-efi@vger.kernel.org" <linux-efi@vger.kernel.org>, "linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>, "kvm@vger.kernel.org" <kvm@vger.kernel.org>, "Fenghua Yu" <fenghua.yu@intel.com>, "Matt Fleming" <matt@codeblueprint.co.uk>, "David Howells" <dhowells@redhat.com>, "Paul Mackerras" <paulus@samba.org>, "H . Peter Anvin" <hpa@zytor.com>, "Christoph Lameter" <cl@linux.com>, "Jonathan Corbet" <corbet@lwn.net>, "Radim Krcmár" <rkrcmar@redhat.com>, "Piotr Luc" <piotr.luc@intel.com>, "Ingo Molnar" <mingo@redhat.com>, "Dave Airlie" <airlied@redhat.com>, "Borislav Petkov" <bp@suse.de>, "Tom Lendacky" <thomas.lendacky@amd.com>, "Kees Cook" <keescook@chromium.org>, "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>, "Reza Arbab" <arbab@linux.vnet.ibm.com>, "Andy Lutomirski" <luto@kernel.org>, "Thomas Gleixner" <tglx@linutronix.de>, "Laura Abbott" <labbott@redhat.com>, "Tony Luck" <tony.luck@intel.com>, "Ard Biesheuvel" <ard.biesheuvel@linaro.org>, "Eric Biederman" <ebiederm@xmission.com>, "Tejun Heo" <tj@kernel.org>, "Paolo Bonzini" <pbonzini@redhat.com>, "Andrew Morton" <akpm@linux-foundation.org>, "Kirill A . Shutemov" <kirill.shutemov@linux.intel.com>, "Lu Baolu" <baolu.lu@linux.intel.com> Subject: Re: [RFC Part1 PATCH v3 13/17] x86/io: Unroll string I/O when SEV is active Date: Wed, 26 Jul 2017 14:24:45 -0500 [thread overview] Message-ID: <ed6d4ce7-97a6-f664-d7d7-4ff48bc6f06a@amd.com> (raw) In-Reply-To: <CAK8P3a3h7JpmkW7W=HwqAuWWmro=ngj6HSeiiML_=T82x-FtZQ@mail.gmail.com> Hi Arnd and David, On 07/26/2017 05:45 AM, Arnd Bergmann wrote: > On Tue, Jul 25, 2017 at 11:51 AM, David Laight <David.Laight@aculab.com> wrote: >> From: Brijesh Singh >>> Sent: 24 July 2017 20:08 >>> From: Tom Lendacky <thomas.lendacky@amd.com> >>> >>> Secure Encrypted Virtualization (SEV) does not support string I/O, so >>> unroll the string I/O operation into a loop operating on one element at >>> a time. >>> >>> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> >>> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com> >>> --- >>> arch/x86/include/asm/io.h | 26 ++++++++++++++++++++++---- >>> 1 file changed, 22 insertions(+), 4 deletions(-) >>> >>> diff --git a/arch/x86/include/asm/io.h b/arch/x86/include/asm/io.h >>> index e080a39..2f3c002 100644 >>> --- a/arch/x86/include/asm/io.h >>> +++ b/arch/x86/include/asm/io.h >>> @@ -327,14 +327,32 @@ static inline unsigned type in##bwl##_p(int port) \ >>> \ >>> static inline void outs##bwl(int port, const void *addr, unsigned long count) \ >>> { > > This will clash with a fix I did to add a "memory" clobber > for the traditional implementation, see > https://patchwork.kernel.org/patch/9854573/ > >> Is it even worth leaving these as inline functions? >> Given the speed of IO cycles it is unlikely that the cost of calling a real >> function will be significant. >> The code bloat reduction will be significant. > > I think the smallest code would be the original "rep insb" etc, which > should be smaller than a function call, unlike the loop. Then again, > there is a rather small number of affected device drivers, almost all > of them for ancient hardware that you won't even build in a 64-bit > x86 kernel, see the list below. The only user I found that is actually > still relevant is drivers/tty/hvc/hvc_xen.c, which uses it for the early > console. There are some indirect user of string I/O functions. The following functions defined in lib/iomap.c calls rep version of ins and outs. - ioread8_rep, ioread16_rep, ioread32_rep - iowrite8_rep, iowrite16_rep, iowrite32_rep I found that several drivers use above functions. Here is one approach to convert it into non-inline functions. In this approach, I have added a new file arch/x86/kernel/io.c which provides non rep version of string I/O routines. The file gets built and used only when AMD_MEM_ENCRYPT is enabled. On positive side, if we don't build kernel with AMD_MEM_ENCRYPT support then we use inline routines, when AMD_MEM_ENCRYPT is built then we make a function call. Inside the function we unroll only when SEV is active. Do you see any issue with this approach ? thanks diff --git a/arch/x86/include/asm/io.h b/arch/x86/include/asm/io.h index e080a39..104927d 100644 --- a/arch/x86/include/asm/io.h +++ b/arch/x86/include/asm/io.h @@ -323,8 +323,9 @@ static inline unsigned type in##bwl##_p(int port) \ unsigned type value = in##bwl(port); \ slow_down_io(); \ return value; \ -} \ - \ +} + +#define BUILDIO_REP(bwl, bw, type) \ static inline void outs##bwl(int port, const void *addr, unsigned long count) \ { \ asm volatile("rep; outs" #bwl \ @@ -335,12 +336,31 @@ static inline void ins##bwl(int port, void *addr, unsigned long count) \ { \ asm volatile("rep; ins" #bwl \ : "+D"(addr), "+c"(count) : "d"(port)); \ -} +} \ BUILDIO(b, b, char) BUILDIO(w, w, short) BUILDIO(l, , int) +#ifdef CONFIG_AMD_MEM_ENCRYPT +extern void outsb_try_rep(int port, const void *addr, unsigned long count); +extern void insb_try_rep(int port, void *addr, unsigned long count); +extern void outsw_try_rep(int port, const void *addr, unsigned long count); +extern void insw_try_rep(int port, void *addr, unsigned long count); +extern void outsl_try_rep(int port, const void *addr, unsigned long count); +extern void insl_try_rep(int port, void *addr, unsigned long count); +#define outsb outsb_try_rep +#define insb insb_try_rep +#define outsw outsw_try_rep +#define insw insw_try_rep +#define outsl outsl_try_rep +#define insl insl_try_rep +#else +BUILDIO_REP(b, b, char) +BUILDIO_REP(w, w, short) +BUILDIO_REP(l, , int) +#endif + extern void *xlate_dev_mem_ptr(phys_addr_t phys); extern void unxlate_dev_mem_ptr(phys_addr_t phys, void *addr); diff --git a/arch/x86/kernel/Makefile b/arch/x86/kernel/Makefile index a01892b..3b6e2a3 100644 --- a/arch/x86/kernel/Makefile +++ b/arch/x86/kernel/Makefile @@ -42,6 +42,7 @@ CFLAGS_irq.o := -I$(src)/../include/asm/trace obj-y := process_$(BITS).o signal.o obj-$(CONFIG_COMPAT) += signal_compat.o +obj-$(CONFIG_AMD_MEM_ENCRYPT) += io.o obj-y += traps.o irq.o irq_$(BITS).o dumpstack_$(BITS).o obj-y += time.o ioport.o dumpstack.o nmi.o obj-$(CONFIG_MODIFY_LDT_SYSCALL) += ldt.o diff --git a/arch/x86/kernel/io.c b/arch/x86/kernel/io.c new file mode 100644 index 0000000..f58afa9 --- /dev/null +++ b/arch/x86/kernel/io.c @@ -0,0 +1,87 @@ +#include <linux/types.h> +#include <linux/io.h> +#include <asm/io.h> + +void outsb_try_rep(int port, const void *addr, unsigned long count) +{ + if (sev_active()) { + unsigned char *value = (unsigned char *)addr; + while (count) { + outb(*value, port); + value++; + count--; + } + } else { + asm volatile("rep; outsb" : "+S"(addr), "+c"(count) : "d"(port)); + } +} + +void insb_try_rep(int port, void *addr, unsigned long count) +{ + if (sev_active()) { + unsigned char *value = (unsigned char *)addr; + while (count) { + *value = inb(port); + value++; + count--; + } + } else { + asm volatile("rep; insb" : "+D"(addr), "+c"(count) : "d"(port)); + } +} + +void outsw_try_rep(int port, const void *addr, unsigned long count) +{ + if (sev_active()) { + unsigned short *value = (unsigned short *)addr; + while (count) { + outw(*value, port); + value++; + count--; + } + } else { + asm volatile("rep; outsw" : "+S"(addr), "+c"(count) : "d"(port)); + } +} +void insw_try_rep(int port, void *addr, unsigned long count) +{ + if (sev_active()) { + unsigned short *value = (unsigned short *)addr; + while (count) { + *value = inw(port); + value++; + count--; + } + } else { + asm volatile("rep; insw" : "+D"(addr), "+c"(count) : "d"(port)); + } +} + +void outsl_try_rep(int port, const void *addr, unsigned long count) +{ + if (sev_active()) { + unsigned int *value = (unsigned int *)addr; + while (count) { + outl(*value, port); + value++; + count--; + } + } else { + asm volatile("rep; outsl" : "+S"(addr), "+c"(count) : "d"(port)); + } +} + +void insl_try_rep(int port, void *addr, unsigned long count) +{ + if (sev_active()) { + unsigned int *value = (unsigned int *)addr; + while (count) { + *value = inl(port); + value++; + count--; + } + } else { + asm volatile("rep; insl" : "+D"(addr), "+c"(count) : "d"(port)); + } +}
WARNING: multiple messages have this Message-ID (diff)
From: Brijesh Singh <brijesh.singh-5C7GfCeVMHo@public.gmane.org> To: Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>, David Laight <David.Laight-JxhZ9S5GRejQT0dZR+AlfA@public.gmane.org> Cc: brijesh.singh-5C7GfCeVMHo@public.gmane.org, "linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>, "x86-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org" <x86-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>, "linux-efi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <linux-efi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>, "linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org" <linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org>, "kvm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <kvm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>, "Fenghua Yu" <fenghua.yu-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>, "Matt Fleming" <matt-mF/unelCI9GS6iBeEJttW/XRex20P6io@public.gmane.org>, "David Howells" <dhowells-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>, "Paul Mackerras" <paulus-eUNUBHrolfbYtjvyW6yDsg@public.gmane.org>, "H . Peter Anvin" <hpa-YMNOUZJC4hwAvxtiuMwx3w@public.gmane.org>, "Christoph Lameter" <cl-vYTEC60ixJUAvxtiuMwx3w@public.gmane.org>, "Jonathan Corbet" <corbet-T1hC0tSOHrs@public.gmane.org>, "Radim Krcmár" <rkrcmar-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>, "Piotr Luc" <piotr.luc-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>, "Ingo Molnar" <mingo-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>, "Dave Airlie" <airlied-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>, "Borislav Petkov" <bp-l3A5Bk7waGM@public.gmane.org>, "Tom Lendacky" <thomas.lendacky-5C7GfCeVMHo@public.gmane.org> Subject: Re: [RFC Part1 PATCH v3 13/17] x86/io: Unroll string I/O when SEV is active Date: Wed, 26 Jul 2017 14:24:45 -0500 [thread overview] Message-ID: <ed6d4ce7-97a6-f664-d7d7-4ff48bc6f06a@amd.com> (raw) In-Reply-To: <CAK8P3a3h7JpmkW7W=HwqAuWWmro=ngj6HSeiiML_=T82x-FtZQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> Hi Arnd and David, On 07/26/2017 05:45 AM, Arnd Bergmann wrote: > On Tue, Jul 25, 2017 at 11:51 AM, David Laight <David.Laight-JxhZ9S5GRejQT0dZR+AlfA@public.gmane.org> wrote: >> From: Brijesh Singh >>> Sent: 24 July 2017 20:08 >>> From: Tom Lendacky <thomas.lendacky-5C7GfCeVMHo@public.gmane.org> >>> >>> Secure Encrypted Virtualization (SEV) does not support string I/O, so >>> unroll the string I/O operation into a loop operating on one element at >>> a time. >>> >>> Signed-off-by: Tom Lendacky <thomas.lendacky-5C7GfCeVMHo@public.gmane.org> >>> Signed-off-by: Brijesh Singh <brijesh.singh-5C7GfCeVMHo@public.gmane.org> >>> --- >>> arch/x86/include/asm/io.h | 26 ++++++++++++++++++++++---- >>> 1 file changed, 22 insertions(+), 4 deletions(-) >>> >>> diff --git a/arch/x86/include/asm/io.h b/arch/x86/include/asm/io.h >>> index e080a39..2f3c002 100644 >>> --- a/arch/x86/include/asm/io.h >>> +++ b/arch/x86/include/asm/io.h >>> @@ -327,14 +327,32 @@ static inline unsigned type in##bwl##_p(int port) \ >>> \ >>> static inline void outs##bwl(int port, const void *addr, unsigned long count) \ >>> { > > This will clash with a fix I did to add a "memory" clobber > for the traditional implementation, see > https://patchwork.kernel.org/patch/9854573/ > >> Is it even worth leaving these as inline functions? >> Given the speed of IO cycles it is unlikely that the cost of calling a real >> function will be significant. >> The code bloat reduction will be significant. > > I think the smallest code would be the original "rep insb" etc, which > should be smaller than a function call, unlike the loop. Then again, > there is a rather small number of affected device drivers, almost all > of them for ancient hardware that you won't even build in a 64-bit > x86 kernel, see the list below. The only user I found that is actually > still relevant is drivers/tty/hvc/hvc_xen.c, which uses it for the early > console. There are some indirect user of string I/O functions. The following functions defined in lib/iomap.c calls rep version of ins and outs. - ioread8_rep, ioread16_rep, ioread32_rep - iowrite8_rep, iowrite16_rep, iowrite32_rep I found that several drivers use above functions. Here is one approach to convert it into non-inline functions. In this approach, I have added a new file arch/x86/kernel/io.c which provides non rep version of string I/O routines. The file gets built and used only when AMD_MEM_ENCRYPT is enabled. On positive side, if we don't build kernel with AMD_MEM_ENCRYPT support then we use inline routines, when AMD_MEM_ENCRYPT is built then we make a function call. Inside the function we unroll only when SEV is active. Do you see any issue with this approach ? thanks diff --git a/arch/x86/include/asm/io.h b/arch/x86/include/asm/io.h index e080a39..104927d 100644 --- a/arch/x86/include/asm/io.h +++ b/arch/x86/include/asm/io.h @@ -323,8 +323,9 @@ static inline unsigned type in##bwl##_p(int port) \ unsigned type value = in##bwl(port); \ slow_down_io(); \ return value; \ -} \ - \ +} + +#define BUILDIO_REP(bwl, bw, type) \ static inline void outs##bwl(int port, const void *addr, unsigned long count) \ { \ asm volatile("rep; outs" #bwl \ @@ -335,12 +336,31 @@ static inline void ins##bwl(int port, void *addr, unsigned long count) \ { \ asm volatile("rep; ins" #bwl \ : "+D"(addr), "+c"(count) : "d"(port)); \ -} +} \ BUILDIO(b, b, char) BUILDIO(w, w, short) BUILDIO(l, , int) +#ifdef CONFIG_AMD_MEM_ENCRYPT +extern void outsb_try_rep(int port, const void *addr, unsigned long count); +extern void insb_try_rep(int port, void *addr, unsigned long count); +extern void outsw_try_rep(int port, const void *addr, unsigned long count); +extern void insw_try_rep(int port, void *addr, unsigned long count); +extern void outsl_try_rep(int port, const void *addr, unsigned long count); +extern void insl_try_rep(int port, void *addr, unsigned long count); +#define outsb outsb_try_rep +#define insb insb_try_rep +#define outsw outsw_try_rep +#define insw insw_try_rep +#define outsl outsl_try_rep +#define insl insl_try_rep +#else +BUILDIO_REP(b, b, char) +BUILDIO_REP(w, w, short) +BUILDIO_REP(l, , int) +#endif + extern void *xlate_dev_mem_ptr(phys_addr_t phys); extern void unxlate_dev_mem_ptr(phys_addr_t phys, void *addr); diff --git a/arch/x86/kernel/Makefile b/arch/x86/kernel/Makefile index a01892b..3b6e2a3 100644 --- a/arch/x86/kernel/Makefile +++ b/arch/x86/kernel/Makefile @@ -42,6 +42,7 @@ CFLAGS_irq.o := -I$(src)/../include/asm/trace obj-y := process_$(BITS).o signal.o obj-$(CONFIG_COMPAT) += signal_compat.o +obj-$(CONFIG_AMD_MEM_ENCRYPT) += io.o obj-y += traps.o irq.o irq_$(BITS).o dumpstack_$(BITS).o obj-y += time.o ioport.o dumpstack.o nmi.o obj-$(CONFIG_MODIFY_LDT_SYSCALL) += ldt.o diff --git a/arch/x86/kernel/io.c b/arch/x86/kernel/io.c new file mode 100644 index 0000000..f58afa9 --- /dev/null +++ b/arch/x86/kernel/io.c @@ -0,0 +1,87 @@ +#include <linux/types.h> +#include <linux/io.h> +#include <asm/io.h> + +void outsb_try_rep(int port, const void *addr, unsigned long count) +{ + if (sev_active()) { + unsigned char *value = (unsigned char *)addr; + while (count) { + outb(*value, port); + value++; + count--; + } + } else { + asm volatile("rep; outsb" : "+S"(addr), "+c"(count) : "d"(port)); + } +} + +void insb_try_rep(int port, void *addr, unsigned long count) +{ + if (sev_active()) { + unsigned char *value = (unsigned char *)addr; + while (count) { + *value = inb(port); + value++; + count--; + } + } else { + asm volatile("rep; insb" : "+D"(addr), "+c"(count) : "d"(port)); + } +} + +void outsw_try_rep(int port, const void *addr, unsigned long count) +{ + if (sev_active()) { + unsigned short *value = (unsigned short *)addr; + while (count) { + outw(*value, port); + value++; + count--; + } + } else { + asm volatile("rep; outsw" : "+S"(addr), "+c"(count) : "d"(port)); + } +} +void insw_try_rep(int port, void *addr, unsigned long count) +{ + if (sev_active()) { + unsigned short *value = (unsigned short *)addr; + while (count) { + *value = inw(port); + value++; + count--; + } + } else { + asm volatile("rep; insw" : "+D"(addr), "+c"(count) : "d"(port)); + } +} + +void outsl_try_rep(int port, const void *addr, unsigned long count) +{ + if (sev_active()) { + unsigned int *value = (unsigned int *)addr; + while (count) { + outl(*value, port); + value++; + count--; + } + } else { + asm volatile("rep; outsl" : "+S"(addr), "+c"(count) : "d"(port)); + } +} + +void insl_try_rep(int port, void *addr, unsigned long count) +{ + if (sev_active()) { + unsigned int *value = (unsigned int *)addr; + while (count) { + *value = inl(port); + value++; + count--; + } + } else { + asm volatile("rep; insl" : "+D"(addr), "+c"(count) : "d"(port)); + } +}
next prev parent reply other threads:[~2017-07-26 19:25 UTC|newest] Thread overview: 226+ messages / expand[flat|nested] mbox.gz Atom feed top 2017-07-24 19:07 [RFC Part1 PATCH v3 00/17] x86: Secure Encrypted Virtualization (AMD) Brijesh Singh 2017-07-24 19:07 ` Brijesh Singh 2017-07-24 19:07 ` Brijesh Singh 2017-07-24 19:07 ` [RFC Part1 PATCH v3 01/17] Documentation/x86: Add AMD Secure Encrypted Virtualization (SEV) descrption Brijesh Singh 2017-07-24 19:07 ` Brijesh Singh 2017-07-24 19:07 ` Brijesh Singh 2017-07-25 5:45 ` Borislav Petkov 2017-07-25 5:45 ` Borislav Petkov 2017-07-25 5:45 ` Borislav Petkov 2017-07-25 14:59 ` Brijesh Singh 2017-07-25 14:59 ` Brijesh Singh 2017-07-25 14:59 ` Brijesh Singh 2017-07-24 19:07 ` [RFC Part1 PATCH v3 02/17] x86/CPU/AMD: Add the Secure Encrypted Virtualization CPU feature Brijesh Singh 2017-07-24 19:07 ` Brijesh Singh 2017-07-24 19:07 ` Brijesh Singh 2017-07-25 10:26 ` Borislav Petkov 2017-07-25 10:26 ` Borislav Petkov 2017-07-25 10:26 ` Borislav Petkov 2017-07-25 14:29 ` Tom Lendacky 2017-07-25 14:29 ` Tom Lendacky 2017-07-25 14:29 ` Tom Lendacky 2017-07-25 14:36 ` Borislav Petkov 2017-07-25 14:36 ` Borislav Petkov 2017-07-25 14:36 ` Borislav Petkov 2017-07-25 14:58 ` Tom Lendacky 2017-07-25 14:58 ` Tom Lendacky 2017-07-25 14:58 ` Tom Lendacky 2017-07-25 15:13 ` Borislav Petkov 2017-07-25 15:13 ` Borislav Petkov 2017-07-25 15:13 ` Borislav Petkov 2017-07-25 15:29 ` Tom Lendacky 2017-07-25 15:29 ` Tom Lendacky 2017-07-25 15:29 ` Tom Lendacky 2017-07-25 15:33 ` Borislav Petkov 2017-07-25 15:33 ` Borislav Petkov 2017-07-25 15:33 ` Borislav Petkov 2017-08-09 18:17 ` Tom Lendacky 2017-08-09 18:17 ` Tom Lendacky 2017-08-17 8:12 ` Borislav Petkov 2017-08-17 8:12 ` Borislav Petkov 2017-08-17 8:12 ` Borislav Petkov 2017-07-24 19:07 ` [RFC Part1 PATCH v3 03/17] x86/mm: Secure Encrypted Virtualization (SEV) support Brijesh Singh 2017-07-24 19:07 ` Brijesh Singh 2017-07-24 19:07 ` Brijesh Singh 2017-07-26 4:28 ` Borislav Petkov 2017-07-26 4:28 ` Borislav Petkov 2017-07-26 4:28 ` Borislav Petkov 2017-07-26 16:47 ` Tom Lendacky 2017-07-26 16:47 ` Tom Lendacky 2017-07-26 16:47 ` Tom Lendacky 2017-07-27 13:39 ` Borislav Petkov 2017-07-27 13:39 ` Borislav Petkov 2017-07-27 13:39 ` Borislav Petkov 2017-07-24 19:07 ` [RFC Part1 PATCH v3 04/17] x86/mm: Don't attempt to encrypt initrd under SEV Brijesh Singh 2017-07-24 19:07 ` Brijesh Singh 2017-07-24 19:07 ` Brijesh Singh 2017-07-26 14:44 ` Borislav Petkov 2017-07-26 14:44 ` Borislav Petkov 2017-07-26 14:44 ` Borislav Petkov 2017-07-24 19:07 ` [RFC Part1 PATCH v3 05/17] x86, realmode: Don't decrypt trampoline area " Brijesh Singh 2017-07-24 19:07 ` Brijesh Singh 2017-07-24 19:07 ` Brijesh Singh 2017-07-26 16:03 ` Borislav Petkov 2017-07-26 16:03 ` Borislav Petkov 2017-07-26 16:03 ` Borislav Petkov 2017-08-10 13:03 ` Tom Lendacky 2017-08-10 13:03 ` Tom Lendacky 2017-08-10 13:03 ` Tom Lendacky 2017-07-24 19:07 ` [RFC Part1 PATCH v3 06/17] x86/mm: Use encrypted access of boot related data with SEV Brijesh Singh 2017-07-24 19:07 ` Brijesh Singh 2017-07-24 19:07 ` Brijesh Singh 2017-07-27 13:31 ` Borislav Petkov 2017-07-27 13:31 ` Borislav Petkov 2017-07-27 13:31 ` Borislav Petkov 2017-08-17 18:05 ` Tom Lendacky 2017-08-17 18:05 ` Tom Lendacky 2017-08-17 18:05 ` Tom Lendacky 2017-07-24 19:07 ` [RFC Part1 PATCH v3 07/17] x86/mm: Include SEV for encryption memory attribute changes Brijesh Singh 2017-07-24 19:07 ` Brijesh Singh 2017-07-24 19:07 ` Brijesh Singh 2017-07-27 14:58 ` Borislav Petkov 2017-07-27 14:58 ` Borislav Petkov 2017-07-27 14:58 ` Borislav Petkov 2017-07-28 8:47 ` David Laight 2017-07-28 8:47 ` David Laight 2017-07-28 8:47 ` David Laight 2017-08-17 18:21 ` Tom Lendacky 2017-08-17 18:21 ` Tom Lendacky 2017-08-17 18:10 ` Tom Lendacky 2017-08-17 18:10 ` Tom Lendacky 2017-08-17 18:10 ` Tom Lendacky 2017-07-24 19:07 ` [RFC Part1 PATCH v3 08/17] x86/efi: Access EFI data as encrypted when SEV is active Brijesh Singh 2017-07-24 19:07 ` Brijesh Singh 2017-07-24 19:07 ` Brijesh Singh 2017-07-28 10:31 ` Borislav Petkov 2017-07-28 10:31 ` Borislav Petkov 2017-07-28 10:31 ` Borislav Petkov 2017-08-17 18:42 ` Tom Lendacky 2017-08-17 18:42 ` Tom Lendacky 2017-08-17 18:42 ` Tom Lendacky 2017-07-24 19:07 ` [RFC Part1 PATCH v3 09/17] resource: Consolidate resource walking code Brijesh Singh 2017-07-24 19:07 ` Brijesh Singh 2017-07-24 19:07 ` Brijesh Singh 2017-07-28 15:23 ` Borislav Petkov 2017-07-28 15:23 ` Borislav Petkov 2017-07-28 15:23 ` Borislav Petkov 2017-08-17 18:55 ` Tom Lendacky 2017-08-17 18:55 ` Tom Lendacky 2017-08-17 18:55 ` Tom Lendacky 2017-08-17 19:03 ` Tom Lendacky 2017-08-17 19:03 ` Tom Lendacky 2017-08-17 19:03 ` Tom Lendacky 2017-07-24 19:07 ` [RFC Part1 PATCH v3 10/17] resource: Provide resource struct in resource walk callback Brijesh Singh 2017-07-24 19:07 ` Brijesh Singh 2017-07-24 19:07 ` Brijesh Singh 2017-07-31 8:26 ` Borislav Petkov 2017-07-31 8:26 ` Borislav Petkov 2017-07-31 8:26 ` Borislav Petkov 2017-07-31 22:19 ` Kees Cook 2017-07-31 22:19 ` Kees Cook 2017-07-31 22:19 ` Kees Cook 2017-07-24 19:07 ` [RFC Part1 PATCH v3 11/17] x86/mm, resource: Use PAGE_KERNEL protection for ioremap of memory pages Brijesh Singh 2017-07-24 19:07 ` Brijesh Singh 2017-07-24 19:07 ` Brijesh Singh 2017-08-02 4:02 ` Borislav Petkov 2017-08-02 4:02 ` Borislav Petkov 2017-08-02 4:02 ` Borislav Petkov 2017-08-17 19:22 ` Tom Lendacky 2017-08-17 19:22 ` Tom Lendacky 2017-08-17 19:22 ` Tom Lendacky 2017-07-24 19:07 ` [RFC Part1 PATCH v3 12/17] x86/mm: DMA support for SEV memory encryption Brijesh Singh 2017-07-24 19:07 ` Brijesh Singh 2017-07-24 19:07 ` Brijesh Singh 2017-08-07 3:48 ` Borislav Petkov 2017-08-07 3:48 ` Borislav Petkov 2017-08-07 3:48 ` Borislav Petkov 2017-08-17 19:35 ` Tom Lendacky 2017-08-17 19:35 ` Tom Lendacky 2017-08-17 19:35 ` Tom Lendacky 2017-07-24 19:07 ` [RFC Part1 PATCH v3 13/17] x86/io: Unroll string I/O when SEV is active Brijesh Singh 2017-07-24 19:07 ` Brijesh Singh 2017-07-24 19:07 ` Brijesh Singh 2017-07-25 9:51 ` David Laight 2017-07-25 9:51 ` David Laight 2017-07-25 9:51 ` David Laight 2017-07-26 10:45 ` Arnd Bergmann 2017-07-26 10:45 ` Arnd Bergmann 2017-07-26 19:24 ` Brijesh Singh [this message] 2017-07-26 19:24 ` Brijesh Singh 2017-07-26 19:26 ` H. Peter Anvin 2017-07-26 19:26 ` H. Peter Anvin 2017-07-26 19:26 ` H. Peter Anvin 2017-07-26 19:26 ` H. Peter Anvin 2017-07-26 20:07 ` Brijesh Singh 2017-07-26 20:07 ` Brijesh Singh 2017-07-27 7:45 ` David Laight 2017-07-27 7:45 ` David Laight 2017-07-27 7:45 ` David Laight 2017-08-22 16:52 ` Borislav Petkov 2017-08-22 16:52 ` Borislav Petkov 2017-09-15 12:24 ` Borislav Petkov 2017-09-15 12:24 ` Borislav Petkov 2017-09-15 14:13 ` Brijesh Singh 2017-09-15 14:13 ` Brijesh Singh 2017-09-15 14:40 ` Borislav Petkov 2017-09-15 14:40 ` Borislav Petkov 2017-09-15 14:48 ` Brijesh Singh 2017-09-15 14:48 ` Brijesh Singh 2017-09-15 16:22 ` Borislav Petkov 2017-09-15 16:22 ` Borislav Petkov 2017-09-15 16:27 ` Brijesh Singh 2017-09-15 16:27 ` Brijesh Singh 2017-07-24 19:07 ` [RFC Part1 PATCH v3 14/17] x86/boot: Add early boot support when running with SEV active Brijesh Singh 2017-07-24 19:07 ` Brijesh Singh 2017-07-24 19:07 ` Brijesh Singh 2017-08-23 15:30 ` Borislav Petkov 2017-08-23 15:30 ` Borislav Petkov 2017-08-23 15:30 ` Borislav Petkov 2017-08-24 18:54 ` Tom Lendacky 2017-08-24 18:54 ` Tom Lendacky 2017-08-24 18:54 ` Tom Lendacky 2017-08-25 12:54 ` Borislav Petkov 2017-08-25 12:54 ` Borislav Petkov 2017-08-25 12:54 ` Borislav Petkov 2017-07-24 19:07 ` [RFC Part1 PATCH v3 15/17] x86: Add support for changing memory encryption attribute in early boot Brijesh Singh 2017-07-24 19:07 ` Brijesh Singh 2017-07-24 19:07 ` Brijesh Singh 2017-08-28 10:51 ` Borislav Petkov 2017-08-28 10:51 ` Borislav Petkov 2017-08-28 10:51 ` Borislav Petkov 2017-08-28 11:49 ` Brijesh Singh 2017-08-28 11:49 ` Brijesh Singh 2017-08-28 11:49 ` Brijesh Singh 2017-07-24 19:07 ` [RFC Part1 PATCH v3 16/17] X86/KVM: Provide support to create Guest and HV shared per-CPU variables Brijesh Singh 2017-07-24 19:07 ` Brijesh Singh 2017-07-24 19:07 ` Brijesh Singh 2017-08-29 10:22 ` Borislav Petkov 2017-08-29 10:22 ` Borislav Petkov 2017-08-29 10:22 ` Borislav Petkov 2017-08-30 16:18 ` Brijesh Singh 2017-08-30 16:18 ` Brijesh Singh 2017-08-30 16:18 ` Brijesh Singh 2017-08-30 17:46 ` Borislav Petkov 2017-08-30 17:46 ` Borislav Petkov 2017-08-30 17:46 ` Borislav Petkov 2017-09-01 22:52 ` Brijesh Singh 2017-09-01 22:52 ` Brijesh Singh 2017-09-01 22:52 ` Brijesh Singh 2017-09-02 3:21 ` Andy Lutomirski 2017-09-02 3:21 ` Andy Lutomirski 2017-09-02 3:21 ` Andy Lutomirski 2017-09-03 2:34 ` Brijesh Singh 2017-09-03 2:34 ` Brijesh Singh 2017-09-03 2:34 ` Brijesh Singh 2017-09-04 17:05 ` Borislav Petkov 2017-09-04 17:05 ` Borislav Petkov 2017-09-04 17:05 ` Borislav Petkov 2017-09-04 17:47 ` Brijesh Singh 2017-09-04 17:47 ` Brijesh Singh 2017-09-04 17:47 ` Brijesh Singh 2017-07-24 19:07 ` [RFC Part1 PATCH v3 17/17] X86/KVM: Clear encryption attribute when SEV is active Brijesh Singh 2017-07-24 19:07 ` Brijesh Singh 2017-07-24 19:07 ` Brijesh Singh 2017-08-31 15:06 ` Borislav Petkov 2017-08-31 15:06 ` Borislav Petkov 2017-08-31 15:06 ` Borislav Petkov
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=ed6d4ce7-97a6-f664-d7d7-4ff48bc6f06a@amd.com \ --to=brijesh.singh@amd.com \ --cc=David.Laight@aculab.com \ --cc=airlied@redhat.com \ --cc=akpm@linux-foundation.org \ --cc=arbab@linux.vnet.ibm.com \ --cc=ard.biesheuvel@linaro.org \ --cc=arnd@arndb.de \ --cc=baolu.lu@linux.intel.com \ --cc=bp@suse.de \ --cc=cl@linux.com \ --cc=corbet@lwn.net \ --cc=dhowells@redhat.com \ --cc=ebiederm@xmission.com \ --cc=fenghua.yu@intel.com \ --cc=hpa@zytor.com \ --cc=keescook@chromium.org \ --cc=kirill.shutemov@linux.intel.com \ --cc=konrad.wilk@oracle.com \ --cc=kvm@vger.kernel.org \ --cc=labbott@redhat.com \ --cc=linux-efi@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linuxppc-dev@lists.ozlabs.org \ --cc=luto@kernel.org \ --cc=matt@codeblueprint.co.uk \ --cc=mingo@redhat.com \ --cc=paulus@samba.org \ --cc=pbonzini@redhat.com \ --cc=piotr.luc@intel.com \ --cc=rkrcmar@redhat.com \ --cc=tglx@linutronix.de \ --cc=thomas.lendacky@amd.com \ --cc=tj@kernel.org \ --cc=tony.luck@intel.com \ --cc=x86@kernel.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.