Re: [PATCH v4 0/5] x86 instruction emulator fuzzing

On 28.06.19 11:26, Sam Caccavale wrote: Dear all, This series aims to provide an entrypoint for, and fuzz KVM's x86 instruction emulator from userspace. It mirrors Xen's application of the AFL fuzzer to it's instruction emulator in the hopes of discovering vulnerabilities. Since this

Re: [PATCH v3 4/5] Added build and install scripts

On 24.06.19 16:24, Sam Caccavale wrote: install_afl.sh installs AFL locally and emits AFLPATH, build.sh, and run.sh build and run respectively --- v1 -> v2: - Introduced this patch v2 -> v3: - Moved non-essential development scripts to a later patch Signed-off-by: Sam Caccavale ---

Re: [v2, 4/4] Added scripts for filtering, building, deploying

On 12.06.19 17:36, Sam Caccavale wrote: bin.sh produces output which diagnoses whether the crash was expected. coalesce.sh, gen_output.sh, and summarize.sh are useful for parsing the large crash directories that afl produces. deploy_remote.sh does all of the setup to launch a fuzz run via

Re: [v2, 3/4] Demonstrating unit testing via simple-harness

On 12.06.19 17:35, Sam Caccavale wrote: Simple-harness.c uses inline asm support to generate asm and then has the emulator emulate this code. This may be useful as a form of testing for the emulator. CR: https://code.amazon.com/reviews/CR-8591638 --- tools/fuzz/x86ie/Makefile | 7

Re: [v2, 2/4] Emulate simple x86 instructions in userspace

On 12.06.19 17:35, Sam Caccavale wrote: Added the minimal subset of code to run afl-harness with a binary file as input. These bytes are used to populate the vcpu structure and then as an instruction stream for the emulator. It does not attempt to handle exceptions an only supports very

Re: [v2, 1/4] Build target for emulate.o as a userspace binary

On 12.06.19 17:35, Sam Caccavale wrote: This commit contains the minimal set of functionality to build afl-harness around arch/x86/emulate.c which allows exercising code in that source file, like x86_emulate_insn. Resolving the dependencies was done via GCC's -H flag by get_headers.py. CR:

Re: [v2, 0/4] x86 instruction emulator fuzzing

On 12.06.19 17:35, Sam Caccavale wrote: Dear all, This series aims to provide an entrypoint for, and fuzz KVM's x86 instruction emulator from userspace. It mirrors Xen's application of the AFL fuzzer to it's instruction emulator in the hopes of discovering vulnerabilities. Since this

Re: [PATCH 2/3] Emulate simple x86 instructions in userspace

On 12.06.19 17:19, samc...@amazon.com wrote: On 5/31/19 10:38 AM, Alexander Graf wrote: On 21.05.19 17:39, Sam Caccavale wrote: +static void dump_state_after(const char *desc, struct state *state) +{ +    debug(" -- State after %s --\n", desc); +    debug("mode: %s\n",

Re: [RFC 00/10] Process-local memory allocations for hiding KVM secrets

On 14.06.19 16:21, Thomas Gleixner wrote: On Wed, 12 Jun 2019, Andy Lutomirski wrote: On Jun 12, 2019, at 12:55 PM, Dave Hansen wrote: On 6/12/19 10:08 AM, Marius Hillenbrand wrote: This patch series proposes to introduce a region for what we call process-local memory into the kernel's

Re: [RFC 00/10] Process-local memory allocations for hiding KVM secrets

On 12.06.19 20:25, Sean Christopherson wrote: On Wed, Jun 12, 2019 at 07:08:24PM +0200, Marius Hillenbrand wrote: The Linux kernel has a global address space that is the same for any kernel code. This address space becomes a liability in a world with processor information leak

Re: [RFC 00/10] Process-local memory allocations for hiding KVM secrets

On 12.06.19 21:55, Dave Hansen wrote: On 6/12/19 10:08 AM, Marius Hillenbrand wrote: This patch series proposes to introduce a region for what we call process-local memory into the kernel's virtual address space. It might be fun to cc some x86 folks on this series. They might have some

Re: [RFC 00/10] Process-local memory allocations for hiding KVM secrets

On 13.06.19 03:30, Andy Lutomirski wrote: On Wed, Jun 12, 2019 at 1:27 PM Andy Lutomirski wrote: On Jun 12, 2019, at 12:55 PM, Dave Hansen wrote: On 6/12/19 10:08 AM, Marius Hillenbrand wrote: This patch series proposes to introduce a region for what we call process-local memory into

Re: [PATCH v2 1/2] KVM: Start populating /sys/hypervisor with KVM entries

On 31.05.19 11:12, Raslan, KarimAllah wrote: On Fri, 2019-05-31 at 11:06 +0200, Alexander Graf wrote: On 17.05.19 17:41, Sironi, Filippo wrote: On 16. May 2019, at 15:50, Graf, Alexander wrote: On 14.05.19 08:16, Filippo Sironi wrote: Start populating /sys/hypervisor with KVM entries when

Re: [PATCH v2 1/2] KVM: Start populating /sys/hypervisor with KVM entries

On 17.05.19 17:41, Sironi, Filippo wrote: On 16. May 2019, at 15:50, Graf, Alexander wrote: On 14.05.19 08:16, Filippo Sironi wrote: Start populating /sys/hypervisor with KVM entries when we're running on KVM. This is to replicate functionality that's available when we're running on Xen.

Re: [PATCH 2/3] Emulate simple x86 instructions in userspace

On 21.05.19 17:39, Sam Caccavale wrote: Added the minimal subset of code to run afl-harness with a binary file as input. These bytes are used to populate the vcpu structure and then as an instruction stream for the emulator. It does not attempt to handle exceptions an only supports very

Re: x86 instruction emulator fuzzing

On 21.05.19 17:39, Sam Caccavale wrote: Dear all, This series aims to provide an entrypoint for, and fuzz KVM's x86 instruction emulator from userspace. It mirrors Xen's application of the AFL fuzzer to it's instruction emulator in the hopes of discovering vulnerabilities. Since this

Re: [PATCH 1/3] Build target for emulate.o as a userspace binary

On 21.05.19 17:39, Sam Caccavale wrote: This commit contains the minimal set of functionality to build afl-harness around arch/x86/emulate.c which allows exercising code in that source file, like x86_emulate_insn. Resolving the dependencies was done via GCC's -H flag by get_headers.py. ---

Re: [PATCH v2 2/2] KVM: x86: Implement the arch-specific hook to report the VM UUID

On 16.05.19 10:41, Sironi, Filippo wrote: >> On 16. May 2019, at 18:40, Boris Ostrovsky >> wrote: >> >> On 5/16/19 11:33 AM, Alexander Graf wrote: >>> On 16.05.19 08:25, Sironi, Filippo wrote: >>>>> On 16. May 2019, at 15:56, Graf, Alexande

Re: [PATCH v2 2/2] KVM: x86: Implement the arch-specific hook to report the VM UUID

On 16.05.19 08:25, Sironi, Filippo wrote: >> On 16. May 2019, at 15:56, Graf, Alexander wrote: >> >> On 14.05.19 08:16, Filippo Sironi wrote: >>> On x86, we report the UUID in DMI System Information (i.e., DMI Type 1) >>> as VM UUID. >>> >>> Signed-off-by: Filippo Sironi >>> --- >>>

Re: [Xen-devel] [PATCH v2 1/2] KVM: Start populating /sys/hypervisor with KVM entries

On 16.05.19 07:02, Andrew Cooper wrote: > On 16/05/2019 14:50, Alexander Graf wrote: >> On 14.05.19 08:16, Filippo Sironi wrote: >>> Start populating /sys/hypervisor with KVM entries when we're running on >>> KVM. This is to replicate functionality that's available wh

Re: [PATCH v2 2/2] KVM: x86: Implement the arch-specific hook to report the VM UUID

On 14.05.19 08:16, Filippo Sironi wrote: > On x86, we report the UUID in DMI System Information (i.e., DMI Type 1) > as VM UUID. > > Signed-off-by: Filippo Sironi > --- > arch/x86/kernel/kvm.c | 7 +++ > 1 file changed, 7 insertions(+) > > diff --git a/arch/x86/kernel/kvm.c

Re: [PATCH v2 1/2] KVM: Start populating /sys/hypervisor with KVM entries

On 14.05.19 08:16, Filippo Sironi wrote: > Start populating /sys/hypervisor with KVM entries when we're running on > KVM. This is to replicate functionality that's available when we're > running on Xen. > > Start with /sys/hypervisor/uuid, which users prefer over >

Re: [PATCH 7/7] irqchip/al-msi: Add ACPI support

On 12.04.19 14:08, Marc Zyngier wrote: > Hi Zeev, > > On 04/04/2019 15:45, Zeev Zilberman wrote: >> Hi Marc, >> >> We have considered exposing our interrupt controller both via MADT >> OEM-specific entry and via DSDT. >> We've chosen MADT OEM-specific entry, because it seemed like a >>

Re: [PATCH] arm64: Make kpti command line options x86 compatible

On 15.11.18 10:41, Christoph Hellwig wrote: > On Tue, Nov 13, 2018 at 04:20:46PM +0100, Alexander Graf wrote: >> I've already stumbled over 2 cases where people got confused about how to >> disable kpti on AArch64. In both cases, they used existing x86_64 options >

Re: [PATCH] arm64: Make kpti command line options x86 compatible

On 15.11.18 10:41, Christoph Hellwig wrote: > On Tue, Nov 13, 2018 at 04:20:46PM +0100, Alexander Graf wrote: >> I've already stumbled over 2 cases where people got confused about how to >> disable kpti on AArch64. In both cases, they used existing x86_64 options >

Re: [RFC PATCH] driver core: make deferring probe forever optional

On 05/14/2018 12:01 AM, Linus Walleij wrote: On Wed, May 9, 2018 at 11:44 AM, Alexander Graf <ag...@suse.de> wrote: On 05/07/2018 08:31 PM, Bjorn Andersson wrote: Can you please name platform that has enough support for Alexander to care about backwards and forwards compatibility but

Re: [RFC PATCH] driver core: make deferring probe forever optional

On 05/14/2018 12:01 AM, Linus Walleij wrote: On Wed, May 9, 2018 at 11:44 AM, Alexander Graf wrote: On 05/07/2018 08:31 PM, Bjorn Andersson wrote: Can you please name platform that has enough support for Alexander to care about backwards and forwards compatibility but lacks a pinctrl driver

Re: [RFC PATCH] driver core: make deferring probe forever optional

On 05/08/2018 12:34 AM, Bjorn Andersson wrote: On Mon 07 May 12:55 PDT 2018, Rob Herring wrote: On Mon, May 7, 2018 at 1:31 PM, Bjorn Andersson wrote: On Tue 01 May 14:31 PDT 2018, Rob Herring wrote: Deferred probe will currently wait forever on dependent

Re: [RFC PATCH] driver core: make deferring probe forever optional

On 05/08/2018 12:34 AM, Bjorn Andersson wrote: On Mon 07 May 12:55 PDT 2018, Rob Herring wrote: On Mon, May 7, 2018 at 1:31 PM, Bjorn Andersson wrote: On Tue 01 May 14:31 PDT 2018, Rob Herring wrote: Deferred probe will currently wait forever on dependent devices to probe, but sometimes a

Re: [RFC PATCH] driver core: make deferring probe forever optional

if there is no matching pinctrl driver in the kernel. Cc: Alexander Graf <ag...@suse.de> Signed-off-by: Rob Herring <r...@kernel.org> --- This patch came out of a discussion on the ARM boot-architecture list[1] about DT forwards and backwards compatibility issues. There are issues wi

Re: [RFC PATCH] driver core: make deferring probe forever optional

if there is no matching pinctrl driver in the kernel. Cc: Alexander Graf Signed-off-by: Rob Herring --- This patch came out of a discussion on the ARM boot-architecture list[1] about DT forwards and backwards compatibility issues. There are issues with newer DTs breaking on older, stable kernels

Re: [RFC PATCH] driver core: make deferring probe forever optional

that can be optional, and then only so many drivers in those that can be modules (at least for pinctrl, many drivers are built-in only). Cc: Alexander Graf <ag...@suse.de> Signed-off-by: Rob Herring <r...@kernel.org> --- This patch came out of a discussion on the ARM boot-architecture l

Re: [RFC PATCH] driver core: make deferring probe forever optional

that can be optional, and then only so many drivers in those that can be modules (at least for pinctrl, many drivers are built-in only). Cc: Alexander Graf Signed-off-by: Rob Herring --- This patch came out of a discussion on the ARM boot-architecture list[1] about DT forwards and backwards

Re: [RFC PATCH 1/3] of: base: Introduce of_alias_check_id() to check alias IDs

On 27.04.18 16:14, Michal Simek wrote: > On 27.4.2018 15:02, Rob Herring wrote: >> On Fri, Apr 27, 2018 at 1:10 AM, Michal Simek >> wrote: >>> On 27.4.2018 04:39, Rob Herring wrote: On Thu, Apr 26, 2018 at 9:08 AM, Michal Simek

Re: [RFC PATCH 1/3] of: base: Introduce of_alias_check_id() to check alias IDs

On 27.04.18 16:14, Michal Simek wrote: > On 27.4.2018 15:02, Rob Herring wrote: >> On Fri, Apr 27, 2018 at 1:10 AM, Michal Simek >> wrote: >>> On 27.4.2018 04:39, Rob Herring wrote: On Thu, Apr 26, 2018 at 9:08 AM, Michal Simek wrote: > The function travers the lookup table to

[PATCH v2] lan78xx: Connect phy early

applied, I can successfully run wicked on my system and bring the interface up and down as many times as I want, without getting NULL pointer dereferences in between. Signed-off-by: Alexander Graf <ag...@suse.de> --- v1 -> v2: - move debug message (Andrew Lunn) - check for phydev != NU

[PATCH v2] lan78xx: Connect phy early

applied, I can successfully run wicked on my system and bring the interface up and down as many times as I want, without getting NULL pointer dereferences in between. Signed-off-by: Alexander Graf --- v1 -> v2: - move debug message (Andrew Lunn) - check for phydev != NULL before phy_stop (Sa

[PATCH] lan78xx: Connect phy early

applied, I can successfully run wicked on my system and bring the interface up and down as many times as I want, without getting NULL pointer dereferences in between. Signed-off-by: Alexander Graf <ag...@suse.de> --- drivers/net/usb/lan78xx.c | 21 ++--- 1 file changed, 10 inse

[PATCH] lan78xx: Connect phy early

applied, I can successfully run wicked on my system and bring the interface up and down as many times as I want, without getting NULL pointer dereferences in between. Signed-off-by: Alexander Graf --- drivers/net/usb/lan78xx.c | 21 ++--- 1 file changed, 10 insertions(+), 11 deletions

[PATCH] KVM: PPC: Book3S HV: Remove vcpu->arch.dec usage

On Book3S in HV mode, we don't use the vcpu->arch.dec field at all. Instead, all logic is built around vcpu->arch.dec_expires. So let's remove the one remaining piece of code that was setting it. Signed-off-by: Alexander Graf <ag...@suse.de> --- Looking through the DEC logic, I fai

[PATCH] KVM: PPC: Book3S HV: Remove vcpu->arch.dec usage

On Book3S in HV mode, we don't use the vcpu->arch.dec field at all. Instead, all logic is built around vcpu->arch.dec_expires. So let's remove the one remaining piece of code that was setting it. Signed-off-by: Alexander Graf --- Looking through the DEC logic, I fail to see an

Re: [PATCH] MAINTAINERS: Add Paul Mackerras as maintainer for KVM/powerpc

On 09.10.17 16:56, Thomas Huth wrote: > On 09.10.2017 16:43, Alexander Graf wrote: >> >> >> On 09.10.17 16:42, Paolo Bonzini wrote: >>> On 09/10/2017 16:34, Thomas Huth wrote: >>>> Paul is handling almost all of the powerpc related KVM patche

Re: [PATCH] MAINTAINERS: Add Paul Mackerras as maintainer for KVM/powerpc

On 09.10.17 16:56, Thomas Huth wrote: > On 09.10.2017 16:43, Alexander Graf wrote: >> >> >> On 09.10.17 16:42, Paolo Bonzini wrote: >>> On 09/10/2017 16:34, Thomas Huth wrote: >>>> Paul is handling almost all of the powerpc related KVM patche

Re: [PATCH] MAINTAINERS: Add Paul Mackerras as maintainer for KVM/powerpc

nclude/asm/kvm* >> F: arch/mips/kvm/ >> >> KERNEL VIRTUAL MACHINE FOR POWERPC (KVM/powerpc) >> +M: Paul Mackerras <pau...@ozlabs.org> >> M: Alexander Graf <ag...@suse.com> >> L: kvm-...@vger.kernel.org >> W: http://www.linux-kvm.org/ >

Re: [PATCH] MAINTAINERS: Add Paul Mackerras as maintainer for KVM/powerpc

arch/mips/kvm/ >> >> KERNEL VIRTUAL MACHINE FOR POWERPC (KVM/powerpc) >> +M: Paul Mackerras >> M: Alexander Graf >> L: kvm-...@vger.kernel.org >> W: http://www.linux-kvm.org/ >> > > Queued, replacing Alex too. What's the state of BookE

Re: [PATCH] MAINTAINERS: Add Paul Mackerras as maintainer for KVM/powerpc

On 09.10.17 16:34, Thomas Huth wrote: > Paul is handling almost all of the powerpc related KVM patches nowadays, > so he should be mentioned in the MAINTAINERS file accordingly. > > Signed-off-by: Thomas Huth <th...@redhat.com> Feel free to replace me too. Reviewed-by:

Re: [PATCH] MAINTAINERS: Add Paul Mackerras as maintainer for KVM/powerpc

On 09.10.17 16:34, Thomas Huth wrote: > Paul is handling almost all of the powerpc related KVM patches nowadays, > so he should be mentioned in the MAINTAINERS file accordingly. > > Signed-off-by: Thomas Huth Feel free to replace me too. Reviewed-by: Alexander Graf Alex

Re: [RFC PATCH v2 0/7] x86/idle: add halt poll support

On 08/29/2017 01:46 PM, Yang Zhang wrote: Some latency-intensive workload will see obviously performance drop when running inside VM. The main reason is that the overhead is amplified when running inside VM. The most cost i have seen is inside idle path. This patch introduces a new mechanism to

Re: [RFC PATCH v2 0/7] x86/idle: add halt poll support

On 08/29/2017 01:46 PM, Yang Zhang wrote: Some latency-intensive workload will see obviously performance drop when running inside VM. The main reason is that the overhead is amplified when running inside VM. The most cost i have seen is inside idle path. This patch introduces a new mechanism to

Re: [PATCH RFC 0/2] KVM: use RCU to allow dynamic kvm->vcpus array

On 17.08.17 16:54, Radim Krčmář wrote: 2017-08-17 09:04+0200, Alexander Graf: On 16.08.17 21:40, Radim Krčmář wrote: The goal is to increase KVM_MAX_VCPUS without worrying about memory impact of many small guests. This is a second out of three major "dynamic" options: 1) size

Re: [PATCH RFC 0/2] KVM: use RCU to allow dynamic kvm->vcpus array

On 17.08.17 16:54, Radim Krčmář wrote: 2017-08-17 09:04+0200, Alexander Graf: On 16.08.17 21:40, Radim Krčmář wrote: The goal is to increase KVM_MAX_VCPUS without worrying about memory impact of many small guests. This is a second out of three major "dynamic" options: 1) size

Re: [PATCH RFC 0/2] KVM: use RCU to allow dynamic kvm->vcpus array

On 16.08.17 21:40, Radim Krčmář wrote: The goal is to increase KVM_MAX_VCPUS without worrying about memory impact of many small guests. This is a second out of three major "dynamic" options: 1) size vcpu array at VM creation time 2) resize vcpu array when new VCPUs are created 3) use a

Re: [PATCH RFC 0/2] KVM: use RCU to allow dynamic kvm->vcpus array

On 16.08.17 21:40, Radim Krčmář wrote: The goal is to increase KVM_MAX_VCPUS without worrying about memory impact of many small guests. This is a second out of three major "dynamic" options: 1) size vcpu array at VM creation time 2) resize vcpu array when new VCPUs are created 3) use a

Re: [PATCH 0/3] arm64 xilinx zynqmp firmware interface

> Am 04.08.2017 um 15:45 schrieb Michal Simek : > > Hi, > > xilinx is using this interface for very long time and we can't merge our > driver changes to Linux because of missing communication layer with > firmware. This interface was developed before scpi and scmi was

Re: [PATCH 0/3] arm64 xilinx zynqmp firmware interface

> Am 04.08.2017 um 15:45 schrieb Michal Simek : > > Hi, > > xilinx is using this interface for very long time and we can't merge our > driver changes to Linux because of missing communication layer with > firmware. This interface was developed before scpi and scmi was > available. In

Re: [PATCH v2 0/3] mailbox: arm: introduce smc triggered mailbox

Hi Andre, On 24.07.17 01:23, Andre Przywara wrote: This is a reworked version of my previous post. It addresses Jassi's comments on the driver and also tries to cover Rob's and Mark's comments on the binding documentation. I dropped the more example-like DT changes from v1, as they are actually

Re: [PATCH v2 0/3] mailbox: arm: introduce smc triggered mailbox

Hi Andre, On 24.07.17 01:23, Andre Przywara wrote: This is a reworked version of my previous post. It addresses Jassi's comments on the driver and also tries to cover Rob's and Mark's comments on the binding documentation. I dropped the more example-like DT changes from v1, as they are actually

Re: [PATCH v2] KVM: arm/arm64: Handle hva aging while destroying the vm

On 17.07.17 20:23, Christoffer Dall wrote: On Mon, Jul 17, 2017 at 05:16:17PM +0200, Andrea Arcangeli wrote: On Mon, Jul 17, 2017 at 04:45:10PM +0200, Christoffer Dall wrote: I would also very much like to get to the bottom of this, and at the very least try to get a valid explanation as to

Re: [PATCH v2] KVM: arm/arm64: Handle hva aging while destroying the vm

On 17.07.17 20:23, Christoffer Dall wrote: On Mon, Jul 17, 2017 at 05:16:17PM +0200, Andrea Arcangeli wrote: On Mon, Jul 17, 2017 at 04:45:10PM +0200, Christoffer Dall wrote: I would also very much like to get to the bottom of this, and at the very least try to get a valid explanation as to

Re: [PATCH 2/2] x86/idle: use dynamic halt poll

On 17.07.17 11:26, Yang Zhang wrote: On 2017/7/14 17:37, Alexander Graf wrote: On 13.07.17 13:49, Yang Zhang wrote: On 2017/7/4 22:13, Radim Krčmář wrote: 2017-07-03 17:28+0800, Yang Zhang: The background is that we(Alibaba Cloud) do get more and more complaints from our customers

Re: [PATCH 2/2] x86/idle: use dynamic halt poll

On 17.07.17 11:26, Yang Zhang wrote: On 2017/7/14 17:37, Alexander Graf wrote: On 13.07.17 13:49, Yang Zhang wrote: On 2017/7/4 22:13, Radim Krčmář wrote: 2017-07-03 17:28+0800, Yang Zhang: The background is that we(Alibaba Cloud) do get more and more complaints from our customers

Re: [PATCH 2/2] x86/idle: use dynamic halt poll

On 13.07.17 13:49, Yang Zhang wrote: On 2017/7/4 22:13, Radim Krčmář wrote: 2017-07-03 17:28+0800, Yang Zhang: The background is that we(Alibaba Cloud) do get more and more complaints from our customers in both KVM and Xen compare to bare-mental.After investigations, the root cause is known

Re: [PATCH 2/2] x86/idle: use dynamic halt poll

On 13.07.17 13:49, Yang Zhang wrote: On 2017/7/4 22:13, Radim Krčmář wrote: 2017-07-03 17:28+0800, Yang Zhang: The background is that we(Alibaba Cloud) do get more and more complaints from our customers in both KVM and Xen compare to bare-mental.After investigations, the root cause is known

Re: [PATCH v2] KVM: arm/arm64: Handle hva aging while destroying the vm

On 05.07.17 10:57, Suzuki K Poulose wrote: Hi Alex, On Wed, Jul 05, 2017 at 08:20:31AM +0200, Alexander Graf wrote: The kvm_age_hva callback may be called all the way concurrently while kvm_mmu_notifier_release() is running. The release function sets kvm->arch.pgd = NULL which the ag

Re: [PATCH v2] KVM: arm/arm64: Handle hva aging while destroying the vm

On 05.07.17 10:57, Suzuki K Poulose wrote: Hi Alex, On Wed, Jul 05, 2017 at 08:20:31AM +0200, Alexander Graf wrote: The kvm_age_hva callback may be called all the way concurrently while kvm_mmu_notifier_release() is running. The release function sets kvm->arch.pgd = NULL which the ag

[PATCH v2] KVM: arm/arm64: Handle hva aging while destroying the vm

nce a NULL pgd pointer. This patch adds a check for that case, so that we leave the aging function silently. Cc: sta...@vger.kernel.org Fixes: 293f29363 ("kvm-arm: Unmap shadow pagetables properly") Signed-off-by: Alexander Graf <ag...@suse.de> --- v1 -> v2: - Fix commit

[PATCH v2] KVM: arm/arm64: Handle hva aging while destroying the vm

nce a NULL pgd pointer. This patch adds a check for that case, so that we leave the aging function silently. Cc: sta...@vger.kernel.org Fixes: 293f29363 ("kvm-arm: Unmap shadow pagetables properly") Signed-off-by: Alexander Graf --- v1 -> v2: - Fix commit message - Add Fixes

Re: [PATCH] KVM: arm/arm64: Handle hva aging while destroying the vm

On 07/03/2017 10:03 AM, Christoffer Dall wrote: Hi Alex, On Fri, Jun 23, 2017 at 05:21:59PM +0200, Alexander Graf wrote: If we want to age an HVA while the VM is getting destroyed, we have a tiny race window during which we may end up dereferencing an invalid kvm->arch.pgd value. C

Re: [PATCH] KVM: arm/arm64: Handle hva aging while destroying the vm

On 07/03/2017 10:03 AM, Christoffer Dall wrote: Hi Alex, On Fri, Jun 23, 2017 at 05:21:59PM +0200, Alexander Graf wrote: If we want to age an HVA while the VM is getting destroyed, we have a tiny race window during which we may end up dereferencing an invalid kvm->arch.pgd value. C

[PATCH] KVM: arm/arm64: Handle hva aging while destroying the vm

ase() kvm_arch_flush_shadow_all() kvm_free_stage2_pgd() stage2_get_pmd() set kvm->arch.pgd = 0 stage2_get_pud() arch.pgd> This patch adds a check for that case. Signed-off-by: Alexander Graf <a

[PATCH] KVM: arm/arm64: Handle hva aging while destroying the vm

ase() kvm_arch_flush_shadow_all() kvm_free_stage2_pgd() stage2_get_pmd() set kvm->arch.pgd = 0 stage2_get_pud() arch.pgd> This patch adds a check for that case. Signed-off-by: Alexander Graf --- vir

Re: [PATCH] KVM: nVMX: fix MWAIT emulation for guests

On 04.05.17 11:37, Wanpeng Li wrote: From: Wanpeng Li The kvm-unit-tests/vmx.flat fails against instruction(mwait) intercept test. Test suite: instruction intercept Unhandled exception 13 #GP at ip 00402397 error_code= rflags=00010012

Re: [PATCH] KVM: nVMX: fix MWAIT emulation for guests

On 04.05.17 11:37, Wanpeng Li wrote: From: Wanpeng Li The kvm-unit-tests/vmx.flat fails against instruction(mwait) intercept test. Test suite: instruction intercept Unhandled exception 13 #GP at ip 00402397 error_code= rflags=00010012 cs=0008 rax=

Re: [PATCH 0/4] KVM: x86: kvm_mwait_in_guest() cleanup and fixes

, but I'm ok with the original approach that sacrificed it for "greater good". I like the series :) Reviewed-by: Alexander Graf <ag...@suse.de> Alex

Re: [PATCH 0/4] KVM: x86: kvm_mwait_in_guest() cleanup and fixes

, but I'm ok with the original approach that sacrificed it for "greater good". I like the series :) Reviewed-by: Alexander Graf Alex

Re: [PATCH v2] ceph: Fix file open flags on ppc64

On 28.04.17 09:57, Yan, Zheng wrote: On 28 Apr 2017, at 00:34, Alexander Graf <ag...@suse.de> wrote: The file open flags (O_foo) are platform specific and should never go out to an interface that is not local to the system. Unfortunately these flags have leaked out onto th

Re: [PATCH v2] ceph: Fix file open flags on ppc64

On 28.04.17 09:57, Yan, Zheng wrote: On 28 Apr 2017, at 00:34, Alexander Graf wrote: The file open flags (O_foo) are platform specific and should never go out to an interface that is not local to the system. Unfortunately these flags have leaked out onto the wire in the cephfs

[PATCH v2] ceph: Fix file open flags on ppc64

view of flags to the ceph view of file open flags. Fixes: 124e68e74 ("ceph: file operations") Signed-off-by: Alexander Graf <ag...@suse.de> --- v1 -> v2: - Only convert flags mds knows about - Fix le conversion --- fs/ceph/file.c

[PATCH v2] ceph: Fix file open flags on ppc64

view of flags to the ceph view of file open flags. Fixes: 124e68e74 ("ceph: file operations") Signed-off-by: Alexander Graf --- v1 -> v2: - Only convert flags mds knows about - Fix le conversion --- fs/ceph/file.c | 35 ++- inclu

Re: [PATCH v3] kvm: arm/arm64: Fix locking for kvm_free_stage2_pgd

On 04.04.17 12:35, Suzuki K Poulose wrote: Hi Christoffer, On 04/04/17 11:13, Christoffer Dall wrote: Hi Suzuki, On Mon, Apr 03, 2017 at 03:12:43PM +0100, Suzuki K Poulose wrote: In kvm_free_stage2_pgd() we don't hold the kvm->mmu_lock while calling unmap_stage2_range() on the entire

Re: [PATCH v3] kvm: arm/arm64: Fix locking for kvm_free_stage2_pgd

On 04.04.17 12:35, Suzuki K Poulose wrote: Hi Christoffer, On 04/04/17 11:13, Christoffer Dall wrote: Hi Suzuki, On Mon, Apr 03, 2017 at 03:12:43PM +0100, Suzuki K Poulose wrote: In kvm_free_stage2_pgd() we don't hold the kvm->mmu_lock while calling unmap_stage2_range() on the entire

Re: [PATCH] ceph: Fix file open flags on ppc64

On 21.04.17 04:22, Yan, Zheng wrote: On 20 Apr 2017, at 20:40, Alexander Graf <ag...@suse.de> wrote: The file open flags (O_foo) are platform specific and should never go out to an interface that is not local to the system. Unfortunately these flags have leaked out onto th

Re: [PATCH] ceph: Fix file open flags on ppc64

On 21.04.17 04:22, Yan, Zheng wrote: On 20 Apr 2017, at 20:40, Alexander Graf wrote: The file open flags (O_foo) are platform specific and should never go out to an interface that is not local to the system. Unfortunately these flags have leaked out onto the wire in the cephfs

Re: [PATCH] ceph: Fix file open flags on ppc64

On 21.04.17 15:46, Jeff Layton wrote: On Thu, 2017-04-20 at 14:40 +0200, Alexander Graf wrote: The file open flags (O_foo) are platform specific and should never go out to an interface that is not local to the system. Unfortunately these flags have leaked out onto the wire in the cephfs

Re: [PATCH] ceph: Fix file open flags on ppc64

On 21.04.17 15:46, Jeff Layton wrote: On Thu, 2017-04-20 at 14:40 +0200, Alexander Graf wrote: The file open flags (O_foo) are platform specific and should never go out to an interface that is not local to the system. Unfortunately these flags have leaked out onto the wire in the cephfs

Re: [PATCH v6] kvm: better MWAIT emulation for guests

On 21.04.17 12:02, Paolo Bonzini wrote: On 12/04/2017 18:29, Michael S. Tsirkin wrote: I don't really agree we do not need the PV flag. mwait on kvm is different from mwait on bare metal in that you are heavily penalized by scheduler for polling unless you configure the host just so. HLT

Re: [PATCH v6] kvm: better MWAIT emulation for guests

On 21.04.17 12:02, Paolo Bonzini wrote: On 12/04/2017 18:29, Michael S. Tsirkin wrote: I don't really agree we do not need the PV flag. mwait on kvm is different from mwait on bare metal in that you are heavily penalized by scheduler for polling unless you configure the host just so. HLT

Re: [PATCH] ceph: Fix file open flags on ppc64

> Am 21.04.2017 um 08:59 schrieb Jan Fajerski <jfajer...@suse.com>: > >> On Fri, Apr 21, 2017 at 10:22:16AM +0800, Yan, Zheng wrote: >> >>> On 20 Apr 2017, at 20:40, Alexander Graf <ag...@suse.de> wrote: >>> >>> The file open flags

Re: [PATCH] ceph: Fix file open flags on ppc64

> Am 21.04.2017 um 08:59 schrieb Jan Fajerski : > >> On Fri, Apr 21, 2017 at 10:22:16AM +0800, Yan, Zheng wrote: >> >>> On 20 Apr 2017, at 20:40, Alexander Graf wrote: >>> >>> The file open flags (O_foo) are platform specific and should never

[PATCH] ceph: Fix file open flags on ppc64

view of flags to the ceph view of file open flags. On x86 systems, the new function should get optimized out by smart compilers. On systems where the flags differ, it should adapt them accordingly. Fixes: 124e68e74 ("ceph: file operations") Signed-off-by: Alexander Graf <ag...@suse.de&

[PATCH] ceph: Fix file open flags on ppc64

view of flags to the ceph view of file open flags. On x86 systems, the new function should get optimized out by smart compilers. On systems where the flags differ, it should adapt them accordingly. Fixes: 124e68e74 ("ceph: file operations") Signed-off-by: Alexander Graf --- fs/c

Re: [PATCH v6] kvm: better MWAIT emulation for guests

On 12.04.17 16:34, Jim Mattson wrote: Actually, we have rejected commit 87c00572ba05aa8c ("kvm: x86: emulate monitor and mwait instructions as nop"), so when we intercept MONITOR/MWAIT, we synthesize #UD. Perhaps it is this difference from vanilla kvm that motivates the following idea... So

Re: [PATCH v6] kvm: better MWAIT emulation for guests

On 12.04.17 16:34, Jim Mattson wrote: Actually, we have rejected commit 87c00572ba05aa8c ("kvm: x86: emulate monitor and mwait instructions as nop"), so when we intercept MONITOR/MWAIT, we synthesize #UD. Perhaps it is this difference from vanilla kvm that motivates the following idea... So

Re: [PATCH v6] kvm: better MWAIT emulation for guests

> Am 11.04.2017 um 19:10 schrieb Jim Mattson : > > This might be more useful if it could be dynamically toggled on and > off, depending on system load. What would trapping mwait (currently) buy you? As it stands today, before this patch, mwait is simply implemented as a

Re: [PATCH v6] kvm: better MWAIT emulation for guests

> Am 11.04.2017 um 19:10 schrieb Jim Mattson : > > This might be more useful if it could be dynamically toggled on and > off, depending on system load. What would trapping mwait (currently) buy you? As it stands today, before this patch, mwait is simply implemented as a nop, so enabling the

Re: [PATCH v6] kvm: better MWAIT emulation for guests

On 04/11/2017 02:41 PM, Gabriel L. Somlo wrote: On Tue, Apr 11, 2017 at 01:45:35PM +0200, Alexander Graf wrote: From: "Michael S. Tsirkin" <m...@redhat.com> Guests that are heavy on futexes end up IPI'ing each other a lot. That can lead to significant slowdowns and latency in

Re: [PATCH v6] kvm: better MWAIT emulation for guests

On 04/11/2017 02:41 PM, Gabriel L. Somlo wrote: On Tue, Apr 11, 2017 at 01:45:35PM +0200, Alexander Graf wrote: From: "Michael S. Tsirkin" Guests that are heavy on futexes end up IPI'ing each other a lot. That can lead to significant slowdowns and latency increase for those g

[PATCH v6] kvm: better MWAIT emulation for guests

; Signed-off-by: Michael S. Tsirkin <m...@redhat.com> [agraf: fix amd, change commit message] Signed-off-by: Alexander Graf <ag...@suse.de> --- v5 -> v6: - Fix AMD check, so that we're consistent between svm and vmx - Clarify commit message --- Documentation/virtual/kvm/a

[PATCH v6] kvm: better MWAIT emulation for guests

x amd, change commit message] Signed-off-by: Alexander Graf --- v5 -> v6: - Fix AMD check, so that we're consistent between svm and vmx - Clarify commit message --- Documentation/virtual/kvm/api.txt| 9 + Documentation/virtual/kvm/cpuid.txt | 6 ++ arch/x86/include/uapi/

Re: [PATCH v5 untested] kvm: better MWAIT emulation for guests

On 04/04/2017 03:13 PM, Radim Krčmář wrote: 2017-04-04 14:51+0200, Alexander Graf: On 04/04/2017 02:39 PM, Radim Krčmář wrote: 2017-04-03 12:04+0200, Alexander Graf: So coming back to the original patch, is there anything that should keep us from exposing MWAIT straight into the guest at all

<    1   2   3   4   5   6   7   8   9   >