search for: set_memori

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

This is the first step towards separating the APIs from the means by which they are carried between the remote and local system. Added a few new classes and types: * HostTransport - defines a type for talking to the Host * Host - the public contract for the host APIs * HostAgent - the QMF transport layer Signed-off-by: Darryl L. Pierce <dpierce at redhat.com> --- .gitignore

On Fri, Apr 26, 2019 at 08:32:39PM +0200, Halil Pasic wrote: > +EXPORT_SYMBOL_GPL(set_memory_encrypted); > +EXPORT_SYMBOL_GPL(set_memory_decrypted); > +EXPORT_SYMBOL_GPL(sev_active); Why do you export these? I know x86 exports those as well, but it shoudn't be needed there either.

On 29.04.19 15:59, Halil Pasic wrote: > On Fri, 26 Apr 2019 12:27:11 -0700 > Christoph Hellwig <hch at infradead.org> wrote: > >> On Fri, Apr 26, 2019 at 08:32:39PM +0200, Halil Pasic wrote: >>> +EXPORT_SYMBOL_GPL(set_memory_encrypted); >> >>> +EXPORT_SYMBOL_GPL(set_memory_decrypted); >> >>> +EXPORT_SYMBOL_GPL(sev_active); >>

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 Fri, Apr 26, 2019 at 08:32:39PM +0200, Halil Pasic wrote: > +EXPORT_SYMBOL_GPL(set_memory_encrypted); > +EXPORT_SYMBOL_GPL(set_memory_decrypted); > +EXPORT_SYMBOL_GPL(sev_active); Why do you export these? I know x86 exports those as well, but it shoudn't be needed there either.

Replaced the previous HostWrapper class with the new HostAgent class, which more closely resembles the style of the ProcessorsAgent class. Deleted the HostWrapper class entirely. Refactored the daemon entry point to reduce the number of methods invoked in order to start or stop the HostAgent instance. Moved the NICWrapper's setupQMFObject method from private to public so that it can be

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 Fri, 26 Apr 2019 12:27:11 -0700 Christoph Hellwig <hch at infradead.org> wrote: > On Fri, Apr 26, 2019 at 08:32:39PM +0200, Halil Pasic wrote: > > +EXPORT_SYMBOL_GPL(set_memory_encrypted); > > > +EXPORT_SYMBOL_GPL(set_memory_decrypted); > > > +EXPORT_SYMBOL_GPL(sev_active); > > Why do you export these? I know x86 exports those as well, but > it

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?

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 Wed, Apr 22, 2020 at 06:33:13PM -0700, Bo Gan wrote: > On 4/15/20 8:53 AM, Joerg Roedel wrote: > > 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

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

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