On 09/09/20 14:44, Laszlo Ersek wrote:
> To summarize: for QemuFlashFvbServicesRuntimeDxe to allocate UEFI
> Runtime Services Data type memory, for its own runtime GHCB, two
> permissions are necessary (together), at OS runtime:
>
> - QemuFlashFvbServicesRuntimeDxe must be
On 09/09/20 10:27, Ard Biesheuvel wrote:
> (adding Laszlo and Brijesh)
>
> On Tue, 8 Sep 2020 at 20:46, Borislav Petkov wrote:
>>
>> + Ard so that he can ack the efi bits.
>>
>> On Mon, Sep 07, 2020 at 03:16:12PM +0200, Joerg Roedel wrote:
>>> From: Tom Lendacky
>>>
>>> Calling down to EFI runtim
ress of first COPY page
> - second page of COPY is marked as not present
> - call to page_mapped(COPY) now triggers fault on access to 2nd
> COPY page at offset 0x30 (_mapcount)
>
> [1]
> https://github.com/jstancek/reproducers/blob/master/kernel/page_mapped_crash/repro.c
>
On 06/16/17 19:03, Philipp Hahn wrote:
> Comparing the corrupted (left) with the supposed (right) driver shows
> the following pattern:
>> /tmp/uefi.bin [+] 15038,1 Alles
>> /tmp/uefi.ko [+]15038,1 Alles
>> 003ac00:
Hi,
did you remove me from the To: / Cc: list intentionally, or was that an
oversight? I caught your message in my list folders only by luck.
Some followup below:
On 05/29/17 17:27, gengdongjiu wrote:
>> (46) What is "physical_addr" good for? Below I can only see an
>> assignment to it, in ghe
On 04/21/17 15:27, gengdongjiu wrote:
> Hi all/Laszlo,
>
> sorry, I have a question to consult with you.
>
>
> On 2017/4/7 2:55, Laszlo Ersek wrote:
>> On 04/06/17 14:35, gengdongjiu wrote:
>>> Dear, Laszlo
>>>Thanks for your detailed explanation
On 04/07/17 04:52, gengdongjiu wrote:
>
> On 2017/4/7 2:55, Laszlo Ersek wrote:
>> I'm unsure if, by "not fixed", you are saying
>>
>> the number of CPER entries that fits in Error Status Data Block N is
>> not *uniform* across 0 <= N <=
On 04/06/17 14:35, gengdongjiu wrote:
> Dear, Laszlo
>Thanks for your detailed explanation.
>
> On 2017/3/29 19:58, Laszlo Ersek wrote:
>> (This ought to be one of the longest address lists I've ever seen :)
>> Thanks for the CC. I'm glad Shannon is already o
On 03/29/17 16:48, Christoffer Dall wrote:
> On Wed, Mar 29, 2017 at 10:36:51PM +0800, gengdongjiu wrote:
>> 2017-03-29 18:36 GMT+08:00, Achin Gupta :
>>> Qemu is essentially fulfilling the role of secure firmware at the
>>> EL2/EL1 interface (as discussed with Christoffer below). So it
>>> should
On 03/29/17 14:51, Michael S. Tsirkin wrote:
> On Wed, Mar 29, 2017 at 01:58:29PM +0200, Laszlo Ersek wrote:
>> (8) When QEMU gets SIGBUS from the kernel -- I hope that's going to come
>> through a signalfd -- QEMU can format the CPER right into guest memory,
>> and then
(This ought to be one of the longest address lists I've ever seen :)
Thanks for the CC. I'm glad Shannon is already on the CC list. For good
measure, I'm adding MST and Igor.)
On 03/29/17 12:36, Achin Gupta wrote:
> Hi gengdongjiu,
>
> On Wed, Mar 29, 2017 at 05:36:37PM +0800, gengdongjiu wrote:
On 11/07/16 17:49, Alex Williamson wrote:
> On Tue, 25 Oct 2016 21:24:25 +0200
> Laszlo Ersek wrote:
>
>> On 10/25/16 20:42, Alex Williamson wrote:
>>> On Tue, 25 Oct 2016 20:24:19 +0200
>>> Laszlo Ersek wrote:
>>>
>>>> Some systems
On 10/25/16 20:24, Laszlo Ersek wrote:
> Some systems have multiple instances of the exact same kind of PCI device
> installed. When VFIO users intend to assign these devices to VMs, they
> occasionally don't want to assign all of them; they'd keep a few for
> host-side us
On 10/27/16 18:41, Radim Krčmář wrote:
> 2016-10-26 23:40+0200, Laszlo Ersek:
>> On 10/26/16 22:50, Radim Krčmář wrote:
>>> [1/2] adds the emulation (and could be split into two patches if you'd
>>> like),
>>> [2/2] just refactors the code.
>>>
&
On 10/26/16 22:50, Radim Krčmář wrote:
> [1/2] adds the emulation (and could be split into two patches if you'd like),
> [2/2] just refactors the code.
>
> This should fix an issue that users are hitting. Laszlo found several
> reports:
> - https://bugs.launchpad.net/qemu/+bug/1623276
> - http
On 10/25/16 21:24, Laszlo Ersek wrote:
> On 10/25/16 20:42, Alex Williamson wrote:
>> FWIW, I think the reason
>> this hasn't been done to date is that PCI bus addresses (except for
>> root bus devices) are not stable. Depending on the system, the address
>> o
On 10/25/16 20:42, Alex Williamson wrote:
> On Tue, 25 Oct 2016 20:24:19 +0200
> Laszlo Ersek wrote:
>
>> Some systems have multiple instances of the exact same kind of PCI device
>> installed. When VFIO users intend to assign these devices to VMs, they
>> occasional
d
Reported-by: Andrei Grigore
Ref: https://www.redhat.com/archives/vfio-users/2016-October/msg00121.html
Signed-off-by: Laszlo Ersek
---
drivers/pci/pci-stub.c | 63 ++
1 file changed, 63 insertions(+)
diff --git a/drivers/pci/pci-stub.c b/driver
On 10/21/16 23:17, Richard W.M. Jones wrote:
> On Fri, Oct 21, 2016 at 02:04:27PM -0700, Andy Lutomirski wrote:
>> https://git.kernel.org/cgit/linux/kernel/git/herbert/cryptodev-2.6.git/commit/?id=6d4952d9d9d4dc2bb9c0255d95a09405a1e958f7
>
> I have tested this one, and it also fixes the bug I was
On 10/21/16 23:04, Andy Lutomirski wrote:
> On Fri, Oct 21, 2016 at 1:48 PM, Laszlo Ersek wrote:
>> The virtio-rng backend for hwrng passes the buffer that it receives for
>> filling to sg_set_buf() directly, in:
>>
>> virtio_read() [drivers/char/hw_random/virtio-
he buffer only temporarily, for every call separately.)
Cc: "Richard W.M. Jones"
Cc:
Cc: Amit Shah
Cc: Andy Lutomirski
Cc: Herbert Xu
Cc: Kees Cook
Cc: Matt Mackall
Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1383451
Fixes: d9e797261933 ("hwrng: add randomness to syst
On 10/21/16 22:32, Laszlo Ersek wrote:
> [...]
Self-NAK, I'll resend in a minute. I added a tag like this:
Cc: # For v3.15+
and git turned it into a garbage email address. I'll drop the "# For
v3.15+" part in the repost.
(I'll also add explicit quotes around Rich
e buffer only temporarily, for every call separately.)
Cc: # For v3.15+
Cc: Amit Shah
Cc: Andy Lutomirski
Cc: Herbert Xu
Cc: Kees Cook
Cc: Matt Mackall
Cc: Richard W.M. Jones
Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1383451
Fixes: d9e797261933 ("hwrng: add randomness to syst
limitation that cpu0 must bind
> to node0")
> Signed-off-by: Lorenzo Pieralisi
> Tested-by: Laszlo Ersek
> Reported-by: Laszlo Ersek
> Cc: Will Deacon
> Cc: Laszlo Ersek
> Cc: Hanjun Guo
> Cc: Andrew Jones
> Cc: Zhen Lei
> Cc: Catalin Marinas
> ---
On 10/14/16 17:42, Lorenzo Pieralisi wrote:
> On Fri, Oct 14, 2016 at 05:27:58PM +0200, Laszlo Ersek wrote:
>> On 10/14/16 17:01, Laszlo Ersek wrote:
>>
>>> Maybe the code I
>>> tried to analyze in this email was never *meant* to associate CPU#0 with
>>
On 10/14/16 15:44, Andrew Jones wrote:
> On Fri, Oct 14, 2016 at 03:18:00PM +0200, Laszlo Ersek wrote:
>> On 10/14/16 10:05, Andrew Jones wrote:
>>> On Fri, Oct 14, 2016 at 12:50:29AM +0200, Laszlo Ersek wrote:
>>>> (4) Analysis (well, a lame attempt at that, becaus
On 10/14/16 17:01, Laszlo Ersek wrote:
> Maybe the code I
> tried to analyze in this email was never *meant* to associate CPU#0 with
> any NUMA node at all (not even node 0); instead, other code -- for
> example code removed by 7ba5f605f3a0 -- was meant to perform that
> associat
On 10/14/16 15:18, Laszlo Ersek wrote:
> On 10/14/16 10:05, Andrew Jones wrote:
>> On Fri, Oct 14, 2016 at 12:50:29AM +0200, Laszlo Ersek wrote:
>>> (4) Analysis (well, a lame attempt at that, because I have zero
>>> familiarity with this code). Let me quote
On 10/14/16 10:05, Andrew Jones wrote:
> On Fri, Oct 14, 2016 at 12:50:29AM +0200, Laszlo Ersek wrote:
>> (4) Analysis (well, a lame attempt at that, because I have zero
>> familiarity with this code). Let me quote the patch:
>>
>>> commit 7ba5f605f3a0d9495aad539eeb8
Hi,
the following regression is experienced in aarch64 qemu/KVM virtual
machines, using the ArmVirtQemu virtual UEFI firmware platform built
from edk2 (EFI Development Kit II).
(1) When booting current master (b67be92feb48) or the bisected first bad
commit (7ba5f605f3a0) with DT enabled, ever
ome other
> cases. Some drivers will need fixes to set suppress_bind_attrs to avoid
> this test.
>
> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=177021
> Fixes: bea5b158ff0d ("driver core: add test of driver remove calls during
> probe")
> Reported-by: Laszlo
Hi,
Greg asked me to stick to email with this bug report, so I'm reposting
the original kernel bugzilla report to personal addresses, and lkml.
Thanks,
Laszlo
https://bugzilla.kernel.org/show_bug.cgi?id=177021
Bug ID: 177021
Summary: [driver core] CONFIG_DEBUG_TEST_DRIVER
On 04/22/16 20:52, Matt Fleming wrote:
> On Thu, 21 Apr, at 06:21:11PM, Laszlo Ersek wrote:
>>
>> ... How about this instead?
>
> Your patch looks fine to me. I've gone ahead and stuck it in the
> urgent EFI queue.
I intended to probe for opinions first, and the
On 04/21/16 14:18, Matt Fleming wrote:
> ( Good Lord, I hate doing string manipulation in C )
>
> On Wed, 20 Apr, at 03:25:32PM, Laszlo Ersek wrote:
>>
>> So, "len" does not include the room for the terminating NUL-byte here.
>> When "len" is pa
20
> [ 170.606475] [] mount_fs+0x10/0x90
> [ 170.606497] [] vfs_kern_mount+0x62/0x100
> [ 170.606508] [] do_mount+0x1e0/0xcd0
> [ 170.606519] [] SyS_mount+0x8f/0xd0
> [ 170.606530] [] entry_SYSCALL_64_fastpath+0x17/0x93
> [ 170.606542] [] 0x
>
> Cc: Matt
On 04/20/16 11:41, Chris Wilson wrote:
> On Wed, Apr 20, 2016 at 11:36:37AM +0200, Laszlo Ersek wrote:
>> On 04/20/16 10:37, Chris Wilson wrote:
>>> If the caller, in this case efivarfs_callback(), only provides sufficent
>>> room for the expanded utf8 and not enough to
170.606508] [] do_mount+0x1e0/0xcd0
> [ 170.606519] [] SyS_mount+0x8f/0xd0
> [ 170.606530] [] entry_SYSCALL_64_fastpath+0x17/0x93
> [ 170.606542] [] 0x
>
> Cc: Matt Fleming
> Cc: Jason Andryuk
> Cc: Matthew Garrett
> Cc: Laszlo Ersek
> Cc: Peter
On 03/09/16 10:45, David Woodhouse wrote:
> On Tue, 2014-12-23 at 09:32 -0700, Jonathan Corbet wrote:
>>
>> -16) Sending "git pull" requests (from Linus emails)
>> +16) Sending "git pull" requests
>> +---
>> +
>> +If you have a series of patches, it may be most conven
mp; 0x7c0) >> 6;
Byte #1 is supposed to consume the 5 most significant bits, from the 11
bits that the code point has:
0111 -- bin
0 7f f-- hex -- all it can have
123 45
0111 1100 -- bin
0 7c 0-- hex -- mask is okay
Shift count of 6 looks okay.
>> +dest[j++] = 0x80 | (c & 0x03f);
Byte #2 is supposed to consume the remaining 6 bits:
123456
0011 -- bin
0 03 f-- hex - mask is okay
Maybe if we could write the mask as 0x3f, instead of 0x03f.
Reviewed-by: Laszlo Ersek
>> } else {
>> maxlength -= 1;
>> dest[j++] = c & 0x7f;
>> --
>> 2.4.3
>>
On 02/09/16 13:20, Ingo Molnar wrote:
>
> * Elliott, Robert (Persistent Memory) wrote:
>
>>
>>> -Original Message-
>>> From: Matt Fleming [mailto:m...@codeblueprint.co.uk]
>>> Sent: Wednesday, February 3, 2016 5:28 AM
>>> To:
efi: mem61: [Persistent Memory | | | | | | | |WB|WT|WC|UC]
> range=[0x00088000-0x000c7fff] (16 GiB)
>
> Signed-off-by: Robert Elliott
> Signed-off-by: Andy Shevchenko
> Cc: Thomas Gleixner
> Cc: Ingo Molnar
> Cc: "H. Peter Anvi
Molnar
> Cc: "H. Peter Anvin"
> Cc: Ard Biesheuvel
> Cc: Taku Izumi
> Cc: Laszlo Ersek
> Signed-off-by: Matt Fleming
> ---
> drivers/firmware/efi/efi.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/firmware/efi/efi
mas Gleixner
> Cc: Ingo Molnar
> Cc: "H. Peter Anvin"
> Cc: Ard Biesheuvel
> Cc: Taku Izumi
> Cc: Laszlo Ersek
> Signed-off-by: Matt Fleming
> ---
> drivers/firmware/efi/efi.c | 5 -
> include/linux/efi.h| 1 +
> 2 files changed, 5 insertio
B|WT|WC|UC]
> range=[0x00088000-0x000c7fff] (16384MB)
>
> Signed-off-by: Robert Elliott
> Cc: Thomas Gleixner
> Cc: Ingo Molnar
> Cc: "H. Peter Anvin"
> Cc: Ard Biesheuvel
> Cc: Leif Lindholm
> Cc: Laszlo Ersek
> Signed-off-by: Matt F
On 11/24/15 18:38, Eric Blake wrote:
> On 11/24/2015 09:55 AM, Gabriel L. Somlo wrote:
>> On Tue, Nov 24, 2015 at 04:14:50AM +0800, kbuild test robot wrote:
>
>>>
>>>drivers/firmware/qemu_fw_cfg.c: In function 'fw_cfg_cmdline_set':
> drivers/firmware/qemu_fw_cfg.c:510:7: warning: format '%
ed-off-by: Gabriel Somlo
> Cc: Laszlo Ersek
> ---
> Documentation/devicetree/bindings/arm/fw-cfg.txt | 38
> ++--
> 1 file changed, 2 insertions(+), 36 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/arm/fw-cfg.txt
> b/Document
On 11/03/15 15:04, Paolo Bonzini wrote:
>
>
> On 03/11/2015 15:02, Laszlo Ersek wrote:
>> On 11/03/15 14:46, Paolo Bonzini wrote:
>>>
>>>
>>> On 03/11/2015 14:40, Laszlo Ersek wrote:
>>>> On 11/03/15 14:29, Paolo Bonzini wrote:
>>>
On 11/03/15 14:46, Paolo Bonzini wrote:
>
>
> On 03/11/2015 14:40, Laszlo Ersek wrote:
>> On 11/03/15 14:29, Paolo Bonzini wrote:
>>> The SDM says that exiting system management mode from 64-bit mode
>>> is invalid, but that would be too good to be true. But
all the way from 64-bit
> mode to real mode only requires clearing CS.L and CR4.PCIDE.
>
> Cc: sta...@vger.kernel.org
> Fixes: 660a5d517aaab9187f93854425c4c63f4a09195c
> Cc: Laszlo Ersek
> Cc: Radim Krčmář
> Signed-off-by: Paolo Bonzini
> ---
> arch/x86/kvm/emulate.c |
On 11/02/15 10:32, Paolo Bonzini wrote:
>
>
> On 31/10/2015 20:50, Laszlo Ersek wrote:
>> Tested-by: Laszlo Ersek
>
> Thanks Laszlo, I applied patches 1 and 2 (since your "part 2" never was :)).
>
> Paolo
>
Thanks.
Since you can rebase the queue fr
ted mode
>
> arch/x86/include/asm/kvm_emulate.h | 10 +
> arch/x86/kvm/emulate.c | 44
> +-
> arch/x86/kvm/x86.c | 10 +
> 3 files changed, 30 insertions(+), 34 deletions(-)
>
Tested-by: Laszlo Er
On 10/08/15 17:03, Marc Marí wrote:
> Add fw_cfg DMA interface specfication in the fw_cfg documentation.
>
> Signed-off-by: Marc Marí
> ---
> Documentation/devicetree/bindings/arm/fw-cfg.txt | 52
> +++-
> 1 file changed, 51 insertions(+), 1 deletion(-)
>
> diff --git a/Doc
On 10/04/15 01:28, Gabriel L. Somlo wrote:
> From: Gabriel Somlo
>
> Make fw_cfg entries of type "file" available via sysfs. Entries
> are listed under /sys/firmware/qemu_fw_cfg/by_key, in folders
> named after each entry's selector key. Filename, selector value,
> and size read-only attributes a
On 10/05/15 15:05, Mark Rutland wrote:
>>> I'm not sure I follow what the difficulty with supporting DT in addition
>>> to ACPI is? It looks like all you need is a compatible string and a reg
>>> entry.
>>
>> Bearing in mind that I have almost no experience with arm:
>>
>> I started out by probing
On 10/01/15 18:21, Eric Blake wrote:
> On 10/01/2015 10:17 AM, Laszlo Ersek wrote:
>> On 10/01/15 18:03, Eric Blake wrote:
>>> [meta-comment]
>>>
>>> On 10/01/2015 06:14 AM, Marc Marí wrote:
>>>> Implementation of the FW CFG DMA interface.
>>
On 10/01/15 18:11, Eric Blake wrote:
> On 10/01/2015 10:03 AM, Eric Blake wrote:
>> [meta-comment]
>>
>> On 10/01/2015 06:14 AM, Marc Marí wrote:
>>> Implementation of the FW CFG DMA interface.
>>
>> The subject line is missing "v4" and "0/7". Also, the cover letter is
>> missing a diffstat. That
On 10/01/15 18:03, Eric Blake wrote:
> [meta-comment]
>
> On 10/01/2015 06:14 AM, Marc Marí wrote:
>> Implementation of the FW CFG DMA interface.
>
> The subject line is missing "v4" and "0/7". Also, the cover letter is
> missing a diffstat. That makes it harder to see from the cover letter
> wh
On 09/28/15 08:41, Matthew Garrett wrote:
> On Mon, Sep 28, 2015 at 08:16:46AM +0200, Ingo Molnar wrote:
>
>> So the question is, what does Windows do?
>
> It's pretty trivial to hack OVMF to dump the SetVirtualAddressMap()
> arguments to the qemu debug port. Unfortunately I'm about to drop
> mostl
On 09/07/15 13:08, Gerd Hoffmann wrote:
> Hi,
>
>> It's just simplicity. If you want to read a few times from the same
>> field (like in ACPI tables, read the data size and then the data), you
>> need a way to enable and disable the selector and manage the current
>> offset for that entry. This
On 08/06/15 13:03, Marc Marí wrote:
> Add fw_cfg DMA interface specfication in the fw_cfg documentation.
>
> Signed-off-by: Marc Marí
> ---
> Documentation/devicetree/bindings/arm/fw-cfg.txt | 36
>
> 1 file changed, 36 insertions(+)
>
> diff --git a/Documentation/devi
On 08/06/15 16:28, Andrew Jones wrote:
> On Thu, Aug 06, 2015 at 04:19:18PM +0200, Marc Marí wrote:
>> On Thu, 6 Aug 2015 16:08:49 +0200
>> Andrew Jones wrote:
>>
>>> On Thu, Aug 06, 2015 at 01:03:07PM +0200, Marc Marí wrote:
Add fw_cfg DMA interface specfication in the fw_cfg documentation.
On 08/06/15 14:12, Stefan Hajnoczi wrote:
> On Thu, Aug 6, 2015 at 12:03 PM, Marc Marí wrote:
>> Add fw_cfg DMA interface specfication in the fw_cfg documentation.
>>
>> Signed-off-by: Marc Marí
>> ---
>> Documentation/devicetree/bindings/arm/fw-cfg.txt | 36
>>
>> 1 fi
On 07/15/15 21:30, Xiao Guangrong wrote:
>
> Hi,
>
> I have posted the pachset to make OVMF happy and have CCed you guys,
> could you please check it if it works for you?
Sorry, I can't check it; I don't have an environment that exposes the
issue in the first place. Perhaps Alex can check it, or
On 07/15/15 00:37, Jordan Justen wrote:
> On 2015-07-14 14:29:11, Laszlo Ersek wrote:
>> On 07/14/15 23:15, Paolo Bonzini wrote:
>>>> The long delay that Alex reported (for the case when all guest memory
>>>> was set to UC up-front) is due to the fact that the SE
On 07/14/15 23:15, Paolo Bonzini wrote:
>> The long delay that Alex reported (for the case when all guest memory
>> was set to UC up-front) is due to the fact that the SEC phase of OVMF
>> decompresses an approximately 1712 KB sized, LZMA-compressed blob, to
>> approx. 896 KB worth of PEI drivers a
Cross-posting to edk2-devel.
Original sub-thread starts here:
http://thread.gmane.org/gmane.linux.kernel/1952205/focus=1994315
On 07/13/15 17:15, Xiao Guangrong wrote:
>
>
> On 07/13/2015 11:13 PM, Paolo Bonzini wrote:
>> On 13/07/2015 16:45, Xiao Guangrong wrote:
+/* MTRR is completel
On 07/10/15 16:59, Paolo Bonzini wrote:
>
>
> On 10/07/2015 16:57, Laszlo Ersek wrote:
>>>> ... In any case, please understand that I'm not campaigning for this
>>>> warning :) IIRC the warning was your (very welcome!) idea after I
>>>> report
On 07/10/15 16:13, Paolo Bonzini wrote:
>
>
> On 09/07/2015 20:57, Laszlo Ersek wrote:
>>> Without EPT, you don't
>>> hit the processor limitation with your setup, but the user should
>>> nevertheless
>>> still be notified.
>>
>> I
On 07/09/15 22:02, Bandan Das wrote:
> Laszlo Ersek writes:
> ...
>> Yes.
>>
>>> Without EPT, you don't
>>> hit the processor limitation with your setup, but the user should
>>> nevertheless
>>> still be notified.
>>
>> I d
On 07/09/15 20:32, Bandan Das wrote:
> Paolo Bonzini writes:
>
>> On 09/07/2015 08:43, Laszlo Ersek wrote:
>>> On 07/09/15 08:09, Paolo Bonzini wrote:
>>>>
>>>>
>>>> On 09/07/2015 00:36, Bandan Das wrote:
>>>>> Let userspace
On 07/09/15 08:09, Paolo Bonzini wrote:
>
>
> On 09/07/2015 00:36, Bandan Das wrote:
>> Let userspace inquire the maximum physical address width
>> of the host processors; this can be used to identify maximum
>> memory that can be assigned to the guest.
>>
>&g
_MAX pages) and is rather a cleanup. The patch is
> supposed to be applied on top of previously sent 'Drivers: hv: hv_balloon:
> survive ballooning request with num_pages=0'.
>
> Both issues were found by Laszlo Ersek during code review.
>
> Vitaly Kuznetsov (2):
>
; 104 + 2048/8 = 360
> Right limit:
> 256 + 2048/16 = 384 (so the right value is 232)
>
> We now have to make an adjustment at 8192 boundary:
> 232 + 8192/16 = 744
> 512 + 8192/32 = 768 (so the right value is 488)
>
> Suggested-by: Laszlo Ersek
> Signed-off-by: Vital
pre- and post-patch code enter
> 'more_pages = 0' branch and finish.
>
> So this patch has two real effects:
> 1) We reply with an empty response to 'num_pages=0' request.
> 2) We try a bit harder on alloc_unit=1 allocations (and reply with an empty
>
On 03/05/15 15:47, Mark Rutland wrote:
> Several dts only list "arm,cortex-a7-gic" or "arm,gic-400" in their GIC
> compatible list, and while this is correct (and supported by the GIC
> driver), KVM will fail to detect that it can support these cases.
>
> This patch adds the missing strings to the
On 01/30/15 17:43, Borislav Petkov wrote:
> From: Borislav Petkov
> Date: Mon, 26 Jan 2015 19:49:59 +0100
> Subject: [PATCH] efi, x86: Add a "debug" option to the efi= cmdline
>
> ... and hide the memory regions dump behind it. Make it default-off.
>
> Signed-off-by: Borislav Petkov
> Link: htt
On 01/10/15 20:56, Linus Torvalds wrote:
> On Sat, Jan 10, 2015 at 11:47 AM, Laszlo Ersek wrote:
>>
>> I grepped the tree for "fullmm", and only tlb_gather_mmu() seems to set
>> it. There are several instances of that function, but each sets fullmm to:
>
On 01/10/15 14:37, Will Deacon wrote:
> My hunch is that when a task exits and sets fullmm, end is zero and so the
> old need_flush cases no longer run.
(Disclaimer: I'm completely unfamiliar with this code.)
If you have the following call chain in mind:
exit_mmap()
tlb_gather_mmu()
then
On 01/09/15 20:43, Will Deacon wrote:
> On Fri, Jan 09, 2015 at 06:37:36PM +, Marc Zyngier wrote:
>> On 09/01/15 17:57, Mark Rutland wrote:
>>> On Fri, Jan 09, 2015 at 02:27:06PM +, Mark Langsdorf wrote:
On 01/09/2015 08:19 AM, Steve Capper wrote:
> On 9 January 2015 at 12:13, Mark
G at mm/slub.c:3341!'
>
> Solve the issue by making name a fixed length string inside struct
> xen_clock_event_device. 16 bytes should be enough.
>
> Suggested-by: Laszlo Ersek
> Signed-off-by: Vitaly Kuznetsov
> ---
> Changes from v1 (David Vrabel):
> - add
On 01/05/15 15:03, Matt Fleming wrote:
> On Wed, 10 Dec, at 11:46:28AM, Borislav Petkov wrote:
>> On Wed, Dec 10, 2014 at 10:17:41AM +0800, Dave Young wrote:
>>> I have same feeling with you, it is too long for most of people.
>>>
>>> Since the printk code are for EFI_DEBUG, they are around the #if
(), kernel is supposed to crash with
>> 'kernel BUG at mm/slub.c:3341!'
>>
>> Solve the issue by making name a fixed length string inside struct
>> xen_clock_event_device. 16 bytes should be enough.
>>
>> The issue was discovered by Laszlo Ersek.
>
>
On 12/09/14 10:58, Borislav Petkov wrote:
> Hi guys,
>
> so this decoded EFI regions output is nice but can we shorten it? It
> sticks too far out in the terminal more than anything else in dmesg and
> staring at it needs me to resize window and such. It probably is an even
> bigger problem if one
IO is being returned. It seems
> that
>-EOPNOTSUPP is more appropriate here.
> Fix all of the above issues.
>
> This patch is based on the original patch by Laszlo Ersek and a comment by
> Jeff Moyer.
>
> Signed-off-by: Vitaly Kuznetsov
> ---
> drivers/block/xen-bl
O code in Aug 2013
> which may possibly be related, commit 4e39b75e ("MdeModulePkg/DiskIoDxe:
> fix source/destination pointer of overrun transfer").
>
> Whatever the cause, it's unlikely that a fix will be forthcoming
> from the vendor, hence the workaround
On 09/05/14 19:03, Yinghai Lu wrote:
> On Thu, Sep 4, 2014 at 11:38 PM, Laszlo Ersek wrote:
>> On 09/05/14 07:47, Anders Darander wrote:
>> In other words, the rounding up of the kernel will be undone in a
>> "somewhat higher level" driver in the firmware, and t
On 09/05/14 07:47, Anders Darander wrote:
> * Yinghai Lu [140905 03:19]:
>
>
>> On Thu, Sep 4, 2014 at 2:29 PM, Matt Fleming wrote:
>>> On Thu, 04 Sep, at 01:59:05PM, H. Peter Anvin wrote:
>
I am fine with this patch, but at the same time I do want to note that
there is an alternativ
On 09/03/14 15:01, Ard Biesheuvel wrote:
> On 3 September 2014 13:32, Laszlo Ersek wrote:
>> changes in v2:
>> - explain with examples how the log's appearance changes, in patches 3-5
>> [Ingo]
>>
>> v1 blurb:
>>
>>> It's a pain
On 09/03/14 15:18, Matt Fleming wrote:
> On Wed, 03 Sep, at 03:01:31PM, Ard Biesheuvel wrote:
>>
>> Tested-by: Ard Biesheuvel
>> (on arm64 only)
>>
>> +1 for aligning between architectures
>> +1 for cleaning up the output to make it more readable
>
> Thanks Ard.
Ah, apologies for forgetting to
dropped in order to match the kernel coding
style more closely. The element size is tightened from 32 to 20 bytes
(maximum actual string length + 1) so that we can derive the field width
from the element size.
Signed-off-by: Laszlo Ersek
---
include/linux/efi.h| 7 ++
drivers/firmware
The effects of the patch on the i64 memory map log are similar to those
visible in the previous (x86) patch: the type enum and the attribute
bitmap are decoded.
Signed-off-by: Laszlo Ersek
---
arch/ia64/kernel/efi.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch
those columns human-readable, and unifies
> their formatting between x86, ia64 and arm64.
Thanks
Laszlo
Laszlo Ersek (5):
efi: add macro for EFI_MEMORY_UCE memory attribute
efi: introduce efi_md_typeattr_format()
x86: efi: format EFI memory type & attrs with efi_md_typeattr_format
Add the following macro from the UEFI spec, for completeness:
EFI_MEMORY_UCE Memory cacheability attribute: The memory region
supports being configured as not cacheable, exported,
and supports the "fetch and add" semaphore mechanism.
Signed-off-
0-0x07f06000) (0MB)
> efi: mem32: [Boot Data | | | | | |WB|WT|WC|UC]
> range=[0x07f06000-0x07fd) (0MB)
> efi: mem33: [Runtime Data |RUN| | | | |WB|WT|WC|UC]
> range=[0x07fd-0x07ff) (0MB)
> efi: mem34: [Con
> |WB|WT|WC|UC]*
> 0x9f1b-0x9f1b0fff [Runtime Data |RUN| | | |
> |WB|WT|WC|UC]*
> 0x9f1b1000-0x00009fffffff [Boot Data | | | | |
> |WB|WT|WC|UC]*
> 0x0400-0x07ff [Memory Mapped I/O |RUN| | | | | | |
> |UC]
&
On 09/01/14 09:22, Ingo Molnar wrote:
>
> * Laszlo Ersek wrote:
>
>> It's a pain to analyze EFI memmap logs while debugging, especially to
>> verify the memory types (an enum) and the memory attributes (a bitmap).
>> This series renders those columns h
0.00] efi: mem32: [Boot Data | | | | | |WB|WT|WC|UC]
> range=[0x07f06000-0x07fd) (0MB)
> [0.00] efi: mem33: [Runtime Data |RUN| | | | |WB|WT|WC|UC]
> range=[0x07fd-0x07ff) (0MB)
> [0.00]
Signed-off-by: Laszlo Ersek
---
arch/ia64/kernel/efi.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/ia64/kernel/efi.c b/arch/ia64/kernel/efi.c
index 741b99c..c52d754 100644
--- a/arch/ia64/kernel/efi.c
+++ b/arch/ia64/kernel/efi.c
@@ -568,6 +568,7 @@ efi_init
Add the following macro from the UEFI spec, for completeness:
EFI_MEMORY_UCE Memory cacheability attribute: The memory region
supports being configured as not cacheable, exported,
and supports the "fetch and add" semaphore mechanism.
Signed-off-
Signed-off-by: Laszlo Ersek
---
arch/x86/platform/efi/efi.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
index 850da94..ae2573a 100644
--- a/arch/x86/platform/efi/efi.c
+++ b/arch/x86/platform/efi/efi.c
1 - 100 of 117 matches
Mail list logo
