On 8/25/19 11:45 PM, Kairui Song wrote:
> Since commit c7753208a94c ("x86, swiotlb: Add memory encryption support"),
> SWIOTLB will be enabled even if there is less than 4G of memory when SME
> is active, to support DMA of devices that not support address with the
> encrypt bit.
>
> And commit aba
On 8/21/19 9:53 PM, Kairui Song wrote:
> Since commit c7753208a94c ("x86, swiotlb: Add memory encryption support"),
> SWIOTLB will be enabled even if there is less than 4G of memory when SME
> is active, to support DMA of devices that not support address with the
> encrypt bit.
>
> And commit aba2
On 8/1/19 8:05 PM, Dave Young wrote:
> Add kexec cc list.
> On 08/01/19 at 11:02pm, lijiang wrote:
>> Hi, Tom
>>
>> Recently, i ran into a problem about SME and used crash tool to check the
>> vmcore as follow:
>>
>> crash> kmem -s | grep -i invalid
>> kmem: dma-kmalloc-512: slab: e192c0001000
On 6/12/19 1:07 PM, Borislav Petkov wrote:
> On Wed, Jun 12, 2019 at 04:52:22PM +0000, Lendacky, Thomas wrote:
>> I think the discussion ended up being that debuginfo wasn't being stripped
>> from the kernel and initrd (mainly the initrd). What are the sizes of
>> the
On 6/12/19 10:10 AM, Borislav Petkov wrote:
> On Wed, Jun 12, 2019 at 09:55:49AM +0800, Baoquan He wrote:
>> With further investigation, the failure after applying Tom's patch is
>> caused by OOM. When increase crashkernel reservation to 512M, kdump
>> kernel can boot successfully. I noticed your c
On 6/4/19 7:56 PM, Baoquan He wrote:
> On 06/04/19 at 03:56pm, Lendacky, Thomas wrote:
>> On 6/4/19 8:49 AM, Baoquan He wrote:
>>> Hi Tom,
>>>
>>> Lianbo reported kdump kernel can't boot well with 'nokaslr' added, and
>>> have to ena
On 6/4/19 8:49 AM, Baoquan He wrote:
> Hi Tom,
>
> Lianbo reported kdump kernel can't boot well with 'nokaslr' added, and
> have to enable KASLR in kdump kernel to make it boot successfully. This
> blocked his work on enabling sme for kexec/kdump. And on some machines
> SME kernel can't boot in 1s
On 4/18/19 5:01 AM, Borislav Petkov wrote:
> On Wed, Apr 17, 2019 at 02:40:09PM +0800, lijiang wrote:
>> Based on the above description, i made a draft patch, please refer to it.
>> But it
>> seems that the code has been changed a lot.
>
> It goes in the right direction. Here is a version where I
On 3/25/19 1:17 PM, Singh, Brijesh wrote:
>
>
> On 3/25/19 12:32 PM, Borislav Petkov wrote:
>> On Mon, Mar 25, 2019 at 05:17:55PM +, Singh, Brijesh wrote:
>>> By default all the memory regions are mapped encrypted. The
>>> set_memory_{encrypt,decrypt}() is a generic function which can be
>>>
On 3/16/19 2:31 AM, lijiang wrote:
>
>
> 在 2018年12月05日 05:33, Lendacky, Thomas 写道:
>> On 11/29/2018 09:37 PM, Dave Young wrote:
>>> + more people
>>>
>>> On 11/29/18 at 04:09pm, Lianbo Jiang wrote:
>>>> When doing kexec_file_load, the first
On 1/28/19 1:45 PM, Kazuhito Hagio wrote:
> On 1/28/2019 9:24 AM, Lendacky, Thomas wrote:
>> On 1/27/19 11:46 PM, Lianbo Jiang wrote:
>>> For AMD machine with SME feature, if SME is enabled in the first
>>> kernel, the crashed kernel's page table(pgd/pud/pmd/pte) co
On 1/27/19 11:46 PM, Lianbo Jiang wrote:
> For AMD machine with SME feature, if SME is enabled in the first
> kernel, the crashed kernel's page table(pgd/pud/pmd/pte) contains
> the memory encryption mask, so makedumpfile needs to remove the
> memory encryption mask to obtain the true physical addr
On 1/24/19 9:55 PM, dyo...@redhat.com wrote:
> + Tom
> On 01/25/19 at 11:06am, lijiang wrote:
>> 在 2019年01月24日 06:16, Kazuhito Hagio 写道:
>>> On 1/22/2019 3:03 AM, Lianbo Jiang wrote:
For AMD machine with SME feature, if SME is enabled in the first
kernel, the crashed kernel's page table(p
On 11/29/2018 09:37 PM, Dave Young wrote:
> + more people
>
> On 11/29/18 at 04:09pm, Lianbo Jiang wrote:
>> When doing kexec_file_load, the first kernel needs to pass the e820
>> reserved ranges to the second kernel. But kernel can not exactly
>> match the e820 reserved ranges when walking throug
On 09/27/2018 07:38 AM, Kairui Song wrote:
> Commit 1958b5fc4010 ("x86/boot: Add early boot support when running
> with SEV active") is causing kexec becomes sometimes unstable even if
> SEV is not active. kexec reboot won't start a second kernel bypassing
> BIOS boot process, instead, the system g
On 09/26/2018 06:22 AM, Baoquan He wrote:
> On 09/26/18 at 03:32pm, Baoquan He wrote:
>> On 09/25/18 at 07:26pm, Borislav Petkov wrote:
>>> IINM, the problem can be addressed in a simpler way by getting rid of
>>> enc_bit and thus getting rid of the need to do relative addressing of
>>> anything an
On 09/07/2018 03:18 AM, Lianbo Jiang wrote:
> When SME is enabled on AMD machine, we also need to support kdump. Because
> the memory is encrypted in the first kernel, we will remap the old memory
> to the kdump kernel for dumping data, and SME is also enabled in the kdump
> kernel, otherwise the o
On 09/25/2018 06:10 AM, Kairui Song wrote:
> Commit 1958b5fc4010 ("x86/boot: Add early boot support when running
> with SEV active") is causing kexec becomes sometimes unstable, kexec
> reboot won't start a second kernel bypassing BIOS boot process, instead,
> the system got reset.
>
> That's beca
18 matches
Mail list logo
