Re: Mouse motion lags
Antoine Martin wrote: > I've noticed what I believe to be the same bug: when moving the mouse > around the vnc viewer, the guest does not seem to follow the same > acceleration and I end up with 2 pointers completely out of sync. If the guest is Windows, turn off "Enhance pointer precision" under Control Panel->Mouse->Pointer Options. I found this to make the pointers move at the same rate. -- 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 1/2] KVM: Fix INTx for device assignment
Missing buckets and wrong parameter for free_irq()
Signed-off-by: Sheng Yang
---
virt/kvm/kvm_main.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index 7a102d7..213bb91 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -296,8 +296,8 @@ static int assigned_device_update_intx(struct kvm *kvm,
if (irqchip_in_kernel(kvm)) {
if (!msi2intx &&
- adev->irq_requested_type & KVM_ASSIGNED_DEV_HOST_MSI) {
- free_irq(adev->host_irq, (void *)kvm);
+ (adev->irq_requested_type & KVM_ASSIGNED_DEV_HOST_MSI)) {
+ free_irq(adev->host_irq, (void *)adev);
pci_disable_msi(adev->dev);
}
--
1.5.4.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
[PATCH 2/2] KVM: Add support to disable MSI for assigned device
MSI is always enabled by default for msi2intx=1. But if msi2intx=0, we
have to disable MSI if guest require to do so.
The patch also discard unnecessary msi2intx judgment if guest want to update
MSI state.
Notice KVM_DEV_IRQ_ASSIGN_MSI_ACTION is a mask which should cover all MSI
related operations, though we only got one for now.
Signed-off-by: Sheng Yang
---
include/linux/kvm.h |1 +
virt/kvm/kvm_main.c | 18 --
2 files changed, 17 insertions(+), 2 deletions(-)
diff --git a/include/linux/kvm.h b/include/linux/kvm.h
index 4ec359e..71c150f 100644
--- a/include/linux/kvm.h
+++ b/include/linux/kvm.h
@@ -550,6 +550,7 @@ struct kvm_assigned_irq {
#define KVM_DEV_ASSIGN_ENABLE_IOMMU(1 << 0)
+#define KVM_DEV_IRQ_ASSIGN_MSI_ACTION KVM_DEV_IRQ_ASSIGN_ENABLE_MSI
#define KVM_DEV_IRQ_ASSIGN_ENABLE_MSI (1 << 0)
#endif
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index 213bb91..dcbfc68 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -343,6 +343,14 @@ static int assigned_device_update_msi(struct kvm *kvm,
adev->irq_requested_type &= ~KVM_ASSIGNED_DEV_GUEST_MSI;
adev->guest_irq = airq->guest_irq;
adev->ack_notifier.gsi = airq->guest_irq;
+ } else {
+ /*
+* Guest require to disable device MSI, we disable MSI and
+* re-enable INTx by default again. Notice it's only for
+* non-msi2intx.
+*/
+ assigned_device_update_intx(kvm, adev, airq);
+ return 0;
}
if (adev->irq_requested_type & KVM_ASSIGNED_DEV_HOST_MSI)
@@ -379,6 +387,7 @@ static int kvm_vm_ioctl_assign_irq(struct kvm *kvm,
{
int r = 0;
struct kvm_assigned_dev_kernel *match;
+ u32 current_flags = 0, changed_flags;
mutex_lock(&kvm->lock);
@@ -416,8 +425,13 @@ static int kvm_vm_ioctl_assign_irq(struct kvm *kvm,
}
}
- if ((!msi2intx &&
-(assigned_irq->flags & KVM_DEV_IRQ_ASSIGN_ENABLE_MSI)) ||
+ if ((match->irq_requested_type & KVM_ASSIGNED_DEV_HOST_MSI) &&
+(match->irq_requested_type & KVM_ASSIGNED_DEV_GUEST_MSI))
+ current_flags |= KVM_DEV_IRQ_ASSIGN_ENABLE_MSI;
+
+ changed_flags = assigned_irq->flags ^ current_flags;
+
+ if ((changed_flags & KVM_DEV_IRQ_ASSIGN_MSI_ACTION) ||
(msi2intx && match->dev->msi_enabled)) {
#ifdef CONFIG_X86
r = assigned_device_update_msi(kvm, match, assigned_irq);
--
1.5.4.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
[PATCH 00/02][v2] Support for disable MSI
Change from v2: Discard first two patches, instead fix bugs in update_intx(). Finally, I purpose to use kvm_free_assigned_irq(), but before that, I think I have to split kvm->lock due to cancel_work_sync() implicit need kvm->lock. So leave it a little later. -- include/linux/kvm.h |1 + virt/kvm/kvm_main.c | 22 ++ 2 files changed, 19 insertions(+), 4 deletions(-) -- regards Yang, Sheng -- 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] KVM: Reset PIT irq injection logic when the PIT IRQ is unmasked
Marcelo Tosatti wrote: I'm worried about: - boot guest using local apic timer - reset - boot with pit timer - a zillion interrupts So at the very least, we need a limiter. Or have a new notifier on kvm_pic_reset, instead of simply acking one pending irq? That seems the appropriate place to zero the counter. Clearing the counter on reset is good, but it doesn't solve the underlying problem, which is that there are two separate cases that appear to the host as the same thing: - guest masks irqs, does a lot of work, unmasks irqs - host deschedules guest, does a lot of work, reschedules guest Right now we assume any missed interrupts are due to host load. In the reboot case, that's clearly wrong, but that is only an example. Maybe we can use preempt notifiers to detect whether the timer tick happened while the guest was scheduled or not. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain. -- 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/3][v2] Fix racy in kvm_free_assigned_irq
Sheng Yang wrote: Hi Avi I just add a comment for kvm_free_assigned_irq(). The other things are all the same as the patchset you have reviewed. Applied, thanks. -- 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/02][v2] Support for disable MSI
Sheng Yang wrote: Change from v2: Discard first two patches, instead fix bugs in update_intx(). Finally, I purpose to use kvm_free_assigned_irq(), but before that, I think I have to split kvm->lock due to cancel_work_sync() implicit need kvm->lock. So leave it a little later. Applied, thanks. -- 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Add microcode patch level dummy
Alexander Graf wrote: VMware ESX checks if the microcode level is correct when using a barcelona CPU, in order to see if it actually can use SVM. Let's tell it we're on the safe side... Applied, thanks. -- 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] KVM: Reset PIT irq injection logic when the PIT IRQ is unmasked
Avi Kivity wrote: Marcelo Tosatti wrote: I'm worried about: - boot guest using local apic timer - reset - boot with pit timer - a zillion interrupts So at the very least, we need a limiter. Or have a new notifier on kvm_pic_reset, instead of simply acking one pending irq? That seems the appropriate place to zero the counter. Clearing the counter on reset is good, but it doesn't solve the underlying problem, which is that there are two separate cases that appear to the host as the same thing: - guest masks irqs, does a lot of work, unmasks irqs - host deschedules guest, does a lot of work, reschedules guest Right now we assume any missed interrupts are due to host load. In the reboot case, that's clearly wrong, but that is only an example. Maybe we can use preempt notifiers to detect whether the timer tick happened while the guest was scheduled or not. It might get too complex. It can be done inside the vcpu_run function too: An irq needs reinjection if the irq window was not open from the timer tick till the next timer tick minus the deschedule time. You also need to know on the right vcpu that the pit irq it routed to. Since scenarios like guests masking their pit and do a lot of work are rare and a bad guest behaviour anyway, I don't think we should special case them. So the pit reset hook is enough. -- 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 fail to compile with CONFIG_DMAR=y
On Tue, 2009-01-06 at 09:29 +0800, Xu, Jiajun wrote: > Hi, > We found against latest kvm commit, > 2c775aece4cb3a05aa5dc8b9966b39a959252dcd, kvm failed to compile with > CONFIG_DMAR=y. > > The error is like following: > > [r...@kvm-build kernel]# make > rm -f include/asm include-compat/asm > ln -sf asm-x86 include/asm > ln -sf asm-x86 include-compat/asm > make -j20 -C /lib/modules/2.6.28-rc6/build M=`pwd` \ > LINUXINCLUDE="-I`pwd`/include -Iinclude \ > \ > -Iarch/x86/include -I`pwd`/include-compat \ > -include include/linux/autoconf.h \ > -include `pwd`/x86/external-module-compat.h " > make[1]: Entering directory > `/mnt/sdb1/kernel/src/redhat/BUILD/kernel-2.6.28rc6' > make[3]: *** No rule to make target > `/workspace/ia32e/nightly/kvm-master-2.6.28-rc6-20090105091035882/kvm-userspace/kernel/x86/vtd.o', > needed by > `/workspace/ia32e/nightly/kvm-master-2.6.28-rc6-20090105091035882/kvm-userspace/kernel/x86/kvm.o'. > Stop. > make[2]: *** > [/workspace/ia32e/nightly/kvm-master-2.6.28-rc6-20090105091035882/kvm-userspace/kernel/x86] > Error 2 > make[1]: *** > [_module_/workspace/ia32e/nightly/kvm-master-2.6.28-rc6-20090105091035882/kvm-userspace/kernel] > Error 2 > make[1]: Leaving directory > `/mnt/sdb1/kernel/src/redhat/BUILD/kernel-2.6.28rc6' > make: *** [all] Error 2 > > My host kernel is 2.6.28-rc6. After setting CONFIG_DMAR=n, kvm compile > is OK. So does anyone know how to enable VT-d in latest kvm? This is because virt/kvm/vt-d.c was renamed to virt/kvm/iommu.c Try manually deleting the stale copy of vt-d.c and re-running make. Cheers, Mark. -- 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
[ kvm-Bugs-1872255 ] cygwin not working inside 64-bit guest
Bugs item #1872255, was opened at 2008-01-15 17:24 Message generated for change (Comment added) made by gringostarr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1872255&group_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: libkvm Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Olivier Paquet (euzeka) Assigned to: Nobody/Anonymous (nobody) Summary: cygwin not working inside 64-bit guest Initial Comment: I installed cygwin on Windows XP x64 inside kvm-59 and it crashes randomly. The easiest way to reproduce it is by simply starting and quitting a few bash shells: --- C:\cygwin\bin>Cygwin.bat C:\cygwin\bin>bash bash-3.2$ bash bash-3.2$ bash bash-3.2$ exit exit 10551 [main] bash 1488 sig_send: wait for sig_complete event failed, signal -34, rc -1, Win32 error 6 Segmentation fault bash-3.2$ exit exit 87 [main] bash 1592 sig_send: wait for sig_complete event failed, signal -34, rc -1, Win32 error 6 Segmentation fault bash-3.2$ exit exit C:\cygwin\bin> --- But it also happens with other programs so it seems to be something related to their weird fork implementation. With kvm disabled (with kvm-56 as it won't boot anymore with 59), cygwin works fine. Host is a Core 2 Duo with slackware 11 and kernel 2.6.21.1. Running with: qemu-system-x86_64 -hda wintest.img -smp 1 -localtime -net nic,model=rtl8139 -net tap,ifname=tap0,script=no -m 512 -- Comment By: Jamie Kirkpatrick (gringostarr) Date: 2009-01-06 10:12 Message: I have found the same problem in every version of KVM I have used including the current KVM-81 release. I've found that this is a known bug in not only KVM, but also in Xen. I posted about it here: http://thread.gmane.org/gmane.comp.emulators.kvm.devel/27003. There are a couple of links of interest in that post that detail the issue further. There also seem to be two issues here: one which is noted above, and another which causes a segfault if you use Cygwin bash's builtin test call ( if [[ 1 ]] then ... fi ). Doing this causes a segfault every time. People who have investigated this bug further from Cygwin's side have found that doing a block-by-block copy of the guest OS to a physical box makes the problem go away and it was agreed that it was definitely down to Xen in the posts I've read. Clearly KVM suffers too. Host: Linux kvm-host 2.6.27-rc9-amd64 #1 SMP Fri Oct 10 11:07:08 UTC 2008 x86_64 GNU/Linux CPU: Intel(R) Core(TM)2 Quad CPUQ6600 @ 2.40GHz Command: /usr/bin/kvm -name windows-dev -smp 4 -m 4096 -daemonize -vnc :1 -usb -usbdevice tablet -net nic,macaddr=00:16:3e:00:00:1,model=e1000 -net tap,ifname=tap1 -pidfile /var/run/kvm/windows-dev.pid -boot c -drive index=0,media=disk,if=ide,file=/dev/kvm-host/windows-dev -drive index=2,media=cdrom,if=ide,file=/home/jkp/NETKVM-20081229.iso -k en-us -monitor telnet:127.0.0.1:4001,server,nowait -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1872255&group_id=180599 -- 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] KVM: MMU: Segregate mmu pages created with different cr4.pge settings
Alexander Graf wrote:
Avi Kivity wrote:
From: Avi Kivity
Don't allow a vcpu with cr4.pge cleared to use a shadow page created with
cr4.pge set; this might cause a cr3 switch not to sync ptes that have the
global bit set (the global bit has no effect if !cr4.pge).
This can only occur on smp with different cr4.pge settings for different
vcpus (since a cr4 change will resync the shadow ptes), but there's no
cost to being correct here.
Signed-off-by: Avi Kivity
diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index f49bfd0..ab8ef1d 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -183,6 +183,7 @@ union kvm_mmu_page_role {
unsigned metaphysical:1;
unsigned access:3;
unsigned invalid:1;
+ unsigned cr4_pge:1;
};
};
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index c4da7fb..aa4575c 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -363,6 +363,7 @@ void kvm_set_cr4(struct kvm_vcpu *vcpu, unsigned long cr4)
}
kvm_x86_ops->set_cr4(vcpu, cr4);
vcpu->arch.cr4 = cr4;
+ vcpu->arch.mmu.base_role.cr4_pge = !!(cr4 & X86_CR4_PGE);
This line broke VMware ESX bootup using NPT on one VCPU for me. If I
comment it out and apply my patches to actually make ESX run, it boots
again.
I think this might be the problem:
static int mmu_need_write_protect(struct kvm_vcpu *vcpu, gfn_t gfn,
bool can_unsync)
{
struct kvm_mmu_page *shadow;
shadow = kvm_mmu_lookup_page(vcpu->kvm, gfn);
if (shadow) {
if (shadow->role.level != PT_PAGE_TABLE_LEVEL)
return 1;
if (shadow->unsync)
return 0;
if (can_unsync && oos_shadow)
return kvm_unsync_page(vcpu, shadow);
return 1;
}
return 0;
}
lookup_page() is not deterministic if there are multiple shadows for a
page, and the patch increases multiple shadows.
Marcelo, shouldn't there be a for_each in there?
--
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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[ kvm-Bugs-2482759 ] Windows SCSI errors
Bugs item #2482759, was opened at 2009-01-02 21:03 Message generated for change (Comment added) made by aketzu You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=893831&aid=2482759&group_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: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Ryan Bair (ryandbair) Assigned to: Nobody/Anonymous (nobody) Summary: Windows SCSI errors Initial Comment: When starting up a fresh install of Windows Server 2003 R2 x64, I get errors similar to the following... scsi-disk: Command: lun=0 tag=0x0 data=0x12 0x01 0x00 0x00 0xff 0x00 scsi-disk: Inquiry (len 255) scsi-disk: Inquiry EVPD[Supported pages] buffer size 255 scsi-disk: Read buf_len=7 scsi-disk: Read sector_count=0 scsi-disk: Command complete tag=0x0 status=0 sense=0 lsi_scsi: error: Unhandled writeb 0xff = 0x0 lsi_scsi: error: Unhandled writeb 0x100 = 0x0 lsi_scsi: error: Unhandled writeb 0x101 = 0x0 lsi_scsi: error: Unhandled writeb 0x102 = 0x0 While these errors are happening on boot, the animated bar continues to scroll. The errors continue for about a minute and then everything suddenly kicks into gear and the machine continues to boot. This also happens while trying to get partition information through the device properties in the device manager and through the disk management mmc snapin. I'm running kvm-82 on Debian Lenny AMD64. The disk is a 20GB virtual SCSI, raw format. Here's the command I'm using to run KVM. kvm -m 1024 -smp 2 -drive file=system.img,if=scsi,boot=on -localtime --vnc 127.0.0.1:0 &> ../win2k3x64.log -- Comment By: Anssi Kolehmainen (aketzu) Date: 2009-01-06 12:58 Message: With that patch Win2k8 64bit install seems to work pretty nicely. Only thing is that just in the end installer freezes for few seconds. Log shows that SCRIPTS has gotten into infinite loop: [1231238098.644651] scsi-disk: Command: lun=0 tag=0x100e1 data=0x28 0x00 0x00 0x13 0x4b 0xb0 0x00 0x00 0x88 0x00 [1231238098.644655] scsi-disk: Read (sector 1264560, count 136) [1231238098.644658] scsi-disk: Read sector_count=136 ... [1231238098.706945] scsi-disk: Command complete tag=0x100e1 status=0 sense=0 ... [1231238098.765279] lsi_scsi: Jump to 0xf0022068 [1231238098.765282] lsi_scsi: SCRIPTS dsp=f0022068 opcode f11c0004 arg [1231238098.765285] lsi_scsi: Load reg 0x1c size 4 addr 0x3fc70b58 = 3fc721e0 [1231238098.765288] lsi_scsi: Write reg 1c = e0 [1231238098.765291] lsi_scsi: Write reg 1d = 21 [1231238098.765293] lsi_scsi: Write reg 1e = c7 [1231238098.765296] lsi_scsi: Write reg 1f = 3f [1231238098.765299] lsi_scsi: SCRIPTS dsp=f0022070 opcode 721c arg [1231238098.765302] lsi_scsi: Read reg 0x1c OR data8=0x00 sfbr=0xe0 [1231238098.765305] lsi_scsi: Read reg 1c (=e0) [1231238098.765308] lsi_scsi: SCRIPTS dsp=f0022078 opcode 8084 arg ffe8 [1231238098.765311] lsi_scsi: Compare data 0xe0 & 0xff != 0x0 [1231238098.765314] lsi_scsi: Jump to 0xf0022068 [1231238098.765316] lsi_scsi: SCRIPTS dsp=f0022068 opcode f11c0004 arg [1231238098.765319] lsi_scsi: Load reg 0x1c size 4 addr 0x3fc70b58 = 3fc721e0 [1231238098.765322] lsi_scsi: Write reg 1c = e0 [1231238098.765325] lsi_scsi: Write reg 1d = 21 [1231238098.765328] lsi_scsi: Write reg 1e = c7 [1231238098.765331] lsi_scsi: Write reg 1f = 3f [1231238098.765333] lsi_scsi: SCRIPTS dsp=f0022070 opcode 721c arg [1231238098.765336] lsi_scsi: Read reg 0x1c OR data8=0x00 sfbr=0xe0 [1231238098.765340] lsi_scsi: Read reg 1c (=e0) [1231238098.765342] lsi_scsi: SCRIPTS dsp=f0022078 opcode 8084 arg ffe8 [1231238098.765345] lsi_scsi: Compare data 0xe0 & 0xff != 0x0 [1231238098.765354] lsi_scsi: Jump to 0xf0022068 ... [1231238098.816065] lsi_scsi: SCSI Interrupt 0x0004 prev 0x [1231238098.816069] lsi_scsi: SCRIPTS execution stopped Though timestamps tell that isn't the main delay. There is about five seconds of just 'Read reg 14' and then Windows does reset on the adapter. Tried Win2k3 (32-bit) with that patch and it seemed to work just fine. But when I tried to trigger bad status move error I've been getting earlier it resulted in 'Unimplemented message 0x77' error. Further digging out the cause I noticed that when writing data at some point Windows decides it wants to reset the adapter (probably because there is no Command complete message within few ms of Write data message). [1231235738.961354] scsi-disk: Write data tag=0x1009d [1231235738.961361] lsi_scsi: SCRIPTS execution stopped [1231235738.961409] lsi_scsi: Read reg 4f (=02) [1231235738.961926] lsi_scsi: Read reg 4f (=02) [1231235738.962442] lsi_scsi: Read reg 4f (=02) [1231235738.962957] lsi_scsi: Read reg 4f (=02) [1231235738.963472] lsi_scsi: Read reg 4f (=02) [1231235738.963480] lsi_scsi: Read r
[PATCH 1/1] kvm: qemu: virtio-net: migration fixes
We were failing to save two important pieces of state:
1) Whether the guest will supply us rx buffers using the
new mergeable format; this caused the migrated guest
to crash with "virtio-net header not in first element"
2) Whether the tx/rx buffers we exchange with the tap
code should include a virtio_net_hdr header; this
caused the migrated guest to receive garbage packets
because the tap code was stripping away the header
and virtio_net was interpreting packet data as the
virtio_net header
With these fixes a guest using mergeable rx buffers and
GSO passes a simple "ping while migrating" test.
The mergeable rx buffers part has been sent upstream to
qemu-devel, but the GSO part is KVM specific.
Signed-off-by: Mark McLoughlin
---
qemu/hw/virtio-net.c | 11 +++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/qemu/hw/virtio-net.c b/qemu/hw/virtio-net.c
index ef8f591..e47a0a4 100644
--- a/qemu/hw/virtio-net.c
+++ b/qemu/hw/virtio-net.c
@@ -360,6 +360,11 @@ static void virtio_net_save(QEMUFile *f, void *opaque)
qemu_put_buffer(f, n->mac, 6);
qemu_put_be32(f, n->tx_timer_active);
+qemu_put_be32(f, n->mergeable_rx_bufs);
+
+#ifdef TAP_VNET_HDR
+qemu_put_be32(f, tap_has_vnet_hdr(n->vc->vlan->first_client));
+#endif
}
static int virtio_net_load(QEMUFile *f, void *opaque, int version_id)
@@ -373,6 +378,12 @@ static int virtio_net_load(QEMUFile *f, void *opaque, int
version_id)
qemu_get_buffer(f, n->mac, 6);
n->tx_timer_active = qemu_get_be32(f);
+n->mergeable_rx_bufs = qemu_get_be32(f);
+
+#ifdef TAP_VNET_HDR
+if (qemu_get_be32(f))
+ tap_using_vnet_hdr(n->vc->vlan->first_client, 1);
+#endif
if (n->tx_timer_active) {
qemu_mod_timer(n->tx_timer,
--
1.6.0.6
--
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: Mouse motion lags
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Jamie Kirkpatrick wrote: > Try adding -usbdevice tablet. This should sort it out. Thank you very much. That did the trick! > > 2009/1/6 Antoine Martin : > nuit...@melchior.nuitari.net wrote: >> Hi everybody, >> >> I switched to KVM some time ago from vmware and VB. Everything works >> great but there are noticeable lags in mouse motion in comparison with >> other VMs. >> Is this a known issue? Are there any optimizations for that? >> >> KVM: 79 >> Distr: Ubuntu Intrepid & Jaunty >> Command line: QEMU_AUDIO_DRV=sdl; kvm -net nic -net user -soundhw >> es1370 -m 750 -smp 2 win.qcow >> > Is this under guest or host load? Or just moving the mouse around? > > Is the host swapping by any chance? I've noticed that issue on guest load, no swapping. But even just moving the mouse around feels more laggy then under vmware. I've tried mine with just 1 guest cpu. > I've noticed what I believe to be the same bug: when moving the mouse > around the vnc viewer, the guest does not seem to follow the same > acceleration and I end up with 2 pointers completely out of sync. > > This makes it really hard to use the mouse (especially as the real > pointer often moves off-screen before you reach the part of the guest > screen that you need..) > I normally would not care about mouse and UI (I run most guests in > no-graphic mode), but I have to run some tests against "that-other-OS" > at the moment, and this makes it even more of a nightmare. > > Any advice would be much appreciated. > I have tried various VNC clients (no effect), looked for mouse options, > etc.. > > Thanks > Antoine > > > > > > - -- 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 >> -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEAREKAAYFAkljVv0ACgkQGK2zHPGK1rs7uwCeJTGgITfgi81RRCXZSoau8JnK z3UAniULdjQ5e+sVSMxv8Zm7RdrIRAiK =oWZ0 -END PGP SIGNATURE- -- 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] KVM: MMU: Segregate mmu pages created with different cr4.pge settings
On Tue, Jan 06, 2009 at 12:41:40PM +0200, Avi Kivity wrote:
> Alexander Graf wrote:
>> Avi Kivity wrote:
>>
>>> From: Avi Kivity
>>>
>>> Don't allow a vcpu with cr4.pge cleared to use a shadow page created with
>>> cr4.pge set; this might cause a cr3 switch not to sync ptes that have the
>>> global bit set (the global bit has no effect if !cr4.pge).
>>>
>>> This can only occur on smp with different cr4.pge settings for different
>>> vcpus (since a cr4 change will resync the shadow ptes), but there's no
>>> cost to being correct here.
>>>
>>> Signed-off-by: Avi Kivity
>>>
>>> diff --git a/arch/x86/include/asm/kvm_host.h
>>> b/arch/x86/include/asm/kvm_host.h
>>> index f49bfd0..ab8ef1d 100644
>>> --- a/arch/x86/include/asm/kvm_host.h
>>> +++ b/arch/x86/include/asm/kvm_host.h
>>> @@ -183,6 +183,7 @@ union kvm_mmu_page_role {
>>> unsigned metaphysical:1;
>>> unsigned access:3;
>>> unsigned invalid:1;
>>> + unsigned cr4_pge:1;
>>> };
>>> };
>>> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
>>> index c4da7fb..aa4575c 100644
>>> --- a/arch/x86/kvm/x86.c
>>> +++ b/arch/x86/kvm/x86.c
>>> @@ -363,6 +363,7 @@ void kvm_set_cr4(struct kvm_vcpu *vcpu, unsigned long
>>> cr4)
>>> }
>>> kvm_x86_ops->set_cr4(vcpu, cr4);
>>> vcpu->arch.cr4 = cr4;
>>> + vcpu->arch.mmu.base_role.cr4_pge = !!(cr4 & X86_CR4_PGE);
>>>
>>
>> This line broke VMware ESX bootup using NPT on one VCPU for me. If I
>> comment it out and apply my patches to actually make ESX run, it boots
>> again.
>>
>
> I think this might be the problem:
>
>> static int mmu_need_write_protect(struct kvm_vcpu *vcpu, gfn_t gfn,
>> bool can_unsync)
>> {
>> struct kvm_mmu_page *shadow;
>>
>> shadow = kvm_mmu_lookup_page(vcpu->kvm, gfn);
>> if (shadow) {
>> if (shadow->role.level != PT_PAGE_TABLE_LEVEL)
>> return 1;
>> if (shadow->unsync)
>> return 0;
>> if (can_unsync && oos_shadow)
>> return kvm_unsync_page(vcpu, shadow);
>> return 1;
>> }
>> return 0;
>> }
>>
>
> lookup_page() is not deterministic if there are multiple shadows for a
> page, and the patch increases multiple shadows.
>
> Marcelo, shouldn't there be a for_each in there?
static int kvm_unsync_page(struct kvm_vcpu *vcpu, struct kvm_mmu_page *sp) {
unsigned index;
struct hlist_head *bucket;
struct kvm_mmu_page *s;
struct hlist_node *node, *n;
index = kvm_page_table_hashfn(sp->gfn);
bucket = &vcpu->kvm->arch.mmu_page_hash[index];
/* don't unsync if pagetable is shadowed with multiple roles */
hlist_for_each_entry_safe(s, node, n, bucket, hash_link) {
if (s->gfn != sp->gfn || s->role.metaphysical)
continue;
if (s->role.word != sp->role.word)
return 1;
}
This one?
--
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] KVM: MMU: Segregate mmu pages created with different cr4.pge settings
Marcelo Tosatti wrote:
On Tue, Jan 06, 2009 at 12:41:40PM +0200, Avi Kivity wrote:
Alexander Graf wrote:
Avi Kivity wrote:
From: Avi Kivity
Don't allow a vcpu with cr4.pge cleared to use a shadow page created with
cr4.pge set; this might cause a cr3 switch not to sync ptes that have the
global bit set (the global bit has no effect if !cr4.pge).
This can only occur on smp with different cr4.pge settings for different
vcpus (since a cr4 change will resync the shadow ptes), but there's no
cost to being correct here.
Signed-off-by: Avi Kivity
diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index f49bfd0..ab8ef1d 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -183,6 +183,7 @@ union kvm_mmu_page_role {
unsigned metaphysical:1;
unsigned access:3;
unsigned invalid:1;
+ unsigned cr4_pge:1;
};
};
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index c4da7fb..aa4575c 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -363,6 +363,7 @@ void kvm_set_cr4(struct kvm_vcpu *vcpu, unsigned long cr4)
}
kvm_x86_ops->set_cr4(vcpu, cr4);
vcpu->arch.cr4 = cr4;
+ vcpu->arch.mmu.base_role.cr4_pge = !!(cr4 & X86_CR4_PGE);
This line broke VMware ESX bootup using NPT on one VCPU for me. If I
comment it out and apply my patches to actually make ESX run, it boots
again.
I think this might be the problem:
static int mmu_need_write_protect(struct kvm_vcpu *vcpu, gfn_t gfn,
bool can_unsync)
{
struct kvm_mmu_page *shadow;
shadow = kvm_mmu_lookup_page(vcpu->kvm, gfn);
if (shadow) {
if (shadow->role.level != PT_PAGE_TABLE_LEVEL)
return 1;
if (shadow->unsync)
return 0;
if (can_unsync && oos_shadow)
return kvm_unsync_page(vcpu, shadow);
return 1;
}
return 0;
}
lookup_page() is not deterministic if there are multiple shadows for a
page, and the patch increases multiple shadows.
Marcelo, shouldn't there be a for_each in there?
static int kvm_unsync_page(struct kvm_vcpu *vcpu, struct kvm_mmu_page *sp) {
unsigned index;
struct hlist_head *bucket;
struct kvm_mmu_page *s;
struct hlist_node *node, *n;
index = kvm_page_table_hashfn(sp->gfn);
bucket = &vcpu->kvm->arch.mmu_page_hash[index];
/* don't unsync if pagetable is shadowed with multiple roles */
hlist_for_each_entry_safe(s, node, n, bucket, hash_link) {
if (s->gfn != sp->gfn || s->role.metaphysical)
continue;
if (s->role.word != sp->role.word)
return 1;
}
This one?
Yes...
Looks like kvm_unsync_page can be folded into mmu_need_write_protect
(after which we can drop lookup_page(), which is not a good API). But
that's after we solve the current problem.
Looks like the addition of a second role for non-pge mode confuses the
mmu. After the second page is created, mmu_need_write_protect() will
return 1, but previously existing sptes can still be writable?
Looks like we need to call rmap_write_protect() when the new page is
created.
--
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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] KVM: MMU: Segregate mmu pages created with different cr4.pge settings
On Tue, Jan 06, 2009 at 04:29:59PM +0200, Avi Kivity wrote:
> Marcelo Tosatti wrote:
>> On Tue, Jan 06, 2009 at 12:41:40PM +0200, Avi Kivity wrote:
>>
>>> Alexander Graf wrote:
>>>
Avi Kivity wrote:
> From: Avi Kivity
>
> Don't allow a vcpu with cr4.pge cleared to use a shadow page created with
> cr4.pge set; this might cause a cr3 switch not to sync ptes that have the
> global bit set (the global bit has no effect if !cr4.pge).
>
> This can only occur on smp with different cr4.pge settings for different
> vcpus (since a cr4 change will resync the shadow ptes), but there's no
> cost to being correct here.
>
> Signed-off-by: Avi Kivity
>
> diff --git a/arch/x86/include/asm/kvm_host.h
> b/arch/x86/include/asm/kvm_host.h
> index f49bfd0..ab8ef1d 100644
> --- a/arch/x86/include/asm/kvm_host.h
> +++ b/arch/x86/include/asm/kvm_host.h
> @@ -183,6 +183,7 @@ union kvm_mmu_page_role {
> unsigned metaphysical:1;
> unsigned access:3;
> unsigned invalid:1;
> + unsigned cr4_pge:1;
> };
> };
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index c4da7fb..aa4575c 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -363,6 +363,7 @@ void kvm_set_cr4(struct kvm_vcpu *vcpu, unsigned long
> cr4)
> }
> kvm_x86_ops->set_cr4(vcpu, cr4);
> vcpu->arch.cr4 = cr4;
> + vcpu->arch.mmu.base_role.cr4_pge = !!(cr4 & X86_CR4_PGE);
>
This line broke VMware ESX bootup using NPT on one VCPU for me. If I
comment it out and apply my patches to actually make ESX run, it boots
again.
>>> I think this might be the problem:
>>>
>>>
static int mmu_need_write_protect(struct kvm_vcpu *vcpu, gfn_t gfn,
bool can_unsync)
{
struct kvm_mmu_page *shadow;
shadow = kvm_mmu_lookup_page(vcpu->kvm, gfn);
if (shadow) {
if (shadow->role.level != PT_PAGE_TABLE_LEVEL)
return 1;
if (shadow->unsync)
return 0;
if (can_unsync && oos_shadow)
return kvm_unsync_page(vcpu, shadow);
return 1;
}
return 0;
}
>>> lookup_page() is not deterministic if there are multiple shadows for
>>> a page, and the patch increases multiple shadows.
>>>
>>> Marcelo, shouldn't there be a for_each in there?
>>>
>>
>> static int kvm_unsync_page(struct kvm_vcpu *vcpu, struct kvm_mmu_page *sp) {
>>
>> unsigned index;
>> struct hlist_head *bucket;
>> struct kvm_mmu_page *s;
>> struct hlist_node *node, *n;
>>
>> index = kvm_page_table_hashfn(sp->gfn);
>> bucket = &vcpu->kvm->arch.mmu_page_hash[index];
>> /* don't unsync if pagetable is shadowed with multiple roles */
>> hlist_for_each_entry_safe(s, node, n, bucket, hash_link) {
>> if (s->gfn != sp->gfn || s->role.metaphysical)
>> continue;
>> if (s->role.word != sp->role.word)
>> return 1;
>> }
>>
>> This one?
>>
>
> Yes...
>
> Looks like kvm_unsync_page can be folded into mmu_need_write_protect
> (after which we can drop lookup_page(), which is not a good API). But
> that's after we solve the current problem.
>
> Looks like the addition of a second role for non-pge mode confuses the
> mmu. After the second page is created, mmu_need_write_protect() will
> return 1, but previously existing sptes can still be writable?
>
> Looks like we need to call rmap_write_protect() when the new page is
> created.
kvm_mmu_get_page:
hlist_for_each_entry_safe(sp, node, tmp, bucket, hash_link)
if (sp->gfn == gfn) {
if (sp->unsync)
if (kvm_sync_page(vcpu, sp))
continue;
So rmap_write_protect is called when the new page is created. Looking
at it now.
--
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] KVM: MMU: Segregate mmu pages created with different cr4.pge settings
On Tue, Jan 06, 2009 at 04:29:59PM +0200, Avi Kivity wrote: > Yes... > > Looks like kvm_unsync_page can be folded into mmu_need_write_protect > (after which we can drop lookup_page(), which is not a good API). But > that's after we solve the current problem. > > Looks like the addition of a second role for non-pge mode confuses the > mmu. After the second page is created, mmu_need_write_protect() will > return 1, but previously existing sptes can still be writable? > > Looks like we need to call rmap_write_protect() when the new page is > created. I'm not sure about the details, but I suspect that multiple shadows confuse NPT somehow. Alexander can you give this a try: diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index 36aa576..2c6579e 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -363,7 +363,8 @@ void kvm_set_cr4(struct kvm_vcpu *vcpu, unsigned long cr4) } kvm_x86_ops->set_cr4(vcpu, cr4); vcpu->arch.cr4 = cr4; - vcpu->arch.mmu.base_role.cr4_pge = !!(cr4 & X86_CR4_PGE); + if (!tdp_enabled) + vcpu->arch.mmu.base_role.cr4_pge = !!(cr4 & X86_CR4_PGE); kvm_mmu_sync_global(vcpu); kvm_mmu_reset_context(vcpu); } -- 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] kvm: compat: define marker_synchronize_unregister on older kernels
marker_synchronize_unregister() is available only on 2.6.28. However, its definition is very simple, so we can define it if it is missing. This fixes compilation of kvm_trace.c against older kernels. Signed-off-by: Eduardo Habkost --- kernel/external-module-compat-comm.h |5 + 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/kernel/external-module-compat-comm.h b/kernel/external-module-compat-comm.h index f2343f6..5cb70b0 100644 --- a/kernel/external-module-compat-comm.h +++ b/kernel/external-module-compat-comm.h @@ -699,3 +699,8 @@ static inline void cpumask_clear_cpu(int cpu, cpumask_var_t mask) #endif + +/* Macro introduced only on newer kernels: */ +#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,28) +#define marker_synchronize_unregister() synchronize_sched() +#endif -- 1.5.6.rc3.11.g5f54d -- 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: __purge_vmap_area_lazy crash with CONFIG_PREEMPT_RCU=y
On Wed, Dec 31, 2008 at 01:32:37PM +1100, Nick Piggin wrote:
> On Wednesday 31 December 2008 02:32:50 Avi Kivity wrote:
> > Marcelo Tosatti wrote:
> > > On Tue, Dec 30, 2008 at 02:53:36PM +1100, Nick Piggin wrote:
> > >>> RSP
> > >>> ---[ end trace 31811279a2e983e8 ]---
> > >>> note: qemu-system-x86[4440] exited with preempt_count 2
> > >>>
> > >>>
> > >>> (gdb) l *(__purge_vmap_area_lazy + 0x12c)
> > >>> 0x80289ca2 is in __purge_vmap_area_lazy (mm/vmalloc.c:516).
> > >>> 511 if (nr || force_flush)
> > >>> 512 flush_tlb_kernel_range(*start, *end);
> > >>> 513
> > >>> 514 if (nr) {
> > >>> 515 spin_lock(&vmap_area_lock);
> > >>> 516 list_for_each_entry(va, &valist, purge_list)
> > >>> 517 __free_vmap_area(va);
> > >>> 518 spin_unlock(&vmap_area_lock);
> > >>> 519 }
> > >>> 520 spin_unlock(&purge_lock);
> > >>>
> > >>> 0x80289c9a <__purge_vmap_area_lazy+292>:mov 0x40(%rbx),%rax
> > >>> 0x80289c9e <__purge_vmap_area_lazy+296>:lea
> > >>> -0x40(%rax),%rbx 0x80289ca2 <__purge_vmap_area_lazy+300>:
> > >>> mov 0x40(%rbx),%rax ^^^
> > >
> > > Note:
> > >
> > > RAX: 6b6b6b6b6b6b6b6b RBX: 6b6b6b6b6b6b6b2b
> >
> > Good old POISON_FREE.
>
> Right, it seems like it has been kfreed while it is still accessed via RCU.
> But I just can't see how the vmap_area can be freed while there is a
> concurrent process traversing the vmap_area_list... __free_vmap_area removes
> the entry from the list first, then does a call_rcu to kfree it.
>
> Hmm...
Ok, the bug seems to be gone now. Avi, can you apply the kernel patch
please? I'll send a separate patch to disable hugepage usage if mmu
notifiers aren't enabled.
--
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
[ kvm-Bugs-2490866 ] repeatable corruption with qcow2 on kvm-79
Bugs item #2490866, was opened at 2009-01-06 21:10 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=893831&aid=2490866&group_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: qemu Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Adrian Bridgett (abridgett) Assigned to: Nobody/Anonymous (nobody) Summary: repeatable corruption with qcow2 on kvm-79 Initial Comment: Creating a qcow2 image, mkfs.ext3, sometimes mounting it would fail immediately, but in all cases it would corrupt (overwritten with zeros) after starting up backuppc on it. This is KVM-79 on a Debian lenny host and guest. This occured using virtio or not. Swapping to a raw file or LV worked flawlessly. I've tested the box with memtest and I don't have issues elsewhere but I've seen corruptions on other images. host and guest are both 2.6.26-1-adm64 kernel (debian lenny) I'm running 32-bit userspace everywhere. Dual core Intel Core2 E6300. I see KVM-81 has "improve qcow2 data integrity with cache=writethrough" which _might_ be what I'm hitting - but I can't find more details about this to check (and backport patch to debian package or wait for newer debian package). thanks. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=893831&aid=2490866&group_id=180599 -- 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: Mouse motion lags
On Fri, 2 Jan 2009 00:08:27 +0200
"Volodymyr Buell" wrote:
> On Thu, Jan 1, 2009 at 11:44 PM, Todd Deshane
> wrote:
> > On Thu, Jan 1, 2009 at 12:05 PM, Volodymyr Buell
> > wrote:
> >> Hi everybody,
> >>
> >> I switched to KVM some time ago from vmware and VB. Everything
> >> works great but there are noticeable lags in mouse motion in
> >> comparison with other VMs.
> >> Is this a known issue? Are there any optimizations for that?
> >>
> >> KVM: 79
> >> Distr: Ubuntu Intrepid & Jaunty
> >> Command line: QEMU_AUDIO_DRV=sdl; kvm -net nic -net user -soundhw
> >> es1370 -m 750 -smp 2 win.qcow
> >>
> >
> > Try adding -usb -usbdevice tablet
> >
> > Hope that helps.
>
> Unfortunately it brings yet more laggy result. It looks like mouse
> filtering in first person action games but again with the delay I
> mentioned before it's nearly unusable...
You can try the attached patch - it shortens the screen update interval
when the mouse moves. It's just a proof of concept and a little bit
ugly, but should work.
I once tried to submit something similar to QEMU upstream, when the
screen update interval was still hardcoded, but the patch wasn't
accepted. There could be some chance now when the update interval is
already dynamic so the modification is trivial.
--
Jindrich Makovicka
--- sdl.c.orig 2008-12-24 15:24:58.0 +0100
+++ sdl.c 2009-01-06 23:53:26.282639309 +0100
@@ -356,6 +356,7 @@
SDL_Event ev1, *ev = &ev1;
int mod_state;
int buttonstate = SDL_GetMouseState(NULL, NULL);
+int moved = 0;
if (last_vm_running != vm_running) {
last_vm_running = vm_running;
@@ -484,6 +485,7 @@
absolute_enabled) {
sdl_send_mouse_event(ev->motion.xrel, ev->motion.yrel, 0,
ev->motion.x, ev->motion.y, ev->motion.state);
+ moved = 1;
}
break;
case SDL_MOUSEBUTTONDOWN:
@@ -536,6 +538,10 @@
break;
}
}
+if (moved && ds->gui_timer_interval == 0)
+ ds->gui_timer_interval = 10;
+else if (!moved && ds->gui_timer_interval == 10)
+ ds->gui_timer_interval = 0;
}
static void sdl_fill(DisplayState *ds, int x, int y, int w, int h, uint32_t c)
Re: [PATCH] KVM: MMU: Segregate mmu pages created with different cr4.pge settings
Marcelo Tosatti wrote: > On Tue, Jan 06, 2009 at 04:29:59PM +0200, Avi Kivity wrote: > >> Yes... >> >> Looks like kvm_unsync_page can be folded into mmu_need_write_protect >> (after which we can drop lookup_page(), which is not a good API). But >> that's after we solve the current problem. >> >> Looks like the addition of a second role for non-pge mode confuses the >> mmu. After the second page is created, mmu_need_write_protect() will >> return 1, but previously existing sptes can still be writable? >> >> Looks like we need to call rmap_write_protect() when the new page is >> created. >> > > I'm not sure about the details, but I suspect that multiple shadows > confuse NPT somehow. > > Alexander can you give this a try: > Using this patch it works. But if I read it correctly, that doesn't actually fix anything but only treats NPT/EPT special, which it shouldn't, should it? Maybe this actually even breaks EPT? I remember having seen a lot of CR4 hacks in svm.c when npt is enabled. Maybe that is related? 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
[ kvm-Bugs-2490866 ] repeatable corruption with qcow2 on kvm-79
Bugs item #2490866, was opened at 2009-01-06 22:10 Message generated for change (Comment added) made by ldvornik You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=893831&aid=2490866&group_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: qemu Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Adrian Bridgett (abridgett) Assigned to: Nobody/Anonymous (nobody) Summary: repeatable corruption with qcow2 on kvm-79 Initial Comment: Creating a qcow2 image, mkfs.ext3, sometimes mounting it would fail immediately, but in all cases it would corrupt (overwritten with zeros) after starting up backuppc on it. This is KVM-79 on a Debian lenny host and guest. This occured using virtio or not. Swapping to a raw file or LV worked flawlessly. I've tested the box with memtest and I don't have issues elsewhere but I've seen corruptions on other images. host and guest are both 2.6.26-1-adm64 kernel (debian lenny) I'm running 32-bit userspace everywhere. Dual core Intel Core2 E6300. I see KVM-81 has "improve qcow2 data integrity with cache=writethrough" which _might_ be what I'm hitting - but I can't find more details about this to check (and backport patch to debian package or wait for newer debian package). thanks. -- Comment By: Laszlo Dvornik (ldvornik) Date: 2009-01-07 08:42 Message: Same problem here. With Lenny and vanilla 2.6.28 kernel, with KVM 79, and with KVM 82 user tools. Tried with KVM 82 module compile for 2.6.28 and with 2.6.28 builtin KVM sources. 32-bit userspace and kernel, Intel C2D T7100. Another effect: With empty qcow2, vmdk disk image formats, when I try to create a partition and save the new partition table, they can't save it until reboot. With raw image format there is no such problem. I liked to try with qcow, but: qemu: could not open disk image teszt.qcow I switched all of my disk images to raw, until the problem fixed. PS: The host filesystem is ext4, but I tested under ext3 filesystem too and the problem wasn't disappeared. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=893831&aid=2490866&group_id=180599 -- 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
