Re: [PATCH v7 71/72] x86/efi: Add GHCB mappings when SEV-ES is active

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

Re: [PATCH v7 71/72] x86/efi: Add GHCB mappings when SEV-ES is active

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

Re: [PATCH v2] mm: page_mapped: don't assume compound page is huge or THP

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 > > Fix the loop

Re: [PATCH v2] mm: page_mapped: don't assume compound page is huge or THP

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 > > Fix the loop

Re: [Qemu-devel] [RFH] qemu-2.6 memory corruption with OVMF and linux-4.9

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 >>

Re: [Qemu-devel] [RFH] qemu-2.6 memory corruption with OVMF and linux-4.9

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 >>

Re: [Qemu-devel] [PATCH v3 1/4] ACPI: Add APEI GHES Table Generation support

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

Re: [Qemu-devel] [PATCH v3 1/4] ACPI: Add APEI GHES Table Generation support

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

Re: [PATCH] kvm: pass the virtual SEI syndrome to guest OS

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

Re: [PATCH] kvm: pass the virtual SEI syndrome to guest OS

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

Re: [PATCH] kvm: pass the virtual SEI syndrome to guest OS

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 <= 10 [

Re: [PATCH] kvm: pass the virtual SEI syndrome to guest OS

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 <= 10 [

Re: [PATCH] kvm: pass the virtual SEI syndrome to guest OS

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 on the CC l

Re: [PATCH] kvm: pass the virtual SEI syndrome to guest OS

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 on the CC l

Re: [PATCH] kvm: pass the virtual SEI syndrome to guest OS

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

Re: [PATCH] kvm: pass the virtual SEI syndrome to guest OS

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 >>>

Re: [PATCH] kvm: pass the virtual SEI syndrome to guest OS

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 inje

Re: [PATCH] kvm: pass the virtual SEI syndrome to guest OS

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 inje

Re: [PATCH] kvm: pass the virtual SEI syndrome to guest OS

(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:

Re: [PATCH] kvm: pass the virtual SEI syndrome to guest OS

(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:

Re: [PATCH] PCI: pci-stub: accept exceptions to the ID- and class-based matching

On 11/07/16 17:49, Alex Williamson wrote: > On Tue, 25 Oct 2016 21:24:25 +0200 > Laszlo Ersek <ler...@redhat.com> wrote: > >> On 10/25/16 20:42, Alex Williamson wrote: >>> On Tue, 25 Oct 2016 20:24:19 +0200 >>> Laszlo Ersek <ler...@redhat.com>

Re: [PATCH] PCI: pci-stub: accept exceptions to the ID- and class-based matching

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

Re: [PATCH] PCI: pci-stub: accept exceptions to the ID- and class-based matching

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 use. Th

Re: [PATCH] PCI: pci-stub: accept exceptions to the ID- and class-based matching

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 use. Th

Re: [PATCH 0/2] KVM: x86: emulate fxsave and fxrstor

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. >>> >&g

Re: [PATCH 0/2] KVM: x86: emulate fxsave and fxrstor

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. >>> >&g

Re: [PATCH 0/2] KVM: x86: emulate fxsave and fxrstor

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 > -

Re: [PATCH 0/2] KVM: x86: emulate fxsave and fxrstor

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 > -

Re: [PATCH] PCI: pci-stub: accept exceptions to the ID- and class-based matching

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

Re: [PATCH] PCI: pci-stub: accept exceptions to the ID- and class-based matching

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

Re: [PATCH] PCI: pci-stub: accept exceptions to the ID- and class-based matching

On 10/25/16 20:42, Alex Williamson wrote: > On Tue, 25 Oct 2016 20:24:19 +0200 > Laszlo Ersek <ler...@redhat.com> 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,

Re: [PATCH] PCI: pci-stub: accept exceptions to the ID- and class-based matching

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

[PATCH] PCI: pci-stub: accept exceptions to the ID- and class-based matching

@gmail.com> Cc: Bjorn Helgaas <bhelg...@google.com> Cc: Jayme Howard <g.pr...@gmail.com> Reported-by: Andrei Grigore <andrei@gmail.com> Ref: https://www.redhat.com/archives/vfio-users/2016-October/msg00121.html Signed-off-by: Laszlo Ersek &l

[PATCH] PCI: pci-stub: accept exceptions to the ID- and class-based matching

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/drivers/pci/pci-stub.

Re: [PATCH RESEND] hwrng: core - don't pass stack allocated buffer to rng->read()

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

Re: [PATCH RESEND] hwrng: core - don't pass stack allocated buffer to rng->read()

On 10/21/16 23:04, Andy Lutomirski wrote: > On Fri, Oct 21, 2016 at 1:48 PM, Laszlo Ersek <ler...@redhat.com> wrote: >> The virtio-rng backend for hwrng passes the buffer that it receives for >> filling to sg_set_buf() directly, in: >> >> virtio_read() [dr

Re: [PATCH RESEND] hwrng: core - don't pass stack allocated buffer to rng->read()

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

Re: [PATCH RESEND] hwrng: core - don't pass stack allocated buffer to rng->read()

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-

[PATCH RESEND] hwrng: core - don't pass stack allocated buffer to rng->read()

Kees Cook <keesc...@chromium.org> Cc: Matt Mackall <m...@selenic.com> Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1383451 Fixes: d9e797261933 ("hwrng: add randomness to system from rng sources") See-also: 5e59d9a1aed2 ("virtio_console: Stop doing DMA on the stack") Rep

[PATCH RESEND] hwrng: core - don't pass stack allocated buffer to rng->read()

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

Re: [PATCH] hwrng: core - don't pass stack allocated buffer to rng->read()

On 10/21/16 22:32, Laszlo Ersek wrote: > [...] Self-NAK, I'll resend in a minute. I added a tag like this: Cc: <sta...@vger.kernel.org> # 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 q

Re: [PATCH] hwrng: core - don't pass stack allocated buffer to rng->read()

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's name -- I ha

[PATCH] hwrng: core - don't pass stack allocated buffer to rng->read()

Matt Mackall <m...@selenic.com> Cc: Richard W.M. Jones <rjo...@redhat.com> Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1383451 Fixes: d9e797261933 ("hwrng: add randomness to system from rng sources") See-also: 5e59d9a1aed2 ("virtio_console: Stop doing DMA on the s

[PATCH] hwrng: core - don't pass stack allocated buffer to rng->read()

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

Re: [PATCH] arm64: kernel: numa: fix ACPI boot cpu numa node mapping

e the limitation that cpu0 must bind > to node0") > Signed-off-by: Lorenzo Pieralisi <lorenzo.pieral...@arm.com> > Tested-by: Laszlo Ersek <ler...@redhat.com> > Reported-by: Laszlo Ersek <ler...@redhat.com> > Cc: Will Deacon <will.dea...@arm.com> > Cc: Laszlo Ers

Re: [PATCH] arm64: kernel: numa: fix ACPI boot cpu numa node mapping

tation 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 > --- >

Re: aarch64 ACPI boot regressed by commit 7ba5f605f3a0 ("arm64/numa: remove the limitation that cpu0 must bind to node0")

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 >>

Re: aarch64 ACPI boot regressed by commit 7ba5f605f3a0 ("arm64/numa: remove the limitation that cpu0 must bind to node0")

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 >>

Re: aarch64 ACPI boot regressed by commit 7ba5f605f3a0 ("arm64/numa: remove the limitation that cpu0 must bind to node0")

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

Re: aarch64 ACPI boot regressed by commit 7ba5f605f3a0 ("arm64/numa: remove the limitation that cpu0 must bind to node0")

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

Re: aarch64 ACPI boot regressed by commit 7ba5f605f3a0 ("arm64/numa: remove the limitation that cpu0 must bind to node0")

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 > associ

Re: aarch64 ACPI boot regressed by commit 7ba5f605f3a0 ("arm64/numa: remove the limitation that cpu0 must bind to node0")

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 > associ

Re: aarch64 ACPI boot regressed by commit 7ba5f605f3a0 ("arm64/numa: remove the limitation that cpu0 must bind to node0")

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

Re: aarch64 ACPI boot regressed by commit 7ba5f605f3a0 ("arm64/numa: remove the limitation that cpu0 must bind to node0")

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

Re: aarch64 ACPI boot regressed by commit 7ba5f605f3a0 ("arm64/numa: remove the limitation that cpu0 must bind to node0")

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

Re: aarch64 ACPI boot regressed by commit 7ba5f605f3a0 ("arm64/numa: remove the limitation that cpu0 must bind to node0")

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

aarch64 ACPI boot regressed by commit 7ba5f605f3a0 ("arm64/numa: remove the limitation that cpu0 must bind to node0")

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,

aarch64 ACPI boot regressed by commit 7ba5f605f3a0 ("arm64/numa: remove the limitation that cpu0 must bind to node0")

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,

Re: [PATCH 1/2] driver core: skip removal test for non-removable drivers

ther > 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 Ersek

Re: [PATCH 1/2] driver core: skip removal test for non-removable drivers

ther > 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 Erse

CONFIG_DEBUG_TEST_DRIVER_REMOVE causes unremovable drivers to bind devices twice

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_REMOVE causes unremovable drivers to bind devices twice

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]

Re: [PATCH] lib: Always NUL terminate ucs2_as_utf8

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 then

Re: [PATCH] lib: Always NUL terminate ucs2_as_utf8

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 then

Re: [PATCH] lib: Always NUL terminate ucs2_as_utf8

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

Re: [PATCH] lib: Always NUL terminate ucs2_as_utf8

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

Re: [PATCH] lib: Always NUL terminate ucs2_as_utf8

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

Re: [PATCH] lib: Always NUL terminate ucs2_as_utf8

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

Re: [PATCH] lib: Always NUL terminate ucs2_as_utf8

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

Re: [PATCH] lib: Always NUL terminate ucs2_as_utf8

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

Re: [PATCH] lib: Always NUL terminate ucs2_as_utf8

606519] [] SyS_mount+0x8f/0xd0 > [ 170.606530] [] entry_SYSCALL_64_fastpath+0x17/0x93 > [ 170.606542] [] 0x > > Cc: Matt Fleming <m...@codeblueprint.co.uk> > Cc: Jason Andryuk <jandr...@gmail.com> > Cc: Matthew Garrett <mj...@coreos.com&g

Re: [PATCH] lib: Always NUL terminate ucs2_as_utf8

06519] [] 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 Jones > Cc: linux-...@vger.kernel.org > Cc

Re: [PATCH 2/7] Docs: Bring SubmittingPatches more into the git era

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

Re: [PATCH 2/7] Docs: Bring SubmittingPatches more into the git era

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

Re: [PATCH] lib/ucs2_string: Correct ucs2 -> utf8 conversion

++] = 0xc0 | (c & 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 <ler...@redhat.com> >> } else { >> maxlength -= 1; >> dest[j++] = c & 0x7f; >> -- >> 2.4.3 >>

Re: [PATCH] lib/ucs2_string: Correct ucs2 -> utf8 conversion

>> 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 >>

Re: [PATCH 14/14] x86/efi: Print size in binary units in efi_print_memmap

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:

Re: [PATCH 14/14] x86/efi: Print size in binary units in efi_print_memmap

AM >>> To: Ingo Molnar <mi...@kernel.org> >>> Cc: Laszlo Ersek <ler...@redhat.com>; H . Peter Anvin <h...@zytor.com>; >>> Thomas Gleixner <t...@linutronix.de>; linux-...@vger.kernel.org; linux- >>> ker...@vger.kernel.org; Elliott, Robert (Persi

Re: [PATCH 14/14] x86/efi: Print size in binary units in efi_print_memmap

[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 Anvin" > C

Re: [PATCH 13/14] efi: Add Persistent Memory type name

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

Re: [PATCH 12/14] efi: Add NV memory attribute

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

Re: [PATCH 11/14] x86/efi: Show actual ending addresses in efi_print_memmap

8000-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 Fleming > --- > arch/x86/pla

Re: [PATCH 13/14] efi: Add Persistent Memory type name

pe.com> > Cc: Thomas Gleixner <t...@linutronix.de> > Cc: Ingo Molnar <mi...@kernel.org> > Cc: "H. Peter Anvin" <h...@zytor.com> > Cc: Ard Biesheuvel <ard.biesheu...@linaro.org> > Cc: Taku Izumi <izumi.t...@jp.fujitsu.com> > Cc: Laszlo Ersek <

Re: [PATCH 11/14] x86/efi: Show actual ending addresses in efi_print_memmap

C|UC] > range=[0x00088000-0x000c7fff] (16384MB) > > Signed-off-by: Robert Elliott <elli...@hpe.com> > Cc: Thomas Gleixner <t...@linutronix.de> > Cc: Ingo Molnar <mi...@kernel.org> > Cc: "H. Peter Anvin" <h...@zytor.com> > Cc: A

Re: [PATCH 12/14] efi: Add NV memory attribute

ert Elliott <elli...@hpe.com> > Cc: Thomas Gleixner <t...@linutronix.de> > Cc: Ingo Molnar <mi...@kernel.org> > Cc: "H. Peter Anvin" <h...@zytor.com> > Cc: Ard Biesheuvel <ard.biesheu...@linaro.org> > Cc: Taku Izumi <izumi.t...@j

Re: [PATCH 14/14] x86/efi: Print size in binary units in efi_print_memmap

as Gleixner <t...@linutronix.de> > Cc: Ingo Molnar <mi...@kernel.org> > Cc: "H. Peter Anvin" <h...@zytor.com> > Cc: Ard Biesheuvel <ard.biesheu...@linaro.org> > Cc: Taku Izumi <izumi.t...@jp.fujitsu.com> > Cc: Laszlo Ersek <ler...@redhat.com&

Re: [Qemu-devel] [PATCH v5 1/4] firmware: introduce sysfs driver for QEMU's fw_cfg device

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

Re: [Qemu-devel] [PATCH v5 1/4] firmware: introduce sysfs driver for QEMU's fw_cfg device

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

Re: [PATCH v5 4/4] devicetree: update documentation for fw_cfg ARM bindings

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

Re: [PATCH v5 4/4] devicetree: update documentation for fw_cfg ARM bindings

ce tree. > > Signed-off-by: Gabriel Somlo <so...@cmu.edu> > Cc: Laszlo Ersek <ler...@redhat.com> > --- > Documentation/devicetree/bindings/arm/fw-cfg.txt | 38 > ++-- > 1 file changed, 2 insertions(+), 36 deletions(-) > > diff --git a/Docu

Re: [PATCH] KVM: x86: allow RSM from 64-bit mode

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: >>>

Re: [PATCH] KVM: x86: allow RSM from 64-bit mode

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. B

Re: [PATCH] KVM: x86: allow RSM from 64-bit mode

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 |

Re: [PATCH 0/3] KVM: x86: simplify RSM into 64-bit protected mode

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

Re: [PATCH 0/3] KVM: x86: simplify RSM into 64-bit protected mode

On 11/02/15 10:32, Paolo Bonzini wrote: > > > On 31/10/2015 20:50, Laszlo Ersek wrote: >> Tested-by: Laszlo Ersek <ler...@redhat.com> > > Thanks Laszlo, I applied patches 1 and 2 (since your "part 2" never was :)). > > Paolo > Thanks. Since y

Re: [PATCH] KVM: x86: allow RSM from 64-bit mode

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: >>>

Re: [PATCH] KVM: x86: allow RSM from 64-bit mode

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 <ler...@redhat.com> > Cc: Radim Krčmář <rkrc...@redhat.com> > Sign

Re: [PATCH] KVM: x86: allow RSM from 64-bit mode

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. B

Re: [PATCH 0/3] KVM: x86: simplify RSM into 64-bit protected mode

ode > > 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 Ersek

Re: [PATCH 0/3] KVM: x86: simplify RSM into 64-bit protected mode

ode > > 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 E

  1   2   3   >