[Patch] acpi: introduce "acpi_addr=" parameter for kdump

[Patch] acpi: introduce "acpi_addr=" parameter for kdump

[Amerigo Wang]

From: Takao Indoh <tindoh@redhat.com>

There is a problem with putting the first kernel in EFI virtual mode,
it is that when the second kernel comes up it tries to initialize the
EFI again and once we have put EFI in virtual mode we can not really
do that.

Actually, EFI is not necessary for kdump, we can boot the second kernel
with "noefi" parameter, but the boot will mostly fail because 2nd kernel
cannot find RSDP.

In this situation, we introduced "acpi_addr=" kernel parameter,
so that kexec-tools can pass the "noefi acpi_addr=X" to the second kernel
to make kdump works.

Signed-off-by: Takao Indoh <tindoh@redhat.com>
[amwang@redhat.com: Add documentation.]
Signed-off-by: WANG Cong <amwang@redhat.com>
Cc: Eric W. Biederman <ebiederm@xmission.com>
Cc: Vivek Goyal <vgoyal@redhat.com>

---

diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
index f4a04c0..0fbbdc6 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -163,6 +163,11 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
 
 			See also Documentation/power/pm.txt, pci=noacpi
 
+	acpi_addr=	[ACPI,EFI]
+			Pass the RSDP address to the kernel, mostly used
+			on machines running EFI runtime service to boot the
+			second kernel for kdump.
+
 	acpi_apic_instance=	[ACPI, IOAPIC]
 			Format: <int>
 			2: use 2nd APIC table, if available
diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c
index c90c76a..06dfec0 100644
--- a/drivers/acpi/osl.c
+++ b/drivers/acpi/osl.c
@@ -238,8 +238,19 @@ void acpi_os_vprintf(const char *fmt, va_list args)
 #endif
 }
 
+static unsigned long acpi_addr;
+static int __init setup_acpi_addr(char *arg)
+{
+	acpi_addr = simple_strtoul(arg, NULL, 16);
+	return 0;
+}
+early_param("acpi_addr", setup_acpi_addr);
+
 acpi_physical_address __init acpi_os_get_root_pointer(void)
 {
+	if (acpi_addr)
+		return acpi_addr;
+
 	if (efi_enabled) {
 		if (efi.acpi20 != EFI_INVALID_TABLE_ADDR)
 			return efi.acpi20;

Re: [Patch] acpi: introduce "acpi_addr=" parameter for kdump

[Vivek Goyal]

On Thu, Mar 10, 2011 at 10:10:43PM +0800, Amerigo Wang wrote:
> From: Takao Indoh <tindoh@redhat.com>
> 
> There is a problem with putting the first kernel in EFI virtual mode,
> it is that when the second kernel comes up it tries to initialize the
> EFI again and once we have put EFI in virtual mode we can not really
> do that.
> 
> Actually, EFI is not necessary for kdump, we can boot the second kernel
> with "noefi" parameter, but the boot will mostly fail because 2nd kernel
> cannot find RSDP.
> 
> In this situation, we introduced "acpi_addr=" kernel parameter,
> so that kexec-tools can pass the "noefi acpi_addr=X" to the second kernel
> to make kdump works.
> 

Little more background on this. So we now seem to have this general
general problem of how to make kexec/kdump work with EFI.

I have very limited knowledge of EFI and based on some information
gleaned, it looks we seem to have two alternatives to make kdump work.

- Don't transition to virtual mode in first kernel and work with
  physical mode of EFI. Maintain a separate set of page tables for
  mapping EFI and use those to make EFI calls.

- Transition EFI in virtual mode in first kernel. Boot second kernel with
  "noefi" and pass in whatever details are required on kernel command line.
  One such details is ACPI pointer.

Matthew Garret mentioned that other OSes tend to transition EFI in
virtual mode (MacOS X seems to be the exception) and if we decide to stick
to physical mode all the time then we can expect a host of BIOS bug report
as vendors are unlikely to test that path.

Keeping in that mind, using noefi for second kernel make sense. But
I think it is not good for pure kexec case. Takao Indoh san mentioned
that he seems to be running into VGA initialization issues and it
seems there is a need to pass SMBIOS address also.

So I think if it work, for kdump case probably using noefi is fine. I
wanted to bring up the case of kexec and wondering how to make it 
work with virtual mode of EFI or what is our strategy to handle it.

Eric and others, any thoughts on this in general?

Thanks
Vivek

> Signed-off-by: Takao Indoh <tindoh@redhat.com>
> [amwang@redhat.com: Add documentation.]
> Signed-off-by: WANG Cong <amwang@redhat.com>
> Cc: Eric W. Biederman <ebiederm@xmission.com>
> Cc: Vivek Goyal <vgoyal@redhat.com>
> 
> ---
> 
> diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
> index f4a04c0..0fbbdc6 100644
> --- a/Documentation/kernel-parameters.txt
> +++ b/Documentation/kernel-parameters.txt
> @@ -163,6 +163,11 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
>  
>  			See also Documentation/power/pm.txt, pci=noacpi
>  
> +	acpi_addr=	[ACPI,EFI]
> +			Pass the RSDP address to the kernel, mostly used
> +			on machines running EFI runtime service to boot the
> +			second kernel for kdump.
> +
>  	acpi_apic_instance=	[ACPI, IOAPIC]
>  			Format: <int>
>  			2: use 2nd APIC table, if available
> diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c
> index c90c76a..06dfec0 100644
> --- a/drivers/acpi/osl.c
> +++ b/drivers/acpi/osl.c
> @@ -238,8 +238,19 @@ void acpi_os_vprintf(const char *fmt, va_list args)
>  #endif
>  }
>  
> +static unsigned long acpi_addr;
> +static int __init setup_acpi_addr(char *arg)
> +{
> +	acpi_addr = simple_strtoul(arg, NULL, 16);
> +	return 0;
> +}
> +early_param("acpi_addr", setup_acpi_addr);
> +
>  acpi_physical_address __init acpi_os_get_root_pointer(void)
>  {
> +	if (acpi_addr)
> +		return acpi_addr;
> +
>  	if (efi_enabled) {
>  		if (efi.acpi20 != EFI_INVALID_TABLE_ADDR)
>  			return efi.acpi20;

Re: [Patch] acpi: introduce "acpi_addr=" parameter for kdump

[Takao Indoh]

(3/10/2011 09:39), Vivek Goyal wrote:
> On Thu, Mar 10, 2011 at 10:10:43PM +0800, Amerigo Wang wrote:
>> From: Takao Indoh<tindoh@redhat.com>
>>
>> There is a problem with putting the first kernel in EFI virtual mode,
>> it is that when the second kernel comes up it tries to initialize the
>> EFI again and once we have put EFI in virtual mode we can not really
>> do that.
>>
>> Actually, EFI is not necessary for kdump, we can boot the second kernel
>> with "noefi" parameter, but the boot will mostly fail because 2nd kernel
>> cannot find RSDP.
>>
>> In this situation, we introduced "acpi_addr=" kernel parameter,
>> so that kexec-tools can pass the "noefi acpi_addr=X" to the second kernel
>> to make kdump works.
>>
>
> Little more background on this. So we now seem to have this general
> general problem of how to make kexec/kdump work with EFI.
>
> I have very limited knowledge of EFI and based on some information
> gleaned, it looks we seem to have two alternatives to make kdump work.
>
> - Don't transition to virtual mode in first kernel and work with
>    physical mode of EFI. Maintain a separate set of page tables for
>    mapping EFI and use those to make EFI calls.

After I posted EFI phys-mode patch, it was pointed out that we should
introduce global 1:1 page table like initial_page_table instead of
making EFI page table. Therefore we don't need to have EFI special page
table if we can do this, though there is still compatibility problem
between phys-mode and firmware.


>
> - Transition EFI in virtual mode in first kernel. Boot second kernel with
>    "noefi" and pass in whatever details are required on kernel command line.
>    One such details is ACPI pointer.
>
> Matthew Garret mentioned that other OSes tend to transition EFI in
> virtual mode (MacOS X seems to be the exception) and if we decide to stick
> to physical mode all the time then we can expect a host of BIOS bug report
> as vendors are unlikely to test that path.
>
> Keeping in that mind, using noefi for second kernel make sense. But
> I think it is not good for pure kexec case. Takao Indoh san mentioned
> that he seems to be running into VGA initialization issues and it
> seems there is a need to pass SMBIOS address also.

As to VGA problem, it seems to be my mistake. Please ignore it...

But yeah, besides RSDP address, we need pass SMBIOS address for some
commands like dmidecode.

Thanks,
Takao Indoh


> So I think if it work, for kdump case probably using noefi is fine. I
> wanted to bring up the case of kexec and wondering how to make it
> work with virtual mode of EFI or what is our strategy to handle it.
>
> Eric and others, any thoughts on this in general?
>
> Thanks
> Vivek
>
>> Signed-off-by: Takao Indoh<tindoh@redhat.com>
>> [amwang@redhat.com: Add documentation.]
>> Signed-off-by: WANG Cong<amwang@redhat.com>
>> Cc: Eric W. Biederman<ebiederm@xmission.com>
>> Cc: Vivek Goyal<vgoyal@redhat.com>
>>
>> ---
>>
>> diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
>> index f4a04c0..0fbbdc6 100644
>> --- a/Documentation/kernel-parameters.txt
>> +++ b/Documentation/kernel-parameters.txt
>> @@ -163,6 +163,11 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
>>
>>   			See also Documentation/power/pm.txt, pci=noacpi
>>
>> +	acpi_addr=	[ACPI,EFI]
>> +			Pass the RSDP address to the kernel, mostly used
>> +			on machines running EFI runtime service to boot the
>> +			second kernel for kdump.
>> +
>>   	acpi_apic_instance=	[ACPI, IOAPIC]
>>   			Format:<int>
>>   			2: use 2nd APIC table, if available
>> diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c
>> index c90c76a..06dfec0 100644
>> --- a/drivers/acpi/osl.c
>> +++ b/drivers/acpi/osl.c
>> @@ -238,8 +238,19 @@ void acpi_os_vprintf(const char *fmt, va_list args)
>>   #endif
>>   }
>>
>> +static unsigned long acpi_addr;
>> +static int __init setup_acpi_addr(char *arg)
>> +{
>> +	acpi_addr = simple_strtoul(arg, NULL, 16);
>> +	return 0;
>> +}
>> +early_param("acpi_addr", setup_acpi_addr);
>> +
>>   acpi_physical_address __init acpi_os_get_root_pointer(void)
>>   {
>> +	if (acpi_addr)
>> +		return acpi_addr;
>> +
>>   	if (efi_enabled) {
>>   		if (efi.acpi20 != EFI_INVALID_TABLE_ADDR)
>>   			return efi.acpi20;

Re: [Patch] acpi: introduce "acpi_addr=" parameter for kdump

[Eric W. Biederman]

Vivek Goyal <vgoyal@redhat.com> writes:

> On Thu, Mar 10, 2011 at 10:10:43PM +0800, Amerigo Wang wrote:
>> From: Takao Indoh <tindoh@redhat.com>
>> 
>> There is a problem with putting the first kernel in EFI virtual mode,
>> it is that when the second kernel comes up it tries to initialize the
>> EFI again and once we have put EFI in virtual mode we can not really
>> do that.
>> 
>> Actually, EFI is not necessary for kdump, we can boot the second kernel
>> with "noefi" parameter, but the boot will mostly fail because 2nd kernel
>> cannot find RSDP.
>> 
>> In this situation, we introduced "acpi_addr=" kernel parameter,
>> so that kexec-tools can pass the "noefi acpi_addr=X" to the second kernel
>> to make kdump works.
>> 
>
> Little more background on this. So we now seem to have this general
> general problem of how to make kexec/kdump work with EFI.
>
> I have very limited knowledge of EFI and based on some information
> gleaned, it looks we seem to have two alternatives to make kdump work.
>
> - Don't transition to virtual mode in first kernel and work with
>   physical mode of EFI. Maintain a separate set of page tables for
>   mapping EFI and use those to make EFI calls.
>
> - Transition EFI in virtual mode in first kernel. Boot second kernel with
>   "noefi" and pass in whatever details are required on kernel command line.
>   One such details is ACPI pointer.
>
> Matthew Garret mentioned that other OSes tend to transition EFI in
> virtual mode (MacOS X seems to be the exception) and if we decide to stick
> to physical mode all the time then we can expect a host of BIOS bug report
> as vendors are unlikely to test that path.
>
> Keeping in that mind, using noefi for second kernel make sense. But
> I think it is not good for pure kexec case. Takao Indoh san mentioned
> that he seems to be running into VGA initialization issues and it
> seems there is a need to pass SMBIOS address also.
>
> So I think if it work, for kdump case probably using noefi is fine. I
> wanted to bring up the case of kexec and wondering how to make it 
> work with virtual mode of EFI or what is our strategy to handle it.
>
> Eric and others, any thoughts on this in general?

If we want to handle EFI in a long term supportable manner and stop
making short term hacks here is my suggestion.

Move all EFI calls that the kernel does (on x86) into a special section
of the bzImage that the bootloader can run.  This works very well for
the x86 BIOS and it should also work very well for EFI.  Among other
things by having a special 32bit and a special 64bit section this solves
the what flavor of EFI problem are we running on problem.

Never perform any EFI calls once the kernel is initialized, last I
looked all of the EFI calls that were interesting to perform at runtime
were a subset of what ACPI can do, and ACPI is a easier to deal with
long term.

Kexec and kdump can easily pass the gather data from the first kernel to
the second kernel like we do for the normal bios paramsters today.

As a fly in the ointment that leaves the question of how do we set EFI
variables.  It is needed functionality when we are installing, and
occasionally nice to have.  But it is a very rare slow path.  I would
isolate the EFI after the kernel has booted to exactly to that one case.
Either with a special driver or a some flavor of virtualization from
userspace like we used to do for video card initialization.

The current design of EFI in the x86 kernel is crap.  We seem to have
advanced past the early adopter hack anything together to make it work
stage.  So let's stop adding hacks and write something that won't give
us a long term support problems.

Eric

Re: [Patch] acpi: introduce "acpi_addr=" parameter for kdump

[Matthew Garrett]

On Thu, Mar 10, 2011 at 09:50:28AM -0800, Eric W. Biederman wrote:

> Move all EFI calls that the kernel does (on x86) into a special section
> of the bzImage that the bootloader can run.  This works very well for
> the x86 BIOS and it should also work very well for EFI.  Among other
> things by having a special 32bit and a special 64bit section this solves
> the what flavor of EFI problem are we running on problem.

There's no benefit in calling any EFI methods in the kernel if we have 
no intention of making further calls later. If we intent on making 
further calls later then this approach doesn't work well.

> Never perform any EFI calls once the kernel is initialized, last I
> looked all of the EFI calls that were interesting to perform at runtime
> were a subset of what ACPI can do, and ACPI is a easier to deal with
> long term.

With the exception of reboot, I don't see any overlap between the EFI 
runtime services and ACPI.

> Kexec and kdump can easily pass the gather data from the first kernel to
> the second kernel like we do for the normal bios paramsters today.

Doing that's not a problem. The real problem is that passing a virtual 
map to EFI is a one-shot event. The information we need to provide to 
the second kernel isn't a set of parameters - it's the whole memory map, 
and we need to depend on the kernel to be able to set up the same map 
again.

> As a fly in the ointment that leaves the question of how do we set EFI
> variables.  It is needed functionality when we are installing, and
> occasionally nice to have.  But it is a very rare slow path.  I would
> isolate the EFI after the kernel has booted to exactly to that one case.
> Either with a special driver or a some flavor of virtualization from
> userspace like we used to do for video card initialization.

Also capsule updating (not that we implement that at present, but 
vendors will want it). But, again, if you want to push this out to some 
sort of magic then we can just drop pretty much all of the kernel EFI 
support.

> The current design of EFI in the x86 kernel is crap.  We seem to have
> advanced past the early adopter hack anything together to make it work
> stage.  So let's stop adding hacks and write something that won't give
> us a long term support problems.

We're using EFI exactly as it's designed to be used at the moment. The 
only problem is that nobody ever thought people would try to do anything 
like booting one OS into another OS that has different ideas about 
address space layout, but that's a problem with the spec and not our 
implementation.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [Patch] acpi: introduce "acpi_addr=" parameter for kdump

[Cong Wang]

Eric, any comments?

Matthew, seems you agree on this patch, may I have your ACK?

Thanks.

于 2011年03月11日 02:50, Matthew Garrett 写道:
> On Thu, Mar 10, 2011 at 09:50:28AM -0800, Eric W. Biederman wrote:
>
>> Move all EFI calls that the kernel does (on x86) into a special section
>> of the bzImage that the bootloader can run.  This works very well for
>> the x86 BIOS and it should also work very well for EFI.  Among other
>> things by having a special 32bit and a special 64bit section this solves
>> the what flavor of EFI problem are we running on problem.
>
> There's no benefit in calling any EFI methods in the kernel if we have
> no intention of making further calls later. If we intent on making
> further calls later then this approach doesn't work well.
>
>> Never perform any EFI calls once the kernel is initialized, last I
>> looked all of the EFI calls that were interesting to perform at runtime
>> were a subset of what ACPI can do, and ACPI is a easier to deal with
>> long term.
>
> With the exception of reboot, I don't see any overlap between the EFI
> runtime services and ACPI.
>
>> Kexec and kdump can easily pass the gather data from the first kernel to
>> the second kernel like we do for the normal bios paramsters today.
>
> Doing that's not a problem. The real problem is that passing a virtual
> map to EFI is a one-shot event. The information we need to provide to
> the second kernel isn't a set of parameters - it's the whole memory map,
> and we need to depend on the kernel to be able to set up the same map
> again.
>
>> As a fly in the ointment that leaves the question of how do we set EFI
>> variables.  It is needed functionality when we are installing, and
>> occasionally nice to have.  But it is a very rare slow path.  I would
>> isolate the EFI after the kernel has booted to exactly to that one case.
>> Either with a special driver or a some flavor of virtualization from
>> userspace like we used to do for video card initialization.
>
> Also capsule updating (not that we implement that at present, but
> vendors will want it). But, again, if you want to push this out to some
> sort of magic then we can just drop pretty much all of the kernel EFI
> support.
>
>> The current design of EFI in the x86 kernel is crap.  We seem to have
>> advanced past the early adopter hack anything together to make it work
>> stage.  So let's stop adding hacks and write something that won't give
>> us a long term support problems.
>
> We're using EFI exactly as it's designed to be used at the moment. The
> only problem is that nobody ever thought people would try to do anything
> like booting one OS into another OS that has different ideas about
> address space layout, but that's a problem with the spec and not our
> implementation.
>

Re: [Patch] acpi: introduce "acpi_addr=" parameter for kdump

[Eric W. Biederman]

Cong Wang <amwang@redhat.com> writes:

> Eric, any comments?

You have my Nack.

We are doing stupid and unnecessary things, that cause us problems with
EFI.  If we stop doing those stupid and unnecessary things we won't have
problems.

So I don't see the point of adding more stupid and unnecessary work, so
we can continue to do stupid and unnecessary things and cause ourselves
problems.

Eric

Re: [Patch] acpi: introduce "acpi_addr=" parameter for kdump

[Vivek Goyal]

On Mon, Mar 21, 2011 at 01:05:04AM -0700, Eric W. Biederman wrote:
> Cong Wang <amwang@redhat.com> writes:
> 
> > Eric, any comments?
> 
> You have my Nack.
> 
> We are doing stupid and unnecessary things, that cause us problems with
> EFI.  If we stop doing those stupid and unnecessary things we won't have
> problems.
> 
> So I don't see the point of adding more stupid and unnecessary work, so
> we can continue to do stupid and unnecessary things and cause ourselves
> problems.

Hi Eric,

I went through your proposal in last mail and frankly speaking I understand
very little of it (due to my lack of knowledge in this area). Had couple
of very high level thoughts though.

- Matthew raised the issue of ACPI not being complete replacement as
  reboot path uses EFI.

- I am assuming with this notion of run time services in EFI, one can
  expect more and more issues down the line where people will want to
  call into EFI. So trying to enforce this notion that never call EFI
  from kernel once kernel is booted and isolate the EFI runtime services
  to make kexec/kdump work might not be best solution.

Matthew and I were chatting in general about it couple of days back and
mattew suggested how about if we embrace the idea of booting the kernel
always in physical mode (both first and second) and keep that extra set
of pagetables around to make EFI calls. That way kexec/kdump should just
work and kernel changes also might not be too much.

The potential problem with this is that this might expose various kind
of BIOS issues with different vendors as vendors might not test the
physical path.

May be we can give it a try and see if it flies?

Thanks
Vivek 

Re: [Patch] acpi: introduce "acpi_addr=" parameter for kdump

[Cong Wang]

于 2011年03月21日 23:56, Vivek Goyal 写道:
>
> Matthew and I were chatting in general about it couple of days back and
> mattew suggested how about if we embrace the idea of booting the kernel
> always in physical mode (both first and second) and keep that extra set
> of pagetables around to make EFI calls. That way kexec/kdump should just
> work and kernel changes also might not be too much.
>
> The potential problem with this is that this might expose various kind
> of BIOS issues with different vendors as vendors might not test the
> physical path.

First I have to say I know a little about EFI.

I am wondering what benefits we will lose if we use physical mode?
comparing it with virtual mode? If very few, this could be a solution.

Thanks.

Re: [Patch] acpi: introduce "acpi_addr=" parameter for kdump

[Randy Dunlap]

On Thu, 10 Mar 2011 22:10:43 +0800 Amerigo Wang wrote:

> From: Takao Indoh <tindoh@redhat.com>
> 
> There is a problem with putting the first kernel in EFI virtual mode,
> it is that when the second kernel comes up it tries to initialize the
> EFI again and once we have put EFI in virtual mode we can not really
> do that.
> 
> Actually, EFI is not necessary for kdump, we can boot the second kernel
> with "noefi" parameter, but the boot will mostly fail because 2nd kernel
> cannot find RSDP.
> 
> In this situation, we introduced "acpi_addr=" kernel parameter,
> so that kexec-tools can pass the "noefi acpi_addr=X" to the second kernel
> to make kdump works.
> 
> Signed-off-by: Takao Indoh <tindoh@redhat.com>
> [amwang@redhat.com: Add documentation.]
> Signed-off-by: WANG Cong <amwang@redhat.com>
> Cc: Eric W. Biederman <ebiederm@xmission.com>
> Cc: Vivek Goyal <vgoyal@redhat.com>
> 
> ---
> 
> diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
> index f4a04c0..0fbbdc6 100644
> --- a/Documentation/kernel-parameters.txt
> +++ b/Documentation/kernel-parameters.txt
> @@ -163,6 +163,11 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
>  
>  			See also Documentation/power/pm.txt, pci=noacpi
>  
> +	acpi_addr=	[ACPI,EFI]
> +			Pass the RSDP address to the kernel, mostly used
> +			on machines running EFI runtime service to boot the
> +			second kernel for kdump.
> +

I think that "acpi_addr" is a bit too generic.  How about
acpi_rsdp or acpi_root instead?


>  	acpi_apic_instance=	[ACPI, IOAPIC]
>  			Format: <int>
>  			2: use 2nd APIC table, if available
> diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c
> index c90c76a..06dfec0 100644
> --- a/drivers/acpi/osl.c
> +++ b/drivers/acpi/osl.c
> @@ -238,8 +238,19 @@ void acpi_os_vprintf(const char *fmt, va_list args)
>  #endif
>  }
>  
> +static unsigned long acpi_addr;
> +static int __init setup_acpi_addr(char *arg)
> +{
> +	acpi_addr = simple_strtoul(arg, NULL, 16);
> +	return 0;
> +}
> +early_param("acpi_addr", setup_acpi_addr);
> +
>  acpi_physical_address __init acpi_os_get_root_pointer(void)
>  {
> +	if (acpi_addr)
> +		return acpi_addr;
> +
>  	if (efi_enabled) {
>  		if (efi.acpi20 != EFI_INVALID_TABLE_ADDR)
>  			return efi.acpi20;


---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***

Re: [Patch] acpi: introduce "acpi_addr=" parameter for kdump

[Cong Wang]

于 2011年03月11日 00:26, Randy Dunlap 写道:
> On Thu, 10 Mar 2011 22:10:43 +0800 Amerigo Wang wrote:
>> +	acpi_addr=	[ACPI,EFI]
>> +			Pass the RSDP address to the kernel, mostly used
>> +			on machines running EFI runtime service to boot the
>> +			second kernel for kdump.
>> +
>
> I think that "acpi_addr" is a bit too generic.  How about
> acpi_rsdp or acpi_root instead?
>

Yup, I agree "acpi_rsdp" is better.

Thanks.

Re: [Patch] acpi: introduce "acpi_addr=" parameter for kdump

[Len Brown]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 679 bytes --]



On Mon, 21 Mar 2011, Cong Wang wrote:

> 于 2011年03月11日 00:26, Randy Dunlap 写道:
> > On Thu, 10 Mar 2011 22:10:43 +0800 Amerigo Wang wrote:
> > > +	acpi_addr=	[ACPI,EFI]
> > > +			Pass the RSDP address to the kernel, mostly used
> > > +			on machines running EFI runtime service to boot the
> > > +			second kernel for kdump.
> > > +
> > 
> > I think that "acpi_addr" is a bit too generic.  How about
> > acpi_rsdp or acpi_root instead?
> > 
> 
> Yup, I agree "acpi_rsdp" is better.

This should also be [KEXEC], and the code should be #ifdef CONFIG_KEXEC
so that sane people can exclude it from their kernels.

thanks,
Len Brown, Intel Open Source Technology Center

Re: [Patch] acpi: introduce "acpi_addr=" parameter for kdump

[Eric W. Biederman]

Len Brown <lenb@kernel.org> writes:

> On Mon, 21 Mar 2011, Cong Wang wrote:
>
>> 于 2011年03月11日 00:26, Randy Dunlap 写道:
>> > On Thu, 10 Mar 2011 22:10:43 +0800 Amerigo Wang wrote:
>> > > +	acpi_addr=	[ACPI,EFI]
>> > > +			Pass the RSDP address to the kernel, mostly used
>> > > +			on machines running EFI runtime service to boot the
>> > > +			second kernel for kdump.
>> > > +
>> > 
>> > I think that "acpi_addr" is a bit too generic.  How about
>> > acpi_rsdp or acpi_root instead?
>> > 
>> 
>> Yup, I agree "acpi_rsdp" is better.
>
> This should also be [KEXEC], and the code should be #ifdef CONFIG_KEXEC
> so that sane people can exclude it from their kernels.

So far sane people don't use EFI on x86 so that is easy enough.

Eric

Re: [Patch] acpi: introduce "acpi_addr=" parameter for kdump

[Matthew Garrett]

On Tue, Mar 22, 2011 at 09:36:33PM -0700, Eric W. Biederman wrote:
> Len Brown <lenb@kernel.org> writes:
> > This should also be [KEXEC], and the code should be #ifdef CONFIG_KEXEC
> > so that sane people can exclude it from their kernels.
> 
> So far sane people don't use EFI on x86 so that is easy enough.

This year's Lenovos and Dells (at least) boot EFI by default. While I'd 
love to see everybody involved in EFI be relocated to a single small 
island without any ability to communicate with the rest of the world, 
it's unfortunately a reality and we have to deal with it.

-- 
Matthew Garrett | mjg59@srcf.ucam.org