similar to: [PATCH 40/70] x86/sev-es: Setup per-cpu GHCBs for the runtime handler

On 4/14/20 2:03 PM, Mike Stunes wrote: > On Mar 19, 2020, at 2:13 AM, Joerg Roedel <joro at 8bytes.org> wrote: >> >> From: Tom Lendacky <thomas.lendacky at amd.com> >> >> The runtime handler needs a GHCB per CPU. Set them up and map them >> unencrypted. >> >> Signed-off-by: Tom Lendacky <thomas.lendacky at amd.com> >>

On 4/14/20 2:03 PM, Mike Stunes wrote: > On Mar 19, 2020, at 2:13 AM, Joerg Roedel <joro at 8bytes.org> wrote: >> >> From: Tom Lendacky <thomas.lendacky at amd.com> >> >> The runtime handler needs a GHCB per CPU. Set them up and map them >> unencrypted. >> >> Signed-off-by: Tom Lendacky <thomas.lendacky at amd.com> >>

Hi Mike, On Tue, Apr 14, 2020 at 07:03:44PM +0000, Mike Stunes wrote: > set_memory_decrypted needs to check the return value. I see it > consistently return ENOMEM. I've traced that back to split_large_page > in arch/x86/mm/pat/set_memory.c. I agree that the return code needs to be checked. But I wonder why this happens. The split_large_page() function returns -ENOMEM when

On 4/14/20 3:12 PM, Dave Hansen wrote: > On 4/14/20 1:04 PM, Tom Lendacky wrote: >>> set_memory_decrypted needs to check the return value. I see it >>> consistently return ENOMEM. I've traced that back to split_large_page >>> in arch/x86/mm/pat/set_memory.c. >> >> At that point the guest won't be able to communicate with the >> hypervisor,

On 4/14/20 1:04 PM, Tom Lendacky wrote: >> set_memory_decrypted needs to check the return value. I see it >> consistently return ENOMEM. I've traced that back to split_large_page >> in arch/x86/mm/pat/set_memory.c. > > At that point the guest won't be able to communicate with the > hypervisor, too. Maybe we should BUG() here to terminate further > processing?

From: Tom Lendacky <thomas.lendacky at amd.com> The runtime handler needs a GHCB per CPU. Set them up and map them unencrypted. Signed-off-by: Tom Lendacky <thomas.lendacky at amd.com> Signed-off-by: Joerg Roedel <jroedel at suse.de> --- arch/x86/include/asm/mem_encrypt.h | 2 ++ arch/x86/kernel/sev-es.c | 25 ++++++++++++++++++++++++- arch/x86/kernel/traps.c

On s390, protected virtualization guests have to use bounced I/O buffers. That requires some plumbing. Let us make sure, any device that uses DMA API with direct ops correctly is spared from the problems, that a hypervisor attempting I/O to a non-shared page would bring. Signed-off-by: Halil Pasic <pasic at linux.ibm.com> --- arch/s390/Kconfig | 4 +++

On Wed, 8 May 2019 15:15:40 +0200 Claudio Imbrenda <imbrenda at linux.ibm.com> wrote: > On Fri, 26 Apr 2019 20:32:39 +0200 > Halil Pasic <pasic at linux.ibm.com> wrote: > > > On s390, protected virtualization guests have to use bounced I/O > > buffers. That requires some plumbing. > > > > Let us make sure, any device that uses DMA API with direct

> Subject: [PATCH 04/10] s390/mm: force swiotlb for protected virtualization > Date: Fri, 26 Apr 2019 20:32:39 +0200 > From: Halil Pasic <pasic at linux.ibm.com> > To: kvm at vger.kernel.org, linux-s390 at vger.kernel.org, Cornelia Huck <cohuck at redhat.com>, > Martin Schwidefsky <schwidefsky at de.ibm.com>, Sebastian Ott <sebott at linux.ibm.com> > CC:

On Fri, 5 Apr 2019 01:16:13 +0200 Halil Pasic <pasic at linux.ibm.com> wrote: > On s390 protected virtualization guests also have to use bounce I/O > buffers. That requires some plumbing. > > Let us make sure any device using DMA API accordingly is spared from the > problems that hypervisor attempting I/O to a non-shared secure page would > bring. I have problems

On s390, protected virtualization guests have to use bounced I/O buffers. That requires some plumbing. Let us make sure, any device that uses DMA API with direct ops correctly is spared from the problems, that a hypervisor attempting I/O to a non-shared page would bring. Signed-off-by: Halil Pasic <pasic at linux.ibm.com> Reviewed-by: Claudio Imbrenda <imbrenda at linux.ibm.com> ---

On s390, protected virtualization guests have to use bounced I/O buffers. That requires some plumbing. Let us make sure, any device that uses DMA API with direct ops correctly is spared from the problems, that a hypervisor attempting I/O to a non-shared page would bring. Signed-off-by: Halil Pasic <pasic at linux.ibm.com> Reviewed-by: Claudio Imbrenda <imbrenda at linux.ibm.com> ---

From: Halil Pasic <pasic at linux.ibm.com> On s390, protected virtualization guests have to use bounced I/O buffers. That requires some plumbing. Let us make sure, any device that uses DMA API with direct ops correctly is spared from the problems, that a hypervisor attempting I/O to a non-shared page would bring. Signed-off-by: Halil Pasic <pasic at linux.ibm.com> Reviewed-by:

From: Halil Pasic <pasic at linux.ibm.com> On s390, protected virtualization guests have to use bounced I/O buffers. That requires some plumbing. Let us make sure, any device that uses DMA API with direct ops correctly is spared from the problems, that a hypervisor attempting I/O to a non-shared page would bring. Signed-off-by: Halil Pasic <pasic at linux.ibm.com> Reviewed-by:

On Tue, 9 Apr 2019 12:54:16 +0200 Halil Pasic <pasic at linux.ibm.com> wrote: > On Tue, 9 Apr 2019 12:16:47 +0200 > Cornelia Huck <cohuck at redhat.com> wrote: > > > On Fri, 5 Apr 2019 01:16:13 +0200 > > Halil Pasic <pasic at linux.ibm.com> wrote: > > > > > On s390 protected virtualization guests also have to use bounce I/O > > >

On Fri, 26 Apr 2019 20:32:39 +0200 Halil Pasic <pasic at linux.ibm.com> wrote: > On s390, protected virtualization guests have to use bounced I/O > buffers. That requires some plumbing. > > Let us make sure, any device that uses DMA API with direct ops > correctly is spared from the problems, that a hypervisor attempting > I/O to a non-shared page would bring. > >

On Fri, 26 Apr 2019 20:32:39 +0200 Halil Pasic <pasic at linux.ibm.com> wrote: > On s390, protected virtualization guests have to use bounced I/O > buffers. That requires some plumbing. > > Let us make sure, any device that uses DMA API with direct ops > correctly is spared from the problems, that a hypervisor attempting > I/O to a non-shared page would bring. > >

On Tue, Feb 11, 2020 at 5:53 AM Joerg Roedel <joro at 8bytes.org> wrote: > > From: Tom Lendacky <thomas.lendacky at amd.com> > > The runtime handler needs a GHCB per CPU. Set them up and map them > unencrypted. > > Signed-off-by: Tom Lendacky <thomas.lendacky at amd.com> > Signed-off-by: Joerg Roedel <jroedel at suse.de> > --- >

From: Tom Lendacky <thomas.lendacky at amd.com> The runtime handler needs a GHCB per CPU. Set them up and map them unencrypted. Signed-off-by: Tom Lendacky <thomas.lendacky at amd.com> Signed-off-by: Joerg Roedel <jroedel at suse.de> --- arch/x86/include/asm/mem_encrypt.h | 2 ++ arch/x86/kernel/sev-es.c | 56 +++++++++++++++++++++++++++++- arch/x86/kernel/traps.c

From: Tom Lendacky <thomas.lendacky at amd.com> The runtime handler needs a GHCB per CPU. Set them up and map them unencrypted. Signed-off-by: Tom Lendacky <thomas.lendacky at amd.com> Signed-off-by: Joerg Roedel <jroedel at suse.de> --- arch/x86/include/asm/mem_encrypt.h | 2 ++ arch/x86/kernel/sev-es.c | 56 +++++++++++++++++++++++++++++- arch/x86/kernel/traps.c