Re: [RFC Part1 PATCH v3 01/17] Documentation/x86: Add AMD Secure Encrypted Virtualization (SEV) descrption

On Mon, Jul 24, 2017 at 02:07:41PM -0500, Brijesh Singh wrote: Subject: Re: [RFC Part1 PATCH v3 01/17] Documentation/x86: Add AMD Secure Encrypted Virtualization (SEV) descrption ^^

[RFC Part1 PATCH v3 13/17] x86/io: Unroll string I/O when SEV is active

From: Tom Lendacky 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 Signed-off-by: Brijesh Singh

[RFC Part1 PATCH v3 14/17] x86/boot: Add early boot support when running with SEV active

From: Tom Lendacky Early in the boot process, add checks to determine if the kernel is running with Secure Encrypted Virtualization (SEV) active. Checking for SEV requires checking that the kernel is running under a hypervisor (CPUID 0x0001, bit 31), that the SEV

[RFC Part1 PATCH v3 17/17] X86/KVM: Clear encryption attribute when SEV is active

The guest physical memory area holding the struct pvclock_wall_clock and struct pvclock_vcpu_time_info are shared with the hypervisor. Hypervisor periodically updates the contents of the memory. When SEV is active, we must clear the encryption attributes from the shared memory pages so that both

[RFC Part1 PATCH v3 15/17] x86: Add support for changing memory encryption attribute in early boot

Some KVM-specific custom MSRs shares the guest physical address with hypervisor. When SEV is active, the shared physical address must be mapped with encryption attribute cleared so that both hypervsior and guest can access the data. Add APIs to change memory encryption attribute in early boot

[RFC Part1 PATCH v3 16/17] X86/KVM: Provide support to create Guest and HV shared per-CPU variables

Some KVM specific MSR's (steal-time, asyncpf, avic_eio) allocates per-CPU variable at compile time and share its physical address with hypervisor. It presents a challege when SEV is active in guest OS, when SEV is active, the guest memory is encrypted with guest key hence hypervisor will not able

[RFC Part1 PATCH v3 11/17] x86/mm, resource: Use PAGE_KERNEL protection for ioremap of memory pages

From: Tom Lendacky In order for memory pages to be properly mapped when SEV is active, we need to use the PAGE_KERNEL protection attribute as the base protection. This will insure that memory mapping of, e.g. ACPI tables, receives the proper mapping attributes.

[RFC Part1 PATCH v3 10/17] resource: Provide resource struct in resource walk callback

From: Tom Lendacky In prep for a new function that will need additional resource information during the resource walk, update the resource walk callback to pass the resource structure. Since the current callback start and end arguments are pulled from the resource

[RFC Part1 PATCH v3 09/17] resource: Consolidate resource walking code

From: Tom Lendacky The walk_iomem_res_desc(), walk_system_ram_res() and walk_system_ram_range() functions each have much of the same code. Create a new function that consolidates the common code from these functions in one place to reduce the amount of duplicated code.

[RFC Part1 PATCH v3 05/17] x86, realmode: Don't decrypt trampoline area under SEV

From: Tom Lendacky When SEV is active the trampoline area will need to be in encrypted memory so only mark the area decrypted if SME is active. Signed-off-by: Tom Lendacky Signed-off-by: Brijesh Singh ---

[RFC Part1 PATCH v3 06/17] x86/mm: Use encrypted access of boot related data with SEV

From: Tom Lendacky When Secure Encrypted Virtualization (SEV) is active, boot data (such as EFI related data, setup data) is encrypted and needs to be accessed as such when mapped. Update the architecture override in early_memremap to keep the encryption attribute when

[RFC Part1 PATCH v3 07/17] x86/mm: Include SEV for encryption memory attribute changes

From: Tom Lendacky The current code checks only for sme_active() when determining whether to perform the encryption attribute change. Include sev_active() in this check so that memory attribute changes can occur under SME and SEV. Signed-off-by: Tom Lendacky

[RFC Part1 PATCH v3 08/17] x86/efi: Access EFI data as encrypted when SEV is active

From: Tom Lendacky EFI data is encrypted when the kernel is run under SEV. Update the page table references to be sure the EFI memory areas are accessed encrypted. Signed-off-by: Tom Lendacky Signed-off-by: Brijesh Singh

[RFC Part1 PATCH v3 02/17] x86/CPU/AMD: Add the Secure Encrypted Virtualization CPU feature

From: Tom Lendacky Update the CPU features to include identifying and reporting on the Secure Encrypted Virtualization (SEV) feature. SME is identified by CPUID 0x801f, but requires BIOS support to enable it (set bit 23 of MSR_K8_SYSCFG and set bit 0 of

[RFC Part1 PATCH v3 04/17] x86/mm: Don't attempt to encrypt initrd under SEV

From: Tom Lendacky When SEV is active the initrd/initramfs will already have already been placed in memory encyrpted so do not try to encrypt it. Signed-off-by: Tom Lendacky Signed-off-by: Brijesh Singh ---

[RFC Part1 PATCH v3 03/17] x86/mm: Secure Encrypted Virtualization (SEV) support

From: Tom Lendacky Provide support for Secure Encyrpted Virtualization (SEV). This initial support defines a flag that is used by the kernel to determine if it is running with SEV active. Signed-off-by: Tom Lendacky Signed-off-by: Brijesh Singh

[RFC Part1 PATCH v3 01/17] Documentation/x86: Add AMD Secure Encrypted Virtualization (SEV) descrption

Update amd-memory-encryption document describing the AMD Secure Encrypted Virtualization (SEV) feature. Signed-off-by: Brijesh Singh --- Documentation/x86/amd-memory-encryption.txt | 29 ++--- 1 file changed, 26 insertions(+), 3 deletions(-) diff

[RFC Part1 PATCH v3 00/17] x86: Secure Encrypted Virtualization (AMD)

This part of Secure Encrypted Virtualization (SEV) series focuses on the changes required in a guest OS for SEV support. When SEV is active, the memory content of guest OS will be transparently encrypted with a key unique to the guest VM. SEV guests have concept of private and shared memory.

Re: [PATCH v1 5/6] uuid: Kill uapi/uuid.h

> diff --git a/scripts/mod/file2alias.c b/scripts/mod/file2alias.c > index 29d6699d5a06..1c68709123aa 100644 > --- a/scripts/mod/file2alias.c > +++ b/scripts/mod/file2alias.c > @@ -36,7 +36,7 @@ typedef uint16_t__u16; > typedef unsigned char__u8; > typedef struct { > __u8

Re: [PATCH v1 4/6] vmbus: Switch to use new generic UUID API

On Wed, Jul 19, 2017 at 09:28:55PM +0300, Andy Shevchenko wrote: > There are new types and helpers that are supposed to be used in new code. > > As a preparation to get rid of legacy types and API functions do > the conversion here. Can you split the uapi changes into a separate patch? I'd love