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 compat-syscalls, as appropriate.
>
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)
> - header-y : headers to be exported
> -
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 (generate
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
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 ARM64_ERRATUM
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 exporte
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
> ---
> arch/x86/kernel/cpu/amd.c | 10 +++---
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 a
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 nee
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 se
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
>>> the PGD is encrypted. The encryption bit should not
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, it
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 s
>>
>> 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
>
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 encryption bit that indicates
the PGD is encrypted. T
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 waiting
> for a follow-up dax_
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 be
> > marked as dirty and write
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 to have our PTE
>> > fault path look more like our PMD fault
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(&wait->completion);
> + reinit_comp
19 matches
Mail list logo
