Re: [PATCH v4] ppc/spapr: Implement H_RANDOM hypercall in QEMU

On 21/09/15 04:10, David Gibson wrote: > On Fri, Sep 18, 2015 at 11:05:52AM +0200, Greg Kurz wrote: >> On Thu, 17 Sep 2015 10:49:41 +0200 >> Thomas Huth wrote: >> >>> The PAPR interface defines a hypercall to pass high-quality >>> hardware generated random numbers to guests.

[PATCH v2] KVM: x86: put vcpu_create under kvm->srcu critical section

This is needed in case vcpu_create wants to access the memslots array. Fixes this lockdep splat: [26421.303750] === [26421.307952] [ INFO: suspicious RCU usage. ] [26421.312161] 4.3.0-rc1+ #1 Not tainted [26421.312161] --- [26421.312162]

Re: [PATCH v4] ppc/spapr: Implement H_RANDOM hypercall in QEMU

On Mon, 21 Sep 2015 12:10:00 +1000 David Gibson wrote: > On Fri, Sep 18, 2015 at 11:05:52AM +0200, Greg Kurz wrote: > > On Thu, 17 Sep 2015 10:49:41 +0200 > > Thomas Huth wrote: > > > > > The PAPR interface defines a hypercall to pass high-quality

Re: [PATCH] KVM: PPC: Take the kvm->srcu lock in kvmppc_h_logical_ci_load/store()

On 21/09/15 03:37, David Gibson wrote: > On Fri, Sep 18, 2015 at 08:57:28AM +0200, Thomas Huth wrote: >> Access to the kvm->buses (like with the kvm_io_bus_read() and -write() >> functions) has to be protected via the kvm->srcu lock. >> The kvmppc_h_logical_ci_load() and -store() functions are

Re: [PATCH] KVM: PPC: Take the kvm->srcu lock in kvmppc_h_logical_ci_load/store()

On 21/09/15 03:37, David Gibson wrote: > On Fri, Sep 18, 2015 at 08:57:28AM +0200, Thomas Huth wrote: >> Access to the kvm->buses (like with the kvm_io_bus_read() and -write() >> functions) has to be protected via the kvm->srcu lock. >> The kvmppc_h_logical_ci_load() and -store() functions are

Re: [PATCH] KVM: PPC: Take the kvm->srcu lock in kvmppc_h_logical_ci_load/store()

On Mon, Sep 21, 2015 at 07:50:22AM +0200, Paolo Bonzini wrote: > > > On 21/09/2015 03:37, David Gibson wrote: > > On Fri, Sep 18, 2015 at 08:57:28AM +0200, Thomas Huth wrote: > >> Access to the kvm->buses (like with the kvm_io_bus_read() and > >> -write() functions) has to be protected via the

Re: [PATCH] KVM: PPC: Take the kvm->srcu lock in kvmppc_h_logical_ci_load/store()

On Mon, Sep 21, 2015 at 07:50:22AM +0200, Paolo Bonzini wrote: > > > On 21/09/2015 03:37, David Gibson wrote: > > On Fri, Sep 18, 2015 at 08:57:28AM +0200, Thomas Huth wrote: > >> Access to the kvm->buses (like with the kvm_io_bus_read() and > >> -write() functions) has to be protected via the

Re: [edk2] KVM: MTRR: fix memory type handling if MTRR is completely disabled

W dniu 21.09.2015 o 04:51, Xiao Guangrong pisze: > > Thanks for your report and analysis, Janusz! > > On 09/19/2015 01:48 AM, Janusz wrote: >> W dniu 18.09.2015 o 12:07, Laszlo Ersek pisze: >>> On 09/18/15 11:37, Janusz wrote: Hello, I am writting about this patch that was posted by

Re: [Qemu-devel] [PATCH v4] ppc/spapr: Implement H_RANDOM hypercall in QEMU

On Mon, Sep 21, 2015 at 10:37:28AM +0200, Greg Kurz wrote: > On Mon, 21 Sep 2015 10:26:52 +0200 > Thomas Huth wrote: > > > On 21/09/15 10:01, Greg Kurz wrote: > > > On Mon, 21 Sep 2015 12:10:00 +1000 > > > David Gibson wrote: > > > > > >> On Fri,

RE: [PATCH v9 12/18] vfio: Register/unregister irq_bypass_producer

> -Original Message- > From: Paolo Bonzini [mailto:pbonz...@redhat.com] > Sent: Monday, September 21, 2015 5:32 PM > To: Wu, Feng; alex.william...@redhat.com; j...@8bytes.org; > mtosa...@redhat.com > Cc: eric.au...@linaro.org; kvm@vger.kernel.org; > io...@lists.linux-foundation.org;

Re: [PATCH kvm-unit-tests] x86: debug: test debug extensions

On 21/09/2015 14:26, Nadav Amit wrote: > Paolo, > > Two students here implemented emulated I/O and data breakpoints support for > KVM under my supervision. I mistakenly graded their project before they > actually sent the patches, and at this point (surprisingly) they > disappeared. The patches

Re: [PATCH kvm-unit-tests] x86: debug: test debug extensions

Paolo, Two students here implemented emulated I/O and data breakpoints support for KVM under my supervision. I mistakenly graded their project before they actually sent the patches, and at this point (surprisingly) they disappeared. The patches are relatively ok and include unit-tests. I also ran

RE: [PATCH v9 12/18] vfio: Register/unregister irq_bypass_producer

> -Original Message- > From: Paolo Bonzini [mailto:pbonz...@redhat.com] > Sent: Monday, September 21, 2015 5:32 PM > To: Wu, Feng; alex.william...@redhat.com; j...@8bytes.org; > mtosa...@redhat.com > Cc: eric.au...@linaro.org; kvm@vger.kernel.org; > io...@lists.linux-foundation.org;

Re: [PATCH v9 12/18] vfio: Register/unregister irq_bypass_producer

On 21/09/2015 14:53, Wu, Feng wrote: >>> > > I think the point is that we cannot trigger the build of irqbypass >>> > > manager inside KVM or VFIO, we need trigger the build at a high >>> > > level and it should be built before VFIO and KVM. Any ideas? >> > >> > We can add virt/Makefile and

Re: [PATCH v9 12/18] vfio: Register/unregister irq_bypass_producer

On 21/09/2015 13:35, Wu, Feng wrote: >>> > > I think the point is that we cannot trigger the build of irqbypass >>> > > manager inside KVM or VFIO, we need trigger the build at a high >>> > > level and it should be built before VFIO and KVM. Any ideas? >> > >> > We can add virt/Makefile and

Re: [PATCH v2 1/2] x86/msr: Carry on after a non-"safe" MSR access fails without !panic_on_oops

On 21/09/2015 10:46, Ingo Molnar wrote: > Or we could extend exception table entry encoding to include a 'warning bit', > to > not bloat the kernel. If the exception handler code encounters such an > exception > it would generate a one-time warning for that entry, but otherwise not crash >

[PATCH kvm-unit-tests] x86: debug: test debug extensions

Not committing this yet since KVM does not support I/O breakpoints, but posting it because it is useful for TCG too. TCG fails the tests because it doesn't preserve DRn_FIXED_1 on mov to dr6 and dr7, and also because it lacks support for ICEBP, but it is easy to fix the former and disable the

Re: [PATCH 0/2] VFIO: Accept IOMMU group (PE) ID

On Mon, Sep 21, 2015 at 11:42:28AM +1000, David Gibson wrote: >On Sat, Sep 19, 2015 at 04:22:47PM +1000, David Gibson wrote: >> On Fri, Sep 18, 2015 at 09:47:32AM -0600, Alex Williamson wrote: >> > On Fri, 2015-09-18 at 16:24 +1000, Gavin Shan wrote: >> > > This allows to accept IOMMU group (PE)

Re: [PATCH 0/2] VFIO: Accept IOMMU group (PE) ID

On Mon, Sep 21, 2015 at 11:42:28AM +1000, David Gibson wrote: >On Sat, Sep 19, 2015 at 04:22:47PM +1000, David Gibson wrote: >> On Fri, Sep 18, 2015 at 09:47:32AM -0600, Alex Williamson wrote: >> > On Fri, 2015-09-18 at 16:24 +1000, Gavin Shan wrote: >> > > This allows to accept IOMMU group (PE)

Re: [PATCH v9 18/18] iommu/vt-d: Add a command line parameter for VT-d posted-interrupts

On Fri, Sep 18, 2015 at 10:29:56PM +0800, Feng Wu wrote: > Enable VT-d Posted-Interrtups and add a command line > parameter for it. > > Signed-off-by: Feng Wu > Reviewed-by: Paolo Bonzini > --- > Documentation/kernel-parameters.txt | 1 + >

Re: [RFC PATCH 0/2] kvmclock: fix ABI breakage from PVCLOCK_COUNTS_FROM_ZERO.

> So either: > > Proceed with guest solution: > -> Make sure the overflow can't happen (and write down why not in the > code). Don't assume a small delta between kvmclock values of vcpus. > -> Handle stable -> non-stable kvmclock transition. > -> kvmclock counts from zero should not depend on

Re: [RFC PATCH 0/2] kvmclock: fix ABI breakage from PVCLOCK_COUNTS_FROM_ZERO.

On Tue, Sep 22, 2015 at 12:00:39AM +0200, Radim Krčmář wrote: > 2015-09-21 17:53-0300, Marcelo Tosatti: > > On Mon, Sep 21, 2015 at 10:00:27PM +0200, Radim Krčmář wrote: > >> 2015-09-21 12:52-0300, Marcelo Tosatti: > >> > On Mon, Sep 21, 2015 at 05:12:10PM +0200, Radim Krčmář wrote: > >> >>

Re: [RFC PATCH 0/2] kvmclock: fix ABI breakage from PVCLOCK_COUNTS_FROM_ZERO.

2015-09-21 17:53-0300, Marcelo Tosatti: > On Mon, Sep 21, 2015 at 10:00:27PM +0200, Radim Krčmář wrote: >> 2015-09-21 12:52-0300, Marcelo Tosatti: >> > On Mon, Sep 21, 2015 at 05:12:10PM +0200, Radim Krčmář wrote: >> >> 2015-09-20 19:57-0300, Marcelo Tosatti: >> >>> Is it counting from zero that

Re: [RFC PATCH 0/2] kvmclock: fix ABI breakage from PVCLOCK_COUNTS_FROM_ZERO.

2015-09-21 17:12+0200, Radim Krčmář: > 2015-09-20 19:57-0300, Marcelo Tosatti: > > On Fri, Sep 18, 2015 at 05:54:28PM +0200, Radim Krčmář wrote: >>> This patch series will be disabling PVCLOCK_COUNTS_FROM_ZERO flag and is >>> RFC because I haven't explored many potential problems or tested it. >>

Re: include/linux/kvm_host.h:488 suspicious rcu_dereference_check() usage!

On 21/09/2015 17:10, Paolo Bonzini wrote: > > > On 20/09/2015 18:48, Borislav Petkov wrote: >> [26421.593927] -- spte 0x3e5a22027 level 4. >> [26421.598228] -- spte 0x38a00b027 level 3. >> [26421.602505] -- spte 0x387334027 level 2. >> [26421.602506] -- spte 0x000b8f67

Re: include/linux/kvm_host.h:488 suspicious rcu_dereference_check() usage!

On 20/09/2015 18:48, Borislav Petkov wrote: > [26421.593927] -- spte 0x3e5a22027 level 4. > [26421.598228] -- spte 0x38a00b027 level 3. > [26421.602505] -- spte 0x387334027 level 2. > [26421.602506] -- spte 0x000b8f67 level 1. > [26421.602506] [ cut here

Re: [PATCH v2] KVM: x86: put vcpu_create under kvm->srcu critical section

On Mon, Sep 21, 2015 at 08:02:56AM +0200, Paolo Bonzini wrote: > This is needed in case vcpu_create wants to access the memslots array. > Fixes this lockdep splat: > > [26421.303750] === > [26421.307952] [ INFO: suspicious RCU usage. ] > [26421.312161] 4.3.0-rc1+ #1

Re: include/linux/kvm_host.h:488 suspicious rcu_dereference_check() usage!

On Mon, Sep 21, 2015 at 05:19:57PM +0200, Paolo Bonzini wrote: > First, the leaf test would have to be == 0, because I prepared the > patch on the first 4.3 pull request instead of the latest Linus > tree. However even this would not be a good change, because > > is_shadow_present_pte(spte) ==

Re: [RFC PATCH 0/2] kvmclock: fix ABI breakage from PVCLOCK_COUNTS_FROM_ZERO.

On Mon, Sep 21, 2015 at 05:12:10PM +0200, Radim Krčmář wrote: > 2015-09-20 19:57-0300, Marcelo Tosatti: > > On Fri, Sep 18, 2015 at 05:54:28PM +0200, Radim Krčmář wrote: > >> This patch series will be disabling PVCLOCK_COUNTS_FROM_ZERO flag and is > >> RFC because I haven't explored many potential

Re: [Qemu-devel] [PATCH v4] ppc/spapr: Implement H_RANDOM hypercall in QEMU

On 09/21/2015 12:00 AM, Thomas Huth wrote: >>> This being said, I am not sure about the use case where a user has a hwrng >>> capable platform and wants to run guests without any hwrng support at all is >>> an appropriate default behavior... I guess we will find more users that want >>> in-kernel

Re: [PATCH v2 1/2] x86/msr: Carry on after a non-"safe" MSR access fails without !panic_on_oops

On Mon, Sep 21, 2015 at 1:46 AM, Ingo Molnar wrote: > > Linus, what's your preference? So quite frankly, is there any reason we don't just implement native_read_msr() as just unsigned long long native_read_msr(unsigned int msr) { int err; unsigned long long

Re: [PATCH v2 1/2] x86/msr: Carry on after a non-"safe" MSR access fails without !panic_on_oops

On 9/21/2015 9:36 AM, Linus Torvalds wrote: On Mon, Sep 21, 2015 at 1:46 AM, Ingo Molnar wrote: Linus, what's your preference? So quite frankly, is there any reason we don't just implement native_read_msr() as just unsigned long long native_read_msr(unsigned int msr)

Re: [PATCH v2 1/2] x86/msr: Carry on after a non-"safe" MSR access fails without !panic_on_oops

On Mon, Sep 21, 2015 at 9:49 AM, Arjan van de Ven wrote: > On 9/21/2015 9:36 AM, Linus Torvalds wrote: >> >> On Mon, Sep 21, 2015 at 1:46 AM, Ingo Molnar wrote: >>> >>> >>> Linus, what's your preference? >> >> >> So quite frankly, is there any reason we

Re: [PATCH v2 1/2] x86/msr: Carry on after a non-"safe" MSR access fails without !panic_on_oops

On Mon, Sep 21, 2015 at 9:49 AM, Arjan van de Ven wrote: >> >> How many msr reads are so critical that the function call >> overhead would matter? > > if anything qualifies it'd be switch_to() and friends. Is there anything else than the FS/GS_BASE thing (possibly hidden

Re: [PATCH 0/2] VFIO: Accept IOMMU group (PE) ID

On Mon, 2015-09-21 at 22:11 +1000, Gavin Shan wrote: > On Mon, Sep 21, 2015 at 11:42:28AM +1000, David Gibson wrote: > >On Sat, Sep 19, 2015 at 04:22:47PM +1000, David Gibson wrote: > >> On Fri, Sep 18, 2015 at 09:47:32AM -0600, Alex Williamson wrote: > >> > On Fri, 2015-09-18 at 16:24 +1000,

RE: [PATCH v9 12/18] vfio: Register/unregister irq_bypass_producer

> -Original Message- > From: Paolo Bonzini [mailto:pbonz...@redhat.com] > Sent: Monday, September 21, 2015 8:07 PM > To: Wu, Feng; alex.william...@redhat.com; j...@8bytes.org; > mtosa...@redhat.com > Cc: eric.au...@linaro.org; kvm@vger.kernel.org; > io...@lists.linux-foundation.org;

Re: [PATCH 0/2] VFIO: Accept IOMMU group (PE) ID

On Mon, 2015-09-21 at 22:11 +1000, Gavin Shan wrote: > On Mon, Sep 21, 2015 at 11:42:28AM +1000, David Gibson wrote: > >On Sat, Sep 19, 2015 at 04:22:47PM +1000, David Gibson wrote: > >> On Fri, Sep 18, 2015 at 09:47:32AM -0600, Alex Williamson wrote: > >> > On Fri, 2015-09-18 at 16:24 +1000,

Re: [RFC PATCH 0/2] kvmclock: fix ABI breakage from PVCLOCK_COUNTS_FROM_ZERO.

2015-09-20 19:57-0300, Marcelo Tosatti: > On Fri, Sep 18, 2015 at 05:54:28PM +0200, Radim Krčmář wrote: >> This patch series will be disabling PVCLOCK_COUNTS_FROM_ZERO flag and is >> RFC because I haven't explored many potential problems or tested it. > > The justification to disable

Re: [PATCH v9 12/18] vfio: Register/unregister irq_bypass_producer

On 21/09/2015 10:56, Wu, Feng wrote: > Hi Paolo & Alex, > > I find that there is a build error in the following two cases: > - KVM is configured as 'M' and VFIO as 'Y' > The reason is the build of irqbypass manager is triggered in > arch/x86/kvm/Makefile, and VFIO is built before KVM, hence >

Re: [RFC PATCH 0/2] kvmclock: fix ABI breakage from PVCLOCK_COUNTS_FROM_ZERO.

On Mon, Sep 21, 2015 at 10:00:27PM +0200, Radim Krčmář wrote: > 2015-09-21 12:52-0300, Marcelo Tosatti: > > On Mon, Sep 21, 2015 at 05:12:10PM +0200, Radim Krčmář wrote: > >> 2015-09-20 19:57-0300, Marcelo Tosatti: > >>> Is it counting from zero that breaks SLES10? > >> > >> Not by itself,

Re: [PATCH v9 12/18] vfio: Register/unregister irq_bypass_producer

Hi, On 09/21/2015 03:02 PM, Paolo Bonzini wrote: > > > On 21/09/2015 14:53, Wu, Feng wrote: >> I think the point is that we cannot trigger the build of irqbypass >> manager inside KVM or VFIO, we need trigger the build at a high >> level and it should be built before VFIO and KVM.

Re: [RFC PATCH 0/2] kvmclock: fix ABI breakage from PVCLOCK_COUNTS_FROM_ZERO.

2015-09-21 12:52-0300, Marcelo Tosatti: > On Mon, Sep 21, 2015 at 05:12:10PM +0200, Radim Krčmář wrote: >> 2015-09-20 19:57-0300, Marcelo Tosatti: >>> Is it counting from zero that breaks SLES10? >> >> Not by itself, treating MSR_KVM_SYSTEM_TIME as one-shot initializer did. >> The guest wants to

Re: [PATCH v9 03/18] KVM: arm/arm64: select IRQ_BYPASS_MANAGER

Hi Feng, There is a compilation issue for arm64 I need to fix here. Shall I resend the pre-requisite series or do you prefer to remove that patch file from this series. It would be included later when arm irq forwarding series get's ready. Best Regards Eric On 09/18/2015 04:29 PM, Feng Wu

Re: [PATCH v2 1/2] x86/msr: Carry on after a non-"safe" MSR access fails without !panic_on_oops

On Mon, Sep 21, 2015 at 11:16 AM, Andy Lutomirski wrote: > > In the interest of sanity, I want to drop the "native_", too Yes. I think the only reason it exists is to have that wrapper layer for PV. And that argument just goes away if you just make the non-inline helper

Re: [PATCH v2 1/2] x86/msr: Carry on after a non-"safe" MSR access fails without !panic_on_oops

On Mon, Sep 21, 2015 at 9:36 AM, Linus Torvalds wrote: > On Mon, Sep 21, 2015 at 1:46 AM, Ingo Molnar wrote: >> >> Linus, what's your preference? > > So quite frankly, is there any reason we don't just implement > native_read_msr() as just > >

[RFT - PATCH 2/2] KVM/arm64: enable armv8 fp/simd lazy switch

This patch enables arm64 lazy fp/simd switch. Removes the ARM constraint, and follows the same approach as armv7 version - found here https://lists.cs.columbia.edu/pipermail/kvmarm/2015-September/016518.html Signed-off-by: Mario Smarduch --- arch/arm/kvm/arm.c | 2

[RFT - PATCH 1/2] KVM/arm64: add hooks for armv8 fp/simd lazy switch support

This patch adds hooks to support fp/simd lazy switch. A vcpu flag to track fp/simd state, offset into the vcpu structure and switch prototype function. Signed-off-by: Mario Smarduch --- arch/arm64/include/asm/kvm_asm.h | 1 + arch/arm64/include/asm/kvm_host.h | 3 +++

[RFT - PATCH 0/2] KVM/arm64: add fp/simd lazy switch support

This patch series is a followup to the armv7 fp/simd lazy switch implementation, uses similar approach and depends on the series - see https://lists.cs.columbia.edu/pipermail/kvmarm/2015-September/016516.html It's based on earlier arm64 fp/simd optimization work - see

Re: [Qemu-devel] [PATCH v4] ppc/spapr: Implement H_RANDOM hypercall in QEMU

On 21/09/15 10:01, Greg Kurz wrote: > On Mon, 21 Sep 2015 12:10:00 +1000 > David Gibson wrote: > >> On Fri, Sep 18, 2015 at 11:05:52AM +0200, Greg Kurz wrote: >>> On Thu, 17 Sep 2015 10:49:41 +0200 >>> Thomas Huth wrote: >>> The PAPR interface

RE: [PATCH v9 12/18] vfio: Register/unregister irq_bypass_producer

Hi Paolo & Alex, I find that there is a build error in the following two cases: - KVM is configured as 'M' and VFIO as 'Y' The reason is the build of irqbypass manager is triggered in arch/x86/kvm/Makefile, and VFIO is built before KVM, hence it cannot find the symbols in irqbypass manager. -

Re: [PATCH] KVM: PPC: Take the kvm->srcu lock in kvmppc_h_logical_ci_load/store()

On 21/09/2015 09:59, Paul Mackerras wrote: > I was going to send you a > pull request tomorrow, but if you are about to send stuff off to Linus > you could pull now from: > > git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git kvm-ppc-fixes Ok, I'll pull from here tomorrow. The

Re: [PATCH] KVM: PPC: Take the kvm->srcu lock in kvmppc_h_logical_ci_load/store()

On 21/09/2015 09:59, Paul Mackerras wrote: > I was going to send you a > pull request tomorrow, but if you are about to send stuff off to Linus > you could pull now from: > > git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git kvm-ppc-fixes Ok, I'll pull from here tomorrow. The

Re: [PATCH v2 1/2] x86/msr: Carry on after a non-"safe" MSR access fails without !panic_on_oops

* Andy Lutomirski wrote: > On Sep 20, 2015 5:15 PM, "Linus Torvalds" > wrote: > > > > On Sun, Sep 20, 2015 at 5:02 PM, Andy Lutomirski wrote: > > > This demotes an OOPS and likely panic due to a failed non-"safe" MSR > > >