From: Brijesh Singh <brijesh.singh@amd.com>
To: "H. Peter Anvin" <hpa@zytor.com>, 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>,
"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>
Subject: Re: [RFC Part1 PATCH v3 13/17] x86/io: Unroll string I/O when SEV is active
Date: Wed, 26 Jul 2017 15:07:14 -0500 [thread overview]
Message-ID: <589d65a4-eb09-bae9-e8b4-a2d78ca6b509@amd.com> (raw)
In-Reply-To: <201707261927.v6QJR228008075@mail.zytor.com>
On 07/26/2017 02:26 PM, H. Peter Anvin wrote:
>>>>>
>> \
>>>>> 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));
>> + }
>> +}
>
> What the heck?
>
I am not sure if I understand your concern.
Are you commenting on amount of code duplication ? If so, I can certainly improve
and use the similar macro used into header file to generate the functions body.
Are you commenting that we should not attempt to make those functions non-inline
and you prefer them to stay inline ?
thanks
WARNING: multiple messages have this Message-ID (diff)
From: Brijesh Singh <brijesh.singh@amd.com>
To: "H. Peter Anvin" <hpa@zytor.com>, 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>,
"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@zytor.com
Subject: Re: [RFC Part1 PATCH v3 13/17] x86/io: Unroll string I/O when SEV is active
Date: Wed, 26 Jul 2017 15:07:14 -0500 [thread overview]
Message-ID: <589d65a4-eb09-bae9-e8b4-a2d78ca6b509@amd.com> (raw)
In-Reply-To: <201707261927.v6QJR228008075@mail.zytor.com>
On 07/26/2017 02:26 PM, H. Peter Anvin wrote:
>>>>>
>> \
>>>>> 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));
>> + }
>> +}
>
> What the heck?
>
I am not sure if I understand your concern.
Are you commenting on amount of code duplication ? If so, I can certainly improve
and use the similar macro used into header file to generate the functions body.
Are you commenting that we should not attempt to make those functions non-inline
and you prefer them to stay inline ?
thanks
next prev parent reply other threads:[~2017-07-26 20:07 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
[not found] ` <20170724190757.11278-1-brijesh.singh-5C7GfCeVMHo@public.gmane.org>
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
[not found] ` <20170724190757.11278-2-brijesh.singh-5C7GfCeVMHo@public.gmane.org>
2017-07-25 5:45 ` Borislav Petkov
2017-07-25 5:45 ` Borislav Petkov
2017-07-25 5:45 ` Borislav Petkov
[not found] ` <20170725054522.GA21822-K5JNixvcfoxupOikMc4+xw@public.gmane.org>
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 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
[not found] ` <20170724190757.11278-6-brijesh.singh-5C7GfCeVMHo@public.gmane.org>
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 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
[not found] ` <20170728152342.GB11564-K5JNixvcfoxupOikMc4+xw@public.gmane.org>
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 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 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
[not found] ` <42cf82fc-03be-c4c7-eaab-b2306a049d20-5C7GfCeVMHo@public.gmane.org>
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 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
[not found] ` <20170724190757.11278-18-brijesh.singh-5C7GfCeVMHo@public.gmane.org>
2017-08-31 15:06 ` Borislav Petkov
2017-08-31 15:06 ` Borislav Petkov
2017-08-31 15:06 ` Borislav Petkov
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
[not found] ` <20170724190757.11278-3-brijesh.singh-5C7GfCeVMHo@public.gmane.org>
2017-07-25 10:26 ` Borislav Petkov
2017-07-25 10:26 ` Borislav Petkov
2017-07-25 10:26 ` Borislav Petkov
[not found] ` <20170725102657.GD21822-K5JNixvcfoxupOikMc4+xw@public.gmane.org>
2017-07-25 14:29 ` Tom Lendacky
2017-07-25 14:29 ` Tom Lendacky
2017-07-25 14:29 ` Tom Lendacky
[not found] ` <7236d267-ebcb-8b45-b8d3-5955903e395f-5C7GfCeVMHo@public.gmane.org>
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
[not found] ` <20170724190757.11278-4-brijesh.singh-5C7GfCeVMHo@public.gmane.org>
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
[not found] ` <facf3ac6-ebda-57a7-f961-6029b3ac7be7-5C7GfCeVMHo@public.gmane.org>
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 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
[not found] ` <20170724190757.11278-8-brijesh.singh-5C7GfCeVMHo@public.gmane.org>
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
[not found] ` <063D6719AE5E284EB5DD2968C1650D6DD0045508-VkEWCZq2GCInGFn1LkZF6NBPR1lH4CV8@public.gmane.org>
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
[not found] ` <20170724190757.11278-9-brijesh.singh-5C7GfCeVMHo@public.gmane.org>
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 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
[not found] ` <20170724190757.11278-12-brijesh.singh-5C7GfCeVMHo@public.gmane.org>
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 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
[not found] ` <CAK8P3a3h7JpmkW7W=HwqAuWWmro=ngj6HSeiiML_=T82x-FtZQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-07-26 19:24 ` Brijesh Singh
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 [this message]
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
[not found] ` <589d65a4-eb09-bae9-e8b4-a2d78ca6b509-5C7GfCeVMHo@public.gmane.org>
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
[not found] ` <ad628a45-8e4e-9cfc-2cc4-33dc6bf4613a-5C7GfCeVMHo@public.gmane.org>
2017-09-15 16:22 ` Borislav Petkov
2017-09-15 16:22 ` Borislav Petkov
[not found] ` <20170915162256.7l4vyy4ee5zeqbir-fF5Pk5pvG8Y@public.gmane.org>
2017-09-15 16:27 ` Brijesh Singh
2017-09-15 16:27 ` Brijesh Singh
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
[not found] ` <CALCETrV+rv=9Rg5V1z8vHtVDW64eCNtZHQMW8DipRADvm+qP5A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-09-03 2:34 ` Brijesh Singh
2017-09-03 2:34 ` Brijesh Singh
2017-09-03 2:34 ` Brijesh Singh
[not found] ` <8155b5b2-b2b3-bc8f-33ae-b81b661a2e38-5C7GfCeVMHo@public.gmane.org>
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
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=589d65a4-eb09-bae9-e8b4-a2d78ca6b509@amd.com \
--to=brijesh.singh@amd.com \
--cc=David.Laight@aculab.com \
--cc=airlied@redhat.com \
--cc=arnd@arndb.de \
--cc=bp@suse.de \
--cc=cl@linux.com \
--cc=corbet@lwn.net \
--cc=dhowells@redhat.com \
--cc=fenghua.yu@intel.com \
--cc=hpa@zytor.com \
--cc=keescook@chromium.org \
--cc=kvm@vger.kernel.org \
--cc=linux-efi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=matt@codeblueprint.co.uk \
--cc=mingo@redhat.com \
--cc=paulus@samba.org \
--cc=piotr.luc@intel.com \
--cc=rkrcmar@redhat.com \
--cc=thomas.lendacky@amd.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: link
Be 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.