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
>>
>> 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: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
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 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 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 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 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
Hi all,
I am happy to announce the release of kexec-tools 2.0.15-rc1.
This is an incremental feature pre-release.
So long as no serious problems arise I intend to release kexec-tools 2.0.15
in a weeks time. Testing of 2.0.15-rc1 would be greatly appreciated.
I do not have any outstanding change
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: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 06/09/17 at 10:29am, Dave Young wrote:
> On 06/09/17 at 10:17am, Xunlei Pang wrote:
> > S390 KEXEC_NOTE_BYTES is not used by note_buf_t as before, which
> > is now defined as follows:
> > typedef u32 note_buf_t[CRASH_CORE_NOTE_BYTES/4];
> > It was changed by the CONFIG_CRASH_CORE feature.
>
12 matches
Mail list logo
