Re: [GIT PULL] KVM fixes for 2.6.26-rc7
Soren Hansen wrote: On Thu, Jun 26, 2008 at 03:52:47PM +0300, Avi Kivity wrote: The ubuntu kernel has a newer KVM module backported to it so it's really 2.6.25-rcX. That's a big no-no. We only guarantee binary compatibility for kernel.org releases. kvm-blah releases may break compatibility temporarily as issues are worked out. Well, anyhow, let's focus on getting this fixed, shall we? The kernel modules shipped in 2.6.24 was causing all sorts of issues, so in an effort to fix those, IIRC I grabbed what was in 2.6.25 at the time and backported that, so if I were to get this issue fixed, it should be sufficient to find anything that touches the kvm clock ABI between 2.6.25-rcwhatever I used and 2.6.25 final. Does that sound about right? Yeah. To be on the safe side you can have KVM_CHECK_EXTENSION return false for KVM_CAP_CLOCKSOURCE. I'm a bit confused about this, though. I was under the impression that for the KVM_CLOCK stuff to work, it'd would have to be in the host *and* the guest kernel, but our kernels don't have KVM_CLOCK enabled at all? Hmm... Looking at the code, it seems it does require host support, but it's not #ifdef'ed, so that would explain my confusion.. Yeah, host and guest support are completely orthogonal. -- 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 of 4] [kvm-userspace][test] consolidate test libs to libcflat
Jerone Young wrote: This set of patches are to consolidate test libraries into a single library archive. This lib archive is libcflat. This will allow common code to be shared among archs. Applied all, thanks. I squashed together 1-3 as Hollis suggested, and with git's rename detection, one can see that you merged exit() puts() etc into a single file. That usually doesn't work will with libraries (if you define your own puts() but not your own exit(), you're in trouble), but we can fix this if/when it starts to hurt. -- 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: another kvm-70 compile bug with rhel/centos 5.2
Farkas Levente wrote: anyone like to fix it? Don't worry, we'll get it fixed. -- 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: nfsroot stays 'readonly'
Louis-David Mitterrand wrote: Hi, To provide an emergency off-site backup server for a client, I'm trying to use kvm on a nightly rsync'ed copy of their server. To avoid the use of a disk image I was advised to try nfsroot. This the command I am running: # kvm -nographic -hda ~/empty.qcow2 -kernel /boot/vmlinuz-2.6.25.7-1-pyrrhus64 -append 3 root=/dev/nfs nfsroot=10.0.3.1:/backup/client.server.com/current/ ip=dhcp console=ttyS0 early_printk=ttyS0 -serial stdio -net nic -net tap,script=/etc/kvm/kvm-ifup-zenon -m 1024 wich mostly works, the remaining problems I have are: 1) the nfsroot fs stays 'readonly' even though I modified the backup's fstab to read: 10.0.3.1:/backup/client.server.com/current / nfs defaults,rw 0 0 try sticking a 'mount -o remount,rw /' somewhere in the boot initscripts. 2) the boot lingers a long time after activating swap even though there is no swap entry in the modified fstab 3) the login: prompt is not reached, the kernel hangs at: Running local boot scripts (/etc/rc.local). Try to find out what it's doing there with some echos. It may be due to the root filesystem being readonly. 4) also I'm not sure what the console= and early_printk= do; is it at the nfsroot or kvm level? These are Linux kernel options, see Documentation/kernel-parameters.txt. -- 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][REPOST]: Fake emulate Intel perfctr MSRs
Chris Lalancette wrote: Respin of my previous patch to fake emulate the Intel perfctr MSRs. As Sheng Yang pointed out, I didn't need an additional include, and I could use other #define's. Applied, thanks. Sorry about the delay. -- 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] KVM: VMX: Add ept_sync_context in flush_tlb
Yang, Sheng wrote:
On Wednesday 25 June 2008 20:02:17 Avi Kivity wrote:
Yang, Sheng wrote:
From 54dc26e44f1c0aa460bef409b799f36dae56a911 Mon Sep 17 00:00:00 2001
From: Sheng Yang [EMAIL PROTECTED]
Date: Wed, 18 Jun 2008 11:23:13 +0800
Subject: [PATCH] KVM: VMX: Add ept_sync_context in flush_tlb
Fix a potention issue caused by kvm_mmu_slot_remove_write_access().
The old behavior don't sync EPT TLB with modified EPT entry, which
result in inconsistent content of EPT TLB and EPT table.
@@ -1407,6 +1408,8 @@ static void exit_lmode(struct kvm_vcpu *vcpu)
static void vmx_flush_tlb(struct kvm_vcpu *vcpu)
{
vpid_sync_vcpu_all(to_vmx(vcpu));
+ if (vm_need_ept())
+ ept_sync_context(to_vmx(vcpu));
}
So we're flushing both the vpid tlb and the ept context? What does an
ept context flush mean exactly? tlb entries for gpa-hpa?
Yeah, the entries for gpa-hpa. So if we don't do this, cpu may see rw entry
rather than ro, then write to it directly rather than fall into KVM.
I see. Back to the patch, can't you replace vmx-eptp by
construct_eptp(vcpu-arch.mmu.root_hpa)?
--
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 2 of 3] Move KVM TRACE DEFINITIONS to common header
Jerone Young wrote: 3 files changed, 40 insertions(+), 40 deletions(-) include/asm-x86/kvm.h | 22 -- include/asm-x86/kvm_host.h | 18 -- include/linux/kvm_host.h | 40 This patch moves moves definitions required to use kvm trace from x86 specific kvm headers to common kvm headers. I applied patch 1, but: vcpu, 0, 0, 0, 0, 0, 0) #ifdef CONFIG_64BIT #define KVM_EX_ENTRY .quad diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h --- a/include/linux/kvm_host.h +++ b/include/linux/kvm_host.h @@ -322,6 +322,46 @@ extern struct dentry *kvm_debugfs_dir; #ifdef CONFIG_KVM_TRACE int kvm_trace_ioctl(unsigned int ioctl, unsigned long arg); void kvm_trace_cleanup(void); +#define KVM_TRC_INJ_VIRQ (KVM_TRC_HANDLER + 0x02) +#define KVM_TRC_REDELIVER_EVT(KVM_TRC_HANDLER + 0x03) +#define KVM_TRC_PEND_INTR(KVM_TRC_HANDLER + 0x04) +#define KVM_TRC_IO_READ (KVM_TRC_HANDLER + 0x05) +#define KVM_TRC_IO_WRITE (KVM_TRC_HANDLER + 0x06) +#define KVM_TRC_CR_READ (KVM_TRC_HANDLER + 0x07) +#define KVM_TRC_CR_WRITE (KVM_TRC_HANDLER + 0x08) +#define KVM_TRC_DR_READ (KVM_TRC_HANDLER + 0x09) +#define KVM_TRC_DR_WRITE (KVM_TRC_HANDLER + 0x0A) +#define KVM_TRC_MSR_READ (KVM_TRC_HANDLER + 0x0B) +#define KVM_TRC_MSR_WRITE(KVM_TRC_HANDLER + 0x0C) +#define KVM_TRC_CPUID(KVM_TRC_HANDLER + 0x0D) +#define KVM_TRC_INTR (KVM_TRC_HANDLER + 0x0E) +#define KVM_TRC_NMI (KVM_TRC_HANDLER + 0x0F) +#define KVM_TRC_VMMCALL (KVM_TRC_HANDLER + 0x10) +#define KVM_TRC_HLT (KVM_TRC_HANDLER + 0x11) +#define KVM_TRC_CLTS (KVM_TRC_HANDLER + 0x12) +#define KVM_TRC_LMSW (KVM_TRC_HANDLER + 0x13) +#define KVM_TRC_APIC_ACCESS (KVM_TRC_HANDLER + 0x14) +#define KVM_TRC_TDP_FAULT(KVM_TRC_HANDLER + 0x15) #else static inline int kvm_trace_ioctl(unsigned int ioctl, unsigned long arg) This hides the defines from the public interface. The KVM_TRC_* constants should be in kvm.h. -- 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
[PATCH 0/3] Fix guest time drift under heavy load.
Resending one more time. There was no response last time I've sent it. Qemu device emulation for timers might be inaccurate and causes coalescing of several IRQs into one. It happens when the load on the host is high and the guest did not manage to ack the previous IRQ. The first patch in the series fixes this by changing qemu_irq subsystem to return IRQ delivery status information. If device is notified that IRQs where lost it can regenerate them as needed. The following two patches add IRQ regeneration to PIC and RTC devices. --- Gleb Natapov (3): Fix time drift problem under high load when RTC is in use. Fix time drift problem under high load when PIT is in use. Change qemu_set_irq() to return status information. hw/apic.c| 103 +++--- hw/esp.c |4 ++ hw/fdc.c |4 ++ hw/i8254.c | 20 ++ hw/i8259.c | 19 +++--- hw/ide.c |8 +++- hw/irq.c | 10 +++-- hw/irq.h | 22 +++- hw/max7310.c |4 ++ hw/mc146818rtc.c | 11 +- hw/pc.c |6 ++- hw/pc.h |2 + hw/pci.c |8 +++- hw/ssd0323.c |4 ++ hw/twl92230.c|8 +++- 15 files changed, 159 insertions(+), 74 deletions(-) -- Gleb. -- 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/3] Fix time drift problem under high load when PIT is in use.
Count the number of interrupts that was lost due to interrupt coalescing
and re-inject them back when possible. This fixes time drift problem when
pit is used as a time source.
Signed-off-by: Gleb Natapov [EMAIL PROTECTED]
---
hw/i8254.c | 20 +++-
1 files changed, 19 insertions(+), 1 deletions(-)
diff --git a/hw/i8254.c b/hw/i8254.c
index 4813b03..c4f0f46 100644
--- a/hw/i8254.c
+++ b/hw/i8254.c
@@ -61,6 +61,8 @@ static PITState pit_state;
static void pit_irq_timer_update(PITChannelState *s, int64_t current_time);
+static uint32_t pit_irq_coalesced;
+
static int pit_get_count(PITChannelState *s)
{
uint64_t d;
@@ -369,12 +371,28 @@ static void pit_irq_timer_update(PITChannelState *s,
int64_t current_time)
return;
expire_time = pit_get_next_transition_time(s, current_time);
irq_level = pit_get_out1(s, current_time);
-qemu_set_irq(s-irq, irq_level);
+if(irq_level) {
+if(!qemu_irq_raise(s-irq))
+pit_irq_coalesced++;
+} else {
+qemu_irq_lower(s-irq);
+if(pit_irq_coalesced 0) {
+if(qemu_irq_raise(s-irq))
+pit_irq_coalesced--;
+qemu_irq_lower(s-irq);
+}
+}
+
#ifdef DEBUG_PIT
printf(irq_level=%d next_delay=%f\n,
irq_level,
(double)(expire_time - current_time) / ticks_per_sec);
#endif
+if(pit_irq_coalesced expire_time != -1) {
+uint32_t div = ((pit_irq_coalesced 10) 0x7f) + 2;
+expire_time -= ((expire_time - current_time) / div);
+}
+
s-next_transition_time = expire_time;
if (expire_time != -1)
qemu_mod_timer(s-irq_timer, expire_time);
--
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 3/3] Fix time drift problem under high load when RTC is in use.
Count the number of interrupts that was lost due to interrupt coalescing
and re-inject them back when possible. This fixes time drift problem when
RTC is used as a time source.
Signed-off-by: Gleb Natapov [EMAIL PROTECTED]
---
hw/mc146818rtc.c | 11 +--
1 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/hw/mc146818rtc.c b/hw/mc146818rtc.c
index 30bb044..64e4c11 100644
--- a/hw/mc146818rtc.c
+++ b/hw/mc146818rtc.c
@@ -72,6 +72,7 @@ struct RTCState {
static void rtc_set_time(RTCState *s);
static void rtc_copy_date(RTCState *s);
+static uint32_t rtc_irq_coalesced;
static void rtc_timer_update(RTCState *s, int64_t current_time)
{
@@ -101,7 +102,8 @@ static void rtc_periodic_timer(void *opaque)
rtc_timer_update(s, s-next_periodic_time);
s-cmos_data[RTC_REG_C] |= 0xc0;
-qemu_irq_raise(s-irq);
+if(!qemu_irq_raise(s-irq))
+rtc_irq_coalesced++;
}
static void cmos_ioport_write(void *opaque, uint32_t addr, uint32_t data)
@@ -360,7 +362,12 @@ static uint32_t cmos_ioport_read(void *opaque, uint32_t
addr)
case RTC_REG_C:
ret = s-cmos_data[s-cmos_index];
qemu_irq_lower(s-irq);
-s-cmos_data[RTC_REG_C] = 0x00;
+if(!rtc_irq_coalesced) {
+s-cmos_data[RTC_REG_C] = 0x00;
+} else {
+if(qemu_irq_raise(s-irq))
+rtc_irq_coalesced--;
+}
break;
default:
ret = s-cmos_data[s-cmos_index];
--
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-2005957 ] TAP networking stalls on large file transfers
Bugs item #2005957, was opened at 2008-06-29 19:12 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=893831aid=2005957group_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: Andrew Zabolotny (andyz) Assigned to: Nobody/Anonymous (nobody) Summary: TAP networking stalls on large file transfers Initial Comment: System: Fedora 9 KVM version: tried 65 and 70, both exhibit the same behaviour When using TAP networking if I copy a large file from host to guest OS, I get extremely low performance (under 1 megabyte/s) and sometimes file transfer stalls. If I run tcpdump in guest OS (even with a bogus filter - e.g. tcpdump -nn -i eth0 host 1.2.3.4) the stalled connection suddenly come alive. If I run repeatedly tcpdump/press Ctrl+C and so on, the file transfer visually goes much faster. I found a old thread about the same bug in QEMU: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=290569 The patch proposed there was applied in QEMU 0.7.3, but when I looked into QEMU 0.9.1 sources - it is not there, so it seems it was removed for some reason. However, if I run the same virtual machine with QEMU, I get stable performance with about 8-9 megabytes per second flowing both ways (from host to guest and from guest to host). I tried to apply the patch on KVM 70, but it does not make any difference :-( The guest OS is Ubuntu 8.04 but I guess that does not matter. I will be glad to cooperate to find/fix the bug but for now I'm out of ideas :-( -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=893831aid=2005957group_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 http://vger.kernel.org/majordomo-info.html
[ kvm-Bugs-1872252 ] 64-bit windows no longer booting with -no-kvm
Bugs item #1872252, was opened at 2008-01-15 19:17 Message generated for change (Comment added) made by avik You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=893831aid=1872252group_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: Pending Resolution: Fixed Priority: 5 Private: No Submitted By: Olivier Paquet (euzeka) Assigned to: Nobody/Anonymous (nobody) Summary: 64-bit windows no longer booting with -no-kvm Initial Comment: With kvm-56 it was possible to boot a Windows XP x64 guest both with and without the kvm module loaded. As of kvm-59, the boot process hangs (at 100% CPU) before the first graphics mode change (ie. it hangs in text mode) when the kvm module is not used or the -no-kvm switch is used. It boots fine with the module loaded though. The host is the same in both cases: a Core 2 Duo running 64-bit slackware 11 with kernel 2.6.21.1. I'm also using the same disk image. -- Comment By: Avi Kivity (avik) Date: 2008-06-29 18:30 Message: Logged In: YES user_id=539971 Originator: NO This ought to work now (even better when kvm-71 is released). -- Comment By: Olivier Paquet (euzeka) Date: 2008-01-15 19:25 Message: Logged In: YES user_id=390374 Originator: YES Forgot, I'm starting the whole thing with: qemu-system-x86_64 -hda wintest.img -smp 1 -localtime -net nic,model=rtl8139 -net tap,ifname=tap0,script=no -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=893831aid=1872252group_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 http://vger.kernel.org/majordomo-info.html
Re: another kvm-70 compile bug with rhel/centos 5.2
Farkas Levente wrote: hi, i'm just try to recompile kvm-70 with the latest centos-5.2 (aka rhel-5.2) kernel, but i've got a new compile error: error: redefinition of typedef 'bool' Please try the attached patch, and let me know if it helps. -- error compiling committee.c: too many arguments to function diff --git a/kernel/external-module-compat.h b/kernel/external-module-compat.h index c28d759..1ad515f 100644 --- a/kernel/external-module-compat.h +++ b/kernel/external-module-compat.h @@ -349,10 +349,14 @@ uint64_t div64_u64(uint64_t dividend, uint64_t divisor); #if LINUX_VERSION_CODE KERNEL_VERSION(2,6,19) +#if !defined(RHEL_RELEASE_VERSION) || (RHEL_RELEASE_VERSION RHEL_RELEASE_CODE(5,2)) + typedef _Bool bool; #endif +#endif + /* * PF_VCPU is a Linux 2.6.24 addition */
Re: another kvm-70 compile bug with rhel/centos 5.2
Avi Kivity wrote: Farkas Levente wrote: hi, i'm just try to recompile kvm-70 with the latest centos-5.2 (aka rhel-5.2) kernel, but i've got a new compile error: error: redefinition of typedef 'bool' Please try the attached patch, and let me know if it helps. not working on centos-5.2: - make[1]: Entering directory `/usr/src/kernels/2.6.18-92.1.6.el5-x86_64' LD /home/robot/rpm/BUILD/kvm-kmod-69/_kmod_build_/kernel/built-in.o CC [M] /home/robot/rpm/BUILD/kvm-kmod-69/_kmod_build_/kernel/svm.o In file included from command line:1: /home/robot/rpm/BUILD/kvm-kmod-69/_kmod_build_/kernel/external-module-compat.h:350:40: warning: RHEL_RELEASE_VERSION is not defined /home/robot/rpm/BUILD/kvm-kmod-69/_kmod_build_/kernel/external-module-compat.h:350:80: error: missing binary operator before token ( make[2]: *** [/home/robot/rpm/BUILD/kvm-kmod-69/_kmod_build_/kernel/svm.o] Error 1 make[1]: *** [_module_/home/robot/rpm/BUILD/kvm-kmod-69/_kmod_build_/kernel] Error 2 make[1]: Leaving directory `/usr/src/kernels/2.6.18-92.1.6.el5-x86_64' make: *** [all] Error 2 - -- Levente Si vis pacem para bellum! -- 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: kvm: unable to handle kernel NULL pointer dereference
Chris Wright wrote: * Tobias Diedrich ([EMAIL PROTECTED]) wrote: PM: Creating hibernation image: PM: Need to copy 126181 pages PM: Normal pages needed: 126181 + 1024 + 38, available pages: 397721 x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106 svm_cpu_init: svm_data is NULL on 0 Yeah, this is broken. What happens is: suspend: hardware_disable svm_hardware_disable kfree(svm_data) per_cpu(svm_data) = NULL resume: hardware_enable svm_hardware_enable if(!svm_data) printk(svm_cpu_init: svm_data is NULL on 0) at this point it is broken. Same would happen on an SMP box by simply doing offline/online of a CPU. This is definitely busted, looking into a patch. Any progress on this? Thanks, -- Tobias PGP: http://9ac7e0bc.uguu.de このメールは十割再利用されたビットで作られています。 -- 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] Re: kvm: unable to handle kernel NULL pointer dereference
Tobias Diedrich wrote:
Chris Wright wrote:
* Tobias Diedrich ([EMAIL PROTECTED]) wrote:
PM: Creating hibernation image:
PM: Need to copy 126181 pages
PM: Normal pages needed: 126181 + 1024 + 38, available pages: 397721
x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
svm_cpu_init: svm_data is NULL on 0
Yeah, this is broken. What happens is:
suspend:
hardware_disable
svm_hardware_disable
kfree(svm_data)
per_cpu(svm_data) = NULL
resume:
hardware_enable
svm_hardware_enable
if(!svm_data) printk(svm_cpu_init: svm_data is NULL on 0)
at this point it is broken.
Same would happen on an SMP box by simply doing offline/online of a CPU.
This is definitely busted, looking into a patch.
Any progress on this?
FWIW, it's still broken on 2.6.26-rc8, but the following patch works
for me (tm):
Index: linux-2.6.26-rc8.forcedwol/arch/x86/kvm/svm.c
===
--- linux-2.6.26-rc8.forcedwol.orig/arch/x86/kvm/svm.c 2008-06-29
20:04:20.0 +0200
+++ linux-2.6.26-rc8.forcedwol/arch/x86/kvm/svm.c 2008-06-29
20:12:15.0 +0200
@@ -268,6 +268,30 @@
return 1;
}
+static int svm_cpu_init(int cpu)
+{
+ struct svm_cpu_data *svm_data;
+ int r;
+
+ svm_data = kzalloc(sizeof(struct svm_cpu_data), GFP_KERNEL);
+ if (!svm_data)
+ return -ENOMEM;
+ svm_data-cpu = cpu;
+ svm_data-save_area = alloc_page(GFP_KERNEL);
+ r = -ENOMEM;
+ if (!svm_data-save_area)
+ goto err_1;
+
+ per_cpu(svm_data, cpu) = svm_data;
+
+ return 0;
+
+err_1:
+ kfree(svm_data);
+ return r;
+
+}
+
static void svm_hardware_disable(void *garbage)
{
struct svm_cpu_data *svm_data
@@ -293,11 +317,17 @@
struct desc_ptr gdt_descr;
struct desc_struct *gdt;
int me = raw_smp_processor_id();
+ int ret;
if (!has_svm()) {
- printk(KERN_ERR svm_cpu_init: err EOPNOTSUPP on %d\n, me);
+ printk(KERN_ERR svm_hardware_enable: err EOPNOTSUPP on %d\n,
me);
+ return;
+ }
+ if ((ret = svm_cpu_init(me)) != 0) {
+ printk(KERN_ERR svm_hardware_enable: svm_cpu_init failed on %d
with status: %d\n, me, ret);
return;
}
+
svm_data = per_cpu(svm_data, me);
if (!svm_data) {
@@ -321,30 +351,6 @@
page_to_pfn(svm_data-save_area) PAGE_SHIFT);
}
-static int svm_cpu_init(int cpu)
-{
- struct svm_cpu_data *svm_data;
- int r;
-
- svm_data = kzalloc(sizeof(struct svm_cpu_data), GFP_KERNEL);
- if (!svm_data)
- return -ENOMEM;
- svm_data-cpu = cpu;
- svm_data-save_area = alloc_page(GFP_KERNEL);
- r = -ENOMEM;
- if (!svm_data-save_area)
- goto err_1;
-
- per_cpu(svm_data, cpu) = svm_data;
-
- return 0;
-
-err_1:
- kfree(svm_data);
- return r;
-
-}
-
static void set_msr_interception(u32 *msrpm, unsigned msr,
int read, int write)
{
--
Tobias PGP: http://9ac7e0bc.uguu.de
このメールは十割再利用されたビットで作られています。
--
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: KVM: x86: accessors for guest registers
On Sun, Jun 29, 2008 at 04:14:37PM +0300, Avi Kivity wrote:
Marcelo Tosatti wrote:
As suggested by Avi, introduce accessors to read/write guest registers.
This simplifies the -cache_regs/-decache_regs interface, and improves
register caching which is important for VMX, where the cost of
vmcs_read/vmcs_write is significant.
I made some changes, which I think simplify things:
Stripped down, looks great.
- svm always caches registers, and all registers are dirty, since
cache/decache is cheap
Accurate regs_dirty information is useful for converting the emulator,
so that you can do something like:
emul_register_write(ctxt, reg, val)
{
if (!__test_and_set_bit(reg, ctxt-vcpu-regs_dirty))
ctxt-original_regs[reg] = kvm_register_read(ctxt-vcpu, reg);
ctxt-vcpu-regs[reg] = val;
}
Because restoring the original reg contents on failure is necessary.
Otherwise you need to cache all regs on emulation entry. RIP is always
read anyway, but RSP not so frequently.
Well, might not be worth the complexity for saving just one vmcs_read().
Or it can be changed later during conversion.
- kvm_register_write() sets the avail bit to avoid read-after-write
corruption (like forwarding in a real cpu :)
Eek.
- made rip a GPR in spite of my own objections, it does simplify things
- init avail and dirty bitmasks on cpu reset
- convert a couple mode GUEST_RIP references
- remove decache_all_regs
- inline decache_reg() into vmx/svm
How does the attached look?
- .cache_regs = svm_cache_regs,
- .decache_regs = svm_decache_regs,
.get_rflags = svm_get_rflags,
.set_rflags = svm_set_rflags,
if (io-in) {
r = pio_copy_data(vcpu);
if (r) {
- kvm_x86_ops-cache_regs(vcpu);
+ kvm_x86_ops-cache_reg(vcpu, VCPU_REGS_RAX);
return r;
}
These two don't go well together. Apparently the intent of this
-cache_regs call on failure was to restore the original registers in
case they were modified by pio_copy_data? But pio_copy_data does not
write to any guest register (and even if it did, this -cache_regs call
assumes what registers are fetched from the guest's originals).
kvm_x86_ops-cache_regs(vcpu);
if (!io-string) {
if (io-in)
memcpy(vcpu-arch.regs[VCPU_REGS_RAX],
vcpu-arch.pio_data,
io-size);
} else {
if (io-in) {
r = pio_copy_data(vcpu);
if (r) {
kvm_x86_ops-cache_regs(vcpu);
return r;
}
}
Unless I'm mistaken you can just remove 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
Re: [PATCH 2/3] Fix time drift problem under high load when PIT is in use.
On Sun, 2008-06-29 at 16:59 +0300, Gleb Natapov wrote:
Count the number of interrupts that was lost due to interrupt coalescing
and re-inject them back when possible. This fixes time drift problem when
pit is used as a time source.
Signed-off-by: Gleb Natapov [EMAIL PROTECTED]
---
hw/i8254.c | 20 +++-
1 files changed, 19 insertions(+), 1 deletions(-)
diff --git a/hw/i8254.c b/hw/i8254.c
index 4813b03..c4f0f46 100644
--- a/hw/i8254.c
+++ b/hw/i8254.c
@@ -61,6 +61,8 @@ static PITState pit_state;
static void pit_irq_timer_update(PITChannelState *s, int64_t current_time);
+static uint32_t pit_irq_coalesced;
The pit has 3 channels, it should be a channel field.
Also every time the pit frequency changes the above field should be
compensated with * (new_freq/old_freq).
For example, if the guest was running with 1000hz clock and the
pit_irq_coalesced value is 100 currently, a frequency change to 100hz
should reduce pit_irq_coalesced to 10.
Except that, its high time we stop drifting :)
+
static int pit_get_count(PITChannelState *s)
{
uint64_t d;
@@ -369,12 +371,28 @@ static void pit_irq_timer_update(PITChannelState *s,
int64_t current_time)
return;
expire_time = pit_get_next_transition_time(s, current_time);
irq_level = pit_get_out1(s, current_time);
-qemu_set_irq(s-irq, irq_level);
+if(irq_level) {
+if(!qemu_irq_raise(s-irq))
+pit_irq_coalesced++;
+} else {
+qemu_irq_lower(s-irq);
+if(pit_irq_coalesced 0) {
+if(qemu_irq_raise(s-irq))
+pit_irq_coalesced--;
+qemu_irq_lower(s-irq);
+}
+}
+
#ifdef DEBUG_PIT
printf(irq_level=%d next_delay=%f\n,
irq_level,
(double)(expire_time - current_time) / ticks_per_sec);
#endif
+if(pit_irq_coalesced expire_time != -1) {
+uint32_t div = ((pit_irq_coalesced 10) 0x7f) + 2;
+expire_time -= ((expire_time - current_time) / div);
+}
+
s-next_transition_time = expire_time;
if (expire_time != -1)
qemu_mod_timer(s-irq_timer, expire_time);
--
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: KVM: x86: accessors for guest registers
Marcelo Tosatti wrote:
- svm always caches registers, and all registers are dirty, since
cache/decache is cheap
Accurate regs_dirty information is useful for converting the emulator,
so that you can do something like:
emul_register_write(ctxt, reg, val)
{
if (!__test_and_set_bit(reg, ctxt-vcpu-regs_dirty))
ctxt-original_regs[reg] = kvm_register_read(ctxt-vcpu, reg);
ctxt-vcpu-regs[reg] = val;
}
Because restoring the original reg contents on failure is necessary.
Otherwise you need to cache all regs on emulation entry. RIP is always
read anyway, but RSP not so frequently.
Well, might not be worth the complexity for saving just one vmcs_read().
Or it can be changed later during conversion.
That doesn't work, because some of the registers may already be dirty
when the emulator is invoked (say, if we're emulating several
instructions back-to-back). I think the best way to change the emulator
is to let it have its own set of dirty/available bits.
if (io-in) {
r = pio_copy_data(vcpu);
if (r) {
- kvm_x86_ops-cache_regs(vcpu);
+ kvm_x86_ops-cache_reg(vcpu, VCPU_REGS_RAX);
return r;
}
These two don't go well together. Apparently the intent of this
-cache_regs call on failure was to restore the original registers in
case they were modified by pio_copy_data? But pio_copy_data does not
write to any guest register (and even if it did, this -cache_regs call
assumes what registers are fetched from the guest's originals).
kvm_x86_ops-cache_regs(vcpu);
if (!io-string) {
if (io-in)
memcpy(vcpu-arch.regs[VCPU_REGS_RAX],
vcpu-arch.pio_data,
io-size);
} else {
if (io-in) {
r = pio_copy_data(vcpu);
if (r) {
kvm_x86_ops-cache_regs(vcpu);
return r;
}
}
Unless I'm mistaken you can just remove it.
Right.
--
Do not meddle in the internals of kernels, for they are subtle and quick to
panic.
--
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
