[kvm-devel] KVM Test result, kernel 90af65.. , userspace ad220a..
Hi, all This is today's KVM test result against kvm.git 90af65e22b7ef28aa0dc6d16ff42dee1b5329a82 and kvm-userspace.git ad220afdd1473a13dca92d88ea9daae335ba8347. One issue has been fixed: 1. 64bit host crashes when booting guests https://sourceforge.net/tracker/?func=detailatid=893831aid=1832246group_id=180599 Old issues: 1. Save/restore causes 64bit host to crash https://sourceforge.net/tracker/?func=detailatid=893831aid=1831586group_id=180599 2. xpsp2 with 2vpus may fail to boot -no-kvm-irqchip has the same issue. It exists on paxville,woodcrest and clowertown, but doesn't exist on weybridge and santarosa. https://sourceforge.net/tracker/index.php?func=detailaid=1805017group_id=180599atid=893831 3. Cannot boot 32bit smp RHEL5.1 guest Only -on-kvm can boot it. https://sourceforge.net/tracker/?func=detailatid=893831aid=1812043group_id=180599 4 Some ltp cases fail on KVM guests https://sourceforge.net/tracker/index.php?func=detailaid=1741316group_id=180599atid=893831 5. 64bit KVM guest fails to save/restore. https://sourceforge.net/tracker/index.php?func=detailaid=1824525group_id=180599atid=893831 6. Timer of SMP linux guest timer is inaccurate By network timer the time-cost of make kernel is about 180s, while by guest timer it's 137s. https://sourceforge.net/tracker/index.php?func=detailaid=1826080group_id=180599atid=893831 Test environment Platform woodcrest CPU 16 Memory size 8G' Details PAE: 1. boot guest with 256M memory PASS 2. boot two windows xp guest PASS 3. boot 4 same guest in parallel PASS 4. boot linux and windows guest in parallel PASS 5. boot 4G linux guest PASS 6. boot guest with 1500M memory PASS 7. boot windows 2003 with ACPI enabled PASS 8. boot Windows xp with ACPI enabled PASS 9. boot Windows 2000 without ACPI PASS 10. kernel build on SMP linux guest PASS 11. LTP on SMP linux guest PASS 12. boot base kernel linux PASS 13. save/restore 32-bit HVM guests FAIL 14. live migration 32-bit HVM guests FAIL 15. boot SMP Windows xp with ACPI enabled FAIL 16. boot SMP windows 2003 with ACPI enabled FAIL 17. boot SMP Windows 2000 with ACPI enabled FAIL IA32e: 1. boot four 32-bit guest in parallel PASS 2. boot four 64-bit guest in parallel PASS 3. boot 4G 64-bit guest PASS 4. boot 4G pae guest PASS 5. boot 32-bit linux and 32 bit windows guest in parallel PASS 6. boot 32-bit guest with 1500M memory PASS 7. boot 64-bit guest with 1500M memory PASS 8. boot 32-bit guest with 256M memory PASS 9. boot 64-bit guest with 256M memory PASS 10. boot two 32-bit windows xp in parallel PASS 11. boot four 32-bit different guest in para PASS 12. save/restore 64-bit linux guests FAIL 13. save/restore 32-bit linux guests FAIL 14. boot 32-bit SMP windows 2003 with ACPI enabled FAIL 15. boot 32bit SMP Windows 2000 with ACPI enabled FAIL 16. boot 32-bit SMP Windows xp with ACPI enabled FAIL 17. boot 32-bit Windows 2000 without ACPI PASS 18. boot 64-bit Windows xp with ACPI enabled PASS 19. boot 32-bit Windows xp without ACPI PASS 20. boot 64-bit vista PASS 21. kernel build in 32-bit linux guest OS PASS 22. kernel build in 64-bit linux guest OS PASS 23. LTP on SMP 32-bit linux guest OS PASS 24. LTP on SMP 64-bit linux guest OS PASS 25. boot 64-bit guests with ACPI enabled PASS 26. boot 32-bit x-server PASS 27. boot 64-bit SMP windows XP with ACPI enabled FAIL 28. boot 64-bit SMP windows 2003 with ACPI enabled PASS Report Summary on IA32-pae Summary Test Report of Last Session = Total PassFailNoResult Crash
Re: [kvm-devel] Unhandled vm exit with old protected mode test
Avi Kivity wrote:
Jan Kiszka wrote:
Hi,
running some oldish 286 protected mode demo in kvm, I came across this
bug of kvm-52:
unhandled vm exit: 0x8021 vcpu_id 0
ds (0010/ p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0)
ds.base must equal ds.sel4 when entering real-mode on Intel. See
fix_rmode_seg() in vmx.c which clearly doesn't handle cases where
ds.base = 0x10. You might try forcing bits 20+ of ds.base to zero
in there. This may fix the problem or move it elsewhere.
Yeah, this actually fixed my test case:
Ensure that segment.base == segment.selector 4 when entering the real
mode on Intel so that the CPU will not bark at us.
Signed-off-by: Jan Kiszka [EMAIL PROTECTED]
---
kernel/vmx.c |6 --
1 file changed, 4 insertions(+), 2 deletions(-)
Index: kvm-52/kernel/vmx.c
===
--- kvm-52.orig/kernel/vmx.c
+++ kvm-52/kernel/vmx.c
@@ -1159,12 +1159,14 @@ static gva_t rmode_tss_base(struct kvm *
static void fix_rmode_seg(int seg, struct kvm_save_segment *save)
{
struct kvm_vmx_segment_field *sf = kvm_vmx_segment_fields[seg];
+ unsigned base;
save-selector = vmcs_read16(sf-selector);
- save-base = vmcs_readl(sf-base);
+ save-base = base = vmcs_readl(sf-base);
save-limit = vmcs_read32(sf-limit);
save-ar = vmcs_read32(sf-ar_bytes);
- vmcs_write16(sf-selector, vmcs_readl(sf-base) 4);
+ vmcs_write16(sf-selector, base 4);
+ vmcs_write32(sf-base, base 0xf);
vmcs_write32(sf-limit, 0x);
vmcs_write32(sf-ar_bytes, 0xf3);
}
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [PATCH] 0/5 kvm.h split
In order to make kvm.h arch-independent, some code need to move out from kvm.h. Now, we move them to x86.h. This is the preparetion for splitting struct kvm and struct kvm_vcpu. [1/5] Move some macro definitions out. [2/5] Move kvm_x86_ops out. [3/5] Move vcpu regs enumeration defintions out [4/5] Move some x86-specific static functions out. [5/5] Move some x86-specific function declares out. Xiantao - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [PATCH] 2/5 Move out kvm_x86_ops
Xiantao 0002-Move-strcut-kvm_x86_ops-defintion-to-x86.h.patch Description: 0002-Move-strcut-kvm_x86_ops-defintion-to-x86.h.patch - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [PATCH] 3/5 Move out vcpu regs defintion.
Xiantao 0003-Move-vcpu-regs-enumeration-defintion-to-x86.h.patch Description: 0003-Move-vcpu-regs-enumeration-defintion-to-x86.h.patch - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [PATCH] 4/5 Move out some static functions.
Xiantao 0004-Move-some-static-inline-functions-out-from-kvm.h.patch Description: 0004-Move-some-static-inline-functions-out-from-kvm.h.patch - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [PATCH] 5/5 Move out some x86-specific function declares
Xiantao 0005-Move-some-function-declares-to-x86.h.patch Description: 0005-Move-some-function-declares-to-x86.h.patch - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [PATCH] 1/5 Move out some x86-specific macro definitions
0001-Move-some-macro-definitions-to-x86.h.patch Description: 0001-Move-some-macro-definitions-to-x86.h.patch - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [PATCH][RFC] Struct kvm split
Hi Avi, Based on privious discussion, I made this patch to split struct kvm. In this patch, strcut kvm only holds common fields, and struct kvm_x86 will keep x86-specific fields. In this way, struct kvm will be a sub-filed in struct kvm_x86, and we can use to_kvm_x86 to get kvm_x86 from struct kvm. It is very similar with current to_vmx approach for getting struct vmx from struct kvm_vcpu.This is a rough split based on this idea. Any comments are welcome! Best Wishes! Xiantao 0006-Use-kvm_x86-to-hold-x86-specific-kvm-fields.patch Description: 0006-Use-kvm_x86-to-hold-x86-specific-kvm-fields.patch - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] Found first KVM-52 regression
Just Found first KVM-52 regression. SUSE 9.1 ceases to boot. It turned out this commit, that killed it: KVM-51-2 - (ab4e018dc95e1b32b7f25746eb9b2c1385aec93e) Avi: Could you please take a look at it ? -Alexey - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [ kvm-Bugs-1834513 ] Regression: SUSE Linux 9.1 ceased to install on KVM-52
Bugs item #1834513, was opened at 2007-11-19 14:40 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=893831aid=1834513group_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: Technologov (technologov) Assigned to: Nobody/Anonymous (nobody) Summary: Regression: SUSE Linux 9.1 ceased to install on KVM-52 Initial Comment: Just Found first KVM-52 regression. SUSE 9.1 ceases to boot. Just stucks at the bootloader stage. It turned out, that this is the commit, that killed it: KVM-51-2 - (ab4e018dc95e1b32b7f25746eb9b2c1385aec93e) (VMX injection of interrupts) Host: Fedora 7/x64, Intel CPU, KVM-52. -Alexey. 19.11.2007. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=893831aid=1834513group_id=180599 - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] 0/3 MMU code split
Zhang, Xiantao wrote: Hi Avi, Considering your comments,I refined the patch, and use kvm-memslots to caculate the nr_mmu_pagas every time. Patch [1/3] Move kvm_vcpu_iotcl_get_dirty_log implementation into arch, and still keep the interface in common. Patch [2/3] Move kvm_mmu init and exit functionality to arch. First two applied (missing a signoff on the first!). Patch [3/3] Add the hook kvm_arch_set_memory_region. In this patch, introduce a function kvm_caculate_mmu_pages to compute mmu pages in total, once memory region changes. Please split this into two. First part makes the real changes (kvm_calculate_mmu_changes) and the second part does the movement. This makes it much easier to review and bisect. Also, please send patches using git-send-email, that way the patches show inline and it is easier to review and comment. -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] 0/5 kvm.h split
Zhang, Xiantao wrote: In order to make kvm.h arch-independent, some code need to move out from kvm.h. Now, we move them to x86.h. This is the preparetion for splitting struct kvm and struct kvm_vcpu. [1/5] Move some macro definitions out. [2/5] Move kvm_x86_ops out. [3/5] Move vcpu regs enumeration defintions out [4/5] Move some x86-specific static functions out. [5/5] Move some x86-specific function declares out. Thanks, applied all. -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] Early Christmas gift
Radisson Hotel claims 30% cut in energy cost due to et GU EnerBrite Technologies Group, Inc. ETGU $0.008 The top five reasons to consider ET gU 1. Energy problems are a Global issue 2. Government sees no real relief in sight. Corporations are finding their own way out. 3. SensorStat, is already providing huge relief to businesses in Florida with reductions as high as 30 percent. 4. Already, Hotels like Radisson and Clarion are boasting e T gu's solution helps them meet the challenge of energy in today's market. 5. EnerBrite will be releasing more news in a media campaign this coming week. Penny stocks are hot and have huge potential, especially when you look at the timing this company has in the market. Take the time out and read the news, look at the price and get going on ET G u before the bell on Monday. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] Unhandled vm exit with old protected mode test
Jan Kiszka wrote: Avi Kivity wrote: Jan Kiszka wrote: Hi, running some oldish 286 protected mode demo in kvm, I came across this bug of kvm-52: unhandled vm exit: 0x8021 vcpu_id 0 ds (0010/ p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) ds.base must equal ds.sel4 when entering real-mode on Intel. See fix_rmode_seg() in vmx.c which clearly doesn't handle cases where ds.base = 0x10. You might try forcing bits 20+ of ds.base to zero in there. This may fix the problem or move it elsewhere. Yeah, this actually fixed my test case: Ensure that segment.base == segment.selector 4 when entering the real mode on Intel so that the CPU will not bark at us. Applied (after de-optimizing), thanks. -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH][RFC] Struct kvm split
Zhang, Xiantao wrote: Based on privious discussion, I made this patch to split struct kvm. In this patch, strcut kvm only holds common fields, and struct kvm_x86 will keep x86-specific fields. In this way, struct kvm will be a sub-filed in struct kvm_x86, and we can use to_kvm_x86 to get kvm_x86 from struct kvm. It is very similar with current to_vmx approach for getting struct vmx from struct kvm_vcpu.This is a rough split based on this idea. Any comments are welcome! Patch #2 does'nt apply for me, on top of #1 on today's kvm.git: [EMAIL PROTECTED]:~/kvm$ quilt push Wende Patch 0002-Move-strcut-kvm_x86_ops-defintion-to-x86.h.patch an (Stripping trailing CRs from patch.) patching file drivers/kvm/kvm.h (Stripping trailing CRs from patch.) patching file drivers/kvm/x86.h patch: malformed patch at line 169: int kvm_mmu_page_fault(struct kvm_vcpu *vcpu, gva_t gva, u32 error_code); Patch 0002-Move-strcut-kvm_x86_ops-defintion-to-x86.h.patch lässt sich nicht anwenden (erzwingen mit -f) - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH][1/3] Move kvm_vcpu_iotcl_get_dirty_log to arch
Zhang, Xiantao wrote:
Move kvm_vcpu_ioctl_get_dirty_log to arch, and still keep the interface
in common.
diff --git a/drivers/kvm/kvm_main.c b/drivers/kvm/kvm_main.c
index 45b18e1..3400265 100644
--- a/drivers/kvm/kvm_main.c
+++ b/drivers/kvm/kvm_main.c
@@ -419,19 +419,14 @@ int kvm_vm_ioctl_set_memory_region(struct kvm *kvm,
return kvm_set_memory_region(kvm, mem, user_alloc);
}
-/*
- * Get (and clear) the dirty memory log for a memory slot.
- */
-static int kvm_vm_ioctl_get_dirty_log(struct kvm *kvm,
- struct kvm_dirty_log *log)
+int kvm_get_dirty_log(struct kvm *kvm,
+ struct kvm_dirty_log *log, int *is_dirty)
Any reason to remove that comment? It looks helpful to me.
{
struct kvm_memory_slot *memslot;
int r, i;
int n;
unsigned long any = 0;
- mutex_lock(kvm-lock);
-
r = -EINVAL;
if (log-slot = KVM_MEMORY_SLOTS)
goto out;
@@ -450,17 +445,11 @@ static int kvm_vm_ioctl_get_dirty_log(struct kvm
*kvm,
if (copy_to_user(log-dirty_bitmap, memslot-dirty_bitmap, n))
goto out;
- /* If nothing is dirty, don't bother messing with page tables. */
- if (any) {
- kvm_mmu_slot_remove_write_access(kvm, log-slot);
- kvm_flush_remote_tlbs(kvm);
- memset(memslot-dirty_bitmap, 0, n);
- }
+ if (any)
+ *is_dirty = 1;
r = 0;
-
out:
- mutex_unlock(kvm-lock);
return r;
}
This split won't work on s390. I think kvm_get_dirty_log should be
arch dependent alltogether: we're not going to have a dirty bitmap on
s390, we rather rely on our hardware support to update our storage
keys accordingly without guest/host intervention required. We'd want
to use that, and thus this implementation of kvm_get_dirty_log makes
no sense for us. On the other hand, I'd really want to keep the ioctl
common, so that guest migration code in userland can be common for all
archs.
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [Patch][2/3] Move kvm_mmu init and exit functionality to arch.
Zhang, Xiantao wrote: Move kvm_mmu init and exit functionality to arch. Acked-by: Carsten Otte [EMAIL PROTECTED] - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH][1/3] Move kvm_vcpu_iotcl_get_dirty_log to arch
Carsten Otte wrote:
Zhang, Xiantao wrote:
Move kvm_vcpu_ioctl_get_dirty_log to arch, and still keep the interface
in common.
diff --git a/drivers/kvm/kvm_main.c b/drivers/kvm/kvm_main.c
index 45b18e1..3400265 100644
--- a/drivers/kvm/kvm_main.c
+++ b/drivers/kvm/kvm_main.c
@@ -419,19 +419,14 @@ int kvm_vm_ioctl_set_memory_region(struct kvm *kvm,
return kvm_set_memory_region(kvm, mem, user_alloc);
}
-/*
- * Get (and clear) the dirty memory log for a memory slot.
- */
-static int kvm_vm_ioctl_get_dirty_log(struct kvm *kvm,
- struct kvm_dirty_log *log)
+int kvm_get_dirty_log(struct kvm *kvm,
+struct kvm_dirty_log *log, int *is_dirty)
Any reason to remove that comment? It looks helpful to me.
{
struct kvm_memory_slot *memslot;
int r, i;
int n;
unsigned long any = 0;
-mutex_lock(kvm-lock);
-
r = -EINVAL;
if (log-slot = KVM_MEMORY_SLOTS)
goto out;
@@ -450,17 +445,11 @@ static int kvm_vm_ioctl_get_dirty_log(struct kvm
*kvm,
if (copy_to_user(log-dirty_bitmap, memslot-dirty_bitmap, n))
goto out;
-/* If nothing is dirty, don't bother messing with page tables. */
-if (any) {
-kvm_mmu_slot_remove_write_access(kvm, log-slot);
-kvm_flush_remote_tlbs(kvm);
-memset(memslot-dirty_bitmap, 0, n);
-}
+if (any)
+*is_dirty = 1;
r = 0;
-
out:
-mutex_unlock(kvm-lock);
return r;
}
This split won't work on s390. I think kvm_get_dirty_log should be
arch dependent alltogether: we're not going to have a dirty bitmap on
s390, we rather rely on our hardware support to update our storage
keys accordingly without guest/host intervention required. We'd want
to use that, and thus this implementation of kvm_get_dirty_log makes
no sense for us. On the other hand, I'd really want to keep the ioctl
common, so that guest migration code in userland can be common for all
archs.
On the other hand, it will work for all others IIUC. Duplicating it in
all other archs is not a good idea.
We can special case it using #ifdef ARCH_HAS_KVM_GUEST_DIRTY_BITMAP or
something.
(hides from the #ifdef police)
--
error compiling committee.c: too many arguments to function
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH][1/3] Move kvm_vcpu_iotcl_get_dirty_log to arch
Avi Kivity wrote:
Carsten Otte wrote:
Zhang, Xiantao wrote:
Move kvm_vcpu_ioctl_get_dirty_log to arch, and still keep the interface
in common.
diff --git a/drivers/kvm/kvm_main.c b/drivers/kvm/kvm_main.c
index 45b18e1..3400265 100644
--- a/drivers/kvm/kvm_main.c
+++ b/drivers/kvm/kvm_main.c
@@ -419,19 +419,14 @@ int kvm_vm_ioctl_set_memory_region(struct kvm *kvm,
return kvm_set_memory_region(kvm, mem, user_alloc);
}
-/*
- * Get (and clear) the dirty memory log for a memory slot.
- */
-static int kvm_vm_ioctl_get_dirty_log(struct kvm *kvm,
- struct kvm_dirty_log *log)
+int kvm_get_dirty_log(struct kvm *kvm,
+struct kvm_dirty_log *log, int *is_dirty)
Any reason to remove that comment? It looks helpful to me.
{
struct kvm_memory_slot *memslot;
int r, i;
int n;
unsigned long any = 0;
-mutex_lock(kvm-lock);
-
r = -EINVAL;
if (log-slot = KVM_MEMORY_SLOTS)
goto out;
@@ -450,17 +445,11 @@ static int kvm_vm_ioctl_get_dirty_log(struct kvm
*kvm,
if (copy_to_user(log-dirty_bitmap, memslot-dirty_bitmap, n))
goto out;
-/* If nothing is dirty, don't bother messing with page tables. */
-if (any) {
-kvm_mmu_slot_remove_write_access(kvm, log-slot);
-kvm_flush_remote_tlbs(kvm);
-memset(memslot-dirty_bitmap, 0, n);
-}
+if (any)
+*is_dirty = 1;
r = 0;
-
out:
-mutex_unlock(kvm-lock);
return r;
}
This split won't work on s390. I think kvm_get_dirty_log should be
arch dependent alltogether: we're not going to have a dirty bitmap on
s390, we rather rely on our hardware support to update our storage
keys accordingly without guest/host intervention required. We'd want
to use that, and thus this implementation of kvm_get_dirty_log makes
no sense for us. On the other hand, I'd really want to keep the ioctl
common, so that guest migration code in userland can be common for all
archs.
On the other hand, it will work for all others IIUC. Duplicating it in
all other archs is not a good idea.
We can special case it using #ifdef ARCH_HAS_KVM_GUEST_DIRTY_BITMAP or
something.
(hides from the #ifdef police)
Yea, I agree that it would make sense in case it works for power too.
We could have an
#ifdef CONFIG_ARCH_S390
return cool_big_iron_get_dirty_log(args);
#endif
at the beginning of that function. It would'nt hurt readability too much.
Hollis? Christian? How about ppc?
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] Add the hook kvm_arch_set_memory region to hold mmu-specific changes
Carsten Otte wrote: Zhang, Xiantao wrote: Patch [3/3] Add the hook kvm_arch_set_memory_region. In this patch, introduce a function kvm_caculate_mmu_pages to compute mmu pages in total, once memory region changes.diff --git a/drivers/kvm/kvm_main.c b/drivers/kvm/kvm_main.c mutex_lock(kvm-lock); r = __kvm_set_memory_region(kvm, mem, user_alloc); + if (r == 0) + kvm_arch_set_memory_region(kvm, mem); mutex_unlock(kvm-lock); return r; } This split of __kvm_set_memory_region assumes that all architectures have physmem slots. I support Avi's suggestion to have user allocated memory as new portable approach, and this old kernel-allocation based one x86 only. If that's where we're heading, this split is the wrong approach. I think we can come up with something smarter then move the whole thing to x86 in this case, but all cases that have user_alloc == 1 should really be handled by x86.c code. User-allocation should be what we are heading. But considering compatibility with old user-space support, I think kernel-allocation approach should exist for a long time. I think we don't need to consider this case now. Once the kernel-allocation approach is abandoned in future, as you say, we can move them all into x86. Xiantao - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH][1/3] Move kvm_vcpu_iotcl_get_dirty_log to arch
Carsten Otte wrote: Yea, I agree that it would make sense in case it works for power too. We could have an #ifdef CONFIG_ARCH_S390 return cool_big_iron_get_dirty_log(args); #endif at the beginning of that function. It would'nt hurt readability too much. Stupid suggestion. We could outsource the #ifdef to the caller, that would be much cleaner. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] Add the hook kvm_arch_set_memory region to hold mmu-specific changes
Zhang, Xiantao wrote: User-allocation should be what we are heading. But considering compatibility with old user-space support, I think kernel-allocation approach should exist for a long time. That's right. This is why I would prefer to have the corresponding code out of kvm_main.c: it may exist for a long time for x86. I think we don't need to consider this case now. Once the kernel-allocation approach is abandoned in future, as you say, we can move them all into x86. I'd rather prefer to move it upfront. Otherwise, I'd have to consider that case for s390 as long as it remains in common. At least I'd have to make sure it does'nt get used on s390 using an if() or #ifdef. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] Add the hook kvm_arch_set_memory region to hold mmu-specific changes
Carsten Otte wrote: Zhang, Xiantao wrote: User-allocation should be what we are heading. But considering compatibility with old user-space support, I think kernel-allocation approach should exist for a long time. That's right. This is why I would prefer to have the corresponding code out of kvm_main.c: it may exist for a long time for x86. I think we don't need to consider this case now. Once the kernel-allocation approach is abandoned in future, as you say, we can move them all into x86. I'd rather prefer to move it upfront. Otherwise, I'd have to consider that case for s390 as long as it remains in common. At least I'd have to make sure it does'nt get used on s390 using an if() or #ifdef. I agree, other archs shouldn't have to suffer. -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [ kvm-Bugs-1834585 ] install from iso fails on 2.6.23.8 kernel
Bugs item #1834585, was opened at 2007-11-19 16:16 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=893831aid=1834585group_id=180599 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: intel Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: erik (erjomo) Assigned to: Nobody/Anonymous (nobody) Summary: install from iso fails on 2.6.23.8 kernel Initial Comment: Hi, When trying to install debian-testing with kvm, I get as far as Configuring apt, scanning the mirror and eventually a crash with a segmentation fault. qemu-img create -f qcow d.img 10G sudo kvm -cdrom debian-testing-i386-netinst.iso -hda d.img -boot d -m 1024 i'm running a custom kernel 2.6.23.8 on an x86-64 core 2 duo machine built whith gcc (Debian 4.2.2-3). kvm version is 52+dfsg-1, kvm-modules-2.6.23.8-x86-64 has 52+dfsg-1+2.6.23.8-x86-64-10.00.Custom When running a distribution kernel (debian 2.6.22-3-amd64) there are no problems. Also running an image once installed works allright under the custom kernel. (I tried Windows XP, debian testing) with --no-kvm flag there is no crash, but an error message 'Bad archive mirror regards erik -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=893831aid=1834585group_id=180599 - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH][RFC] Struct kvm split
Zhang, Xiantao wrote: Carsten Otte wrote: Zhang, Xiantao wrote: Based on privious discussion, I made this patch to split struct kvm. In this patch, strcut kvm only holds common fields, and struct kvm_x86 will keep x86-specific fields. In this way, struct kvm will be a sub-filed in struct kvm_x86, and we can use to_kvm_x86 to get kvm_x86 from struct kvm. It is very similar with current to_vmx approach for getting struct vmx from struct kvm_vcpu.This is a rough split based on this idea. Any comments are welcome! Patch #2 does'nt apply for me, on top of #1 on today's kvm.git: [EMAIL PROTECTED]:~/kvm$ quilt push Wende Patch 0002-Move-strcut-kvm_x86_ops-defintion-to-x86.h.patch an (Stripping trailing CRs from patch.) patching file drivers/kvm/kvm.h (Stripping trailing CRs from patch.) patching file drivers/kvm/x86.h patch: malformed patch at line 169: int kvm_mmu_page_fault(struct kvm_vcpu *vcpu, gva_t gva, u32 error_code); Patch 0002-Move-strcut-kvm_x86_ops-defintion-to-x86.h.patch lässt sich nicht anwenden (erzwingen mit -f) Hi, Carsten The first 5 patches have been checked into upstream tree. Maybe you can have a pull. For the sixth one, it can be applied on the latest commits. Xiantao They only applied after much massaging by me (I forgot to complain, sorry). Please use git-send-email, it's much better at getting the patches out undamaged. -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] Add the hook kvm_arch_set_memory region to hold mmu-specific changes
Avi Kivity wrote: Carsten Otte wrote: Zhang, Xiantao wrote: User-allocation should be what we are heading. But considering compatibility with old user-space support, I think kernel-allocation approach should exist for a long time. That's right. This is why I would prefer to have the corresponding code out of kvm_main.c: it may exist for a long time for x86. I think we don't need to consider this case now. Once the kernel-allocation approach is abandoned in future, as you say, we can move them all into x86. I'd rather prefer to move it upfront. Otherwise, I'd have to consider that case for s390 as long as it remains in common. At least I'd have to make sure it does'nt get used on s390 using an if() or #ifdef. I agree, other archs shouldn't have to suffer. So, now we move the whole thing(__kvm_set_memory_region) into arch ? :) Xiantao - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH][RFC] Struct kvm split
Avi Kivity wrote: Zhang, Xiantao wrote: Carsten Otte wrote: Zhang, Xiantao wrote: Based on privious discussion, I made this patch to split struct kvm. In this patch, strcut kvm only holds common fields, and struct kvm_x86 will keep x86-specific fields. In this way, struct kvm will be a sub-filed in struct kvm_x86, and we can use to_kvm_x86 to get kvm_x86 from struct kvm. It is very similar with current to_vmx approach for getting struct vmx from struct kvm_vcpu. This is a rough split based on this idea. Any comments are welcome! Patch #2 does'nt apply for me, on top of #1 on today's kvm.git: [EMAIL PROTECTED]:~/kvm$ quilt push Wende Patch 0002-Move-strcut-kvm_x86_ops-defintion-to-x86.h.patch an (Stripping trailing CRs from patch.) patching file drivers/kvm/kvm.h (Stripping trailing CRs from patch.) patching file drivers/kvm/x86.h patch: malformed patch at line 169: int kvm_mmu_page_fault(struct kvm_vcpu *vcpu, gva_t gva, u32 error_code); Patch 0002-Move-strcut-kvm_x86_ops-defintion-to-x86.h.patch lässt sich nicht anwenden (erzwingen mit -f) Hi, Carsten The first 5 patches have been checked into upstream tree. Maybe you can have a pull. For the sixth one, it can be applied on the latest commits. Xiantao They only applied after much massaging by me (I forgot to complain, sorry). Please use git-send-email, it's much better at getting the patches out undamaged. OK, I will try to use git-send-email for patch out next time, although seems it also have something wrong at my side. :) Xiantao - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [PATCH] KVM: SVM: Fix FPU leak and re-enable lazy FPU switching
The clts code didn't use set_cr0 properly, so our lazy FPU
processing wasn't being done by the clts instruction at all.
This fixes all the FPU leaks, so re-enabling lazy FPU
optimization.
Signed-off-by: Amit Shah [EMAIL PROTECTED]
---
drivers/kvm/svm.c |2 --
drivers/kvm/x86.c |3 +--
2 files changed, 1 insertions(+), 4 deletions(-)
diff --git a/drivers/kvm/svm.c b/drivers/kvm/svm.c
index 1c3cc3e..928fb35 100644
--- a/drivers/kvm/svm.c
+++ b/drivers/kvm/svm.c
@@ -1601,13 +1601,11 @@ static void svm_set_cr3(struct kvm_vcpu *vcpu, unsigned
long root)
svm-vmcb-save.cr3 = root;
force_new_asid(vcpu);
-#if 0 /* lazy fpu is broken on AMD for now */
if (vcpu-fpu_active) {
svm-vmcb-control.intercept_exceptions |= (1 NM_VECTOR);
svm-vmcb-save.cr0 |= X86_CR0_TS;
vcpu-fpu_active = 0;
}
-#endif
}
static void svm_inject_page_fault(struct kvm_vcpu *vcpu,
diff --git a/drivers/kvm/x86.c b/drivers/kvm/x86.c
index f832aa0..69b00da 100644
--- a/drivers/kvm/x86.c
+++ b/drivers/kvm/x86.c
@@ -1283,8 +1283,7 @@ int emulate_invlpg(struct kvm_vcpu *vcpu, gva_t address)
int emulate_clts(struct kvm_vcpu *vcpu)
{
- vcpu-cr0 = ~X86_CR0_TS;
- kvm_x86_ops-set_cr0(vcpu, vcpu-cr0);
+ kvm_x86_ops-set_cr0(vcpu, vcpu-cr0 ~X86_CR0_TS);
return X86EMUL_CONTINUE;
}
--
1.5.3
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [ kvm-Bugs-1834719 ] bad_page in kvm_qemu when running Windows XP SP2
Bugs item #1834719, was opened at 2007-11-20 02:58 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=893831aid=1834719group_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: William Poetra Yoga Hadisoeseno (williampoetra) Assigned to: Nobody/Anonymous (nobody) Summary: bad_page in kvm_qemu when running Windows XP SP2 Initial Comment: Host OS: Linux 2.6.22.10 (vanilla) Host Bitness: 32 Guest OS: Windows XP SP2 Guest Bitness: 32 GCC: 4.1.2 CPU: T5600 RAM: 1 GB (allocated 256 MB for kvm_qemu) KVM Version: 0.52 Description: I ran kvm_qemu without modprobe-ing kvm-intel, and it just died. I didn't check the kernel logs (didn't suspect anything), and loaded the kvm-intel module. After that, I re-ran kvm, and connected to it through rdp. Initially everything was fine, I logged in and got to the desktop, but after a few seconds my mouse clicks weren't detected by the guest OS, and then a few seconds later my machine freezed, requiring a reboot. The logs below are taken from /var/log/kernel, after rebooting. The command is: kvm_qemu \ -hda c.img \ -no-reboot \ -nographic \ -localtime \ -m 256 \ -alt-grab \ -smb /home/william \ -redir tcp:3389::3389 Nov 20 02:01:09 darkstar kernel: kvm: guest NX capability removed Nov 20 02:01:16 darkstar kernel: kvm: emulating exchange as write Nov 20 02:03:02 darkstar kernel: Bad page state in process 'kvm_qemu' Nov 20 02:03:03 darkstar kernel: page:c138dfc0 flags:0x4014 mapping: mapcount:1 count:0 Nov 20 02:03:03 darkstar kernel: Trying to fix it up, but a reboot is needed Nov 20 02:03:03 darkstar kernel: Backtrace: Nov 20 02:03:03 darkstar kernel: [c0151712] bad_page+0x62/0xa0 Nov 20 02:03:03 darkstar kernel: [c0151c71] free_hot_cold_page+0x151/0x160 Nov 20 02:03:03 darkstar kernel: [f8e06a4a] rmap_remove+0x5a/0x180 [kvm] Nov 20 02:03:03 darkstar kernel: [f8e06d7d] kvm_mmu_zap_page+0x20d/0x250 [kvm] Nov 20 02:03:03 darkstar kernel: [f8e082cd] kvm_mmu_pte_write+0x20d/0x3e0 [kvm] Nov 20 02:03:03 darkstar kernel: [f8e01bf1] kvm_write_guest_page+0x71/0xa0 [kvm] Nov 20 02:03:03 darkstar kernel: [f8e03910] emulator_write_emulated_onepage+0xb0/0x140 [kvm] Nov 20 02:03:03 darkstar kernel: [f8e0a741] x86_emulate_insn+0x571/0x33c0 [kvm] Nov 20 02:03:03 darkstar kernel: [f8e01cdd] kvm_read_guest_page+0x5d/0x80 [kvm] Nov 20 02:03:03 darkstar kernel: [f8e01d4d] kvm_read_guest+0x4d/0x60 [kvm] Nov 20 02:03:03 darkstar kernel: [f8e03b3f] emulator_read_std+0x3f/0x90 [kvm] Nov 20 02:03:03 darkstar kernel: [f8e097eb] x86_decode_insn+0x9b/0xa80 [kvm] Nov 20 02:03:03 darkstar kernel: [f8e03d8c] emulate_instruction+0x16c/0x2a0 [kvm] Nov 20 02:03:03 darkstar kernel: [f8e078e4] kvm_mmu_page_fault+0x64/0xa0 [kvm] Nov 20 02:03:03 darkstar kernel: [f8d2e579] kvm_handle_exit+0x79/0xc0 [kvm_intel] Nov 20 02:03:04 darkstar kernel: [f8d2c294] vmcs_readl+0x14/0x20 [kvm_intel] Nov 20 02:03:04 darkstar kernel: [f8d2e6af] vmx_vcpu_run+0xef/0x110 [kvm_intel] Nov 20 02:03:04 darkstar kernel: [f8e05cec] kvm_arch_vcpu_ioctl_run+0xec/0x420 [kvm] Nov 20 02:03:04 darkstar kernel: [f8e028f0] kvm_vcpu_ioctl+0x0/0x410 [kvm] Nov 20 02:03:04 darkstar kernel: [f8e02ca3] kvm_vcpu_ioctl+0x3b3/0x410 [kvm] Nov 20 02:03:04 darkstar kernel: [c023cfab] dev_queue_xmit+0x9b/0x350 Nov 20 02:03:04 darkstar kernel: [c025f221] ip_output+0x1a1/0x340 Nov 20 02:03:04 darkstar kernel: [c011d891] __activate_task+0x21/0x40 Nov 20 02:03:04 darkstar kernel: [c011f8e1] try_to_wake_up+0x41/0x3c0 Nov 20 02:03:05 darkstar kernel: [c017a0b2] core_sys_select+0x242/0x2e0 Nov 20 02:03:05 darkstar kernel: [c011d619] __wake_up_common+0x39/0x70 Nov 20 02:03:05 darkstar kernel: [c011dc78] __wake_up+0x38/0x50 Nov 20 02:03:05 darkstar kernel: [c014129b] wake_futex+0x3b/0x50 Nov 20 02:03:05 darkstar kernel: [c014261d] futex_wake+0xad/0xd0 Nov 20 02:03:05 darkstar kernel: [c012eae0] __dequeue_signal+0x10/0x170 Nov 20 02:03:05 darkstar kernel: [c012e82b] recalc_sigpending+0xb/0x20 Nov 20 02:03:05 darkstar kernel: [c0130507] dequeue_signal+0x47/0x170 Nov 20 02:03:05 darkstar kernel: [f8e02405] kvm_vm_ioctl+0x35/0x290 [kvm] Nov 20 02:03:05 darkstar kernel: [c01cca71] rb_insert_color+0x91/0xc0 Nov 20 02:03:05 darkstar kernel: [c013b0cb] enqueue_hrtimer+0x6b/0x110 Nov 20 02:03:06 darkstar kernel: [c013b92d] hrtimer_start+0xbd/0x130 Nov 20 02:03:06 darkstar kernel: [f8e028f0] kvm_vcpu_ioctl+0x0/0x410 [kvm] Nov 20 02:03:06 darkstar kernel: [c0178beb] do_ioctl+0x2b/0xc0 Nov 20 02:03:06 darkstar kernel: [c0137e72] sys_timer_settime+0x272/0x290 Nov 20 02:03:06 darkstar kernel: [c0178cdc] vfs_ioctl+0x5c/0x290 Nov 20 02:03:06 darkstar kernel: [c01cf540] copy_to_user+0x30/0x60
[kvm-devel] [PATCH] discard MSR writes
this patch discards MSR writes to the Performance Event-Select Registers, this is the first issue why vista seems to fail although now vista ends up in an endless loop a bit later. Qemu currently also discards those writes. Signed-off-by: Joerg Roedel [EMAIL PROTECTED] Signed-off-by: Markus Rechberger [EMAIL PROTECTED] diff --git a/drivers/kvm/svm.c b/drivers/kvm/svm.c index 1c3cc3e..1f34501 100644 --- a/drivers/kvm/svm.c +++ b/drivers/kvm/svm.c @@ -1143,6 +1143,12 @@ static int svm_set_msr(struct kvm_vcpu *vcpu, unsigned ecx, u64 data) case MSR_SYSCALL_MASK: svm-vmcb-save.sfmask = data; break; + case MSR_K7_EVNTSEL0: + case MSR_K7_EVNTSEL1: + case MSR_K7_EVNTSEL2: + case MSR_K7_EVNTSEL3: + /* discard those writes for now, required by vista 64bit */ + break; #endif case MSR_IA32_SYSENTER_CS: svm-vmcb-save.sysenter_cs = data; - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH][RFC] Struct kvm split
On Mon, 2007-11-19 at 18:05 +0800, Zhang, Xiantao wrote:
Hi Avi,
Based on privious discussion, I made this patch to split struct kvm.
In this patch, strcut kvm only holds common fields, and struct kvm_x86
will keep x86-specific fields. In this way, struct kvm will be a
sub-filed in struct kvm_x86, and we can use to_kvm_x86 to get kvm_x86
from struct kvm. It is very similar with current to_vmx approach for
getting struct vmx from struct kvm_vcpu.This is a rough split based
on this idea. Any comments are welcome!
I was very confused until I realized you're only dealing with struct
kvm, not struct kvm_vcpu. I actually started the kvm_vcpu work last
week, and it is a much larger patch. :)
Some whitespace sloppiness (e.g. struct kvm_x86{, extra blank lines in
a few places, and I'm worried about 80 columns in a few places).
Some of the fields you've left common (e.g. apic_access_page, mmio_bus,
pio_bus) should be moved, but if this split works for IA64 then it's
fine to leave those changes for other architectures.
In general I like it.
Acked-by: Hollis Blanchard [EMAIL PROTECTED]
--
Hollis Blanchard
IBM Linux Technology Center
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [PATCH 3 of 3] Remove unused rmap_overflow variable
Signed-off-by: Hollis Blanchard [EMAIL PROTECTED]
---
1 file changed, 1 deletion(-)
drivers/kvm/kvm.h |1 -
diff --git a/drivers/kvm/kvm.h b/drivers/kvm/kvm.h
--- a/drivers/kvm/kvm.h
+++ b/drivers/kvm/kvm.h
@@ -318,7 +318,6 @@ struct kvm {
unsigned int n_alloc_mmu_pages;
struct hlist_head mmu_page_hash[KVM_NUM_MMU_PAGES];
struct kvm_vcpu *vcpus[KVM_MAX_VCPUS];
- unsigned long rmap_overflow;
struct list_head vm_list;
struct file *filp;
struct kvm_io_bus mmio_bus;
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [PATCH 0 of 3] cosmetic fixes
These are a few fixes to minor/cosmetic issues I've stumbled across recently. 3 files changed, 7 insertions(+), 8 deletions(-) drivers/kvm/kvm.h | 11 +-- drivers/kvm/kvm_main.c |2 +- drivers/kvm/x86.c |2 +- - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [PATCH 2 of 3] Move misplaced comment
Signed-off-by: Hollis Blanchard [EMAIL PROTECTED]
---
1 file changed, 4 insertions(+), 4 deletions(-)
drivers/kvm/kvm.h |8
diff --git a/drivers/kvm/kvm.h b/drivers/kvm/kvm.h
--- a/drivers/kvm/kvm.h
+++ b/drivers/kvm/kvm.h
@@ -135,15 +135,15 @@ struct kvm_mmu {
#define KVM_NR_MEM_OBJS 40
+/*
+ * We don't want allocation failures within the mmu code, so we preallocate
+ * enough memory for a single page fault in a cache.
+ */
struct kvm_mmu_memory_cache {
int nobjs;
void *objects[KVM_NR_MEM_OBJS];
};
-/*
- * We don't want allocation failures within the mmu code, so we preallocate
- * enough memory for a single page fault in a cache.
- */
struct kvm_guest_debug {
int enabled;
unsigned long bp[4];
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [PATCH 1 of 3] Correct consistent typo: destory - destroy
Signed-off-by: Hollis Blanchard [EMAIL PROTECTED]
---
3 files changed, 3 insertions(+), 3 deletions(-)
drivers/kvm/kvm.h |2 +-
drivers/kvm/kvm_main.c |2 +-
drivers/kvm/x86.c |2 +-
diff --git a/drivers/kvm/kvm.h b/drivers/kvm/kvm.h
--- a/drivers/kvm/kvm.h
+++ b/drivers/kvm/kvm.h
@@ -462,7 +462,7 @@ void kvm_arch_vcpu_load(struct kvm_vcpu
void kvm_arch_vcpu_load(struct kvm_vcpu *vcpu, int cpu);
void kvm_arch_vcpu_put(struct kvm_vcpu *vcpu);
struct kvm_vcpu *kvm_arch_vcpu_create(struct kvm *kvm, unsigned int id);
-void kvm_arch_vcpu_destory(struct kvm_vcpu *vcpu);
+void kvm_arch_vcpu_destroy(struct kvm_vcpu *vcpu);
int kvm_arch_vcpu_reset(struct kvm_vcpu *vcpu);
void kvm_arch_hardware_enable(void *garbage);
diff --git a/drivers/kvm/kvm_main.c b/drivers/kvm/kvm_main.c
--- a/drivers/kvm/kvm_main.c
+++ b/drivers/kvm/kvm_main.c
@@ -838,7 +838,7 @@ unlink:
kvm-vcpus[n] = NULL;
mutex_unlock(kvm-lock);
vcpu_destroy:
- kvm_arch_vcpu_destory(vcpu);
+ kvm_arch_vcpu_destroy(vcpu);
return r;
}
diff --git a/drivers/kvm/x86.c b/drivers/kvm/x86.c
--- a/drivers/kvm/x86.c
+++ b/drivers/kvm/x86.c
@@ -2513,7 +2513,7 @@ fail:
return ERR_PTR(r);
}
-void kvm_arch_vcpu_destory(struct kvm_vcpu *vcpu)
+void kvm_arch_vcpu_destroy(struct kvm_vcpu *vcpu)
{
vcpu_load(vcpu);
kvm_mmu_unload(vcpu);
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 7/24] consolidate msr.h
On Mon, 19 Nov 2007, Bastian Blank wrote: On Fri, Nov 09, 2007 at 04:42:48PM -0200, Glauber de Oliveira Costa wrote: - wrmsrl(MSR_CSTAR, ia32_cstar_target); + wrmsrl(MSR_CSTAR, (u64)ia32_cstar_target); Hmm, why do you add explicit casts? The compiler should convert that correctly on its own. +static inline void wrmsrl(unsigned int msr, unsigned long long val) Hmm, long long is 64 bit on all x86, but why not use explicit u64 to show that? (quick reply) With PVOPS on it gives compiler warnings without that explict cast. Without looking at the code, IIRC with non-PVOPS it is a macro directly into asm, so it didn't matter what the cast was. But with PVOPS as a function, it gave compiler warnings. Take it out and try compiling it for both i386 and x86_64. One of them gave warnings. But maybe it's not a problem now. -- Steve - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] Move kvm_regs to asm-x86/kvm.h
This patch moves structure kvm_regs to include/asm-x86/kvm.h.
Each architecture will need to create there own version of this
structure.
Signed-off-by: Jerone Young [EMAIL PROTECTED]
diff --git a/include/asm-x86/kvm.h b/include/asm-x86/kvm.h
index 7a8f4d5..ec99d9a 100644
--- a/include/asm-x86/kvm.h
+++ b/include/asm-x86/kvm.h
@@ -63,4 +63,14 @@ struct kvm_ioapic_state {
#define KVM_IRQCHIP_PIC_SLAVE1
#define KVM_IRQCHIP_IOAPIC 2
+/* for KVM_GET_REGS and KVM_SET_REGS */
+struct kvm_regs {
+ /* out (KVM_GET_REGS) / in (KVM_SET_REGS) */
+ __u64 rax, rbx, rcx, rdx;
+ __u64 rsi, rdi, rsp, rbp;
+ __u64 r8, r9, r10, r11;
+ __u64 r12, r13, r14, r15;
+ __u64 rip, rflags;
+};
+
#endif
diff --git a/include/linux/kvm.h b/include/linux/kvm.h
index 1779c3d..0d83efc 100644
--- a/include/linux/kvm.h
+++ b/include/linux/kvm.h
@@ -134,15 +134,6 @@ struct kvm_run {
};
};
-/* for KVM_GET_REGS and KVM_SET_REGS */
-struct kvm_regs {
- /* out (KVM_GET_REGS) / in (KVM_SET_REGS) */
- __u64 rax, rbx, rcx, rdx;
- __u64 rsi, rdi, rsp, rbp;
- __u64 r8, r9, r10, r11;
- __u64 r12, r13, r14, r15;
- __u64 rip, rflags;
-};
/* for KVM_GET_FPU and KVM_SET_FPU */
struct kvm_fpu {
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] Move cpuid sturctures
This patch moves structures:
kvm_cpuid_entry
kvm_cpuid
from include/linux/kvm.h to include/asm-x86/kvm.h
Signed-off-by: Jerone Young [EMAIL PROTECTED]
diff --git a/include/asm-x86/kvm.h b/include/asm-x86/kvm.h
index 97edada..5db4d91 100644
--- a/include/asm-x86/kvm.h
+++ b/include/asm-x86/kvm.h
@@ -129,4 +129,21 @@ struct kvm_msr_list {
};
+struct kvm_cpuid_entry {
+ __u32 function;
+ __u32 eax;
+ __u32 ebx;
+ __u32 ecx;
+ __u32 edx;
+ __u32 padding;
+};
+
+/* for KVM_SET_CPUID */
+struct kvm_cpuid {
+ __u32 nent;
+ __u32 padding;
+ struct kvm_cpuid_entry entries[0];
+};
+
+
#endif
diff --git a/include/linux/kvm.h b/include/linux/kvm.h
index edda200..9605d43 100644
--- a/include/linux/kvm.h
+++ b/include/linux/kvm.h
@@ -195,22 +195,6 @@ struct kvm_dirty_log {
};
};
-struct kvm_cpuid_entry {
- __u32 function;
- __u32 eax;
- __u32 ebx;
- __u32 ecx;
- __u32 edx;
- __u32 padding;
-};
-
-/* for KVM_SET_CPUID */
-struct kvm_cpuid {
- __u32 nent;
- __u32 padding;
- struct kvm_cpuid_entry entries[0];
-};
-
/* for KVM_SET_SIGNAL_MASK */
struct kvm_signal_mask {
__u32 len;
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] Move kvm_sregs structure msr related stuructures
Move structures:
kvm_sregs
kvm_msr_entry
kvm_msrs
kvm_msr_list
from include/linux/kvm.h to include/asm-x86/kvm.h
diff --git a/include/asm-x86/kvm.h b/include/asm-x86/kvm.h
index 07e7fee..1970520 100644
--- a/include/asm-x86/kvm.h
+++ b/include/asm-x86/kvm.h
@@ -9,6 +9,9 @@
#include asm/types.h
#include linux/ioctl.h
+/* Architectural interrupt line count. */
+#define KVM_NR_INTERRUPTS 256
+
struct kvm_memory_alias {
__u32 slot; /* this has a different namespace than memory slots */
__u32 flags;
@@ -99,4 +102,37 @@ struct kvm_dtable {
};
+/* for KVM_GET_SREGS and KVM_SET_SREGS */
+struct kvm_sregs {
+ /* out (KVM_GET_SREGS) / in (KVM_SET_SREGS) */
+ struct kvm_segment cs, ds, es, fs, gs, ss;
+ struct kvm_segment tr, ldt;
+ struct kvm_dtable gdt, idt;
+ __u64 cr0, cr2, cr3, cr4, cr8;
+ __u64 efer;
+ __u64 apic_base;
+ __u64 interrupt_bitmap[(KVM_NR_INTERRUPTS + 63) / 64];
+};
+
+struct kvm_msr_entry {
+ __u32 index;
+ __u32 reserved;
+ __u64 data;
+};
+
+/* for KVM_GET_MSRS and KVM_SET_MSRS */
+struct kvm_msrs {
+ __u32 nmsrs; /* number of msrs in entries */
+ __u32 pad;
+
+ struct kvm_msr_entry entries[0];
+};
+
+/* for KVM_GET_MSR_INDEX_LIST */
+struct kvm_msr_list {
+ __u32 nmsrs; /* number of msrs in entries */
+ __u32 indices[0];
+};
+
+
#endif
diff --git a/include/linux/kvm.h b/include/linux/kvm.h
index 442cb58..e6867aa 100644
--- a/include/linux/kvm.h
+++ b/include/linux/kvm.h
@@ -13,9 +13,6 @@
#define KVM_API_VERSION 12
-/* Architectural interrupt line count. */
-#define KVM_NR_INTERRUPTS 256
-
/* for KVM_CREATE_MEMORY_REGION */
struct kvm_memory_region {
__u32 slot;
@@ -151,39 +148,6 @@ struct kvm_fpu {
};
-
-/* for KVM_GET_SREGS and KVM_SET_SREGS */
-struct kvm_sregs {
- /* out (KVM_GET_SREGS) / in (KVM_SET_SREGS) */
- struct kvm_segment cs, ds, es, fs, gs, ss;
- struct kvm_segment tr, ldt;
- struct kvm_dtable gdt, idt;
- __u64 cr0, cr2, cr3, cr4, cr8;
- __u64 efer;
- __u64 apic_base;
- __u64 interrupt_bitmap[(KVM_NR_INTERRUPTS + 63) / 64];
-};
-
-struct kvm_msr_entry {
- __u32 index;
- __u32 reserved;
- __u64 data;
-};
-
-/* for KVM_GET_MSRS and KVM_SET_MSRS */
-struct kvm_msrs {
- __u32 nmsrs; /* number of msrs in entries */
- __u32 pad;
-
- struct kvm_msr_entry entries[0];
-};
-
-/* for KVM_GET_MSR_INDEX_LIST */
-struct kvm_msr_list {
- __u32 nmsrs; /* number of msrs in entries */
- __u32 indices[0];
-};
-
/* for KVM_TRANSLATE */
struct kvm_translation {
/* in */
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] Move kvm_memory_alias to include/asm-x86/kvm.h
This patch moves sturct kvm_memory_alias from include/linux/kvm.h
to include/asm-x86/kvm.h. Also have include/linux/kvm.h include
include/asm/kvm.h.
Signed-off-by: Jerone Young [EMAIL PROTECTED]
diff --git a/include/asm-x86/kvm.h b/include/asm-x86/kvm.h
new file mode 100644
index 000..9e692a8
--- /dev/null
+++ b/include/asm-x86/kvm.h
@@ -0,0 +1,20 @@
+#ifndef __LINUX_KVM_X86_H
+#define __LINUX_KVM_X86_H
+
+/*
+ * KVM x86 specific structures and definitions
+ *
+ */
+
+#include asm/types.h
+#include linux/ioctl.h
+
+struct kvm_memory_alias {
+ __u32 slot; /* this has a different namespace than memory slots */
+ __u32 flags;
+ __u64 guest_phys_addr;
+ __u64 memory_size;
+ __u64 target_phys_addr;
+};
+
+#endif
diff --git a/include/linux/kvm.h b/include/linux/kvm.h
index 71d33d6..d09dd5d 100644
--- a/include/linux/kvm.h
+++ b/include/linux/kvm.h
@@ -9,6 +9,7 @@
#include asm/types.h
#include linux/ioctl.h
+#include asm/kvm.h
#define KVM_API_VERSION 12
@@ -35,13 +36,6 @@ struct kvm_userspace_memory_region {
/* for kvm_memory_region::flags */
#define KVM_MEM_LOG_DIRTY_PAGES 1UL
-struct kvm_memory_alias {
- __u32 slot; /* this has a different namespace than memory slots */
- __u32 flags;
- __u64 guest_phys_addr;
- __u64 memory_size;
- __u64 target_phys_addr;
-};
/* for KVM_IRQ_LINE */
struct kvm_irq_level {
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [PATCH 0/7] Move x86 code out of include/linux/kvm.h
This set of patches move structres definitions that are x86 specific from include/linux/kvm.h to inclue/asm-x86/kvm.h. Missing from these patches is exactly how to move the IOCTL definitions while keeping things in order. I'll disscuss this on the list. Signed-off-by: Jerone Young [EMAIL PROTECTED] - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH][RFC] Struct kvm split
Hollis Blanchard wrote:
On Mon, 2007-11-19 at 18:05 +0800, Zhang, Xiantao wrote:
Hi Avi,
Based on privious discussion, I made this patch to split struct kvm.
In this patch, strcut kvm only holds common fields, and struct
kvm_x86 will keep x86-specific fields. In this way, struct kvm will
be a sub-filed in struct kvm_x86, and we can use to_kvm_x86 to get
kvm_x86 from struct kvm. It is very similar with current to_vmx
approach for getting struct vmx from struct kvm_vcpu.This is a
rough split based on this idea. Any comments are welcome!
I was very confused until I realized you're only dealing with struct
kvm, not struct kvm_vcpu. I actually started the kvm_vcpu work last
week, and it is a much larger patch. :)
Glad to see you working on kvm_vcpu split. As you said, it should be
more complex. I aslo began it last week, but now please go ahead. I will
focusing on kvm structure split:)
Some whitespace sloppiness (e.g. struct kvm_x86{, extra blank lines
in a few places, and I'm worried about 80 columns in a few places).
This is a rough patch. If ppc and s390 like this approach, I will send
the refined patch
Some of the fields you've left common (e.g. apic_access_page,
mmio_bus, pio_bus) should be moved, but if this split works for IA64
then it's fine to leave those changes for other architectures.
Thank your suggestions. apic_access_page is not necessary for IA64. But
for now, we at least have to reuse mmio_bus infrastructure. Maybe have a
good method to handle it. In addtion mmio_bus, and io_bus implementation
are all kept in common. So, I leave them common now.
In general I like it.
Acked-by: Hollis Blanchard [EMAIL PROTECTED]
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [PATCH] KVM Portability split: Splitting kvm structure (V2)
From: Zhang xiantao [EMAIL PROTECTED]
Date: Tue, 20 Nov 2007 10:08:19 +0800
Subject: [PATCH] KVM Portability split: Splitting kvm structure.
Use kvm_x86 to hold x86 specific kvm fields, in this way
kvm strcut only contains common fields.
Signed-off-by: Zhang xiantao [EMAIL PROTECTED]
---
drivers/kvm/ioapic.c |7 +++-
drivers/kvm/irq.h |1 +
drivers/kvm/kvm.h | 33 -
drivers/kvm/kvm_main.c |9 --
drivers/kvm/mmu.c | 74
+--
drivers/kvm/vmx.c | 18
drivers/kvm/x86.c | 33 +
drivers/kvm/x86.h | 50 +++-
8 files changed, 139 insertions(+), 86 deletions(-)
diff --git a/drivers/kvm/ioapic.c b/drivers/kvm/ioapic.c
index cf1d50b..541164d 100644
--- a/drivers/kvm/ioapic.c
+++ b/drivers/kvm/ioapic.c
@@ -276,7 +276,9 @@ static int get_eoi_gsi(struct kvm_ioapic *ioapic,
int vector)
void kvm_ioapic_update_eoi(struct kvm *kvm, int vector)
{
- struct kvm_ioapic *ioapic = kvm-vioapic;
+ struct kvm_x86 *kvm_x86 = to_kvm_x86(kvm);
+
+ struct kvm_ioapic *ioapic = kvm_x86-vioapic;
union ioapic_redir_entry *ent;
int gsi;
@@ -386,11 +388,12 @@ void kvm_ioapic_reset(struct kvm_ioapic *ioapic)
int kvm_ioapic_init(struct kvm *kvm)
{
struct kvm_ioapic *ioapic;
+ struct kvm_x86 *kvm_x86 = to_kvm_x86(kvm);
ioapic = kzalloc(sizeof(struct kvm_ioapic), GFP_KERNEL);
if (!ioapic)
return -ENOMEM;
- kvm-vioapic = ioapic;
+ kvm_x86-vioapic = ioapic;
kvm_ioapic_reset(ioapic);
ioapic-dev.read = ioapic_mmio_read;
ioapic-dev.write = ioapic_mmio_write;
diff --git a/drivers/kvm/irq.h b/drivers/kvm/irq.h
index 5ad3cfd..7180481 100644
--- a/drivers/kvm/irq.h
+++ b/drivers/kvm/irq.h
@@ -23,6 +23,7 @@
#define __IRQ_H
#include kvm.h
+#include x86.h
typedef void irq_request_func(void *opaque, int level);
diff --git a/drivers/kvm/kvm.h b/drivers/kvm/kvm.h
index 1901456..445012e 100644
--- a/drivers/kvm/kvm.h
+++ b/drivers/kvm/kvm.h
@@ -309,48 +309,16 @@ struct kvm {
int nmemslots;
struct kvm_memory_slot memslots[KVM_MEMORY_SLOTS +
KVM_PRIVATE_MEM_SLOTS];
- /*
-* Hash table of struct kvm_mmu_page.
-*/
- struct list_head active_mmu_pages;
- unsigned int n_free_mmu_pages;
- unsigned int n_requested_mmu_pages;
- unsigned int n_alloc_mmu_pages;
- struct hlist_head mmu_page_hash[KVM_NUM_MMU_PAGES];
struct kvm_vcpu *vcpus[KVM_MAX_VCPUS];
unsigned long rmap_overflow;
struct list_head vm_list;
struct file *filp;
struct kvm_io_bus mmio_bus;
struct kvm_io_bus pio_bus;
- struct kvm_pic *vpic;
- struct kvm_ioapic *vioapic;
int round_robin_prev_vcpu;
- unsigned int tss_addr;
- struct page *apic_access_page;
struct kvm_vm_stat stat;
};
-static inline struct kvm_pic *pic_irqchip(struct kvm *kvm)
-{
- return kvm-vpic;
-}
-
-static inline struct kvm_ioapic *ioapic_irqchip(struct kvm *kvm)
-{
- return kvm-vioapic;
-}
-
-static inline int irqchip_in_kernel(struct kvm *kvm)
-{
- return pic_irqchip(kvm) != NULL;
-}
-
-struct descriptor_table {
- u16 limit;
- unsigned long base;
-} __attribute__((packed));
-
/* The guest did something we don't support. */
#define pr_unimpl(vcpu, fmt, ...)
\
do {
\
@@ -493,7 +461,6 @@ static inline int memslot_id(struct kvm *kvm, struct
kvm_memory_slot *slot)
return slot - kvm-memslots;
}
-
enum kvm_stat_kind {
KVM_STAT_VM,
KVM_STAT_VCPU,
diff --git a/drivers/kvm/kvm_main.c b/drivers/kvm/kvm_main.c
index bda733a..5d4bb68 100644
--- a/drivers/kvm/kvm_main.c
+++ b/drivers/kvm/kvm_main.c
@@ -233,6 +233,8 @@ int __kvm_set_memory_region(struct kvm *kvm,
struct kvm_memory_slot *memslot;
struct kvm_memory_slot old, new;
+ struct kvm_x86 *kvm_x86 = to_kvm_x86(kvm);
+
r = -EINVAL;
/* General sanity checks */
if (mem-memory_size (PAGE_SIZE - 1))
@@ -332,18 +334,19 @@ int __kvm_set_memory_region(struct kvm *kvm,
if (mem-slot = kvm-nmemslots)
kvm-nmemslots = mem-slot + 1;
- if (!kvm-n_requested_mmu_pages) {
+ if (!kvm_x86-n_requested_mmu_pages) {
unsigned int n_pages;
if (npages) {
n_pages = npages * KVM_PERMILLE_MMU_PAGES /
1000;
- kvm_mmu_change_mmu_pages(kvm,
kvm-n_alloc_mmu_pages +
+ kvm_mmu_change_mmu_pages(kvm,
+
kvm_x86-n_alloc_mmu_pages +
n_pages);
} else {
unsigned int nr_mmu_pages;
n_pages = old.npages * KVM_PERMILLE_MMU_PAGES /
1000;
- nr_mmu_pages =
[kvm-devel] [PATCH] KVM Portability split: splitting kvm.h
From e7a0fcaa7d87c20a4e7155a11ee2afa880bdc471 Mon Sep 17 00:00:00 2001
From: Zhang xiantao [EMAIL PROTECTED]
Date: Tue, 20 Nov 2007 10:44:08 +0800
Subject: [PATCH] KVM Portability split: splitting kvm.h
Moving code related to mmu to x86.h
Signed-off-by: Zhang xiantao [EMAIL PROTECTED]
---
drivers/kvm/kvm.h | 78
drivers/kvm/x86.h | 79
+
2 files changed, 79 insertions(+), 78 deletions(-)
diff --git a/drivers/kvm/kvm.h b/drivers/kvm/kvm.h
index 445012e..5149d39 100644
--- a/drivers/kvm/kvm.h
+++ b/drivers/kvm/kvm.h
@@ -58,89 +58,11 @@ typedef unsigned long hva_t;
typedef u64hpa_t;
typedef unsigned long hfn_t;
-#define NR_PTE_CHAIN_ENTRIES 5
-
-struct kvm_pte_chain {
- u64 *parent_ptes[NR_PTE_CHAIN_ENTRIES];
- struct hlist_node link;
-};
-
-/*
- * kvm_mmu_page_role, below, is defined as:
- *
- * bits 0:3 - total guest paging levels (2-4, or zero for real mode)
- * bits 4:7 - page table level for this shadow (1-4)
- * bits 8:9 - page table quadrant for 2-level guests
- * bit 16 - metaphysical - gfn is not a real page (huge page/real
mode)
- * bits 17:19 - access - the user, writable, and nx bits of a huge
page pde
- */
-union kvm_mmu_page_role {
- unsigned word;
- struct {
- unsigned glevels : 4;
- unsigned level : 4;
- unsigned quadrant : 2;
- unsigned pad_for_nice_hex_output : 6;
- unsigned metaphysical : 1;
- unsigned hugepage_access : 3;
- };
-};
-
-struct kvm_mmu_page {
- struct list_head link;
- struct hlist_node hash_link;
-
- /*
-* The following two entries are used to key the shadow page in
the
-* hash table.
-*/
- gfn_t gfn;
- union kvm_mmu_page_role role;
-
- u64 *spt;
- /* hold the gfn of each spte inside spt */
- gfn_t *gfns;
- unsigned long slot_bitmap; /* One bit set per slot which has
memory
- * in this shadow page.
- */
- int multimapped; /* More than one parent_pte? */
- int root_count; /* Currently serving as active root */
- union {
- u64 *parent_pte; /* !multimapped */
- struct hlist_head parent_ptes; /* multimapped,
kvm_pte_chain */
- };
-};
struct kvm_vcpu;
extern struct kmem_cache *kvm_vcpu_cache;
/*
- * x86 supports 3 paging modes (4-level 64-bit, 3-level 64-bit, and
2-level
- * 32-bit). The kvm_mmu structure abstracts the details of the current
mmu
- * mode.
- */
-struct kvm_mmu {
- void (*new_cr3)(struct kvm_vcpu *vcpu);
- int (*page_fault)(struct kvm_vcpu *vcpu, gva_t gva, u32 err);
- void (*free)(struct kvm_vcpu *vcpu);
- gpa_t (*gva_to_gpa)(struct kvm_vcpu *vcpu, gva_t gva);
- void (*prefetch_page)(struct kvm_vcpu *vcpu,
- struct kvm_mmu_page *page);
- hpa_t root_hpa;
- int root_level;
- int shadow_root_level;
-
- u64 *pae_root;
-};
-
-#define KVM_NR_MEM_OBJS 40
-
-struct kvm_mmu_memory_cache {
- int nobjs;
- void *objects[KVM_NR_MEM_OBJS];
-};
-
-/*
* We don't want allocation failures within the mmu code, so we
preallocate
* enough memory for a single page fault in a cache.
*/
diff --git a/drivers/kvm/x86.h b/drivers/kvm/x86.h
index 1a6f8fe..2fdda8f 100644
--- a/drivers/kvm/x86.h
+++ b/drivers/kvm/x86.h
@@ -55,6 +55,85 @@
extern spinlock_t kvm_lock;
extern struct list_head vm_list;
+#define NR_PTE_CHAIN_ENTRIES 5
+
+struct kvm_pte_chain {
+ u64 *parent_ptes[NR_PTE_CHAIN_ENTRIES];
+ struct hlist_node link;
+};
+
+/*
+ * kvm_mmu_page_role, below, is defined as:
+ *
+ * bits 0:3 - total guest paging levels (2-4, or zero for real mode)
+ * bits 4:7 - page table level for this shadow (1-4)
+ * bits 8:9 - page table quadrant for 2-level guests
+ * bit 16 - metaphysical - gfn is not a real page (huge page/real
mode)
+ * bits 17:19 - access - the user, writable, and nx bits of a huge
page pde
+ */
+union kvm_mmu_page_role {
+ unsigned word;
+ struct {
+ unsigned glevels : 4;
+ unsigned level : 4;
+ unsigned quadrant : 2;
+ unsigned pad_for_nice_hex_output : 6;
+ unsigned metaphysical : 1;
+ unsigned hugepage_access : 3;
+ };
+};
+
+struct kvm_mmu_page {
+ struct list_head link;
+ struct hlist_node hash_link;
+
+ /*
+* The following two entries are used to key the shadow page in
the
+* hash table.
+*/
+ gfn_t gfn;
+ union kvm_mmu_page_role role;
+
+ u64 *spt;
+ /* hold the gfn of each spte inside spt */
+ gfn_t *gfns;
+ unsigned long slot_bitmap; /* One bit set per slot which has
memory
+
[kvm-devel] [PATCH] KVM Portability move: Moving kvm_vcpu_stat to x86.h
From: Zhang xiantao [EMAIL PROTECTED]
Date: Tue, 20 Nov 2007 10:46:33 +0800
Subject: [PATCH] KVM Portability move: Moving kvm_vcpu_stat to x86.h
Signed-off-by: Zhang xiantao [EMAIL PROTECTED]
---
drivers/kvm/kvm.h | 22 --
drivers/kvm/x86.h | 22 ++
2 files changed, 22 insertions(+), 22 deletions(-)
diff --git a/drivers/kvm/kvm.h b/drivers/kvm/kvm.h
index 5149d39..24fa37a 100644
--- a/drivers/kvm/kvm.h
+++ b/drivers/kvm/kvm.h
@@ -85,28 +85,6 @@ struct kvm_pio_request {
int rep;
};
-struct kvm_vcpu_stat {
- u32 pf_fixed;
- u32 pf_guest;
- u32 tlb_flush;
- u32 invlpg;
-
- u32 exits;
- u32 io_exits;
- u32 mmio_exits;
- u32 signal_exits;
- u32 irq_window_exits;
- u32 halt_exits;
- u32 halt_wakeup;
- u32 request_irq_exits;
- u32 irq_exits;
- u32 host_state_reload;
- u32 efer_reload;
- u32 fpu_reload;
- u32 insn_emulation;
- u32 insn_emulation_fail;
-};
-
struct kvm_io_device {
void (*read)(struct kvm_io_device *this,
gpa_t addr,
diff --git a/drivers/kvm/x86.h b/drivers/kvm/x86.h
index 2fdda8f..a0b8c84 100644
--- a/drivers/kvm/x86.h
+++ b/drivers/kvm/x86.h
@@ -134,6 +134,28 @@ struct kvm_mmu_memory_cache {
void *objects[KVM_NR_MEM_OBJS];
};
+struct kvm_vcpu_stat {
+ u32 pf_fixed;
+ u32 pf_guest;
+ u32 tlb_flush;
+ u32 invlpg;
+
+ u32 exits;
+ u32 io_exits;
+ u32 mmio_exits;
+ u32 signal_exits;
+ u32 irq_window_exits;
+ u32 halt_exits;
+ u32 halt_wakeup;
+ u32 request_irq_exits;
+ u32 irq_exits;
+ u32 host_state_reload;
+ u32 efer_reload;
+ u32 fpu_reload;
+ u32 insn_emulation;
+ u32 insn_emulation_fail;
+};
+
enum {
VCPU_REGS_RAX = 0,
VCPU_REGS_RCX = 1,
--
1.5.0.5
0003-KVM-Portability-move-Moving-kvm_vcpu_stat-to-x86.h.patch
Description: 0003-KVM-Portability-move-Moving-kvm_vcpu_stat-to-x86.h.patch
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [PATCH] Move x86 ioctl definitions from include/linux/kvm.h
This patch is a continuation of the 7 patches sent earlier. This
patch moves all x86 specific macros from include/linux/kvm.h to
include/asm-x86/kvm.h.
Signed-off-by: Jerone Young [EMAIL PROTECTED]
*note just realized none of the other patches except for email 0
had the [PATCH] addendum on the subjects.
diff --git a/include/asm-x86/kvm.h b/include/asm-x86/kvm.h
index 9d40f75..5622f25 100644
--- a/include/asm-x86/kvm.h
+++ b/include/asm-x86/kvm.h
@@ -151,5 +151,38 @@ struct kvm_cpuid {
struct kvm_cpuid_entry entries[0];
};
+/*
+ * ioctls for /dev/kvm fds:
+ */
+#define KVM_GET_MSR_INDEX_LIST_IOWR(KVMIO, 0x02, struct kvm_msr_list)
+
+/*
+ * KVM_CREATE_VCPU receives as a parameter the vcpu slot, and returns
+ * a vcpu fd.
+ */
+#define KVM_SET_MEMORY_ALIAS _IOW(KVMIO, 0x43, struct kvm_memory_alias)
+
+/*
+ * Extension capability list.
+ */
+#define KVM_CAP_IRQCHIP 0
+#define KVM_CAP_HLT 1
+#define KVM_CAP_MMU_SHADOW_CACHE_CONTROL 2
+#define KVM_CAP_USER_MEMORY 3
+#define KVM_CAP_SET_TSS_ADDR 4
+
+/*
+ * ioctls for VM fds
+ */
+#define KVM_SET_TSS_ADDR _IO(KVMIO, 0x47)
+
+/*
+ * ioctls for vcpu fds
+ */
+#define KVM_GET_MSRS _IOWR(KVMIO, 0x88, struct kvm_msrs)
+#define KVM_SET_MSRS _IOW(KVMIO, 0x89, struct kvm_msrs)
+#define KVM_SET_CPUID _IOW(KVMIO, 0x8a, struct kvm_cpuid)
+#define KVM_GET_LAPIC _IOR(KVMIO, 0x8e, struct kvm_lapic_state)
+#define KVM_SET_LAPIC _IOW(KVMIO, 0x8f, struct kvm_lapic_state)
#endif
diff --git a/include/linux/kvm.h b/include/linux/kvm.h
index fd4f900..ed85110 100644
--- a/include/linux/kvm.h
+++ b/include/linux/kvm.h
@@ -205,7 +205,6 @@ struct kvm_signal_mask {
*/
#define KVM_GET_API_VERSION _IO(KVMIO, 0x00)
#define KVM_CREATE_VM _IO(KVMIO, 0x01) /* returns a VM fd */
-#define KVM_GET_MSR_INDEX_LIST_IOWR(KVMIO, 0x02, struct kvm_msr_list)
/*
* Check if a kvm extension is available. Argument is extension number,
* return is 1 (yes) or 0 (no, sorry).
@@ -217,15 +216,6 @@ struct kvm_signal_mask {
#define KVM_GET_VCPU_MMAP_SIZE_IO(KVMIO, 0x04) /* in bytes */
/*
- * Extension capability list.
- */
-#define KVM_CAP_IRQCHIP 0
-#define KVM_CAP_HLT 1
-#define KVM_CAP_MMU_SHADOW_CACHE_CONTROL 2
-#define KVM_CAP_USER_MEMORY 3
-#define KVM_CAP_SET_TSS_ADDR 4
-
-/*
* ioctls for VM fds
*/
#define KVM_SET_MEMORY_REGION _IOW(KVMIO, 0x40, struct kvm_memory_region)
@@ -233,14 +223,13 @@ struct kvm_signal_mask {
#define KVM_GET_NR_MMU_PAGES _IO(KVMIO, 0x45)
#define KVM_SET_USER_MEMORY_REGION _IOW(KVMIO, 0x46,\
struct kvm_userspace_memory_region)
-#define KVM_SET_TSS_ADDR _IO(KVMIO, 0x47)
+
/*
* KVM_CREATE_VCPU receives as a parameter the vcpu slot, and returns
* a vcpu fd.
*/
#define KVM_CREATE_VCPU _IO(KVMIO, 0x41)
#define KVM_GET_DIRTY_LOG _IOW(KVMIO, 0x42, struct kvm_dirty_log)
-#define KVM_SET_MEMORY_ALIAS _IOW(KVMIO, 0x43, struct kvm_memory_alias)
/* Device model IOC */
#define KVM_CREATE_IRQCHIP _IO(KVMIO, 0x60)
#define KVM_IRQ_LINE _IOW(KVMIO, 0x61, struct kvm_irq_level)
@@ -258,13 +247,8 @@ struct kvm_signal_mask {
#define KVM_TRANSLATE _IOWR(KVMIO, 0x85, struct kvm_translation)
#define KVM_INTERRUPT _IOW(KVMIO, 0x86, struct kvm_interrupt)
#define KVM_DEBUG_GUEST _IOW(KVMIO, 0x87, struct kvm_debug_guest)
-#define KVM_GET_MSRS _IOWR(KVMIO, 0x88, struct kvm_msrs)
-#define KVM_SET_MSRS _IOW(KVMIO, 0x89, struct kvm_msrs)
-#define KVM_SET_CPUID _IOW(KVMIO, 0x8a, struct kvm_cpuid)
#define KVM_SET_SIGNAL_MASK _IOW(KVMIO, 0x8b, struct kvm_signal_mask)
#define KVM_GET_FPU _IOR(KVMIO, 0x8c, struct kvm_fpu)
#define KVM_SET_FPU _IOW(KVMIO, 0x8d, struct kvm_fpu)
-#define KVM_GET_LAPIC _IOR(KVMIO, 0x8e, struct kvm_lapic_state)
-#define KVM_SET_LAPIC _IOW(KVMIO, 0x8f, struct kvm_lapic_state)
#endif
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [ kvm-Bugs-1834938 ] Booting mutil guest may cause 64bit host to crashl
Bugs item #1834938, was opened at 2007-11-20 13:49 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=893831aid=1834938group_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: yunfeng (yunfeng) Assigned to: Nobody/Anonymous (nobody) Summary: Booting mutil guest may cause 64bit host to crashl Initial Comment: In the testing for kernel: 9fbcc4a1b7cf873a5aa1a357320fb82d588aa316, userspace:14892fe1817712ff8555a9de474165e9d38d1b90 we found that booting multi guest may cause 64bit host to crash. A case to boot 4 linux guests with 256MB memory size may crash 64bit host. Many call trace mesages printed by kernel, see the attached serial output Following are error messages on console Message from [EMAIL PROTECTED] at Tue Nov 20 09:34:03 2007 ... vt-dp8 kernel: Oops: [1] SMP Message from [EMAIL PROTECTED] at Tue Nov 20 09:34:03 2007 ... vt-dp8 kernel: CR2: 0008 Message from [EMAIL PROTECTED] at Tue Nov 20 09:34:03 2007 ... vt-dp8 kernel: [ cut here ] Message from [EMAIL PROTECTED] at Tue Nov 20 09:34:03 2007 ... vt-dp8 kernel: invalid opcode: [2] SMP -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=893831aid=1834938group_id=180599 - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 7/24] consolidate msr.h
* Steven Rostedt [EMAIL PROTECTED] wrote: On Fri, Nov 09, 2007 at 04:42:48PM -0200, Glauber de Oliveira Costa wrote: - wrmsrl(MSR_CSTAR, ia32_cstar_target); + wrmsrl(MSR_CSTAR, (u64)ia32_cstar_target); Hmm, why do you add explicit casts? The compiler should convert that correctly on its own. +static inline void wrmsrl(unsigned int msr, unsigned long long val) Hmm, long long is 64 bit on all x86, but why not use explicit u64 to show that? (quick reply) With PVOPS on it gives compiler warnings without that explict cast. Without looking at the code, IIRC with non-PVOPS it is a macro directly into asm, so it didn't matter what the cast was. But with PVOPS as a function, it gave compiler warnings. Take it out and try compiling it for both i386 and x86_64. One of them gave warnings. But maybe it's not a problem now. i dont think there's ever any true need (and good cause) to force integer type casts like that at the callee site. Ingo - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 7/24] consolidate msr.h
On Tue, 20 Nov 2007, Ingo Molnar wrote: i dont think there's ever any true need (and good cause) to force integer type casts like that at the callee site. Unless you mean we should do something like this: static inline void __wrmsrl(unsigned int msr, unsigned long long val); #define wrmsr(msr, val) __wrmsrl(msr, (unsigned long long)var) -- Steve - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 7/24] consolidate msr.h
On Tue, 20 Nov 2007, Ingo Molnar wrote: * Steven Rostedt [EMAIL PROTECTED] wrote: With PVOPS on it gives compiler warnings without that explict cast. Without looking at the code, IIRC with non-PVOPS it is a macro directly into asm, so it didn't matter what the cast was. But with PVOPS as a function, it gave compiler warnings. Take it out and try compiling it for both i386 and x86_64. One of them gave warnings. But maybe it's not a problem now. i dont think there's ever any true need (and good cause) to force integer type casts like that at the callee site. I guess the problem is that we converted a macro to a function, where the macro did no type checking. Now we need to pick between integers and pointers. Some places uses intergers in wrmsrl and some use pointers. So changing this to a typechecking protocol is not going to be nice. Looking at the current code now, we have this: checking_wrmsrl(MSR_IA32_SYSENTER_CS, (u64)__KERNEL_CS); checking_wrmsrl(MSR_IA32_SYSENTER_ESP, 0ULL); checking_wrmsrl(MSR_IA32_SYSENTER_EIP, (u64)ia32_sysenter_target); wrmsrl(MSR_CSTAR, ia32_cstar_target); A typecast is already used in that same area. -- Steve - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] discard MSR writes
On Tuesday 20 November 2007 00:38:05 Markus Rechberger wrote: this patch discards MSR writes to the Performance Event-Select Registers, this is the first issue why vista seems to fail although now vista ends up in an endless loop a bit later. Qemu currently also discards those writes. Won't this make the corresponding rdmsrs fail? What happens when the rdmsr returns an error, but windows then uses some garbage value (as it thinks the wrmsr succeeded, so the rdmsr also should)? - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
