Weekly KVM Test report, kernel 5b9207ec ... userspace 5f2a9719 ...
Hi All, This is our Weekly KVM Testing Report against lastest kvm.git 5b9207ec01681337786c7898ffc0165ec4e7c2e4 and kvm-userspace.git 5f2a9719f105e29fbde4529cf919a5351b05da9a. There is no new issue found this week. Two Old Issues: 1. 32bits Rhel5/FC6 guest may fail to reboot after installation https://sourceforge.net/tracker/?func=detailatid=893831aid=1991647group_id=180599 2. failure to migrate guests with more than 4GB of RAM https://sourceforge.net/tracker/index.php?func=detailaid=1971512group_id=180599atid=893831 Test environment Platform Woodcrest CPU 4 Memory size 8G' Details IA32-pae: 1. boot guest with 256M memory PASS 2. boot guest with 1500M memory PASS 3. boot 4 same guest in parallel PASS 4. boot two windows xp guestPASS 5. boot linux and windows guest in parallel PASS 6. save/restore 32-bit HVM guests PASS 7. save/restore 32-bit HVM guests with 4 vcpus PASS 8. live migration 32-bit HVM guests PASS 9. live migration 32-bit HVM guests with 4 vcpus PASS 10. boot base kernel linux PASS 11. kernel build on SMP linux guestPASS 12. LTP on linux guest PASS 13. boot Windows 2000 without ACPI PASS 14. boot Windows 2000 with ACPI enabled PASS 15. boot Windows 2003 with ACPI enabled PASS 16. boot Windows xp with ACPI enabled PASS 17. boot Windows vista with ACPI enabled PASS 18. boot SMP Windows 2000 with ACPI enabled PASS 19. boot SMP Windows 2003 with ACPI enabled PASS 20. boot SMP Windows xp with ACPI enabled PASS 21. boot SMP Windows 2008 with ACPI enabled PASS IA32e: 1. boot 32-bit guest with 256M memory PASS 2. boot 64-bit guest with 256M memory PASS 3. boot 32-bit guest with 1500M memory PASS 4. boot 64-bit guest with 1500M memory PASS 5. boot 4G pae guest PASS 6. boot 4G 64-bit guest PASS 7. boot four 32-bit guest in parallel PASS 8. boot four 64-bit guest in parallel PASS 9. boot two 32-bit windows xp in parallel PASS 10. boot 32-bit linux and 32 bit windows guest in parallel PASS 11. boot four 32-bit different guest in para PASS 12. save/restore 32-bit linux guests PASS 13. save/restore 64-bit linux guests PASS 14. save/restore 64-bit linux guests with 4 vcpus PASS 15. save/restore 32-bit linux guests with 4 vcpus PASS 16. live migration 64bit linux guests PASS 17. live migration 32bit linux guests PASS 18. live migration 64bit linux guests with 4 vcpus PASS 19. live migration 32bit linux guests with 4 vcpus PASS 20. boot 32-bit x-server PASS 21. kernel build in 32-bit linux guest OS PASS 22. kernel build in 64-bit linux guest OS PASS 23. LTP on 32-bit linux guest OS PASS 24. LTP on 64-bit linux guest OS PASS 25. boot 64-bit guests with ACPI enabled PASS 26. boot 32-bit Windows 2000 without ACPIPASS 27. boot 32-bit Windows xp without ACPIPASS 28. boot 64-bit Windows xp with ACPI enabledPASS 29. boot 64-bit Windows vista with ACPI enabled PASS 30. boot 32-bit SMP Windows 2000 with ACPI enabled PASS 31. boot 32-bit SMP windows 2003 with ACPI enabled PASS 32. boot 32-bit SMP Windows xp with ACPI enabledPASS 33. boot 64-bit SMP Windows vista with ACPI enabled PASS 34. boot 32-bit SMP windows 2008 with ACPI enabled PASS 35. boot 64-bit SMP windows 2003 with ACPI enabled PASS 36. boot 64-bit SMP windows XP with ACPI enabled PASS 37. boot 64-bit SMP windows 2008 with ACPI
Re: Bug in reboot when using scsi or virtio
Stuart Sheldon wrote: Thanks Avi, Should I test against the daily to verify? I've reproduced it locally and verified the fix, but of course additional confirmation is welcome. -- 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] KVM: Qemu: Set default pm_io_base to 0x1f40.
From 6039f279745733c52b291ec45c69eca028567c62 Mon Sep 17 00:00:00 2001 From: Xiantao Zhang [EMAIL PROTECTED] Date: Sun, 31 Aug 2008 14:27:23 +0800 Subject: [PATCH] KVM: Qemu: Set default pm_io_base to 0x1f40. The firmware of kvm/ia64 use 0x1f40 as default pm_io_base, and doesn't have re-configure mechanism, so use 0x1f40 as default value to support kvm/ia64's power management. Signed-off-by: Xiantao Zhang [EMAIL PROTECTED] --- qemu/hw/acpi.c |4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/qemu/hw/acpi.c b/qemu/hw/acpi.c index 74535bc..4fc1d3f 100644 --- a/qemu/hw/acpi.c +++ b/qemu/hw/acpi.c @@ -498,7 +498,9 @@ i2c_bus *piix4_pm_init(PCIBus *bus, int devfn, uint32_t smb_io_base, pci_conf[0x0e] = 0x00; // header_type pci_conf[0x3d] = 0x01; // interrupt pin 1 -pci_conf[0x40] = 0x01; /* PM io base read only bit */ +pci_conf[0x40] = 0x41; /* PM io base read only bit */ +pci_conf[0x41] = 0x1f; +pm_write_config(s, 0x80, 0x01, 1); /*Set default pm_io_base 0x1f40*/ register_ioport_write(0xb2, 2, 1, pm_smi_writeb, s); register_ioport_read(0xb2, 2, 1, pm_smi_readb, s); -- 1.5.1 0001-KVM-Qemu-Set-default-pm_io_base-to-0x1f40.patch Description: 0001-KVM-Qemu-Set-default-pm_io_base-to-0x1f40.patch
Re: [PATCH] KVM: MMU: Add shadow_accessed_shift
[EMAIL PROTECTED] wrote: From: Sheng Yang [EMAIL PROTECTED] We use a fake A/D bit for EPT, to keep epte behaviour consistent with shadow spte. But it's not that good for MMU notifier. Now we can only expect return young=0 for clean_flush_young() in most condition. Perhaps we are better off setting shadow_accessed_mask to 0 for ept, and adding a test for clear_flush_young()? This is the only place that needs adjusting as far as I can tell. I don't see what having a fake accessed bit buys us, and I'd like the patch to be as small as possible, since it needs to go into 2.6.26-stable and 2.6.27-rc. -- 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: Qemu: Set default pm_io_base to 0x1f40.
Zhang, Xiantao wrote: From 6039f279745733c52b291ec45c69eca028567c62 Mon Sep 17 00:00:00 2001 From: Xiantao Zhang [EMAIL PROTECTED] Date: Sun, 31 Aug 2008 14:27:23 +0800 Subject: [PATCH] KVM: Qemu: Set default pm_io_base to 0x1f40. The firmware of kvm/ia64 use 0x1f40 as default pm_io_base, and doesn't have re-configure mechanism, so use 0x1f40 as default value to support kvm/ia64's power management. Signed-off-by: Xiantao Zhang [EMAIL PROTECTED] --- qemu/hw/acpi.c |4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/qemu/hw/acpi.c b/qemu/hw/acpi.c index 74535bc..4fc1d3f 100644 --- a/qemu/hw/acpi.c +++ b/qemu/hw/acpi.c @@ -498,7 +498,9 @@ i2c_bus *piix4_pm_init(PCIBus *bus, int devfn, uint32_t smb_io_base, pci_conf[0x0e] = 0x00; // header_type pci_conf[0x3d] = 0x01; // interrupt pin 1 -pci_conf[0x40] = 0x01; /* PM io base read only bit */ +pci_conf[0x40] = 0x41; /* PM io base read only bit */ +pci_conf[0x41] = 0x1f; +pm_write_config(s, 0x80, 0x01, 1); /*Set default pm_io_base 0x1f40*/ Please limit this to ia64; no need to change x86 behaviour. -- 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: Qemu: Set default pm_io_base to 0x1f40.
Avi Kivity wrote: Zhang, Xiantao wrote: From 6039f279745733c52b291ec45c69eca028567c62 Mon Sep 17 00:00:00 2001 From: Xiantao Zhang [EMAIL PROTECTED] Date: Sun, 31 Aug 2008 14:27:23 +0800 Subject: [PATCH] KVM: Qemu: Set default pm_io_base to 0x1f40. The firmware of kvm/ia64 use 0x1f40 as default pm_io_base, and doesn't have re-configure mechanism, so use 0x1f40 as default value to support kvm/ia64's power management. Signed-off-by: Xiantao Zhang [EMAIL PROTECTED] --- qemu/hw/acpi.c |4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/qemu/hw/acpi.c b/qemu/hw/acpi.c index 74535bc..4fc1d3f 100644 --- a/qemu/hw/acpi.c +++ b/qemu/hw/acpi.c @@ -498,7 +498,9 @@ i2c_bus *piix4_pm_init(PCIBus *bus, int devfn, uint32_t smb_io_base, pci_conf[0x0e] = 0x00; // header_type pci_conf[0x3d] = 0x01; // interrupt pin 1 -pci_conf[0x40] = 0x01; /* PM io base read only bit */ +pci_conf[0x40] = 0x41; /* PM io base read only bit */ + pci_conf[0x41] = 0x1f; +pm_write_config(s, 0x80, 0x01, 1); /*Set default pm_io_base 0x1f40*/ Please limit this to ia64; no need to change x86 behaviour. X86 will do update and set pm_io_base to 0xb000 in bios, so x86 behaviour doesn't change with this defaul set. 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: [REGRESSION] High, likely incorrect process cpu usage counters with kvm and 2.6.2[67]
On Sun, Aug 31, 2008 at 11:43 AM, Avi Kivity [EMAIL PROTECTED] wrote: Running an idle Windows VM on Linux 2.6.26+ with kvm, one sees high values for the kvm process in top (30%-70% cpu), where one would normally expect 0%-1%. Surprisingly, the per-cpu system counters show almost 100% idle, leading me to believe this is an accounting error and that the process does not actually consume this much cpu. Busted process accounting - This looks the same as http://bugzilla.kernel.org/show_bug.cgi?id=11209 . Please verify. Peter's patch in latest git stops showing incorrect looking CPU usage but at least the process times are still wrong, horribly. In fact the CPU usage thing in -rc5 is likely also incorrect but I need to analyze that bit a little more. From Today's Git - PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND 12961 parag 20 0 83000 8908 6628 R0 0.1 5124415h npviewer.bin I bisected this to a scheduler change, namely commit 3e51f33fcc7f55e6df25d15b55ed10c8b4da84cd Author: Peter Zijlstra [EMAIL PROTECTED] Date: Sat May 3 18:29:28 2008 +0200 sched: add optional support for CONFIG_HAVE_UNSTABLE_SCHED_CLOCK this replaces the rq-clock stuff (and possibly cpu_clock()). - architectures that have an 'imperfect' hardware clock can set CONFIG_HAVE_UNSTABLE_SCHED_CLOCK - the 'jiffie' window might be superfulous when we update tick_gtod before the __update_sched_clock() call in sched_clock_tick() - cpu_clock() might be implemented as: sched_clock_cpu(smp_processor_id()) if the accuracy proves good enough - how far can TSC drift in a single jiffie when considering the filtering and idle hooks? [ [EMAIL PROTECTED]: various fixes and cleanups ] Signed-off-by: Peter Zijlstra [EMAIL PROTECTED] Signed-off-by: Ingo Molnar [EMAIL PROTECTED] That patch sounds like it had open questions? Really giving this is a long standing bad regression, all the offending patches should be reverted in absence of a fix, no? Parag -- 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
serial problems cont..
Hi everyone, I've written a couple of questions regarding the serial device in KVM. After slightly more investigation I think I have found what's going awry. Correct me if I'm wrong, but I believe that KVM generates an interrupt for every single character it sends through the serial port. This throws CPU usage through the roof and I suspect this means that the timers aren't being handled correctly and it failed on a string of 0's for me due to the timing slips. GNU/Linux and Windows don't have anywhere near the processor usage for their serial ports. Now, I know nothing of serial programming and don't have any time to investigate it too heavily just now, but I have pulled down the source and had a look through that, but it looks to be doing the right thing (I suppose?). I was mainly wondering how GNU/Linux and windows handle serial interrupts or if some of the serial character events could be buffered, rather than overload the processor? I guess this is a low priority for you, but any help would be greatly appreciated (And when I have some more time, I will spend some of it helping to develop KVM! Quid pro quo, Clarice...) Thanks, Michael === This email, including any attachments, is only for the intended addressee. It is subject to copyright, is confidential and may be the subject of legal or other privilege, none of which is waived or lost by reason of this transmission. If the receiver is not the intended addressee, please accept our apologies, notify us by return, delete all copies and perform no other act on the email. Unfortunately, we cannot warrant that the email has not been altered or corrupted during transmission. === -- 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: testsuite: Save eflags in exec_in_big_real_mode()
Save eflags in exec_in_big_real_mode(). This is needed to test instructions that modify the eflags register. Signed-off-by: Mohammed Gamal [EMAIL PROTECTED] --- user/test/x86/realmode.c |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/user/test/x86/realmode.c b/user/test/x86/realmode.c index 79df0f5..906be09 100644 --- a/user/test/x86/realmode.c +++ b/user/test/x86/realmode.c @@ -82,6 +82,10 @@ static void exec_in_big_real_mode(const struct regs *inregs, test_insn: . = . + 16\n\t test_insn_end: \n\t + /* Save EFLAGS in outregs*/ + pushfl \n\t + popl %[save]+36 \n\t + xchg %%eax, %[save]+0 \n\t xchg %%ebx, %[save]+4 \n\t xchg %%ecx, %[save]+8 \n\t -- 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
[PATCH] kvm: testsuite: Add cld/std, cli/sti, and clc instructions.
Adds cld/std, cli/sti, and clc instructions to the test harness.
Signed-off-by: Mohammed Gamal [EMAIL PROTECTED]
---
user/test/x86/realmode.c | 40
1 files changed, 40 insertions(+), 0 deletions(-)
diff --git a/user/test/x86/realmode.c b/user/test/x86/realmode.c
index 906be09..904ef21 100644
--- a/user/test/x86/realmode.c
+++ b/user/test/x86/realmode.c
@@ -172,6 +172,45 @@ void test_mov_imm(const struct regs *inregs, struct regs
*outregs)
print_serial(mov test 5: FAIL\n);
}
+void test_eflags_insn(struct regs *inregs, struct regs *outregs)
+{
+ MK_INSN(clc, clc);
+ MK_INSN(cli, cli);
+ MK_INSN(sti, sti);
+ MK_INSN(cld, cld);
+ MK_INSN(std, std);
+
+ exec_in_big_real_mode(inregs, outregs,
+ insn_clc,
+ insn_clc_end - insn_clc);
+ if(outregs-eflags 1)
+ print_serial(clc test: FAIL\n);
+
+ exec_in_big_real_mode(inregs, outregs,
+ insn_cli,
+ insn_cli_end - insn_cli);
+ if(outregs-eflags (1 9))
+ print_serial(cli test: FAIL\n);
+
+ exec_in_big_real_mode(inregs, outregs,
+ insn_sti,
+ insn_sti_end - insn_sti);
+ if(!(outregs-eflags (1 9)))
+ print_serial(sti test: FAIL\n);
+
+ exec_in_big_real_mode(inregs, outregs,
+ insn_cld,
+ insn_cld_end - insn_cld);
+ if(outregs-eflags (1 10))
+ print_serial(cld test: FAIL\n);
+
+ exec_in_big_real_mode(inregs, outregs,
+ insn_std,
+ insn_std_end - insn_std);
+ if(!(outregs-eflags (1 10)))
+ print_serial(std test: FAIL\n);
+}
+
void start(void)
{
struct regs inregs = { 0 }, outregs;
@@ -181,6 +220,7 @@ void start(void)
if (!regs_equal(inregs, outregs, 0))
print_serial(null test: FAIL\n);
test_mov_imm(inregs, outregs);
+ test_eflags_insn(inregs, outregs);
exit(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
[PATCH] x86 emulator: Add std and cld instructions (opcodes 0xfc-0xfd)
This adds the std and cld instructions to the emulator.
Encountered while running the BIOS with the invalid guest
state emulation patch.
Signed-off-by: Mohammed Gamal [EMAIL PROTECTED]
---
arch/x86/kvm/x86_emulate.c | 10 +-
1 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/arch/x86/kvm/x86_emulate.c b/arch/x86/kvm/x86_emulate.c
index d5da7f1..005f1db 100644
--- a/arch/x86/kvm/x86_emulate.c
+++ b/arch/x86/kvm/x86_emulate.c
@@ -180,7 +180,7 @@ static u16 opcode_table[256] = {
ImplicitOps, ImplicitOps, Group | Group3_Byte, Group | Group3,
/* 0xF8 - 0xFF */
ImplicitOps, 0, ImplicitOps, ImplicitOps,
- 0, 0, Group | Group4, Group | Group5,
+ ImplicitOps, ImplicitOps, Group | Group4, Group | Group5,
};
static u16 twobyte_table[256] = {
@@ -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] KVM: Qemu: Set default pm_io_base to 0x1f40.
Avi Kivity wrote: Zhang, Xiantao wrote: Avi Kivity wrote: Zhang, Xiantao wrote: From 6039f279745733c52b291ec45c69eca028567c62 Mon Sep 17 00:00:00 2001 From: Xiantao Zhang [EMAIL PROTECTED] Date: Sun, 31 Aug 2008 14:27:23 +0800 Subject: [PATCH] KVM: Qemu: Set default pm_io_base to 0x1f40. The firmware of kvm/ia64 use 0x1f40 as default pm_io_base, and doesn't have re-configure mechanism, so use 0x1f40 as default value to support kvm/ia64's power management. Signed-off-by: Xiantao Zhang [EMAIL PROTECTED] --- qemu/hw/acpi.c |4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/qemu/hw/acpi.c b/qemu/hw/acpi.c index 74535bc..4fc1d3f 100644 --- a/qemu/hw/acpi.c +++ b/qemu/hw/acpi.c @@ -498,7 +498,9 @@ i2c_bus *piix4_pm_init(PCIBus *bus, int devfn, uint32_t smb_io_base, pci_conf[0x0e] = 0x00; // header_type pci_conf[0x3d] = 0x01; // interrupt pin 1 -pci_conf[0x40] = 0x01; /* PM io base read only bit */ +pci_conf[0x40] = 0x41; /* PM io base read only bit */ + pci_conf[0x41] = 0x1f; +pm_write_config(s, 0x80, 0x01, 1); /*Set default pm_io_base 0x1f40*/ Please limit this to ia64; no need to change x86 behaviour. X86 will do update and set pm_io_base to 0xb000 in bios, so x86 behaviour doesn't change with this defaul set. It still changes how x86 works. Since we want to push this to upsteam qemu eventually, we need to keep x86 operating in the same way as real hardware. (it would be even better to have ia64 firmware program this; how does real ia64 hardware work?) Maybe we can limit it in ia64 side. Program firmware maybe hard to get check-in, since Xen also share this firmware. From 3893e60105bc9a493c67faed760edd0a14bfed2b Mon Sep 17 00:00:00 2001 From: Xiantao Zhang [EMAIL PROTECTED] Date: Mon, 1 Sep 2008 09:47:25 +0800 Subject: [PATCH] KVM: Qemu: Set default pm_io_base to 0x1f40. The firmware of kvm/ia64 use 0x1f40 as default pm_io_base, and doesn't have re-configure mechanism, so use 0x1f40 as default value to support kvm/ia64's power management. Signed-off-by: Xiantao Zhang [EMAIL PROTECTED] --- qemu/hw/acpi.c |6 +- 1 files changed, 5 insertions(+), 1 deletions(-) diff --git a/qemu/hw/acpi.c b/qemu/hw/acpi.c index 74535bc..d12a43e 100644 --- a/qemu/hw/acpi.c +++ b/qemu/hw/acpi.c @@ -499,7 +499,11 @@ i2c_bus *piix4_pm_init(PCIBus *bus, int devfn, uint32_t smb_io_base, pci_conf[0x3d] = 0x01; // interrupt pin 1 pci_conf[0x40] = 0x01; /* PM io base read only bit */ - +#if defined(TARGET_IA64) +pci_conf[0x40] = 0x41; /* PM io base read only bit */ +pci_conf[0x41] = 0x1f; +pm_write_config(s, 0x80, 0x01, 1); /*Set default pm_io_base 0x1f40*/ +#endif register_ioport_write(0xb2, 2, 1, pm_smi_writeb, s); register_ioport_read(0xb2, 2, 1, pm_smi_readb, s); -- 1.5.1 0001-KVM-Qemu-Set-default-pm_io_base-to-0x1f40.patch Description: 0001-KVM-Qemu-Set-default-pm_io_base-to-0x1f40.patch
Re: [PATCH] KVM: MMU: Add shadow_accessed_shift
On Sunday 31 August 2008 23:13:54 Avi Kivity wrote:
[EMAIL PROTECTED] wrote:
From: Sheng Yang [EMAIL PROTECTED]
We use a fake A/D bit for EPT, to keep epte behaviour consistent with
shadow spte. But it's not that good for MMU notifier. Now we can only
expect return young=0 for clean_flush_young() in most condition.
Perhaps we are better off setting shadow_accessed_mask to 0 for ept, and
adding a test for clear_flush_young()? This is the only place that
needs adjusting as far as I can tell.
I don't see what having a fake accessed bit buys us, and I'd like the
patch to be as small as possible, since it needs to go into
2.6.26-stable and 2.6.27-rc.
Though I still think fake accessed bit here makes logic consistent, here is
the patch follow your comment. But I think it may not necessary for the
2.6.26-stable?
From: Sheng Yang [EMAIL PROTECTED]
Date: Mon, 1 Sep 2008 13:22:09 +0800
Subject: [PATCH] KVM: VMX: Always return 0 for clear_flush_young() when using
EPT
As well as discard fake accessed bit and dirty bit of EPT.
Signed-off-by: Sheng Yang [EMAIL PROTECTED]
---
arch/x86/kvm/mmu.c | 15 +++
arch/x86/kvm/vmx.c |3 +--
arch/x86/kvm/vmx.h |2 --
3 files changed, 12 insertions(+), 8 deletions(-)
diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index f33c594..e437985 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -716,10 +716,17 @@ static int kvm_age_rmapp(struct kvm *kvm, unsigned long
*rmapp)
int _young;
u64 _spte = *spte;
BUG_ON(!(_spte PT_PRESENT_MASK));
- _young = _spte PT_ACCESSED_MASK;
- if (_young) {
- young = 1;
- clear_bit(PT_ACCESSED_SHIFT, (unsigned long *)spte);
+
+ /* always return old for EPT */
+ if (!shadow_accessed_mask)
+ _young = 0;
+ else {
+ _young = _spte PT_ACCESSED_MASK;
+ if (_young) {
+ young = 1;
+ clear_bit(PT_ACCESSED_SHIFT,
+ (unsigned long *)spte);
+ }
}
spte = rmap_next(kvm, rmapp, spte);
}
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 81c121c..d637897 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -3557,8 +3557,7 @@ static int __init vmx_init(void)
kvm_mmu_set_base_ptes(VMX_EPT_READABLE_MASK |
VMX_EPT_WRITABLE_MASK |
VMX_EPT_DEFAULT_MT VMX_EPT_MT_EPTE_SHIFT);
- kvm_mmu_set_mask_ptes(0ull, VMX_EPT_FAKE_ACCESSED_MASK,
- VMX_EPT_FAKE_DIRTY_MASK, 0ull,
+ kvm_mmu_set_mask_ptes(0ull, 0ull, 0ull, 0ull,
VMX_EPT_EXECUTABLE_MASK);
kvm_enable_tdp();
} else
diff --git a/arch/x86/kvm/vmx.h b/arch/x86/kvm/vmx.h
index 0c22e5f..41e8c10 100644
--- a/arch/x86/kvm/vmx.h
+++ b/arch/x86/kvm/vmx.h
@@ -370,8 +370,6 @@ enum vmcs_field {
#define VMX_EPT_READABLE_MASK 0x1ull
#define VMX_EPT_WRITABLE_MASK 0x2ull
#define VMX_EPT_EXECUTABLE_MASK0x4ull
-#define VMX_EPT_FAKE_ACCESSED_MASK (1ull 62)
-#define VMX_EPT_FAKE_DIRTY_MASK(1ull 63)
#define VMX_EPT_IDENTITY_PAGETABLE_ADDR0xfffbc000ul
--
1.5.4.5
From 23229946e717294091bf54cee704fb3b1cd4167d Mon Sep 17 00:00:00 2001
From: Sheng Yang [EMAIL PROTECTED]
Date: Mon, 1 Sep 2008 13:22:09 +0800
Subject: [PATCH] KVM: VMX: Always return 0 for clear_flush_young() when using EPT
As well as discard fake accessed bit and dirty bit of EPT.
Signed-off-by: Sheng Yang [EMAIL PROTECTED]
---
arch/x86/kvm/mmu.c | 15 +++
arch/x86/kvm/vmx.c |3 +--
arch/x86/kvm/vmx.h |2 --
3 files changed, 12 insertions(+), 8 deletions(-)
diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index f33c594..e437985 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -716,10 +716,17 @@ static int kvm_age_rmapp(struct kvm *kvm, unsigned long *rmapp)
int _young;
u64 _spte = *spte;
BUG_ON(!(_spte PT_PRESENT_MASK));
- _young = _spte PT_ACCESSED_MASK;
- if (_young) {
- young = 1;
- clear_bit(PT_ACCESSED_SHIFT, (unsigned long *)spte);
+
+ /* always return old for EPT */
+ if (!shadow_accessed_mask)
+ _young = 0;
+ else {
+ _young = _spte PT_ACCESSED_MASK;
+ if (_young) {
+young = 1;
+clear_bit(PT_ACCESSED_SHIFT,
+ (unsigned long *)spte);
+ }
}
spte = rmap_next(kvm, rmapp, spte);
}
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 81c121c..d637897 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -3557,8 +3557,7 @@ static int __init vmx_init(void)
kvm_mmu_set_base_ptes(VMX_EPT_READABLE_MASK |
VMX_EPT_WRITABLE_MASK
