Re: [PATCH v2 01/11] crypto: introduce crypto wait for async op

On Mon, May 29, 2017 at 11:22:48AM +0300, Gilad Ben-Yossef wrote: > > +static inline int crypto_wait_req(int err, struct crypto_wait *wait) > +{ > + switch (err) { > + case -EINPROGRESS: > + case -EBUSY: > + wait_for_completion(>completion); > +

Re: [PATCH 1/3] mm: add vm_insert_mixed_mkwrite()

On Fri, Jun 9, 2017 at 8:03 PM, Ross Zwisler wrote: > On Fri, Jun 09, 2017 at 02:23:51PM -0700, Dan Williams wrote: >> On Wed, Jun 7, 2017 at 1:48 PM, Ross Zwisler >> wrote: >> > To be able to use the common 4k zero page in DAX we need

Re: [PATCH 1/3] mm: add vm_insert_mixed_mkwrite()

On Fri, Jun 09, 2017 at 02:23:51PM -0700, Dan Williams wrote: > On Wed, Jun 7, 2017 at 1:48 PM, Ross Zwisler > wrote: > > To be able to use the common 4k zero page in DAX we need to have our PTE > > fault path look more like our PMD fault path where a PTE entry can

Re: [PATCH 1/3] mm: add vm_insert_mixed_mkwrite()

On Wed, Jun 7, 2017 at 1:48 PM, Ross Zwisler wrote: > To be able to use the common 4k zero page in DAX we need to have our PTE > fault path look more like our PMD fault path where a PTE entry can be > marked as dirty and writeable as it is first inserted, rather than

Re: [PATCH v6 10/34] x86, x86/mm, x86/xen, olpc: Use __va() against just the physical address in cr3

On 6/9/2017 1:46 PM, Andy Lutomirski wrote: On Thu, Jun 8, 2017 at 3:38 PM, Tom Lendacky wrote: On 6/8/2017 1:05 AM, Andy Lutomirski wrote: On Wed, Jun 7, 2017 at 12:14 PM, Tom Lendacky wrote: The cr3 register entry can contain the SME

Re: [Xen-devel] [PATCH v6 10/34] x86, x86/mm, x86/xen, olpc: Use __va() against just the physical address in cr3

>> >> PV guests don't go through Linux x86 early boot code. They start at >> xen_start_kernel() (well, xen-head.S:startup_xen(), really) and merge >> with baremetal path at x86_64_start_reservations() (for 64-bit). >> > > Ok, I don't think anything needs to be done then. The sme_me_mask is set >

Re: [Xen-devel] [PATCH v6 10/34] x86, x86/mm, x86/xen, olpc: Use __va() against just the physical address in cr3

On 6/9/2017 1:43 PM, Boris Ostrovsky wrote: On 06/09/2017 02:36 PM, Tom Lendacky wrote: On 6/8/2017 5:01 PM, Andrew Cooper wrote: On 08/06/2017 22:17, Boris Ostrovsky wrote: On 06/08/2017 05:02 PM, Tom Lendacky wrote: On 6/8/2017 3:51 PM, Boris Ostrovsky wrote: What may be needed is making

Re: [Xen-devel] [PATCH v6 10/34] x86, x86/mm, x86/xen, olpc: Use __va() against just the physical address in cr3

On 09/06/17 19:43, Boris Ostrovsky wrote: > On 06/09/2017 02:36 PM, Tom Lendacky wrote: >>> basis, although (as far as I am aware) Xen as a whole would be able to >>> encompass itself and all of its PV guests inside one single SME >>> instance. >> Yes, that is correct. Thinking more about this,

Re: [PATCH v6 10/34] x86, x86/mm, x86/xen, olpc: Use __va() against just the physical address in cr3

On Thu, Jun 8, 2017 at 3:38 PM, Tom Lendacky wrote: > On 6/8/2017 1:05 AM, Andy Lutomirski wrote: >> >> On Wed, Jun 7, 2017 at 12:14 PM, Tom Lendacky >> wrote: >>> >>> The cr3 register entry can contain the SME encryption bit that indicates >>>

Re: [Xen-devel] [PATCH v6 10/34] x86, x86/mm, x86/xen, olpc: Use __va() against just the physical address in cr3

On 06/09/2017 02:36 PM, Tom Lendacky wrote: > On 6/8/2017 5:01 PM, Andrew Cooper wrote: >> On 08/06/2017 22:17, Boris Ostrovsky wrote: >>> On 06/08/2017 05:02 PM, Tom Lendacky wrote: On 6/8/2017 3:51 PM, Boris Ostrovsky wrote: >>> What may be needed is making sure X86_FEATURE_SME is not

Re: [Xen-devel] [PATCH v6 10/34] x86, x86/mm, x86/xen, olpc: Use __va() against just the physical address in cr3

On 6/8/2017 5:01 PM, Andrew Cooper wrote: On 08/06/2017 22:17, Boris Ostrovsky wrote: On 06/08/2017 05:02 PM, Tom Lendacky wrote: On 6/8/2017 3:51 PM, Boris Ostrovsky wrote: What may be needed is making sure X86_FEATURE_SME is not set for PV guests. And that may be something that Xen will

Re: [PATCH v6 06/34] x86/mm: Add Secure Memory Encryption (SME) support

On Wed, Jun 07, 2017 at 02:14:16PM -0500, Tom Lendacky wrote: > Add support for Secure Memory Encryption (SME). This initial support > provides a Kconfig entry to build the SME support into the kernel and > defines the memory encryption mask that will be used in subsequent > patches to mark pages

Re: [PATCH v6 05/34] x86/CPU/AMD: Handle SME reduction in physical address size

On Wed, Jun 07, 2017 at 02:14:04PM -0500, Tom Lendacky wrote: > When System Memory Encryption (SME) is enabled, the physical address > space is reduced. Adjust the x86_phys_bits value to reflect this > reduction. > > Signed-off-by: Tom Lendacky > --- >

Re: [PATCH] kbuild: replace genhdr-y with generated-y, deprecating genhdr-y

Le 09/06/2017 à 10:29, Masahiro Yamada a écrit : > Prior to commit fcc8487d477a ("uapi: export all headers under uapi > directories"), genhdr-y was meant to specify generated UAPI headers. > > - generated-y: generated headers (other than asm-generic wrappers) > - header-y : headers to be

Re: [PATCH 05/20] arm64: rename COMPAT to AARCH32_EL0 in Kconfig

On Fri, Jun 09, 2017 at 01:40:59AM +0300, Yury Norov wrote: > On Thu, Jun 08, 2017 at 03:09:12PM +0100, Catalin Marinas wrote: > > On Sun, Jun 04, 2017 at 02:59:54PM +0300, Yury Norov wrote: > > > --- a/arch/arm64/Kconfig > > > +++ b/arch/arm64/Kconfig > > > @@ -402,7 +402,7 @@ config

Re: [PATCH v6 04/34] x86/CPU/AMD: Add the Secure Memory Encryption CPU feature

On Wed, Jun 07, 2017 at 02:13:53PM -0500, Tom Lendacky wrote: > Update the CPU features to include identifying and reporting on the > Secure Memory Encryption (SME) feature. SME is identified by CPUID > 0x801f, but requires BIOS support to enable it (set bit 23 of > MSR_K8_SYSCFG). Only show

[PATCH] kbuild: replace genhdr-y with generated-y, deprecating genhdr-y

Prior to commit fcc8487d477a ("uapi: export all headers under uapi directories"), genhdr-y was meant to specify generated UAPI headers. - generated-y: generated headers (other than asm-generic wrappers) - header-y : headers to be exported - genhdr-y : generated headers to be exported

Re: [PATCH] kbuild: replace genhdr-y with generated-y, deprecating genhdr-y

2017-06-09 17:29 GMT+09:00 Masahiro Yamada : > Prior to commit fcc8487d477a ("uapi: export all headers under uapi > directories"), genhdr-y was meant to specify generated UAPI headers. > > - generated-y: generated headers (other than asm-generic wrappers) > -

Re: [PATCH 14/20] arm64: ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it

On Thu, Jun 08, 2017 at 04:05:36PM +0100, James Morse wrote: > Hi Yury, > > On 04/06/17 13:00, Yury Norov wrote: > > From: Andrew Pinski > > > > Add a separate syscall-table for ILP32, which dispatches either to native > > LP64 system call implementation or to