Re: [PATCH v7 00/12] Fix kdump faults on system with amd iommu

2016-12-23 Thread Baoquan He
Hi Joerg,

Ping!

Could you help review this version? Not sure this could catch up to
v4.10 merging.

Thanks
Baoqaun

On 11/25/16 at 01:13pm, Baoquan He wrote:
> This is v7 post.
> 
> The principle of the fix is similar to intel iommu. Just defer the assignment
> of device to domain to device driver init. In this version of post, a new
> call-back is_attach_deferred is added to iommu-ops, it's used to check whether
> we need defer the domain attach/detach in iommu-core code.
> 
> v5:
> bnx2 NIC can't reset itself during driver init. Post patch to reset
> it during driver init. IO_PAGE_FAULT can't be seen anymore.
> 
> Below is link of v5 post.
> 
> https://lists.linuxfoundation.org/pipermail/iommu/2016-September/018527.html
> 
> v5->v6:
> According to Joerg's comments made several below main changes:
> - Add sanity check when copy old dev tables.
> 
> - If a device is set up with guest translations (DTE.GV=1), then don't
>   copy that information but move the device over to an empty guest-cr3
>   table and handle the faults in the PPR log (which just answer them
>   with INVALID).
> 
> v6->v7:
> Two main changes are made according to Joerg's suggestion:
> - Add is_attach_deferred call-back to iommu-ops. With this domain
>   can be deferred to device driver init cleanly.
> 
> - Allocate memory below 4G for dev table if translation pre-enabled.
>   AMD engineer pointed out that it's unsafe to update the device-table
>   while iommu is enabled. device-table pointer update is split up into
>   two 32bit writes in the IOMMU hardware. So updating it while the IOMMU
>   is enabled could have some nasty side effects.
> 
> Baoquan He (12):
>   iommu/amd: Detect pre enabled translation
>   iommu/amd: add several helper function
>   iommu/amd: Define bit fields for DTE particularly
>   iommu/amd: Add function copy_dev_tables
>   iommu/amd: copy old trans table from old kernel
>   iommu: Add is_attach_deferred call-back to iommu-ops
>   iommu/amd: Use is_attach_deferred call-back
>   iommu/amd: Add sanity check of irq remap information of old dev table
> entry
>   iommu/amd: Don't copy GCR3 table root pointer
>   iommu/amd: Clear out the GV flag when handle deferred domain attach
>   iommu: Assign the direct mapped domain to group->domain
>   iommu/amd: Allocate memory below 4G for dev table if translation
> pre-enabled
> 
>  drivers/iommu/amd_iommu.c   |  78 +---
>  drivers/iommu/amd_iommu_init.c  | 201 
> +---
>  drivers/iommu/amd_iommu_proto.h |   2 +
>  drivers/iommu/amd_iommu_types.h |  53 ++-
>  drivers/iommu/amd_iommu_v2.c|  18 +++-
>  drivers/iommu/iommu.c   |   9 ++
>  include/linux/iommu.h   |   1 +
>  7 files changed, 313 insertions(+), 49 deletions(-)
> 
> -- 
> 2.5.5
> 

___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec


Re: [PATCH] x86/crash: Update the stale comment in reserve_crashkernel()

2016-12-23 Thread Xunlei Pang
On 12/22/2016 at 11:22 AM, Baoquan He wrote:
> On 12/15/16 at 11:30am, Xunlei Pang wrote:
>> CRASH_KERNEL_ADDR_MAX was missing for a long time, update it
>> with more detailed explanation.
>>
>> Cc: Robert LeBlanc 
>> Cc: Baoquan He 
>> Signed-off-by: Xunlei Pang 
>> ---
>>  arch/x86/kernel/setup.c | 5 -
>>  1 file changed, 4 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
>> index 9c337b0..79ee507 100644
>> --- a/arch/x86/kernel/setup.c
>> +++ b/arch/x86/kernel/setup.c
>> @@ -575,7 +575,10 @@ static void __init reserve_crashkernel(void)
>>  /* 0 means: find the address automatically */
>>  if (crash_base <= 0) {
>>  /*
>> - *  kexec want bzImage is below CRASH_KERNEL_ADDR_MAX
>> + * Set CRASH_ADDR_LOW_MAX upper bound for crash range
>> + * as old kexec-tools loads bzImage below that, unless
>> + * "size,high" or "size@offset"(nonzero offset, see the
>> + * else leg below) is specified.
> Yes, this is a good catch. It might be better to add comment only about
> this if branch. If you want to say more about the upper bounds, better

OK, how about the following change?
/*
 * Set CRASH_ADDR_LOW_MAX upper bound for crash memory.
 * as old kexec-tools loads bzImage below that, unless
 * "crashkernel=size[KMG],high" is specified.
 */

> discuss with Robert LeBlanc to see if it can be detailed in kdump.txt.

Yes, this is independent of Robert's documentation patch.

>
> Also please CC to x86 maintainers, or akpm. They can help merge this.

OK, thanks!

Regards,
Xunlei

___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec