Re: [PATCH v5 2/3] x86/asm: add _ASM_ARG* constants for argument registers to

On 06/14/18 13:59, Nick Desaulniers wrote: > On Thu, Jun 14, 2018 at 1:48 PM H. Peter Anvin wrote: >> >> On 06/13/18 14:05, Nick Desaulniers wrote: >>> From: "H. Peter Anvin" >>> >>> i386 and x86-64 uses different registers for arguments

Re: [PATCH v5 2/3] x86/asm: add _ASM_ARG* constants for argument registers to

On 06/13/18 14:05, Nick Desaulniers wrote: > From: "H. Peter Anvin" > > i386 and x86-64 uses different registers for arguments; make them > available so we don't have to #ifdef in the actual code. > > Native size and specified size (q, l, w, b) versions are provid

Re: [PATCH v4 1/3] compiler-gcc.h: add gnu_inline to all inline declarations

On 06/12/18 13:19, Nick Desaulniers wrote: > > Oh, by [0] __GCC_STDC_INLINE__ is indeed actually the correct symbol > to check for. Clang does support that, so nothing to fix there. > >> By the way, you should check clang against gcc's predefined macros by doing: >> >> gcc [options] -x c

Re: [PATCH v4 1/3] compiler-gcc.h: add gnu_inline to all inline declarations

les have removed an explicit C standard compiler flag for users >of GCC >> >> 5.1+ or Clang. >> >> >> >> Signed-off-by: Nick Desaulniers >> >> Suggested-by: H. Peter Anvin >> >> Suggested-by: Joe Perches >> > >> > I s

Re: [PATCH v3 2/3] x86/asm: add _ASM_ARG* constants for argument registers to

On 06/07/18 11:32, Nick Desaulniers wrote: > > Suggested-by: Sedat Dilek If this was suggested by Sedat, I didn't see that suggestion... -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majord...@vger.kernel.org More majordomo

Re: [PATCH v2 2/2] x86: paravirt: make native_save_fl extern inline

On 06/05/18 10:52, Nick Desaulniers wrote: > > Does the kernel have a different calling convention for 32b x86? How > does that work? regparm=3? Does that need to be added to the > declaration? > Yes, -mregparm=3. No, doesn't need to be added to the declaration. >> Something like this added

Re: [PATCH v2 2/2] x86: paravirt: make native_save_fl extern inline

On 06/05/18 10:28, H. Peter Anvin wrote: > On 06/05/18 10:05, Nick Desaulniers wrote: >> + >> +/* >> + * void native_restore_fl(unsigned long flags) >> + * %rdi: flags >> + */ >> +ENTRY(native_restore_fl) >> +push %_ASM_DI >>

Re: [PATCH v2 2/2] x86: paravirt: make native_save_fl extern inline

e_restore_fl) > To work on i386, this would have to be %_ASM_AX in that case. Something like this added to might be useful; then you can simply: push %_ASM_ARG1 >From 83a7c1b7167dceee0eb731cf4ae3af7f9b2c05ea Mon Sep 17 00:00:00 2001 From: "H. Peter Anvin" Date: Tue, 5 Jun

Re: [RFC Part1 PATCH v3 13/17] x86/io: Unroll string I/O when SEV is active

,Eric Biederman ,Tejun Heo ,Paolo Bonzini ,Andrew Morton ,"Kirill A . Shutemov" ,Lu Baolu From: h...@zytor.com

Re: [PATCH v7 3/3] x86: Make the GDT remapping read-only on 64-bit

,"Luis R . Rodriguez" ,Stanislaw Gruszka ,Peter Zijlstra ,Josh Poimboeuf ,Vitaly Kuznetsov ,Tim Chen ,Joerg Roedel

Re: [PATCH 1/2] x86: Fix kernel panic when booting with XD disabled in uEFI firmware

On December 8, 2015 12:30:06 PM PST, Kees Cook wrote: >On Tue, Dec 8, 2015 at 6:19 AM, Borislav Petkov wrote: >> On Tue, Dec 08, 2015 at 12:25:57PM +, Matt Fleming wrote: >>> On Mon, 07 Dec, at 11:10:43PM, Kosuke Tatsukawa wrote: >>> > >>> > Thank you

Re: [PATCH] x86: setup: extend low identity map to cover whole kernel range

On October 14, 2015 2:39:58 PM PDT, Andy Lutomirski wrote: >On Wed, Oct 14, 2015 at 2:00 PM, Matt Fleming > wrote: >> On Wed, 14 Oct, at 09:22:03AM, Andy Lutomirski wrote: >>> On Wed, Oct 14, 2015 at 6:52 AM, Matt Fleming >

Re: [PATCH 2/2] arm64/efi: Don't pad between EFI_MEMORY_RUNTIME regions

On 09/29/2015 07:36 AM, Matt Fleming wrote: > > That's a pretty good summary for x86. I think specifically the reason > we map the EFI memmap entries "backwards" (entry N has higher VA than > entry N+1) is because the code was easier to write that way, but > you'll know better than me ;-) >

Re: [PATCH 2/2] arm64/efi: Don't pad between EFI_MEMORY_RUNTIME regions

On 09/29/2015 06:16 PM, Andy Lutomirski wrote: > > Can we at least do 1:1 without an offset on arm64? Given that Linux > seems to be more of a reference on arm64 than Windows is, maybe that > would give everyone something vaguely sane to work with. > I have no idea. That's a question for the

Re: [PATCH 1/2] x86/efi: Map EFI memmap entries in-order at runtime

On 09/27/2015 11:16 PM, Ingo Molnar wrote: > > So the question is, what does Windows do? > > PC firmware is a hostile environment for Linux, to be compatible the best we > can > do is to mimic the environment that the firmware is tested under - i.e. try > to use > the firmware in the way

Re: [PATCH 2/2] arm64/efi: Don't pad between EFI_MEMORY_RUNTIME regions

On 09/27/2015 12:06 AM, Ingo Molnar wrote: > > * Ard Biesheuvel wrote: > >>> If we allocate the EFI runtime as a single virtual memory block then issues >>> like rounding between sections does not even come up as a problem: we map >>> the >>> original offsets and

Re: [PATCH 1/2] x86/efi: Map EFI memmap entries in-order at runtime

. On September 26, 2015 1:09:17 PM PDT, Ard Biesheuvel <ard.biesheu...@linaro.org> wrote: > >> On 26 sep. 2015, at 12:57, Matt Fleming <m...@codeblueprint.co.uk> >wrote: >> >>> On Sat, 26 Sep, at 12:49:26PM, H. Peter Anvin wrote: >>> >>> It

Re: [PATCH 1/2] x86/efi: Map EFI memmap entries in-order at runtime

It is still a hack unless all relative offsets are preserved. That is actually simpler, even: no sorting necessary. On September 26, 2015 11:15:57 AM PDT, Ard Biesheuvel <ard.biesheu...@linaro.org> wrote: >On 26 September 2015 at 10:20, H. Peter Anvin <h...@zytor.com> wr

Re: [PATCH] x86_64/efi: Mapping Boot and Runtime EFI memory regions to different starting virtual address

On 07/29/2015 09:32 PM, Lee, Chun-Yi wrote: When testing hibernate, I found the EFI runtime services was broken on some old EFI machines on my hand, Intel DQ57TM development board and Acer Gateway Z5WT2 notebook. After printing the EFI memmap and virtual address mapping on -4G area, found

Re: EFI mixed mode + perf = rampant triple faults

On 01/15/2015 11:41 AM, Matt Fleming wrote: Tianocore makes assumptions about the kernel's GDT layout? Yuck. No, but 32-bit Tianocore does rely on the second GDT entry being a 32-bit CS. It has no knowledge of Linux's GDT layout. If it assumes that descriptor 16 is a 32-bit CS (and what

Re: [PATCH] rtc: Disable EFI rtc for x86

On 11/10/2014 12:37 PM, Austin S Hemmelgarn wrote: On 2014-11-10 12:04, Matthew Garrett wrote: On Mon, Nov 10, 2014 at 11:45:06AM -0500, Austin S Hemmelgarn wrote: I agree, without it you need PC CMOS RTC support to access the RTC on most systems, which in turn means that you have to enable

Re: [PATCH -v4] x86: only load initrd above 4g on second try

On 09/04/2014 03:01 AM, Matt Fleming wrote: On Wed, 03 Sep, at 09:50:07PM, Yinghai Lu wrote: Mantas found that after commit 4bf7111f5016 (x86/efi: Support initrd loaded above 4G), the kernel freezes at the earliest possible moment when trying to boot via UEFI on Asus laptop. Revert to old

Re: [REGRESSION] efi: efistub: Convert into static library and preparation patches

On 09/03/2014 12:57 PM, Ard Biesheuvel wrote: I guess that is likely to work, I just wasn't aware it existed :-) I think adding another visibility(hidden) attribute or 2 would complete eliminate the need for GOT fixups, but I guess that is more sensitive to compiler versions being recent

Re: [REGRESSION] efi: efistub: Convert into static library and preparation patches

Any reason we can't reuse the existing GOT fixup code in the early x86 boot code? We're not executing it before the EFI boot stub atm, which is the reason Maarten is hitting these difficulties. Maarten, does the following help? If not, Ard please go ahead with option #2 above. Overkill

Re: [PATCH] x86: only load initrd above 4g on second try

On 08/26/2014 02:45 PM, Yinghai Lu wrote: Mantas found that after commit 4bf7111f5016 (x86/efi: Support initrd loaded above 4G), the kernel freezes at the earliest possible moment when trying to boot via UEFI on Asus laptop. There are buggy EFI implementations: with EFI run time, kernel need

Re: [PATCH] x86/efi: Fix 3DNow optimization build failure in EFI stub

on ACPI + depends on ACPI !X86_USE_3DNOW select UCS2_STRING select EFI_RUNTIME_WRAPPERS ---help--- As we discussed over IRC, should be EFI_STUB not EFI. Once that is fixed: Acked-by: H. Peter Anvin h...@linux.intel.com ... in case Ingo or Thomas grabs it before I do

Re: [PATCH] x86, eboot: Support initrd loaded above 4G

On 07/15/2014 08:10 AM, Matt Fleming wrote: Going forward, I suspect any attempts to use the EFI File Protocol are going to result in this kind of breakage, and that the only thing that can be relied upon is the Disk I/O Protocol. Do we know what the Windows bootloader does? I thought it

Re: [PATCH] efi: Request desired alignment via the PE/COFF headers

On 07/09/2014 03:44 PM, Michael Brown wrote: Signed-off-by: Michael Brown mbr...@fensystems.co.uk --- arch/x86/boot/header.S | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/boot/header.S b/arch/x86/boot/header.S index 7a6d43a..16ef025 100644 ---

Re: Linux kernel EFI stub bug?

On 07/09/2014 08:44 AM, Michael Brown wrote: It is possible to create a .bss section in the PE/COFF header: iPXE does this. For example: objdump -x bin-x86_64-efi/ipxe.efi Sections: Idx Name Size VMA LMA File off Algn 0 .text00081948

Re: [PATCH] efi: Include a .bss section within the PE/COFF headers

init_size does not include any kind of alignment padding. On July 9, 2014 3:20:40 PM PDT, Michael Brown mbr...@fensystems.co.uk wrote: On 09/07/14 22:41, Michael Brown wrote: The PE/COFF headers currently describe only the initialised-data portions of the image, and result in no space being

Re: [Xen-devel] [PATCH v5 7/7] arch/x86: Comment out efi_set_rtc_mmss()

On 06/16/2014 04:54 AM, Juergen Gross wrote: And shouldn't it be removed from include/linux/efi.h as well? Indeed. -hpa -- To unsubscribe from this list: send the line unsubscribe linux-efi in the body of a message to majord...@vger.kernel.org More majordomo info at

Re: [GIT PULL] EFI changes for v3.16

On 05/19/2014 04:10 PM, Borislav Petkov wrote: The question is, why can't that pstore mumbo jumbo go and do its dance in !irq context? And how useful is the whole deal really, btw? I wanted to use it for saving oopses into it, for example, but Tony said its write speed is horribly low for

Re: [PATCH v2 00/10] arm64: UEFI support

On 04/29/2014 04:43 AM, Matt Fleming wrote: (Pulling in Peter and Stephen) On Tue, 29 Apr, at 11:28:17AM, Catalin Marinas wrote: The patches look fine to me, they've been through several rounds of review already. How do we propose these get merged as the series contains both generic and

Re: [PATCH v2 00/10] arm64: UEFI support

On 04/29/2014 06:47 AM, Catalin Marinas wrote: Waiting for the tip/x86/efi to be merged first is not a problem. We also need a stable base for testing the arm64 UEFI series, so I assume this series can be based onto tip/x86/efi (would such branch be rebased before hitting mainline?).

Re: Trusted kernel patchset for Secure Boot lockdown

On 03/13/2014 03:12 AM, One Thousand Gnomes wrote: I would prefer it did the revocation of CAP_SYS_RAWIO or at least documented the absolute requirement. Seconded. This has been my opinion, raised over and over and over again. -hpa -- To unsubscribe from this list: send the line

Re: Trusted kernel patchset for Secure Boot lockdown

On 03/13/2014 02:24 PM, One Thousand Gnomes wrote: If I have CAP_SYS_RAWIO I can make arbitary ring 0 calls from userspace, trivially and in a fashion well known and documented. ... and once we eliminate CAP_SYS_RAWIO a bunch of the patches become redundant. -hpa -- To unsubscribe

Re: [patch] x86/efi: use GFP_ATOMIC under spin_lock

On 03/07/2014 03:20 AM, Dan Carpenter wrote: In phys_efi_get_time() we call efi_call_phys_prelog() with a spin_lock so this allocation should be atomic. Fixes: b8f2c21db390 ('efi, x86: Pass a proper identity mapping in efi_call_phys_prelog') Signed-off-by: Dan Carpenter

Re: [PATCH 06/13] x86/efi: Build our own EFI services pointer table

Much better indeed. On February 28, 2014 6:12:06 AM PST, Matt Fleming m...@console-pimps.org wrote: On Thu, 27 Feb, at 12:09:21PM, H. Peter Anvin wrote: That being said, is there a reason we can't simply write this as: efi_system_table_##bits##_t table; /* ... */ func

Re: [PATCH 12/12] Add option to automatically set trusted_kernel when in Secure Boot mode

On 02/26/2014 02:41 PM, One Thousand Gnomes wrote: On Wed, 26 Feb 2014 15:11:13 -0500 Matthew Garrett matthew.garr...@nebula.com wrote: UEFI Secure Boot provides a mechanism for ensuring that the firmware will only load signed bootloaders and kernels. Certain use cases may also require that

Re: [PATCH] ACPI / init: Run acpi_early_init() before timekeeping_init()

timekeeping_init() to prepare setting system clock with ACPI TAD. v1: Rafael J. Wysocki ACPI / init: Run acpi_early_init() before efi_enter_virtual_mode() Cc: Rafael J. Wysocki r...@rjwysocki.net Cc: Matt Fleming m...@console-pimps.org Cc: H. Peter Anvin h...@zytor.com Cc: Borislav Petkov

Re: [PATCH 1/4] x86, ptdump: Add the functionality to dump an arbitrary pagetable

On 01/14/2014 05:16 PM, Dave Young wrote: Why the [Finnish] do you feel that information needs to be in a different form because it is (currently!) not available as a module? I think moving them to comment can avoid including extra linux/module.h And that matters, why? -hpa --

Re: [PATCH 1/4] x86, ptdump: Add the functionality to dump an arbitrary pagetable

On 01/15/2014 07:03 PM, Dave Young wrote: making something harder to grep and less standardized is hardly cleaner and these things compile to nothing for non-modules. It's not nothing, just very small increasement: text data bss dec hex filename 7636121

Re: [RFT][PATCH] ACPI / init: Run acpi_early_init() before efi_enter_virtual_mode()

On 01/13/2014 08:09 PM, joeyli wrote: This patch works to me on Acer Gateway Z5WT2 UEFI notebook and Intel UEFI development board. Does it possible move acpi_early_init() to before timekeeping_init()? The position is also before efi_enter_virtual_mode() and that will be useful for parsing

Re: [PATCH 1/4] x86, ptdump: Add the functionality to dump an arbitrary pagetable

On 01/13/2014 05:40 PM, Dave Young wrote: On 01/13/14 at 06:48am, Arjan van de Ven wrote: On 1/13/2014 4:23 AM, Dave Young wrote: How about do not limit to only if (pgd) case, instead do something like below: set dump_to_dmesg as a module parameter X86_PTDUMP is not a module. Hmm, I just

Re: [RFC PATCH 04/14] ACPI: Add ACPI 5.0 Time and Alarm Device driver

On 01/08/2014 06:59 AM, joeyli wrote: ACPICA denied AML access RTC ports. I tried to access 0x70, 0x71 ports in ASL on a real machine, ACPICA denied AML access to those ports. I got the following dmesg: hwvalid-0188 hw_validate_io_request: Denied AML access to port 0x0071/1

Re: [RFC PATCH 04/14] ACPI: Add ACPI 5.0 Time and Alarm Device driver

On 01/08/2014 07:47 PM, joeyli wrote: Unfortunately current acpica leaks the SystemCMOS handler: ACPI Error: Region SystemCMOS (ID=5) has no handler (20131115/exfldio-299) I'm sorry, I can't parse either your statement or the error message... sounds like there is a bug here, too.

Re: [RFC PATCH 04/14] ACPI: Add ACPI 5.0 Time and Alarm Device driver

On 01/07/2014 02:40 AM, joeyli wrote: Due to accessing CMOS through ASL need enable SMM support in OVMF, Why? The CMOS is its own ASL address space, and you need that anyway to be able to access the RTC proper. If you don't want to use it because you don't want to export any indication of a

Re: [RFC PATCH 04/14] ACPI: Add ACPI 5.0 Time and Alarm Device driver

On 01/06/2014 12:58 AM, joeyli wrote: 於 二，2013-12-31 於 16:42 -0800，H. Peter Anvin 提到： On 12/19/2013 09:41 PM, joeyli wrote: What platform do you have that has TAD support? I am wondering how this was tested. It's a testing platform that's only support get/set time functions of ACPI TAD

Re: [RFC PATCH 04/14] ACPI: Add ACPI 5.0 Time and Alarm Device driver

On 12/19/2013 09:41 PM, joeyli wrote: What platform do you have that has TAD support? I am wondering how this was tested. It's a testing platform that's only support get/set time functions of ACPI TAD. It would be really, really good to get this into Qemu (either SeaBIOS or OVMF, or

Re: split efi systab in sysfs

On 12/25/2013 05:53 PM, Dave Young wrote: Hi, Matt and Peter Currently /sys/firmware/efi/systab contains multi-lines for efi systab entries. As previous discussion with Greg, this is not a good in sysfs. I wonder if there's other users for this file except kexec-tools. If kexec-tools is

Re: [PATCH 02/14] x86-64/efi: Use EFI to deal with platform wall clock (again)

On 12/20/2013 03:29 AM, One Thousand Gnomes wrote: On Thu, 19 Dec 2013 21:32:19 +0800 joeyli j...@suse.com wrote: 於 四，2013-12-19 於 10:49 +，Matt Fleming 提到： On Thu, 19 Dec, at 06:20:16PM, Lee, Chun-Yi wrote: From: Jan Beulich jbeul...@suse.com Other than ix86, x86-64 on EFI so far

Re: [RFC PATCH 06/14] rtc-efi: register rtc-efi device when EFI enabled

. Peter Anvin wrote: On 12/19/2013 08:24 PM, joeyli wrote: I agreed, but userspace application should not be too often to access RTC. Maybe only when system boot and set timezone. This is, quite frankly, an idiotic argument. TBH, I've been struggling with the question too - and it might even

Re: [RFC PATCH 00/14] Support timezone of ACPI TAD and EFI TIME

matthew.garr...@nebula.com wrote: On Thu, 2013-12-19 at 20:22 -0800, H. Peter Anvin wrote: On 12/19/2013 08:05 PM, joeyli wrote: Can we use EFI time services on x86_64 after Borislav's patches accepted to mainline? No. We will want to use them to (at minimum) obtain the clock timezone

Re: [RFC PATCH 00/14] Support timezone of ACPI TAD and EFI TIME

Yes, but the TZ isn't all that critical, either. It certainly doesn't matter at all for a pure Linux system. Matthew Garrett matthew.garr...@nebula.com wrote: On Fri, 2013-12-20 at 08:57 -0800, H. Peter Anvin wrote: But we prefer the TAD for that. The case where the EFI runtime is the only

Re: [RFC PATCH 06/14] rtc-efi: register rtc-efi device when EFI enabled

On 12/20/2013 07:14 AM, Matthew Garrett wrote: On Fri, 2013-12-20 at 11:37 +0100, Borislav Petkov wrote: On Thu, Dec 19, 2013 at 08:30:48PM -0800, H. Peter Anvin wrote: On 12/19/2013 08:24 PM, joeyli wrote: I agreed, but userspace application should not be too often to access RTC. Maybe only

Re: [RFC PATCH 00/14] Support timezone of ACPI TAD and EFI TIME

On 12/19/2013 09:38 PM, joeyli wrote: If don't use EFI time, then the first priority is using ACPI TAD if it present. Due to ACPI TAD is a generic acpi device that's need OS parsing DSDT table before set system time. Either move DSDT parser from subsystem initial stage to start_kernel or

Re: [RFC PATCH 00/14] Support timezone of ACPI TAD and EFI TIME

On 12/20/2013 07:16 AM, Matthew Garrett wrote: On Thu, 2013-12-19 at 20:22 -0800, H. Peter Anvin wrote: On 12/19/2013 08:05 PM, joeyli wrote: Can we use EFI time services on x86_64 after Borislav's patches accepted to mainline? No. We will want to use them to (at minimum) obtain

Re: [RFC PATCH 00/14] Support timezone of ACPI TAD and EFI TIME

On 12/20/2013 01:10 PM, H. Peter Anvin wrote: On 12/19/2013 09:38 PM, joeyli wrote: If don't use EFI time, then the first priority is using ACPI TAD if it present. Due to ACPI TAD is a generic acpi device that's need OS parsing DSDT table before set system time. Either move DSDT parser from

Re: [RFC PATCH 00/14] Support timezone of ACPI TAD and EFI TIME

On 12/20/2013 01:45 PM, Rafael J. Wysocki wrote: My understanding, however, is that to use the TAD, we don't actually need to create a struct acpi_device for it. We just need a handle to the ACPICA object which can be found using acpi_get_devices() as soon as the namespace has been

Re: [RFC PATCH 00/14] Support timezone of ACPI TAD and EFI TIME

On 12/20/2013 02:53 AM, Thomas Renninger wrote: On Thursday, December 19, 2013 08:22:08 PM H. Peter Anvin wrote: On 12/19/2013 08:05 PM, joeyli wrote: Then that means the priority of PNP0B0x is higher then CMOS RTC Not Present flag. ACPI spec doesn't have clear definition on this. According

Re: [RFC PATCH 06/14] rtc-efi: register rtc-efi device when EFI enabled

On 12/20/2013 05:24 PM, joeyli wrote: 於 五，2013-12-20 於 13:04 -0800，H. Peter Anvin 提到： Actually, it doesn't have to reprogram the clock ... it just needs to know if another OS has already done so. All Linux needs to do is to be able to derive UTC from whatever the RTC is set to and to be able

Re: [PATCH 03/14] rtc: block registration of rtc-cmos when CMOS RTC Not Present

Where did you find a platform with no CMOS set and a PNP RTC? I find the expect behavior in that case to be quite ambiguous and it is not at all clear to me that what you have here is the right thing. Lee, Chun-Yi joeyli.ker...@gmail.com wrote: We should not acess CMOS address when CMOS RTC Not

Re: [RFC PATCH 00/14] Support timezone of ACPI TAD and EFI TIME

On 12/18/2013 11:43 PM, Lee, Chun-Yi wrote: This patchset add the timezone support of ACPI TAD and EFI TIME, it also add codes for adjusting system time base on the timezone value from EFI TIME services when system boot. EFI time is something we used to support and ripped out, because it

Re: [RFC PATCH 04/14] ACPI: Add ACPI 5.0 Time and Alarm Device driver

On 12/18/2013 11:51 PM, Lee, Chun-Yi wrote: This patch add the driver of Time and Alarm Device in ACPI 5.0. Currently it only implemented get/set time functions and grab the capabilities of device when driver initial. This driver also register rtc-acpitad platform device for RTC ACPITAD

Re: [RFC PATCH 00/14] Support timezone of ACPI TAD and EFI TIME

On 12/19/2013 08:05 PM, joeyli wrote: Then that means the priority of PNP0B0x is higher then CMOS RTC Not Present flag. ACPI spec doesn't have clear definition on this. According to the Microsoft requirements documents, such a platform is broken and shouldn't exist. I look forward to

Re: [RFC PATCH 06/14] rtc-efi: register rtc-efi device when EFI enabled

On 12/19/2013 08:24 PM, joeyli wrote: I agreed, but userspace application should not be too often to access RTC. Maybe only when system boot and set timezone. This is, quite frankly, an idiotic argument. Userspace doesn't access the RTC, the kernel does, and if the underlying

Re: [PATCH] UEFI: Don't use UEFI time services on 32-bit

On 11/29/2013 05:45 PM, H. Peter Anvin wrote: Does the Dell Venue have either an ACPI TAD or one of the PNP0B0x devices exposed? Ping on this? Either way, I maintain what I have said in the past: Unless we find evidence to the contrary, we should probably do: ACPI TAD PNP0B0x EFI hard

Re: [PATCH] UEFI: Don't use UEFI time services on 32-bit

On 12/10/2013 02:58 PM, Matthew Garrett wrote: On Tue, 2013-12-10 at 14:54 -0800, H. Peter Anvin wrote: Ping on this? No TAD, yes ACPI declaration for RTC. OK, that is unfortunate. Unless we find evidence to the contrary, we should probably do: ACPI TAD PNP0B0x EFI hard probing

Re: [PATCH v5 00/14] kexec kernel efi runtime support

On 12/10/2013 03:32 PM, Borislav Petkov wrote: On Tue, Dec 10, 2013 at 03:25:49PM -0800, Andrew Morton wrote: On Mon, 9 Dec 2013 17:42:13 +0800 Dave Young dyo...@redhat.com wrote: Here is the V5 patchset for supporting kexec kernel efi runtime. It's unclear (to me) who's supposed to merge

Re: [PATCH] UEFI: Don't use UEFI time services on 32-bit

On 12/10/2013 03:24 PM, Matthew Garrett wrote: TAD would also give us the timezone. I'm not sure how you can realistically only use the time function during boot, however, unless you inherently assume it is coherent with the hardware RTC, since you wouldn't be able to set it. If we can

Re: [PATCH] UEFI: Don't use UEFI time services on 32-bit

On 12/10/2013 04:20 PM, joeyli wrote: Actually, I am working on the timezone support of ACPI TIME and EFI TIME. My current implementation is using EFI time services to deal with clock in RTC. The ACPI TAD is a generic device that need parse DSDT for access it. The DSDT parser is in

Re: [PATCH v4 06/12] efi: export efi runtime memory mapping to sysfs

This is very good advice indeed. Borislav Petkov b...@alien8.de wrote: On Sat, Dec 07, 2013 at 04:01:02AM -0500, Dave Young wrote: Hi, all Update my status: I have finished most of thecode related changes including the krealloc fixes (both for original code and my new code). And I'm

Re: [PATCH] UEFI: Don't use UEFI time services on 32-bit

On 11/29/2013 11:44 AM, Matthew Garrett wrote: UEFI time services are often broken once we're in virtual mode. We were already refusing to use them on 64-bit systems, but it turns out that they're also broken on some 32-bit firmware, including the Dell Venue. Disable them for now, we can

Re: [patch 00/12 v4] kexec kernel efi runtime support v v4] efi: export more efi table variable to sysfs

On 11/25/2013 12:56 AM, dyo...@redhat.com wrote: For efi runtime mapping I add a new directory /sys/firmware/efi/ runtime-map/ like below [dave@darkstar ~]$ tree /sys/firmware/efi/runtime-map/ /sys/firmware/efi/runtime-map/ ├── 0 │ ├── attribute │ ├── num_pages

Re: [RFC v2 0/2] Early use of boot service memory

On 11/21/2013 03:07 PM, Matthew Garrett wrote: On Thu, Nov 21, 2013 at 02:01:24PM -0700, Jerry Hoemann wrote: Some platform have firmware that violates the UEFI spec and access boot service code or data segments after the system has called ExitBootServices(). The call to

Re: [RFC v2 0/2] Early use of boot service memory

Various DMA-deficient devices, at least without an iommu. Vivek Goyal vgo...@redhat.com wrote: On Thu, Nov 21, 2013 at 05:31:54PM -0800, H. Peter Anvin wrote: On 11/21/2013 05:29 PM, Yinghai Lu wrote: On Thu, Nov 21, 2013 at 5:25 PM, jerry.hoem...@hp.com wrote: On Thu, Nov 21, 2013 at 05:12

Re: [PATCH 0/3] Early use of boot service memory

On 11/18/2013 07:22 AM, Vivek Goyal wrote: And if that's true, then reserving 72M extra due to crashkernel=X,high should not be a big issue in KVM guests. It will still be an issue on physical servers though. Yes, but there it is a single instance and not a huge amount of RAM.

Re: [PATCH 0/3] Early use of boot service memory

On 11/15/2013 10:30 AM, Vivek Goyal wrote: And IOMMU support is very flaky with kdump. And IOMMU's can be turned off at command line. And that would force one to remove crahkernel_low=0. So change of one command line option forces change of another. It is complicated. Also there are very

Re: [patch 1/3 v2] Add function get_bootparam

In other words, we didn't catch that one in time. Oh well. Dave Young dyo...@redhat.com wrote: On 11/17/13 at 07:29pm, H. Peter Anvin wrote: On 11/17/2013 06:22 PM, Dave Young wrote: On 11/13/13 at 08:50am, Dave Young wrote: On 11/12/13 at 06:51pm, Greg KH wrote: On Tue, Nov 12, 2013

Re: [PATCH 0/3] Early use of boot service memory

On 11/15/2013 10:30 AM, Vivek Goyal wrote: I agree taking assistance of hypervisor should be useful. One reason we use kdump for VM too because it makes life simple. There is no difference in how we configure, start and manage crash dumps in baremetal or inside VM. And in practice have not

Re: [PATCH 0/3] Early use of boot service memory

On 11/15/2013 10:46 AM, H. Peter Anvin wrote: On 11/15/2013 10:30 AM, Vivek Goyal wrote: I agree taking assistance of hypervisor should be useful. One reason we use kdump for VM too because it makes life simple. There is no difference in how we configure, start and manage crash dumps

Re: [PATCH 0/3] Early use of boot service memory

On 11/14/2013 10:44 AM, Pekka Enberg wrote: On Thu, Nov 14, 2013 at 8:04 PM, jerry.hoem...@hp.com wrote: Making this issue a quirk will be a lot more practical. Its a small, focused change whose implications are limited and more easily understood. There's nothing practical with requiring

Re: [PATCH 0/3] Early use of boot service memory

On 11/14/2013 10:55 PM, Yinghai Lu wrote: Why just asking distros to append ,high in their installation program for 64bit by default? [...] What is hpa's suggestion? Pretty much what you just said ;) -- To unsubscribe from this list: send the line unsubscribe linux-efi in the body of

Re: [patch 7/7 v2] x86: add xloadflags bit for efi runtime support on kexec

On 11/05/2013 12:20 AM, dyo...@redhat.com wrote: Old kexec-tools can not load new kernel. The reason is previously kexec-tools do not fill efi_info in x86 setup header thus efi init fail and switch to noefi boot. In new kexec-tools it will by default fill efi_info and pass other efi required

Re: [PATCH 0/3] Early use of boot service memory

On 11/13/2013 03:57 PM, jerry.hoem...@hp.com wrote: I think i can go to a date based black list, that removes the manual step. System running firmware before certain date assumes we need to do the work around. If firmware is newer than that date, we don't use the workaround. Blacklist

Re: [patch 1/3 v2] Add function get_bootparam

On 11/12/2013 12:30 AM, Greg KH wrote: And these binary data blobs are a standard somewhere, and will not change per kernel version change? If so, that structure is fine with me. Correct. The structure is documented in Documentation/x86/boot.txt, and has been largely invariant (but

Re: [PATCH 0/3] Early use of boot service memory

The problem with the crashkernel is that it by default has to sit very low in memory because the tools don't know if the crashkernel is me enough to sit anywhere. That is the real fix. Jerry Hoemann jerry.hoem...@hp.com wrote: Some platform have firmware that violates UEFI spec and access boot

Re: [patch 1/3 v2] Add function get_bootparam

On 11/11/2013 05:27 PM, Toshi Kani wrote: On Tue, 2013-11-05 at 16:29 +0800, dyo...@redhat.com wrote: Not only setup_subarch will get data from debugfs file boot_params/data, later code for adding efi_info will also need do same thing. Thus add a common function here for later use.

Re: [patch 0/7 v2] kexec kernel efi runtime support

On 11/10/2013 06:13 PM, Dave Young wrote: Huang Ying ying.hu...@intel.com created the debugfs file for boot_params. His first version patch tried sysfs, but sysfs is not designed for such binary blobs so finally it go to debugfs. That is a misunderstanding. Binary blobs can exist in sysfs

Re: [patch 0/7 v2] kexec kernel efi runtime support

On 11/08/2013 07:57 PM, Dave Young wrote: Hmm, if CONFIG_DEBUG_BOOT_PARAMS is not set, then kexec-tools should fail getting efi_info, so I will fix kexec-tools patch about this. Also CONFIG_EFI_RUNTIME_MAP should select CONFIG_DEBUG_BOOT_PARAMS. In future will try to move the boot params

Re: [patch 3/6] Cleanup efi_enter_virtual_mode function

On 10/30/2013 07:07 PM, Dave Young wrote: On 10/31/13 at 10:04am, Dave Young wrote: On 10/30/13 at 11:47am, Borislav Petkov wrote: On Wed, Oct 30, 2013 at 10:03:49AM +0800, Dave Young wrote: Will try, but please keep the posted patches in mailing list up-to-date, Would you like me to send

Re: [PATCH 1/2] x86/efi: Include linux/efi.h in asm/efi.h

/efi.h. Just include linux/efi.h directly and avoid the duplication. Cc: H. Peter Anvin h...@zytor.com Cc: Thomas Gleixner t...@linutronix.de Suggested-by: Ingo Molnar mi...@kernel.org Signed-off-by: Matt Fleming matt.flem...@intel.com --- arch/x86/boot/compressed/eboot.c | 1 - arch/x86/include

Re: [PATCH -v2] EFI: Runtime services virtual mapping

We can do that... but it is different from what Windows does to my understanding and it also has the potential of severe pathologies... e.g. a window at the top of the address space being mapped. Borislav Petkov b...@alien8.de wrote: On Wed, Oct 02, 2013 at 11:46:44AM -0700, H. Peter Anvin

Re: [PATCH] Remove redundant and incorrect memset()

On 10/04/2013 10:33 AM, Ingo Molnar wrote: * Roy Franz roy.fr...@linaro.org wrote: Remove a redundant memset() call from efi_relocate_kernel() that was clearing memory that would be used by BSS in non-compressed images loaded with this function. This clear was redundant with the clearing

Re: [PATCH -v2] EFI: Runtime services virtual mapping

On 10/02/2013 10:05 AM, Borislav Petkov wrote: Btw, Matt just found another issue with the bottom-up approach - due to different alignment of VA and PA addresses, this messes up the pagetable in terms of the order in which we're using 4K, 2M, etc pages. What can happen is that, you can get

Re: [PATCH -v2] EFI: Runtime services virtual mapping

On 10/02/2013 11:42 AM, Borislav Petkov wrote: Yes, so the alignment has to be such that both PA and VA are the same amount of 4K pages away from the next 2M boundary, to put it bluntly. I have a couple of ideas on how to do that. It's pretty straightforward - just drop the starting

Re: [GIT PULL] EFI changes

On 09/30/2013 03:49 AM, Matt Fleming wrote: Hi, These changes are targetted for the next merge window. Is it possible to get them into linux-next for some vigorous testing? The pending ARM EFI boot stub patches from Roy Franz depend on the x86 EFI boot stub cleanups included in this pull

Re: [PATCH -v2] EFI: Runtime services virtual mapping

On 09/24/2013 07:56 AM, Borislav Petkov wrote: On Tue, September 24, 2013 2:45 pm, Dave Young wrote: Think again about this, how about 1:1 map them from a base address like -64G phy_addr - (-64G + phy_addr), in this way we can avoid depending on the previous region size. Right, how we

Re: [PATCH -v2] EFI: Runtime services virtual mapping

The address that faults is interesting in that it is indeed just below -4G. The question at hand is probably what information you are using to build the EFI mappings in the secondary kernel and what could make it not match the primary. Assuming it isn't as simple as the mappings never get

Re: [PATCH 10/18] Do proper conversion from UTF-16 to UTF-8

Sorry this version is broken and doesn't even compile due to remaining options_size references. Roy Franz roy.fr...@linaro.org wrote: From: H. Peter Anvin h...@zytor.com Improve the conversion of the UTF-16 EFI command line to UTF-8 for passing to the kernel. Signed-off-by: Roy Franz roy.fr

  1   2   >