[GIT PULL] KVM fixes for 4.3-rc6

Linus, The following changes since commit d2922422c48df93f3edff7d872ee4f3191fefb08: Use WARN_ON_ONCE for missing X86_FEATURE_NRIPS (2015-10-01 14:59:37 +0200) are available in the git repository at: git://git.kernel.org/pub/scm/virt/kvm/kvm.git tags/for-linus for you to fetch changes up

[PATCH] VFIO: platform: clear IRQ_NOAUTOEN when de-assigning the IRQ

The vfio platform driver currently sets the IRQ_NOAUTOEN before doing the request_irq to properly handle the user masking. However it does not clear it when de-assigning the IRQ. This brings issues when loading the native driver again which may not explicitly enable the IRQ. This problem was

Re: [PATCH v3 27/32] nvdimm: support DSM_CMD_IMPLEMENTED function

On 10/14/2015 05:41 PM, Stefan Hajnoczi wrote: On Sun, Oct 11, 2015 at 11:52:59AM +0800, Xiao Guangrong wrote: +out->len = sizeof(out->status); out->len is uint16_t, it needs cpu_to_le16(). There may be other instances in this patch series. out->len is internally used only which is

Re: [PATCH] VFIO: platform: AMD xgbe reset module

On Wednesday 14 October 2015 15:33:12 Eric Auger wrote: > --- a/drivers/vfio/platform/vfio_platform_common.c > +++ b/drivers/vfio/platform/vfio_platform_common.c > @@ -31,6 +31,11 @@ static const struct vfio_platform_reset_combo > reset_lookup_table[] = { > .reset_function_name =

Re: [PATCH v2] kvm: svm: Only propagate next_rip when guest supports it

On 14/10/2015 15:10, Joerg Roedel wrote: > From 94ee662c527683c26ea5fa98a5a8f2c798c58470 Mon Sep 17 00:00:00 2001 > From: Joerg Roedel > Date: Wed, 7 Oct 2015 13:38:19 +0200 > Subject: [PATCH] kvm: svm: Only propagate next_rip when guest supports it > > Currently we always

Re: [PATCH v3 27/32] nvdimm: support DSM_CMD_IMPLEMENTED function

On 10/14/2015 05:40 PM, Stefan Hajnoczi wrote: On Sun, Oct 11, 2015 at 11:52:59AM +0800, Xiao Guangrong wrote: static void dsm_write(void *opaque, hwaddr addr, uint64_t val, unsigned size) { +NVDIMMState *state = opaque; +MemoryRegion *dsm_ram_mr; +

[PATCH] VFIO: platform: AMD xgbe reset module

This patch introduces a module that registers and implements a low-level reset function for the AMD XGBE device. it performs the following actions: - reset the PHY - disable auto-negotiation - disable & clear auto-negotiation IRQ - soft-reset the MAC Those tiny pieces of code are inherited from

Re: [PATCH v3 27/32] nvdimm: support DSM_CMD_IMPLEMENTED function

On Wed, Oct 14, 2015 at 10:50:40PM +0800, Xiao Guangrong wrote: > On 10/14/2015 05:40 PM, Stefan Hajnoczi wrote: > >On Sun, Oct 11, 2015 at 11:52:59AM +0800, Xiao Guangrong wrote: > >> static void dsm_write(void *opaque, hwaddr addr, > >>uint64_t val, unsigned size) > >>

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

W dniu 14.10.2015 o 10:32, Xiao Guangrong pisze: > > > On 10/14/2015 04:24 PM, Xiao Guangrong wrote: >> >> >> On 10/14/2015 03:37 PM, Janusz wrote: >>> I was able to run my virtual machine with this, but had very high cpu >>> usage when something happen in it like booting system. once, my virtual

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

I was able to run my virtual machine with this, but had very high cpu usage when something happen in it like booting system. once, my virtual machine hang and I couln't even get my mouse / keyboard back from qemu. When I did vga passthrough, I didn't get any video output, and cpu usage was also

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

W dniu 14.10.2015 o 11:13, Janusz pisze: > W dniu 14.10.2015 o 10:32, Xiao Guangrong pisze: >> >> On 10/14/2015 04:24 PM, Xiao Guangrong wrote: >>> >>> On 10/14/2015 03:37 PM, Janusz wrote: I was able to run my virtual machine with this, but had very high cpu usage when something happen

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

On 10/14/2015 04:24 PM, Xiao Guangrong wrote: On 10/14/2015 03:37 PM, Janusz wrote: I was able to run my virtual machine with this, but had very high cpu usage when something happen in it like booting system. once, my virtual machine hang and I couln't even get my mouse / keyboard back from

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

W dniu 14.10.2015 o 10:32, Xiao Guangrong pisze: > > > On 10/14/2015 04:24 PM, Xiao Guangrong wrote: >> >> >> On 10/14/2015 03:37 PM, Janusz wrote: >>> I was able to run my virtual machine with this, but had very high cpu >>> usage when something happen in it like booting system. once, my virtual

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

On 10/14/15 10:32, Xiao Guangrong wrote: > > > On 10/14/2015 04:24 PM, Xiao Guangrong wrote: >> >> >> On 10/14/2015 03:37 PM, Janusz wrote: >>> I was able to run my virtual machine with this, but had very high cpu >>> usage when something happen in it like booting system. once, my virtual >>>

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

On 10/14/2015 03:37 PM, Janusz wrote: I was able to run my virtual machine with this, but had very high cpu usage when something happen in it like booting system. once, my virtual machine hang and I couln't even get my mouse / keyboard back from qemu. When I did vga passthrough, I didn't get

Re: [PATCH v3 00/16] KVM: arm64: GICv3 ITS emulation

Hi Andre, Pavel On 10/12/2015 05:18 PM, Pavel Fedin wrote: > Hello! > >> Also what is the status of Eric's IRQ routing support? Should this go in >> first now? > > I'd say without vITS there's nothing to use IRQ routing with. It could go in > and just lay around > silently, so that it's not

RE: [PATCH v3 00/16] KVM: arm64: GICv3 ITS emulation

Hello! > Currently the gsi routing applies on top of ITS emulation series. I am > going to rebase it soon. It can go in 4.5 with ITS emulation series. Ah, yes, of course, because it reuses API definitions. I forgot this. Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research

Re: [Qemu-devel] [PATCH v3 00/32] implement vNVDIMM

On Tue, Oct 13, 2015 at 9:03 PM, Xiao Guangrong wrote: >> Label-less DIMMs are tested as part of the unit test [1] and the >> "memmap=nn!ss" kernel parameter that registers a persistent-memory >> address range without a DIMM. What error do you see when label >>

just an observation about USB

update from the NaturallySpeaking in a VM project. don't remember what I told you before but, yes I can now send keystroke events generated by speech recognition in the Windows guest into the Linux input queue. I can also extract information from the Linux side, and have it modify the

Re: just an observation about USB

On 14/10/2015 21:39, Eric S. Johansson wrote: > update from the NaturallySpeaking in a VM project. > > don't remember what I told you before but, yes I can now send keystroke > events generated by speech recognition in the Windows guest into the > Linux input queue. I can also extract

Re: just an observation about USB

On 10/14/2015 04:04 PM, Paolo Bonzini wrote: On 14/10/2015 21:39, Eric S. Johansson wrote: update from the NaturallySpeaking in a VM project. don't remember what I told you before but, yes I can now send keystroke events generated by speech recognition in the Windows guest into the

[PATCH] KVM: x86: move steal time initialization to vcpu entry time

As reported at https://bugs.launchpad.net/qemu/+bug/1494350, it is possible to have vcpu->arch.st.last_steal initialized from a thread other than vcpu thread, say the iothread, via KVM_SET_MSRS. Which can cause an overflow later (when subtracting from vcpu threads sched_info.run_delay). To

Re: [PATCH] KVM: VMX: enable LBR virtualization

On 12/10/2015 20:44, Paolo Bonzini wrote: On 12/10/2015 14:10, Jian Zhou wrote: ping... I think your expectations for review RTT are a bit too optimistic. I have only worked 4 hours since you posted the patch... But it was on my list anyway, so let's do it. Thank for Paolo's time to

Re: [PATCH] KVM: VMX: enable LBR virtualization

On 14/10/2015 13:26, Jian Zhou wrote: > On 12/10/2015 20:44, Paolo Bonzini wrote: >> In addition, the MSR numbers may differ between the guest and the host, >> because it is possible to emulate e.g. a Core CPU on a Core 2 CPU. So I >> recommend against using the atomic switch mechanism for the

RE: [PATCH v9 17/18] KVM: Update Posted-Interrupts Descriptor when vCPU is blocked

> -Original Message- > From: David Matlack [mailto:dmatl...@google.com] > Sent: Thursday, October 15, 2015 7:41 AM > To: Wu, Feng > Cc: Paolo Bonzini ; alex.william...@redhat.com; Joerg > Roedel ; Marcelo Tosatti

Re: [PATCH v9 17/18] KVM: Update Posted-Interrupts Descriptor when vCPU is blocked

Hi Feng. On Fri, Sep 18, 2015 at 7:29 AM, Feng Wu wrote: > This patch updates the Posted-Interrupts Descriptor when vCPU > is blocked. > > pre-block: > - Add the vCPU to the blocked per-CPU list > - Set 'NV' to POSTED_INTR_WAKEUP_VECTOR > > post-block: > - Remove the vCPU from

[PATCH v3 5/5] KVM: nVMX: expose VPID capability to L1

Expose VPID capability to L1. For nested guests, we don't do anything specific for single context invalidation. Hence, only advertise support for global context invalidation. The major benefit of nested VPID comes from having separate vpids when switching between L1 and L2, and also when L2's

[PATCH v3 4/5] KVM: nVMX: nested VPID emulation

VPID is used to tag address space and avoid a TLB flush. Currently L0 use the same VPID to run L1 and all its guests. KVM flushes VPID when switching between L1 and L2. This patch advertises VPID to the L1 hypervisor, then address space of L1 and L2 can be separately treated and avoid TLB flush

[PATCH v3 0/5] KVM: nVMX: nested VPID emulation

v2 -> v3: * separate nested_vmx_vpid_caps and move checks to patch 3/5, only rejoin them when reading the MSR. v1 -> v2: * set bit 32 of the VMX_EPT_VPID_CAP MSR * check against the supported types in the implementation of the INVVPID instruction * the memory operand must always be

RE: [PATCH v3 14/16] KVM: arm64: implement ITS command queue command handlers

Hello! > -Original Message- > From: kvm-ow...@vger.kernel.org [mailto:kvm-ow...@vger.kernel.org] On Behalf > Of Andre Przywara > Sent: Wednesday, October 07, 2015 5:55 PM > To: marc.zyng...@arm.com; christoffer.d...@linaro.org > Cc: eric.au...@linaro.org; p.fe...@samsung.com;

[PATCH v3 3/5] KVM: nVMX: emulate the INVVPID instruction

Add the INVVPID instruction emulation. Reviewed-by: Wincy Van Signed-off-by: Wanpeng Li --- arch/x86/include/asm/vmx.h | 1 + arch/x86/kvm/vmx.c | 61 +- 2 files changed, 61 insertions(+), 1

[PATCH v3 2/5] KVM: VMX: introduce __vmx_flush_tlb to handle specific vpid

Introduce __vmx_flush_tlb() to handle specific vpid. It will be used by later patches, note that the "all context" variant can be mapped to vpid_sync_vcpu_single with vpid02 as the argument (a nice side effect of vpid02 design). Reviewed-by: Wincy Van Signed-off-by:

[PATCH v3 1/5] KVM: VMX: adjust interface to allocate/free_vpid

Adjust allocate/free_vid so that they can be reused for the nested vpid. Reviewed-by: Wincy Van Signed-off-by: Wanpeng Li --- arch/x86/kvm/vmx.c | 25 - 1 file changed, 12 insertions(+), 13 deletions(-) diff --git

Re: Inconsistent guest OS disk size compared to volume.img size

On Tue, Sep 29, 2015 at 12:02:17AM -0700, Jay Fishman wrote: > I have looked all over the internet but I can not even find a > reference to this issue. > > > I have installed the following on Linux Mint 17.1 > QEMU emulator version 2.0.0 (Debian 2.0.0+dfsg-2ubuntu1.19), Fabrice Bellard > > On

Re: [PATCH v3 27/32] nvdimm: support DSM_CMD_IMPLEMENTED function

On Sun, Oct 11, 2015 at 11:52:59AM +0800, Xiao Guangrong wrote: > static void dsm_write(void *opaque, hwaddr addr, >uint64_t val, unsigned size) > { > +NVDIMMState *state = opaque; > +MemoryRegion *dsm_ram_mr; > +dsm_in *in; > +dsm_out *out; > +

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

On 10/14/2015 05:47 PM, Laszlo Ersek wrote: On 10/14/15 10:32, Xiao Guangrong wrote: On 10/14/2015 04:24 PM, Xiao Guangrong wrote: On 10/14/2015 03:37 PM, Janusz wrote: I was able to run my virtual machine with this, but had very high cpu usage when something happen in it like booting

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

On 10/15/2015 02:08 AM, Janusz wrote: W dniu 14.10.2015 o 10:32, Xiao Guangrong pisze: On 10/14/2015 04:24 PM, Xiao Guangrong wrote: On 10/14/2015 03:37 PM, Janusz wrote: I was able to run my virtual machine with this, but had very high cpu usage when something happen in it like booting

[PATCH v2] kvm: svm: Only propagate next_rip when guest supports it

On Fri, Oct 09, 2015 at 01:15:11PM +0200, Paolo Bonzini wrote: > This could be a bit expensive to do on every vmexit. Can you benchmark > it with kvm-unit-tests, or just cache the result in struct vcpu_svm? Yes, caching it is certainly a good idea. I updated the patch: >From

[PATCH] KVM: x86: fix RSM into 64-bit protected mode

In order to get into 64-bit protected mode, CS.L must be 0. This is always the case when executing RSM, so it is enough to load the segments after CR0 and CR4. Fixes: 660a5d517aaab9187f93854425c4c63f4a09195c Cc: sta...@vger.kernel.org Signed-off-by: Paolo Bonzini ---

Re: [PATCH v3 27/32] nvdimm: support DSM_CMD_IMPLEMENTED function

On 10/15/2015 01:06 AM, Eduardo Habkost wrote: On Wed, Oct 14, 2015 at 10:50:40PM +0800, Xiao Guangrong wrote: On 10/14/2015 05:40 PM, Stefan Hajnoczi wrote: On Sun, Oct 11, 2015 at 11:52:59AM +0800, Xiao Guangrong wrote: static void dsm_write(void *opaque, hwaddr addr,

Re: AIO requests may be disordered by Qemu-kvm iothread with disk cache=writethrough, Bug or Feature?

On Thu, Oct 08, 2015 at 07:59:56PM +0800, charlie.song wrote: > We recently try to use Linux AIO from guest OS and find that the IOthread > mechanism of Qemu-KVM will reorder I/O requests from guest OS > even when the AIO write requests are issued from a single thread in order. > This does

Re: [PATCH v3 27/32] nvdimm: support DSM_CMD_IMPLEMENTED function

On Sun, Oct 11, 2015 at 11:52:59AM +0800, Xiao Guangrong wrote: > +out->len = sizeof(out->status); out->len is uint16_t, it needs cpu_to_le16(). There may be other instances in this patch series. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to

Re: [PATCH] KVM: PPC: e500: fix couple of shift operations on 64 bits

On Thu, Oct 01, 2015 at 03:58:03PM +0300, Laurentiu Tudor wrote: > Fix couple of cases where we shift left a 32-bit > value thus might get truncated results on 64-bit > targets. > > Signed-off-by: Laurentiu Tudor > Suggested-by: Scott Wood

Re: [PATCH][v2] KVM: PPC: e500: Emulate TMCFG0 TMRN register

On Fri, Sep 25, 2015 at 06:02:23PM +0300, Laurentiu Tudor wrote: > Emulate TMCFG0 TMRN register exposing one HW thread per vcpu. > > Signed-off-by: Mihai Caraman > [laurentiu.tu...@freescale.com: rebased on latest kernel, use > define instead of hardcoded value,

Re: [PATCH] powerpc/e6500: add TMCFG0 register definition

On Wed, Sep 23, 2015 at 06:06:22PM +0300, Laurentiu Tudor wrote: > The register is not currently used in the base kernel > but will be in a forthcoming kvm patch. > > Signed-off-by: Laurentiu Tudor Thanks, applied to my kvm-ppc-next branch. Paul. -- To

Re: [PATCH][v2] KVM: PPC: e500: Emulate TMCFG0 TMRN register

On Fri, Sep 25, 2015 at 06:02:23PM +0300, Laurentiu Tudor wrote: > Emulate TMCFG0 TMRN register exposing one HW thread per vcpu. > > Signed-off-by: Mihai Caraman > [laurentiu.tu...@freescale.com: rebased on latest kernel, use > define instead of hardcoded value,

Re: [PATCH] KVM: PPC: e500: fix couple of shift operations on 64 bits

On Thu, Oct 01, 2015 at 03:58:03PM +0300, Laurentiu Tudor wrote: > Fix couple of cases where we shift left a 32-bit > value thus might get truncated results on 64-bit > targets. > > Signed-off-by: Laurentiu Tudor > Suggested-by: Scott Wood

Re: [PATCH 15/19] KVM: PPC: e500: fix handling local_sid_lookup result

On Thu, Sep 24, 2015 at 04:00:23PM +0200, Andrzej Hajda wrote: > The function can return negative value. > > The problem has been detected using proposed semantic patch > scripts/coccinelle/tests/assign_signed_to_unsigned.cocci [1]. > > [1]: http://permalink.gmane.org/gmane.linux.kernel/2046107

[PATCH] KVM: PPC: Book3S HV: Make H_REMOVE return correct HPTE value for absent HPTEs

This fixes a bug where the old HPTE value returned by H_REMOVE has the valid bit clear if the HPTE was an absent HPTE, as happens for HPTEs for emulated MMIO pages and for RAM pages that have been paged out by the host. If the absent bit is set, we clear it and set the valid bit, because from the

[PATCH] KVM: PPC: Book3S HV: Make H_REMOVE return correct HPTE value for absent HPTEs

This fixes a bug where the old HPTE value returned by H_REMOVE has the valid bit clear if the HPTE was an absent HPTE, as happens for HPTEs for emulated MMIO pages and for RAM pages that have been paged out by the host. If the absent bit is set, we clear it and set the valid bit, because from the

[PATCH] KVM: PPC: Book3S HV: Don't fall back to smaller HPT size in allocation ioctl

Currently the KVM_PPC_ALLOCATE_HTAB will try to allocate the requested size of HPT, and if that is not possible, then try to allocate smaller sizes (by factors of 2) until either a minimum is reached or the allocation succeeds. This is not ideal for userspace, particularly in migration scenarios,

[PATCH] KVM: PPC: Book3S HV: Don't fall back to smaller HPT size in allocation ioctl

Currently the KVM_PPC_ALLOCATE_HTAB will try to allocate the requested size of HPT, and if that is not possible, then try to allocate smaller sizes (by factors of 2) until either a minimum is reached or the allocation succeeds. This is not ideal for userspace, particularly in migration scenarios,