[PATCH] kvm: external module: move Kbuild to x86 directory
From: Xiantao Zhang [EMAIL PROTECTED] Moving x86's Kbuild to x86. Signed-off-by: Xiantao Zhang [EMAIL PROTECTED] Signed-off-by: Avi Kivity [EMAIL PROTECTED] diff --git a/kernel/Kbuild b/kernel/Kbuild dissimilarity index 100% index cb63582..7019ca0 100644 --- a/kernel/Kbuild +++ b/kernel/Kbuild @@ -1,11 +1 @@ -obj-m := kvm.o kvm-intel.o kvm-amd.o -kvm-objs := kvm_main.o x86.o mmu.o x86_emulate.o anon_inodes.o irq.o i8259.o \ -lapic.o ioapic.o x86/preempt.o i8254.o coalesced_mmio.o \ -x86/external-module-compat.o -ifeq ($(CONFIG_KVM_TRACE),y) -kvm-objs += kvm_trace.o -endif -kvm-intel-objs := vmx.o x86/vmx-debug.o x86/external-module-compat.o -kvm-amd-objs := svm.o x86/external-module-compat.o - -CFLAGS_kvm_main.o = -DKVM_MAIN +obj-$(CONFIG_X86) += x86/ diff --git a/kernel/Makefile b/kernel/Makefile index c2c666e..94d63bc 100644 --- a/kernel/Makefile +++ b/kernel/Makefile @@ -67,16 +67,19 @@ source-sync: $(LINUX)/virt/kvm/./*.[ch] \ $T/ + set -e for i in $(find $T -name '*.c'); do \ + $(call unifdef,$$i); done + for i in $(hack-files); \ do $(call hack, $$i); done for i in $$(find $T -type f -printf '%P '); \ - do cmp -s $$i $T/$$i || cp $T/$$i $$i; done + do cmp -s $(ARCH_DIR)/$$i $T/$$i || cp $T/$$i $(ARCH_DIR)/$$i; done rm -rf $T install: mkdir -p $(DESTDIR)/$(INSTALLDIR) - cp *.ko $(DESTDIR)/$(INSTALLDIR) + cp $(ARCH_DIR)/*.ko $(DESTDIR)/$(INSTALLDIR) for i in $(ORIGMODDIR)/drivers/kvm/*.ko \ $(ORIGMODDIR)/arch/$(ARCH_DIR)/kvm/*.ko; do \ if [ -f $$i ]; then mv $$i $$i.orig; fi; \ @@ -94,7 +97,7 @@ rpm: all sed 's/^Release:.*/Release: $(rpmrelease)/; s/^%define kverrel.*/%define kverrel $(KVERREL)/' \ kvm-kmod.spec $(tmpspec) rpmbuild --define=kverrel $(KVERREL) \ ---define=objdir $$(pwd) \ +--define=objdir $$(pwd)/$(ARCH_DIR) \ --define=_rpmdir $(RPMDIR) \ --define=_topdir $(rpm-topdir) \ -bb $(tmpspec) diff --git a/kernel/x86/Kbuild b/kernel/x86/Kbuild new file mode 100644 index 000..ee81a1e --- /dev/null +++ b/kernel/x86/Kbuild @@ -0,0 +1,11 @@ +obj-m := kvm.o kvm-intel.o kvm-amd.o +kvm-objs := kvm_main.o x86.o mmu.o x86_emulate.o ../anon_inodes.o irq.o i8259.o \ +lapic.o ioapic.o preempt.o i8254.o coalesced_mmio.o \ +external-module-compat.o +ifeq ($(CONFIG_KVM_TRACE),y) +kvm-objs += kvm_trace.o +endif +kvm-intel-objs := vmx.o vmx-debug.o external-module-compat.o +kvm-amd-objs := svm.o external-module-compat.o + +CFLAGS_kvm_main.o = -DKVM_MAIN -- To unsubscribe from this list: send the line unsubscribe kvm-commits in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] kvm: external module: workqueue compatibility
From: Avi Kivity [EMAIL PROTECTED]
Signed-off-by: Avi Kivity [EMAIL PROTECTED]
diff --git a/kernel/external-module-compat-comm.h
b/kernel/external-module-compat-comm.h
index f5169b8..be5c6b7 100644
--- a/kernel/external-module-compat-comm.h
+++ b/kernel/external-module-compat-comm.h
@@ -495,3 +495,28 @@ struct timespec kvm_ns_to_timespec(const s64 nsec);
#endif
+/* work_struct lost the 'data' field in 2.6.20 */
+#if LINUX_VERSION_CODE KERNEL_VERSION(2,6,20)
+
+#define kvm_INIT_WORK(work, handler) \
+ INIT_WORK(work, (void (*)(void *))handler, work)
+
+#else
+
+#define kvm_INIT_WORK(work, handler) INIT_WORK(work, handler)
+
+#endif
+
+/* cancel_work_sync() was flush_work() in 2.6.21 */
+#if LINUX_VERSION_CODE KERNEL_VERSION(2,6,22)
+
+static inline int cancel_work_sync(struct work_struct *work)
+{
+ /*
+* FIXME: actually cancel. How? Add own implementation of workqueues?
+*/
+ return 0;
+}
+
+#endif
+
diff --git a/kernel/hack-module.awk b/kernel/hack-module.awk
index 4a9379c..a9ac1f2 100644
--- a/kernel/hack-module.awk
+++ b/kernel/hack-module.awk
@@ -1,3 +1,4 @@
+BEGIN { split(INIT_WORK, compat_apis); }
/^int kvm_init\(/ { anon_inodes = 1 }
@@ -69,6 +70,13 @@
{ sub(/hrtimer_start/, hrtimer_start_p) }
{ sub(/hrtimer_cancel/, hrtimer_cancel_p) }
+{
+for (i in compat_apis) {
+ ident = compat_apis[i]
+ sub(\\ ident \\, kvm_ ident)
+}
+}
+
{ print }
/kvm_x86_ops-run/ {
--
To unsubscribe from this list: send the line unsubscribe kvm-commits in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/5] KVM: pci device assignment
* On Tuesday 29 July 2008 15:08:27 Ben-Ami Yassour wrote:
On Tue, 2008-07-29 at 14:49 +0530, Amit Shah wrote:
* On Monday 28 Jul 2008 21:56:26 Ben-Ami Yassour wrote:
+static int kvm_vm_ioctl_assign_device(struct kvm *kvm,
+ struct kvm_assigned_pci_dev *assigned_dev)
+{
+ if (pci_enable_device(dev)) {
+ printk(KERN_INFO %s: Could not enable PCI device\n, __func__);
+ r = -EBUSY;
+ goto out_put;
+ }
+ r = pci_request_regions(dev, kvm_assigned_device);
+ if (r) {
+ printk(KERN_INFO %s: Could not get access to device regions\n,
+__func__);
+ goto out_disable;
Shouldn't disable here unconditionally (see my comment earlier to the
previous patch).
Why? the device should not be used by the host at the same time.
What is the condition that you were thinking of?
+static void kvm_free_assigned_devices(struct kvm *kvm)
+{
+ struct list_head *ptr, *ptr2;
+ struct kvm_assigned_dev_kernel *assigned_dev;
+
+ list_for_each_safe(ptr, ptr2, kvm-arch.assigned_dev_head) {
+ assigned_dev = list_entry(ptr,
+ struct kvm_assigned_dev_kernel,
+ list);
+
+ if (irqchip_in_kernel(kvm) assigned_dev-irq_requested) {
+ free_irq(assigned_dev-host_irq,
+ (void *)assigned_dev);
+
+ kvm_unregister_irq_ack_notifier(kvm,
+ assigned_dev-
+ ack_notifier);
+ }
Unregister the notifier before freeing irq
I don't think that there is any importance to the order in this case,
but just in case, the order should be in reverse to the initialization
order, which is the case here.
Just that we shouldn't accept any new interrupts to ack because we're going to
free the irq as the next step. This is more relevant now that we don't have
the rwlock for the device assignment structures. If the work gets scheduled
after we free the resources, it's going to bomb:
+/* Ack the irq line for an assigned device */
+static void kvm_assigned_dev_ack_irq(struct kvm_irq_ack_notifier *kian)
+{
+ struct kvm_assigned_dev_kernel *dev;
+
+ if (kian-gsi == -1)
+ return;
+
+ dev = container_of(kian, struct kvm_assigned_dev_kernel,
+ ack_notifier);
+ kvm_set_irq(dev-kvm, dev-guest_irq, 0);
+ enable_irq(dev-host_irq);
+}
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] reserved-ram for pci-passthrough without VT-d capable hardware
* On Tuesday 29 July 2008 18:47:35 Andi Kleen wrote: I'm not so interested to go there right now, because while this code is useful right now because the majority of systems out there lacks VT-d/iommu, I suspect this code could be nuked in the long run when all systems will ship with that, which is why I kept it all Actually at least on Intel platforms and if you exclude the lowest end VT-d is shipping universally for quite some time now. If you buy a Intel box today or bought it in the last year the chances are pretty high that it has VT-d support. I think you mean VT-x, which is virtualization extensions for the x86 architecture. VT-d is virtualization extensions for devices (IOMMU). Amit -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Live Migration fails
Daniel Hasler wrote: After a while, on host B (the target), I see the following error: migration: wait_for_go: read error len=0 (Interrupted system call) Migration failed rc=210 while on host A, I read following error message: WAIT FOR ACK: timeout reached Migration failed! ret=0 error=13 No, this is a bug I just fixed yesterday in Qemu proper. The next time that Avi rebases KVM to Qemu (which he said he would do as soon as the fix went into Qemu), then this should be fixed. FYI, the problem is basically that the i2c restore on the destination side was expecting 4 bytes, while the i2c save on the sending side was only sending 1 byte, so they eventually timed out while waiting for each other. Chris Lalancette -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fresh install of Windows XP hangs early in boot?
Roland Dreier wrote: BTW I tried using if=ide to install Windows XP and got a blue screen during the installer. What are people doing to run XP in a kvm guest? Hm, your comment later on makes me think you tried this on AMD. If so, I have also run into a similar problem with Windows guests under AMD. After installing WinDbg, it told me that it was a Paging Request in Non-Paged memory related to the Video memory area. Does yours look similar to that? I have not had time to track it further than that, though. Chris Lalancette -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] autoport overrides actual VNC port number in dump-xml
On Wed, Jul 30, 2008 at 12:32:57AM -0500, Charles Duffy wrote: Per subject; if autoport is in use for a host, the current virDomainGraphicsDefFormat code always emits port=-1, even if a port is assigned to the host; this leaves no way for a client to find the VNC port assigned to the host in question. You've got the wrong mailing list here - you want the libvirt list at [EMAIL PROTECTED] Regards, Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
kvm72: configure script mangles --audio-drv-list and --audio-card-list and blocks them from --help
The ./configure script, whilst trying to be clever in passing options to qemu/configure, mangles the --audio-*-list options. It also prevents the audio-*-list options showing up as a result of --help. Here's the output with additional logging echos to show what it and qemu/configure actually see: $ ./configure --prefix=/usr --enable-vde \ --audio-card-list=ac97 adlib cs4231a gus \ --audio-drv-list=alsa esd pa Checking options: --prefix = /usr --enable-vde = --audio-card-list = ac97 adlib cs4231a gus --audio-drv-list = alsa esd pa qemu/configure command line: ./configure --target-list=x86_64-softmmu --disable-kqemu --disable-gcc-check \ --extra-cflags=-I /home/all/SourceCode/kvm-72/qemu/../libkvm -DCONFIG_X86 \ --extra-ldflags=-L /home/all/SourceCode/kvm-72/qemu/../libkvm \ --kernel-path=/home/all/SourceCode/kvm-72/kernel \ --prefix=/usr --enable-vde --audio-card-list --audio-drv-list Checking options: --target-list=x86_64-softmmu = x86_64-softmmu --disable-kqemu = --disable-gcc-check = --extra-cflags=-I /home/all/SourceCode/kvm-72/qemu/../libkvm -DCONFIG_X86 = -I /home/all/SourceCode/kvm-72/qemu/../libkvm -DCONFIG_X86 --extra-ldflags=-L /home/all/SourceCode/kvm-72/qemu/../libkvm = -L /home/all/SourceCode/kvm-72/qemu/../libkvm --kernel-path=/home/all/SourceCode/kvm-72/kernel = /home/all/SourceCode/kvm-72/kernel --prefix=/usr = /usr --enable-vde = --audio-card-list = ERROR: unknown option --audio-card-list Usage: ./configure [options] -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] reserved-ram for pci-passthrough without VT-d capable hardware
On Wed, Jul 30, 2008 at 11:50:43AM +0530, Amit Shah wrote: * On Tuesday 29 July 2008 18:47:35 Andi Kleen wrote: I'm not so interested to go there right now, because while this code is useful right now because the majority of systems out there lacks VT-d/iommu, I suspect this code could be nuked in the long run when all systems will ship with that, which is why I kept it all Actually at least on Intel platforms and if you exclude the lowest end VT-d is shipping universally for quite some time now. If you buy a Intel box today or bought it in the last year the chances are pretty high that it has VT-d support. I think you mean VT-x, which is virtualization extensions for the x86 architecture. VT-d is virtualization extensions for devices (IOMMU). No I really mean VT-d. The modern not very lowend Intel IOHubs all have it. -Andi -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] kvm-s390: Fix facility bits for guest
Am Dienstag, 29. Juli 2008 schrieb Christian Borntraeger: @@ -158,6 +158,7 @@ static int handle_stfl(struct kvm_vcpu * vcpu-stat.instruction_stfl++; facility_list = ~(1UL24); /* no stfle */ + facility_list = ~(1UL23); /* no large pages */ rc = copy_to_guest(vcpu, offsetof(struct _lowcore, stfl_fac_list), facility_list, sizeof(facility_list)); Hello Avi, please dont apply this patch, there is a better one... Heiko pointed out, that its generally safer to use an opt-in method instead of killing problematic cases. What about this updated patch: From: Christian Borntraeger [EMAIL PROTECTED] Newer machine models can add new feature bits, which might require host changes. We have to ensure that we only advertise feature flags which we consider save. I disabled all unassigned feature flags, as well as stfle, large pages and some others. Signed-off-by: Christian Borntraeger [EMAIL PROTECTED] --- arch/s390/kvm/priv.c |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) Index: kvm/arch/s390/kvm/priv.c === --- kvm.orig/arch/s390/kvm/priv.c +++ kvm/arch/s390/kvm/priv.c @@ -157,7 +157,8 @@ static int handle_stfl(struct kvm_vcpu * int rc; vcpu-stat.instruction_stfl++; - facility_list = ~(1UL24); /* no stfle */ + /* only pass the facility bits, which we can handle */ + facility_list = 0xfe00fff3; rc = copy_to_guest(vcpu, offsetof(struct _lowcore, stfl_fac_list), facility_list, sizeof(facility_list)); -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] KVM: Fix exiting from HLT emulation with MP_STATE_HALTED
From 8019bdd0c7e2933a4d6f7e046d1cc2ded221784e Mon Sep 17 00:00:00 2001
From: Sheng Yang [EMAIL PROTECTED]
Date: Wed, 30 Jul 2008 21:45:58 +0800
Subject: [PATCH] KVM: Fix exiting from HLT emulation with
MP_STATE_HALTED
VCPU can be forced exit from HLT emulation without setting mp_state to
MP_STATE_RUNNABLE, it's due to QEmu can kick vcpus which are doing HLT
emulation to do something like stop or info cpus. Here are two
issues of this behaviour:
First, if vcpu exit to QEmu with MP_STATE_HALTED, it would keep in
this state later for vcpu_run(), which is eerie...
Second, a practical problem: bios load AP boot up code to 0x1, and
AP is running HLT there. But later grub load it's stage2 code to the
same address. Then if the halting vcpu was forced exit to QEmu in
grub, and come back for vcpu_run later, it can't execute HLT
instruction anymore, just because the bios code is not there,
and it would follow a piece of code of grub, which would cause
completely chaos...
The second issue directly lead to guest crash or SMP linux can't boot
up AP later if we stop or info cpus in grub.
The patch resumes the HLT emulation after interrupt by QEmu to fix it.
Signed-off-by: Sheng Yang [EMAIL PROTECTED]
---
arch/x86/kvm/x86.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 94a2165..3b31959 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -2881,6 +2881,11 @@ again:
clear_bit(KVM_REQ_PENDING_TIMER, vcpu-requests);
kvm_inject_pending_timer_irqs(vcpu);
+ if (vcpu-arch.mp_state == KVM_MP_STATE_HALTED) {
+ r = kvm_emulate_halt(vcpu);
+ goto next_around;
+ }
+
preempt_disable();
kvm_x86_ops-prepare_guest_switch(vcpu);
@@ -2962,6 +2967,7 @@ again:
r = kvm_x86_ops-handle_exit(kvm_run, vcpu);
+next_around:
if (r 0) {
if (dm_request_for_irq_injection(vcpu, kvm_run)) {
r = -EINTR;
--
1.5.4.5
From 8019bdd0c7e2933a4d6f7e046d1cc2ded221784e Mon Sep 17 00:00:00 2001
From: Sheng Yang [EMAIL PROTECTED]
Date: Wed, 30 Jul 2008 21:45:58 +0800
Subject: [PATCH] KVM: Fix exiting from HLT emulation with MP_STATE_HALTED
VCPU can be forced exit from HLT emulation without setting mp_state to
MP_STATE_RUNNABLE, it's due to QEmu can kick vcpus which are doing HLT
emulation to do something like stop or info cpus. Here are two issues of
this behaviour:
First, if vcpu exit to QEmu with MP_STATE_HALTED, it would keep in this state
later for vcpu_run(), which is eerie...
Second, a practical problem: bios load AP boot up code to 0x1, and AP is
running HLT there. But later grub load it's stage2 code to the same address. Then
if the halting vcpu was forced exit to QEmu in grub, and come back for vcpu_run later,
it can't execute HLT instruction anymore, just because the bios code is not there,
and it would follow a piece of code of grub, which would cause completely chaos...
The second issue directly lead to guest crash or SMP linux can't boot up AP
later if we stop or info cpus in grub.
The patch resumes the HLT emulation after interrupt by QEmu to fix it.
Signed-off-by: Sheng Yang [EMAIL PROTECTED]
---
arch/x86/kvm/x86.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 94a2165..3b31959 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -2881,6 +2881,11 @@ again:
clear_bit(KVM_REQ_PENDING_TIMER, vcpu-requests);
kvm_inject_pending_timer_irqs(vcpu);
+ if (vcpu-arch.mp_state == KVM_MP_STATE_HALTED) {
+ r = kvm_emulate_halt(vcpu);
+ goto next_around;
+ }
+
preempt_disable();
kvm_x86_ops-prepare_guest_switch(vcpu);
@@ -2962,6 +2967,7 @@ again:
r = kvm_x86_ops-handle_exit(kvm_run, vcpu);
+next_around:
if (r 0) {
if (dm_request_for_irq_injection(vcpu, kvm_run)) {
r = -EINTR;
--
1.5.4.5
Re: [PATCH] reserved-ram for pci-passthrough without VT-d capable hardware
On Wed, Jul 30, 2008 at 11:50:43AM +0530, Amit Shah wrote: * On Tuesday 29 July 2008 18:47:35 Andi Kleen wrote: I'm not so interested to go there right now, because while this code is useful right now because the majority of systems out there lacks VT-d/iommu, I suspect this code could be nuked in the long run when all systems will ship with that, which is why I kept it all Actually at least on Intel platforms and if you exclude the lowest end VT-d is shipping universally for quite some time now. If you buy a Intel box today or bought it in the last year the chances are pretty high that it has VT-d support. I think you mean VT-x, which is virtualization extensions for the x86 architecture. VT-d is virtualization extensions for devices (IOMMU). I think Andi understood VT-d right but even if he was right that every reader of this email that is buying a new VT-x system today is also almost guaranteed to get a VT-d motherboard (which I disagree unless you buy some really expensive toy), there are current large installations of VT-x systems that lacks VT-d and that with recent current dual/quadcore cpus are very fast and will be used for the next couple of years and they will not upgrade just the motherboard to use pci-passthrough. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/04]Create x86 directory to hold x86-specific files.
Zhang, Xiantao wrote: Avi Kivity wrote: Zhang, Xiantao wrote: From c8c8c5a6b3ff943cb645f9ac4ef169490f14cd08 Mon Sep 17 00:00:00 2001 From: Zhang Xiantao [EMAIL PROTECTED] Date: Fri, 25 Jul 2008 16:50:30 +0800 Subject: [PATCH] KVM: external module: Moving x86-speicif files to x86 directory. Create x86 directory to hold x86-specific files. Signed-off-by: Zhang Xiantao [EMAIL PROTECTED] You forgot to attach a patch; and your mailer corrupts patches, so I can't apply this. Sorry. Attached! :) Applied all, but I had to revert the change to the install command in the last patch. My install doesn't like the -C option. Please check if further changes are necessary. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 0/3] fix PIT injection
Hi Dor, On Wed, Jul 30, 2008 at 12:50:06AM +0300, Dor Laor wrote: Marcelo Tosatti wrote: The in-kernel PIT emulation can either inject too many or too few interrupts. While it's an improvement, the in-kernel pit is still not perfect. For example, on pit frequency changes the pending count should be recalculated and matched to the new frequency. Point. That one can be addressed. I also tumbled on live migration problem Can you provide more details? How to reproduce? and there is your guest smp fix. IMHO we need to switch back to userspace pit. [Actually I did consider in-kernel pit myself in the past.]. The reasons: 1. There is no performance advantage doing this in the kernel. It's just potentially reduced the host stability and reduces code Keeping device emulation in userspace is desired, of course. The drawbacks of timer emulation, AFAICS, are: - Timers in QEMU are, currently, not handled separately from other IO processing. The delay between timer expiration and interrupt injection depends on the time spent handling unrelated IO in QEMU's main loop. This can be fixed, by treating guest timer expiration with higher priority. - The in-kernel emulation allows the host timer to be locked to the vcpu it belongs. With userspace emulation, an IPI is necessary whenever the iothread is running on a different physical CPU than the target vcpu. The overall cost to wakeup a vcpu in a different physical CPU is: syscall, IRQ lock acquision (currently kvm-lock, which also protects access to in-kernel devices) and finally the IPI cost, which is hundreds of ns (googling around it seems to be in the range of 700ns). That cost is non-existant with timers locked to the vcpu. I don't know what specific problems the in-kernel PIT emulation solved (I recall certain Windows configurations were largely improved). Do you the details? Sheng? 2. There are floating patches to fix pit/rtc injection in the same way the acked irq is sone here. So the first 2 patches are relevant. 3. Will we do the same for rtc? - why duplicate userspace code in the kernel? We won't have smp issues since we have qemu_mutex and it will be simpler too. If you agree, please help merging the qemu patches. Otherwise argue against the above :) Cheers, Dor -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] reserved-ram for pci-passthrough without VT-d capable hardware
Andrea Arcangeli wrote: On Wed, Jul 30, 2008 at 11:50:43AM +0530, Amit Shah wrote: * On Tuesday 29 July 2008 18:47:35 Andi Kleen wrote: I'm not so interested to go there right now, because while this code is useful right now because the majority of systems out there lacks VT-d/iommu, I suspect this code could be nuked in the long run when all systems will ship with that, which is why I kept it all Actually at least on Intel platforms and if you exclude the lowest end VT-d is shipping universally for quite some time now. If you buy a Intel box today or bought it in the last year the chances are pretty high that it has VT-d support. I think you mean VT-x, which is virtualization extensions for the x86 architecture. VT-d is virtualization extensions for devices (IOMMU). I think Andi understood VT-d right but even if he was right that every reader of this email that is buying a new VT-x system today is also almost guaranteed to get a VT-d motherboard (which I disagree unless you buy some really expensive toy), there are current large installations of VT-x systems that lacks VT-d and that with recent current dual/quadcore cpus are very fast and will be used for the next couple of years and they will not upgrade just the motherboard to use pci-passthrough. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html In addition KVM is used in embedded too and things are slower there, we know of a specific use case (production) that demands 1:1 mapping and can't use VT-d -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATH] kvm-72 - fix compilation on 2.6.26 (anon_inode_getfd flag)
Nikola Ciprich wrote: Should that be = for future use? nope, newer versions have also the flag parameter (see 2.6.27-rcX), so this is intended only for 2.6.26 Please resend the patch as I don't have it in my mailbox. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Live Migration fails
Chris Lalancette wrote: Daniel Hasler wrote: After a while, on host B (the target), I see the following error: migration: wait_for_go: read error len=0 (Interrupted system call) Migration failed rc=210 while on host A, I read following error message: WAIT FOR ACK: timeout reached Migration failed! ret=0 error=13 No, this is a bug I just fixed yesterday in Qemu proper. The next time that Avi rebases KVM to Qemu (which he said he would do as soon as the fix went into Qemu), then this should be fixed. Migration is also known to be broken with virtio. Regards, Anthony Liguori FYI, the problem is basically that the i2c restore on the destination side was expecting 4 bytes, while the i2c save on the sending side was only sending 1 byte, so they eventually timed out while waiting for each other. Chris Lalancette -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] reserved-ram for pci-passthrough without VT-d capable hardware
On Wed, Jul 30, 2008 at 05:16:06PM +0300, Dor Laor wrote: In addition KVM is used in embedded too and things are slower there, we know of a specific use case (production) that demands 1:1 mapping and can't use VT-d Since you mentioned this ;), I take opportunity to add that those embedded usages are the ones that are totally fine with the compile time passthrough-guest-ram decision, instead of a boot time decision. Those host kernels will likely have RT patches (KVM works great with preempt-RT indeed) and in turn the compile time ram selection is the least of their problems as you can imagine ;). So you can see my patch as an embedded-build option, similar to Configure standard kernel features (for small systems) and no distro is shipping new kernels with that feature on either. Than if we decide 1:1 should have larger userbase instead of only the people that knows what they're doing (i.e. 1:1 guest can destroy linux-hypervisor) we can always add a bit of strtol parsing to 16bit kernelloader. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] reserved-ram for pci-passthrough without VT-d capable hardware
On Wed, 30 Jul 2008 15:58:46 +0200 Andrea Arcangeli [EMAIL PROTECTED] wrote: On Wed, Jul 30, 2008 at 11:50:43AM +0530, Amit Shah wrote: * On Tuesday 29 July 2008 18:47:35 Andi Kleen wrote: I'm not so interested to go there right now, because while this code is useful right now because the majority of systems out there lacks VT-d/iommu, I suspect this code could be nuked in the long run when all systems will ship with that, which is why I kept it all Actually at least on Intel platforms and if you exclude the lowest end VT-d is shipping universally for quite some time now. If you buy a Intel box today or bought it in the last year the chances are pretty high that it has VT-d support. I think you mean VT-x, which is virtualization extensions for the x86 architecture. VT-d is virtualization extensions for devices (IOMMU). I think Andi understood VT-d right but even if he was right that every reader of this email that is buying a new VT-x system today is also almost guaranteed to get a VT-d motherboard (which I disagree unless you buy some really expensive toy), there are current large installations of VT-x systems that lacks VT-d and that with recent current dual/quadcore cpus are very fast and will be used for the next couple of years and they will not upgrade just the motherboard to use pci-passthrough. Today, very inexpensive desktops (for example, Dell OptiPlex 755) have VT-d support. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 0/3] fix PIT injection
(Sorry, forgot to switch to plain text in Gmail, rejected by vger.kernel.org...) On Wed, Jul 30, 2008 at 10:15 PM, Marcelo Tosatti [EMAIL PROTECTED] wrote: Hi Dor, On Wed, Jul 30, 2008 at 12:50:06AM +0300, Dor Laor wrote: Marcelo Tosatti wrote: The in-kernel PIT emulation can either inject too many or too few interrupts. While it's an improvement, the in-kernel pit is still not perfect. For example, on pit frequency changes the pending count should be recalculated and matched to the new frequency. Point. That one can be addressed. I also tumbled on live migration problem Can you provide more details? How to reproduce? and there is your guest smp fix. IMHO we need to switch back to userspace pit. [Actually I did consider in-kernel pit myself in the past.]. The reasons: 1. There is no performance advantage doing this in the kernel. It's just potentially reduced the host stability and reduces code Keeping device emulation in userspace is desired, of course. The drawbacks of timer emulation, AFAICS, are: - Timers in QEMU are, currently, not handled separately from other IO processing. The delay between timer expiration and interrupt injection depends on the time spent handling unrelated IO in QEMU's main loop. This can be fixed, by treating guest timer expiration with higher priority. - The in-kernel emulation allows the host timer to be locked to the vcpu it belongs. With userspace emulation, an IPI is necessary whenever the iothread is running on a different physical CPU than the target vcpu. The overall cost to wakeup a vcpu in a different physical CPU is: syscall, IRQ lock acquision (currently kvm-lock, which also protects access to in-kernel devices) and finally the IPI cost, which is hundreds of ns (googling around it seems to be in the range of 700ns). That cost is non-existant with timers locked to the vcpu. I don't know what specific problems the in-kernel PIT emulation solved (I recall certain Windows configurations were largely improved). Do you the details? Sheng? Basicly, after in-kernel irqchip checked in and before in-kernel pit checked in, the time mechanism in KVM is chaos... Simply because userspace pit can't sync with in-kernel irqchip, typically tons of interrupt lost, e.g. a bug named guest time is 1/6 compare to host time. The main purpose to move pit to kernel is to fix this timer issue. There was another purpose, when we do the same to the Xen. That's Xen's IO exit to qemu is too heavy and affect performance badly. But KVM at least don't suffer that much. Personally, I don't against the idea move the IO part of PIT back to qemu and keep the interrupt handling part in kernel (though still a little sad...). I just don't know if we can do it elegantly, genericly, precisely, efficiently and relatively simply, for all (important) timer source. vpt.c in Xen has been criticized as too complex. -- regards Yang, Sheng -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fresh install of Windows XP hangs early in boot?
Hm, your comment later on makes me think you tried this on AMD. If so, I have also run into a similar problem with Windows guests under AMD. After installing WinDbg, it told me that it was a Paging Request in Non-Paged memory related to the Video memory area. Does yours look similar to that? I have not had time to track it further than that, though. Yes, I got a bluescreen on an AMD host but not an Intel host. And the bluescreen (I posted earlier) said PAGE_FAULT_IN_NONPAGED_AREA - R. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Device assignemnt: updated patches
Ben-Ami Yassour wrote: Following are the device assignment patches with the fixes of the comments that were sent for the previous version. Applied 1 and 3, thanks. I already got irq ack notifiers from Marcelo. 4/5 need to be updated to compile when VT-d is not built into the kernel, and also need retesting with mmu notifiers. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATH] kvm-72 - fix compilation on 2.6.26 (anon_inode_getfd flag)
Hi, sure.
hope it's OK
n.
PS: I mean't PATCH, not PATH of course. Although it was quite a long path to
patch :)
On Wed, Jul 30, 2008 at 05:34:14PM +0300, Avi Kivity wrote:
Nikola Ciprich wrote:
Should that be = for future use?
nope, newer versions have also the flag parameter (see 2.6.27-rcX), so this
is intended only for 2.6.26
Please resend the patch as I don't have it in my mailbox.
--
error compiling committee.c: too many arguments to function
--
-
Nikola CIPRICH
LinuxBox.cz, s.r.o.
28. rijna 168, 709 01 Ostrava
tel.: +420 596 603 142
fax:+420 596 621 273
mobil: +420 777 093 799
www.linuxbox.cz
mobil servis: +420 737 238 656
email servis: [EMAIL PROTECTED]
-
diff -Naur kvm-72/kernel/anon_inodes.c
kvm-72-fix-2.6.26-anon-inode/kernel/anon_inodes.c
--- kvm-72/kernel/anon_inodes.c 2008-07-27 12:08:56.0 +0200
+++ kvm-72-fix-2.6.26-anon-inode/kernel/anon_inodes.c 2008-07-29
10:36:51.0 +0200
@@ -245,6 +245,15 @@
return fd;
}
+#elif LINUX_VERSION_CODE == KERNEL_VERSION(2,6,26)
+
+int kvm_anon_inode_getfd(const char *name,
+const struct file_operations *fops,
+void *priv, int flags)
+{
+ return anon_inode_getfd(name, fops, priv);
+}
+
#else
int kvm_anon_inode_getfd(const char *name,
Re: kvm72: configure script mangles --audio-drv-list and --audio-card-list and blocks them from --help
On Wed, Jul 30, 2008 at 12:13:10PM +0100, TJ wrote: The ./configure script, whilst trying to be clever in passing options to qemu/configure, mangles the --audio-*-list options. It also prevents the audio-*-list options showing up as a result of --help. this sounds like the problem that was introduced with the qemu merge for kvm-71; the following patch series addresses it : http://www.mail-archive.com/kvm@vger.kernel.org/msg01763.html they should also apply to kvm-72 cleanly, but will try to rebase them and resend them later so they have a better chance of getting merged. Carlo -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[RESEND][PATCH 0/2] configure: add support for audio-{drv,card}-list
This is a rebased version of the original patch series presented to fix
issues to configure the different audio options in kvm and that is still
present in kvm-72 as shown by recent reports.
The following series adds support for the audio option lists from qemu's
configure that were added in kvm-71 to support selecting which interface
will be used to enable audio in the host from the guest (oss, alsa, sdl, esd,
fmod, or pulseaudio) and which audio devices emulation to enable for the
guest (ac97, adlib, cs2431a or gus).
PATCH 1/2 : configure: include audio list options for --help output
PATCH 2/2 : configure: passthrough for audio-{drv,card}-list
Carlo
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] configure: include audio list options for --help output
Reflects in kvm's configure the qemu options used to enable support for
the different libraries used for audio support propagation and the list
of audio devices emulated.
This list of options replaces the individual options that were used before
kvm-71 with a functional equivalent feature but will require build or script
instructions to replace calls to from --enable-{adlib,ac97,gus} or
--enable-{coreaudio,alsa,esd,fmod,dsound} with their equivalent flags.
Signed-off-by: Carlo Marcelo Arenas Belon [EMAIL PROTECTED]
---
configure |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/configure b/configure
index 72337c9..2558e0e 100755
--- a/configure
+++ b/configure
@@ -30,10 +30,11 @@ usage() {
EOF
cd qemu
-./configure --help | egrep enable-|disable- \
+./configure --help | egrep enable-|disable-|audio-|Available \
| grep -v user | grep -v system | grep -v kqemu | grep -v kvm \
| sed -e s/^ //g \
- | sed -es/ enable/enable/g | sed -e s/ disable/disable/g
+ | sed -e s/ enable/enable/g | sed -e s/ disable/disable/g \
+ | sed -e s/ set/set/g | sed -e s/ Available/Available/g
exit 1
}
--
1.5.4.5
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] configure: passthrough for audio-{drv,card} and logic cleanup
Avoids reformatting for the options that are send verbatim to qemu's
configure and add a passthrough for qemu options that use a space
separated list of options like the list for audio drivers enabled
or the list for audio devices emulated.
Signed-off-by: Carlo Marcelo Arenas Belon [EMAIL PROTECTED]
---
configure | 17 +
1 files changed, 13 insertions(+), 4 deletions(-)
diff --git a/configure b/configure
index 2558e0e..fc05767 100755
--- a/configure
+++ b/configure
@@ -10,6 +10,8 @@ qemu_cflags=
qemu_ldflags=
qemu_opts=
cross_prefix=
+audio_drv_list=
+audio_card_list=
arch=`uname -m`
target_exec=
@@ -39,7 +41,8 @@ EOF
}
while [[ $1 = -* ]]; do
-opt=$1; shift
+optorig=$1; shift
+opt=$optorig
arg=
if [[ $opt = *=* ]]; then
arg=${opt#*=}
@@ -67,16 +70,21 @@ while [[ $1 = -* ]]; do
--cross-prefix)
cross_prefix=$arg
;;
+ --audio-drv-list)
+ audio_drv_list=$arg
+ ;;
+ --audio-card-list)
+ audio_card_list=$arg
+ ;;
--help)
usage
;;
*)
- qemu_opts=$qemu_opts $opt
+ qemu_opts=$qemu_opts $optorig
;;
esac
done
-
#set kenel directory
libkvm_kerneldir=$(readlink -f kernel)
@@ -114,11 +122,12 @@ fi
--extra-ldflags=-L $PWD/../libkvm $qemu_ldflags \
--kernel-path=$libkvm_kerneldir \
--prefix=$prefix \
+${audio_drv_list:+--audio-drv-list=$audio_drv_list} \
+${audio_card_list:+--audio-card-list=$audio_card_list} \
${cross_prefix:+--cross-prefix=$cross_prefix} \
${cross_prefix:+--cpu=$arch} $qemu_opts
) || usage
-
cat EOF config.mak
ARCH=$arch
PREFIX=$prefix
--
1.5.4.5
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] x86 emulator: Emulate cld and std instructions
This patch adds instructions 'cld' and 'std' to the emulator. Signed-off-by: Mohammed Gamal [EMAIL PROTECTED] --- From 23c0868c6a48a5e75693bd4552255a89cf26bdc8 Mon Sep 17 00:00:00 2001 From: Mohammed Gamal [EMAIL PROTECTED](none) Date: Thu, 31 Jul 2008 00:04:34 +0300 Subject: [PATCH] Emulate cld and std instructions --- arch/x86/kvm/x86_emulate.c |8 1 files changed, 8 insertions(+), 0 deletions(-) diff --git a/arch/x86/kvm/x86_emulate.c b/arch/x86/kvm/x86_emulate.c index d5da7f1..9c72a77 100644 --- a/arch/x86/kvm/x86_emulate.c +++ b/arch/x86/kvm/x86_emulate.c @@ -1755,6 +1755,14 @@ special_insn: ctxt-eflags |= X86_EFLAGS_IF; c-dst.type = OP_NONE; /* Disable writeback. */ break; + case 0xfc: /* cld */ + ctxt-eflags = ~EFLG_DF; + c-dst.type = OP_NONE; /* Disable writeback. */ + break; + case 0xfd: /* std */ + ctxt-eflags |= EFLG_DF; + c-dst.type = OP_NONE; /* Disable writeback. */ + break; case 0xfe ... 0xff: /* Grp4/Grp5 */ rc = emulate_grp45(ctxt, ops); if (rc != 0) -- 1.5.4.3 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] x86 emulator: Emulate cld and std instructions
On Thu, Jul 31, 2008 at 12:08 AM, Mohammed Gamal [EMAIL PROTECTED] wrote: This patch adds instructions 'cld' and 'std' to the emulator. Signed-off-by: Mohammed Gamal [EMAIL PROTECTED] --- From 23c0868c6a48a5e75693bd4552255a89cf26bdc8 Mon Sep 17 00:00:00 2001 From: Mohammed Gamal [EMAIL PROTECTED](none) Date: Thu, 31 Jul 2008 00:04:34 +0300 Subject: [PATCH] Emulate cld and std instructions --- arch/x86/kvm/x86_emulate.c |8 1 files changed, 8 insertions(+), 0 deletions(-) diff --git a/arch/x86/kvm/x86_emulate.c b/arch/x86/kvm/x86_emulate.c index d5da7f1..9c72a77 100644 --- a/arch/x86/kvm/x86_emulate.c +++ b/arch/x86/kvm/x86_emulate.c @@ -1755,6 +1755,14 @@ special_insn: ctxt-eflags |= X86_EFLAGS_IF; c-dst.type = OP_NONE; /* Disable writeback. */ break; + case 0xfc: /* cld */ + ctxt-eflags = ~EFLG_DF; + c-dst.type = OP_NONE; /* Disable writeback. */ + break; + case 0xfd: /* std */ + ctxt-eflags |= EFLG_DF; + c-dst.type = OP_NONE; /* Disable writeback. */ + break; case 0xfe ... 0xff: /* Grp4/Grp5 */ rc = emulate_grp45(ctxt, ops); if (rc != 0) -- 1.5.4.3 Please ignore this patch due to format errors. I will resend it. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH][RESEND] x86_emulator: Emulate cld and std instruction
This patch adds 'cld' and 'std' instructions to the emulator Signed-off-by: Mohammed Gamal [EMAIL PROTECTED] --- arch/x86/kvm/x86_emulate.c |8 1 files changed, 8 insertions(+), 0 deletions(-) diff --git a/arch/x86/kvm/x86_emulate.c b/arch/x86/kvm/x86_emulate.c index d5da7f1..9c72a77 100644 --- a/arch/x86/kvm/x86_emulate.c +++ b/arch/x86/kvm/x86_emulate.c @@ -1755,6 +1755,14 @@ special_insn: ctxt-eflags |= X86_EFLAGS_IF; c-dst.type = OP_NONE; /* Disable writeback. */ break; + case 0xfc: /* cld */ + ctxt-eflags = ~EFLG_DF; + c-dst.type = OP_NONE; /* Disable writeback. */ + break; + case 0xfd: /* std */ + ctxt-eflags |= EFLG_DF; + c-dst.type = OP_NONE; /* Disable writeback. */ + break; case 0xfe ... 0xff: /* Grp4/Grp5 */ rc = emulate_grp45(ctxt, ops); if (rc != 0) -- 1.5.4.3 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
linux-next: ia64 allmodconfig
arch/ia64/kvm/../../../virt/kvm/ioapic.c:42:17: irq.h: No such file or directory arch/ia64/kvm/../../../virt/kvm/ioapic.c: In function `__kvm_ioapic_update_eoi': arch/ia64/kvm/../../../virt/kvm/ioapic.c:296: error: implicit declaration of function `kvm_notify_acked_irq' arch/ia64/kvm/../../../virt/kvm/ioapic.c: In function `ioapic_mmio_write': arch/ia64/kvm/../../../virt/kvm/ioapic.c:389: error: too few arguments to functi -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] kvm: bios: Put AP boot up code to 0x1000
From ba05b3c821400127074f65ee4d172fabbe3524cd Mon Sep 17 00:00:00 2001 From: Sheng Yang [EMAIL PROTECTED] Date: Thu, 31 Jul 2008 10:39:24 +0800 Subject: [PATCH] kvm: bios: Put AP boot up code to 0x1000 Rather than 0x1, which can be overrided by userspace program like grub. Signed-off-by: Sheng Yang [EMAIL PROTECTED] --- bios/rombios32.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/bios/rombios32.c b/bios/rombios32.c index 2dc1d25..f7a4234 100755 --- a/bios/rombios32.c +++ b/bios/rombios32.c @@ -60,7 +60,7 @@ typedef unsigned long long uint64_t; #define APIC_ENABLED 0x0100 -#define AP_BOOT_ADDR 0x1 +#define AP_BOOT_ADDR 0x1000 #define MPTABLE_MAX_SIZE 0x2000 #define SMI_CMD_IO_ADDR 0xb2 -- 1.5.6 From ba05b3c821400127074f65ee4d172fabbe3524cd Mon Sep 17 00:00:00 2001 From: Sheng Yang [EMAIL PROTECTED] Date: Thu, 31 Jul 2008 10:39:24 +0800 Subject: [PATCH] kvm: bios: Put AP boot up code to 0x1000 Rather than 0x1, which can be overrided by userspace program like grub. Signed-off-by: Sheng Yang [EMAIL PROTECTED] --- bios/rombios32.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/bios/rombios32.c b/bios/rombios32.c index 2dc1d25..f7a4234 100755 --- a/bios/rombios32.c +++ b/bios/rombios32.c @@ -60,7 +60,7 @@ typedef unsigned long long uint64_t; #define APIC_ENABLED 0x0100 -#define AP_BOOT_ADDR 0x1 +#define AP_BOOT_ADDR 0x1000 #define MPTABLE_MAX_SIZE 0x2000 #define SMI_CMD_IO_ADDR 0xb2 -- 1.5.6
Re: [PATCH 01/04]Create x86 directory to hold x86-specific files.
On Sunday 27 July 2008 17:46:26 Zhang, Xiantao wrote: Avi Kivity wrote: Zhang, Xiantao wrote: From c8c8c5a6b3ff943cb645f9ac4ef169490f14cd08 Mon Sep 17 00:00:00 2001 From: Zhang Xiantao [EMAIL PROTECTED] Date: Fri, 25 Jul 2008 16:50:30 +0800 Subject: [PATCH] KVM: external module: Moving x86-speicif files to x86 directory. Create x86 directory to hold x86-specific files. Signed-off-by: Zhang Xiantao [EMAIL PROTECTED] You forgot to attach a patch; and your mailer corrupts patches, so I can't apply this. Sorry. Attached! :) This broke kvm script in kvm-userspace. We need a update of it... -- regards Yang, Sheng -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] configure: passthrough for audio-{drv,card} and logic cleanup
This patch fails to achieve the intended aim since the values assigned to audio-*-list are hard-reset in several places in qemu/configure, both for initial variable 'declaration' and when setting sane defaults in the absence of command-line over-rides. If qemu/configure is to be left alone ./configure will have to insert the options into $qemuopt in a way that will allow the quotes surrounding the arguments to be correctly interpreted by the shell. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 01/04]Create x86 directory to hold x86-specific files.
Yang, Sheng wrote: On Sunday 27 July 2008 17:46:26 Zhang, Xiantao wrote: Avi Kivity wrote: Zhang, Xiantao wrote: From c8c8c5a6b3ff943cb645f9ac4ef169490f14cd08 Mon Sep 17 00:00:00 2001 From: Zhang Xiantao [EMAIL PROTECTED] Date: Fri, 25 Jul 2008 16:50:30 +0800 Subject: [PATCH] KVM: external module: Moving x86-speicif files to x86 directory. Create x86 directory to hold x86-specific files. Signed-off-by: Zhang Xiantao [EMAIL PROTECTED] You forgot to attach a patch; and your mailer corrupts patches, so I can't apply this. Sorry. Attached! :) This broke kvm script in kvm-userspace. We need a update of it... Why break kvm scripts ? xiantao -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] KVM: Fix exiting from HLT emulation with MP_STATE_HALTED
On Wednesday 30 July 2008 21:55:19 Yang, Sheng wrote: From 8019bdd0c7e2933a4d6f7e046d1cc2ded221784e Mon Sep 17 00:00:00 2001 From: Sheng Yang [EMAIL PROTECTED] Date: Wed, 30 Jul 2008 21:45:58 +0800 Subject: [PATCH] KVM: Fix exiting from HLT emulation with MP_STATE_HALTED Recall this patch, would update it soon. -- regards Yang, Sheng -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[ kvm-Bugs-2025527 ] kvm-71 crash (oops) in kvm_mmu_slot_remove_write_access
Bugs item #2025527, was opened at 2008-07-23 09:39 Message generated for change (Comment added) made by jlokier You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=893831aid=2025527group_id=180599 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: kernel Group: None Status: Open Resolution: None Priority: 7 Private: No Submitted By: Daniel van Vugt (danv) Assigned to: Nobody/Anonymous (nobody) Summary: kvm-71 crash (oops) in kvm_mmu_slot_remove_write_access Initial Comment: This seems to be happening regularly with kvm-71 so I have downgraded to kvm-70. So far so good... I'm running Ubuntu 8.04.1 desktop amd64 2.6.24-19-generic #1 SMP. [84184.614760] Unable to handle kernel paging request at 00100100 RIP: [84184.614765] [88c67545] :kvm:kvm_mmu_slot_remove_write_access+0x55/0x70 [84184.614784] PGD 3b98d067 PUD 5da31067 PMD 0 [84184.614788] Oops: [1] SMP [84184.614790] CPU 2 [84184.614792] Modules linked in: nls_iso8859_1 nls_cp437 vfat fat kvm_intel kvm binfmt_misc rfcomm l2cap bluetooth ppdev acpi_cpufreq cpufreq_userspace cpufreq_ondemand cpufreq_stats cpufreq_conservative freq_table cpufreq_powersave dock video output container sbs sbshc battery ipv6 xt_limit xt_tcpudp ipt_LOG ipt_MASQUERADE ipt_TOS ipt_REJECT nf_conntrack_irc nf_conntrack_ftp ac xt_state lp snd_hda_intel snd_pcm_oss snd_mixer_oss snd_pcm snd_page_alloc snd_hwdep snd_seq_dummy snd_seq_oss snd_seq_midi snd_rawmidi nvidia(P) usb_storage snd_seq_midi_event libusual sky2 i2c_core iTCO_wdt snd_seq iTCO_vendor_support snd_timer snd_seq_device parport_pc snd parport shpchp evdev pcspkr intel_agp pci_hotplug button soundcore iptable_nat nf_nat nf_conntrack_ipv4 nf_conntrack iptable_mangle iptable_filter ip_tables x_tables usbhid hid ext3 jbd mbcache sg sr_mod sd_mod cdrom pata_acpi ehci_hcd uhci_hcd ata_piix ata_generic libata scsi_mod usbcore thermal processor fan fbcon tileblit font bitblit softcursor fuse [84184.614855] Pid: 6868, comm: qemu Tainted: P2.6.24-19-generic #1 [84184.614857] RIP: 0010:[88c67545] [88c67545] :kvm:kvm_mmu_slot_remove_write_access+0x55/0x70 [84184.614867] RSP: 0018:81003bbefe20 EFLAGS: 00010246 [84184.614869] RAX: RBX: 81001addc000 RCX: [84184.614871] RDX: 00100100 RSI: 0005 RDI: 81001addeaf0 [84184.614873] RBP: 81003bbefe88 R08: ec8fdb30 R09: 00100100 [84184.614875] R10: R11: 0001 R12: [84184.614877] R13: 81001addc020 R14: 4010ae42 R15: [84184.614879] FS: 7f80e48e56e0() GS:81007dc01a00() knlGS: [84184.614882] CS: 0010 DS: ES: CR0: 8005003b [84184.614884] CR2: 00100100 CR3: 3bad3000 CR4: 26e0 [84184.614885] DR0: DR1: DR2: [84184.614888] DR3: DR6: 0ff0 DR7: 0400 [84184.614890] Process qemu (pid: 6868, threadinfo 81003bbee000, task 81005d910fc0) [84184.614892] Stack: 88c630f2 000e 0001fffe 0001 [84184.614897] 81001addc000 81003bbefe88 4010ae42 0005 [84184.614900] 88c60771 810001022598 8062b540 0082 [84184.614904] Call Trace: [84184.614912] [88c630f2] :kvm:kvm_vm_ioctl_get_dirty_log+0x82/0xc0 [84184.614926] [88c60771] :kvm:kvm_vm_ioctl+0xd1/0x200 [84184.614934] [80256e0e] hrtimer_start+0xee/0x170 [84184.614941] [80233e20] default_wake_function+0x0/0x10 [84184.614948] [802c070f] do_ioctl+0x2f/0xa0 [84184.614953] [802c09a0] vfs_ioctl+0x220/0x2c0 [84184.614957] [802b32fd] vfs_read+0xed/0x190 [84184.614963] [802c0ad1] sys_ioctl+0x91/0xb0 [84184.614971] [8020c37e] system_call+0x7e/0x83 [84184.614981] [84184.614982] [84184.614982] Code: 49 8b 11 49 39 f9 0f 18 0a 75 b9 f3 c3 66 66 66 66 66 2e 0f [84184.614991] RIP [88c67545] :kvm:kvm_mmu_slot_remove_write_access+0x55/0x70 [84184.615000] RSP 81003bbefe20 [84184.615002] CR2: 00100100 [84184.615005] ---[ end trace dbc91eb222360215 ]--- -- Comment By: Jamie Lokier (jlokier) Date: 2008-07-31 06:16 Message: Logged In: YES user_id=1233069 Originator: NO I'm using kvm-69 and I've just had a similar crash... -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=893831aid=2025527group_id=180599 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at
[ kvm-Bugs-2001452 ] Restarted Windows 2003 Server guests have disk corruption
Bugs item #2001452, was opened at 2008-06-24 06:27 Message generated for change (Comment added) made by jlokier You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=893831aid=2001452group_id=180599 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: intel Group: None Status: Open Resolution: None Priority: 7 Private: No Submitted By: gwachs (gerdwachs) Assigned to: Nobody/Anonymous (nobody) Summary: Restarted Windows 2003 Server guests have disk corruption Initial Comment: I have a number of Windows 2003 32Bit guests. I use them to perform installation and configuration tests of a large software product. During these tests, the guests are restarted. Randomly, the guests produce disk corruption messages after a restart. The following are two examples : --- Windows Registry Hive Recovered Registry hive (file): SOFTWARE was corrupted and it has been recovered. Some data might have been lost. --- The system cannot log on due to the following error: Unable to complete the requested operation because of either a catastrophic media failure or a data structure corruption on the disk. --- OS : Ubuntu 8.04 x86_64 Kernel : 2.6.24-18-server #1 SMP x86_64 GNU/Linux KVM: kvm-70 CPU: Intel(R) Core(TM)2 Quad CPU @ 2.40GHz flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good pni monitor ds_cpl vmx est tm2 ssse3 cx16 xt Start Command : sudo /usr/local/kvm/bin/qemu-system-x86_64 -hda asit51ascs.img \ -m 1024 -std-vga -boot c -k sv -usb -usbdevice tablet -snapshot -vnc :51 \ -net nic,vlan=0,macaddr=00:16:3e:00:51:00 -net tap,vlan=0,script=/etc/qemu-ifup-br0 \ -net nic,vlan=1,macaddr=00:16:3e:00:51:01 -net tap,vlan=1,script=/etc/qemu-ifup-br1 no-kvm : Cannot do due to the loss of performance. Tests execute time is 7 hours with kvm. -- Comment By: Jamie Lokier (jlokier) Date: 2008-07-31 06:19 Message: Logged In: YES user_id=1233069 Originator: NO Did you start with the Windows Server 2003 image which is available free from Microsoft, and convert it to qcow2 using 'qemu-img convert'? That conversion is known to be buggy. -- Comment By: gwachs (gerdwachs) Date: 2008-07-17 08:39 Message: Logged In: YES user_id=2122332 Originator: YES I use qcow2 The host disk format is xfs I do not have access to the computers until Aug 10th so I cannot test the raw format until them. -- Comment By: Avi Kivity (avik) Date: 2008-07-16 15:23 Message: Logged In: YES user_id=539971 Originator: NO What disk format are you using? Does switching to raw format help? -- Comment By: gwachs (gerdwachs) Date: 2008-07-10 06:10 Message: Logged In: YES user_id=2122332 Originator: YES Regarding using daily builds. From Build 20080707, my existing guests would not start. Have rebuilt one guest using 20080708. Seems OK but need to be running more guests for longer time to be sure. I will not have access to the environment from July 12 to Aug 10 -- Comment By: gwachs (gerdwachs) Date: 2008-06-30 12:27 Message: Logged In: YES user_id=2122332 Originator: YES Sorry, I am not that advanced on the usage of git. If you would care to send instructions, I will try. I am currently using the latest snapshots. It appears to be working enough to for my requirements, but I have still been getting the odd corruption message. P.S. I believe that kvm is an absolute winning concept. -- Comment By: Brian Jackson (iggy_cav) Date: 2008-06-27 15:09 Message: Logged In: YES user_id=611130 Originator: NO For some reason, I thought a virtio patch would help you, when you obviously aren't using that with windows guests. It could still be something with the i/o thread though. Is there any way you can do a git bisect to figure out where exactly it breaks? I know it's hard to do something like that when it takes so long to trigger the issue. It may be our only option though. kvm-69 doesn't have the i/o thread (I think), so it should be safe to use if you just need something that works. -- Comment By: gwachs (gerdwachs) Date: 2008-06-27 11:44 Message: Logged In: YES
[ kvm-Bugs-2025527 ] kvm-71 crash (oops) in kvm_mmu_slot_remove_write_access
Bugs item #2025527, was opened at 2008-07-23 09:39 Message generated for change (Comment added) made by jlokier You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=893831aid=2025527group_id=180599 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: kernel Group: None Status: Open Resolution: None Priority: 7 Private: No Submitted By: Daniel van Vugt (danv) Assigned to: Nobody/Anonymous (nobody) Summary: kvm-71 crash (oops) in kvm_mmu_slot_remove_write_access Initial Comment: This seems to be happening regularly with kvm-71 so I have downgraded to kvm-70. So far so good... I'm running Ubuntu 8.04.1 desktop amd64 2.6.24-19-generic #1 SMP. [84184.614760] Unable to handle kernel paging request at 00100100 RIP: [84184.614765] [88c67545] :kvm:kvm_mmu_slot_remove_write_access+0x55/0x70 [84184.614784] PGD 3b98d067 PUD 5da31067 PMD 0 [84184.614788] Oops: [1] SMP [84184.614790] CPU 2 [84184.614792] Modules linked in: nls_iso8859_1 nls_cp437 vfat fat kvm_intel kvm binfmt_misc rfcomm l2cap bluetooth ppdev acpi_cpufreq cpufreq_userspace cpufreq_ondemand cpufreq_stats cpufreq_conservative freq_table cpufreq_powersave dock video output container sbs sbshc battery ipv6 xt_limit xt_tcpudp ipt_LOG ipt_MASQUERADE ipt_TOS ipt_REJECT nf_conntrack_irc nf_conntrack_ftp ac xt_state lp snd_hda_intel snd_pcm_oss snd_mixer_oss snd_pcm snd_page_alloc snd_hwdep snd_seq_dummy snd_seq_oss snd_seq_midi snd_rawmidi nvidia(P) usb_storage snd_seq_midi_event libusual sky2 i2c_core iTCO_wdt snd_seq iTCO_vendor_support snd_timer snd_seq_device parport_pc snd parport shpchp evdev pcspkr intel_agp pci_hotplug button soundcore iptable_nat nf_nat nf_conntrack_ipv4 nf_conntrack iptable_mangle iptable_filter ip_tables x_tables usbhid hid ext3 jbd mbcache sg sr_mod sd_mod cdrom pata_acpi ehci_hcd uhci_hcd ata_piix ata_generic libata scsi_mod usbcore thermal processor fan fbcon tileblit font bitblit softcursor fuse [84184.614855] Pid: 6868, comm: qemu Tainted: P2.6.24-19-generic #1 [84184.614857] RIP: 0010:[88c67545] [88c67545] :kvm:kvm_mmu_slot_remove_write_access+0x55/0x70 [84184.614867] RSP: 0018:81003bbefe20 EFLAGS: 00010246 [84184.614869] RAX: RBX: 81001addc000 RCX: [84184.614871] RDX: 00100100 RSI: 0005 RDI: 81001addeaf0 [84184.614873] RBP: 81003bbefe88 R08: ec8fdb30 R09: 00100100 [84184.614875] R10: R11: 0001 R12: [84184.614877] R13: 81001addc020 R14: 4010ae42 R15: [84184.614879] FS: 7f80e48e56e0() GS:81007dc01a00() knlGS: [84184.614882] CS: 0010 DS: ES: CR0: 8005003b [84184.614884] CR2: 00100100 CR3: 3bad3000 CR4: 26e0 [84184.614885] DR0: DR1: DR2: [84184.614888] DR3: DR6: 0ff0 DR7: 0400 [84184.614890] Process qemu (pid: 6868, threadinfo 81003bbee000, task 81005d910fc0) [84184.614892] Stack: 88c630f2 000e 0001fffe 0001 [84184.614897] 81001addc000 81003bbefe88 4010ae42 0005 [84184.614900] 88c60771 810001022598 8062b540 0082 [84184.614904] Call Trace: [84184.614912] [88c630f2] :kvm:kvm_vm_ioctl_get_dirty_log+0x82/0xc0 [84184.614926] [88c60771] :kvm:kvm_vm_ioctl+0xd1/0x200 [84184.614934] [80256e0e] hrtimer_start+0xee/0x170 [84184.614941] [80233e20] default_wake_function+0x0/0x10 [84184.614948] [802c070f] do_ioctl+0x2f/0xa0 [84184.614953] [802c09a0] vfs_ioctl+0x220/0x2c0 [84184.614957] [802b32fd] vfs_read+0xed/0x190 [84184.614963] [802c0ad1] sys_ioctl+0x91/0xb0 [84184.614971] [8020c37e] system_call+0x7e/0x83 [84184.614981] [84184.614982] [84184.614982] Code: 49 8b 11 49 39 f9 0f 18 0a 75 b9 f3 c3 66 66 66 66 66 2e 0f [84184.614991] RIP [88c67545] :kvm:kvm_mmu_slot_remove_write_access+0x55/0x70 [84184.615000] RSP 81003bbefe20 [84184.615002] CR2: 00100100 [84184.615005] ---[ end trace dbc91eb222360215 ]--- -- Comment By: Jamie Lokier (jlokier) Date: 2008-07-31 06:28 Message: Logged In: YES user_id=1233069 Originator: NO That is, kvm-69 compiled by me on a _32_-bit host. (I don't have a 64-bit host.) It's quite a nasty crash, too: kernel thinks the VNC port and tap devices are still bound, but the kvm process is stuck and cannot die. So you can't start another kvm on the same VNC port and/or tap device, without rebooting the host Linux. --
[ kvm-Bugs-2025527 ] kvm-71 crash (oops) in kvm_mmu_slot_remove_write_access
Bugs item #2025527, was opened at 2008-07-23 09:39 Message generated for change (Comment added) made by jlokier You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=893831aid=2025527group_id=180599 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: kernel Group: None Status: Open Resolution: None Priority: 7 Private: No Submitted By: Daniel van Vugt (danv) Assigned to: Nobody/Anonymous (nobody) Summary: kvm-71 crash (oops) in kvm_mmu_slot_remove_write_access Initial Comment: This seems to be happening regularly with kvm-71 so I have downgraded to kvm-70. So far so good... I'm running Ubuntu 8.04.1 desktop amd64 2.6.24-19-generic #1 SMP. [84184.614760] Unable to handle kernel paging request at 00100100 RIP: [84184.614765] [88c67545] :kvm:kvm_mmu_slot_remove_write_access+0x55/0x70 [84184.614784] PGD 3b98d067 PUD 5da31067 PMD 0 [84184.614788] Oops: [1] SMP [84184.614790] CPU 2 [84184.614792] Modules linked in: nls_iso8859_1 nls_cp437 vfat fat kvm_intel kvm binfmt_misc rfcomm l2cap bluetooth ppdev acpi_cpufreq cpufreq_userspace cpufreq_ondemand cpufreq_stats cpufreq_conservative freq_table cpufreq_powersave dock video output container sbs sbshc battery ipv6 xt_limit xt_tcpudp ipt_LOG ipt_MASQUERADE ipt_TOS ipt_REJECT nf_conntrack_irc nf_conntrack_ftp ac xt_state lp snd_hda_intel snd_pcm_oss snd_mixer_oss snd_pcm snd_page_alloc snd_hwdep snd_seq_dummy snd_seq_oss snd_seq_midi snd_rawmidi nvidia(P) usb_storage snd_seq_midi_event libusual sky2 i2c_core iTCO_wdt snd_seq iTCO_vendor_support snd_timer snd_seq_device parport_pc snd parport shpchp evdev pcspkr intel_agp pci_hotplug button soundcore iptable_nat nf_nat nf_conntrack_ipv4 nf_conntrack iptable_mangle iptable_filter ip_tables x_tables usbhid hid ext3 jbd mbcache sg sr_mod sd_mod cdrom pata_acpi ehci_hcd uhci_hcd ata_piix ata_generic libata scsi_mod usbcore thermal processor fan fbcon tileblit font bitblit softcursor fuse [84184.614855] Pid: 6868, comm: qemu Tainted: P2.6.24-19-generic #1 [84184.614857] RIP: 0010:[88c67545] [88c67545] :kvm:kvm_mmu_slot_remove_write_access+0x55/0x70 [84184.614867] RSP: 0018:81003bbefe20 EFLAGS: 00010246 [84184.614869] RAX: RBX: 81001addc000 RCX: [84184.614871] RDX: 00100100 RSI: 0005 RDI: 81001addeaf0 [84184.614873] RBP: 81003bbefe88 R08: ec8fdb30 R09: 00100100 [84184.614875] R10: R11: 0001 R12: [84184.614877] R13: 81001addc020 R14: 4010ae42 R15: [84184.614879] FS: 7f80e48e56e0() GS:81007dc01a00() knlGS: [84184.614882] CS: 0010 DS: ES: CR0: 8005003b [84184.614884] CR2: 00100100 CR3: 3bad3000 CR4: 26e0 [84184.614885] DR0: DR1: DR2: [84184.614888] DR3: DR6: 0ff0 DR7: 0400 [84184.614890] Process qemu (pid: 6868, threadinfo 81003bbee000, task 81005d910fc0) [84184.614892] Stack: 88c630f2 000e 0001fffe 0001 [84184.614897] 81001addc000 81003bbefe88 4010ae42 0005 [84184.614900] 88c60771 810001022598 8062b540 0082 [84184.614904] Call Trace: [84184.614912] [88c630f2] :kvm:kvm_vm_ioctl_get_dirty_log+0x82/0xc0 [84184.614926] [88c60771] :kvm:kvm_vm_ioctl+0xd1/0x200 [84184.614934] [80256e0e] hrtimer_start+0xee/0x170 [84184.614941] [80233e20] default_wake_function+0x0/0x10 [84184.614948] [802c070f] do_ioctl+0x2f/0xa0 [84184.614953] [802c09a0] vfs_ioctl+0x220/0x2c0 [84184.614957] [802b32fd] vfs_read+0xed/0x190 [84184.614963] [802c0ad1] sys_ioctl+0x91/0xb0 [84184.614971] [8020c37e] system_call+0x7e/0x83 [84184.614981] [84184.614982] [84184.614982] Code: 49 8b 11 49 39 f9 0f 18 0a 75 b9 f3 c3 66 66 66 66 66 2e 0f [84184.614991] RIP [88c67545] :kvm:kvm_mmu_slot_remove_write_access+0x55/0x70 [84184.615000] RSP 81003bbefe20 [84184.615002] CR2: 00100100 [84184.615005] ---[ end trace dbc91eb222360215 ]--- -- Comment By: Jamie Lokier (jlokier) Date: 2008-07-31 06:29 Message: Logged In: YES user_id=1233069 Originator: NO That is, kvm-69 compiled by me on a _32_-bit host. (I don't have a 64-bit host.) It's quite a nasty crash, too: kernel thinks the VNC port and tap devices are still bound, but the kvm process is stuck and cannot die. So you can't start another kvm on the same VNC port and/or tap device, without rebooting the host Linux. --
[ kvm-Bugs-2025527 ] kvm-71 crash (oops) in kvm_mmu_slot_remove_write_access
Bugs item #2025527, was opened at 2008-07-23 09:39 Message generated for change (Comment added) made by jlokier You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=893831aid=2025527group_id=180599 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: kernel Group: None Status: Open Resolution: None Priority: 7 Private: No Submitted By: Daniel van Vugt (danv) Assigned to: Nobody/Anonymous (nobody) Summary: kvm-71 crash (oops) in kvm_mmu_slot_remove_write_access Initial Comment: This seems to be happening regularly with kvm-71 so I have downgraded to kvm-70. So far so good... I'm running Ubuntu 8.04.1 desktop amd64 2.6.24-19-generic #1 SMP. [84184.614760] Unable to handle kernel paging request at 00100100 RIP: [84184.614765] [88c67545] :kvm:kvm_mmu_slot_remove_write_access+0x55/0x70 [84184.614784] PGD 3b98d067 PUD 5da31067 PMD 0 [84184.614788] Oops: [1] SMP [84184.614790] CPU 2 [84184.614792] Modules linked in: nls_iso8859_1 nls_cp437 vfat fat kvm_intel kvm binfmt_misc rfcomm l2cap bluetooth ppdev acpi_cpufreq cpufreq_userspace cpufreq_ondemand cpufreq_stats cpufreq_conservative freq_table cpufreq_powersave dock video output container sbs sbshc battery ipv6 xt_limit xt_tcpudp ipt_LOG ipt_MASQUERADE ipt_TOS ipt_REJECT nf_conntrack_irc nf_conntrack_ftp ac xt_state lp snd_hda_intel snd_pcm_oss snd_mixer_oss snd_pcm snd_page_alloc snd_hwdep snd_seq_dummy snd_seq_oss snd_seq_midi snd_rawmidi nvidia(P) usb_storage snd_seq_midi_event libusual sky2 i2c_core iTCO_wdt snd_seq iTCO_vendor_support snd_timer snd_seq_device parport_pc snd parport shpchp evdev pcspkr intel_agp pci_hotplug button soundcore iptable_nat nf_nat nf_conntrack_ipv4 nf_conntrack iptable_mangle iptable_filter ip_tables x_tables usbhid hid ext3 jbd mbcache sg sr_mod sd_mod cdrom pata_acpi ehci_hcd uhci_hcd ata_piix ata_generic libata scsi_mod usbcore thermal processor fan fbcon tileblit font bitblit softcursor fuse [84184.614855] Pid: 6868, comm: qemu Tainted: P2.6.24-19-generic #1 [84184.614857] RIP: 0010:[88c67545] [88c67545] :kvm:kvm_mmu_slot_remove_write_access+0x55/0x70 [84184.614867] RSP: 0018:81003bbefe20 EFLAGS: 00010246 [84184.614869] RAX: RBX: 81001addc000 RCX: [84184.614871] RDX: 00100100 RSI: 0005 RDI: 81001addeaf0 [84184.614873] RBP: 81003bbefe88 R08: ec8fdb30 R09: 00100100 [84184.614875] R10: R11: 0001 R12: [84184.614877] R13: 81001addc020 R14: 4010ae42 R15: [84184.614879] FS: 7f80e48e56e0() GS:81007dc01a00() knlGS: [84184.614882] CS: 0010 DS: ES: CR0: 8005003b [84184.614884] CR2: 00100100 CR3: 3bad3000 CR4: 26e0 [84184.614885] DR0: DR1: DR2: [84184.614888] DR3: DR6: 0ff0 DR7: 0400 [84184.614890] Process qemu (pid: 6868, threadinfo 81003bbee000, task 81005d910fc0) [84184.614892] Stack: 88c630f2 000e 0001fffe 0001 [84184.614897] 81001addc000 81003bbefe88 4010ae42 0005 [84184.614900] 88c60771 810001022598 8062b540 0082 [84184.614904] Call Trace: [84184.614912] [88c630f2] :kvm:kvm_vm_ioctl_get_dirty_log+0x82/0xc0 [84184.614926] [88c60771] :kvm:kvm_vm_ioctl+0xd1/0x200 [84184.614934] [80256e0e] hrtimer_start+0xee/0x170 [84184.614941] [80233e20] default_wake_function+0x0/0x10 [84184.614948] [802c070f] do_ioctl+0x2f/0xa0 [84184.614953] [802c09a0] vfs_ioctl+0x220/0x2c0 [84184.614957] [802b32fd] vfs_read+0xed/0x190 [84184.614963] [802c0ad1] sys_ioctl+0x91/0xb0 [84184.614971] [8020c37e] system_call+0x7e/0x83 [84184.614981] [84184.614982] [84184.614982] Code: 49 8b 11 49 39 f9 0f 18 0a 75 b9 f3 c3 66 66 66 66 66 2e 0f [84184.614991] RIP [88c67545] :kvm:kvm_mmu_slot_remove_write_access+0x55/0x70 [84184.615000] RSP 81003bbefe20 [84184.615002] CR2: 00100100 [84184.615005] ---[ end trace dbc91eb222360215 ]--- -- Comment By: Jamie Lokier (jlokier) Date: 2008-07-31 06:36 Message: Logged In: YES user_id=1233069 Originator: NO Actually, I'm running kvm-69 userspace, but whatever version of the kernel modules comes with Ubuntu's linux-image-2.6.24-19.21 package (current in Ubuntu 8.04 at this time). I don't know what the version of those modules is, but the userspace which accompanies Ubuntu 8.04 is kvm-62, so that might be the kernel module version (or approximately) too. So this crash might be quite an old bug in the
[PATCH] KVM: Fix QEmu interrupted HLT emulation
From: Sheng Yang [EMAIL PROTECTED]
Date: Thu, 31 Jul 2008 13:43:58 +0800
Subject: [PATCH] KVM: Fix QEmu interrupted HLT emulation
QEmu can interrupt VCPU from HLT emulation without setting mp_state to
MP_STATE_RUNNABLE, when it kick vcpus which are doing HLT emulation to
do something like stop or info cpus. Here are two issues of this
behaviour:
First, if vcpu exit to QEmu with MP_STATE_HALTED, it would keep in
this state later for vcpu_run(), which is eerie...
Second, a practical problem: bios load AP boot up code to 0x1
(now), and AP is running HLT there. But later grub load it's stage2
code to the same address. Then if the halting vcpu was forced exit to
QEmu in grub, and come back for vcpu_run later, it can't execute HLT
instruction anymore, just because the bios code is not there,
and it would follow a piece of code of grub, which would cause
completely chaos...
The second issue directly lead to guest crash or SMP linux can't boot
up AP later if we stop or info cpus in grub. Though I also sent a
patch for BIOS, it's necessary to get correct behavior here.
The patch resumes the HLT emulation after interrupt by QEmu to fix it.
Signed-off-by: Sheng Yang [EMAIL PROTECTED]
---
arch/x86/kvm/x86.c | 14 ++
1 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 94a2165..8219074 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -2881,6 +2881,19 @@ again:
clear_bit(KVM_REQ_PENDING_TIMER, vcpu-requests);
kvm_inject_pending_timer_irqs(vcpu);
+ /*
+* If HLT emulating was interrupted by QEmu, we'd better resume it.
+* And if QEmu don't interrupt it again, set correct state rather
than
+* keeping running with STATE_HALTED
+*/
+ if (vcpu-arch.mp_state == KVM_MP_STATE_HALTED) {
+ r = kvm_emulate_halt(vcpu);
+ if (!signal_pending(current)
+ !kvm_arch_vcpu_runnable(vcpu))
+ vcpu-arch.mp_state = KVM_MP_STATE_RUNNABLE;
+ goto next_round;
+ }
+
preempt_disable();
kvm_x86_ops-prepare_guest_switch(vcpu);
@@ -2962,6 +2975,7 @@ again:
r = kvm_x86_ops-handle_exit(kvm_run, vcpu);
+next_round:
if (r 0) {
if (dm_request_for_irq_injection(vcpu, kvm_run)) {
r = -EINTR;
--
1.5.4.5
From ea0a1f70d44590929c9d618ee4bef8af1553b442 Mon Sep 17 00:00:00 2001
From: Sheng Yang [EMAIL PROTECTED]
Date: Thu, 31 Jul 2008 13:43:58 +0800
Subject: [PATCH] KVM: Fix QEmu interrupted HLT emulation
QEmu can interrupt VCPU from HLT emulation without setting mp_state to
MP_STATE_RUNNABLE, when it kick vcpus which are doing HLT emulation to do
something like stop or info cpus. Here are two issues of this behaviour:
First, if vcpu exit to QEmu with MP_STATE_HALTED, it would keep in this state
later for vcpu_run(), which is eerie...
Second, a practical problem: bios load AP boot up code to 0x1 (now), and AP is
running HLT there. But later grub load it's stage2 code to the same address. Then
if the halting vcpu was forced exit to QEmu in grub, and come back for vcpu_run later,
it can't execute HLT instruction anymore, just because the bios code is not there,
and it would follow a piece of code of grub, which would cause completely chaos...
The second issue directly lead to guest crash or SMP linux can't boot up AP
later if we stop or info cpus in grub. Though I also sent a patch for BIOS,
it's necessary to get correct behavior here.
The patch resumes the HLT emulation after interrupt by QEmu to fix it.
Signed-off-by: Sheng Yang [EMAIL PROTECTED]
---
arch/x86/kvm/x86.c | 14 ++
1 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 94a2165..8219074 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -2881,6 +2881,19 @@ again:
clear_bit(KVM_REQ_PENDING_TIMER, vcpu-requests);
kvm_inject_pending_timer_irqs(vcpu);
+ /*
+ * If HLT emulating was interrupted by QEmu, we'd better resume it.
+ * And if QEmu don't interrupt it again, set correct state rather than
+ * keeping running with STATE_HALTED
+ */
+ if (vcpu-arch.mp_state == KVM_MP_STATE_HALTED) {
+ r = kvm_emulate_halt(vcpu);
+ if (!signal_pending(current)
+ !kvm_arch_vcpu_runnable(vcpu))
+ vcpu-arch.mp_state = KVM_MP_STATE_RUNNABLE;
+ goto next_round;
+ }
+
preempt_disable();
kvm_x86_ops-prepare_guest_switch(vcpu);
@@ -2962,6 +2975,7 @@ again:
r = kvm_x86_ops-handle_exit(kvm_run, vcpu);
+next_round:
if (r 0) {
if (dm_request_for_irq_injection(vcpu, kvm_run)) {
r = -EINTR;
--
1.5.4.5
