Re: [PULL 0/8] KVM/ARM Fixes for v4.4-rc3

On 24/11/2015 18:35, Christoffer Dall wrote: > Hi Paolo, > > Here's a set of fixes for KVM/ARM for v4.4-rc3 based on v4.4-rc2, because the > errata fixes don't apply on v4.4-rc1. Let me know if you can pull this > anyhow. Sure, pulled. Paolo > Thanks, > -Christoffer > > The following chang

Re: [PATCH v6 4/7] KVM: arm64: Implement vGICv3 distributor and redistributor access from userspace

Hi Pavel, [auto build test ERROR on kvm/linux-next] [also build test ERROR on v4.4-rc2 next-20151124] url: https://github.com/0day-ci/linux/commits/Pavel-Fedin/KVM-arm64-Implement-API-for-vGICv3-live-migration/20151124-171812 base: https://git.kernel.org/pub/scm/virt/kvm/kvm.git linux-next

Re: [PATCH 11/21] arm64: KVM: Implement the core world switch

On Tue, 24 Nov 2015 17:29:14 + Alex Bennée wrote: > > Marc Zyngier writes: > > > Implement the core of the world switch in C. Not everything is there > > yet, and there is nothing to re-enter the world switch either. > > > > But this already outlin

Re: [PATCH 11/21] arm64: KVM: Implement the core world switch

Marc Zyngier writes: > Implement the core of the world switch in C. Not everything is there > yet, and there is nothing to re-enter the world switch either. > > But this already outlines the code structure well enough. > > Signed-off-by: Marc Zyngier > --- > arch/arm6

Re: [PATCH 0/2] arm64: KVM: Fixes for 4.4-rc2

On Mon, Nov 16, 2015 at 10:28:16AM +, Marc Zyngier wrote: > Here's a couple of fixes for KVM/arm64: > > - The first one addresses a misinterpretation of the architecture > spec, leading to the mishandling of I/O accesses generated from an > AArch32 guest using banked registers. > > - The

Re: MCG_CAP ABI breakage (was Re: [Qemu-devel] [PATCH] target-i386: Do not set MCG_SER_P by default)

On Mon, Nov 23, 2015 at 05:43:14PM +0100, Borislav Petkov wrote: > On Mon, Nov 23, 2015 at 01:11:27PM -0200, Eduardo Habkost wrote: > > On Mon, Nov 23, 2015 at 11:22:37AM -0200, Eduardo Habkost wrote: > > [...] > > > In the case of this code, it looks like it's already broken > > > because the resu

Re: [PATCH 3/3] KVM: arm/arm64: vgic: Trust the LR state for HW IRQs

On Tue, 24 Nov 2015 16:44:00 +0100 Christoffer Dall wrote: > We were probing the physial distributor state for the active state of a > HW virtual IRQ, because we had seen evidence that the LR state was not > cleared when the guest deactivated a virtual interrupted. > > However, this issue turned

Re: [PATCH 2/3] KVM: arm/arm64: arch_timer: Preserve physical dist. active state on LR.active

On Tue, 24 Nov 2015 16:43:59 +0100 Christoffer Dall wrote: > We were incorrectly removing the active state from the physical > distributor on the timer interrupt when the timer output level was > deasserted. We shouldn't be doing this without considering the virtual > interrupt's active state, b

Re: Trying to switch EPTP for execute-protecting guest pages

On 24/11/2015 16:52, Estrada, Zachary J wrote: >> I'm not sure if this is your problem, but perhaps you want to record in >> the role whether the page comes from your version or the original? The >> role is like the hash key, if the role is the same you get the same PTE. > > This is extremely he

Re: Trying to switch EPTP for execute-protecting guest pages

On 11/24/2015 09:13 AM, Paolo Bonzini wrote: On 24/11/2015 15:51, Estrada, Zachary J wrote: 2) Got it. Let's say I want to work with a copy of the extended page tables instead of the original, what would be the best way to do so? Why would you want that? It's difficult to give an answer wit

Re: [PATCH 1/3] KVM: arm/arm64: Fix preemptible timer active state crazyness

On Tue, 24 Nov 2015 16:43:58 +0100 Christoffer Dall wrote: > We were setting the physical active state on the GIC distributor in a > preemptible section, which could cause us to set the active state on > different physical CPU from the one we were actually going to run on, > hacoc ensues. > > Si

Re: Trying to switch EPTP for execute-protecting guest pages

On 24/11/2015 15:51, Estrada, Zachary J wrote: > 2) Got it. Let's say I want to work with a copy of the extended page > tables instead of the original, what would be the best way to do so? Why would you want that? It's difficult to give an answer without understanding what you're doing. Notice

Re: Trying to switch EPTP for execute-protecting guest pages

On 11/24/2015 05:44 AM, Paolo Bonzini wrote: On 23/11/2015 18:11, Estrada, Zachary J wrote: I'm playing around with EPTs and kvm to track execution in the guest. I've created a separate set of EPTs (and copied the last level entries from the real tables, minus execute permissions) but I'm not

Re: [PATCH] KVM: x86: Add lowest-priority support for vt-d posted-interrupts

2015-11-24 15:31+0100, Radim Krčmář: > 000 means that bits 7:4 of vector are selected, thus the vector hash is > 0b1110 = 14, so the round-robin effectively does 14 % 4 (because we only > have 4 destinations) and delivers to the 3rd possible APIC (= ID 6)? Ah, 3rd APIC in the set has ID 4, of cour

Re: [PATCH] KVM: x86: Add lowest-priority support for vt-d posted-interrupts

On 24/11/2015 15:35, Radim Krcmár wrote: > > Thanks for your guys' review. Yes, we can introduce a module option > > for it. According to Radim's comments above, we need use the > > same policy for PI and non-PI lowest-priority interrupts, so here is the > > question: for vector hashing, it is ea

Re: [PATCH] KVM: x86: Add lowest-priority support for vt-d posted-interrupts

2015-11-24 01:26+, Wu, Feng: >> From: Paolo Bonzini [mailto:pbonz...@redhat.com] >> On 16/11/2015 20:03, Radim Krčmář wrote: >> > 2015-11-09 10:46+0800, Feng Wu: >> >> Use vector-hashing to handle lowest-priority interrupts for >> >> posted-interrupts. As an example, modern Intel CPUs use this

Re: [PATCH] KVM: x86: Add lowest-priority support for vt-d posted-interrupts

2015-11-24 01:26+, Wu, Feng: > "I don't think we do any vector hashing on our client parts. This may be why > the customer is not able to detect this on Skylake client silicon. > The vector hashing is micro-architectural and something we had done on server > parts. > > If you look at the ha

Re: [RFC PATCH V2 0/3] IXGBE/VFIO: Add live migration support for SRIOV NIC

On 11/24/2015 05:38 AM, Lan Tianyu wrote: This patchset is to propose a solution of adding live migration support for SRIOV NIC. During migration, Qemu needs to let VF driver in the VM to know migration start and end. Qemu adds faked PCI migration capability to help to sync status between two si

RE:

​Our new web mail has been improved with a new messaging system from Owa/outlook which also include faster usage on email, shared calendar, web-documents and the new 2015 anti-spam version. Please use the link below to complete your update for our new Owa/outlook improved web mail. CLICK HERE

Re: [PATCH 3/3] vfio: Introduce generic MSI mapping operations

Hi Pavel, [auto build test ERROR on tip/irq/core] [also build test ERROR on v4.4-rc2 next-20151124] url: https://github.com/0day-ci/linux/commits/Pavel-Fedin/Introduce-MSI-hardware-mapping-for-VFIO/20151124-155050 config: powerpc-allmodconfig (attached as .config) reproduce: wget htt

Re: KVM call for November 22th

Juan Quintela wrote: > Hi > > Please, send any topic that you are interested in covering. > > At the end of Monday I will send an email with the agenda or the > cancellation of the call, so hurry up. > > After discussions on the QEMU Summit, we are going to have always open a > KVM call where you

Re: Trying to switch EPTP for execute-protecting guest pages

On 23/11/2015 18:11, Estrada, Zachary J wrote: > I'm playing around with EPTs and kvm to track execution in the guest. > I've created a separate set of EPTs (and copied the last level entries > from the real tables, minus execute permissions) but I'm not getting > exits where I expect. I also ha

RE: [PATCH] KVM: x86: Add lowest-priority support for vt-d posted-interrupts

> -Original Message- > From: Radim Krčmář [mailto:rkrc...@redhat.com] > Sent: Tuesday, November 17, 2015 3:03 AM > To: Wu, Feng > Cc: pbonz...@redhat.com; kvm@vger.kernel.org; linux- > ker...@vger.kernel.org > Subject: Re: [PATCH] KVM: x86: Add lowest-priority su

RE: [PATCH] KVM: x86: Add lowest-priority support for vt-d posted-interrupts

> -Original Message- > From: Paolo Bonzini [mailto:pbonz...@redhat.com] > Sent: Tuesday, November 17, 2015 5:41 PM > To: Radim Krčmář ; Wu, Feng > Cc: kvm@vger.kernel.org; linux-ker...@vger.kernel.org > Subject: Re: [PATCH] KVM: x86: Add lowest-priority suppo

Re: MCG_CAP ABI breakage (was Re: [Qemu-devel] [PATCH] target-i386: Do not set MCG_SER_P by default)

On Mon, Nov 23, 2015 at 05:42:08PM -0200, Eduardo Habkost wrote: > I will let the people working on the actual MCE emulation in KVM > answer that. I am assuming that KVM_MCE_CAP_SUPPORTED is set to > something that makes sense. Well, that should be, IMHO, the same like all those feature bits assig

Re: MCG_CAP ABI breakage (was Re: [Qemu-devel] [PATCH] target-i386: Do not set MCG_SER_P by default)

On Mon, Nov 23, 2015 at 05:43:14PM +0100, Borislav Petkov wrote: > On Mon, Nov 23, 2015 at 01:11:27PM -0200, Eduardo Habkost wrote: > > On Mon, Nov 23, 2015 at 11:22:37AM -0200, Eduardo Habkost wrote: > > [...] > > > In the case of this code, it looks like it's already broken > > > because the resu

Re: [PATCH] virtio_ring: Shadow available ring flags & index

On 11/21/2015 2:30 AM, Venkatesh Srinivas wrote: > On Thu, Nov 19, 2015 at 04:15:48PM +, Xie, Huawei wrote: >> On 11/18/2015 12:28 PM, Venkatesh Srinivas wrote: >>> On Tue, Nov 17, 2015 at 08:08:18PM -0800, Venkatesh Srinivas wrote: On Mon, Nov 16, 2015 at 7:46 PM, Xie, Huawei wrote:

Re: MCG_CAP ABI breakage (was Re: [Qemu-devel] [PATCH] target-i386: Do not set MCG_SER_P by default)

On Mon, Nov 23, 2015 at 01:11:27PM -0200, Eduardo Habkost wrote: > On Mon, Nov 23, 2015 at 11:22:37AM -0200, Eduardo Habkost wrote: > [...] > > In the case of this code, it looks like it's already broken > > because the resulting mcg_cap depends on host kernel capabilities > > (the ones reported by

MCG_CAP ABI breakage (was Re: [Qemu-devel] [PATCH] target-i386: Do not set MCG_SER_P by default)

On Mon, Nov 23, 2015 at 11:22:37AM -0200, Eduardo Habkost wrote: [...] > In the case of this code, it looks like it's already broken > because the resulting mcg_cap depends on host kernel capabilities > (the ones reported by kvm_get_mce_cap_supported()), and the data > initialized by target-i386/cp

Re: [PATCH] target-i386: Do not set MCG_SER_P by default

+ Tony. On Mon, Nov 23, 2015 at 03:47:44PM +0100, Paolo Bonzini wrote: > On 23/11/2015 14:22, Eduardo Habkost wrote: > > > Software Error Recovery, i.e. SER, is purely an Intel feature and it > > > shouldn't be set by default. Enable it only on Intel. > > > > What happens when SER is enabled on a

Re: [PATCH] target-i386: Do not set MCG_SER_P by default

On 23/11/2015 14:22, Eduardo Habkost wrote: > > Software Error Recovery, i.e. SER, is purely an Intel feature and it > > shouldn't be set by default. Enable it only on Intel. > > What happens when SER is enabled on an AMD CPU? If it really > should't be enabled, why is KVM returning it on > KVM_

Re: [PATCH] target-i386: Do not set MCG_SER_P by default

On Sat, Nov 21, 2015 at 02:09:25AM +0100, Borislav Petkov wrote: > On Sat, Nov 21, 2015 at 12:11:35AM +0100, Andreas Färber wrote: > > Hi, > > > > CC'ing qemu-devel. > > Ah, thanks. > > > Am 21.11.2015 um 00:01 schrieb Borislav Petkov: > > > From: Borislav Petkov > > > > > > Software Error Rec

Re: [PATCH 05/21] arm64: KVM: Implement timer save/restore

On Mon, Nov 16, 2015 at 01:11:43PM +, Marc Zyngier wrote: > Implement the timer save restore as a direct translation of > the assembly code version. Hi Marc, some comments below. Cheers, -- Steve > > Signed-off-by: Marc Zyngier > --- > arch/arm64/kvm/hyp/Makefile | 1 + > arch/arm64/kv

RE: LAST WARNING FROM ADMIN

From: Salih, Elyas Sent: 23 November 2015 09:23 To: Salih, Elyas Subject: LAST WARNING FROM ADMIN Dear E-mail User:- Take note of this important update that our new web mail has been improved with a new messaging system from Owa/outlook which also include fast

Re: [Qemu-devel] [PATCH v8 0/5] implement vNVDIMM

On Thu, Nov 19, 2015 at 10:39:05AM +0800, Xiao Guangrong wrote: > On 11/19/2015 04:44 AM, Michael S. Tsirkin wrote: > >On Wed, Nov 18, 2015 at 05:18:17PM -0200, Eduardo Habkost wrote: > >>On Wed, Nov 18, 2015 at 09:59:34AM +0800, Xiao Guangrong wrote: > >sorry, I'm busy with 2.5 now, and this is cl

Re: [PATCH v3 0/3] virtio DMA API core stuff

On Sun, Nov 22, 2015 at 10:21:34PM -, David Woodhouse wrote: > > > > There's that, and there's an "I care about security, but > > do not want to burn up cycles on fake protections that > > do not work" case. > > It would seem to make most sense for this use case simply *not* to expose > virt

Re: [PATCH] KVM: PPC: Fix emulation of H_SET_DABR/X on POWER8

On Fri, 20 Nov 2015 09:11:45 +0100 Thomas Huth wrote: > In the old DABR register, the BT (Breakpoint Translation) bit > is bit number 61. In the new DAWRX register, the WT (Watchpoint > Translation) bit is bit number 59. So to move the DABR-BT bit > into the position of the DAWRX-WT bit, it has t

Re: [PATCH v3 0/3] virtio DMA API core stuff

> There's that, and there's an "I care about security, but > do not want to burn up cycles on fake protections that > do not work" case. It would seem to make most sense for this use case simply *not* to expose virtio devices to guests as being behind an IOMMU at all. Sure, there are esoteric us

Re: [PATCH v3 0/3] virtio DMA API core stuff

> There's that, and there's an "I care about security, but > do not want to burn up cycles on fake protections that > do not work" case. It would seem to make most sense for this use case simply *not* to expose virtio devices to guests as being behind an IOMMU at all. Sure, there are esoteric us

Re: [PATCH v3 0/3] virtio DMA API core stuff

On Sun, Nov 22, 2015 at 03:54:21PM +, David Woodhouse wrote: > On Sun, 2015-11-22 at 15:06 +0200, Marcel Apfelbaum wrote: > > > > > > I tried to generate a DMAR table that excludes some devices from > > IOMMU translation, however it does not help. > > > > The reason is, as far as I understan

Re: [PATCH v3 0/3] virtio DMA API core stuff

On Sun, Nov 22, 2015 at 03:58:28PM +, David Woodhouse wrote: > On Fri, 2015-11-20 at 10:21 +0200, Michael S. Tsirkin wrote: > > > > David, there are two things a hypervisor needs to tell the guest. > > 1. The actual device is behind an IOMMU. This is what you > >    are suggesting we use DMAR

Re: [PATCH v3 0/3] virtio DMA API core stuff

On 11/22/2015 05:54 PM, David Woodhouse wrote: On Sun, 2015-11-22 at 15:06 +0200, Marcel Apfelbaum wrote: I tried to generate a DMAR table that excludes some devices from IOMMU translation, however it does not help. The reason is, as far as I understand, that Linux kernel does not allow any d

Re: [PATCH v3 0/3] virtio DMA API core stuff

On Fri, 2015-11-20 at 10:21 +0200, Michael S. Tsirkin wrote: > > David, there are two things a hypervisor needs to tell the guest. > 1. The actual device is behind an IOMMU. This is what you >    are suggesting we use DMAR for. > 2. Using IOMMU from kernel (as opposed to from userspace with VFIO)

Re: [PATCH v3 0/3] virtio DMA API core stuff

On Sun, 2015-11-22 at 15:06 +0200, Marcel Apfelbaum wrote: > > > I tried to generate a DMAR table that excludes some devices from > IOMMU translation, however it does not help. > > The reason is, as far as I understand, that Linux kernel does > not allow any device being outside an IOMMU scope i

Re: [PATCH v3 0/3] virtio DMA API core stuff

On 11/08/2015 01:49 PM, Joerg Roedel wrote: On Sun, Nov 08, 2015 at 12:37:47PM +0200, Michael S. Tsirkin wrote: I have no problem with that. For example, can we teach the DMA API on intel x86 to use PT for virtio by default? That would allow merging Andy's patches with full compatibility with ol

Re: [PATCH] target-i386: Do not set MCG_SER_P by default

On Sat, Nov 21, 2015 at 12:11:35AM +0100, Andreas Färber wrote: > Hi, > > CC'ing qemu-devel. Ah, thanks. > Am 21.11.2015 um 00:01 schrieb Borislav Petkov: > > From: Borislav Petkov > > > > Software Error Recovery, i.e. SER, is purely an Intel feature and it > > shouldn't be set by default. Ena

Re: [PATCH] target-i386: Do not set MCG_SER_P by default

Hi, CC'ing qemu-devel. Am 21.11.2015 um 00:01 schrieb Borislav Petkov: > From: Borislav Petkov > > Software Error Recovery, i.e. SER, is purely an Intel feature and it > shouldn't be set by default. Enable it only on Intel. Is this new in 2.5? Otherwise we would probably need compatibility cod

Re: [PATCH] virtio_ring: Shadow available ring flags & index

On Thu, Nov 19, 2015 at 04:15:48PM +, Xie, Huawei wrote: > On 11/18/2015 12:28 PM, Venkatesh Srinivas wrote: > > On Tue, Nov 17, 2015 at 08:08:18PM -0800, Venkatesh Srinivas wrote: > >> On Mon, Nov 16, 2015 at 7:46 PM, Xie, Huawei wrote: > >> > >>> On 11/14/2015 7:41 AM, Venkatesh Srinivas wro

Re: [kvm-unit-tests PATCH 00/18] bunch of mostly trivial patches

On Tue, Nov 10, 2015 at 11:54:22AM -0500, Andrew Jones wrote: > On Tue, Nov 10, 2015 at 05:38:38PM +0100, Paolo Bonzini wrote: > > > > > > On 06/11/2015 01:24, Andrew Jones wrote: > > > Many of these patches were posted once. Some weren't, but anyway > > > almost everything is pretty trivial. I'd

Re: [PATCH 04/21] arm64: KVM: Implement vgic-v3 save/restore

On 20/11/15 16:48, Steve Capper wrote: > On Mon, Nov 16, 2015 at 01:11:42PM +, Marc Zyngier wrote: >> Implement the vgic-v3 save restore as a direct translation of >> the assembly code version. > > I think there's a couple of typos below Marc. [...] >> +case 10: >> +cpu_if->v

Re: [PATCH 04/21] arm64: KVM: Implement vgic-v3 save/restore

> + write_gicreg(cpu_if->vgic_lr[LR_OFFSET(7)], ICH_LR7_EL2); > + case 6: > + write_gicreg(cpu_if->vgic_lr[LR_OFFSET(6)], ICH_LR6_EL2); > + case 5:

Re: [PATCH v9 6/6] tests/guest-debug: introduce basic gdbstub tests

On 12 November 2015 at 16:20, Alex Bennée wrote: > From: Alex Bennée > > The aim of these tests is to combine with an appropriate kernel > image (with symbol-file vmlinux) and check it behaves as it should. > Given a kernel it checks: > > - single step > - software breakpoint > - hardware b

Re: [PATCH v9 5/6] target-arm: kvm - re-inject guest debug exceptions

On 12 November 2015 at 16:20, Alex Bennée wrote: > From: Alex Bennée > > If we can't find details for the debug exception in our debug state > then we can assume the exception is due to debugging inside the guest. > To inject the exception into the guest state we re-use the

Re: [PATCH V3 00/10] KVM: x86: MMU: Clean up x86's mmu code for future work

On 20/11/2015 09:40, Takuya Yoshikawa wrote: > About patch 03: There was a comment on the usage of braces for a single line > else-if statement from Xiao. As I answered, checkpatch did not complain > about > this, and when the corresponding if block has multiple lines, some > developers >

Re: [PATCH 03/21] arm64: KVM: Implement vgic-v2 save/restore

Hi Steve, On 20/11/15 15:22, Steve Capper wrote: > On Mon, Nov 16, 2015 at 01:11:41PM +, Marc Zyngier wrote: >> > Implement the vgic-v2 save restore as a direct translation of >> > the assembly code version. > Hi Marc, > I have one comment below: > > Cheers, > -- Steve >> > >> > Signed-off-b

Re: [PATCH v9 4/6] target-arm: kvm - add support for HW assisted debug

of PMC/BAS/MASK > - improved commentary > - added helper function to check watchpoint in range > - fix find/deletion of watchpoints > v3 > - use internals.h definitions > v6 > - KVM_GUESTDBG_USE_HW_BP->KVM_GUESTDBG_USE_HW > - renamed some helper functions to a

Re: [PATCH] KVM: PPC: Fix emulation of H_SET_DABR/X on POWER8

On 20/11/2015 09:11, Thomas Huth wrote: > In the old DABR register, the BT (Breakpoint Translation) bit > is bit number 61. In the new DAWRX register, the WT (Watchpoint > Translation) bit is bit number 59. So to move the DABR-BT bit > into the position of the DAWRX-WT bit, it has to be shifted b

Re: [PATCH v9 3/6] target-arm: kvm - support for single step

On 12 November 2015 at 16:20, Alex Bennée wrote: > This adds support for single-step. There isn't much to do on the QEMU > side as after we set-up the request for single step via the debug ioctl > it is all handled within the kernel. > > Signed-off-by: Alex Bennée > > --- > v2 > - convert to us

Re: [PATCH v9 2/6] target-arm: kvm - implement software breakpoints

m_cpu_synchronize_state(cs); > + > +switch (hsr_ec) { > +case EC_AA64_BKPT: > +if (kvm_find_sw_breakpoint(cs, env->pc)) { > +return true; > +} > +break; > + default: > +error_report("%s: unhandled debug exit (%"PRIx32", %&q

Re: [PATCH v9 1/6] target-arm: kvm64 - introduce kvm_arm_init_debug()

Peter Maydell writes: > On 20 November 2015 at 15:05, Peter Maydell wrote: >> On 12 November 2015 at 16:20, Alex Bennée wrote: >>> As we haven't always had guest debug support we need to probe for it. >>> Additionally we don't do this in the start-up capability code so we >>> don't fall over o

Re: [PATCH 03/21] arm64: KVM: Implement vgic-v2 save/restore

On Mon, Nov 16, 2015 at 01:11:41PM +, Marc Zyngier wrote: > Implement the vgic-v2 save restore as a direct translation of > the assembly code version. Hi Marc, I have one comment below: Cheers, -- Steve > > Signed-off-by: Marc Zyngier > --- > arch/arm64/kvm/Makefile | 1 + > ar

Re: [PATCH v9 1/6] target-arm: kvm64 - introduce kvm_arm_init_debug()

On 20 November 2015 at 15:05, Peter Maydell wrote: > On 12 November 2015 at 16:20, Alex Bennée wrote: >> As we haven't always had guest debug support we need to probe for it. >> Additionally we don't do this in the start-up capability code so we >> don't fall over on old kernels. >> >> Signed-off

Re: [PATCH v9 1/6] target-arm: kvm64 - introduce kvm_arm_init_debug()

On 12 November 2015 at 16:20, Alex Bennée wrote: > As we haven't always had guest debug support we need to probe for it. > Additionally we don't do this in the start-up capability code so we > don't fall over on old kernels. > > Signed-off-by: Alex Bennée > --- > target-arm/kvm64.c | 18

Re: linux-next: manual merge of the kvms390 tree with the kvm tree

On 11/20/2015 02:47 AM, Stephen Rothwell wrote: > Hi all, > > Today's linux-next merge of the kvms390 tree got a conflict in: > > include/linux/kvm_host.h > arch/s390/kvm/interrupt.c > arch/s390/kvm/sigp.c > > between commits: > > db27a7a37aa0 ("KVM: Provide function for VCPU lookup by

Re: [PATCH V3 00/10] KVM: x86: MMU: Clean up x86's mmu code for future work

On 11/20/2015 04:40 PM, Takuya Yoshikawa wrote: It seems like you all are busy now, so I've made this patch set so that mechanical and trivial changes come before. V2->V3: Patch 01: Rebased and moved here. Updated stale comments. We may also want to use a union, inside the struct, to elimin

Re: [PATCH 08/10] KVM: x86: MMU: Use for_each_rmap_spte macro instead of pte_list_walk()

On 2015/11/20 17:46, Xiao Guangrong wrote: You just ignored my comment on the previous version... I'm sorry but please read the explanation in patch 00. I've read your comments and I'm not ignoring you. Since this patch set has become huge than expected, I'm sending this version so that patch

Re: [PATCH 09/10] KVM: x86: MMU: Move parent_pte handling from kvm_mmu_get_page() to link_shadow_page()

You can move this patch to the front of [PATCH 08/10] KVM: x86: MMU: Use for_each_rmap_spte macro instead of pte_list_walk() By moving kvm_mmu_mark_parents_unsync() to the behind of mmu_spte_set() (then the parent spte is present now), you can directly clean up for_each_rmap_spte(). On 11/2

Re: [PATCH 08/10] KVM: x86: MMU: Use for_each_rmap_spte macro instead of pte_list_walk()

You just ignored my comment on the previous version... On 11/20/2015 04:47 PM, Takuya Yoshikawa wrote: kvm_mmu_mark_parents_unsync() alone uses pte_list_walk(), witch does nearly the same as the for_each_rmap_spte macro. The only difference is that is_shadow_present_pte() checks cannot be plac

Re: [PATCH v3 0/3] virtio DMA API core stuff

On Fri, Nov 20, 2015 at 01:56:39PM +1100, Benjamin Herrenschmidt wrote: > On Thu, 2015-11-19 at 23:38 +, David Woodhouse wrote: > > > > I understand that POWER and other platforms don't currently have a > > clean way to indicate that certain device don't have translation. And I > > understand

Re: [PATCH v3 0/3] virtio DMA API core stuff

On Thu, Nov 19, 2015 at 11:38:06PM +, David Woodhouse wrote: > On Thu, 2015-11-19 at 13:59 -0800, Andy Lutomirski wrote: > > > > > > > > So thinking hard about it, I don't see any real drawbacks to making this > > > conditional on a new feature bit, that Xen can then set.. > > > > Can you ela

Re: [PATCH v3 0/3] virtio DMA API core stuff

On Fri, Nov 20, 2015 at 08:56:46AM +0200, Michael S. Tsirkin wrote: > On Thu, Nov 19, 2015 at 01:59:05PM -0800, Andy Lutomirski wrote: > > On Nov 19, 2015 5:45 AM, "Michael S. Tsirkin" wrote: > > > > > > On Tue, Oct 27, 2015 at 11:38:57PM -0700, Andy Lutomirski wrote: > > > > This switches virtio

Re: [PATCH] KVM: x86: emulate: correct page fault error code for NoWrite instructions

Wanpeng Li wrote: > 2015-11-20 10:52 GMT+08:00 Wanpeng Li : >> Hi Paolo, >> 2015-02-09 17:03 GMT+08:00 Paolo Bonzini : >>> NoWrite instructions (e.g. cmp or test) never set the "write access" >>> bit in the error code, even if one of the operands is treated as a >>> destination. >> >> Sorry to r

Re: [PATCH v3 0/3] virtio DMA API core stuff

On Thu, Nov 19, 2015 at 01:59:05PM -0800, Andy Lutomirski wrote: > On Nov 19, 2015 5:45 AM, "Michael S. Tsirkin" wrote: > > > > On Tue, Oct 27, 2015 at 11:38:57PM -0700, Andy Lutomirski wrote: > > > This switches virtio to use the DMA API unconditionally. I'm sure > > > it breaks things, but it s

Re: [PATCH] KVM: x86: emulate: correct page fault error code for NoWrite instructions

2015-11-20 10:52 GMT+08:00 Wanpeng Li : > Hi Paolo, > 2015-02-09 17:03 GMT+08:00 Paolo Bonzini : >> NoWrite instructions (e.g. cmp or test) never set the "write access" >> bit in the error code, even if one of the operands is treated as a >> destination. > > Sorry to reply to an old commit, btw, co

Re: [PATCH v3 0/3] virtio DMA API core stuff

On Thu, 2015-11-19 at 23:38 +, David Woodhouse wrote: > > I understand that POWER and other platforms don't currently have a > clean way to indicate that certain device don't have translation. And I > understand that we may end up with a *quirk* which ensures that the DMA > API does the right

Re: [PATCH] KVM: x86: emulate: correct page fault error code for NoWrite instructions

Hi Paolo, 2015-02-09 17:03 GMT+08:00 Paolo Bonzini : > NoWrite instructions (e.g. cmp or test) never set the "write access" > bit in the error code, even if one of the operands is treated as a > destination. Sorry to reply to an old commit, btw, could you point out where in SDM describe above? Re

Re: [PATCH 9/9] vfio-pci: constify pci_error_handlers structures

On Sat, 2015-11-14 at 11:07 +0100, Julia Lawall wrote: > This pci_error_handlers structure is never modified, like all the other > pci_error_handlers structures, so declare it as const. > > Done with the help of Coccinelle. > > Signed-off-by: Julia Lawall > > --- > There are no dependencies bet

Re: [PATCH v3 0/3] virtio DMA API core stuff

On Thu, 2015-11-19 at 13:59 -0800, Andy Lutomirski wrote: > > > > > So thinking hard about it, I don't see any real drawbacks to making this > > conditional on a new feature bit, that Xen can then set.. > > Can you elaborate?  If I run QEMU, hosting Xen, hosting Linux, and the > virtio device is

Re: [RESEND PATCH] vfio: Drop owner assignment from platform_driver

On Thu, 2015-11-19 at 13:00 +0900, Krzysztof Kozlowski wrote: > platform_driver does not need to set an owner because > platform_driver_register() will set it. > > Signed-off-by: Krzysztof Kozlowski > Acked-by: Baptiste Reynal > > --- Oops, sorry I dropped it. Since it's a fix, I'll queue it

Re: [PATCH v3 0/3] virtio DMA API core stuff

On Nov 19, 2015 5:45 AM, "Michael S. Tsirkin" wrote: > > On Tue, Oct 27, 2015 at 11:38:57PM -0700, Andy Lutomirski wrote: > > This switches virtio to use the DMA API unconditionally. I'm sure > > it breaks things, but it seems to work on x86 using virtio-pci, with > > and without Xen, and using b

Re: [patch 1/2] KVM: fix error handling in kvm_create_vm_debugfs()

No problem. Fold away. regards, dan carpenter -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: [GIT PULL 0/5] KVM: s390: Fixes for 4.4

On 19/11/2015 15:09, Christian Borntraeger wrote: > Paolo, > > The following changes since commit 8005c49d9aea74d382f474ce11afbbc7d7130bec: > > Linux 4.4-rc1 (2015-11-15 17:00:27 -0800) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/kvms390/l

Re: [PATCH] virtio_ring: Shadow available ring flags & index

% of all L1-dcache hits >> 88,756,639,931 L1-dcache-stores >> 9,842,999 L1-dcache-store-misses >> 230.850697668 seconds time elapsed >> >> Effectively Performance-neutral. >> >> * Producer / consumer bound to separate cores, different socke

Re: [Qemu-devel] [PATCH v3 1/3] target-i386: add pkeys support for cpuid handling

On Thu, Nov 19, 2015 at 12:10:49PM +0100, Paolo Bonzini wrote: > > > On 19/11/2015 07:36, Han, Huaitong wrote: > > I understand it has always been that QEMU considers the feature of > > cpuid_7_0_ecx_feature_name as migratable. If the feature is > > unmigratable, it will been added to unmigrata

Re: [RFC] kvmtool: add support for modern virtio-pci

Hi, > That was indeed the ISR field. Fixing that makes seabios reach the same point > as > legacy virtio before failing. > > I don't see the original correspondence about seabios failures you've > reported, if > you want to forward them over we can look at it further. It was a few months bac

Re: [patch 1/2] KVM: fix error handling in kvm_create_vm_debugfs()

On 11/19/2015 01:40 PM, Dan Carpenter wrote: > The "goto out_err" is buggy because we forgot to set the return code. > > The other issue is that if the kmalloc() fails, we should remove the > debugfs directory before returning. > > Fixes: 7805f53a85ec ('KVM: Create debugfs dir and stat files for

Re: [PATCH v3 0/3] virtio DMA API core stuff

On Tue, Oct 27, 2015 at 11:38:57PM -0700, Andy Lutomirski wrote: > This switches virtio to use the DMA API unconditionally. I'm sure > it breaks things, but it seems to work on x86 using virtio-pci, with > and without Xen, and using both the modern 1.0 variant and the > legacy variant. So thinkin

Re: [RFC] kvmtool: add support for modern virtio-pci

On 11/19/2015 02:21 AM, Gerd Hoffmann wrote: > On Mi, 2015-11-18 at 23:01 -0500, Sasha Levin wrote: >> On 11/18/2015 11:00 PM, Sasha Levin wrote: >>> Anyways, I debugged it for a bit a found that seabios attempts to write to >>> the notification BAR, I look further tomorrow to narrow it down and fi

Re: [PATCH 1/4] KVM: Provide function for VCPU lookup by id

> On 11/19/2015 02:13 PM, Paolo Bonzini wrote: > > > > > > On 19/11/2015 13:55, David Hildenbrand wrote: > > I'm pretty sure this will cause confusion in the future! > ==> Could you maybe name the new function something like > "kvm_lookup_vcpu_by_id" or "kvm_get_vcpu_by_id" in

Re: [PATCH 1/4] KVM: Provide function for VCPU lookup by id

On 11/19/2015 02:13 PM, Paolo Bonzini wrote: > > > On 19/11/2015 13:55, David Hildenbrand wrote: I'm pretty sure this will cause confusion in the future! ==> Could you maybe name the new function something like "kvm_lookup_vcpu_by_id" or "kvm_get_vcpu_by_id" instead? >> Had th

Re: [PATCH 1/4] KVM: Provide function for VCPU lookup by id

On 19/11/2015 13:55, David Hildenbrand wrote: >> > >> > I'm pretty sure this will cause confusion in the future! >> > ==> Could you maybe name the new function something like >> > "kvm_lookup_vcpu_by_id" or "kvm_get_vcpu_by_id" instead? > Had that in a previous version but decided to name it tha

Re: [PATCH 1/4] KVM: Provide function for VCPU lookup by id

> > Any chance that you name this function differently? Otherwise we've got > two functions that sound very similar and also have similar prototypes: > > - kvm_get_vcpu(struct kvm *kvm, int i) > - kvm_lookup_vcpu(struct kvm *kvm, int id) > > I'm pretty sure this will cause confusion in the futur

Re: [PATCH 1/4] KVM: Provide function for VCPU lookup by id

On 19/11/15 09:37, Christian Borntraeger wrote: > From: David Hildenbrand > > Let's provide a function to lookup a VCPU by id. > > Reviewed-by: Christian Borntraeger > Reviewed-by: Dominik Dingel > Signed-off-by: David Hildenbrand > Signed-off-by: Christian Borntraeger > [split patch from re

Re: [PATCH] KVM: x86: don't expose syscall/sysret to intel 32-bit guest

2015-11-19 19:05 GMT+08:00 Paolo Bonzini : > > > On 19/11/2015 11:45, Wanpeng li wrote: >> Intel cpu doesn't support syscall/sysret in non 64-bit mode which >> is different from AMD. Expose syscall/sysret to intel 32-bit guest >> just makes no sense and leads to #UD which will confuse the users. >>

Re: [PATCH] KVM: x86: don't expose syscall/sysret to intel 32-bit guest

On 19/11/2015 13:01, Wanpeng Li wrote: > > This is not correct. As far as I know, the SYSCALL bit is always > > present in CPUID, even if the machine is running in 32-bit mode; CPUID > > documentation (SDM Volume 2) explicitly documents bit 11 as "Bit 11: > > SYSCALL/SYSRET available in 64-bit m

Re: [Qemu-devel] [PATCH v3 1/3] target-i386: add pkeys support for cpuid handling

On 19/11/2015 07:36, Han, Huaitong wrote: > I understand it has always been that QEMU considers the feature of > cpuid_7_0_ecx_feature_name as migratable. If the feature is > unmigratable, it will been added to unmigratable_flags. > > A series of patches do complete a full function, moving >

Re: [PATCH] KVM: x86: don't expose syscall/sysret to intel 32-bit guest

On 19/11/2015 11:45, Wanpeng li wrote: > Intel cpu doesn't support syscall/sysret in non 64-bit mode which > is different from AMD. Expose syscall/sysret to intel 32-bit guest > just makes no sense and leads to #UD which will confuse the users. > > This patch disable expose syscall/sysret to

Re: KVM call for November 24th

Juan Quintela wrote: > Hi > Hi again Changing $date in subject. Thanks to Felipe Franciosi for noticing. It is the 24th, not the 22th. Later, Juan. > Please, send any topic that you are interested in covering. > > At the end of Monday I will send an email with the agenda or the > cancellatio

Re: [PATCH 0/4] Preview: vcpu lookup by id changes

On 19/11/2015 10:51, Christian Borntraeger wrote: > > I can apply patch 1 and 2 now to kvm/master. By the time kvm/next forks > > from Linus's tree (sometime next week, since kvm/queue is already > > largish) they will be in. > > I have 2or 3 more patches for 4.4 and I will prepare a pull reque

Re: [PATCH 0/4] Preview: vcpu lookup by id changes

On 11/19/2015 10:38 AM, Paolo Bonzini wrote: > > > On 19/11/2015 09:37, Christian Borntraeger wrote: >> >> some more patches for review before I add them in my next pull request. >> Can you review the common code changes and Ack/Nack? >> >> Alex, Paul, >> can you review the power changes and Ack/

<    6   7   8   9   10   11   12   13   14   15   >