[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20140813142748.GS15082@console-pimps.org>
Date: Wed, 13 Aug 2014 15:27:48 +0100
From: Matt Fleming <matt@...sole-pimps.org>
To: Dave Young <dyoung@...hat.com>
Cc: Matt Fleming <matt.fleming@...el.com>,
Catalin Marinas <catalin.marinas@....com>,
Will Deacon <will.deacon@....com>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>, hpa@...or.com,
Alessandro Zummo <a.zummo@...ertech.it>,
Leif Lindholm <leif.lindholm@...aro.org>,
Ard Biesheuvel <ard.biesheuvel@...aro.org>,
Mark Salter <msalter@...hat.com>,
Randy Dunlap <rdunlap@...radead.org>,
linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
linux-efi@...r.kernel.org, rtc-linux@...glegroups.com
Subject: Re: [PATCH 4/5] efi x86: clear EFI_RUNTIME_SERVICES bit in case
failures other than SetVirtualAddressMap
On Tue, 12 Aug, at 02:10:21PM, Dave Young wrote:
> If enter virtual mode failed due to some reason other than the efi call
> the EFI_RUNTIME_SERVICES bit in efi.flags should be cleared thus users
> of efi runtime services can check the bit and handle the case instead of
> assume efi runtime is ok.
>
> Per Matt, if efi call SetVirtualAddressMap fails we will be not sure it's safe
> to make any assumptions about the state of the system. so kernel panics instead
> of clears EFI_RUNTIME_SERVICES bit.
>
> Signed-off-by: Dave Young <dyoung@...hat.com>
> ---
> arch/x86/platform/efi/efi.c | 10 ++++++++--
> 1 file changed, 8 insertions(+), 2 deletions(-)
[...]
> @@ -882,8 +886,10 @@ static void __init __efi_enter_virtual_mode(void)
>
> void __init efi_enter_virtual_mode(void)
> {
> - if (efi_enabled(EFI_PARAVIRT))
> + if (efi_enabled(EFI_PARAVIRT)) {
> + clear_bit(EFI_RUNTIME_SERVICES, &efi.flags);
> return;
> + }
The EFI_PARAVIRT folks purposely do not set this bit, so there should be
no reason to clear it here.
--
Matt Fleming, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists