Re: [kvm-devel] [PATCH] Move x86 ioctl definitions from include/linux/kvm.h

[Carsten Otte]

Jerone Young wrote:
> 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]>
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] Move x86 ioctl definitions frominclude/linux/kvm.h

[Zhang, Xiantao]

Jerone Young wrote:
> 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_IRQCHIP0
> +#define KVM_CAP_HLT1
> +#define KVM_CAP_MMU_SHADOW_CACHE_CONTROL 2


> +#define KVM_CAP_USER_MEMORY 3

One minor comment:  Currenlty, user and kernel space memory interfaces
are in common, should we move this capability 
definition to arch?

Anyway this is not a big issue.

Acked-by: Zhang Xiantao<[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

-
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] [RFC] virtio-blk PCI backend

[Christian Borntraeger]

Am Freitag, 9. November 2007 schrieb Dor Laor:
> I believe that the network interface will quickly go to the kernel since 
> copy takes most of the
> cpu time and qemu does not support scatter gather dma at the moment.
> Nevertheless using pio seems good enough, Anthony's suggestion of 
> notifying the kernel using ioctls
> is logical. If we'll run into troubles further on we can add a hypercall 
> capability and if exist use hypercalls
> instead of pios.

Sorry for being late in this thread.
We (s390) will need a hypercall as we do not have port I/O. I think it should be
possible to default to hypercall on s390 and use pio everywhere else.

Christian

-
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] Migration doesn't working at all for me

[Anton Patrushev]

[EMAIL PROTECTED] ~]# uname -a
Linux localhost.localdomain 2.6.20-1.2320.fc5smp #1 SMP Tue Jun 12 19:40:16 
EDT 2007 i686 i686 i386 GNU/Linux

[EMAIL PROTECTED] ~]# modinfo kvm
filename:   /lib/modules/2.6.20-1.2320.fc5smp/extra/kvm.ko
license:GPL
author: Qumranet
version:kvm-52
srcversion: E46DE2B98872EDFF6C75BE1
depends:
vermagic:   2.6.20-1.2320.fc5smp SMP mod_unload 686 4KSTACKS

[EMAIL PROTECTED] ~]# modinfo kvm-intel
filename:   /lib/modules/2.6.20-1.2320.fc5smp/extra/kvm-intel.ko
license:GPL
author: Qumranet
version:kvm-52
srcversion: F7E80D6C3124584F75EDAAF
depends:kvm,kvm
vermagic:   2.6.20-1.2320.fc5smp SMP mod_unload 686 4KSTACKS
parm:   bypass_guest_pf:bool


[EMAIL PROTECTED] 
kvm-52]# /usr/local/kvm/bin/qemu-system-x86_64 -hda /dev/sdc -cdrom 
/mnt/distribs/Fedora-8-i386-DVD.iso -m 
256 -vnc :0 -net nic -net tap,script=/usr/local/bin/tapup -monitor stdio
QEMU 0.9.0 monitor - type 'help' for more information
(qemu) stop
(qemu) migrate "exec:dd of=STATEFILE"
BUG: kvm_dirty_pages_log_change: invalid parameters
Could not start migration

-- 
WBR, Anton Patrushev

-
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: Recaculate mmu pages needed for every memory region change.

[Zhang, Xiantao]

From: Zhang Xiantao <[EMAIL PROTECTED]>
Date: Tue, 20 Nov 2007 13:11:38 +0800
Subject: [PATCH] KVM Portability: Recaculate mmu pages needed for every
memory region change.
Signed-off-by: Zhang Xiantao <[EMAIL PROTECTED]>
---
 drivers/kvm/kvm_main.c |   21 -
 drivers/kvm/mmu.c  |   19 +++
 drivers/kvm/x86.h  |2 ++
 3 files changed, 25 insertions(+), 17 deletions(-)

diff --git a/drivers/kvm/kvm_main.c b/drivers/kvm/kvm_main.c
index bda733a..8a90f7d 100644
--- a/drivers/kvm/kvm_main.c
+++ b/drivers/kvm/kvm_main.c
@@ -332,26 +332,13 @@ int __kvm_set_memory_region(struct kvm *kvm,
if (mem->slot >= kvm->nmemslots)
kvm->nmemslots = mem->slot + 1;
 
+   *memslot = new;
+
if (!kvm->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 +
-n_pages);
-   } else {
-   unsigned int nr_mmu_pages;
-
-   n_pages = old.npages * KVM_PERMILLE_MMU_PAGES /
1000;
-   nr_mmu_pages = kvm->n_alloc_mmu_pages - n_pages;
-   nr_mmu_pages = max(nr_mmu_pages,
-   (unsigned int)
KVM_MIN_ALLOC_MMU_PAGES);
-   kvm_mmu_change_mmu_pages(kvm, nr_mmu_pages);
-   }
+   unsigned int nr_mmu_pages =
kvm_mmu_calculate_mmu_pages(kvm);
+   kvm_mmu_change_mmu_pages(kvm, nr_mmu_pages);
}
 
-   *memslot = new;
-
kvm_mmu_slot_remove_write_access(kvm, mem->slot);
kvm_flush_remote_tlbs(kvm);
 
diff --git a/drivers/kvm/mmu.c b/drivers/kvm/mmu.c
index 87d8e70..46822f0 100644
--- a/drivers/kvm/mmu.c
+++ b/drivers/kvm/mmu.c
@@ -1526,6 +1526,25 @@ nomem:
return -ENOMEM;
 }
 
+/*
+ * Caculate mmu pages needed for kvm.
+ */
+unsigned int kvm_mmu_calculate_mmu_pages(struct kvm *kvm)
+{
+   int i;
+   unsigned int nr_mmu_pages;
+   unsigned int  nr_pages = 0;
+
+   for (i = 0; i < kvm->nmemslots; i++)
+   nr_pages += kvm->memslots[i].npages;
+
+   nr_mmu_pages = nr_pages * KVM_PERMILLE_MMU_PAGES / 1000;
+   nr_mmu_pages = max(nr_mmu_pages,
+   (unsigned int) KVM_MIN_ALLOC_MMU_PAGES);
+
+   return nr_mmu_pages;
+}
+
 #ifdef AUDIT
 
 static const char *audit_msg;
diff --git a/drivers/kvm/x86.h b/drivers/kvm/x86.h
index 90b791b..c1a8f90 100644
--- a/drivers/kvm/x86.h
+++ b/drivers/kvm/x86.h
@@ -236,6 +236,8 @@ void kvm_mmu_set_nonpresent_ptes(u64 trap_pte, u64
notrap_pte);
 int kvm_mmu_reset_context(struct kvm_vcpu *vcpu);
 void kvm_mmu_slot_remove_write_access(struct kvm *kvm, int slot);
 void kvm_mmu_zap_all(struct kvm *kvm);
+
+unsigned int  kvm_mmu_calculate_mmu_pages(struct kvm *kvm);
 void kvm_mmu_change_mmu_pages(struct kvm *kvm, unsigned int
kvm_nr_mmu_pages);
 
 enum emulation_result {
-- 
1.5.1.2


0001-KVM-Portability-Recaculate-mmu-pages-needed-for-eve.patch
Description: 0001-KVM-Portability-Recaculate-mmu-pages-needed-for-eve.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

Re: [kvm-devel] [RFC] virtio-blk PCI backend

[Arnd Bergmann]

On Tuesday 20 November 2007, Avi Kivity wrote:
> 
> >
> > Sorry for being late in this thread.
> > We (s390) will need a hypercall as we do not have port I/O. I think it 
> > should be
> > possible to default to hypercall on s390 and use pio everywhere else.
> >   
> 
> Or be generic: advertise the methods available according to host 
> (kvm/x86, qemu/x86, kvm/s390) and let the guest pick.

Not sure if I'm following the reasoning here. Shouldn't the method be
inherent to the virtio bus driver?

When you use a PCI based virtio bus, the natural choice would be PIO
in some way, but you could also have a different virtio implementation
on PCI that uses hcalls. This choice is completely up to virtio-pci.

On s390, you have a different virtio backend altogether, so you always
use DIAG or hcall instead of whatever virtio-pci does.

The virtio-blk and other high-level drivers don't need to care about
what transport the bus uses in the first place.

Arnd <><

-
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

[Amit Shah]

On Tuesday 20 November 2007 15:42:35 Avi Kivity wrote:
> Amit Shah wrote:
> > On Tuesday 20 November 2007 15:17:54 Avi Kivity wrote:
> >> Amit Shah wrote:
> >>> 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)?
> >>
> >> rdmsr will inject #GP for these msrs.  Implementing set_msr() doesn't
> >> affect rdmsr.
> >>
> > >From the AMD programming manual, vol 2:
> >
> > The performance event-select registers can be read and written only by
> > system software running at CPL = 0 using the RDMSR and WRMSR
> > instructions, respectively. Any attempt to read or write these registers
> > at CPL > 0 causes a general-protection exception to occur.
>
> Look through the code that implements rdmsr, it doesn't care about the
> manuals and will happily inject a #GP for rdmsr of any unimplemented msr
> (like PerfEvtSel)  wrmsr and rdmsr implementations are not linked.

That's right; but isn't that wrong if we cause it? I mean if we just allow the 
wrmsr access to go through (and if they're actually used, not disabled as you 
mentioned separately), then there'll be no interrupts when the guest expects 
them to occur, or the rdmsr will fail, when the guest thinks it shouldn't 
have.

I guess we're putting forth the same point: if the wrmsr is not for disabling 
interrupts, we shouldn't let it go through, or just implement the required 
emulation.

-
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

[Amit Shah]

On Tuesday 20 November 2007 15:17:54 Avi Kivity wrote:
> Amit Shah wrote:
> > 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)?
>
> rdmsr will inject #GP for these msrs.  Implementing set_msr() doesn't
> affect rdmsr.

>From the AMD programming manual, vol 2:

The performance event-select registers can be read and written only by system 
software running at CPL = 0 using the RDMSR and WRMSR instructions, 
respectively. Any attempt to read or write these registers at CPL > 0 causes 
a general-protection exception to occur.

Also, a grep through the Linux code shows a rdmsrl on EVNTSEL3.


-
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] Migration doesn't working at all for me

[Avi Kivity]

Anton Patrushev wrote:
> [EMAIL PROTECTED] ~]# uname -a
> Linux localhost.localdomain 2.6.20-1.2320.fc5smp #1 SMP Tue Jun 12 19:40:16 
> EDT 2007 i686 i686 i386 GNU/Linux
>
> [EMAIL PROTECTED] ~]# modinfo kvm
> filename:   /lib/modules/2.6.20-1.2320.fc5smp/extra/kvm.ko
> license:GPL
> author: Qumranet
> version:kvm-52
> srcversion: E46DE2B98872EDFF6C75BE1
> depends:
> vermagic:   2.6.20-1.2320.fc5smp SMP mod_unload 686 4KSTACKS
>
> [EMAIL PROTECTED] ~]# modinfo kvm-intel
> filename:   /lib/modules/2.6.20-1.2320.fc5smp/extra/kvm-intel.ko
> license:GPL
> author: Qumranet
> version:kvm-52
> srcversion: F7E80D6C3124584F75EDAAF
> depends:kvm,kvm
> vermagic:   2.6.20-1.2320.fc5smp SMP mod_unload 686 4KSTACKS
> parm:   bypass_guest_pf:bool
>
>
> [EMAIL PROTECTED] 
> kvm-52]# /usr/local/kvm/bin/qemu-system-x86_64 -hda /dev/sdc -cdrom 
> /mnt/distribs/Fedora-8-i386-DVD.iso -m 
> 256 -vnc :0 -net nic -net tap,script=/usr/local/bin/tapup -monitor stdio
> QEMU 0.9.0 monitor - type 'help' for more information
> (qemu) stop
> (qemu) migrate "exec:dd of=STATEFILE"
> BUG: kvm_dirty_pages_log_change: invalid parameters
> Could not start migration
>
>   

Probably due to this being a 32-bit host.  We'll look into it.


-- 
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] discard MSR writes

[Avi Kivity]

Amit Shah wrote:
> 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)?
>   

rdmsr will inject #GP for these msrs.  Implementing set_msr() doesn't 
affect rdmsr.


-- 
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/7] Move x86 code out of include/linux/kvm.h

[Avi Kivity]

Jerone Young wrote:
> This set of patches move structres & definitions that
> are x86 specific from include/linux/kvm.h to inclue/asm-x86/kvm.h.
>   


Applied all, 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

[kvm-devel] [PATCH] KVM Portability : Spliting kvm_set_memory_region.

[Zhang, Xiantao]

From: Zhang Xiantao <[EMAIL PROTECTED]>
Date: Tue, 20 Nov 2007 16:25:04 +0800
Subject: [PATCH] KVM Portability : Spliting kvm_set_memory_region.
Moving !user_alloc case to kvm_arch to avoid unnecessary
code logic in non-x86 platform.
Signed-off-by: Zhang Xiantao <[EMAIL PROTECTED]>
---
 drivers/kvm/kvm.h  |4 +++
 drivers/kvm/kvm_main.c |   38 ---
 drivers/kvm/x86.c  |   51

 3 files changed, 60 insertions(+), 33 deletions(-)

diff --git a/drivers/kvm/kvm.h b/drivers/kvm/kvm.h
index 1901456..9b8bd9d 100644
--- a/drivers/kvm/kvm.h
+++ b/drivers/kvm/kvm.h
@@ -392,6 +392,10 @@ int kvm_set_memory_region(struct kvm *kvm,
 int __kvm_set_memory_region(struct kvm *kvm,
struct kvm_userspace_memory_region *mem,
int user_alloc);
+int kvm_arch_set_memory_region(struct kvm *kvm,
+   struct kvm_userspace_memory_region *mem,
+   struct kvm_memory_slot old,
+   int user_alloc);
 gfn_t unalias_gfn(struct kvm *kvm, gfn_t gfn);
 struct page *gfn_to_page(struct kvm *kvm, gfn_t gfn);
 void kvm_release_page(struct page *page);
diff --git a/drivers/kvm/kvm_main.c b/drivers/kvm/kvm_main.c
index 8a90f7d..4624761 100644
--- a/drivers/kvm/kvm_main.c
+++ b/drivers/kvm/kvm_main.c
@@ -290,33 +290,7 @@ int __kvm_set_memory_region(struct kvm *kvm,
memset(new.rmap, 0, npages * sizeof(*new.rmap));
 
new.user_alloc = user_alloc;
-   if (user_alloc)
-   new.userspace_addr = mem->userspace_addr;
-   else {
-   down_write(¤t->mm->mmap_sem);
-   new.userspace_addr = do_mmap(NULL, 0,
-npages * PAGE_SIZE,
-PROT_READ |
PROT_WRITE,
-MAP_SHARED |
MAP_ANONYMOUS,
-0);
-   up_write(¤t->mm->mmap_sem);
-
-   if (IS_ERR((void *)new.userspace_addr))
-   goto out_free;
-   }
-   } else {
-   if (!old.user_alloc && old.rmap) {
-   int ret;
-
-   down_write(¤t->mm->mmap_sem);
-   ret = do_munmap(current->mm, old.userspace_addr,
-   old.npages * PAGE_SIZE);
-   up_write(¤t->mm->mmap_sem);
-   if (ret < 0)
-   printk(KERN_WARNING
-  "kvm_vm_ioctl_set_memory_region:
"
-  "failed to munmap memory\n");
-   }
+   new.userspace_addr = mem->userspace_addr;
}
 
/* Allocate page dirty bitmap if needed */
@@ -334,14 +308,12 @@ int __kvm_set_memory_region(struct kvm *kvm,
 
*memslot = new;
 
-   if (!kvm->n_requested_mmu_pages) {
-   unsigned int nr_mmu_pages =
kvm_mmu_calculate_mmu_pages(kvm);
-   kvm_mmu_change_mmu_pages(kvm, nr_mmu_pages);
+   r = kvm_arch_set_memory_region(kvm, mem, old, user_alloc);
+   if (r){
+   *memslot = old;
+   goto out_free;
}
 
-   kvm_mmu_slot_remove_write_access(kvm, mem->slot);
-   kvm_flush_remote_tlbs(kvm);
-
kvm_free_physmem_slot(&old, &new);
return 0;
 
diff --git a/drivers/kvm/x86.c b/drivers/kvm/x86.c
index 40871b5..6864d18 100644
--- a/drivers/kvm/x86.c
+++ b/drivers/kvm/x86.c
@@ -24,6 +24,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -2647,3 +2648,53 @@ void kvm_arch_destroy_vm(struct kvm *kvm)
kvm_free_physmem(kvm);
kfree(kvm);
 }
+
+int kvm_arch_set_memory_region(struct kvm *kvm,
+   struct kvm_userspace_memory_region *mem,
+   struct kvm_memory_slot old,
+   int user_alloc)
+{
+   int npages = mem->memory_size >> PAGE_SHIFT;
+   struct kvm_memory_slot *memslot = &kvm->memslots[mem->slot];
+
+   /*To keep backward compatibility with older userspace,
+*x86 needs to hanlde !user_alloc case.
+*/
+   if (!user_alloc) {
+   if (npages && !old.rmap) {
+   down_write(¤t->mm->mmap_sem);
+   memslot->userspace_addr = do_mmap(NULL, 0,
+npages * PAGE_SIZE,
+PROT_READ |
PROT_WRITE,
+MAP_SHARED |
MAP_ANONYMOUS,
+0);
+   up_write(¤t->mm->mmap_sem);
+
+   if (IS_ERR((void *)memslot-

Re: [kvm-devel] [PATCH 0/7] Move x86 code out of include/linux/kvm.h

[Zhang, Xiantao]

Jerone Young wrote:
> 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. 

Should be fine to IA64. Good work!

Acked-by: Zhang Xiantao<[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

-
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/7] Move x86 code out of include/linux/kvm.h

[Carsten Otte]

Jerone Young wrote:
> 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]>
Whole series looks good to me.
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] Migration doesn't working at all for me

[Izik Eidus]

Avi Kivity wrote:
> Anton Patrushev wrote:
>   
>> [EMAIL PROTECTED] ~]# uname -a
>> Linux localhost.localdomain 2.6.20-1.2320.fc5smp #1 SMP Tue Jun 12 19:40:16 
>> EDT 2007 i686 i686 i386 GNU/Linux
>>
>> [EMAIL PROTECTED] ~]# modinfo kvm
>> filename:   /lib/modules/2.6.20-1.2320.fc5smp/extra/kvm.ko
>> license:GPL
>> author: Qumranet
>> version:kvm-52
>> srcversion: E46DE2B98872EDFF6C75BE1
>> depends:
>> vermagic:   2.6.20-1.2320.fc5smp SMP mod_unload 686 4KSTACKS
>>
>> [EMAIL PROTECTED] ~]# modinfo kvm-intel
>> filename:   /lib/modules/2.6.20-1.2320.fc5smp/extra/kvm-intel.ko
>> license:GPL
>> author: Qumranet
>> version:kvm-52
>> srcversion: F7E80D6C3124584F75EDAAF
>> depends:kvm,kvm
>> vermagic:   2.6.20-1.2320.fc5smp SMP mod_unload 686 4KSTACKS
>> parm:   bypass_guest_pf:bool
>>
>>
>> [EMAIL PROTECTED] 
>> kvm-52]# /usr/local/kvm/bin/qemu-system-x86_64 -hda /dev/sdc -cdrom 
>> /mnt/distribs/Fedora-8-i386-DVD.iso -m 
>> 256 -vnc :0 -net nic -net tap,script=/usr/local/bin/tapup -monitor stdio
>> QEMU 0.9.0 monitor - type 'help' for more information
>> (qemu) stop
>> (qemu) migrate "exec:dd of=STATEFILE"
>> BUG: kvm_dirty_pages_log_change: invalid parameters
>> Could not start migration
>>
>>   
>> 
>
> Probably due to this being a 32-bit host.  We'll look into it.
>   
no avi, it related to the new userspace allocation & qemu new mapping 
that we use
it can be fixed very easily but i talked with uri and we agreed to fix 
it when he get the migration more stable on his place first.


-
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] Migration doesn't working at all for me

[Avi Kivity]

Izik Eidus wrote:
>>
>> Probably due to this being a 32-bit host.  We'll look into it.
>>   
> no avi, it related to the new userspace allocation & qemu new mapping 
> that we use
> it can be fixed very easily but i talked with uri and we agreed to fix 
> it when he get the migration more stable on his place first.
>

Ah okay.  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

[kvm-devel] [ANNOUNCE] kvm-53 release

[Avi Kivity]

Most notable is that an fpu leak on AMD has been plugged.  Currently 
this has some performance impact; next release should restore 
performance while maintaining correctness.

Changes from kvm-52:
- testsuite: exit on end of test
- batch mode for kvm_stat script
- compile fixes (Carlo Marcelo Arenas Belon, Joe Perches)
- portability (Jerone Young, Zhang Xiantao)
- disable lazy fpu on AMD (Amit Shah)
   - should fix instability on AMD
   - will cause performance regression, fix in progress
- x86 emulator: fix 'push r/m' emulation (Amit Shah)
- register use reduction in vmx guest entry
- infrastructure for per-vm stats
   - extends existing per-vcpu stats
- add mmu, state switch, emulation statistics
- use copy_{to,from}_user to access guest memory (Izik Eidus)
- simplify access to guest page tables (Izik Eidus)
- fix entry to real mode with segment bases beyond 1MB (Jan Kiszka)
- finally kill last use of cr2 in emulator (Sheng Yang)

Notes:
  If you use the modules bundled with kvm-53, you can use any version
of Linux from 2.6.9 upwards.
  If you use the modules bundled with Linux 2.6.20, you need to use
kvm-12.
  If you use the modules bundled with Linux 2.6.21, you need to use
kvm-17.
  Modules from Linux 2.6.22 and up will work with any kvm version from
kvm-22.  Some features may only be available in newer releases.
  For best performance, use Linux 2.6.23-rc2 or later as the host.

http://kvm.qumranet.com


-
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

[Avi Kivity]

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.
>
> 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;

What value is actually written into those MSRs?  If the value causes the 
counter to be disabled (e.g. the interrupt enabled bit is cleared) we 
can be more clever: discard the write if it disables interrupts, and 
print a message and return -ESOMETHING if it enables interrupts.  This 
way, if some other guest depends on the performance counters, we'll have 
some indication that something is wrong.

btw, is this Vista x86 or x64?



-- 
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 of 3] cosmetic fixes

[Avi Kivity]

Hollis Blanchard wrote:
> These are a few fixes to minor/cosmetic issues I've stumbled across recently.
>
>   
Thanks, applied all three.


-- 
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] [RFC] virtio-blk PCI backend

[Avi Kivity]

Christian Borntraeger wrote:
> Am Freitag, 9. November 2007 schrieb Dor Laor:
>   
>> I believe that the network interface will quickly go to the kernel since 
>> copy takes most of the
>> cpu time and qemu does not support scatter gather dma at the moment.
>> Nevertheless using pio seems good enough, Anthony's suggestion of 
>> notifying the kernel using ioctls
>> is logical. If we'll run into troubles further on we can add a hypercall 
>> capability and if exist use hypercalls
>> instead of pios.
>> 
>
> Sorry for being late in this thread.
> We (s390) will need a hypercall as we do not have port I/O. I think it should 
> be
> possible to default to hypercall on s390 and use pio everywhere else.
>   

Or be generic: advertise the methods available according to host 
(kvm/x86, qemu/x86, kvm/s390) and let the guest pick.

-- 
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

[Avi Kivity]

Hollis Blanchard wrote:
> 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. :)
>   

It can be probably done in parts with members moved off to x86-land 
incrementally.


-- 
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] discard MSR writes

[Avi Kivity]

Amit Shah wrote:
> On Tuesday 20 November 2007 15:17:54 Avi Kivity wrote:
>   
>> Amit Shah wrote:
>> 
>>> 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)?
>>>   
>> rdmsr will inject #GP for these msrs.  Implementing set_msr() doesn't
>> affect rdmsr.
>> 
>
> >From the AMD programming manual, vol 2:
>
> The performance event-select registers can be read and written only by system 
> software running at CPL = 0 using the RDMSR and WRMSR instructions, 
> respectively. Any attempt to read or write these registers at CPL > 0 causes 
> a general-protection exception to occur.
>   

Look through the code that implements rdmsr, it doesn't care about the 
manuals and will happily inject a #GP for rdmsr of any unimplemented msr 
(like PerfEvtSel)  wrmsr and rdmsr implementations are not linked.

-- 
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] discard MSR writes

[Avi Kivity]

Amit Shah wrote:
> On Tuesday 20 November 2007 15:42:35 Avi Kivity wrote:
>   
>> Amit Shah wrote:
>> 
>>> On Tuesday 20 November 2007 15:17:54 Avi Kivity wrote:
>>>   
 Amit Shah wrote:
 
> 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)?
>   
 rdmsr will inject #GP for these msrs.  Implementing set_msr() doesn't
 affect rdmsr.

 
>>> >From the AMD programming manual, vol 2:
>>>
>>> The performance event-select registers can be read and written only by
>>> system software running at CPL = 0 using the RDMSR and WRMSR
>>> instructions, respectively. Any attempt to read or write these registers
>>> at CPL > 0 causes a general-protection exception to occur.
>>>   
>> Look through the code that implements rdmsr, it doesn't care about the
>> manuals and will happily inject a #GP for rdmsr of any unimplemented msr
>> (like PerfEvtSel)  wrmsr and rdmsr implementations are not linked.
>> 
>
> That's right; but isn't that wrong if we cause it? I mean if we just allow 
> the 
> wrmsr access to go through (and if they're actually used, not disabled as you 
> mentioned separately), then there'll be no interrupts when the guest expects 
> them to occur, or the rdmsr will fail, when the guest thinks it shouldn't 
> have.
>
>   

It is wrong; but at least it fails loudly.  We can't implement all msrs 
(Intel and AMD are adding them faster than we can code), so we must make 
sure that where we don't implement things, at least we have visibility 
if the guest tries to use them.

> I guess we're putting forth the same point: if the wrmsr is not for disabling 
> interrupts, we shouldn't let it go through, or just implement the required 
> emulation.
>   

Yes.  Ignoring an msr will "fix" one guest but kill another.

-- 
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 7/24] consolidate msr.h

[Rusty Russell]

On Tuesday 20 November 2007 17:16:45 Steven Rostedt wrote:
> 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)

Heh:

union ptr_or_val {
void *ptr;
unsigned long long val;
};

static inline void __wrmsrl(unsigned int msr, union ptr_or_val pv);
#define wrmsr(msr, v) __wrmsrl(msr, (union ptr_or_val)v)

Ok, maybe not...
Rusty.

-
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] [RFC] virtio-blk PCI backend

[Carsten Otte]

Arnd Bergmann wrote:
> Not sure if I'm following the reasoning here. Shouldn't the method be
> inherent to the virtio bus driver?
> 
> When you use a PCI based virtio bus, the natural choice would be PIO
> in some way, but you could also have a different virtio implementation
> on PCI that uses hcalls. This choice is completely up to virtio-pci.
> 
> On s390, you have a different virtio backend altogether, so you always
> use DIAG or hcall instead of whatever virtio-pci does.
> 
> The virtio-blk and other high-level drivers don't need to care about
> what transport the bus uses in the first place.

If you look at HPA's virtio PCI bus in lguest, it uses PCI device 
organization but no other PCI features. That's where we're heading, 
because we don't want a different virtio backend.

-
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] KVM: SVM: Fix FPU leak and re-enable lazy FPU switching

[Avi Kivity]

Amit Shah wrote:
> 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.
>   


Applied, 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] discard MSR writes

[Avi Kivity]

Markus Rechberger wrote:
> I also discussed this with Joerg, since Qemu doesn't handle those MSR 
> writes at the moment we think it's ok temporary. Lateron it should be 
> emulated (but we're hunting a different issue at the moment). Our 
> perfmon guys would also prefer a proper emulation.
>

There's no need to copy mistakes from qemu.  I too would prefer proper 
emulation, but meanwhile, if Vista disables performance monitoring when 
writing to these msrs, we can allow it, and error out if some other 
guest attempts to enable performance monitoring (which will fail silently).

-- 
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] KVM Portability : Spliting kvm_set_memory_region.

[Avi Kivity]

Zhang, Xiantao wrote:
> From: Zhang Xiantao <[EMAIL PROTECTED]>
> Date: Tue, 20 Nov 2007 16:25:04 +0800
> Subject: [PATCH] KVM Portability : Spliting kvm_set_memory_region.
> Moving !user_alloc case to kvm_arch to avoid unnecessary
> code logic in non-x86 platform.
> Signed-off-by: Zhang Xiantao <[EMAIL PROTECTED]>
>   

Applied this and the previous patch; 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] discard MSR writes

[Markus Rechberger]

Avi Kivity wrote:
> Amit Shah wrote:
>> On Tuesday 20 November 2007 15:42:35 Avi Kivity wrote:
>>  
>>> Amit Shah wrote:
>>>
 On Tuesday 20 November 2007 15:17:54 Avi Kivity wrote:
  
> Amit Shah wrote:
>
>> 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)?
>>   
> rdmsr will inject #GP for these msrs.  Implementing set_msr() doesn't
> affect rdmsr.
>
> 
 >From the AMD programming manual, vol 2:

 The performance event-select registers can be read and written only by
 system software running at CPL = 0 using the RDMSR and WRMSR
 instructions, respectively. Any attempt to read or write these 
 registers
 at CPL > 0 causes a general-protection exception to occur.
   
>>> Look through the code that implements rdmsr, it doesn't care about the
>>> manuals and will happily inject a #GP for rdmsr of any unimplemented 
>>> msr
>>> (like PerfEvtSel)  wrmsr and rdmsr implementations are not linked.
>>> 
>>
>> That's right; but isn't that wrong if we cause it? I mean if we just 
>> allow the wrmsr access to go through (and if they're actually used, 
>> not disabled as you mentioned separately), then there'll be no 
>> interrupts when the guest expects them to occur, or the rdmsr will 
>> fail, when the guest thinks it shouldn't have.
>>
>>   
>
> It is wrong; but at least it fails loudly.  We can't implement all 
> msrs (Intel and AMD are adding them faster than we can code), so we 
> must make sure that where we don't implement things, at least we have 
> visibility if the guest tries to use them.
>
>> I guess we're putting forth the same point: if the wrmsr is not for 
>> disabling interrupts, we shouldn't let it go through, or just 
>> implement the required emulation.
>>   
>
> Yes.  Ignoring an msr will "fix" one guest but kill another.
>
I also discussed this with Joerg, since Qemu doesn't handle those MSR 
writes at the moment we think it's ok temporary. Lateron it should be 
emulated (but we're hunting a different issue at the moment). Our 
perfmon guys would also prefer a proper emulation.

Markus



-
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] KVM Portability : Spliting kvm_set_memory_region.

[Carsten Otte]

Zhang, Xiantao wrote:
> From: Zhang Xiantao <[EMAIL PROTECTED]>
> Date: Tue, 20 Nov 2007 16:25:04 +0800
> Subject: [PATCH] KVM Portability : Spliting kvm_set_memory_region.
> Moving !user_alloc case to kvm_arch to avoid unnecessary
> code logic in non-x86 platform.
> Signed-off-by: Zhang Xiantao <[EMAIL PROTECTED]>
> ---
>  drivers/kvm/kvm.h  |4 +++
>  drivers/kvm/kvm_main.c |   38 ---
>  drivers/kvm/x86.c  |   51
> 
>  3 files changed, 60 insertions(+), 33 deletions(-)

I don't think we'll want the rmap part in common for s390, but I am 
not sure just yet. If it turns out to be the case, I might submit an 
add on patch that moves it to arch on day. Other then that, this split 
looks good to me. Well done, Xiantao!

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] KVM Test result, kernel 90af65.. , userspace ad220a.

[Avi Kivity]

Zhao, Yunfeng wrote:
>
> Hi, all,
>
> This is today's KVM test result against kvm.git 
> 9fbcc4a1b7cf873a5aa1a357320fb82d588aa316 and kvm-userspace.git 
> 14892fe1817712ff8555a9de474165e9d38d1b90.
>
> One new issue has been found:
>
> 1. Booting multi guests may cause 64bit host to crash
>
> https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1834938&group_id=180599
>  
> 
>

This is now fixed.

-- 
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 3/3] virtio PCI device

[Avi Kivity]

Anthony Liguori wrote:
> This is a PCI device that implements a transport for virtio.  It allows virtio
> devices to be used by QEMU based VMMs like KVM or Xen.
>
> +
> +/* the notify function used when creating a virt queue */
> +static void vp_notify(struct virtqueue *vq)
> +{
> + struct virtio_pci_device *vp_dev = to_vp_device(vq->vdev);
> + struct virtio_pci_vq_info *info = vq->priv;
> +
> + /* we write the queue's selector into the notification register to
> +  * signal the other end */
> + iowrite16(info->queue_index, vp_dev->ioaddr + VIRTIO_PCI_QUEUE_NOTIFY);
> +}
>   

This means we can't kick multiple queues with one exit.

I'd also like to see a hypercall-capable version of this (but that can 
wait).

> +
> +/* A small wrapper to also acknowledge the interrupt when it's handled.
> + * I really need an EIO hook for the vring so I can ack the interrupt once we
> + * know that we'll be handling the IRQ but before we invoke the callback 
> since
> + * the callback may notify the host which results in the host attempting to
> + * raise an interrupt that we would then mask once we acknowledged the
> + * interrupt. */
> +static irqreturn_t vp_interrupt(int irq, void *opaque)
> +{
> + struct virtio_pci_device *vp_dev = opaque;
> + struct virtio_pci_vq_info *info;
> + irqreturn_t ret = IRQ_NONE;
> + u8 isr;
> +
> + /* reading the ISR has the effect of also clearing it so it's very
> +  * important to save off the value. */
> + isr = ioread8(vp_dev->ioaddr + VIRTIO_PCI_ISR);
>   

Can this be implemented via shared memory? We're exiting now on every 
interrupt.


> + return ret;
> +}
> +
> +/* the config->find_vq() implementation */
> +static struct virtqueue *vp_find_vq(struct virtio_device *vdev, unsigned 
> index,
> + bool (*callback)(struct virtqueue *vq))
> +{
> + struct virtio_pci_device *vp_dev = to_vp_device(vdev);
> + struct virtio_pci_vq_info *info;
> + struct virtqueue *vq;
> + int err;
> + u16 num;
> +
> + /* Select the queue we're interested in */
> + iowrite16(index, vp_dev->ioaddr + VIRTIO_PCI_QUEUE_SEL);
>   

I would really like to see this implemented as pci config space, with no 
tricks like multiplexing several virtqueues on one register. Something 
like the PCI BARs where you have all the register numbers allocated 
statically to queues.

> +
> + /* Check if queue is either not available or already active. */
> + num = ioread16(vp_dev->ioaddr + VIRTIO_PCI_QUEUE_NUM);
> + if (!num || ioread32(vp_dev->ioaddr + VIRTIO_PCI_QUEUE_PFN))
> + return ERR_PTR(-ENOENT);
> +
> + /* allocate and fill out our structure the represents an active
> +  * queue */
> + info = kmalloc(sizeof(struct virtio_pci_vq_info), GFP_KERNEL);
> + if (!info)
> + return ERR_PTR(-ENOMEM);
> +
> + info->queue_index = index;
> + info->num = num;
> +
> + /* determine the memory needed for the queue and provide the memory
> +  * location to the host */
> + info->n_pages = DIV_ROUND_UP(vring_size(num), PAGE_SIZE);
> + info->pages = alloc_pages(GFP_KERNEL | __GFP_ZERO,
> +   get_order(info->n_pages));
> + if (info->pages == NULL) {
> + err = -ENOMEM;
> + goto out_info;
> + }
> +
> + /* FIXME: is this sufficient for info->n_pages > 1? */
> + info->queue = kmap(info->pages);
> + if (info->queue == NULL) {
> + err = -ENOMEM;
> + goto out_alloc_pages;
> + }
> +
> + /* activate the queue */
> + iowrite32(page_to_pfn(info->pages),
> +   vp_dev->ioaddr + VIRTIO_PCI_QUEUE_PFN);
> +   
> + /* create the vring */
> + vq = vring_new_virtqueue(info->num, vdev, info->queue,
> +  vp_notify, callback);
> + if (!vq) {
> + err = -ENOMEM;
> + goto out_activate_queue;
> + }
> +
> + vq->priv = info;
> + info->vq = vq;
> +
> + spin_lock(&vp_dev->lock);
> + list_add(&info->node, &vp_dev->virtqueues);
> + spin_unlock(&vp_dev->lock);
> +
>   

Is this run only on init? If so the lock isn't needed.


-- 
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 3/3] virtio PCI device

[Anthony Liguori]

Avi Kivity wrote:
> Anthony Liguori wrote:
>> This is a PCI device that implements a transport for virtio.  It 
>> allows virtio
>> devices to be used by QEMU based VMMs like KVM or Xen.
>>
>> +
>> +/* the notify function used when creating a virt queue */
>> +static void vp_notify(struct virtqueue *vq)
>> +{
>> +struct virtio_pci_device *vp_dev = to_vp_device(vq->vdev);
>> +struct virtio_pci_vq_info *info = vq->priv;
>> +
>> +/* we write the queue's selector into the notification register to
>> + * signal the other end */
>> +iowrite16(info->queue_index, vp_dev->ioaddr + 
>> VIRTIO_PCI_QUEUE_NOTIFY);
>> +}
>>   
>
> This means we can't kick multiple queues with one exit.

There is no interface in virtio currently to batch multiple queue 
notifications so the only way one could do this AFAICT is to use a timer 
to delay the notifications.  Were you thinking of something else?

> I'd also like to see a hypercall-capable version of this (but that can 
> wait).

That can be a different device.

>> +
>> +/* A small wrapper to also acknowledge the interrupt when it's handled.
>> + * I really need an EIO hook for the vring so I can ack the 
>> interrupt once we
>> + * know that we'll be handling the IRQ but before we invoke the 
>> callback since
>> + * the callback may notify the host which results in the host 
>> attempting to
>> + * raise an interrupt that we would then mask once we acknowledged the
>> + * interrupt. */
>> +static irqreturn_t vp_interrupt(int irq, void *opaque)
>> +{
>> +struct virtio_pci_device *vp_dev = opaque;
>> +struct virtio_pci_vq_info *info;
>> +irqreturn_t ret = IRQ_NONE;
>> +u8 isr;
>> +
>> +/* reading the ISR has the effect of also clearing it so it's very
>> + * important to save off the value. */
>> +isr = ioread8(vp_dev->ioaddr + VIRTIO_PCI_ISR);
>>   
>
> Can this be implemented via shared memory? We're exiting now on every 
> interrupt.

I don't think so.  A vmexit is required to lower the IRQ line.  It may 
be possible to do something clever like set a shared memory value that's 
checked on every vmexit.  I think it's very unlikely that it's worth it 
though.

>
>> +return ret;
>> +}
>> +
>> +/* the config->find_vq() implementation */
>> +static struct virtqueue *vp_find_vq(struct virtio_device *vdev, 
>> unsigned index,
>> +bool (*callback)(struct virtqueue *vq))
>> +{
>> +struct virtio_pci_device *vp_dev = to_vp_device(vdev);
>> +struct virtio_pci_vq_info *info;
>> +struct virtqueue *vq;
>> +int err;
>> +u16 num;
>> +
>> +/* Select the queue we're interested in */
>> +iowrite16(index, vp_dev->ioaddr + VIRTIO_PCI_QUEUE_SEL);
>>   
>
> I would really like to see this implemented as pci config space, with 
> no tricks like multiplexing several virtqueues on one register. 
> Something like the PCI BARs where you have all the register numbers 
> allocated statically to queues.

My first implementation did that.  I switched to using a selector 
because it reduces the amount of PCI config space used and does not 
limit the number of queues defined by the ABI as much.

>> +
>> +/* Check if queue is either not available or already active. */
>> +num = ioread16(vp_dev->ioaddr + VIRTIO_PCI_QUEUE_NUM);
>> +if (!num || ioread32(vp_dev->ioaddr + VIRTIO_PCI_QUEUE_PFN))
>> +return ERR_PTR(-ENOENT);
>> +
>> +/* allocate and fill out our structure the represents an active
>> + * queue */
>> +info = kmalloc(sizeof(struct virtio_pci_vq_info), GFP_KERNEL);
>> +if (!info)
>> +return ERR_PTR(-ENOMEM);
>> +
>> +info->queue_index = index;
>> +info->num = num;
>> +
>> +/* determine the memory needed for the queue and provide the memory
>> + * location to the host */
>> +info->n_pages = DIV_ROUND_UP(vring_size(num), PAGE_SIZE);
>> +info->pages = alloc_pages(GFP_KERNEL | __GFP_ZERO,
>> +  get_order(info->n_pages));
>> +if (info->pages == NULL) {
>> +err = -ENOMEM;
>> +goto out_info;
>> +}
>> +
>> +/* FIXME: is this sufficient for info->n_pages > 1? */
>> +info->queue = kmap(info->pages);
>> +if (info->queue == NULL) {
>> +err = -ENOMEM;
>> +goto out_alloc_pages;
>> +}
>> +
>> +/* activate the queue */
>> +iowrite32(page_to_pfn(info->pages),
>> +  vp_dev->ioaddr + VIRTIO_PCI_QUEUE_PFN);
>> +  +/* create the vring */
>> +vq = vring_new_virtqueue(info->num, vdev, info->queue,
>> + vp_notify, callback);
>> +if (!vq) {
>> +err = -ENOMEM;
>> +goto out_activate_queue;
>> +}
>> +
>> +vq->priv = info;
>> +info->vq = vq;
>> +
>> +spin_lock(&vp_dev->lock);
>> +list_add(&info->node, &vp_dev->virtqueues);
>> +spin_unlock(&vp_dev->lock);
>> +
>>   
>
> Is this run only on init? If so the lock isn't needed.

Yes, it's also not stricly needed on cleanup I think.  I left it there 
though for 

Re: [kvm-devel] [PATCH 3/3] virtio PCI device

[Avi Kivity]

Anthony Liguori wrote:
> Avi Kivity wrote:
>   
>> Anthony Liguori wrote:
>> 
>>> This is a PCI device that implements a transport for virtio.  It 
>>> allows virtio
>>> devices to be used by QEMU based VMMs like KVM or Xen.
>>>
>>> +
>>> +/* the notify function used when creating a virt queue */
>>> +static void vp_notify(struct virtqueue *vq)
>>> +{
>>> +struct virtio_pci_device *vp_dev = to_vp_device(vq->vdev);
>>> +struct virtio_pci_vq_info *info = vq->priv;
>>> +
>>> +/* we write the queue's selector into the notification register to
>>> + * signal the other end */
>>> +iowrite16(info->queue_index, vp_dev->ioaddr + 
>>> VIRTIO_PCI_QUEUE_NOTIFY);
>>> +}
>>>   
>>>   
>> This means we can't kick multiple queues with one exit.
>> 
>
> There is no interface in virtio currently to batch multiple queue 
> notifications so the only way one could do this AFAICT is to use a timer 
> to delay the notifications.  Were you thinking of something else?
>
>   

No.  We can change virtio though, so let's have a flexible ABI.

>> I'd also like to see a hypercall-capable version of this (but that can 
>> wait).
>> 
>
> That can be a different device.
>   

That means the user has to select which device to expose.  With feature 
bits, the hypervisor advertises both pio and hypercalls, the guest picks 
whatever it wants.

>   
>>> +
>>> +/* A small wrapper to also acknowledge the interrupt when it's handled.
>>> + * I really need an EIO hook for the vring so I can ack the 
>>> interrupt once we
>>> + * know that we'll be handling the IRQ but before we invoke the 
>>> callback since
>>> + * the callback may notify the host which results in the host 
>>> attempting to
>>> + * raise an interrupt that we would then mask once we acknowledged the
>>> + * interrupt. */
>>> +static irqreturn_t vp_interrupt(int irq, void *opaque)
>>> +{
>>> +struct virtio_pci_device *vp_dev = opaque;
>>> +struct virtio_pci_vq_info *info;
>>> +irqreturn_t ret = IRQ_NONE;
>>> +u8 isr;
>>> +
>>> +/* reading the ISR has the effect of also clearing it so it's very
>>> + * important to save off the value. */
>>> +isr = ioread8(vp_dev->ioaddr + VIRTIO_PCI_ISR);
>>>   
>>>   
>> Can this be implemented via shared memory? We're exiting now on every 
>> interrupt.
>> 
>
> I don't think so.  A vmexit is required to lower the IRQ line.  It may 
> be possible to do something clever like set a shared memory value that's 
> checked on every vmexit.  I think it's very unlikely that it's worth it 
> though.
>   

Why so unlikely?  Not all workloads will have good batching.


>   
>>> +return ret;
>>> +}
>>> +
>>> +/* the config->find_vq() implementation */
>>> +static struct virtqueue *vp_find_vq(struct virtio_device *vdev, 
>>> unsigned index,
>>> +bool (*callback)(struct virtqueue *vq))
>>> +{
>>> +struct virtio_pci_device *vp_dev = to_vp_device(vdev);
>>> +struct virtio_pci_vq_info *info;
>>> +struct virtqueue *vq;
>>> +int err;
>>> +u16 num;
>>> +
>>> +/* Select the queue we're interested in */
>>> +iowrite16(index, vp_dev->ioaddr + VIRTIO_PCI_QUEUE_SEL);
>>>   
>>>   
>> I would really like to see this implemented as pci config space, with 
>> no tricks like multiplexing several virtqueues on one register. 
>> Something like the PCI BARs where you have all the register numbers 
>> allocated statically to queues.
>> 
>
> My first implementation did that.  I switched to using a selector 
> because it reduces the amount of PCI config space used and does not 
> limit the number of queues defined by the ABI as much.
>   

But... it's tricky, and it's nonstandard.  With pci config, you can do 
live migration by shipping the pci config space to the other side.  With 
the special iospace, you need to encode/decode it.

Not much of an argument, I know.


wrt. number of queues, 8 queues will consume 32 bytes of pci space if 
all you store is the ring pfn.


-- 
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-1835207 ] Windows 2000 setup fails on AMD

[SourceForge.net]

Bugs item #1835207, was opened at 2007-11-20 17:27
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1835207&group_id=180599

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Technologov (technologov)
Assigned to: Nobody/Anonymous (nobody)
Summary: Windows 2000 setup fails on AMD

Initial Comment:
Host: AMD Barcelona, Fedora7/x64, KVM-53.

Guest: Windows 2000.

Windows 2000 auto-restarts during the "Install components" stage. This 
effectively prevents installation.

The command sent to Qemu/KVM is: /usr/local/bin/qemu-system-x86_64 -hda 
/isos/disks-vm/alexeye/Windows2000-test.qcow2 -m 128 -monitor 
tcp:localhost:4501,server,nowait -cdrom /isos/windows/Windows2000_SP4.ISO -boot 
d -no-acpi

dmesg output:
apic write: bad size=1 fee00030
Ignoring de-assert INIT to vcpu 0
Ignoring de-assert INIT to vcpu 0

The same works fine on Intel.

-Alexey

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1835207&group_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

[kvm-devel] [ kvm-Bugs-1835211 ] SUSE Linux 9.1 Setup fails on AMD

[SourceForge.net]

Bugs item #1835211, was opened at 2007-11-20 17:33
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1835211&group_id=180599

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Technologov (technologov)
Assigned to: Nobody/Anonymous (nobody)
Summary: SUSE Linux 9.1 Setup fails on AMD

Initial Comment:
Host: AMD Barcelona, Fedora7/x64, KVM-53.

Guest: SUSE Linux9.1. and openSUSE 10.3.

both guests auto-restarts during the setup. This
effectively prevents installation.

The command sent to Qemu/KVM is: /usr/local/bin/qemu-system-x86_64 -hda 
/isos/disks-vm/alexeye/openSUSE-10.3-test32.vmdk -m 384 -monitor 
tcp:localhost:4534,server,nowait -cdrom /isos/linux/openSUSE-10.3-32-bit.iso 
-boot d

openSUSE Linux 10.3 doesn't work on Intel due to lack of real mode support.

-Alexey


Dmesg output:

kvm: emulating exchange as write
apic write: bad size=1 fee00030
Ignoring de-assert INIT to vcpu 0
kvm: 8784: cpu0 unhandled rdmsr: 0x417
kvm: 8784: cpu0 unhandled rdmsr: 0xc400
kvm: 8784: cpu0 unhandled rdmsr: 0xc401
kvm: 8784: cpu0 unhandled rdmsr: 0xc402
kvm: 8784: cpu0 unhandled rdmsr: 0xc403
kvm: 8784: cpu0 unhandled rdmsr: 0xc404
kvm: 8784: cpu0 unhandled rdmsr: 0xc405
kvm: 8784: cpu0 unhandled rdmsr: 0xc406
kvm: 8784: cpu0 unhandled rdmsr: 0xc407
kvm: 12456: cpu0 kvm_set_msr_common: MSR_IA32_MC0_STATUS 0x0, nop
apic write: bad size=1 fee00030
Ignoring de-assert INIT to vcpu 0
apic write: bad size=1 fee00030
Ignoring de-assert INIT to vcpu 0
kvm: 32622: cpu0 kvm_set_msr_common: MSR_IA32_MC0_STATUS 0x0, nop
apic write: bad size=1 fee00030
Ignoring de-assert INIT to vcpu 0
kvm: 4790: cpu0 unhandled rdmsr: 0x417
kvm: 4790: cpu0 unhandled rdmsr: 0xc400
kvm: 4790: cpu0 unhandled rdmsr: 0xc401
kvm: 4790: cpu0 unhandled rdmsr: 0xc402
kvm: 4790: cpu0 unhandled rdmsr: 0xc403
kvm: 4790: cpu0 unhandled rdmsr: 0xc404
kvm: 4790: cpu0 unhandled rdmsr: 0xc405
kvm: 4790: cpu0 unhandled rdmsr: 0xc406
kvm: 4790: cpu0 unhandled rdmsr: 0xc407
qemu-system-x86[4790]: segfault at  rip 0031348784a0 rsp 
7086f758 error 6
apic write: bad size=1 fee00030
Ignoring de-assert INIT to vcpu 0
kvm: 14673: cpu0 unhandled rdmsr: 0x417
kvm: 14673: cpu0 unhandled rdmsr: 0xc400
kvm: 14673: cpu0 unhandled rdmsr: 0xc401
kvm: 14673: cpu0 unhandled rdmsr: 0xc402
kvm: 14673: cpu0 unhandled rdmsr: 0xc403
kvm: 14673: cpu0 unhandled rdmsr: 0xc404
kvm: 14673: cpu0 unhandled rdmsr: 0xc405
kvm: 14673: cpu0 unhandled rdmsr: 0xc406
kvm: 14673: cpu0 unhandled rdmsr: 0xc407
apic write: bad size=1 fee00030
Ignoring de-assert INIT to vcpu 0
kvm: 15539: cpu0 unhandled wrmsr: 0xc001
apic write: bad size=1 fee00030
Ignoring de-assert INIT to vcpu 0
kvm: 25569: cpu0 unhandled wrmsr: 0xc001
apic write: bad size=1 fee00030
Ignoring de-assert INIT to vcpu 0
Ignoring de-assert INIT to vcpu 0
apic write: bad size=1 fee00030
Ignoring de-assert INIT to vcpu 0
Ignoring de-assert INIT to vcpu 0
apic write: bad size=1 fee00030
Ignoring de-assert INIT to vcpu 0
kvm: 29744: cpu0 unhandled wrmsr: 0xc001
kvm: 2079: cpu0 kvm_set_msr_common: MSR_IA32_MC0_STATUS 0x0, nop
apic write: bad size=1 fee00030
Ignoring de-assert INIT to vcpu 0
Ignoring de-assert INIT to vcpu 0
kvm: 6065: cpu0 kvm_set_msr_common: MSR_IA32_MC0_STATUS 0x0, nop
qemu-system-x86[14673]: segfault at 003100626184 rip 003134870695 rsp 
7fffdc96aa70 error 6
apic write: bad size=1 fee00030
Ignoring de-assert INIT to vcpu 0
kvm: 13660: cpu0 unhandled wrmsr: 0xc001
kvm: 7484: cpu0 kvm_set_msr_common: MSR_IA32_MC0_STATUS 0x0, nop
kvm: 9247: cpu0 kvm_set_msr_common: MSR_IA32_MC0_STATUS 0x0, nop
kvm: 9247: cpu0 unhandled wrmsr: 0xc0010004
kvm: 9247: cpu0 unhandled wrmsr: 0xc001
kvm: 9247: cpu0 unhandled wrmsr: 0xc0010004
kvm: 9247: cpu0 unhandled wrmsr: 0xc001
kvm: 7484: cpu0 kvm_set_msr_common: MSR_IA32_MC0_STATUS 0x0, nop
kvm: 16386: cpu0 kvm_set_msr_common: MSR_IA32_MC0_STATUS 0x0, nop
kvm: 17478: cpu0 kvm_set_msr_common: MSR_IA32_MC0_STATUS 0x0, nop
kvm: 26160: cpu0 kvm_set_msr_common: MSR_IA32_MC0_STATUS 0x0, nop
kvm: 9247: cpu0 kvm_set_msr_common: MSR_IA32_MC0_STATUS 0x0, nop
kvm: 9247: cpu0 unhandled wrmsr: 0xc0010004
kvm: 9247: cpu0 unhandled wrmsr: 0xc001
kvm: 9247: cpu0 unhandled wrmsr: 0xc0010004
kvm: 9247: cpu0 unhandled wrmsr: 0xc001
kvm: 9247: cpu0 kvm_set_msr_common: MSR_IA32_MC0_STATUS 0x0, nop
kvm: 9247: cpu0 unhandled wrmsr: 0xc0010004
kvm: 9247: cpu0 unhandled wrmsr: 0xc001
kvm: 9247: cpu0 unhandled wrmsr: 0xc0010004
kvm: 9247: cpu0 unhandled wrmsr: 0xc001
kvm: 26160: cpu0 kvm_set_msr_common: MSR_IA32_M

[kvm-devel] [PATCH] 2/10 KVM Portability: Moving naliases and aliases fileds to kvm_x86.

[Zhang, Xiantao]

>From fbeb4f42542b7fd996331529a8e3afe3f62ee462 Mon Sep 17 00:00:00 2001
From: Zhang Xiantao <[EMAIL PROTECTED]>
Date: Tue, 20 Nov 2007 22:45:32 +0800
Subject: [PATCH] KVM Portability: Splitting kvm structure
Moving naliases and aliases fileds to kvm_x86.
Signed-off-by: Zhang Xiantao <[EMAIL PROTECTED]>
---
 drivers/kvm/kvm.h  |2 --
 drivers/kvm/kvm_main.c |5 +++--
 drivers/kvm/x86.c  |7 ---
 drivers/kvm/x86.h  |2 ++
 4 files changed, 9 insertions(+), 7 deletions(-)

diff --git a/drivers/kvm/kvm.h b/drivers/kvm/kvm.h
index b65f5de..476150c 100644
--- a/drivers/kvm/kvm.h
+++ b/drivers/kvm/kvm.h
@@ -304,8 +304,6 @@ struct kvm_vm_stat {
 
 struct kvm {
struct mutex lock; /* protects everything except vcpus */
-   int naliases;
-   struct kvm_mem_alias aliases[KVM_ALIAS_SLOTS];
int nmemslots;
struct kvm_memory_slot memslots[KVM_MEMORY_SLOTS +
KVM_PRIVATE_MEM_SLOTS];
diff --git a/drivers/kvm/kvm_main.c b/drivers/kvm/kvm_main.c
index 2733fbf..2490e06 100644
--- a/drivers/kvm/kvm_main.c
+++ b/drivers/kvm/kvm_main.c
@@ -404,9 +404,10 @@ gfn_t unalias_gfn(struct kvm *kvm, gfn_t gfn)
 {
int i;
struct kvm_mem_alias *alias;
+   struct kvm_x86 *kvm_x86 = to_kvm_x86(kvm);
 
-   for (i = 0; i < kvm->naliases; ++i) {
-   alias = &kvm->aliases[i];
+   for (i = 0; i < kvm_x86->naliases; ++i) {
+   alias = &kvm_x86->aliases[i];
if (gfn >= alias->base_gfn
&& gfn < alias->base_gfn + alias->npages)
return alias->target_gfn + gfn -
alias->base_gfn;
diff --git a/drivers/kvm/x86.c b/drivers/kvm/x86.c
index fd2ccb9..15b43f5 100644
--- a/drivers/kvm/x86.c
+++ b/drivers/kvm/x86.c
@@ -843,6 +843,7 @@ static int kvm_vm_ioctl_set_memory_alias(struct kvm
*kvm,
 {
int r, n;
struct kvm_mem_alias *p;
+   struct kvm_x86 *kvm_x86 = to_kvm_x86(kvm);
 
r = -EINVAL;
/* General sanity checks */
@@ -861,15 +862,15 @@ static int kvm_vm_ioctl_set_memory_alias(struct
kvm *kvm,
 
mutex_lock(&kvm->lock);
 
-   p = &kvm->aliases[alias->slot];
+   p = &kvm_x86->aliases[alias->slot];
p->base_gfn = alias->guest_phys_addr >> PAGE_SHIFT;
p->npages = alias->memory_size >> PAGE_SHIFT;
p->target_gfn = alias->target_phys_addr >> PAGE_SHIFT;
 
for (n = KVM_ALIAS_SLOTS; n > 0; --n)
-   if (kvm->aliases[n - 1].npages)
+   if (kvm_x86->aliases[n - 1].npages)
break;
-   kvm->naliases = n;
+   kvm_x86->naliases = n;
 
kvm_mmu_zap_all(kvm);
 
diff --git a/drivers/kvm/x86.h b/drivers/kvm/x86.h
index 5a87557..e5db023 100644
--- a/drivers/kvm/x86.h
+++ b/drivers/kvm/x86.h
@@ -158,6 +158,8 @@ struct kvm_vcpu {
 
 struct kvm_x86 {
struct kvm kvm;
+   int naliases;
+   struct kvm_mem_alias aliases[KVM_ALIAS_SLOTS];
 };
 
 static inline struct kvm_x86 *to_kvm_x86(struct kvm *kvm)
-- 
1.5.1.2


0002-KVM-Portability-Splitting-kvm-structure.patch
Description: 0002-KVM-Portability-Splitting-kvm-structure.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/10 KVM Portability: Introducing kvm_x86 to hold x86-specific fields

[Zhang, Xiantao]

>From 32bc765f65184f6612549a52ead86c740d0ce5a9 Mon Sep 17 00:00:00 2001
From: Zhang Xiantao <[EMAIL PROTECTED]>
Date: Tue, 20 Nov 2007 22:40:04 +0800
Subject: [PATCH] KVM Portability: Spliting kvm structure.
Introduing kvm_x86 structure to hold x86_specific fileds,
but only infrastructure is implemented.
Signed-off-by: Zhang Xiantao <[EMAIL PROTECTED]>
---
 drivers/kvm/x86.c |8 
 drivers/kvm/x86.h |9 +
 2 files changed, 13 insertions(+), 4 deletions(-)

diff --git a/drivers/kvm/x86.c b/drivers/kvm/x86.c
index 2b41217..fd2ccb9 100644
--- a/drivers/kvm/x86.c
+++ b/drivers/kvm/x86.c
@@ -2591,14 +2591,14 @@ void kvm_arch_vcpu_uninit(struct kvm_vcpu *vcpu)
 
 struct  kvm *kvm_arch_create_vm(void)
 {
-   struct kvm *kvm = kzalloc(sizeof(struct kvm), GFP_KERNEL);
+   struct kvm_x86 *kvm_x86 = kzalloc(sizeof(struct kvm_x86),
GFP_KERNEL);
 
-   if (!kvm)
+   if (!kvm_x86)
return ERR_PTR(-ENOMEM);
 
-   INIT_LIST_HEAD(&kvm->active_mmu_pages);
+   INIT_LIST_HEAD(&kvm_x86->kvm.active_mmu_pages);
 
-   return kvm;
+   return &kvm_x86->kvm;
 }
 
 static void kvm_unload_vcpu_mmu(struct kvm_vcpu *vcpu)
diff --git a/drivers/kvm/x86.h b/drivers/kvm/x86.h
index 71f2477..5a87557 100644
--- a/drivers/kvm/x86.h
+++ b/drivers/kvm/x86.h
@@ -156,6 +156,15 @@ struct kvm_vcpu {
struct x86_emulate_ctxt emulate_ctxt;
 };
 
+struct kvm_x86 {
+   struct kvm kvm;
+};
+
+static inline struct kvm_x86 *to_kvm_x86(struct kvm *kvm)
+{
+   return container_of(kvm, struct kvm_x86, kvm);
+}
+
 struct kvm_x86_ops {
int (*cpu_has_kvm_support)(void);  /* __init */
int (*disabled_by_bios)(void); /* __init */
-- 
1.5.1.2


0001-KVM-Portability-Spliting-kvm-structure.patch
Description: 0001-KVM-Portability-Spliting-kvm-structure.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] 9/10 KVM Portability: Moving the filed stat to kvm_x86.

[Zhang, Xiantao]

>From 7c007a478b0369c54e4efcc05311c51b8fc8f037 Mon Sep 17 00:00:00 2001
From: Zhang Xiantao <[EMAIL PROTECTED]>
Date: Tue, 20 Nov 2007 23:41:44 +0800
Subject: [PATCH] KVM Portability: Splitting kvm strcuture
Moving the filed stat to kvm_x86.
Signed-off-by: Zhang Xiantao <[EMAIL PROTECTED]>
---
 drivers/kvm/kvm.h |   10 --
 drivers/kvm/mmu.c |   14 --
 drivers/kvm/x86.c |2 +-
 drivers/kvm/x86.h |   10 ++
 4 files changed, 19 insertions(+), 17 deletions(-)

diff --git a/drivers/kvm/kvm.h b/drivers/kvm/kvm.h
index 0df84b6..f752797 100644
--- a/drivers/kvm/kvm.h
+++ b/drivers/kvm/kvm.h
@@ -204,15 +204,6 @@ struct kvm_memory_slot {
int user_alloc;
 };
 
-struct kvm_vm_stat {
-   u32 mmu_shadow_zapped;
-   u32 mmu_pte_write;
-   u32 mmu_pte_updated;
-   u32 mmu_pde_zapped;
-   u32 mmu_flooded;
-   u32 mmu_recycled;
-};
-
 struct kvm {
struct mutex lock; /* protects everything except vcpus */
int nmemslots;
@@ -224,7 +215,6 @@ struct kvm {
struct kvm_io_bus mmio_bus;
struct kvm_io_bus pio_bus;
int round_robin_prev_vcpu;
-   struct kvm_vm_stat stat;
 };
 
 struct descriptor_table {
diff --git a/drivers/kvm/mmu.c b/drivers/kvm/mmu.c
index 683ad72..9ec754a 100644
--- a/drivers/kvm/mmu.c
+++ b/drivers/kvm/mmu.c
@@ -767,7 +767,7 @@ static void kvm_mmu_zap_page(struct kvm *kvm,
u64 *parent_pte;
struct kvm_x86 *kvm_x86 = to_kvm_x86(kvm);
 
-   ++kvm->stat.mmu_shadow_zapped;
+   ++kvm_x86->stat.mmu_shadow_zapped;
while (page->multimapped || page->parent_pte) {
if (!page->multimapped)
parent_pte = page->parent_pte;
@@ -1246,12 +1246,14 @@ static void mmu_pte_write_new_pte(struct
kvm_vcpu *vcpu,
  const void *new, int bytes,
  int offset_in_pte)
 {
+   struct kvm_x86 *kvm_x86 = to_kvm_x86(vcpu->kvm);
+
if (page->role.level != PT_PAGE_TABLE_LEVEL) {
-   ++vcpu->kvm->stat.mmu_pde_zapped;
+   ++kvm_x86->stat.mmu_pde_zapped;
return;
}
 
-   ++vcpu->kvm->stat.mmu_pte_updated;
+   ++kvm_x86->stat.mmu_pte_updated;
if (page->role.glevels == PT32_ROOT_LEVEL)
paging32_update_pte(vcpu, page, spte, new, bytes,
offset_in_pte);
@@ -1287,7 +1289,7 @@ void kvm_mmu_pte_write(struct kvm_vcpu *vcpu,
gpa_t gpa,
struct kvm_x86 *kvm_x86 = to_kvm_x86(vcpu->kvm);
 
pgprintk("%s: gpa %llx bytes %d\n", __FUNCTION__, gpa, bytes);
-   ++vcpu->kvm->stat.mmu_pte_write;
+   ++kvm_x86->stat.mmu_pte_write;
kvm_mmu_audit(vcpu, "pre pte write");
if (gfn == vcpu->last_pt_write_gfn
&& !last_updated_pte_accessed(vcpu)) {
@@ -1321,7 +1323,7 @@ void kvm_mmu_pte_write(struct kvm_vcpu *vcpu,
gpa_t gpa,
pgprintk("misaligned: gpa %llx bytes %d role
%x\n",
 gpa, bytes, page->role.word);
kvm_mmu_zap_page(vcpu->kvm, page);
-   ++vcpu->kvm->stat.mmu_flooded;
+   ++kvm_x86->stat.mmu_flooded;
continue;
}
page_offset = offset;
@@ -1372,7 +1374,7 @@ void __kvm_mmu_free_some_pages(struct kvm_vcpu
*vcpu)
page = container_of(kvm_x86->active_mmu_pages.prev,
struct kvm_mmu_page, link);
kvm_mmu_zap_page(vcpu->kvm, page);
-   ++vcpu->kvm->stat.mmu_recycled;
+   ++kvm_x86->stat.mmu_recycled;
}
 }
 
diff --git a/drivers/kvm/x86.c b/drivers/kvm/x86.c
index ace1dbc..a969d15 100644
--- a/drivers/kvm/x86.c
+++ b/drivers/kvm/x86.c
@@ -43,7 +43,7 @@
 #define CR8_RESERVED_BITS (~(unsigned long)X86_CR8_TPR)
 #define EFER_RESERVED_BITS 0xf2fe
 
-#define VM_STAT(x) offsetof(struct kvm, stat.x), KVM_STAT_VM
+#define VM_STAT(x) offsetof(struct kvm_x86, stat.x), KVM_STAT_VM
 #define VCPU_STAT(x) offsetof(struct kvm_vcpu, stat.x), KVM_STAT_VCPU
 
 struct kvm_x86_ops *kvm_x86_ops;
diff --git a/drivers/kvm/x86.h b/drivers/kvm/x86.h
index 11f7626..4093c81 100644
--- a/drivers/kvm/x86.h
+++ b/drivers/kvm/x86.h
@@ -245,6 +245,15 @@ struct kvm_mem_alias {
gfn_t target_gfn;
 };
 
+struct kvm_vm_stat {
+   u32 mmu_shadow_zapped;
+   u32 mmu_pte_write;
+   u32 mmu_pte_updated;
+   u32 mmu_pde_zapped;
+   u32 mmu_flooded;
+   u32 mmu_recycled;
+};
+
 struct kvm_x86 {
struct kvm kvm;
int naliases;
@@ -261,6 +270,7 @@ struct kvm_x86 {
struct kvm_ioapic *vioapic;
unsigned int tss_addr;
struct page *apic_access_page;
+   struct kvm_vm_stat stat;
 };
 
 static inline struct kvm_x86 *to_kvm_x86(struct kvm *kvm)
-- 
1.5.1.2


0009-KVM-Portability-Splitting-kvm-strcuture.patch
Description: 0009-KVM-Portability-Splitting-kvm-strcuture.patch
-

[kvm-devel] [PATCH]10/10 Moving descriptor_table definition to x86.h

[Zhang, Xiantao]

>From f23cb5d86802eddcc8330dcf966c44e086f9227a Mon Sep 17 00:00:00 2001
From: Zhang Xiantao <[EMAIL PROTECTED]>
Date: Tue, 20 Nov 2007 23:43:09 +0800
Subject: [PATCH] Moving descriptor_table definition to x86.h
Signed-off-by: Zhang Xiantao <[EMAIL PROTECTED]>
---
 drivers/kvm/kvm.h |5 -
 drivers/kvm/x86.h |5 +
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/kvm/kvm.h b/drivers/kvm/kvm.h
index f752797..11e8491 100644
--- a/drivers/kvm/kvm.h
+++ b/drivers/kvm/kvm.h
@@ -217,11 +217,6 @@ struct kvm {
int round_robin_prev_vcpu;
 };
 
-struct descriptor_table {
-   u16 limit;
-   unsigned long base;
-} __attribute__((packed));
-
 /* The guest did something we don't support. */
 #define pr_unimpl(vcpu, fmt, ...)
\
  do {
\
diff --git a/drivers/kvm/x86.h b/drivers/kvm/x86.h
index 4093c81..59c4da7 100644
--- a/drivers/kvm/x86.h
+++ b/drivers/kvm/x86.h
@@ -171,6 +171,11 @@ struct kvm_mmu_memory_cache {
void *objects[KVM_NR_MEM_OBJS];
 };
 
+struct descriptor_table {
+   u16 limit;
+   unsigned long base;
+} __attribute__((packed));
+
 #include "x86_emulate.h"
 
 struct kvm_vcpu {
-- 
1.5.1.2


0010-Moving-descriptor_table-definition-to-x86.h.patch
Description: 0010-Moving-descriptor_table-definition-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] 6/10 KVM Portability:Moving fields vpic and vioapic to kvm_x86.

[Zhang, Xiantao]

>From 52a33b98a3c53b4e888f71b3c149cf7cec88b026 Mon Sep 17 00:00:00 2001
From: Zhang Xiantao <[EMAIL PROTECTED]>
Date: Tue, 20 Nov 2007 23:23:50 +0800
Subject: [PATCH] KVM Portability: Splitting kvm structure.
Moving fields vpic and vioapic to kvm_x86.
Signed-off-by: Zhang Xiantao <[EMAIL PROTECTED]>
---
 drivers/kvm/i8259.c  |1 +
 drivers/kvm/ioapic.c |7 +--
 drivers/kvm/kvm.h|   17 -
 drivers/kvm/x86.c|   18 ++
 drivers/kvm/x86.h|   21 +
 5 files changed, 37 insertions(+), 27 deletions(-)

diff --git a/drivers/kvm/i8259.c b/drivers/kvm/i8259.c
index f0dc2ee..8871eb8 100644
--- a/drivers/kvm/i8259.c
+++ b/drivers/kvm/i8259.c
@@ -27,6 +27,7 @@
  */
 #include 
 #include "irq.h"
+#include "x86.h"
 
 /*
  * set irq level. If an edge is detected, then the IRR is set to 1
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/kvm.h b/drivers/kvm/kvm.h
index dac517f..bcfa555 100644
--- a/drivers/kvm/kvm.h
+++ b/drivers/kvm/kvm.h
@@ -223,29 +223,12 @@ struct kvm {
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;
diff --git a/drivers/kvm/x86.c b/drivers/kvm/x86.c
index d41d962..ace1dbc 100644
--- a/drivers/kvm/x86.c
+++ b/drivers/kvm/x86.c
@@ -995,6 +995,7 @@ long kvm_arch_vm_ioctl(struct file *filp,
struct kvm *kvm = filp->private_data;
void __user *argp = (void __user *)arg;
int r = -EINVAL;
+   struct kvm_x86 *kvm_x86 = to_kvm_x86(kvm);
 
switch (ioctl) {
case KVM_SET_TSS_ADDR:
@@ -1039,12 +1040,12 @@ long kvm_arch_vm_ioctl(struct file *filp,
}
case KVM_CREATE_IRQCHIP:
r = -ENOMEM;
-   kvm->vpic = kvm_create_pic(kvm);
-   if (kvm->vpic) {
+   kvm_x86->vpic = kvm_create_pic(kvm);
+   if (kvm_x86->vpic) {
r = kvm_ioapic_init(kvm);
if (r) {
-   kfree(kvm->vpic);
-   kvm->vpic = NULL;
+   kfree(kvm_x86->vpic);
+   kvm_x86->vpic = NULL;
goto out;
}
} else
@@ -1062,7 +1063,7 @@ long kvm_arch_vm_ioctl(struct file *filp,
kvm_pic_set_irq(pic_irqchip(kvm),
irq_event.irq,
irq_event.level);
-   kvm_ioapic_set_irq(kvm->vioapic,
+   kvm_ioapic_set_irq(kvm_x86->vioapic,
irq_event.irq,
irq_event.level);
mutex_unlock(&kvm->lock);
@@ -2649,8 +2650,10 @@ static void kvm_free_vcpus(struct kvm *kvm)
 
 void kvm_arch_destroy_vm(struct kvm *kvm)
 {
-   kfree(kvm->vpic);
-   kfree(kvm->vioapic);
+   struct kvm_x86 *kvm_x86 = to_kvm_x86(kvm);
+
+   kfree(kvm_x86->vpic);
+   kfree(kvm_x86->vioapic);
kvm_free_vcpus(kvm);
kvm_free_physmem(kvm);
kfree(kvm);
@@ -2665,7 +2668,6 @@ int kvm_arch_set_memory_region(struct kvm *kvm,
struct kvm_memory_slot *memslot = &kvm->memslots[mem->slot];
struct kvm_x86 *kvm_x86 = to_kvm_x86(kvm);
 
-
/*To keep backward compatibility with older userspace,
 *x86 needs to hanlde !u

[kvm-devel] [PATCH] 5/10 KVM Portability: Moving out definitions related to mmu from kvm.h

[Zhang, Xiantao]

>From 32c70b0f1b605585d9e296bc8c5431f40a194ba7 Mon Sep 17 00:00:00 2001
From: Zhang Xiantao <[EMAIL PROTECTED]>
Date: Tue, 20 Nov 2007 23:13:33 +0800
Subject: [PATCH] KVM Portability: Moving out definitions related to mmu
from kvm.h
Signed-off-by: Zhang Xiantao <[EMAIL PROTECTED]>
---
 drivers/kvm/kvm.h |   83
-
 drivers/kvm/x86.h |   83
+
 2 files changed, 83 insertions(+), 83 deletions(-)

diff --git a/drivers/kvm/kvm.h b/drivers/kvm/kvm.h
index 1e1d515..dac517f 100644
--- a/drivers/kvm/kvm.h
+++ b/drivers/kvm/kvm.h
@@ -58,92 +58,9 @@ 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
-
-/*
- * 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];
-};
-
 struct kvm_guest_debug {
int enabled;
unsigned long bp[4];
diff --git a/drivers/kvm/x86.h b/drivers/kvm/x86.h
index 788ec13..ea8e635 100644
--- a/drivers/kvm/x86.h
+++ b/drivers/kvm/x86.h
@@ -88,6 +88,89 @@ enum {
VCPU_SREG_LDTR,
 };
 
+#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; /* On

[kvm-devel] [PATCH] 3/10 KVM Portability: Moving out kvm_mem_alias, and unalias_gfn definitions from common code.

[Zhang, Xiantao]

From: Zhang Xiantao <[EMAIL PROTECTED]>
Date: Tue, 20 Nov 2007 22:54:22 +0800
Subject: [PATCH] KVM Portability: Moving out kvm_mem_alias, and
unalias_gfn definitions from common code.
Signed-off-by: Zhang Xiantao <[EMAIL PROTECTED]>
---
 drivers/kvm/kvm.h  |6 --
 drivers/kvm/kvm_main.c |   15 ---
 drivers/kvm/x86.c  |   15 +++
 drivers/kvm/x86.h  |6 ++
 4 files changed, 21 insertions(+), 21 deletions(-)

diff --git a/drivers/kvm/kvm.h b/drivers/kvm/kvm.h
index 476150c..c7fdcd6 100644
--- a/drivers/kvm/kvm.h
+++ b/drivers/kvm/kvm.h
@@ -277,12 +277,6 @@ void kvm_io_bus_register_dev(struct kvm_io_bus
*bus,
struct kvm_vcpu_stat stat;  \
KVM_VCPU_MMIO
 
-struct kvm_mem_alias {
-   gfn_t base_gfn;
-   unsigned long npages;
-   gfn_t target_gfn;
-};
-
 struct kvm_memory_slot {
gfn_t base_gfn;
unsigned long npages;
diff --git a/drivers/kvm/kvm_main.c b/drivers/kvm/kvm_main.c
index 2490e06..33a1354 100644
--- a/drivers/kvm/kvm_main.c
+++ b/drivers/kvm/kvm_main.c
@@ -400,21 +400,6 @@ int kvm_is_error_hva(unsigned long addr)
 }
 EXPORT_SYMBOL_GPL(kvm_is_error_hva);
 
-gfn_t unalias_gfn(struct kvm *kvm, gfn_t gfn)
-{
-   int i;
-   struct kvm_mem_alias *alias;
-   struct kvm_x86 *kvm_x86 = to_kvm_x86(kvm);
-
-   for (i = 0; i < kvm_x86->naliases; ++i) {
-   alias = &kvm_x86->aliases[i];
-   if (gfn >= alias->base_gfn
-   && gfn < alias->base_gfn + alias->npages)
-   return alias->target_gfn + gfn -
alias->base_gfn;
-   }
-   return gfn;
-}
-
 static struct kvm_memory_slot *__gfn_to_memslot(struct kvm *kvm, gfn_t
gfn)
 {
int i;
diff --git a/drivers/kvm/x86.c b/drivers/kvm/x86.c
index 15b43f5..13db394 100644
--- a/drivers/kvm/x86.c
+++ b/drivers/kvm/x86.c
@@ -833,6 +833,21 @@ static int kvm_vm_ioctl_get_nr_mmu_pages(struct kvm
*kvm)
return kvm->n_alloc_mmu_pages;
 }
 
+gfn_t unalias_gfn(struct kvm *kvm, gfn_t gfn)
+{
+   int i;
+   struct kvm_mem_alias *alias;
+   struct kvm_x86 *kvm_x86 = to_kvm_x86(kvm);
+
+   for (i = 0; i < kvm_x86->naliases; ++i) {
+   alias = &kvm_x86->aliases[i];
+   if (gfn >= alias->base_gfn
+   && gfn < alias->base_gfn + alias->npages)
+   return alias->target_gfn + gfn -
alias->base_gfn;
+   }
+   return gfn;
+}
+
 /*
  * Set a new alias region.  Aliases map a portion of physical memory
into
  * another portion.  This is useful for memory windows, for example the
PC
diff --git a/drivers/kvm/x86.h b/drivers/kvm/x86.h
index e5db023..f792bb9 100644
--- a/drivers/kvm/x86.h
+++ b/drivers/kvm/x86.h
@@ -156,6 +156,12 @@ struct kvm_vcpu {
struct x86_emulate_ctxt emulate_ctxt;
 };
 
+struct kvm_mem_alias {
+   gfn_t base_gfn;
+   unsigned long npages;
+   gfn_t target_gfn;
+};
+
 struct kvm_x86 {
struct kvm kvm;
int naliases;
-- 
1.5.1.2


0003-KVM-Portability-Moving-out-kvm_mem_alias-and-unali.patch
Description: 0003-KVM-Portability-Moving-out-kvm_mem_alias-and-unali.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] 8/10 KVM Portability: Moving the filed apic_access_page to kvm_x86.

[Zhang, Xiantao]

>From 50b1594999ba046c3de73e7fccbee44816c5708c Mon Sep 17 00:00:00 2001
From: Zhang Xiantao <[EMAIL PROTECTED]>
Date: Tue, 20 Nov 2007 23:34:14 +0800
Subject: [PATCH] KVM Portability: Splitting kvm structure.
Moving the filed apic_access_page to kvm_x86.
Signed-off-by: Zhang Xiantao <[EMAIL PROTECTED]>
---
 drivers/kvm/kvm.h |1 -
 drivers/kvm/vmx.c |8 +---
 drivers/kvm/x86.h |1 +
 3 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/drivers/kvm/kvm.h b/drivers/kvm/kvm.h
index d8fdd7b..0df84b6 100644
--- a/drivers/kvm/kvm.h
+++ b/drivers/kvm/kvm.h
@@ -224,7 +224,6 @@ struct kvm {
struct kvm_io_bus mmio_bus;
struct kvm_io_bus pio_bus;
int round_robin_prev_vcpu;
-   struct page *apic_access_page;
struct kvm_vm_stat stat;
 };
 
diff --git a/drivers/kvm/vmx.c b/drivers/kvm/vmx.c
index 02593ad..d5df045 100644
--- a/drivers/kvm/vmx.c
+++ b/drivers/kvm/vmx.c
@@ -1470,10 +1470,11 @@ static void seg_setup(int seg)
 static int alloc_apic_access_page(struct kvm *kvm)
 {
struct kvm_userspace_memory_region kvm_userspace_mem;
+   struct kvm_x86 *kvm_x86 = to_kvm_x86(kvm);
int r = 0;
 
mutex_lock(&kvm->lock);
-   if (kvm->apic_access_page)
+   if (kvm_x86->apic_access_page)
goto out;
kvm_userspace_mem.slot = APIC_ACCESS_PAGE_PRIVATE_MEMSLOT;
kvm_userspace_mem.flags = 0;
@@ -1482,7 +1483,7 @@ static int alloc_apic_access_page(struct kvm *kvm)
r = __kvm_set_memory_region(kvm, &kvm_userspace_mem, 0);
if (r)
goto out;
-   kvm->apic_access_page = gfn_to_page(kvm, 0xfee00);
+   kvm_x86->apic_access_page = gfn_to_page(kvm, 0xfee00);
 out:
mutex_unlock(&kvm->lock);
return r;
@@ -1605,6 +1606,7 @@ static int vmx_vcpu_setup(struct vcpu_vmx *vmx)
 static int vmx_vcpu_reset(struct kvm_vcpu *vcpu)
 {
struct vcpu_vmx *vmx = to_vmx(vcpu);
+   struct kvm_x86 *kvm_x86 = to_kvm_x86(vcpu->kvm);
u64 msr;
int ret;
 
@@ -1697,7 +1699,7 @@ static int vmx_vcpu_reset(struct kvm_vcpu *vcpu)
 
if (vm_need_virtualize_apic_accesses(vmx->vcpu.kvm))
vmcs_write64(APIC_ACCESS_ADDR,
-
page_to_phys(vmx->vcpu.kvm->apic_access_page));
+page_to_phys(kvm_x86->apic_access_page));
 
vmx->vcpu.cr0 = 0x6010;
vmx_set_cr0(&vmx->vcpu, vmx->vcpu.cr0); /* enter rmode */
diff --git a/drivers/kvm/x86.h b/drivers/kvm/x86.h
index ebd5ae0..11f7626 100644
--- a/drivers/kvm/x86.h
+++ b/drivers/kvm/x86.h
@@ -260,6 +260,7 @@ struct kvm_x86 {
struct kvm_pic *vpic;
struct kvm_ioapic *vioapic;
unsigned int tss_addr;
+   struct page *apic_access_page;
 };
 
 static inline struct kvm_x86 *to_kvm_x86(struct kvm *kvm)
-- 
1.5.1.2


0008-KVM-Portability-Splitting-kvm-structure.patch
Description: 0008-KVM-Portability-Splitting-kvm-structure.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

Re: [kvm-devel] [PATCH] KVM Portability split: Splitting kvm structure (V2)

[Hollis Blanchard]

NAK. I sent you a patch queue yesterday that replaces this patch.
(Unfortunately I didn't copy kvm-devel due to technical error; resending
in a moment.)

-- 
Hollis Blanchard
IBM Linux Technology Center

On Tue, 2007-11-20 at 10:29 +0800, Zhang, Xiantao wrote:
> 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 = n

[kvm-devel] [PATCH]7/10 KVM Portability:Moving the filed tss_addr to kvm_x86.

[Zhang, Xiantao]

>From e3c2f0fcf9264d03a90a788fe5770ac9b8ce44d9 Mon Sep 17 00:00:00 2001
From: Zhang Xiantao <[EMAIL PROTECTED]>
Date: Tue, 20 Nov 2007 23:31:38 +0800
Subject: [PATCH] KVM Portability: Splitting kvm structure.
Moving the filed tss_addr to kvm_x86.
Signed-off-by: Zhang Xiantao <[EMAIL PROTECTED]>
---
 drivers/kvm/kvm.h |1 -
 drivers/kvm/vmx.c |   10 +++---
 drivers/kvm/x86.h |1 +
 3 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/drivers/kvm/kvm.h b/drivers/kvm/kvm.h
index bcfa555..d8fdd7b 100644
--- a/drivers/kvm/kvm.h
+++ b/drivers/kvm/kvm.h
@@ -224,7 +224,6 @@ struct kvm {
struct kvm_io_bus mmio_bus;
struct kvm_io_bus pio_bus;
int round_robin_prev_vcpu;
-   unsigned int tss_addr;
struct page *apic_access_page;
struct kvm_vm_stat stat;
 };
diff --git a/drivers/kvm/vmx.c b/drivers/kvm/vmx.c
index 4ad60c9..02593ad 100644
--- a/drivers/kvm/vmx.c
+++ b/drivers/kvm/vmx.c
@@ -1141,12 +1141,15 @@ static void enter_pmode(struct kvm_vcpu *vcpu)
 
 static gva_t rmode_tss_base(struct kvm *kvm)
 {
-   if (!kvm->tss_addr) {
+
+   struct kvm_x86 *kvm_x86 = to_kvm_x86(kvm);
+
+   if (!kvm_x86->tss_addr) {
gfn_t base_gfn = kvm->memslots[0].base_gfn +
 kvm->memslots[0].npages - 3;
return base_gfn << PAGE_SHIFT;
}
-   return kvm->tss_addr;
+   return kvm_x86->tss_addr;
 }
 
 static void fix_rmode_seg(int seg, struct kvm_save_segment *save)
@@ -1775,11 +1778,12 @@ static int vmx_set_tss_addr(struct kvm *kvm,
unsigned int addr)
.memory_size = PAGE_SIZE * 3,
.flags = 0,
};
+   struct kvm_x86 *kvm_x86 = to_kvm_x86(kvm);
 
ret = kvm_set_memory_region(kvm, &tss_mem, 0);
if (ret)
return ret;
-   kvm->tss_addr = addr;
+   kvm_x86->tss_addr = addr;
return 0;
 }
 
diff --git a/drivers/kvm/x86.h b/drivers/kvm/x86.h
index d16d9a3..ebd5ae0 100644
--- a/drivers/kvm/x86.h
+++ b/drivers/kvm/x86.h
@@ -259,6 +259,7 @@ struct kvm_x86 {
struct hlist_head mmu_page_hash[KVM_NUM_MMU_PAGES];
struct kvm_pic *vpic;
struct kvm_ioapic *vioapic;
+   unsigned int tss_addr;
 };
 
 static inline struct kvm_x86 *to_kvm_x86(struct kvm *kvm)
-- 
1.5.1.2


0007-KVM-Portability-Splitting-kvm-structure.patch
Description: 0007-KVM-Portability-Splitting-kvm-structure.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] 0/10 Splitting kvm structure (V3)

[Zhang, Xiantao]

Hi Avi,
 I rebased the series of patches for splitting kvm structure.  For
more readability, I split them into small ones. 
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] 4/10 KVM Portability: Moving fileds related to mmu into kvm_x86.

[Zhang, Xiantao]

>From 30e5badef53e8e5edf72ba2dbc6b9f1ccfd2aaa0 Mon Sep 17 00:00:00 2001
From: Zhang Xiantao <[EMAIL PROTECTED]>
Date: Tue, 20 Nov 2007 23:06:06 +0800
Subject: [PATCH] KVM Portability: Spliting kvm structure
Moving fileds related to mmu into kvm_x86.
Signed-off-by: Zhang Xiantao <[EMAIL PROTECTED]>
---
 drivers/kvm/kvm.h |8 -
 drivers/kvm/mmu.c |   74
+
 drivers/kvm/x86.c |   14 +++---
 drivers/kvm/x86.h |   12 -
 4 files changed, 67 insertions(+), 41 deletions(-)

diff --git a/drivers/kvm/kvm.h b/drivers/kvm/kvm.h
index c7fdcd6..1e1d515 100644
--- a/drivers/kvm/kvm.h
+++ b/drivers/kvm/kvm.h
@@ -301,14 +301,6 @@ 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];
struct list_head vm_list;
struct file *filp;
diff --git a/drivers/kvm/mmu.c b/drivers/kvm/mmu.c
index 101cd53..683ad72 100644
--- a/drivers/kvm/mmu.c
+++ b/drivers/kvm/mmu.c
@@ -530,12 +530,14 @@ static int is_empty_shadow_page(u64 *spt)
 static void kvm_mmu_free_page(struct kvm *kvm,
  struct kvm_mmu_page *page_head)
 {
+   struct kvm_x86 *kvm_x86 = to_kvm_x86(kvm);
+
ASSERT(is_empty_shadow_page(page_head->spt));
list_del(&page_head->link);
__free_page(virt_to_page(page_head->spt));
__free_page(virt_to_page(page_head->gfns));
kfree(page_head);
-   ++kvm->n_free_mmu_pages;
+   ++kvm_x86->n_free_mmu_pages;
 }
 
 static unsigned kvm_page_table_hashfn(gfn_t gfn)
@@ -547,8 +549,9 @@ static struct kvm_mmu_page
*kvm_mmu_alloc_page(struct kvm_vcpu *vcpu,
   u64 *parent_pte)
 {
struct kvm_mmu_page *page;
+   struct kvm_x86 *kvm_x86 = to_kvm_x86(vcpu->kvm);
 
-   if (!vcpu->kvm->n_free_mmu_pages)
+   if (!kvm_x86->n_free_mmu_pages)
return NULL;
 
page = mmu_memory_cache_alloc(&vcpu->mmu_page_header_cache,
@@ -556,12 +559,12 @@ static struct kvm_mmu_page
*kvm_mmu_alloc_page(struct kvm_vcpu *vcpu,
page->spt = mmu_memory_cache_alloc(&vcpu->mmu_page_cache,
PAGE_SIZE);
page->gfns = mmu_memory_cache_alloc(&vcpu->mmu_page_cache,
PAGE_SIZE);
set_page_private(virt_to_page(page->spt), (unsigned long)page);
-   list_add(&page->link, &vcpu->kvm->active_mmu_pages);
+   list_add(&page->link, &kvm_x86->active_mmu_pages);
ASSERT(is_empty_shadow_page(page->spt));
page->slot_bitmap = 0;
page->multimapped = 0;
page->parent_pte = parent_pte;
-   --vcpu->kvm->n_free_mmu_pages;
+   --kvm_x86->n_free_mmu_pages;
return page;
 }
 
@@ -647,10 +650,12 @@ static struct kvm_mmu_page
*kvm_mmu_lookup_page(struct kvm *kvm,
struct hlist_head *bucket;
struct kvm_mmu_page *page;
struct hlist_node *node;
+   struct kvm_x86 *kvm_x86 = to_kvm_x86(kvm);
+
 
pgprintk("%s: looking for gfn %lx\n", __FUNCTION__, gfn);
index = kvm_page_table_hashfn(gfn) % KVM_NUM_MMU_PAGES;
-   bucket = &kvm->mmu_page_hash[index];
+   bucket = &kvm_x86->mmu_page_hash[index];
hlist_for_each_entry(page, node, bucket, hash_link)
if (page->gfn == gfn && !page->role.metaphysical) {
pgprintk("%s: found role %x\n",
@@ -674,6 +679,8 @@ static struct kvm_mmu_page *kvm_mmu_get_page(struct
kvm_vcpu *vcpu,
struct hlist_head *bucket;
struct kvm_mmu_page *page;
struct hlist_node *node;
+   struct kvm_x86 *kvm_x86 = to_kvm_x86(vcpu->kvm);
+
 
role.word = 0;
role.glevels = vcpu->mmu.root_level;
@@ -688,7 +695,7 @@ static struct kvm_mmu_page *kvm_mmu_get_page(struct
kvm_vcpu *vcpu,
pgprintk("%s: looking gfn %lx role %x\n", __FUNCTION__,
 gfn, role.word);
index = kvm_page_table_hashfn(gfn) % KVM_NUM_MMU_PAGES;
-   bucket = &vcpu->kvm->mmu_page_hash[index];
+   bucket = &kvm_x86->mmu_page_hash[index];
hlist_for_each_entry(page, node, bucket, hash_link)
if (page->gfn == gfn && page->role.word == role.word) {
mmu_page_add_parent_pte(vcpu, page, parent_pte);
@@ -758,6 +765,7 @@ static void kvm_mmu_zap_page(struct kvm *kvm,
 struct kvm_mmu_page *page)
 {
u64 *parent_pte;
+   struct kvm_x86 *kvm_x86 = to_kvm_x86(kvm);
 
++kvm->stat.mmu_shadow_zapped;
while (page->multimapped || page->parent_pte) {
@@ -779,7 +787,7 @@ static void kvm_mmu_zap_page(struct kvm *kvm,
hlist_del(

[kvm-devel] [PATCH 2 of 3] Move vm_stat and apic_access_page to kvm_x86

[Hollis Blanchard]

Signed-off-by: Hollis Blanchard <[EMAIL PROTECTED]>

---
5 files changed, 18 insertions(+), 13 deletions(-)
drivers/kvm/kvm.h |2 --
drivers/kvm/mmu.c |   14 --
drivers/kvm/vmx.c |   11 +++
drivers/kvm/x86.c |2 +-
drivers/kvm/x86.h |2 ++


diff --git a/drivers/kvm/kvm.h b/drivers/kvm/kvm.h
--- a/drivers/kvm/kvm.h
+++ b/drivers/kvm/kvm.h
@@ -315,8 +315,6 @@ struct kvm {
struct kvm_io_bus mmio_bus;
struct kvm_io_bus pio_bus;
int round_robin_prev_vcpu;
-   struct page *apic_access_page;
-   struct kvm_vm_stat stat;
 };
 
 struct descriptor_table {
diff --git a/drivers/kvm/mmu.c b/drivers/kvm/mmu.c
--- a/drivers/kvm/mmu.c
+++ b/drivers/kvm/mmu.c
@@ -761,7 +761,7 @@ static void kvm_mmu_zap_page(struct kvm 
u64 *parent_pte;
struct kvm_x86 *kvm_x86 = to_kvm_x86(kvm);
 
-   ++kvm->stat.mmu_shadow_zapped;
+   ++kvm_x86->stat.mmu_shadow_zapped;
while (page->multimapped || page->parent_pte) {
if (!page->multimapped)
parent_pte = page->parent_pte;
@@ -1236,12 +1236,14 @@ static void mmu_pte_write_new_pte(struct
  const void *new, int bytes,
  int offset_in_pte)
 {
+   struct kvm_x86 *kvm_x86 = to_kvm_x86(vcpu->kvm);
+
if (page->role.level != PT_PAGE_TABLE_LEVEL) {
-   ++vcpu->kvm->stat.mmu_pde_zapped;
+   ++kvm_x86->stat.mmu_pde_zapped;
return;
}
 
-   ++vcpu->kvm->stat.mmu_pte_updated;
+   ++kvm_x86->stat.mmu_pte_updated;
if (page->role.glevels == PT32_ROOT_LEVEL)
paging32_update_pte(vcpu, page, spte, new, bytes,
offset_in_pte);
@@ -1277,7 +1279,7 @@ void kvm_mmu_pte_write(struct kvm_vcpu *
int npte;
 
pgprintk("%s: gpa %llx bytes %d\n", __FUNCTION__, gpa, bytes);
-   ++vcpu->kvm->stat.mmu_pte_write;
+   ++kvm_x86->stat.mmu_pte_write;
kvm_mmu_audit(vcpu, "pre pte write");
if (gfn == vcpu->last_pt_write_gfn
&& !last_updated_pte_accessed(vcpu)) {
@@ -1311,7 +1313,7 @@ void kvm_mmu_pte_write(struct kvm_vcpu *
pgprintk("misaligned: gpa %llx bytes %d role %x\n",
 gpa, bytes, page->role.word);
kvm_mmu_zap_page(vcpu->kvm, page);
-   ++vcpu->kvm->stat.mmu_flooded;
+   ++kvm_x86->stat.mmu_flooded;
continue;
}
page_offset = offset;
@@ -1362,7 +1364,7 @@ void __kvm_mmu_free_some_pages(struct kv
page = container_of(kvm_x86->active_mmu_pages.prev,
struct kvm_mmu_page, link);
kvm_mmu_zap_page(vcpu->kvm, page);
-   ++vcpu->kvm->stat.mmu_recycled;
+   ++kvm_x86->stat.mmu_recycled;
}
 }
 
diff --git a/drivers/kvm/vmx.c b/drivers/kvm/vmx.c
--- a/drivers/kvm/vmx.c
+++ b/drivers/kvm/vmx.c
@@ -1468,11 +1468,12 @@ static void seg_setup(int seg)
 
 static int alloc_apic_access_page(struct kvm *kvm)
 {
+   struct kvm_x86 *kvm_x86 = to_kvm_x86(kvm);
struct kvm_userspace_memory_region kvm_userspace_mem;
int r = 0;
 
mutex_lock(&kvm->lock);
-   if (kvm->apic_access_page)
+   if (kvm_x86->apic_access_page)
goto out;
kvm_userspace_mem.slot = APIC_ACCESS_PAGE_PRIVATE_MEMSLOT;
kvm_userspace_mem.flags = 0;
@@ -1481,7 +1482,7 @@ static int alloc_apic_access_page(struct
r = __kvm_set_memory_region(kvm, &kvm_userspace_mem, 0);
if (r)
goto out;
-   kvm->apic_access_page = gfn_to_page(kvm, 0xfee00);
+   kvm_x86->apic_access_page = gfn_to_page(kvm, 0xfee00);
 out:
mutex_unlock(&kvm->lock);
return r;
@@ -1694,9 +1695,11 @@ static int vmx_vcpu_reset(struct kvm_vcp
vmcs_write32(TPR_THRESHOLD, 0);
}
 
-   if (vm_need_virtualize_apic_accesses(vmx->vcpu.kvm))
+   if (vm_need_virtualize_apic_accesses(vmx->vcpu.kvm)) {
+   struct kvm_x86 *kvm_x86 = to_kvm_x86(vmx->vcpu.kvm);
vmcs_write64(APIC_ACCESS_ADDR,
-page_to_phys(vmx->vcpu.kvm->apic_access_page));
+page_to_phys(kvm_x86->apic_access_page));
+   }
 
vmx->vcpu.cr0 = 0x6010;
vmx_set_cr0(&vmx->vcpu, vmx->vcpu.cr0); /* enter rmode */
diff --git a/drivers/kvm/x86.c b/drivers/kvm/x86.c
--- a/drivers/kvm/x86.c
+++ b/drivers/kvm/x86.c
@@ -42,7 +42,7 @@
 #define CR8_RESERVED_BITS (~(unsigned long)X86_CR8_TPR)
 #define EFER_RESERVED_BITS 0xf2fe
 
-#define VM_STAT(x) offsetof(struct kvm, stat.x), KVM_STAT_VM
+#define VM_STAT(x) offsetof(struct kvm_x86, stat.x), KVM_STAT_VM
 #define VCPU_STAT(x) offsetof(struct kvm_vcpu, stat.x), KVM_STAT_VCPU
 
 struct kvm_x86_ops *kvm_x86_ops;
diff --git a/drivers/kvm/x86

[kvm-devel] [PATCH 0 of 3] create kvm_x86

[Hollis Blanchard]

These patches are based on Xiantao's work to create struct kvm_x86. Patch 1 
replaces his "KVM Portability split: Splitting kvm structure (V2)", and patches 
2 and 3 build on it.

9 files changed, 180 insertions(+), 116 deletions(-)
drivers/kvm/i8259.c|1 
drivers/kvm/ioapic.c   |   16 ---
drivers/kvm/irq.h  |3 -
drivers/kvm/kvm.h  |   30 --
drivers/kvm/kvm_main.c |   13 ++
drivers/kvm/mmu.c  |   99 
drivers/kvm/vmx.c  |   20 ++---
drivers/kvm/x86.c  |   67 ++--
drivers/kvm/x86.h  |   47 ++

-
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] Use kvm_x86 to hold x86 specific kvm fields

[Hollis Blanchard]

Signed-off-by: Zhang xiantao <[EMAIL PROTECTED]>
Signed-off-by: Hollis Blanchard <[EMAIL PROTECTED]>
---
Changes from Xiantao's patch:
- Fix whitespace
- Reorder variables to avoid stack padding
- Leave descriptor_table relocation for another patch

8 files changed, 132 insertions(+), 85 deletions(-)
drivers/kvm/ioapic.c   |7 ++-
drivers/kvm/irq.h  |1 
drivers/kvm/kvm.h  |   26 --
drivers/kvm/kvm_main.c |9 ++---
drivers/kvm/mmu.c  |   85 
drivers/kvm/vmx.c  |9 +++--
drivers/kvm/x86.c  |   37 
drivers/kvm/x86.h  |   43 +++-


diff --git a/drivers/kvm/ioapic.c b/drivers/kvm/ioapic.c
--- a/drivers/kvm/ioapic.c
+++ b/drivers/kvm/ioapic.c
@@ -276,7 +276,9 @@ static int get_eoi_gsi(struct kvm_ioapic
 
 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 @@ int kvm_ioapic_init(struct kvm *kvm)
 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
--- 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
--- a/drivers/kvm/kvm.h
+++ b/drivers/kvm/kvm.h
@@ -309,41 +309,15 @@ 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];
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;
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
@@ -232,6 +232,7 @@ int __kvm_set_memory_region(struct kvm *
unsigned long i;
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 */
@@ -332,18 +333,18 @@ int __kvm_set_memory_region(struct 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 +
-n_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->n_alloc_mmu_pages - n_pages;
+   nr_mmu_pages = kvm_x86->n_alloc_mmu_pages - n_pages;
nr_mmu_pages = max(nr_mmu_pages,
(unsigned int) KVM_MIN_ALLOC_MMU_PAGES);
kvm_mmu_change_mmu_pages(kvm, nr_mmu_pages);
diff --git a/drivers/kvm/mmu.c b/drivers/kvm/mmu.c
--- a/drivers/kvm/mmu.c
+++ b/drivers/kvm/mmu.c
@@ -526,12 +526,14 @@ static void kvm_mmu_free_page(struct kvm
 static void kvm_mmu_free_page(struct kvm *kvm,
  struct kvm_mmu_page *page_h

Re: [kvm-devel] [PATCH] 0/10 Splitting kvm structure (V3)

[Hollis Blanchard]

On Wed, 2007-11-21 at 00:32 +0800, Zhang, Xiantao wrote:
> Hi Avi,
>  I rebased the series of patches for splitting kvm structure.  For
> more readability, I split them into small ones. 

You still seem to be ignoring my comments on these patches. I spent some
time to respin your original patch, and now you've broken it into 10,
still lacking those changes. At least part of this is based on the
latency of Sourceforge mailing lists, but it's becoming frustrating.

Also, you are still sending very whitespace-mangled emails. I see that
you are also sending patches as attachments, but I really wish you could
figure out a way to solve this problem. If you use a standard mailing
script, the mails will also be threaded correctly for ease of reading.

-- 
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] Export the symbol empty_zero_page on the 32-bit x86 architecture

[Theodore Ts'o]

The latest KVM driver wants to use the empty_zero_page symbol, and it's
not exported in 32-bit x86 (although it is exported by x86_64, s390, and
uml architectures).

Signed-off-by: "Theodore Ts'o" <[EMAIL PROTECTED]>
---
 arch/x86/kernel/i386_ksyms_32.c |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/arch/x86/kernel/i386_ksyms_32.c b/arch/x86/kernel/i386_ksyms_32.c
index edd39cc..02112fc 100644
--- a/arch/x86/kernel/i386_ksyms_32.c
+++ b/arch/x86/kernel/i386_ksyms_32.c
@@ -2,6 +2,7 @@
 #include 
 #include 
 #include 
+#include 
 
 EXPORT_SYMBOL(__down_failed);
 EXPORT_SYMBOL(__down_failed_interruptible);
@@ -29,3 +30,4 @@ EXPORT_SYMBOL(__read_lock_failed);
 #endif
 
 EXPORT_SYMBOL(csum_partial);
+EXPORT_SYMBOL(empty_zero_page);
-- 
1.5.3.5.629.g4ff4-dirty


-
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] success running XPSP2(g32 on h64) with kvm-53-11-gcc02b6a, was BSOD-land before

[Cyrille Chépélov]

Hi all,

I would like to report that using the following setup:
git kvm-userspace: kvm-53, kvm: kvm-53-11-gcc02b6a
on my 4400+ (Athlon64-X2)  debian amd64 box, and contrary to kvm-52, I
can now successfully run Windows XP SP2 (32-bit) guests!

Previously, the guests hardly ever survived 3 minutes before popping
into a blue screen or another (various failure modes, all pointing to
memory issues). I suspect that Sheng Yang's
8cdbd1f3f0b5d9599fd834de2000d2286ee05931 or something else around CR2
was involved in the correction.

Anyway, congratulations & big thanks to everyone involved in what made
kvm-53-11-gcc02b6a what it is!

-- Cyrille






-
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_SET_MEMORY_REGION hang in linux 2.6.23.y

[Marko Kohtala]

Wait for right amount of tlb flushes. Completed can be larger than
needed and therefore the loop waiting them to match never ends.

Signed-off-by: Marko Kohtala <[EMAIL PROTECTED]>

---

This solves kernel lockup in KVM_SET_MEMORY_REGION ioctl with Linux
2.6.23.8 and before at kvm-52 start. Not needed in 2.6.24.

diff --git a/drivers/kvm/kvm_main.c b/drivers/kvm/kvm_main.c
index cd05579..b148aff 100644
--- a/drivers/kvm/kvm_main.c
+++ b/drivers/kvm/kvm_main.c
@@ -279,7 +279,8 @@ void kvm_flush_remote_tlbs(struct kvm *kvm)
 * to complete.
 */
for (cpu = first_cpu(cpus); cpu != NR_CPUS; cpu = next_cpu(cpu, cpus))
-   smp_call_function_single(cpu, ack_flush, &completed, 1, 0);
+   if (cpu_isset(cpu, cpus))
+   smp_call_function_single(cpu, ack_flush, &completed, 1, 
0);
while (atomic_read(&completed) != needed) {
cpu_relax();
barrier();

-
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 3/3] virtio PCI device

[Anthony Liguori]

Avi Kivity wrote:
> Anthony Liguori wrote:
>> Avi Kivity wrote:
>>  
>>> Anthony Liguori wrote:
>>>
 This is a PCI device that implements a transport for virtio.  It 
 allows virtio
 devices to be used by QEMU based VMMs like KVM or Xen.

 +
 +/* the notify function used when creating a virt queue */
 +static void vp_notify(struct virtqueue *vq)
 +{
 +struct virtio_pci_device *vp_dev = to_vp_device(vq->vdev);
 +struct virtio_pci_vq_info *info = vq->priv;
 +
 +/* we write the queue's selector into the notification 
 register to
 + * signal the other end */
 +iowrite16(info->queue_index, vp_dev->ioaddr + 
 VIRTIO_PCI_QUEUE_NOTIFY);
 +}
 
>>> This means we can't kick multiple queues with one exit.
>>> 
>>
>> There is no interface in virtio currently to batch multiple queue 
>> notifications so the only way one could do this AFAICT is to use a 
>> timer to delay the notifications.  Were you thinking of something else?
>>
>>   
>
> No.  We can change virtio though, so let's have a flexible ABI.

Well please propose the virtio API first and then I'll adjust the PCI 
ABI.  I don't want to build things into the ABI that we never actually 
end up using in virtio :-)

>>> I'd also like to see a hypercall-capable version of this (but that 
>>> can wait).
>>> 
>>
>> That can be a different device.
>>   
>
> That means the user has to select which device to expose.  With 
> feature bits, the hypervisor advertises both pio and hypercalls, the 
> guest picks whatever it wants.

I was thinking more along the lines that a hypercall-based device would 
certainly be implemented in-kernel whereas the current device is 
naturally implemented in userspace.  We can simply use a different 
device for in-kernel drivers than for userspace drivers.  There's no 
point at all in doing a hypercall based userspace device IMHO.

>> I don't think so.  A vmexit is required to lower the IRQ line.  It 
>> may be possible to do something clever like set a shared memory value 
>> that's checked on every vmexit.  I think it's very unlikely that it's 
>> worth it though.
>>   
>
> Why so unlikely?  Not all workloads will have good batching.

It's pretty invasive.  I think a more paravirt device that expected an 
edge triggered interrupt would be a better solution for those types of 
devices.
 
 +return ret;
 +}
 +
 +/* the config->find_vq() implementation */
 +static struct virtqueue *vp_find_vq(struct virtio_device *vdev, 
 unsigned index,
 +bool (*callback)(struct virtqueue *vq))
 +{
 +struct virtio_pci_device *vp_dev = to_vp_device(vdev);
 +struct virtio_pci_vq_info *info;
 +struct virtqueue *vq;
 +int err;
 +u16 num;
 +
 +/* Select the queue we're interested in */
 +iowrite16(index, vp_dev->ioaddr + VIRTIO_PCI_QUEUE_SEL);
 
>>> I would really like to see this implemented as pci config space, 
>>> with no tricks like multiplexing several virtqueues on one register. 
>>> Something like the PCI BARs where you have all the register numbers 
>>> allocated statically to queues.
>>> 
>>
>> My first implementation did that.  I switched to using a selector 
>> because it reduces the amount of PCI config space used and does not 
>> limit the number of queues defined by the ABI as much.
>>   
>
> But... it's tricky, and it's nonstandard.  With pci config, you can do 
> live migration by shipping the pci config space to the other side.  
> With the special iospace, you need to encode/decode it.

None of the PCI devices currently work like that in QEMU.  It would be 
very hard to make a device that worked this way because since the order 
in which values are written matter a whole lot.  For instance, if you 
wrote the status register before the queue information, the driver could 
get into a funky state.

We'll still need save/restore routines for virtio devices.  I don't 
really see this as a problem since we do this for every other device.

> Not much of an argument, I know.
>
>
> wrt. number of queues, 8 queues will consume 32 bytes of pci space if 
> all you store is the ring pfn.

You also at least need a num argument which takes you to 48 or 64 
depending on whether you care about strange formatting.  8 queues may 
not be enough either.  Eric and I have discussed whether the 9p virtio 
device should support multiple mounts per-virtio device and if so, 
whether each one should have it's own queue.  Any devices that supports 
this sort of multiplexing will very quickly start using a lot of queues.

I think most types of hardware have some notion of a selector or mode.  
Take a look at the LSI adapter or even VGA.

Regards,

Anthony Liguori


-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.

Re: [kvm-devel] [PATCH] KVM Portability split: Splitting kvm structure (V2)

[Zhang, Xiantao]

Hollis Blanchard wrote:
> NAK. I sent you a patch queue yesterday that replaces this patch.
> (Unfortunately I didn't copy kvm-devel due to technical error;
> resending in a moment.)

Hi Hollis,
Unfortunately, I didn't receive this mail  you mentioned :(.
Does it have new changes except moving the filed stat to kvm_x86?  I
have included them in V3.
BTW, I used git-send-emailt to deliver these mails, seems it still can't
work with you.  I will check my mail format again. Thank you:)
Xiantao

> On Tue, 2007-11-20 at 10:29 +0800, Zhang, Xiantao wrote:
>> 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_mem

[kvm-devel] Does KVM bios support DMI ?

[walter tech]

Hi, guys,

My Thinkpad T60 came with an authentic windows xp,  but the version is
for IBM/lenovo only, the Windows XP need to read bios DMI to match the
vendor name and manufacture Name to be activated. I dont want to buy
another M$ window xp for KVM, just what to change the bios info to
meet the check, is it possible?

Thanks, Rgds
Walter

-
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] KVM Test result, kernel 90af65.. , userspace ad220a.

[Izik Eidus]

Zhao, Yunfeng wrote:
>
> 4. Cannot boot 32bit smp RHEL5.1 guest with nic enabled
>
> Only "-on-kvm" can boot it.
>
> https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1812043&group_id=180599
>  
> 
>
what you mean with nic enabled?
without nic it work?

-
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] Does KVM bios support DMI ?

[Avi Kivity]

walter tech wrote:
> Hi, guys,
>
> My Thinkpad T60 came with an authentic windows xp,  but the version is
> for IBM/lenovo only, the Windows XP need to read bios DMI to match the
> vendor name and manufacture Name to be activated. I dont want to buy
> another M$ window xp for KVM, just what to change the bios info to
> meet the check, is it possible?
>   

Currently, no. But we need DMI support in the BIOS anyway (so 32-bit 
Linux guests can use ACPI), so watch this space.  I expect support to be 
added soon.

-- 
Any sufficiently difficult bug is indistinguishable from a feature.


-
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] KVM_SET_MEMORY_REGION hang in linux 2.6.23.y

[Avi Kivity]

Marko Kohtala wrote:
> Wait for right amount of tlb flushes. Completed can be larger than
> needed and therefore the loop waiting them to match never ends.
>
> Signed-off-by: Marko Kohtala <[EMAIL PROTECTED]>
>
> ---
>
> This solves kernel lockup in KVM_SET_MEMORY_REGION ioctl with Linux
> 2.6.23.8 and before at kvm-52 start. Not needed in 2.6.24.
>
> diff --git a/drivers/kvm/kvm_main.c b/drivers/kvm/kvm_main.c
> index cd05579..b148aff 100644
> --- a/drivers/kvm/kvm_main.c
> +++ b/drivers/kvm/kvm_main.c
> @@ -279,7 +279,8 @@ void kvm_flush_remote_tlbs(struct kvm *kvm)
>* to complete.
>*/
>   for (cpu = first_cpu(cpus); cpu != NR_CPUS; cpu = next_cpu(cpu, cpus))
> - smp_call_function_single(cpu, ack_flush, &completed, 1, 0);
> + if (cpu_isset(cpu, cpus))
> + smp_call_function_single(cpu, ack_flush, &completed, 1, 
> 0);
>   

Can you explain how this makes a difference?  Aren't first_cpu() and 
next_cpu() designed to iterate over all cpus which have cpu_isset(cpus)?

-- 
Any sufficiently difficult bug is indistinguishable from a feature.


-
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 3/3] virtio PCI device

[Avi Kivity]

Anthony Liguori wrote:
> Avi Kivity wrote:
>   
>> Anthony Liguori wrote:
>> 
>>> Avi Kivity wrote:
>>>  
>>>   
 Anthony Liguori wrote:

 
> This is a PCI device that implements a transport for virtio.  It 
> allows virtio
> devices to be used by QEMU based VMMs like KVM or Xen.
>
> +
> +/* the notify function used when creating a virt queue */
> +static void vp_notify(struct virtqueue *vq)
> +{
> +struct virtio_pci_device *vp_dev = to_vp_device(vq->vdev);
> +struct virtio_pci_vq_info *info = vq->priv;
> +
> +/* we write the queue's selector into the notification 
> register to
> + * signal the other end */
> +iowrite16(info->queue_index, vp_dev->ioaddr + 
> VIRTIO_PCI_QUEUE_NOTIFY);
> +}
> 
>   
 This means we can't kick multiple queues with one exit.
 
 
>>> There is no interface in virtio currently to batch multiple queue 
>>> notifications so the only way one could do this AFAICT is to use a 
>>> timer to delay the notifications.  Were you thinking of something else?
>>>
>>>   
>>>   
>> No.  We can change virtio though, so let's have a flexible ABI.
>> 
>
> Well please propose the virtio API first and then I'll adjust the PCI 
> ABI.  I don't want to build things into the ABI that we never actually 
> end up using in virtio :-)
>
>   

Move ->kick() to virtio_driver.

I believe Xen networking uses the same event channel for both rx and tx, 
so in effect they're using this model.  Long time since I looked though,

 I'd also like to see a hypercall-capable version of this (but that 
 can wait).
 
 
>>> That can be a different device.
>>>   
>>>   
>> That means the user has to select which device to expose.  With 
>> feature bits, the hypervisor advertises both pio and hypercalls, the 
>> guest picks whatever it wants.
>> 
>
> I was thinking more along the lines that a hypercall-based device would 
> certainly be implemented in-kernel whereas the current device is 
> naturally implemented in userspace.  We can simply use a different 
> device for in-kernel drivers than for userspace drivers.  

Where the device is implemented is an implementation detail that should 
be hidden from the guest, isn't that one of the strengths of 
virtualization?  Two examples: a file-based block device implemented in 
qemu gives you fancy file formats with encryption and compression, while 
the same device implemented in the kernel gives you a low-overhead path 
directly to a zillion-disk SAN volume.  Or a user-level network device 
capable of running with the slirp stack and no permissions vs. the 
kernel device running copyless most of the time and using a dma engine 
for the rest but requiring you to be good friends with the admin.

The user should expect zero reconfigurations moving a VM from one model 
to the other.

> There's no 
> point at all in doing a hypercall based userspace device IMHO.
>   

We abstract this away by having a "channel signalled" API (both at the 
kernel for kernel devices and as a kvm.h exit reason / libkvm callback.

Again, somewhat like Xen's event channels, though asymmetric.

>>> I don't think so.  A vmexit is required to lower the IRQ line.  It 
>>> may be possible to do something clever like set a shared memory value 
>>> that's checked on every vmexit.  I think it's very unlikely that it's 
>>> worth it though.
>>>   
>>>   
>> Why so unlikely?  Not all workloads will have good batching.
>> 
>
> It's pretty invasive.  I think a more paravirt device that expected an 
> edge triggered interrupt would be a better solution for those types of 
> devices.
>   

I was thinking it could be useful mostly in the context of a paravirt 
irqchip, where we can lower the cost of level-triggered interrupts.

> +
> +/* Select the queue we're interested in */
> +iowrite16(index, vp_dev->ioaddr + VIRTIO_PCI_QUEUE_SEL);
> 
>   
 I would really like to see this implemented as pci config space, 
 with no tricks like multiplexing several virtqueues on one register. 
 Something like the PCI BARs where you have all the register numbers 
 allocated statically to queues.
 
 
>>> My first implementation did that.  I switched to using a selector 
>>> because it reduces the amount of PCI config space used and does not 
>>> limit the number of queues defined by the ABI as much.
>>>   
>>>   
>> But... it's tricky, and it's nonstandard.  With pci config, you can do 
>> live migration by shipping the pci config space to the other side.  
>> With the special iospace, you need to encode/decode it.
>> 
>
> None of the PCI devices currently work like that in QEMU.  It would be 
> very hard to make a device that worked this way because since the order 
> in which values are written matter a whole lot.  For instance, if y

[kvm-devel] [PATCH] qemu: add definition for kvm_qemu_check_extension to qemu-kvm.h

[Carlo Marcelo Arenas Belon]

The following patch complement c79baa60813812e8d0e34d998d609e8 to avoid the
implicit declaration of kvm_qemu_check_extension as shown by :

  kvm-53/qemu/vl.c: In function `main':
  kvm-53/qemu/vl.c:8675: warning implicit  declaration of function 
`kvm_qemu_check_extension'
  kvm-53/qemu/hw/pc.c:727: warning: implicit declaration of function 
`kvm_qemu_check_extension'

Signed-off-by: Carlo Marcelo Arenas Belon <[EMAIL PROTECTED]>
---
 qemu/qemu-kvm.h |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/qemu/qemu-kvm.h b/qemu/qemu-kvm.h
index 6fdfc03..57f70ec 100644
--- a/qemu/qemu-kvm.h
+++ b/qemu/qemu-kvm.h
@@ -14,6 +14,7 @@ void kvm_save_registers(CPUState *env);
 int kvm_cpu_exec(CPUState *env);
 int kvm_update_debugger(CPUState *env);
 int kvm_qemu_init_env(CPUState *env);
+int kvm_qemu_check_extension(int ext);
 void kvm_apic_init(CPUState *env);
 
 int kvm_physical_memory_set_dirty_tracking(int enable);
-- 
1.5.2.5


-
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: VMX: Remove the secondary execute control depends on irqchip

[Sheng Yang]

From 140114fbd60afaf08fde429d05c280d88205051b Mon Sep 17 00:00:00 2001
From: Sheng Yang <[EMAIL PROTECTED]>
Date: Wed, 21 Nov 2007 14:33:25 +0800
Subject: [PATCH] KVM: VMX: Remove the secondary execute control depends on 
irqchip

The state of SECONDARY_VM_EXEC_CONTROL shouldn't depend on in-kernel IRQ chip,
this patch fix this.

Signed-off-by: Sheng Yang <[EMAIL PROTECTED]>
---
 drivers/kvm/vmx.c |   17 +++--
 1 files changed, 7 insertions(+), 10 deletions(-)

diff --git a/drivers/kvm/vmx.c b/drivers/kvm/vmx.c
index 4ad60c9..aad31ec 100644
--- a/drivers/kvm/vmx.c
+++ b/drivers/kvm/vmx.c
@@ -186,11 +186,6 @@ static inline int cpu_has_secondary_exec_ctrls(void)
CPU_BASED_ACTIVATE_SECONDARY_CONTROLS);
 }
 
-static inline int vm_need_secondary_exec_ctrls(struct kvm *kvm)
-{
-   return ((cpu_has_secondary_exec_ctrls()) && (irqchip_in_kernel(kvm)));
-}
-
 static inline int cpu_has_vmx_virtualize_apic_accesses(void)
 {
return (vmcs_config.cpu_based_2nd_exec_ctrl &
@@ -1516,13 +1511,15 @@ static int vmx_vcpu_setup(struct vcpu_vmx *vmx)
CPU_BASED_CR8_LOAD_EXITING;
 #endif
}
-   if (!vm_need_secondary_exec_ctrls(vmx->vcpu.kvm))
-   exec_control &= ~CPU_BASED_ACTIVATE_SECONDARY_CONTROLS;
vmcs_write32(CPU_BASED_VM_EXEC_CONTROL, exec_control);
 
-   if (vm_need_secondary_exec_ctrls(vmx->vcpu.kvm))
-   vmcs_write32(SECONDARY_VM_EXEC_CONTROL,
-vmcs_config.cpu_based_2nd_exec_ctrl);
+   if (cpu_has_secondary_exec_ctrls()) {
+   exec_control = vmcs_config.cpu_based_2nd_exec_ctrl;
+   if (!vm_need_virtualize_apic_accesses(vmx->vcpu.kvm))
+   exec_control &=
+   ~SECONDARY_EXEC_VIRTUALIZE_APIC_ACCESSES;
+   vmcs_write32(SECONDARY_VM_EXEC_CONTROL, exec_control);
+   }
 
vmcs_write32(PAGE_FAULT_ERROR_CODE_MASK, !!bypass_guest_pf);
vmcs_write32(PAGE_FAULT_ERROR_CODE_MATCH, !!bypass_guest_pf);
-- 
1.5.3.4

From 140114fbd60afaf08fde429d05c280d88205051b Mon Sep 17 00:00:00 2001
From: Sheng Yang <[EMAIL PROTECTED]>
Date: Wed, 21 Nov 2007 14:33:25 +0800
Subject: [PATCH] KVM: VMX: Remove the secondary execute control depends on irqchip

The state of SECONDARY_VM_EXEC_CONTROL shouldn't depend on in-kernel IRQ chip,
this patch fix this.

Signed-off-by: Sheng Yang <[EMAIL PROTECTED]>
---
 drivers/kvm/vmx.c |   17 +++--
 1 files changed, 7 insertions(+), 10 deletions(-)

diff --git a/drivers/kvm/vmx.c b/drivers/kvm/vmx.c
index 4ad60c9..aad31ec 100644
--- a/drivers/kvm/vmx.c
+++ b/drivers/kvm/vmx.c
@@ -186,11 +186,6 @@ static inline int cpu_has_secondary_exec_ctrls(void)
 		CPU_BASED_ACTIVATE_SECONDARY_CONTROLS);
 }
 
-static inline int vm_need_secondary_exec_ctrls(struct kvm *kvm)
-{
-	return ((cpu_has_secondary_exec_ctrls()) && (irqchip_in_kernel(kvm)));
-}
-
 static inline int cpu_has_vmx_virtualize_apic_accesses(void)
 {
 	return (vmcs_config.cpu_based_2nd_exec_ctrl &
@@ -1516,13 +1511,15 @@ static int vmx_vcpu_setup(struct vcpu_vmx *vmx)
 CPU_BASED_CR8_LOAD_EXITING;
 #endif
 	}
-	if (!vm_need_secondary_exec_ctrls(vmx->vcpu.kvm))
-		exec_control &= ~CPU_BASED_ACTIVATE_SECONDARY_CONTROLS;
 	vmcs_write32(CPU_BASED_VM_EXEC_CONTROL, exec_control);
 
-	if (vm_need_secondary_exec_ctrls(vmx->vcpu.kvm))
-		vmcs_write32(SECONDARY_VM_EXEC_CONTROL,
-			 vmcs_config.cpu_based_2nd_exec_ctrl);
+	if (cpu_has_secondary_exec_ctrls()) {
+		exec_control = vmcs_config.cpu_based_2nd_exec_ctrl;
+		if (!vm_need_virtualize_apic_accesses(vmx->vcpu.kvm))
+			exec_control &=
+~SECONDARY_EXEC_VIRTUALIZE_APIC_ACCESSES;
+		vmcs_write32(SECONDARY_VM_EXEC_CONTROL, exec_control);
+	}
 
 	vmcs_write32(PAGE_FAULT_ERROR_CODE_MASK, !!bypass_guest_pf);
 	vmcs_write32(PAGE_FAULT_ERROR_CODE_MATCH, !!bypass_guest_pf);
-- 
1.5.3.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