在 2018年09月25日 06:15, Bjorn Helgaas 写道:
> From: Bjorn Helgaas
>
> Previously find_next_iomem_res() used "*res" as both an input parameter for
> the range to search and the type of resource to search for, and an output
> parameter for the resource we found, which makes the interface confusing
> and
在 2018年09月27日 10:06, Baoquan He 写道:
> Hi Lianbo,
>
> On 09/26/18 at 05:34pm, lijiang wrote:
>> When SME is enabled on AMD machine, the memory is encrypted in the first
>> kernel. In this case, SME also needs to be enabled in kdump kernel, and
>> we have to remap the old memory with the memory encr
在 2018年09月25日 20:04, Joerg Roedel 写道:
> On Fri, Sep 07, 2018 at 04:18:04PM +0800, Lianbo Jiang wrote:
>> In kdump kernel, it will copy the device table of IOMMU from the old device
>> table, which is encrypted when SME is enabled in the first kernel. So we
>> have to remap the old device table with
Hi Lianbo,
On 09/26/18 at 05:34pm, lijiang wrote:
> When SME is enabled on AMD machine, the memory is encrypted in the first
> kernel. In this case, SME also needs to be enabled in kdump kernel, and
> we have to remap the old memory with the memory encryption mask.
>
> Here we only talk about the
On 9/26/2018 12:56 PM, Hari Bathini wrote:
> * Required for kernel 4.19
>
> With kernel commit 7d4340bb92a9 ("powerpc/mm: Increase MAX_PHYSMEM_BITS
> to 128TB with SPARSEMEM_VMEMMAP config"), MAX_PHYSMEM_BITS is bumped up
> to 47. Make the appropriate update here.
>
> Signed-off-by: Hari Bathini
On Thursday 27 September 2018 12:40 AM, Dave Anderson wrote:
- Original Message -
* Required for kernel 4.19
With kernel commit 7d4340bb92a9 ("powerpc/mm: Increase MAX_PHYSMEM_BITS
to 128TB with SPARSEMEM_VMEMMAP config"), MAX_PHYSMEM_BITS is bumped up
to 47. Make the appropriate upd
- Original Message -
>
> * Required for kernel 4.19
>
> With kernel commit 7d4340bb92a9 ("powerpc/mm: Increase MAX_PHYSMEM_BITS
> to 128TB with SPARSEMEM_VMEMMAP config"), MAX_PHYSMEM_BITS is bumped up
> to 47. Make the appropriate update here.
>
> Signed-off-by: Hari Bathini
> ---
>
* Required for kernel 4.19
With kernel commit 7d4340bb92a9 ("powerpc/mm: Increase MAX_PHYSMEM_BITS
to 128TB with SPARSEMEM_VMEMMAP config"), MAX_PHYSMEM_BITS is bumped up
to 47. Make the appropriate update here.
Signed-off-by: Hari Bathini
---
arch/ppc64.c |5 +
makedumpfile.h |1
在 2018年09月26日 17:22, lijiang 写道:
>
>
> 在 2018年09月25日 06:14, Bjorn Helgaas 写道:
>> Hi Lianbo,
>>
>> These three patches are a possible replacement for your first patch
>> ("[PATCH 1/3 v3] resource: fix an error which walks through iomem
>> resources").
>>
>> I think the interface of find_next_iomem
On 09/26/18 at 01:01pm, Lendacky, Thomas wrote:
> 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 ri
On Wed, Sep 26, 2018 at 01:01:00PM +, Lendacky, Thomas wrote:
> No concern from me. The original version of the patch did not cache the
> value, that was added based on the patch series feedback. So, if there
> is no concern about executing some extra CPUID/RDMSR instructions, then
> it would
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/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 and simply doing the whole dance of figuring ou
On Wed, Sep 26, 2018 at 3:33 PM 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 and simply doing the whole dance of
Am 20.9.2018 19:52, schrieb Jürgen Herrmann:
Hello!
I am trying to debug a hang in btrfs-send: I talked to the guys on the
linux-btrfs
mailing list and they need a kdump of the state when the hang happens.
I already set up kdump:
$ kdump-config show
DUMP_MODE:kdump
USE_KDUMP:1
K
When SME is enabled on AMD machine, the memory is encrypted in the first
kernel. In this case, SME also needs to be enabled in kdump kernel, and
we have to remap the old memory with the memory encryption mask.
Here we only talk about the case that SME is active in the first kernel,
and only care i
在 2018年09月25日 06:14, Bjorn Helgaas 写道:
> Hi Lianbo,
>
> These three patches are a possible replacement for your first patch
> ("[PATCH 1/3 v3] resource: fix an error which walks through iomem
> resources").
>
> I think the interface of find_next_iomem_res() can be improved to make
> the code ea
Hi Rob,
On 09/25/18 22:57, AKASHI Takahiro wrote:
> Frank,
>
> On Fri, Sep 14, 2018 at 10:19:38AM -0700, Frank Rowand wrote:
>> On 09/13/18 18:26, Frank Rowand wrote:
>>> I was re-reading this while answering a later email in the thread. After
>>> reading
>>> other patches in the series that we
On 09/05/18 at 10:02am, Thomas Gleixner wrote:
> On Tue, 4 Sep 2018, H. Peter Anvin wrote:
>
> > On 09/04/18 01:42, Kirill A. Shutemov wrote:
> > >
> > > Switching between 4- and 5-level paging modes (in either direction)
> > > requires paing disabling. It means the code that does the switching h
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 and simply doing the whole dance of figuring out the C-bit each
> time. It probably wouldn't be e
20 matches
Mail list logo
