Re: [fedora-virt] 3.13 - Nested KVM (vmx) totally broken?
Il 04/03/2014 03:40, Ian Pilcher ha scritto: Is this a known problem? I just tried using nested vmx for the first time since upgrading my system from F19 (3.12.?? at the time) to F20, and I cannot start any L2 guests. The L2 guest appears to hang almost immediately after starting, consuming 100% of one of the L1 guest's VCPUs. If I reboot with kernel-3.12.10-300.fc20.x86_64, the problem does not occur. Any known workaround? (Other than using 3.12.10?) There is a fix on the way to the 3.13 kernel. You can open a Fedora bug and ask them to include http://article.gmane.org/gmane.linux.kernel.stable/82043/raw in the kernel. Paolo -- 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: [RFC]VM live snapshot proposal
On Tue, Mar 04, 2014 at 01:02:44AM +, Huangpeng (Peter) wrote: But back to the options: If the host has enough free memory to fork QEMU, a small helper process can be used to save the copy-on-write memory snapshot (thanks to fork(2) semantics). The hard part about the fork(2) approach is that QEMU isn't really designed to fork, so work is necessary to reach a quiescent state for the child process. If there is not enough memory to fork, then a synchronous approach to catching guest memory writes is needed. I'm not sure if a good mechanism for that exists but the simplest would be mprotect(2) and a signal handler (which will make the guest run very slowly). Stefan In real production environment, memory over-commit or use as much memory as possible may be the normal case, so the fork semantics cannot meet the needs. Yes, I think you're right. The fork approach only works in the easy case where there is plenty of free host memory. Is there any other proposals to implement vm-snapshot? See the discussion by Paolo and Andrea about post-copy migration, which adds kernel memory management features for tracking userspace page faults. Perhaps you can use that infrastructure to trap guest writes. Stefan -- 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: [Qemu-devel] [PATCH 1/6] s390x/virtio-ccw: Adapter interrupt support.
On Tue, 25 Feb 2014 18:25:15 +0100 Cornelia Huck cornelia.h...@de.ibm.com wrote: Handle the new CCW_CMD_SET_IND_ADAPTER command enabling adapter interrupts on guest request. When active, host-guest notifications will be handled via global_indicator - queue indicators instead of queue indicators + subchannel I/O interrupt. Indicators for virtqueues may be present at an offset. Signed-off-by: Cornelia Huck cornelia.h...@de.ibm.com --- hw/s390x/css.c| 10 + hw/s390x/css.h|2 + hw/s390x/virtio-ccw.c | 102 + hw/s390x/virtio-ccw.h |4 ++ target-s390x/ioinst.h |2 + target-s390x/kvm.c|8 +++- trace-events |1 + 7 files changed, 120 insertions(+), 9 deletions(-) As this is a nicely self-contained patch, I'd like to send a pull request for this, unless there are any objections. -- 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: [RFC]VM live snapshot proposal
Il 04/03/2014 09:54, Stefan Hajnoczi ha scritto: Is there any other proposals to implement vm-snapshot? See the discussion by Paolo and Andrea about post-copy migration, which adds kernel memory management features for tracking userspace page faults. Perhaps you can use that infrastructure to trap guest writes. That infrastructure actually traps guest reads too. But it's fine, as they are a superset of guest writes and the image will still be consistent. Paolo -- 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: [Qemu-devel] [PATCH 1/6] s390x/virtio-ccw: Adapter interrupt support.
On 04/03/14 10:05, Cornelia Huck wrote: On Tue, 25 Feb 2014 18:25:15 +0100 Cornelia Huck cornelia.h...@de.ibm.com wrote: Handle the new CCW_CMD_SET_IND_ADAPTER command enabling adapter interrupts on guest request. When active, host-guest notifications will be handled via global_indicator - queue indicators instead of queue indicators + subchannel I/O interrupt. Indicators for virtqueues may be present at an offset. Signed-off-by: Cornelia Huck cornelia.h...@de.ibm.com --- hw/s390x/css.c| 10 + hw/s390x/css.h|2 + hw/s390x/virtio-ccw.c | 102 + hw/s390x/virtio-ccw.h |4 ++ target-s390x/ioinst.h |2 + target-s390x/kvm.c|8 +++- trace-events |1 + 7 files changed, 120 insertions(+), 9 deletions(-) As this is a nicely self-contained patch, I'd like to send a pull request for this, unless there are any objections. ACK from my side. I will send out the guest kernel patch with the next kvm patches for s390. Christian -- 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: [fedora-virt] 3.13 - Nested KVM (vmx) totally broken?
On Tue, Mar 04, 2014 at 09:13:40AM +0100, Paolo Bonzini wrote: Il 04/03/2014 03:40, Ian Pilcher ha scritto: Is this a known problem? I just tried using nested vmx for the first time since upgrading my system from F19 (3.12.?? at the time) to F20, and I cannot start any L2 guests. The L2 guest appears to hang almost immediately after starting, consuming 100% of one of the L1 guest's VCPUs. If I reboot with kernel-3.12.10-300.fc20.x86_64, the problem does not occur. Any known workaround? (Other than using 3.12.10?) If you want to try, I made a Fedora Kernel scratch build (i.e. not official) with fix Paolo pointed to below and this works for me: http://koji.fedoraproject.org/koji/taskinfo?taskID=6577700 (NOTE: Fedora Scratch build URLs won't last more than 10 days or so) There is a fix on the way to the 3.13 kernel. You can open a Fedora bug and ask them to include http://article.gmane.org/gmane.linux.kernel.stable/82043/raw in the kernel. Paolo -- 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 -- /kashyap -- 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: [fedora-virt] 3.13 - Nested KVM (vmx) totally broken?
On Tue, Mar 04, 2014 at 03:00:22PM +0530, Kashyap Chamarthy wrote: On Tue, Mar 04, 2014 at 09:13:40AM +0100, Paolo Bonzini wrote: Il 04/03/2014 03:40, Ian Pilcher ha scritto: Is this a known problem? I just tried using nested vmx for the first time since upgrading my system from F19 (3.12.?? at the time) to F20, and I cannot start any L2 guests. The L2 guest appears to hang almost immediately after starting, consuming 100% of one of the L1 guest's VCPUs. If I reboot with kernel-3.12.10-300.fc20.x86_64, the problem does not occur. Err, I missed to read this. Sorry about that. Any known workaround? (Other than using 3.12.10?) If you want to try, I made a Fedora Kernel scratch build (i.e. not official) with fix Paolo pointed to below and this works for me: http://koji.fedoraproject.org/koji/taskinfo?taskID=6577700 (NOTE: Fedora Scratch build URLs won't last more than 10 days or so) There is a fix on the way to the 3.13 kernel. You can open a Fedora bug and ask them to include http://article.gmane.org/gmane.linux.kernel.stable/82043/raw in the kernel. Paolo -- 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 -- /kashyap -- /kashyap -- 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: [Qemu-devel] [RFC]VM live snapshot proposal
* Huangpeng (Peter) (peter.huangp...@huawei.com) wrote: I think this is different in the same way that block-backup and block-mirror are different. Huangpeng's proposal would let you make a consistent snapshot of disks and RAM. Right. Though the point isn't about consistency (doing the disk snapshot when memory has converged would be consistent as well), but about having the snapshot semantically right at the time when the monitor command is issued instead of only starting it then and being consistent at the point of completion. This is indeed like pre/post-copy live migration, and probably both options have their uses. I would suggest starting with the easy one, and adding the post-copy feature on top. Good suggestion, The latest patches of post-copy seems updated 2 years ago. https://github.com/yamahata/qemu I'm working on post-copy at the moment, using Andrea's kernel code, using bits of Yamahata's code base as well; hopefully it won't be too long until we have something to post. One question: Can post-copy fallback if exceptions happen during post-copy? What do you mean by 'exceptions' here? Generally postcopy can't fall back to precopy because once you're in postcopy mode the state is split between the two machines. Dave -- Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK -- 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
Guest VMs access a strange address
Hi there,
I have tried to log EPT construction status at VM startup, that is to
add some codes in function __direct_map (arch/x86/kvm/mmu.c).
__direct_map constructs the EPT paging structure when a guest page
firstly touched, and I can get related gfn and pfn here.
But I tracked a strange address, which is vcpu 0 pfn
0x8000 gfn 0xfebf1. Here pfn and gfn are the value of
the params in function __direct_map. How can pfn be
0x8000? Besides, I searched 0xfebf1 in kvm-memslots and
cannot get it in any memslots, but __direct_map catches this memory
access and build the mapping. Why should this happen?
Thanks ahead,
Arthur
A1. Here's my code in __direct_map:
for_each_shadow_entry(vcpu, (u64)gfn PAGE_SHIFT, iterator) {
if (iterator.level == level) {
printk(KERN_NOTICE vcpu %d\tpfn 0x%llx\tgfn 0x%llx\n,
kvm-tm_turn, vcpu-vcpu_id, pfn, gfn);
}
mmu_set_spte(vcpu, iterator.sptep, ACC_ALL,
write, emulate, level, gfn, pfn,
prefault, map_writable);
direct_pte_prefetch(vcpu, iterator.sptep);
++vcpu-stat.pf_fixed;
break;
}
--
Arthur Chunqi Li
Department of Computer Science
School of EECS
Peking University
Beijing, China
--
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: 3.10.X kernel/jump_label kvm
On 2014-03-03 19:17, Stefan Priebe wrote:
Am 03.03.2014 17:36, schrieb Paolo Bonzini:
Il 28/02/2014 20:47, Stefan Priebe ha scritto:
Hello,
i got this stack trace multiple times while using a vanilla 3.10.32
kernel and already sent it to the list in december but got no replies.
Please try the patch of commit 0dce7cd67fd9055c4a2ff278f8af1431e646d346:
Thanks - will try it. So this one should also go into 3.10.X
It's part of 3.10.29. Only .26..28 were affected by the regression below.
Jan
diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
index 1673940cf9c3..775702f649ca 100644
--- a/arch/x86/kvm/lapic.c
+++ b/arch/x86/kvm/lapic.c
@@ -1355,7 +1355,7 @@ void kvm_lapic_set_base(struct kvm_vcpu *vcpu, u64
value)
vcpu-arch.apic_base = value;
/* update jump label if enable bit changes */
- if ((vcpu-arch.apic_base ^ value) MSR_IA32_APICBASE_ENABLE) {
+ if ((old_value ^ value) MSR_IA32_APICBASE_ENABLE) {
if (value MSR_IA32_APICBASE_ENABLE)
static_key_slow_dec_deferred(apic_hw_disabled);
else
Paolo
--
Siemens AG, Corporate Technology, CT RTC ITP SES-DE
Corporate Competence Center Embedded Linux
--
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: 3.10.X kernel/jump_label kvm
Am 04.03.2014 11:01, schrieb Jan Kiszka:
On 2014-03-03 19:17, Stefan Priebe wrote:
Am 03.03.2014 17:36, schrieb Paolo Bonzini:
Il 28/02/2014 20:47, Stefan Priebe ha scritto:
Hello,
i got this stack trace multiple times while using a vanilla 3.10.32
kernel and already sent it to the list in december but got no replies.
Please try the patch of commit 0dce7cd67fd9055c4a2ff278f8af1431e646d346:
Thanks - will try it. So this one should also go into 3.10.X
It's part of 3.10.29. Only .26..28 were affected by the regression below.
Jan
HI Jan,
but i'm using 3.10.32. So it is another bug i'm seeing?
Stefan
diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
index 1673940cf9c3..775702f649ca 100644
--- a/arch/x86/kvm/lapic.c
+++ b/arch/x86/kvm/lapic.c
@@ -1355,7 +1355,7 @@ void kvm_lapic_set_base(struct kvm_vcpu *vcpu, u64
value)
vcpu-arch.apic_base = value;
/* update jump label if enable bit changes */
- if ((vcpu-arch.apic_base ^ value) MSR_IA32_APICBASE_ENABLE) {
+ if ((old_value ^ value) MSR_IA32_APICBASE_ENABLE) {
if (value MSR_IA32_APICBASE_ENABLE)
static_key_slow_dec_deferred(apic_hw_disabled);
else
Paolo
--
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: 3.10.X kernel/jump_label kvm
On 2014-03-04 11:26, Stefan Priebe - Profihost AG wrote: Am 04.03.2014 11:01, schrieb Jan Kiszka: On 2014-03-03 19:17, Stefan Priebe wrote: Am 03.03.2014 17:36, schrieb Paolo Bonzini: Il 28/02/2014 20:47, Stefan Priebe ha scritto: Hello, i got this stack trace multiple times while using a vanilla 3.10.32 kernel and already sent it to the list in december but got no replies. Please try the patch of commit 0dce7cd67fd9055c4a2ff278f8af1431e646d346: Thanks - will try it. So this one should also go into 3.10.X It's part of 3.10.29. Only .26..28 were affected by the regression below. Jan HI Jan, but i'm using 3.10.32. So it is another bug i'm seeing? Yes, that's the logical consequence. Jan -- Siemens AG, Corporate Technology, CT RTC ITP SES-DE Corporate Competence Center Embedded Linux -- 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
[PULL 0/8] KVM: s390,virtio-ccw: Features, cleanups and fixes
Paolo, The following changes since commit d3714010c307d26df251c45be9cd12ab6d41f0c4: KVM: x86: emulator_cmpxchg_emulated should mark_page_dirty (2014-02-26 10:11:08 +0100) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/kvms390/linux.git tags/kvm-s390-20140304 for you to fetch changes up to 96b14536d935848cffd904f583f67c66169002d8: virtio-ccw: virtio-ccw adapter interrupt support. (2014-03-04 10:41:04 +0100) The pull target is kvm/queue. this is the next round of patches for KVM: s390: - It contains the guest kernel part for adapter interrupt support for virtio-ccw, no irqfd yet - cleanups, getting rid of some interrupt data structure - ONEREG access to GBEA and PP - Fixes for virtio-ccw, sigp Christian Borntraeger (2): KVM: s390: Provide access to program parameter KVM: s390: expose gbea register to userspace Cornelia Huck (1): virtio-ccw: virtio-ccw adapter interrupt support. Heinz Graalfs (1): virtio_ccw: fix vcdev pointer handling issues Jens Freimann (2): KVM: s390: Simplify online vcpus counting for stsi KVM: s390: get rid of local_int array Martin Schwidefsky (1): s390/airq: add support for irq ranges Michael Mueller (3): KVM: s390: implementation of kvm_arch_vcpu_runnable() KVM: add kvm_arch_vcpu_runnable() test to kvm_vcpu_on_spin() loop KVM/s390: Set preempted flag during vcpu wakeup and interrupt delivery Takuya Yoshikawa (1): KVM: x86: Break kvm_for_each_vcpu loop after finding the VP_INDEX Thomas Huth (1): KVM: s390: Fixed CC of SIGP SET_PREFIX handler arch/s390/include/asm/airq.h | 14 +- arch/s390/include/asm/irq.h | 1 + arch/s390/include/asm/kvm_host.h | 5 +- arch/s390/include/uapi/asm/kvm.h | 2 + arch/s390/kernel/irq.c | 1 + arch/s390/kvm/interrupt.c| 9 +- arch/s390/kvm/kvm-s390.c | 26 +++- arch/s390/kvm/priv.c | 7 +- arch/s390/kvm/sigp.c | 148 -- arch/x86/kvm/x86.c | 7 +- drivers/s390/cio/airq.c | 66 + drivers/s390/kvm/virtio_ccw.c| 313 --- virt/kvm/kvm_main.c | 2 +- 13 files changed, 448 insertions(+), 153 deletions(-) -- 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
[PULL 2/8] KVM: s390: expose gbea register to userspace
For migration/reset we want to expose the guest breaking event
address register to userspace. Lets use ONE_REG for that purpose.
Signed-off-by: Christian Borntraeger borntrae...@de.ibm.com
Reviewed-by: Jason J. Herne jjhe...@linux.vnet.ibm.com
---
arch/s390/include/uapi/asm/kvm.h | 1 +
arch/s390/kvm/kvm-s390.c | 8
2 files changed, 9 insertions(+)
diff --git a/arch/s390/include/uapi/asm/kvm.h b/arch/s390/include/uapi/asm/kvm.h
index 7663244..2f0ade2 100644
--- a/arch/s390/include/uapi/asm/kvm.h
+++ b/arch/s390/include/uapi/asm/kvm.h
@@ -77,4 +77,5 @@ struct kvm_sync_regs {
#define KVM_REG_S390_PFCOMPARE (KVM_REG_S390 | KVM_REG_SIZE_U64 | 0x6)
#define KVM_REG_S390_PFSELECT (KVM_REG_S390 | KVM_REG_SIZE_U64 | 0x7)
#define KVM_REG_S390_PP(KVM_REG_S390 | KVM_REG_SIZE_U64 | 0x8)
+#define KVM_REG_S390_GBEA (KVM_REG_S390 | KVM_REG_SIZE_U64 | 0x9)
#endif
diff --git a/arch/s390/kvm/kvm-s390.c b/arch/s390/kvm/kvm-s390.c
index 0262936..a3e4c07 100644
--- a/arch/s390/kvm/kvm-s390.c
+++ b/arch/s390/kvm/kvm-s390.c
@@ -576,6 +576,10 @@ static int kvm_arch_vcpu_ioctl_get_one_reg(struct kvm_vcpu
*vcpu,
r = put_user(vcpu-arch.sie_block-pp,
(u64 __user *)reg-addr);
break;
+ case KVM_REG_S390_GBEA:
+ r = put_user(vcpu-arch.sie_block-gbea,
+(u64 __user *)reg-addr);
+ break;
default:
break;
}
@@ -621,6 +625,10 @@ static int kvm_arch_vcpu_ioctl_set_one_reg(struct kvm_vcpu
*vcpu,
r = get_user(vcpu-arch.sie_block-pp,
(u64 __user *)reg-addr);
break;
+ case KVM_REG_S390_GBEA:
+ r = get_user(vcpu-arch.sie_block-gbea,
+(u64 __user *)reg-addr);
+ break;
default:
break;
}
--
1.8.4.2
--
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
[PULL 5/8] KVM: s390: get rid of local_int array
From: Jens Freimann jf...@linux.vnet.ibm.com
We can use kvm_get_vcpu() now and don't need the
local_int array in the floating_int struct anymore.
This also means we don't have to hold the float_int.lock
in some places.
Signed-off-by: Jens Freimann jf...@linux.vnet.ibm.com
Signed-off-by: Christian Borntraeger borntrae...@de.ibm.com
---
arch/s390/include/asm/kvm_host.h | 1 -
arch/s390/kvm/interrupt.c| 6 +-
arch/s390/kvm/kvm-s390.c | 5 +-
arch/s390/kvm/sigp.c | 124 ---
4 files changed, 56 insertions(+), 80 deletions(-)
diff --git a/arch/s390/include/asm/kvm_host.h b/arch/s390/include/asm/kvm_host.h
index 062b78c..734d302 100644
--- a/arch/s390/include/asm/kvm_host.h
+++ b/arch/s390/include/asm/kvm_host.h
@@ -215,7 +215,6 @@ struct kvm_s390_float_interrupt {
int next_rr_cpu;
unsigned long idle_mask[(KVM_MAX_VCPUS + sizeof(long) - 1)
/ sizeof(long)];
- struct kvm_s390_local_interrupt *local_int[KVM_MAX_VCPUS];
unsigned int irq_count;
};
diff --git a/arch/s390/kvm/interrupt.c b/arch/s390/kvm/interrupt.c
index fff070b..1d0f9d5 100644
--- a/arch/s390/kvm/interrupt.c
+++ b/arch/s390/kvm/interrupt.c
@@ -692,6 +692,7 @@ static int __inject_vm(struct kvm *kvm, struct
kvm_s390_interrupt_info *inti)
struct kvm_s390_local_interrupt *li;
struct kvm_s390_float_interrupt *fi;
struct kvm_s390_interrupt_info *iter;
+ struct kvm_vcpu *dst_vcpu = NULL;
int sigcpu;
int rc = 0;
@@ -726,9 +727,10 @@ static int __inject_vm(struct kvm *kvm, struct
kvm_s390_interrupt_info *inti)
sigcpu = fi-next_rr_cpu++;
if (sigcpu == KVM_MAX_VCPUS)
sigcpu = fi-next_rr_cpu = 0;
- } while (fi-local_int[sigcpu] == NULL);
+ } while (kvm_get_vcpu(kvm, sigcpu) == NULL);
}
- li = fi-local_int[sigcpu];
+ dst_vcpu = kvm_get_vcpu(kvm, sigcpu);
+ li = dst_vcpu-arch.local_int;
spin_lock_bh(li-lock);
atomic_set_mask(CPUSTAT_EXT_INT, li-cpuflags);
if (waitqueue_active(li-wq))
diff --git a/arch/s390/kvm/kvm-s390.c b/arch/s390/kvm/kvm-s390.c
index a3e4c07..9136f8d 100644
--- a/arch/s390/kvm/kvm-s390.c
+++ b/arch/s390/kvm/kvm-s390.c
@@ -460,11 +460,8 @@ struct kvm_vcpu *kvm_arch_vcpu_create(struct kvm *kvm,
spin_lock_init(vcpu-arch.local_int.lock);
INIT_LIST_HEAD(vcpu-arch.local_int.list);
vcpu-arch.local_int.float_int = kvm-arch.float_int;
- spin_lock(kvm-arch.float_int.lock);
- kvm-arch.float_int.local_int[id] = vcpu-arch.local_int;
vcpu-arch.local_int.wq = vcpu-wq;
vcpu-arch.local_int.cpuflags = vcpu-arch.sie_block-cpuflags;
- spin_unlock(kvm-arch.float_int.lock);
rc = kvm_vcpu_init(vcpu, kvm, id);
if (rc)
@@ -952,7 +949,7 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu, struct
kvm_run *kvm_run)
atomic_clear_mask(CPUSTAT_STOPPED, vcpu-arch.sie_block-cpuflags);
- BUG_ON(vcpu-kvm-arch.float_int.local_int[vcpu-vcpu_id] == NULL);
+ BUG_ON(kvm_get_vcpu(vcpu-kvm, vcpu-vcpu_id) == NULL);
switch (kvm_run-exit_reason) {
case KVM_EXIT_S390_SIEIC:
diff --git a/arch/s390/kvm/sigp.c b/arch/s390/kvm/sigp.c
index 466eefa..3fe44c4 100644
--- a/arch/s390/kvm/sigp.c
+++ b/arch/s390/kvm/sigp.c
@@ -23,29 +23,30 @@
static int __sigp_sense(struct kvm_vcpu *vcpu, u16 cpu_addr,
u64 *reg)
{
- struct kvm_s390_float_interrupt *fi = vcpu-kvm-arch.float_int;
+ struct kvm_s390_local_interrupt *li;
+ struct kvm_vcpu *dst_vcpu = NULL;
+ int cpuflags;
int rc;
if (cpu_addr = KVM_MAX_VCPUS)
return SIGP_CC_NOT_OPERATIONAL;
- spin_lock(fi-lock);
- if (fi-local_int[cpu_addr] == NULL)
- rc = SIGP_CC_NOT_OPERATIONAL;
- else if (!(atomic_read(fi-local_int[cpu_addr]-cpuflags)
- (CPUSTAT_ECALL_PEND | CPUSTAT_STOPPED)))
+ dst_vcpu = kvm_get_vcpu(vcpu-kvm, cpu_addr);
+ if (!dst_vcpu)
+ return SIGP_CC_NOT_OPERATIONAL;
+ li = dst_vcpu-arch.local_int;
+
+ cpuflags = atomic_read(li-cpuflags);
+ if (!(cpuflags (CPUSTAT_ECALL_PEND | CPUSTAT_STOPPED)))
rc = SIGP_CC_ORDER_CODE_ACCEPTED;
else {
*reg = 0xUL;
- if (atomic_read(fi-local_int[cpu_addr]-cpuflags)
-CPUSTAT_ECALL_PEND)
+ if (cpuflags CPUSTAT_ECALL_PEND)
*reg |= SIGP_STATUS_EXT_CALL_PENDING;
- if (atomic_read(fi-local_int[cpu_addr]-cpuflags)
-CPUSTAT_STOPPED)
+ if (cpuflags CPUSTAT_STOPPED)
*reg |= SIGP_STATUS_STOPPED;
rc = SIGP_CC_STATUS_STORED;
}
- spin_unlock(fi-lock);
[PULL 8/8] virtio-ccw: virtio-ccw adapter interrupt support.
From: Cornelia Huck cornelia.h...@de.ibm.com
Implement the new CCW_CMD_SET_IND_ADAPTER command and try to enable
adapter interrupts for every device on the first startup. If the host
does not support adapter interrupts, fall back to normal I/O interrupts.
virtio-ccw adapter interrupts use the same isc as normal I/O subchannels
and share a summary indicator for all devices sharing the same indicator
area.
Indicator bits for the individual virtqueues may be contained in the same
indicator area for different devices.
Signed-off-by: Cornelia Huck cornelia.h...@de.ibm.com
Signed-off-by: Christian Borntraeger borntrae...@de.ibm.com
---
arch/s390/include/asm/irq.h | 1 +
arch/s390/kernel/irq.c| 1 +
drivers/s390/kvm/virtio_ccw.c | 278 --
3 files changed, 270 insertions(+), 10 deletions(-)
diff --git a/arch/s390/include/asm/irq.h b/arch/s390/include/asm/irq.h
index 5f8bcc5..35f0faa 100644
--- a/arch/s390/include/asm/irq.h
+++ b/arch/s390/include/asm/irq.h
@@ -53,6 +53,7 @@ enum interruption_class {
IRQIO_PCI,
IRQIO_MSI,
IRQIO_VIR,
+ IRQIO_VAI,
NMI_NMI,
CPU_RST,
NR_ARCH_IRQS
diff --git a/arch/s390/kernel/irq.c b/arch/s390/kernel/irq.c
index bb27a26..c288ef7 100644
--- a/arch/s390/kernel/irq.c
+++ b/arch/s390/kernel/irq.c
@@ -84,6 +84,7 @@ static const struct irq_class irqclass_sub_desc[NR_ARCH_IRQS]
= {
[IRQIO_PCI] = {.name = PCI, .desc = [I/O] PCI Interrupt },
[IRQIO_MSI] = {.name = MSI, .desc = [I/O] MSI Interrupt },
[IRQIO_VIR] = {.name = VIR, .desc = [I/O] Virtual I/O Devices},
+ [IRQIO_VAI] = {.name = VAI, .desc = [I/O] Virtual I/O Devices AI},
[NMI_NMI]= {.name = NMI, .desc = [NMI] Machine Check},
[CPU_RST]= {.name = RST, .desc = [CPU] CPU Restart},
};
diff --git a/drivers/s390/kvm/virtio_ccw.c b/drivers/s390/kvm/virtio_ccw.c
index 413c630..6a2b5fd 100644
--- a/drivers/s390/kvm/virtio_ccw.c
+++ b/drivers/s390/kvm/virtio_ccw.c
@@ -1,7 +1,7 @@
/*
* ccw based virtio transport
*
- * Copyright IBM Corp. 2012
+ * Copyright IBM Corp. 2012, 2014
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License (version 2 only)
@@ -32,6 +32,8 @@
#include asm/cio.h
#include asm/ccwdev.h
#include asm/virtio-ccw.h
+#include asm/isc.h
+#include asm/airq.h
/*
* virtio related functions
@@ -58,6 +60,8 @@ struct virtio_ccw_device {
unsigned long indicators;
unsigned long indicators2;
struct vq_config_block *config_block;
+ bool is_thinint;
+ void *airq_info;
};
struct vq_info_block {
@@ -72,15 +76,38 @@ struct virtio_feature_desc {
__u8 index;
} __packed;
+struct virtio_thinint_area {
+ unsigned long summary_indicator;
+ unsigned long indicator;
+ u64 bit_nr;
+ u8 isc;
+} __packed;
+
struct virtio_ccw_vq_info {
struct virtqueue *vq;
int num;
void *queue;
struct vq_info_block *info_block;
+ int bit_nr;
struct list_head node;
long cookie;
};
+#define VIRTIO_AIRQ_ISC IO_SCH_ISC /* inherit from subchannel */
+
+#define VIRTIO_IV_BITS (L1_CACHE_BYTES * 8)
+#define MAX_AIRQ_AREAS 20
+
+static int virtio_ccw_use_airq = 1;
+
+struct airq_info {
+ rwlock_t lock;
+ u8 summary_indicator;
+ struct airq_struct airq;
+ struct airq_iv *aiv;
+};
+static struct airq_info *airq_areas[MAX_AIRQ_AREAS];
+
#define CCW_CMD_SET_VQ 0x13
#define CCW_CMD_VDEV_RESET 0x33
#define CCW_CMD_SET_IND 0x43
@@ -91,6 +118,7 @@ struct virtio_ccw_vq_info {
#define CCW_CMD_WRITE_CONF 0x21
#define CCW_CMD_WRITE_STATUS 0x31
#define CCW_CMD_READ_VQ_CONF 0x32
+#define CCW_CMD_SET_IND_ADAPTER 0x73
#define VIRTIO_CCW_DOING_SET_VQ 0x0001
#define VIRTIO_CCW_DOING_RESET 0x0004
@@ -102,6 +130,7 @@ struct virtio_ccw_vq_info {
#define VIRTIO_CCW_DOING_SET_IND 0x0100
#define VIRTIO_CCW_DOING_READ_VQ_CONF 0x0200
#define VIRTIO_CCW_DOING_SET_CONF_IND 0x0400
+#define VIRTIO_CCW_DOING_SET_IND_ADAPTER 0x0800
#define VIRTIO_CCW_INTPARM_MASK 0x
static struct virtio_ccw_device *to_vc_device(struct virtio_device *vdev)
@@ -109,6 +138,125 @@ static struct virtio_ccw_device *to_vc_device(struct
virtio_device *vdev)
return container_of(vdev, struct virtio_ccw_device, vdev);
}
+static void drop_airq_indicator(struct virtqueue *vq, struct airq_info *info)
+{
+ unsigned long i, flags;
+
+ write_lock_irqsave(info-lock, flags);
+ for (i = 0; i airq_iv_end(info-aiv); i++) {
+ if (vq == (void *)airq_iv_get_ptr(info-aiv, i)) {
+ airq_iv_free_bit(info-aiv, i);
+ airq_iv_set_ptr(info-aiv, i, 0);
+ break;
+ }
+ }
+ write_unlock_irqrestore(info-lock, flags);
+}
+
+static void virtio_airq_handler(struct
[PULL 7/8] s390/airq: add support for irq ranges
From: Martin Schwidefsky schwidef...@de.ibm.com
Add airq_iv_alloc and airq_iv_free to allocate and free consecutive
ranges of irqs from the interrupt vector.
Signed-off-by: Martin Schwidefsky schwidef...@de.ibm.com
Signed-off-by: Christian Borntraeger borntrae...@de.ibm.com
---
arch/s390/include/asm/airq.h | 14 --
drivers/s390/cio/airq.c | 66 +++-
2 files changed, 53 insertions(+), 27 deletions(-)
diff --git a/arch/s390/include/asm/airq.h b/arch/s390/include/asm/airq.h
index 4bbb595..bd93ff6 100644
--- a/arch/s390/include/asm/airq.h
+++ b/arch/s390/include/asm/airq.h
@@ -44,11 +44,21 @@ struct airq_iv {
struct airq_iv *airq_iv_create(unsigned long bits, unsigned long flags);
void airq_iv_release(struct airq_iv *iv);
-unsigned long airq_iv_alloc_bit(struct airq_iv *iv);
-void airq_iv_free_bit(struct airq_iv *iv, unsigned long bit);
+unsigned long airq_iv_alloc(struct airq_iv *iv, unsigned long num);
+void airq_iv_free(struct airq_iv *iv, unsigned long bit, unsigned long num);
unsigned long airq_iv_scan(struct airq_iv *iv, unsigned long start,
unsigned long end);
+static inline unsigned long airq_iv_alloc_bit(struct airq_iv *iv)
+{
+ return airq_iv_alloc(iv, 1);
+}
+
+static inline void airq_iv_free_bit(struct airq_iv *iv, unsigned long bit)
+{
+ airq_iv_free(iv, bit, 1);
+}
+
static inline unsigned long airq_iv_end(struct airq_iv *iv)
{
return iv-end;
diff --git a/drivers/s390/cio/airq.c b/drivers/s390/cio/airq.c
index f055df0..445564c 100644
--- a/drivers/s390/cio/airq.c
+++ b/drivers/s390/cio/airq.c
@@ -186,55 +186,71 @@ void airq_iv_release(struct airq_iv *iv)
EXPORT_SYMBOL(airq_iv_release);
/**
- * airq_iv_alloc_bit - allocate an irq bit from an interrupt vector
+ * airq_iv_alloc - allocate irq bits from an interrupt vector
* @iv: pointer to an interrupt vector structure
+ * @num: number of consecutive irq bits to allocate
*
- * Returns the bit number of the allocated irq, or -1UL if no bit
- * is available or the AIRQ_IV_ALLOC flag has not been specified
+ * Returns the bit number of the first irq in the allocated block of irqs,
+ * or -1UL if no bit is available or the AIRQ_IV_ALLOC flag has not been
+ * specified
*/
-unsigned long airq_iv_alloc_bit(struct airq_iv *iv)
+unsigned long airq_iv_alloc(struct airq_iv *iv, unsigned long num)
{
- unsigned long bit;
+ unsigned long bit, i;
- if (!iv-avail)
+ if (!iv-avail || num == 0)
return -1UL;
spin_lock(iv-lock);
bit = find_first_bit_inv(iv-avail, iv-bits);
- if (bit iv-bits) {
- clear_bit_inv(bit, iv-avail);
- if (bit = iv-end)
- iv-end = bit + 1;
- } else
+ while (bit + num = iv-bits) {
+ for (i = 1; i num; i++)
+ if (!test_bit_inv(bit + i, iv-avail))
+ break;
+ if (i = num) {
+ /* Found a suitable block of irqs */
+ for (i = 0; i num; i++)
+ clear_bit_inv(bit + i, iv-avail);
+ if (bit + num = iv-end)
+ iv-end = bit + num + 1;
+ break;
+ }
+ bit = find_next_bit_inv(iv-avail, iv-bits, bit + i + 1);
+ }
+ if (bit + num iv-bits)
bit = -1UL;
spin_unlock(iv-lock);
return bit;
}
-EXPORT_SYMBOL(airq_iv_alloc_bit);
+EXPORT_SYMBOL(airq_iv_alloc);
/**
- * airq_iv_free_bit - free an irq bit of an interrupt vector
+ * airq_iv_free - free irq bits of an interrupt vector
* @iv: pointer to interrupt vector structure
- * @bit: number of the irq bit to free
+ * @bit: number of the first irq bit to free
+ * @num: number of consecutive irq bits to free
*/
-void airq_iv_free_bit(struct airq_iv *iv, unsigned long bit)
+void airq_iv_free(struct airq_iv *iv, unsigned long bit, unsigned long num)
{
- if (!iv-avail)
+ unsigned long i;
+
+ if (!iv-avail || num == 0)
return;
spin_lock(iv-lock);
- /* Clear (possibly left over) interrupt bit */
- clear_bit_inv(bit, iv-vector);
- /* Make the bit position available again */
- set_bit_inv(bit, iv-avail);
- if (bit == iv-end - 1) {
+ for (i = 0; i num; i++) {
+ /* Clear (possibly left over) interrupt bit */
+ clear_bit_inv(bit + i, iv-vector);
+ /* Make the bit positions available again */
+ set_bit_inv(bit + i, iv-avail);
+ }
+ if (bit + num = iv-end) {
/* Find new end of bit-field */
- while (--iv-end 0)
- if (!test_bit_inv(iv-end - 1, iv-avail))
- break;
+ while (iv-end 0 !test_bit_inv(iv-end - 1, iv-avail))
+
[PULL 1/8] KVM: s390: Provide access to program parameter
commit d208c79d63e06457eef077af770d23dc4cde4d43 (KVM: s390: Enable
the LPP facility for guests) enabled the LPP instruction for guests.
We should expose the program parameter as a pseudo register for
migration/reset etc. Lets also reset this value on initial CPU
reset.
Signed-off-by: Christian Borntraeger borntrae...@de.ibm.com
Reviewed-by: Thomas Huth th...@linux.vnet.ibm.com
Reviewed-by: Jason J. Herne jjhe...@linux.vnet.ibm.com
---
arch/s390/include/asm/kvm_host.h | 4 +++-
arch/s390/include/uapi/asm/kvm.h | 1 +
arch/s390/kvm/kvm-s390.c | 9 +
3 files changed, 13 insertions(+), 1 deletion(-)
diff --git a/arch/s390/include/asm/kvm_host.h b/arch/s390/include/asm/kvm_host.h
index 2c69ba2..062b78c 100644
--- a/arch/s390/include/asm/kvm_host.h
+++ b/arch/s390/include/asm/kvm_host.h
@@ -107,7 +107,9 @@ struct kvm_s390_sie_block {
__u64 gbea; /* 0x0180 */
__u8reserved188[24];/* 0x0188 */
__u32 fac;/* 0x01a0 */
- __u8reserved1a4[68];/* 0x01a4 */
+ __u8reserved1a4[58];/* 0x01a4 */
+ __u64 pp; /* 0x01de */
+ __u8reserved1e6[2]; /* 0x01e6 */
__u64 itdba; /* 0x01e8 */
__u8reserved1f0[16];/* 0x01f0 */
} __attribute__((packed));
diff --git a/arch/s390/include/uapi/asm/kvm.h b/arch/s390/include/uapi/asm/kvm.h
index cb4c1eb8..7663244 100644
--- a/arch/s390/include/uapi/asm/kvm.h
+++ b/arch/s390/include/uapi/asm/kvm.h
@@ -76,4 +76,5 @@ struct kvm_sync_regs {
#define KVM_REG_S390_PFTOKEN (KVM_REG_S390 | KVM_REG_SIZE_U64 | 0x5)
#define KVM_REG_S390_PFCOMPARE (KVM_REG_S390 | KVM_REG_SIZE_U64 | 0x6)
#define KVM_REG_S390_PFSELECT (KVM_REG_S390 | KVM_REG_SIZE_U64 | 0x7)
+#define KVM_REG_S390_PP(KVM_REG_S390 | KVM_REG_SIZE_U64 | 0x8)
#endif
diff --git a/arch/s390/kvm/kvm-s390.c b/arch/s390/kvm/kvm-s390.c
index 18959bb..0262936 100644
--- a/arch/s390/kvm/kvm-s390.c
+++ b/arch/s390/kvm/kvm-s390.c
@@ -386,6 +386,7 @@ static void kvm_s390_vcpu_initial_reset(struct kvm_vcpu
*vcpu)
vcpu-arch.guest_fpregs.fpc = 0;
asm volatile(lfpc %0 : : Q (vcpu-arch.guest_fpregs.fpc));
vcpu-arch.sie_block-gbea = 1;
+ vcpu-arch.sie_block-pp = 0;
vcpu-arch.pfault_token = KVM_S390_PFAULT_TOKEN_INVALID;
kvm_clear_async_pf_completion_queue(vcpu);
atomic_set_mask(CPUSTAT_STOPPED, vcpu-arch.sie_block-cpuflags);
@@ -571,6 +572,10 @@ static int kvm_arch_vcpu_ioctl_get_one_reg(struct kvm_vcpu
*vcpu,
r = put_user(vcpu-arch.pfault_select,
(u64 __user *)reg-addr);
break;
+ case KVM_REG_S390_PP:
+ r = put_user(vcpu-arch.sie_block-pp,
+(u64 __user *)reg-addr);
+ break;
default:
break;
}
@@ -612,6 +617,10 @@ static int kvm_arch_vcpu_ioctl_set_one_reg(struct kvm_vcpu
*vcpu,
r = get_user(vcpu-arch.pfault_select,
(u64 __user *)reg-addr);
break;
+ case KVM_REG_S390_PP:
+ r = get_user(vcpu-arch.sie_block-pp,
+(u64 __user *)reg-addr);
+ break;
default:
break;
}
--
1.8.4.2
--
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
[PULL 3/8] KVM: s390: Simplify online vcpus counting for stsi
From: Jens Freimann jf...@linux.vnet.ibm.com
We don't need to loop over all cpus to get the number of
vcpus. Let's use the available counter online_vcpus instead.
Signed-off-by: Jens Freimann jf...@linux.vnet.ibm.com
Signed-off-by: Christian Borntraeger borntrae...@de.ibm.com
---
arch/s390/kvm/priv.c | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/arch/s390/kvm/priv.c b/arch/s390/kvm/priv.c
index 75beea6..ae9e8ee 100644
--- a/arch/s390/kvm/priv.c
+++ b/arch/s390/kvm/priv.c
@@ -396,15 +396,10 @@ static int handle_stidp(struct kvm_vcpu *vcpu)
static void handle_stsi_3_2_2(struct kvm_vcpu *vcpu, struct sysinfo_3_2_2 *mem)
{
- struct kvm_s390_float_interrupt *fi = vcpu-kvm-arch.float_int;
int cpus = 0;
int n;
- spin_lock(fi-lock);
- for (n = 0; n KVM_MAX_VCPUS; n++)
- if (fi-local_int[n])
- cpus++;
- spin_unlock(fi-lock);
+ cpus = atomic_read(vcpu-kvm-online_vcpus);
/* deal with other level 3 hypervisors */
if (stsi(mem, 3, 2, 2))
--
1.8.4.2
--
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
[PULL 4/8] KVM: s390: Fixed CC of SIGP SET_PREFIX handler
From: Thomas Huth th...@linux.vnet.ibm.com
When SIGP SET_PREFIX is called with an illegal CPU id, it must return
the condition code 3 (not operational) instead of 1. Also fixed the
order in which the checks are done - CC3 has a higher priority than CC1.
And while we're at it, this patch also get rid of the floating interrupt
lock here by using kvm_get_vcpu() to get the local_int struct of the
destination CPU.
Signed-off-by: Thomas Huth th...@linux.vnet.ibm.com
Reviewed-by: Cornelia Huck cornelia.h...@de.ibm.com
Signed-off-by: Christian Borntraeger borntrae...@de.ibm.com
---
arch/s390/kvm/sigp.c | 24
1 file changed, 8 insertions(+), 16 deletions(-)
diff --git a/arch/s390/kvm/sigp.c b/arch/s390/kvm/sigp.c
index fe9442d..466eefa 100644
--- a/arch/s390/kvm/sigp.c
+++ b/arch/s390/kvm/sigp.c
@@ -249,12 +249,18 @@ static int __sigp_set_arch(struct kvm_vcpu *vcpu, u32
parameter)
static int __sigp_set_prefix(struct kvm_vcpu *vcpu, u16 cpu_addr, u32 address,
u64 *reg)
{
- struct kvm_s390_float_interrupt *fi = vcpu-kvm-arch.float_int;
- struct kvm_s390_local_interrupt *li = NULL;
+ struct kvm_s390_local_interrupt *li;
+ struct kvm_vcpu *dst_vcpu = NULL;
struct kvm_s390_interrupt_info *inti;
int rc;
u8 tmp;
+ if (cpu_addr KVM_MAX_VCPUS)
+ dst_vcpu = kvm_get_vcpu(vcpu-kvm, cpu_addr);
+ if (!dst_vcpu)
+ return SIGP_CC_NOT_OPERATIONAL;
+ li = dst_vcpu-arch.local_int;
+
/* make sure that the new value is valid memory */
address = address 0x7fffe000u;
if (copy_from_guest_absolute(vcpu, tmp, address, 1) ||
@@ -268,18 +274,6 @@ static int __sigp_set_prefix(struct kvm_vcpu *vcpu, u16
cpu_addr, u32 address,
if (!inti)
return SIGP_CC_BUSY;
- spin_lock(fi-lock);
- if (cpu_addr KVM_MAX_VCPUS)
- li = fi-local_int[cpu_addr];
-
- if (li == NULL) {
- *reg = 0xUL;
- *reg |= SIGP_STATUS_INCORRECT_STATE;
- rc = SIGP_CC_STATUS_STORED;
- kfree(inti);
- goto out_fi;
- }
-
spin_lock_bh(li-lock);
/* cpu must be in stopped state */
if (!(atomic_read(li-cpuflags) CPUSTAT_STOPPED)) {
@@ -302,8 +296,6 @@ static int __sigp_set_prefix(struct kvm_vcpu *vcpu, u16
cpu_addr, u32 address,
VCPU_EVENT(vcpu, 4, set prefix of cpu %02x to %x, cpu_addr, address);
out_li:
spin_unlock_bh(li-lock);
-out_fi:
- spin_unlock(fi-lock);
return rc;
}
--
1.8.4.2
--
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
[PULL 6/8] virtio_ccw: fix vcdev pointer handling issues
From: Heinz Graalfs graa...@linux.vnet.ibm.com
The interrupt handler virtio_ccw_int_handler() using the vcdev pointer
is protected by the ccw_device lock. Resetting the pointer within the
ccw_device structure should be done when holding this lock.
Also resetting the vcdev pointer (under the ccw_device lock) prior to
freeing the vcdev pointer memory removes a critical path.
Signed-off-by: Heinz Graalfs graa...@linux.vnet.ibm.com
Acked-by: Cornelia Huck cornelia.h...@de.ibm.com
Signed-off-by: Christian Borntraeger borntrae...@de.ibm.com
---
drivers/s390/kvm/virtio_ccw.c | 35 ---
1 file changed, 28 insertions(+), 7 deletions(-)
diff --git a/drivers/s390/kvm/virtio_ccw.c b/drivers/s390/kvm/virtio_ccw.c
index 0fc5848..413c630 100644
--- a/drivers/s390/kvm/virtio_ccw.c
+++ b/drivers/s390/kvm/virtio_ccw.c
@@ -636,6 +636,8 @@ static void virtio_ccw_int_handler(struct ccw_device *cdev,
struct virtqueue *vq;
struct virtio_driver *drv;
+ if (!vcdev)
+ return;
/* Check if it's a notification from the host. */
if ((intparm == 0)
(scsw_stctl(irb-scsw) ==
@@ -734,23 +736,37 @@ static int virtio_ccw_probe(struct ccw_device *cdev)
return 0;
}
+static struct virtio_ccw_device *virtio_grab_drvdata(struct ccw_device *cdev)
+{
+ unsigned long flags;
+ struct virtio_ccw_device *vcdev;
+
+ spin_lock_irqsave(get_ccwdev_lock(cdev), flags);
+ vcdev = dev_get_drvdata(cdev-dev);
+ if (!vcdev) {
+ spin_unlock_irqrestore(get_ccwdev_lock(cdev), flags);
+ return NULL;
+ }
+ dev_set_drvdata(cdev-dev, NULL);
+ spin_unlock_irqrestore(get_ccwdev_lock(cdev), flags);
+ return vcdev;
+}
+
static void virtio_ccw_remove(struct ccw_device *cdev)
{
- struct virtio_ccw_device *vcdev = dev_get_drvdata(cdev-dev);
+ struct virtio_ccw_device *vcdev = virtio_grab_drvdata(cdev);
- if (cdev-online) {
+ if (vcdev cdev-online)
unregister_virtio_device(vcdev-vdev);
- dev_set_drvdata(cdev-dev, NULL);
- }
cdev-handler = NULL;
}
static int virtio_ccw_offline(struct ccw_device *cdev)
{
- struct virtio_ccw_device *vcdev = dev_get_drvdata(cdev-dev);
+ struct virtio_ccw_device *vcdev = virtio_grab_drvdata(cdev);
- unregister_virtio_device(vcdev-vdev);
- dev_set_drvdata(cdev-dev, NULL);
+ if (vcdev)
+ unregister_virtio_device(vcdev-vdev);
return 0;
}
@@ -759,6 +775,7 @@ static int virtio_ccw_online(struct ccw_device *cdev)
{
int ret;
struct virtio_ccw_device *vcdev;
+ unsigned long flags;
vcdev = kzalloc(sizeof(*vcdev), GFP_KERNEL);
if (!vcdev) {
@@ -786,7 +803,9 @@ static int virtio_ccw_online(struct ccw_device *cdev)
INIT_LIST_HEAD(vcdev-virtqueues);
spin_lock_init(vcdev-lock);
+ spin_lock_irqsave(get_ccwdev_lock(cdev), flags);
dev_set_drvdata(cdev-dev, vcdev);
+ spin_unlock_irqrestore(get_ccwdev_lock(cdev), flags);
vcdev-vdev.id.vendor = cdev-id.cu_type;
vcdev-vdev.id.device = cdev-id.cu_model;
ret = register_virtio_device(vcdev-vdev);
@@ -797,7 +816,9 @@ static int virtio_ccw_online(struct ccw_device *cdev)
}
return 0;
out_put:
+ spin_lock_irqsave(get_ccwdev_lock(cdev), flags);
dev_set_drvdata(cdev-dev, NULL);
+ spin_unlock_irqrestore(get_ccwdev_lock(cdev), flags);
put_device(vcdev-vdev.dev);
return ret;
out_free:
--
1.8.4.2
--
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: [Qemu-devel] [RFC]VM live snapshot proposal
于 2014/3/4 17:05, Paolo Bonzini 写道: Il 04/03/2014 09:54, Stefan Hajnoczi ha scritto: Is there any other proposals to implement vm-snapshot? See the discussion by Paolo and Andrea about post-copy migration, which adds kernel memory management features for tracking userspace page faults. Perhaps you can use that infrastructure to trap guest writes. That infrastructure actually traps guest reads too. But it's fine, as they are a superset of guest writes and the image will still be consistent. Paolo I heard that Kernel going to have API to let userspace catch memory operation, which originally can be only caught by kernel code. I am not sure how it is now, but if kernel have it, qemu can use it more gracefully than modifing migration code. -- 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: [PULL 0/8] KVM: s390,virtio-ccw: Features, cleanups and fixes
Il 04/03/2014 12:27, Christian Borntraeger ha scritto: Paolo, The following changes since commit d3714010c307d26df251c45be9cd12ab6d41f0c4: KVM: x86: emulator_cmpxchg_emulated should mark_page_dirty (2014-02-26 10:11:08 +0100) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/kvms390/linux.git tags/kvm-s390-20140304 for you to fetch changes up to 96b14536d935848cffd904f583f67c66169002d8: virtio-ccw: virtio-ccw adapter interrupt support. (2014-03-04 10:41:04 +0100) The pull target is kvm/queue. this is the next round of patches for KVM: s390: - It contains the guest kernel part for adapter interrupt support for virtio-ccw, no irqfd yet - cleanups, getting rid of some interrupt data structure - ONEREG access to GBEA and PP - Fixes for virtio-ccw, sigp Christian Borntraeger (2): KVM: s390: Provide access to program parameter KVM: s390: expose gbea register to userspace Cornelia Huck (1): virtio-ccw: virtio-ccw adapter interrupt support. Heinz Graalfs (1): virtio_ccw: fix vcdev pointer handling issues Jens Freimann (2): KVM: s390: Simplify online vcpus counting for stsi KVM: s390: get rid of local_int array Martin Schwidefsky (1): s390/airq: add support for irq ranges Michael Mueller (3): KVM: s390: implementation of kvm_arch_vcpu_runnable() KVM: add kvm_arch_vcpu_runnable() test to kvm_vcpu_on_spin() loop KVM/s390: Set preempted flag during vcpu wakeup and interrupt delivery Takuya Yoshikawa (1): KVM: x86: Break kvm_for_each_vcpu loop after finding the VP_INDEX Thomas Huth (1): KVM: s390: Fixed CC of SIGP SET_PREFIX handler arch/s390/include/asm/airq.h | 14 +- arch/s390/include/asm/irq.h | 1 + arch/s390/include/asm/kvm_host.h | 5 +- arch/s390/include/uapi/asm/kvm.h | 2 + arch/s390/kernel/irq.c | 1 + arch/s390/kvm/interrupt.c| 9 +- arch/s390/kvm/kvm-s390.c | 26 +++- arch/s390/kvm/priv.c | 7 +- arch/s390/kvm/sigp.c | 148 -- arch/x86/kvm/x86.c | 7 +- drivers/s390/cio/airq.c | 66 + drivers/s390/kvm/virtio_ccw.c| 313 --- virt/kvm/kvm_main.c | 2 +- 13 files changed, 448 insertions(+), 153 deletions(-) Pulled to kvm/queue, thanks. Paolo -- 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: [PATCH 0/2 v2] x86: kvm: global clock updates
Il 28/02/2014 15:52, Marcelo Tosatti ha scritto: On Fri, Feb 28, 2014 at 12:52:53PM +0100, Andrew Jones wrote: This patch series addresses two issues with global clock updates. The first fixes a bug found on hosts that have a tsc marked as unstable. As global clock updates get triggered on every vcpu load in these cases, guests with a large number of vcpus have their progress nearly halted. The fix for that bug should also go to stable. The second patch in this series ensures that NTP corrections on the host, as well as on guests with all vcpus pinned, will be propagated periodically. That patch improves things, but doesn't fix a bug, thus it can be merged at a later time than the first. I've posted them together as a series, as the second one builds on the first. Andrew Jones (2): x86: kvm: rate-limit global clock updates x86: kvm: introduce periodic global clock updates arch/x86/include/asm/kvm_host.h | 2 + arch/x86/kvm/x86.c | 92 +++-- 2 files changed, 90 insertions(+), 4 deletions(-) -- 1.8.1.4 Looks good. Applied to kvm/queue, thanks to both. Paolo -- 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: KVM call agenda for 2014-03-04
Juan Quintela quint...@redhat.com wrote: Hi Please, send any topic that you are interested in covering. Agenda: As there were no topics, we cancel it. PD. Sorry for the last notice, I was on vacation and forgot :p Thanks, Juan. Call details: 09:00 AM to 10:00 AM EDT Every two weeks If you need phone number details, contact me privately -- 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
[PATCH] [fix] kernel does not compile without CONFIG_KVM_ARM_VGIC
When the kernel is configured without CONFIG_KVM_ARM_VGIC, the compilation process fails with : arch/arm/kvm/arm.c: In function 'kvm_vm_ioctl_set_device_addr': arch/arm/kvm/arm.c:797:3: error: implicit declaration of function 'kvm_vgic_addr' [-Werror=implicit-function-declaration] return kvm_vgic_addr(kvm, type, dev_addr-addr, true) Signed-off-by: Michele Paolino m.paol...@virtualopensystems.com --- include/kvm/arm_vgic.h |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/kvm/arm_vgic.h b/include/kvm/arm_vgic.h index be85127..0bab057 100644 --- a/include/kvm/arm_vgic.h +++ b/include/kvm/arm_vgic.h @@ -143,8 +143,8 @@ struct kvm_vcpu; struct kvm_run; struct kvm_exit_mmio; -#ifdef CONFIG_KVM_ARM_VGIC int kvm_vgic_addr(struct kvm *kvm, unsigned long type, u64 *addr, bool write); +#ifdef CONFIG_KVM_ARM_VGIC int kvm_vgic_hyp_init(void); int kvm_vgic_init(struct kvm *kvm); int kvm_vgic_create(struct kvm *kvm); -- 1.7.9.5 -- 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: [PATCH] [fix] kernel does not compile without CONFIG_KVM_ARM_VGIC
Il 04/03/2014 16:10, Michele Paolino ha scritto: When the kernel is configured without CONFIG_KVM_ARM_VGIC, the compilation process fails with : arch/arm/kvm/arm.c: In function 'kvm_vm_ioctl_set_device_addr': arch/arm/kvm/arm.c:797:3: error: implicit declaration of function 'kvm_vgic_addr' [-Werror=implicit-function-declaration] return kvm_vgic_addr(kvm, type, dev_addr-addr, true) Signed-off-by: Michele Paolino m.paol...@virtualopensystems.com --- include/kvm/arm_vgic.h |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/kvm/arm_vgic.h b/include/kvm/arm_vgic.h index be85127..0bab057 100644 --- a/include/kvm/arm_vgic.h +++ b/include/kvm/arm_vgic.h @@ -143,8 +143,8 @@ struct kvm_vcpu; struct kvm_run; struct kvm_exit_mmio; -#ifdef CONFIG_KVM_ARM_VGIC int kvm_vgic_addr(struct kvm *kvm, unsigned long type, u64 *addr, bool write); +#ifdef CONFIG_KVM_ARM_VGIC int kvm_vgic_hyp_init(void); int kvm_vgic_init(struct kvm *kvm); int kvm_vgic_create(struct kvm *kvm); Christoffer, Marc, I can queue this directly for kvm/master if it's okay for you. Paolo -- 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: [fedora-virt] 3.13 - Nested KVM (vmx) totally broken?
On 03/04/2014 03:30 AM, Kashyap Chamarthy wrote: If you want to try, I made a Fedora Kernel scratch build (i.e. not official) with fix Paolo pointed to below and this works for me: http://koji.fedoraproject.org/koji/taskinfo?taskID=6577700 Works here. Thanks! -- Ian Pilcher arequip...@gmail.com Sent from the cloud -- where it's already tomorrow -- 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
host_fx_image, guest_fx_image ; what are they ?
Hi List, Could you please help me understand below variables ? i found it in struct kvm_vcpu char *host_fx_image; char *guest_fx_image; -Ratheesh -- 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
[PATCH v9 02/20] Add kvm_eventfds_enabled function
Add a function to check if the eventfd capability is present in KVM in
the host kernel.
Signed-off-by: Antonios Motakis a.mota...@virtualopensystems.com
Signed-off-by: Nikolay Nikolaev n.nikol...@virtualopensystems.com
---
include/sysemu/kvm.h | 11 +++
kvm-all.c| 4
kvm-stub.c | 1 +
3 files changed, 16 insertions(+)
diff --git a/include/sysemu/kvm.h b/include/sysemu/kvm.h
index a02d67c..3db063e 100644
--- a/include/sysemu/kvm.h
+++ b/include/sysemu/kvm.h
@@ -43,6 +43,7 @@ extern bool kvm_allowed;
extern bool kvm_kernel_irqchip;
extern bool kvm_async_interrupts_allowed;
extern bool kvm_halt_in_kernel_allowed;
+extern bool kvm_eventfds_allowed;
extern bool kvm_irqfds_allowed;
extern bool kvm_msi_via_irqfd_allowed;
extern bool kvm_gsi_routing_allowed;
@@ -83,6 +84,15 @@ extern bool kvm_readonly_mem_allowed;
#define kvm_halt_in_kernel() (kvm_halt_in_kernel_allowed)
/**
+ * kvm_eventfds_enabled:
+ *
+ * Returns: true if we can use eventfds to receive notifications
+ * from a KVM CPU (ie the kernel supports eventds and we are running
+ * with a configuration where it is meaningful to use them).
+ */
+#define kvm_eventfds_enabled() (kvm_eventfds_allowed)
+
+/**
* kvm_irqfds_enabled:
*
* Returns: true if we can use irqfds to inject interrupts into
@@ -128,6 +138,7 @@ extern bool kvm_readonly_mem_allowed;
#define kvm_irqchip_in_kernel() (false)
#define kvm_async_interrupts_enabled() (false)
#define kvm_halt_in_kernel() (false)
+#define kvm_eventfds_enabled() (false)
#define kvm_irqfds_enabled() (false)
#define kvm_msi_via_irqfd_enabled() (false)
#define kvm_gsi_routing_allowed() (false)
diff --git a/kvm-all.c b/kvm-all.c
index fd8157a..85f31b4 100644
--- a/kvm-all.c
+++ b/kvm-all.c
@@ -110,6 +110,7 @@ KVMState *kvm_state;
bool kvm_kernel_irqchip;
bool kvm_async_interrupts_allowed;
bool kvm_halt_in_kernel_allowed;
+bool kvm_eventfds_allowed;
bool kvm_irqfds_allowed;
bool kvm_msi_via_irqfd_allowed;
bool kvm_gsi_routing_allowed;
@@ -1505,6 +1506,9 @@ int kvm_init(void)
(kvm_check_extension(s, KVM_CAP_READONLY_MEM) 0);
#endif
+kvm_eventfds_allowed =
+(kvm_check_extension(s, KVM_CAP_IOEVENTFD) 0);
+
ret = kvm_arch_init(s);
if (ret 0) {
goto err;
diff --git a/kvm-stub.c b/kvm-stub.c
index e979f76..a25cda2 100644
--- a/kvm-stub.c
+++ b/kvm-stub.c
@@ -22,6 +22,7 @@
KVMState *kvm_state;
bool kvm_kernel_irqchip;
bool kvm_async_interrupts_allowed;
+bool kvm_eventfds_allowed;
bool kvm_irqfds_allowed;
bool kvm_msi_via_irqfd_allowed;
bool kvm_gsi_routing_allowed;
--
1.8.3.2
--
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: [PATCH 3/3] drivers/vfio/pci: Fix MSIx message lost
On Tue, 2014-03-04 at 10:30 +0800, Gavin Shan wrote: On Mon, Mar 03, 2014 at 12:36:16PM -0700, Alex Williamson wrote: On Mon, 2014-03-03 at 14:10 +0800, Gavin Shan wrote: On Sun, Mar 02, 2014 at 09:49:49PM -0700, Alex Williamson wrote: On Mon, 2014-03-03 at 14:51 +1100, Benjamin Herrenschmidt wrote: On Mon, 2014-03-03 at 11:24 +0800, Gavin Shan wrote: ../... Various PCI devices could have different ways to do BIST. It's a bit hard to capture all of them, I think. Alex, please advise which way to fix the issue would be better. Or we can have this patch and figure out the way using vfio_bar_restore() later? :-) This approach arguably has a very niche application. I'd rather see this device fall into the vfio_bar_restore() and add a callout to the vfio irq code to restore the MSIX table and MSI/MSIX capabilities if the surprise reset occurred with either enabled. That seems like it would be generally useful to any device with a backdoor reset. Besides, if the BARs on the device are being deprogrammed by BIST, then it must already be hitting the vfio_bar_restore code or just re-writing the vector table entry wouldn't be enough to get it running again. Thanks, I had some debugging output in vfio_bar_restore() for my case, which is pci_save_state(), BIST and then pci_restore_state() on guest side. I never saw those debugging output from vfio_bar_restore(). Host VFIO-PCI has cached PCI config space, which was built in advance, and BIST on guest side didn't get altered PCI_COMMAND (memory/IO enable). So we didn't call into the function where we expect to restore MSIx stuff, Or I missed your point? :-) Ok, I think I'm slowly wrapping my head around exactly what's going on, let me summarize to make sure I understand. The driver for this device does some degree of configuration, including enabling MSI-X for the device. It then initiates a BIST via non-standard memory mapped registers which resets some parts of the device, including the MMIO space containing the MSI-X vector table, but not including PCI config space of the device. In particular, the COMMAND register and BAR values in PCI config space are left intact (and apparently the MSI-X capability as well). If the driver wanted to be really evil, it could do this with vectors enabled and rely on the reset value of the MSI-X vectors being masked. However, we get lucky and the driver has all of the vectors masked prior to reset so that after reset we see the masked to unmasked transition and use that to program the eventfd, which is where you'd like to re-write the vector message. Is that all correct? If the rest of config space is unaffected by this reset then my suggestion to tie it into vfio_bar_restore() probably doesn't make sense. In fact, it doesn't seem like there's any config space interaction we could count on to reliably detect this. Thinking out loud, I wonder if there's any value to reading the MSI-X message from the device and comparing to the cached value so that we can at least detect that we've encountered this situation. If we did that, we could restore all of the vectors in the table. However, it seems like the only value that would add would be to write a message to syslog since the guest will need to re-write any vectors it intends to use (and assuming we can count on vectors being masked after reset as the spec indicates). So, I guess I can't think of anything better than what you proposed (with better comments to detail the situation for later). Thanks, Alex -- 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: [RFC]VM live snapshot proposal
Is there any other proposals to implement vm-snapshot?
See the discussion by Paolo and Andrea about post-copy migration, which adds
kernel memory management features for tracking userspace page faults.
Perhaps you can use that infrastructure to trap guest writes.
Stefan
I will look into Paolo's new infrastructure first, and post new progress later.
Thanks
N�r��yb�X��ǧv�^�){.n�+h����ܨ}���Ơz�j:+v���zZ+��+zf���h���~i���z� �w���?��)ߢf
RE: [Qemu-devel] [RFC]VM live snapshot proposal
Good suggestion, The latest patches of post-copy seems updated 2 years ago. https://github.com/yamahata/qemu I'm working on post-copy at the moment, using Andrea's kernel code, using bits of Yamahata's code base as well; hopefully it won't be too long until we have something to post. One question: Can post-copy fallback if exceptions happen during post-copy? What do you mean by 'exceptions' here? Generally postcopy can't fall back to precopy because once you're in postcopy mode the state is split between the two machines. Like destination VM interrupted due to memory-copy error or other exceptions, with pre-copy scheme, we can fall-back to the source-vm. One simple question(may be discussed before), what kind of scenario does post-copy aim for?
Re: host_fx_image, guest_fx_image ; what are they ?
any hint ? or clue ? On Tue, Mar 4, 2014 at 11:35 PM, ratheesh kannoth ratheesh@gmail.com wrote: Hi List, Could you please help me understand below variables ? i found it in struct kvm_vcpu char *host_fx_image; char *guest_fx_image; -Ratheesh -- 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: [RFC]VM live snapshot proposal
Hi, Andrea Where can I get the dev-git-branch? I can use it to try the snapshot prototype coding. Thanks. -Original Message- From: Andrea Arcangeli [mailto:aarca...@redhat.com] Sent: Tuesday, March 04, 2014 3:52 AM To: Paolo Bonzini Cc: Kevin Wolf; Stefan Hajnoczi; Huangpeng (Peter); qemu-de...@nongnu.org; Wenchao Xia; Pavel Hrdina; KVM devel mailing list; Zhanghailiang Subject: Re: [RFC]VM live snapshot proposal Hi Paolo, On Mon, Mar 03, 2014 at 02:47:31PM +0100, Paolo Bonzini wrote: I'm not sure what's the status of the kernel infrastructure for post-copy. Andrea? sys_userfaultfd is still work in progress but it shouldn't be much work left to completion. madvise(MADV_USERFAULT) and remap_anon_pages() are complete for a while.
[Bug 71521] New: Host call trace when create guest.
https://bugzilla.kernel.org/show_bug.cgi?id=71521 Bug ID: 71521 Summary: Host call trace when create guest. Product: Virtualization Version: unspecified Kernel Version: 3.14.0-rc1 Hardware: x86-64 OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: kvm Assignee: virtualization_...@kernel-bugs.osdl.org Reporter: robert...@intel.com Regression: No Created attachment 128051 -- https://bugzilla.kernel.org/attachment.cgi?id=128051action=edit host-dmesg Environment: Host OS (ia32/ia32e/IA64):ia32e Guest OS (ia32/ia32e/IA64):ia32e Guest OS Type (Linux/Windows):Linux kvm.git Commit:d3714010c307d26df251c45be9cd12ab6d41f0c4 qemu-kvm Commit:9fbee91a131a05e443d7108d7fbdf3ca91020290 Host Kernel Version:3.14.0-rc1 Hardware:Romley_EP, Ivytown_EP Bug detailed description: -- after create guest, the host will call trace Reproduce steps: 1. create guest qemu-system-x86_64 -enable-kvm -m 1024 -smp 2 -net none /root/rhel6u4.qcow Current result: host call trace Expected result: guest and host work fine Basic root-causing log: -- vmwrite error: reg 2812 value 0 (err 12) CPU: 2 PID: 10596 Comm: qemu-system-x86 Not tainted 3.14.0-rc1 #2 Hardware name: Intel Corporation S2600CP/S2600CP, BIOS SE5C600.86B.02.01.1001.080920131108 08/09/2013 880234079c78 81482475 0006 880623130040 880234079c88 a02d51d2 880234079c98 a02d51ed 880234079cc8 a02dd407 03c0 Call Trace: [81482475] dump_stack+0x49/0x5c [a02d51d2] vmwrite_error+0x27/0x29 [kvm_intel] [a02d51ed] vmcs_writel+0x19/0x1b [kvm_intel] [a02dd407] vmx_set_msr+0x10b/0x26e [kvm_intel] [a025c37c] do_set_msr+0x27/0x29 [kvm] [a02673cf] msr_io+0xa0/0x101 [kvm] [a025c355] ? kvm_set_msr+0x13/0x13 [kvm] [a0267936] kvm_arch_vcpu_ioctl+0x37e/0xb7b [kvm] [a02d5484] ? update_cr8_intercept+0x1b/0x1d [kvm_intel] [a0264495] ? update_cr8_intercept+0x65/0x6a [kvm] [a026a07c] ? kvm_arch_vcpu_ioctl_set_sregs+0x38b/0x407 [kvm] [a025750e] ? kvm_vcpu_ioctl+0x25c/0x4b5 [kvm] [a02681d8] ? kvm_arch_vcpu_load+0xa5/0x16c [kvm] [a02576f0] kvm_vcpu_ioctl+0x43e/0x4b5 [kvm] [8110349b] ? do_brk+0x265/0x2bc [8113495d] do_vfs_ioctl+0x2a2/0x2be [8113c799] ? __fget_light+0x4a/0x5c [811349d2] SyS_ioctl+0x59/0x7d [8148c762] system_call_fastpath+0x16/0x1b more tests: kernel version:3.14.0-rc1 kvm.git + qemu.git =result d3714010 + 732c66ce =pass d3714010 + 9fbee91a =fail kernel version:3.13.-rc2 kvm.git + qemu.git =result 7650b687 + 732c66ce = pass 7650b687 + 9fbee91a = pass -- You are receiving this mail because: You are watching the assignee of the bug. -- 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] KVM/ARM for 3.15
On Tue, Mar 4, 2014 at 10:27 AM, Marc Zyngier marc.zyng...@arm.com wrote: Paolo, Gleb, Please pull the following tag to get what we currently have queued for 3.15. This series fixes a number of issue we have with when the guest runs with caches off. Thanks, M. The following changes since commit 1b385cbdd74aa803e966e01e5fe49490d6044e30: kvm, vmx: Really fix lazy FPU on nested guest (2014-02-27 22:54:11 +0100) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git tags/kvm-for-3.15-1 for you to fetch changes up to 56041bf920d2937b7cadcb30cb206f0372eee814: ARM: KVM: fix warning in mmu.c (2014-03-03 01:15:25 +) This series fixes coherency issues on arm and arm64 when the guest runs with caches off, and fixes a couple of other bugs in the process. Marc Zyngier (12): arm64: KVM: force cache clean on page fault when caches are off arm64: KVM: allows discrimination of AArch32 sysreg access arm64: KVM: trap VM system registers until MMU and caches are ON ARM: KVM: introduce kvm_p*d_addr_end arm64: KVM: flush VM pages before letting the guest enable caches I tested the first 5 patches on APM arm64 board, and only after applying the 5 patches, qemu can boot kernel successfully, otherwise kernel can't be booted from qemu. Thanks Marc. Thanks, -- Ming Lei -- 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] KVM/ARM for 3.15
On Wed, Mar 5, 2014 at 1:23 PM, Ming Lei ming@canonical.com wrote: On Tue, Mar 4, 2014 at 10:27 AM, Marc Zyngier marc.zyng...@arm.com Marc Zyngier (12): arm64: KVM: force cache clean on page fault when caches are off arm64: KVM: allows discrimination of AArch32 sysreg access arm64: KVM: trap VM system registers until MMU and caches are ON ARM: KVM: introduce kvm_p*d_addr_end arm64: KVM: flush VM pages before letting the guest enable caches I tested the first 5 patches on APM arm64 board, and only after applying the 5 patches, qemu can boot kernel successfully, otherwise kernel can't be booted from qemu. For the first 5 patches, please feel free to add: Tested-by: Ming Lei ming@canonical.com Thanks, -- Ming Lei -- 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
