On 09/16/13 12:59, Matt Fleming wrote:
> On Fri, 13 Sep, at 02:38:12PM, jerry.hoem...@hp.com wrote:
>> Matt,
>>
>> We have hit an issue on our new platform in development related to the
>> call of efi_reserve_boot_services() from setup_arch().
>>
>> The reservation can interfere with allocation of
On 09/16/13 17:57, Josh Triplett wrote:
>> The edk2 commit that flipped the memory type underneath the image data
>> from EfiReservedMemoryType to EfiBootServicesData is:
>>
>> https://github.com/tianocore/edk2/commit/4c58575e
>>
>> I think this commit is wrong. It's fine for OSPM to release t
On 08/01/13 18:49, Borislav Petkov wrote:
> On Wed, Jul 31, 2013 at 10:55:27PM +0100, David Woodhouse wrote:
>> On Wed, 2013-07-31 at 22:54 +0200, Borislav Petkov wrote:
>>> so I'm seeing this funny thing where an EFI region changes when we enter
>>> efi_enter_virtual_mode when booting with edk2 on
On 08/05/13 15:02, Borislav Petkov wrote:
> On Mon, Aug 05, 2013 at 01:27:16PM +0200, Laszlo Ersek wrote:
>>> --- before 2013-07-31 22:20:52.316039492 +0200
>>> +++ after 2013-07-31 22:21:30.960731706 +0200
>>> @@ -9,7 +9,7 @@ efi: mem07: type=2, attr=0
On 08/05/13 16:03, Borislav Petkov wrote:
> On Mon, Aug 05, 2013 at 03:39:31PM +0200, Laszlo Ersek wrote:
>> My question was: is my understanding correct that you only see this
>> problem with "-enable-kvm"? Because,
>>
>> On 08/01/13 18:49, Borislav Petko
On 08/05/13 16:40, Borislav Petkov wrote:
> On Mon, Aug 05, 2013 at 04:27:44PM +0200, Laszlo Ersek wrote:
>> I wouldn't call the design of SetVirtualAddressMap() braindead.
>
> Ok, I've always wondered and you could probably shed some light on the
> matter: why is S
Apologies in advance for my response because it diverges from the
technical stuff.
On 08/05/13 17:34, James Bottomley wrote:
> On Mon, 2013-08-05 at 17:15 +0200, Laszlo Ersek wrote:
>> On 08/05/13 16:40, Borislav Petkov wrote:
>>> On Mon, Aug 05, 2013 at 04:27:44PM +0200,
On 08/05/13 18:12, Borislav Petkov wrote:
> On Mon, Aug 05, 2013 at 05:15:38PM +0200, Laszlo Ersek wrote:
>> The current implementation (how pointers are converted) probably doesn't
>> accommodate a second call.
>>
>> Of course you want to know why SetVirtualAddres
On 08/05/13 18:47, Borislav Petkov wrote:
> On Mon, Aug 05, 2013 at 06:41:20PM +0200, Laszlo Ersek wrote:
>> I didn't realize the timestamps survive kexec. (As far as I remember
>> the kernels I played with kexec on didn't have the automatic
>> timestamps yet in dm
On 08/05/13 18:47, Borislav Petkov wrote:
> Here's the whole dmesg up until efi_enter_virtual_map. When we have entered
> efi_enter_virtual_mode, the region has changed from
>
> [0.00] efi: mem11: type=4, attr=0xf,
> range=[0x7e0ad000-0x7e0cc000) (0MB)
>
> to
>
> [0
On 08/05/13 23:41, Borislav Petkov wrote:
> On Mon, Aug 05, 2013 at 02:37:08PM -0700, H. Peter Anvin wrote:
>> All of this would be a non-problem if there weren't buggy
>> implementations which can't run *without* SetVirtualAddressMap().
>
> Oh, you mean, if we were to call the runtime services th
On 08/06/13 00:52, James Bottomley wrote:
> On Mon, 2013-08-05 at 23:55 +0200, Laszlo Ersek wrote:
>> On 08/05/13 23:41, Borislav Petkov wrote:
>>> On Mon, Aug 05, 2013 at 02:37:08PM -0700, H. Peter Anvin wrote:
>>>> All of this would be a non-problem if there were
On 08/06/13 16:10, Borislav Petkov wrote:
> On Tue, Aug 06, 2013 at 12:08:08AM +0200, Borislav Petkov wrote:
>> Ok, thanks again for finding it, I'll go and try to figure out the whole
>> mess tomorrow.
>
> Ok, some more observations:
>
> Decompressing Linux... Parsing ELF... done.
> Booting the
On 08/07/13 17:19, Borislav Petkov wrote:
> On Tue, Aug 06, 2013 at 05:31:29PM +0200, Laszlo Ersek wrote:
>> Can you capture the OVMF debug output? Do you see
>>
>> ConvertPages: Incompatible memory types
>>
>> there?
>>
>> Can you set the follow
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 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/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 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 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 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: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.
>>
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 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
(), 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 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
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/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
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/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 08/20/14 22:30, Matt Fleming wrote:
> [ Pulling in EDK2 folks for help ]
>
> On Wed, 20 Aug, at 08:53:45PM, Michael Brown wrote:
>> On 20/08/14 20:05, Mantas Mikulėnas wrote:
>>>
>>> I experimented with some things (like setting chunk size to a few kB
>>> to see if it hangs earlier or only at t
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/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
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/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/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
Signed-off-by: Laszlo Ersek
---
arch/arm64/kernel/efi.c | 26 ++
1 file changed, 6 insertions(+), 20 deletions(-)
diff --git a/arch/arm64/kernel/efi.c b/arch/arm64/kernel/efi.c
index 03aaa99..3b1f23c 100644
--- a/arch/arm64/kernel/efi.c
+++ b/arch/arm64/kernel/efi.c
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
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
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.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
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
> |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]
&
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
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
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
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
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
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/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
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 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 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 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 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 '%
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:
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
>>
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
>
; 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
_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):
>
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
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 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
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/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
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
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
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
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 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 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 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
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/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
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 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/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 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
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
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
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
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
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 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-
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/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
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: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
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/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
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/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/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/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
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
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
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
1 - 100 of 117 matches
Mail list logo
