public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: lijiang <lijiang@redhat.com>
To: Dave Young <dyoung@redhat.com>
Cc: linux-kernel@vger.kernel.org, kexec@lists.infradead.org,
	x86@kernel.org, linux-ia64@vger.kernel.org,
	linux-efi@vger.kernel.org, tglx@linutronix.de, mingo@redhat.com,
	bp@alien8.de, akpm@linux-foundation.org,
	dave.hansen@linux.intel.com, luto@kernel.org,
	peterz@infradead.org, ard.biesheuvel@linaro.org,
	tony.luck@intel.com, fenghua.yu@intel.com, bhe@redhat.com,
	Tom Lendacky <thomas.lendacky@amd.com>,
	Toshi Kani <toshi.kani@hp.com>,
	Dan Williams <dan.j.williams@intel.com>
Subject: Re: [PATCH 1/2 v8] resource: add the new I/O resource descriptor 'IORES_DESC_RESERVED'
Date: Fri, 30 Nov 2018 15:04:44 +0800	[thread overview]
Message-ID: <bbf6352b-b060-4cb8-dfd2-99166b0149a7@redhat.com> (raw)
In-Reply-To: <20181130033703.GA23624@dhcp-128-65.nay.redhat.com>

在 2018年11月30日 11:37, Dave Young 写道:
> + more people
> 

Thank you, Dave.

That would be fine to let more people review this patch.

> 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 through the iomem resources
>> with the descriptor 'IORES_DESC_NONE', because several e820 types(
>> e.g. E820_TYPE_RESERVED_KERN/E820_TYPE_RAM/E820_TYPE_UNUSABLE/E820
>> _TYPE_RESERVED) are converted to the descriptor 'IORES_DESC_NONE'. It
>> may pass these four types to the kdump kernel, that is not desired result.
>>
>> So, this patch adds a new I/O resource descriptor 'IORES_DESC_RESERVED'
>> for the iomem resources search interfaces. It is helpful to exactly
>> match the reserved resource ranges when walking through iomem resources.
>>
>> In addition, since the new descriptor 'IORES_DESC_RESERVED' is introduced,
>> these code originally related to the descriptor 'IORES_DESC_NONE' need to
>> be updated. Otherwise, it will be easily confused and also cause some
>> errors. Because the 'E820_TYPE_RESERVED' type is converted to the new
>> descriptor 'IORES_DESC_RESERVED' instead of 'IORES_DESC_NONE', it has been
>> changed.
>>
>> Suggested-by: Dave Young <dyoung@redhat.com>
>> Signed-off-by: Lianbo Jiang <lijiang@redhat.com>
>> ---
>>  arch/ia64/kernel/efi.c |  4 ++++
>>  arch/x86/kernel/e820.c |  2 +-
>>  arch/x86/mm/ioremap.c  | 13 ++++++++++++-
>>  include/linux/ioport.h |  1 +
>>  kernel/resource.c      |  6 +++---
>>  5 files changed, 21 insertions(+), 5 deletions(-)
>>
>> diff --git a/arch/ia64/kernel/efi.c b/arch/ia64/kernel/efi.c
>> index 8f106638913c..1841e9b4db30 100644
>> --- a/arch/ia64/kernel/efi.c
>> +++ b/arch/ia64/kernel/efi.c
>> @@ -1231,6 +1231,10 @@ efi_initialize_iomem_resources(struct resource *code_resource,
>>  				break;
>>  
>>  			case EFI_RESERVED_TYPE:
>> +				name = "reserved";
> 
> Ingo updated X86 code to use "Reserved",  I think it would be good to do
> same for this case as well
> 

I have noticed the changes on x86, but for IA64, i'm not sure whether it should do the same
thing, so keep it as before.

If IA64 people would like to give any comment, that will be appreciated.


>> +				desc = IORES_DESC_RESERVED;
>> +				break;
>> +
>>  			case EFI_RUNTIME_SERVICES_CODE:
>>  			case EFI_RUNTIME_SERVICES_DATA:
>>  			case EFI_ACPI_RECLAIM_MEMORY:
> 
> Originally, above 3 are all "reserved", so probably they all should be
> IORES_DESC_RESERVED.
> 

This is a good question.

If above 3 types are converted to the new descriptor 'IORES_DESC_RESERVED', how to handle
the all 'default' case? Because the all 'default' case is also converted to the descriptor
'IORES_DESC_NONE' and the name 'reserved'.

> Can any IA64 people to review this?
> 
>> diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c
>> index 50895c2f937d..57fafdafb860 100644
>> --- a/arch/x86/kernel/e820.c
>> +++ b/arch/x86/kernel/e820.c
>> @@ -1048,10 +1048,10 @@ static unsigned long __init e820_type_to_iores_desc(struct e820_entry *entry)
>>  	case E820_TYPE_NVS:		return IORES_DESC_ACPI_NV_STORAGE;
>>  	case E820_TYPE_PMEM:		return IORES_DESC_PERSISTENT_MEMORY;
>>  	case E820_TYPE_PRAM:		return IORES_DESC_PERSISTENT_MEMORY_LEGACY;
>> +	case E820_TYPE_RESERVED:	return IORES_DESC_RESERVED;
>>  	case E820_TYPE_RESERVED_KERN:	/* Fall-through: */
>>  	case E820_TYPE_RAM:		/* Fall-through: */
>>  	case E820_TYPE_UNUSABLE:	/* Fall-through: */
>> -	case E820_TYPE_RESERVED:	/* Fall-through: */
>>  	default:			return IORES_DESC_NONE;
>>  	}
>>  }
>> diff --git a/arch/x86/mm/ioremap.c b/arch/x86/mm/ioremap.c
>> index 5378d10f1d31..fea2ef99415d 100644
>> --- a/arch/x86/mm/ioremap.c
>> +++ b/arch/x86/mm/ioremap.c
>> @@ -83,7 +83,18 @@ static bool __ioremap_check_ram(struct resource *res)
>>  
>>  static int __ioremap_check_desc_other(struct resource *res)
>>  {
>> -	return (res->desc != IORES_DESC_NONE);
>> +	/*
>> +	 * But now, the 'E820_TYPE_RESERVED' type is converted to the new
>> +	 * descriptor 'IORES_DESC_RESERVED' instead of 'IORES_DESC_NONE',
>> +	 * it has been changed. And the value of 'mem_flags.desc_other'
>> +	 * is equal to 'true' if we don't strengthen the condition in this
>> +	 * function, that is wrong. Because originally it is equal to
>> +	 * 'false' for the same reserved type.
>> +	 *
>> +	 * So, that would be nice to keep it the same as before.
>> +	 */
>> +	return ((res->desc != IORES_DESC_NONE) &&
>> +		(res->desc != IORES_DESC_RESERVED));
>>  }
> 
> Added Tom since he added the check function.  Is it possible to only
> check explict valid desc types instead of exclude IORES_DESC_NONE?
> 

So sorry that i forgot to add Tom.

I'm looking forward to Tom's reply. If i made a mistake, please help me
to point out. Thanks a lot.

Regards,
Lianbo

>>  
>>  static int __ioremap_res_check(struct resource *res, void *arg)
>> diff --git a/include/linux/ioport.h b/include/linux/ioport.h
>> index da0ebaec25f0..6ed59de48bd5 100644
>> --- a/include/linux/ioport.h
>> +++ b/include/linux/ioport.h
>> @@ -133,6 +133,7 @@ enum {
>>  	IORES_DESC_PERSISTENT_MEMORY_LEGACY	= 5,
>>  	IORES_DESC_DEVICE_PRIVATE_MEMORY	= 6,
>>  	IORES_DESC_DEVICE_PUBLIC_MEMORY		= 7,
>> +	IORES_DESC_RESERVED			= 8,
>>  };
>>  
>>  /* helpers to define resources */
>> diff --git a/kernel/resource.c b/kernel/resource.c
>> index b0fbf685c77a..f34a632c4169 100644
>> --- a/kernel/resource.c
>> +++ b/kernel/resource.c
>> @@ -994,7 +994,7 @@ __reserve_region_with_split(struct resource *root, resource_size_t start,
>>  	res->start = start;
>>  	res->end = end;
>>  	res->flags = type | IORESOURCE_BUSY;
>> -	res->desc = IORES_DESC_NONE;
>> +	res->desc = IORES_DESC_RESERVED;
>>  
>>  	while (1) {
>>  
>> @@ -1029,7 +1029,7 @@ __reserve_region_with_split(struct resource *root, resource_size_t start,
>>  				next_res->start = conflict->end + 1;
>>  				next_res->end = end;
>>  				next_res->flags = type | IORESOURCE_BUSY;
>> -				next_res->desc = IORES_DESC_NONE;
>> +				next_res->desc = IORES_DESC_RESERVED;
>>  			}
>>  		} else {
>>  			res->start = conflict->end + 1;
>> @@ -1477,7 +1477,7 @@ static int __init reserve_setup(char *str)
>>  			res->start = io_start;
>>  			res->end = io_start + io_num - 1;
>>  			res->flags |= IORESOURCE_BUSY;
>> -			res->desc = IORES_DESC_NONE;
>> +			res->desc = IORES_DESC_RESERVED;
>>  			res->child = NULL;
>>  			if (request_resource(parent, res) == 0)
>>  				reserved = x+1;
>> -- 
>> 2.17.1
>>
> 
> 
> There are a lot of places call region_intersects which use DESC_NONE,
> I'm not sure if needed changes accordingly.  Cced Dan and Toshi.
> 
> 
> Thanks
> Dave
> 

  parent reply	other threads:[~2018-11-30  7:05 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-29  8:09 [PATCH 0/2 v8] add reserved e820 ranges to the kdump kernel e820 table Lianbo Jiang
2018-11-29  8:09 ` [PATCH 1/2 v8] resource: add the new I/O resource descriptor 'IORES_DESC_RESERVED' Lianbo Jiang
2018-11-30  3:37   ` Dave Young
2018-11-30  3:49     ` Dave Young
2018-11-30  7:04     ` lijiang [this message]
2018-12-06 20:11       ` Borislav Petkov
2018-12-10  4:20         ` lijiang
2019-01-07  5:10         ` lijiang
2018-12-04 21:33     ` Lendacky, Thomas
2018-12-12  1:55       ` lijiang
2019-01-25 11:55       ` lijiang
2019-03-16  7:31       ` lijiang
2019-03-25 19:34         ` Lendacky, Thomas
2019-03-26  9:52           ` lijiang
2019-03-26  9:58           ` Boris Petkov
2018-11-30  3:41   ` Dave Young
2018-11-30  4:44     ` lijiang
2018-11-29  8:09 ` [PATCH 2/2 v8] x86/kexec_file: add reserved e820 ranges to kdump kernel e820 table Lianbo Jiang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bbf6352b-b060-4cb8-dfd2-99166b0149a7@redhat.com \
    --to=lijiang@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=ard.biesheuvel@linaro.org \
    --cc=bhe@redhat.com \
    --cc=bp@alien8.de \
    --cc=dan.j.williams@intel.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=dyoung@redhat.com \
    --cc=fenghua.yu@intel.com \
    --cc=kexec@lists.infradead.org \
    --cc=linux-efi@vger.kernel.org \
    --cc=linux-ia64@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=tglx@linutronix.de \
    --cc=thomas.lendacky@amd.com \
    --cc=tony.luck@intel.com \
    --cc=toshi.kani@hp.com \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox