Re: [kvm-devel] [kvm-ppc-devel] [PATCH] Split kvm_vcpu to support new archs.
Hollis Blanchard wrote:
> I must be misunderstanding, because this seems completely backwards to
> me. With your nesting, any time architecture code wants to access
> architecture state (which is almost all the time), you'd *need*
> container_of:
>
> void arch_func(struct kvm_vcpu *vcpu) {
> struct arch_vcpu *arch = container_of(vcpu, arch_vcpu,
> arch);
> arch->gpr[3] = 0;
> }
>
> In contrast, my nesting proposal would look like this:
>
> void arch_func(struct kvm_vcpu *vcpu) {
> vcpu->arch.gpr[3] = 0;
> }
>
I'm with Hollis on this one. It looks clearly preferable to me.
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] severe bug in 2.6.23+ kvm.git
Mike Lampard wrote: > There was a commit ab9c232286c2b77be78441c2d8396500b045777e regarding libata > on linus's master tree that happened on Friday, that was pulled into kvm git > over the weekend.. I dont know if that may be affecting you.. there is/was > also chatter on LKML regarding some problems with s/g, you may want to check > there. Oh, that's a couple of patches in question. Git-bisect seems to be a loong way once you loose your installation every time you try. First thing we do, is figure whether or not 2.6.23.1 as released breaks our system too. This way, we can either focus on differences between Linus and Avi, or turn on the big red warning sign saying "regression". - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] severe bug in 2.6.23+ kvm.git
Laurent Vivier wrote: > How do you know the problem has been introduced by kvm ? I don't. In fact I think it has not been introduced by kvm. All I stated, is that we experienced the problem when running the kvm.git kernel after the 2.6.23 update that has not been present in the kvm.git -rc8 as of last thursday. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] severe bug in 2.6.23+ kvm.git
Hi list, we've experienced a severe bug in current kvm.git, that may have been introduced to the git tree quite recently around last weekend. 2.6.23 is broken, 2.6.23-rc8 works for us. The symptom is, that our operon kvm test machine shredders its hard disk content to a state that is not correctably by the file system checker. We use raid1 md mirrored ext3 file systems on 4 sata hard disks on it, and we've verified correct operation of the hardware via badblocks and memtest86. The problem occurs even without kvm modules loaded, so the cause seems to be something that Avi pulled elsewhere. Did anyone else experience similar problems with the 2.6.23 based kvm tree? Does anyone have an idea about a possible cause, which would help us debugging it? thanks, Carsten - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] severe bug in 2.6.23+ kvm.git
Aurelien Jarno wrote: > Could you please precise what is corrupted? The guest disk image? As stated, we actually did not run any guests and did not load the kvm kernel modules. The host root file system gets corrupted to an extend not correctable by the file system checker (we gave it 24h to repair, then interrupted it), and it's very easy to reproduce: a simple kernel make on the hosts lets us reinstall the entire host operating system. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] severe bug in 2.6.23+ kvm.git
Carsten Otte wrote: > First thing we do, is figure whether or not 2.6.23.1 as released breaks > our system too. This way, we can either focus on differences between > Linus and Avi, or turn on the big red warning sign saying "regression". Looks like 2.6.23.1 works fine on that box. We'll leave it running over the weekend with "while true; do make; make clean; done". - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] severe bug in 2.6.23+ kvm.git
Carsten Otte wrote: > 2.6.23 is broken, 2.6.23-rc8 works for us. Actually, the working version was 2.6.23-rc6, git-head of kvm.git as of October 11. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] severe bug in 2.6.23+ kvm.git
Avi Kivity wrote: > kvm.git is actually 2.6.24-rc, pulled from -linus at a random point in > time, so it's not at all surprising if something is broken. Right. We have a backup now, so next time we'll be ok ;-). Would you please pull from Linus again to get the fix into kvm.git so that we can use your tree on that machine again? thanks, Carsten - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] Split kvm_vcpu to support new archs (V2)
Dong, Eddie wrote: > Should fpu_active be X86 specific? Not sure about PPC & S390 (Hollis & > Carsten?), but for IA64 > it is catagoried into low fp & high fp. Our FPU is always "active", we restore FPU state on every context switch. We don't need that flag. Carsten - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [RFC PATCH] current PowerPC patch
Hollis Blanchard wrote: > This patch can now execute guest userspace (I'm not saying it's complete > or stable or anything though). I need to put together a more > full-featured ramdisk to test userspace more completely. Congratulations Hollis, cool stuff :-). - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] severe bug in 2.6.23+ kvm.git
Avi Kivity wrote: > I pulled yesterday so it should be all right (and you don't need me for > that; you can pull from Linus on top of kvm.git). Thanks :-). - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] Split kvm_vcpu to support new archs (V2)
Avi Kivity wrote: > Maybe guard it with CONFIG_KVM_FPU_SWITCHING? Kconfig can set that up > automatically. Since there's nothing this flag breaks for us afaics, I think we should just leave it in common. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] severe bug in 2.6.23+ kvm.git
Avi Kivity wrote: > I pulled yesterday so it should be all right (and you don't need me for > that; you can pull from Linus on top of kvm.git). The machine runs kvm.git for a while now, seems to work ok. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] Split kvm_vcpu to support new archs (V2)
Anthony Liguori wrote: > While both PPC and x86 may be able to use it, I doubt there will > actually be common code that ever touches it. Common code could figure whether or not it needs to save/restore the fpu register set, and call back to an arch specific callback to do so. On the other hand, your argument is hard to disprove without actual portability split of the code that works with the data structures. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] kvm uses smp_call_function_mask() in kvm_flush_remote_tlbs()
Laurent Vivier wrote: > This patches can be applied only on kvm-updates-2.6.24 and kvm-updates-2.6.25 > as it needs smp_call_function_mask(). There's one thing I don't understand: How is this locked versus cpu hotplug? Isn't there an obvious race involved where a cpu unplugged after cpu_set()? - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] kvm uses smp_call_function_mask() in kvm_flush_remote_tlbs()
Avi Kivity wrote: > A cpu unplug first evicts all tasks from the victim cpu. During this > process, it calls kvm via a hotplug notifier, which notifier calls > vcpu_clear() for all vcpus that are resident on that cpu. So after it > runs, there won't be any vcpus on the dead cpu. > > The notifier is called from within stop_machine_run(), which ensures > that no task is running on any cpu, so by the time the cpu is being > unplugged, any concurrent call to kvm_flush_remote_tlbs() will have ended. > > It's a miracle that it works. Really interresting. I put it on the "neat code I want to read" list for long and dark winter evenings :-). - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] Split kvm_vcpu to support new archs.
Hollis Blanchard wrote: > What is the plan here Xiantao? If I want to begin PPC integration, > should I submit some patches too (hopefully in areas where we will not > conflict)? Or should I just review your submissions and hold off on PPC > code changes until the dust settles? Oh, let's throw more patches at Avi. Now that our kvm test machine is up and running again, I'll continue to do so as well. This way, we'll have something that works for all four archs once the dust settles. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] RFC/patch portability: split kvm_vm_ioctl v2
This patch splits kvm_vm_ioctl into archtecture independent parts, and
x86 specific parts which go to kvm_arch_vcpu_ioctl in x86.c.
Common ioctls for all architectures are:
KVM_CREATE_VCPU, KVM_GET_DIRTY_LOG, KVM_SET_USER_MEMORY_REGION
KVM_SET_USER_MEMORY_REGION is actually implemented in x86.c now, because
the code behind looks arch specific to me. The ioctl however is generic
as suggested by Avi's review feedback.
x86 specific ioctls are:
KVM_SET_MEMORY_REGION,
KVM_GET/SET_NR_MMU_PAGES, KVM_SET_MEMORY_ALIAS, KVM_CREATE_IRQCHIP,
KVM_CREATE_IRQ_LINE, KVM_GET/SET_IRQCHIP
Signed-off-by: Carsten Otte <[EMAIL PROTECTED]>
kvm.h |7 +
kvm_main.c | 402 ---
x86.c | 415 +
3 files changed, 426 insertions(+), 398 deletions(-)
---
diff --git a/drivers/kvm/kvm.h b/drivers/kvm/kvm.h
index 08b5b21..a2f2536 100644
--- a/drivers/kvm/kvm.h
+++ b/drivers/kvm/kvm.h
@@ -610,6 +610,13 @@ long kvm_arch_vcpu_ioctl(struct file *filp,
unsigned int ioctl, unsigned long arg);
void kvm_arch_vcpu_load(struct kvm_vcpu *vcpu, int cpu);
void kvm_arch_vcpu_put(struct kvm_vcpu *vcpu);
+int kvm_arch_vm_ioctl_set_memory_region(struct kvm *kvm,
+ struct kvm_userspace_memory_region
+ *mem,
+ int user_alloc);
+long kvm_arch_vm_ioctl(struct file *filp,
+ unsigned int ioctl, unsigned long arg);
+void kvm_arch_destroy_vm(struct kvm *kvm);
__init void kvm_arch_init(void);
diff --git a/drivers/kvm/kvm_main.c b/drivers/kvm/kvm_main.c
index 6f7b31e..09a0826 100644
--- a/drivers/kvm/kvm_main.c
+++ b/drivers/kvm/kvm_main.c
@@ -42,7 +42,6 @@
#include
#include
#include
-#include
#include
#include
@@ -301,31 +300,6 @@ static struct kvm *kvm_create_vm(void)
return kvm;
}
-/*
- * Free any memory in @free but not in @dont.
- */
-static void kvm_free_physmem_slot(struct kvm_memory_slot *free,
- struct kvm_memory_slot *dont)
-{
- if (!dont || free->rmap != dont->rmap)
- vfree(free->rmap);
-
- if (!dont || free->dirty_bitmap != dont->dirty_bitmap)
- vfree(free->dirty_bitmap);
-
- free->npages = 0;
- free->dirty_bitmap = NULL;
- free->rmap = NULL;
-}
-
-static void kvm_free_physmem(struct kvm *kvm)
-{
- int i;
-
- for (i = 0; i < kvm->nmemslots; ++i)
- kvm_free_physmem_slot(&kvm->memslots[i], NULL);
-}
-
static void free_pio_guest_pages(struct kvm_vcpu *vcpu)
{
int i;
@@ -373,7 +347,7 @@ static void kvm_destroy_vm(struct kvm *kvm)
kfree(kvm->vpic);
kfree(kvm->vioapic);
kvm_free_vcpus(kvm);
- kvm_free_physmem(kvm);
+ kvm_arch_destroy_vm(kvm);
kfree(kvm);
}
@@ -638,166 +612,6 @@ void fx_init(struct kvm_vcpu *vcpu)
EXPORT_SYMBOL_GPL(fx_init);
/*
- * Allocate some memory and give it an address in the guest physical address
- * space.
- *
- * Discontiguous memory is allowed, mostly for framebuffers.
- */
-static int kvm_vm_ioctl_set_memory_region(struct kvm *kvm,
- struct
- kvm_userspace_memory_region *mem,
- int user_alloc)
-{
- int r;
- gfn_t base_gfn;
- unsigned long npages;
- unsigned long i;
- struct kvm_memory_slot *memslot;
- struct kvm_memory_slot old, new;
-
- r = -EINVAL;
- /* General sanity checks */
- if (mem->memory_size & (PAGE_SIZE - 1))
- goto out;
- if (mem->guest_phys_addr & (PAGE_SIZE - 1))
- goto out;
- if (mem->slot >= KVM_MEMORY_SLOTS)
- goto out;
- if (mem->guest_phys_addr + mem->memory_size < mem->guest_phys_addr)
- goto out;
-
- memslot = &kvm->memslots[mem->slot];
- base_gfn = mem->guest_phys_addr >> PAGE_SHIFT;
- npages = mem->memory_size >> PAGE_SHIFT;
-
- if (!npages)
- mem->flags &= ~KVM_MEM_LOG_DIRTY_PAGES;
-
- mutex_lock(&kvm->lock);
-
- new = old = *memslot;
-
- new.base_gfn = base_gfn;
- new.npages = npages;
- new.flags = mem->flags;
-
- /* Disallow changing a memory slot's size. */
- r = -EINVAL;
- if (npages && old.npages && npages != old.npages)
- goto out_unlock;
-
- /* Check for overlaps */
- r = -EEXIST;
- for (i = 0; i < KVM_MEMORY_SLOTS; ++i) {
- struct kvm_memory_slot *s = &kvm->memslots[i];
-
- if (s == memslot)
- continue;
- if (!((base_gf
Re: [kvm-devel] [kvm-ppc-devel] RFC/patch portability: split kvm_vm_ioctl v2
Izik Eidus wrote: > btw, if you look at kvmctl, we already do it, > so it is good question if it better to leave this work to userspace > (like it do now) > or do the mapping to userspace from the kernel to userspace (using the > mmap syscall) > > (i like the secoend option beacuse it would be easier to work with qemu > like this) I think we should leave it to userland. This was userland is free to use whatever it wants: - malloc() to get anonymous memory - mmap() to get file backed memory - posix or sysv shared memory - hugetlbfs to save translation steps so long, Carsten - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [kvm-ppc-devel] RFC/patch portability: split kvm_vm_ioctl v2
Avi Kivity wrote: > Hollis Blanchard wrote: >> On Fri, 2007-10-26 at 00:12 +0200, Izik Eidus wrote: >> >>> ok i was thinking, >>> maybe we can rewrite the way kvm hold memory so more code would be shared, >>> lets say we throw away all the slots and arch depended stuff, and we let kvm >>> just hold the userspace allocated memory address, >>> >> With that approach, how would you create a sparse (guest physical) >> memory map in userspace? I guess you would need to use repeated >> mmap(MAP_FIXED), and that's starting to look very brittle. >> >> > > It can't work on i386 due to the limited host virtual address space. That's why memory allocation/preparation needs to be arch dependent: i386 needs a memory layout different from userspace page table due to your argument, and s390 needs to use the userspace page table due to hardware features we want to exploit. As Xiantao pointed out, x86 and ia64 can share the same memory setup code. But s390 and ppc don't. Therefore, I vote for putting it into x86 for now, and come up with an approach to share between x86 and ia64 later on. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [kvm-ppc-devel] RFC/patch portability: split kvm_vm_ioctl v2
Carsten Otte wrote: > That's why memory allocation/preparation needs to be arch dependent: > i386 needs a memory layout different from userspace page table due to > your argument, and s390 needs to use the userspace page table due to > hardware features we want to exploit. > As Xiantao pointed out, x86 and ia64 can share the same memory setup > code. But s390 and ppc don't. Therefore, I vote for putting it into > x86 for now, and come up with an approach to share between x86 and > ia64 later on. After reading Izik's idea: Maybe we should go Izik's way, and have an i386 special case that we can deprecate later on? so long, Carsten - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] RFC/patch portability: split kvm_vm_ioctl v2
Izik Eidus wrote: > ok i was thinking, > maybe we can rewrite the way kvm hold memory so more code would be shared, > lets say we throw away all the slots and arch depended stuff, and we let kvm > just hold the userspace allocated memory address, > > then we will will have to each arch "arch specific" functions that will > map the memory as it will need. > for example for x86 we will make gfn_to_page map on the fly how the > memory should look. > i think i will write patch to example this, but it might take me some time, > > anyway what do you think about this idea? I do strongly vote for it. This way, we'd have memory handling common over all architectures. For a sane end result of a real portably hypervisor, this is very preferable over "have every arch to its own thing". After reading your suggestion, I think memory allocation needs more engineering work to be done until we find a proper arch split then just move it to x86.c. Therefore, I'll modify the patch to leave memory handling in common for now. This way, the rest of the patch can be picked up for the time being. so long, Carsten - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [kvm-ppc-devel] RFC/patch portability: split kvm_vm_ioctl v2
Avi Kivity wrote: > I was talking about x86. > > On x86, you need contiguous userspace, contiguous guest, but again, > what's the problem with one memory slot? There is no problem with one memory slot: it works. It's just that Izik's idea gives us the opportunity to have common code for all four architectures here. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] somthing new for shared memory???
Izik Eidus wrote: > beside moving the memory allocation to userspace (this is first step in > share memory between VMs using smart file system) > there is not much advance. > > about sharing memory between VM and host, we improved it by adding > partial swapping support, > so the host can take memory from the guest in demand. Oooh shared memory :-), my old passion before I started on kvm. We've put a very nice infrastructure for that into the kernel which I would like to advertise here: We have arch/s390/mm/extmem.c, which implements primitives like segment_load, segment_unload etc. Sysfs attributes, and a kernel parameter are used to configure what segments are to be used. On top of that, we have drivers/s390/dcssblk.c, a block driver for shared memory segments that provides an extra block device operation direct_access() which hands out a page pointer to a specific disk block. Furthermore, we modified the memory management (mm/filemap_xip.c) and the ext2 file system (fs/ext2/xip.c) to support a new address space operation get_xip_page(), which is used by ext2 to fullfill all file operations. The beauty of this solution comes with the execute in place effect. Binary executable files and libraries (glibc is a very good candidate) can be used by multiple user programs on multiple guests, while being present in host memory only once. For that, ext2 needs to be mounted read only on a shared memory segment with -o xip. And target binaries and libraries need to be installed on that file system. The rest is transparent to userland. We also played with writable shared memory between user programs on different guests, but did'nt find a good use for that. A prototype 2.6. driver that provides it on top of extmem.c segment_* functions can be found here: http://www.ussg.iu.edu/hypermail/linux/kernel/0412.3/0617.html - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [kvm-ppc-devel] RFC/patch portability: split kvm_vm_ioctl v2
Avi Kivity wrote: > I don't really see a big difference between what we have now (sparse > userspace, sparse guest) and Izik's idea (contiguous userspace, sparse > guest). In both cases you need something like memory slots to describe > the different sections. We don't on s390: we receive a page fault by the guest once it accesses a sparse hole in its address space. We check the user space's VMA and either page it in or submit an addressing exception to the guest. > Moreover, on x86 you may want different properties for different > sections (4K pages for the framebuffer, large pages for main memory), so > you can't allocate memory in one big chunk. That's right. On s390, we can live with whatever properties a section has with regard to page size, backing device and such. So memory may well come to live by different alloations, and different allocation methods. All we need is a permanent contiguous mapping of the guest physical addresses to host user addresses. So Izik's idea would work for us even if we have different sections. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [kvm-ppc-devel] RFC/patch portability: split kvm_vm_ioctl v2
Avi Kivity wrote: > Why aren't memory slots common too? Only their number is different, > while the implementation is the same. Your approach makes the meaning of memory slot somewhat useless on s390, if that one may be sparse and may be result of different allocations: On x86, there has to be one memory slot per allocation, versus on s390 there has to be exactly one memory slot with multiple allocations behind. For userspace that means, with your approach it has to do total different memory setup for different archs _if_ it wants to use multiple allocations and/or sparse: - on x86 it does allocations to random userspace address, and registers each of them as memory slot - on s390 it does allocations to a specific address layout similar to the guest, and registers only one memory slot for the whole thing With Izik's approach however, this is transparent to userspace: it has multiple memory slots, one per allocation. Regardless of the CPU architecture. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [kvm-ppc-devel] RFC/patch portability: split kvm_vm_ioctl v2
Avi Kivity wrote: > Carsten Otte wrote: >> Avi Kivity wrote: >>> Why aren't memory slots common too? Only their number is different, >>> while the implementation is the same. >> Your approach makes the meaning of memory slot somewhat useless on >> s390, if that one may be sparse and may be result of different >> allocations: On x86, there has to be one memory slot per allocation, >> versus on s390 there has to be exactly one memory slot with multiple >> allocations behind. > > No, a memory slot can span multiple backing stores. But it must be > contiguous in both the host userspace and guest physical address spaces. I was not preceise enough: I meant to state that x86 demands one memory slot per contiguous allocation. But with your "s390 has only one memory slot" idea, this introduces a severe restriction for us: our "single memory slot" does not need to be contiguous, neither in guest physical nor in host userspace. All we need, is a certain 1:1+offset relationship between guest physical and host user. Page size, backing, sparse are all variable. Izik's idea, at least how I understood him, makes the best of both worlds: we keep above addressing relationship intact, and have multiple memory slots for all architectures. >> For userspace that means, with your approach it has to do total >> different memory setup for different archs _if_ it wants to use >> multiple allocations and/or sparse: >> - on x86 it does allocations to random userspace address, and >> registers each of them as memory slot >> - on s390 it does allocations to a specific address layout similar to >> the guest, and registers only one memory slot for the whole thing >> >> With Izik's approach however, this is transparent to userspace: it has >> multiple memory slots, one per allocation. Regardless of the CPU >> architecture. > > You can do this with the current memory slots as well. Although I'm > feeling that I misunderstood Izik's idea. I'll go talk to him. No we can't: because current memory slots don't have a permanent relationship between user and guest physical addresses that we do need on s390. We cannot guarantee that over multiple slots, and we cannot keep the guest from addressing memory around the memory slots unless we refuse to use more than only one slot which has to start at guest physical zero. so long, Carsten - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] RFC/patch portability: split kvm_vm_ioctl v3
This patch splits kvm_vm_ioctl into archtecture independent parts, and
x86 specific parts which go to kvm_arch_vcpu_ioctl in x86.c.
The patch has been updated to current git, and it leaves out memory slot
registration work which is currently subject to a detailed discussion.
Common ioctls for all architectures are:
KVM_CREATE_VCPU, KVM_GET_DIRTY_LOG, KVM_SET_USER_MEMORY_REGION
KVM_SET_USER_MEMORY_REGION implementation is no longer moved to x86.c.
It seems to me that more fine-grained refinement then just moving the
code is required here.
x86 specific ioctls are:
KVM_SET_MEMORY_REGION,
KVM_GET/SET_NR_MMU_PAGES, KVM_SET_MEMORY_ALIAS, KVM_CREATE_IRQCHIP,
KVM_CREATE_IRQ_LINE, KVM_GET/SET_IRQCHIP
KVM_SET_TSS_ADDR
KVM_SET_TSS_ADDR has been added to the list of x86 specifics, as Izik's
commit states it is used for emulating real mode on intel.
kvm.h |7 +
kvm_main.c | 255
+---
x86.c | 258
+
3 files changed, 271 insertions(+), 249 deletions(-)
Signed-off-by: Carsten Otte <[EMAIL PROTECTED]>
---
diff --git a/drivers/kvm/kvm.h b/drivers/kvm/kvm.h
index b08fc9e..438d4a9 100644
--- a/drivers/kvm/kvm.h
+++ b/drivers/kvm/kvm.h
@@ -621,6 +621,13 @@ long kvm_arch_vcpu_ioctl(struct file *filp,
unsigned int ioctl, unsigned long arg);
void kvm_arch_vcpu_load(struct kvm_vcpu *vcpu, int cpu);
void kvm_arch_vcpu_put(struct kvm_vcpu *vcpu);
+int kvm_vm_ioctl_set_memory_region(struct kvm *kvm,
+ struct
+ kvm_userspace_memory_region *mem,
+ int user_alloc);
+long kvm_arch_vm_ioctl(struct file *filp,
+ unsigned int ioctl, unsigned long arg);
+void kvm_arch_destroy_vm(struct kvm *kvm);
__init void kvm_arch_init(void);
diff --git a/drivers/kvm/kvm_main.c b/drivers/kvm/kvm_main.c
index 9a3d663..7a85be9 100644
--- a/drivers/kvm/kvm_main.c
+++ b/drivers/kvm/kvm_main.c
@@ -792,36 +792,16 @@ out:
}
EXPORT_SYMBOL_GPL(kvm_set_memory_region);
-static int kvm_vm_ioctl_set_memory_region(struct kvm *kvm,
- struct
- kvm_userspace_memory_region *mem,
- int user_alloc)
+int kvm_vm_ioctl_set_memory_region(struct kvm *kvm,
+ struct
+ kvm_userspace_memory_region *mem,
+ int user_alloc)
{
if (mem->slot >= KVM_MEMORY_SLOTS)
return -EINVAL;
return kvm_set_memory_region(kvm, mem, user_alloc);
}
-static int kvm_vm_ioctl_set_nr_mmu_pages(struct kvm *kvm,
- u32 kvm_nr_mmu_pages)
-{
- if (kvm_nr_mmu_pages < KVM_MIN_ALLOC_MMU_PAGES)
- return -EINVAL;
-
- mutex_lock(&kvm->lock);
-
- kvm_mmu_change_mmu_pages(kvm, kvm_nr_mmu_pages);
- kvm->n_requested_mmu_pages = kvm_nr_mmu_pages;
-
- mutex_unlock(&kvm->lock);
- return 0;
-}
-
-static int kvm_vm_ioctl_get_nr_mmu_pages(struct kvm *kvm)
-{
- return kvm->n_alloc_mmu_pages;
-}
-
/*
* Get (and clear) the dirty memory log for a memory slot.
*/
@@ -867,111 +847,6 @@ out:
return r;
}
-/*
- * 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
- * VGA region.
- */
-static int kvm_vm_ioctl_set_memory_alias(struct kvm *kvm,
-struct kvm_memory_alias *alias)
-{
- int r, n;
- struct kvm_mem_alias *p;
-
- r = -EINVAL;
- /* General sanity checks */
- if (alias->memory_size & (PAGE_SIZE - 1))
- goto out;
- if (alias->guest_phys_addr & (PAGE_SIZE - 1))
- goto out;
- if (alias->slot >= KVM_ALIAS_SLOTS)
- goto out;
- if (alias->guest_phys_addr + alias->memory_size
- < alias->guest_phys_addr)
- goto out;
- if (alias->target_phys_addr + alias->memory_size
- < alias->target_phys_addr)
- goto out;
-
- mutex_lock(&kvm->lock);
-
- p = &kvm->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)
- break;
- kvm->naliases = n;
-
- kvm_mmu_zap_all(kvm);
-
- mutex_unlock(&kvm->lock);
-
- return 0;
-
-out:
- return r;
-}
-
-static int kvm_vm_ioctl_get_i
Re: [kvm-devel] [kvm-ppc-devel] RFC/patch portability: split kvm_vm_ioctl v2
Hollis Blanchard wrote: > Izik's idea (as I understand it) is to have one ioctl registering all of > RAM, and then multiple "configure slot" ioctls that tell the kernel how > to divide that area into the guest physical address space. That seems > more awkward to me and I don't seem a benefit. I think we need to wait for Izik to explain more. In this interpretation it really does'nt make sense for s390 as well. My interpretation of Izik's idea was just like memory slots are today. Avi clarified my misunderstanding of memory slots on x86. so long, Carsten - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] RFC/patch portability: split kvm_vm_ioctl v2
Zhang, Xiantao wrote: > I don't think we can move the whole function to arch-specific part, > because it should work well (or with few issues) for most archs. > Basically, IA64 mostly can use it directly. If we move them as > arch-specific, it will introduces many duplicates. As you said, S390 has > quite difference about this side, but I think maybe we can use macros, > such as #ifndef CONFIG_S390 to comment out them, and S390 define it in > your arch-specific portions. Any other good ideas ? I really dislike CONFIG_ARCH sections. They are usually a strong indication that proper interfaces between arch dependent and arch independent code have not been found just yet. If you look at old subsystems where lots of engineers had time to optimize the code, like memory management for example, you rarely find #ifdefs at all. I think that should be our goal. As for KVM_SET_USER_MEMORY_REGION, the function you pointed at, I've left it in common for now in patch version 3. thanks for your review, Carsten - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [kvm-ppc-devel] RFC/patch portability: split kvm_vm_ioctl v2
Izik Eidus wrote: > yep, > another cleanup is needed for: > the rmap part, and the mmu cache size setting that found it way to the > memory slot allocation function. That's true, but can be subject of one of the next portability paches. I want to keep each of them trivial and easily reviewable. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [kvm-ppc-devel] RFC/patch portability: split kvm_vm_ioctl v2
Avi Kivity wrote: > Zhang, Xiantao wrote: >> Avi Kivity wrote: >>> Wht about aliases? Aliases allow you go have two different physical >>> addresses for the same page. This is useful for mapping the >>> framebuffer on x86 (both at the pci region and at 0xa, the >>> traditional ISA location). >>> >>> Are they useful for ia64? >>> >> >> Sure, it also should benefit IA64 side :) >> > > Actually, thinking about it, regular memory slots support this too. > Simply create a new memory slot to that memory. So aliases can be x86 > specific (for compatibility reasons). Memory slots turn out to be surprisingly flexible :-). - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [kvm-ppc-devel] RFC/patch portability: split kvm_vm_ioctl v2
Izik Eidus wrote: > my idea was to let kvm register userspace memory that will hold the > guest memory, > and then much like qemu do with its cpu_register_physical_memory > function, run ioctls > that will tell the kernel how to map this memory, > what i wanted to achieved is making the memory allocation code shared, > but still > let each arch to use any kind of "arch depended" mapping rules it want, > but after reading the last posts it seems like you can use the normal > memslots, so it is kind of useless i guess and i will > give up the idea of writing patch to make this, unless you still have > problem with the memslots? Looks like we shared the same misunderstanding about the current memslot implementation *shaking hands*. After being educated on memslots by Avi, I agree that memslots do the right thing. cheers, Carsten - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] RFC/Patch 0/4 portability split
This patch series continues the split of kvm_main.c for portability. The first patch that splits kvm_vm_ioctl is unchanged since last submit, but has not yet been picked up upstream. There are no more ongoing discussions regarding it's content, therefore I'd like to ask for integration of that one. The other three patches require peer review. They move entire functions blocks from kvm_main.c to x86.c. Xiantao and Hollis please make sure I am not moving anything of interrest for your ports. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] RFC/Patch 1/4 portability: split kvm_vm_ioctl v3
This patch splits kvm_vm_ioctl into archtecture independent parts, and
x86 specific parts which go to kvm_arch_vcpu_ioctl in x86.c.
The patch is unchanged since last submission.
Common ioctls for all architectures are:
KVM_CREATE_VCPU, KVM_GET_DIRTY_LOG, KVM_SET_USER_MEMORY_REGION
x86 specific ioctls are:
KVM_SET_MEMORY_REGION,
KVM_GET/SET_NR_MMU_PAGES, KVM_SET_MEMORY_ALIAS, KVM_CREATE_IRQCHIP,
KVM_CREATE_IRQ_LINE, KVM_GET/SET_IRQCHIP
KVM_SET_TSS_ADDR
Signed-off-by: Carsten Otte <[EMAIL PROTECTED]>
Reviewed-by: Christian Borntraeger <[EMAIL PROTECTED]>
Acked-by: Hollis Blanchard <[EMAIL PROTECTED]>
---
kvm.h |7 +
kvm_main.c | 255 +---
x86.c | 258 +
3 files changed, 271 insertions(+), 249 deletions(-)
diff --git a/drivers/kvm/kvm.h b/drivers/kvm/kvm.h
index b08fc9e..438d4a9 100644
--- a/drivers/kvm/kvm.h
+++ b/drivers/kvm/kvm.h
@@ -621,6 +621,13 @@ long kvm_arch_vcpu_ioctl(struct file *filp,
unsigned int ioctl, unsigned long arg);
void kvm_arch_vcpu_load(struct kvm_vcpu *vcpu, int cpu);
void kvm_arch_vcpu_put(struct kvm_vcpu *vcpu);
+int kvm_vm_ioctl_set_memory_region(struct kvm *kvm,
+ struct
+ kvm_userspace_memory_region *mem,
+ int user_alloc);
+long kvm_arch_vm_ioctl(struct file *filp,
+ unsigned int ioctl, unsigned long arg);
+void kvm_arch_destroy_vm(struct kvm *kvm);
__init void kvm_arch_init(void);
diff --git a/drivers/kvm/kvm_main.c b/drivers/kvm/kvm_main.c
index 9a3d663..7a85be9 100644
--- a/drivers/kvm/kvm_main.c
+++ b/drivers/kvm/kvm_main.c
@@ -792,36 +792,16 @@ out:
}
EXPORT_SYMBOL_GPL(kvm_set_memory_region);
-static int kvm_vm_ioctl_set_memory_region(struct kvm *kvm,
- struct
- kvm_userspace_memory_region *mem,
- int user_alloc)
+int kvm_vm_ioctl_set_memory_region(struct kvm *kvm,
+ struct
+ kvm_userspace_memory_region *mem,
+ int user_alloc)
{
if (mem->slot >= KVM_MEMORY_SLOTS)
return -EINVAL;
return kvm_set_memory_region(kvm, mem, user_alloc);
}
-static int kvm_vm_ioctl_set_nr_mmu_pages(struct kvm *kvm,
- u32 kvm_nr_mmu_pages)
-{
- if (kvm_nr_mmu_pages < KVM_MIN_ALLOC_MMU_PAGES)
- return -EINVAL;
-
- mutex_lock(&kvm->lock);
-
- kvm_mmu_change_mmu_pages(kvm, kvm_nr_mmu_pages);
- kvm->n_requested_mmu_pages = kvm_nr_mmu_pages;
-
- mutex_unlock(&kvm->lock);
- return 0;
-}
-
-static int kvm_vm_ioctl_get_nr_mmu_pages(struct kvm *kvm)
-{
- return kvm->n_alloc_mmu_pages;
-}
-
/*
* Get (and clear) the dirty memory log for a memory slot.
*/
@@ -867,111 +847,6 @@ out:
return r;
}
-/*
- * 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
- * VGA region.
- */
-static int kvm_vm_ioctl_set_memory_alias(struct kvm *kvm,
-struct kvm_memory_alias *alias)
-{
- int r, n;
- struct kvm_mem_alias *p;
-
- r = -EINVAL;
- /* General sanity checks */
- if (alias->memory_size & (PAGE_SIZE - 1))
- goto out;
- if (alias->guest_phys_addr & (PAGE_SIZE - 1))
- goto out;
- if (alias->slot >= KVM_ALIAS_SLOTS)
- goto out;
- if (alias->guest_phys_addr + alias->memory_size
- < alias->guest_phys_addr)
- goto out;
- if (alias->target_phys_addr + alias->memory_size
- < alias->target_phys_addr)
- goto out;
-
- mutex_lock(&kvm->lock);
-
- p = &kvm->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)
- break;
- kvm->naliases = n;
-
- kvm_mmu_zap_all(kvm);
-
- mutex_unlock(&kvm->lock);
-
- return 0;
-
-out:
- return r;
-}
-
-static int kvm_vm_ioctl_get_irqchip(struct kvm *kvm, struct kvm_irqchip *chip)
-{
- int r;
-
- r = 0;
- switch (chip->chip_id) {
- case KVM_IRQCHIP_PIC_MASTER:
- memcpy(&chip->chip.pic,
- &pic_irqchip(kvm)->pics[0],
- si
[kvm-devel] RFC/Patch 2/4 portability: move memory segmentation to x86.c
This patch moves the definition of segment_descriptor_64 for AMD64 and
EM64T from kvm_main.c to segment_descriptor.h. It also adds a proper
#ifndef...#define...#endif around that header file.
The implementation of segment_base is moved from kvm_main.c to x86.c.
Signed-off-by: Carsten Otte <[EMAIL PROTECTED]>
Reviewed-by: Christian Borntraeger <[EMAIL PROTECTED]>
---
kvm_main.c | 42 --
segment_descriptor.h | 12
x86.c| 33 +
3 files changed, 45 insertions(+), 42 deletions(-)
Index: kvm/drivers/kvm/kvm_main.c
===
--- kvm.orig/drivers/kvm/kvm_main.c 2007-10-29 12:48:55.0 +0100
+++ kvm/drivers/kvm/kvm_main.c 2007-10-29 13:05:00.0 +0100
@@ -18,7 +18,6 @@
#include "kvm.h"
#include "x86.h"
#include "x86_emulate.h"
-#include "segment_descriptor.h"
#include "irq.h"
#include
@@ -104,50 +103,9 @@
#define CR8_RESERVED_BITS (~(unsigned long)X86_CR8_TPR)
#define EFER_RESERVED_BITS 0xf2fe
-#ifdef CONFIG_X86_64
-/* LDT or TSS descriptor in the GDT. 16 bytes. */
-struct segment_descriptor_64 {
- struct segment_descriptor s;
- u32 base_higher;
- u32 pad_zero;
-};
-
-#endif
-
static long kvm_vcpu_ioctl(struct file *file, unsigned int ioctl,
unsigned long arg);
-unsigned long segment_base(u16 selector)
-{
- struct descriptor_table gdt;
- struct segment_descriptor *d;
- unsigned long table_base;
- unsigned long v;
-
- if (selector == 0)
- return 0;
-
- asm("sgdt %0" : "=m"(gdt));
- table_base = gdt.base;
-
- if (selector & 4) { /* from ldt */
- u16 ldt_selector;
-
- asm("sldt %0" : "=g"(ldt_selector));
- table_base = segment_base(ldt_selector);
- }
- d = (struct segment_descriptor *)(table_base + (selector & ~7));
- v = d->base_low | ((unsigned long)d->base_mid << 16) |
- ((unsigned long)d->base_high << 24);
-#ifdef CONFIG_X86_64
- if (d->system == 0 && (d->type == 2 || d->type == 9 || d->type == 11))
- v |= ((unsigned long) \
- ((struct segment_descriptor_64 *)d)->base_higher) << 32;
-#endif
- return v;
-}
-EXPORT_SYMBOL_GPL(segment_base);
-
static inline int valid_vcpu(int n)
{
return likely(n >= 0 && n < KVM_MAX_VCPUS);
Index: kvm/drivers/kvm/segment_descriptor.h
===
--- kvm.orig/drivers/kvm/segment_descriptor.h 2007-10-29 12:48:55.0
+0100
+++ kvm/drivers/kvm/segment_descriptor.h2007-10-29 13:04:38.0
+0100
@@ -1,3 +1,6 @@
+#ifndef __SEGMENT_DESCRIPTOR_H
+#define __SEGMENT_DESCRIPTOR_H
+
struct segment_descriptor {
u16 limit_low;
u16 base_low;
@@ -14,4 +17,13 @@
u8 base_high;
} __attribute__((packed));
+#ifdef CONFIG_X86_64
+/* LDT or TSS descriptor in the GDT. 16 bytes. */
+struct segment_descriptor_64 {
+ struct segment_descriptor s;
+ u32 base_higher;
+ u32 pad_zero;
+};
+#endif
+#endif
Index: kvm/drivers/kvm/x86.c
===
--- kvm.orig/drivers/kvm/x86.c 2007-10-29 12:48:55.0 +0100
+++ kvm/drivers/kvm/x86.c 2007-10-29 13:06:01.0 +0100
@@ -16,16 +16,49 @@
#include "kvm.h"
#include "x86.h"
+#include "segment_descriptor.h"
#include "irq.h"
#include
#include
#include
+#include
#include
#define MAX_IO_MSRS 256
+unsigned long segment_base(u16 selector)
+{
+ struct descriptor_table gdt;
+ struct segment_descriptor *d;
+ unsigned long table_base;
+ unsigned long v;
+
+ if (selector == 0)
+ return 0;
+
+ asm("sgdt %0" : "=m"(gdt));
+ table_base = gdt.base;
+
+ if (selector & 4) { /* from ldt */
+ u16 ldt_selector;
+
+ asm("sldt %0" : "=g"(ldt_selector));
+ table_base = segment_base(ldt_selector);
+ }
+ d = (struct segment_descriptor *)(table_base + (selector & ~7));
+ v = d->base_low | ((unsigned long)d->base_mid << 16) |
+ ((unsigned long)d->base_high << 24);
+#ifdef CONFIG_X86_64
+ if (d->system == 0 && (d->type == 2 || d->type == 9 || d->type == 11))
+ v |= ((unsigned long) \
+ ((struct segment_descriptor_64 *)d)->base_higher) << 32;
+#endif
+ return v;
+}
+EXPORT_SYMBOL_GPL(segment_base);
+
/*
* List of msr numb
[kvm-devel] RFC/Patch 3/4 portability: move get/set_apic_base to x86.c
This patch moves the implementation of get_apic_base and set_apic_base
from kvm_main.c to x86.c
Signed-off-by: Carsten Otte <[EMAIL PROTECTED]>
Reviewed-by: Christian Borntraeger <[EMAIL PROTECTED]>
---
kvm_main.c | 19 ---
x86.c | 19 +++
2 files changed, 19 insertions(+), 19 deletions(-)
Index: kvm/drivers/kvm/kvm_main.c
===
--- kvm.orig/drivers/kvm/kvm_main.c 2007-10-29 13:06:53.0 +0100
+++ kvm/drivers/kvm/kvm_main.c 2007-10-29 13:08:49.0 +0100
@@ -556,25 +556,6 @@
}
EXPORT_SYMBOL_GPL(get_cr8);
-u64 kvm_get_apic_base(struct kvm_vcpu *vcpu)
-{
- if (irqchip_in_kernel(vcpu->kvm))
- return vcpu->apic_base;
- else
- return vcpu->apic_base;
-}
-EXPORT_SYMBOL_GPL(kvm_get_apic_base);
-
-void kvm_set_apic_base(struct kvm_vcpu *vcpu, u64 data)
-{
- /* TODO: reserve bits check */
- if (irqchip_in_kernel(vcpu->kvm))
- kvm_lapic_set_base(vcpu, data);
- else
- vcpu->apic_base = data;
-}
-EXPORT_SYMBOL_GPL(kvm_set_apic_base);
-
void fx_init(struct kvm_vcpu *vcpu)
{
unsigned after_mxcsr_mask;
Index: kvm/drivers/kvm/x86.c
===
--- kvm.orig/drivers/kvm/x86.c 2007-10-29 13:06:53.0 +0100
+++ kvm/drivers/kvm/x86.c 2007-10-29 13:08:48.0 +0100
@@ -59,6 +59,25 @@
}
EXPORT_SYMBOL_GPL(segment_base);
+u64 kvm_get_apic_base(struct kvm_vcpu *vcpu)
+{
+ if (irqchip_in_kernel(vcpu->kvm))
+ return vcpu->apic_base;
+ else
+ return vcpu->apic_base;
+}
+EXPORT_SYMBOL_GPL(kvm_get_apic_base);
+
+void kvm_set_apic_base(struct kvm_vcpu *vcpu, u64 data)
+{
+ /* TODO: reserve bits check */
+ if (irqchip_in_kernel(vcpu->kvm))
+ kvm_lapic_set_base(vcpu, data);
+ else
+ vcpu->apic_base = data;
+}
+EXPORT_SYMBOL_GPL(kvm_set_apic_base);
+
/*
* List of msr numbers which we expose to userspace through KVM_GET_MSRS
* and KVM_SET_MSRS, and KVM_GET_MSR_INDEX_LIST.
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] RFC/Patch 4/4 portability: move control register helper functions to x86.c
This patch moves the definitions of CR0_RESERVED_BITS,
CR4_RESERVED_BITS, and CR8_RESERVED_BITS along with the following
functions from kvm_main.c to x86.c:
set_cr0(), set_cr3(), set_cr4(), set_cr8(), get_cr8(), lmsw(),
load_pdptrs()
The static function wrapper inject_gp is duplicated in kvm_main.c and
x86.c for now, the version in kvm_main.c should disappear once the last
user of it is gone too.
The function load_pdptrs is no longer static, and now defined in x86.h
for the time being, until the last user of it is gone from kvm_main.c.
Signed-off-by: Carsten Otte <[EMAIL PROTECTED]>
Reviewed-by: Christian Borntraeger <[EMAIL PROTECTED]>
---
kvm_main.c | 219 ---
x86.c | 224 +
x86.h |2
3 files changed, 225 insertions(+), 220 deletions(-)
Index: kvm/drivers/kvm/kvm_main.c
===
--- kvm.orig/drivers/kvm/kvm_main.c 2007-10-29 13:12:18.0 +0100
+++ kvm/drivers/kvm/kvm_main.c 2007-10-29 15:04:21.0 +0100
@@ -90,17 +90,6 @@
static struct dentry *debugfs_dir;
-#define CR0_RESERVED_BITS \
- (~(unsigned long)(X86_CR0_PE | X86_CR0_MP | X86_CR0_EM | X86_CR0_TS \
- | X86_CR0_ET | X86_CR0_NE | X86_CR0_WP | X86_CR0_AM \
- | X86_CR0_NW | X86_CR0_CD | X86_CR0_PG))
-#define CR4_RESERVED_BITS \
- (~(unsigned long)(X86_CR4_VME | X86_CR4_PVI | X86_CR4_TSD | X86_CR4_DE\
- | X86_CR4_PSE | X86_CR4_PAE | X86_CR4_MCE \
- | X86_CR4_PGE | X86_CR4_PCE | X86_CR4_OSFXSR \
- | X86_CR4_OSXMMEXCPT | X86_CR4_VMXE))
-
-#define CR8_RESERVED_BITS (~(unsigned long)X86_CR8_TPR)
#define EFER_RESERVED_BITS 0xf2fe
static long kvm_vcpu_ioctl(struct file *file, unsigned int ioctl,
@@ -348,214 +337,6 @@
kvm_x86_ops->inject_gp(vcpu, 0);
}
-/*
- * Load the pae pdptrs. Return true is they are all valid.
- */
-static int load_pdptrs(struct kvm_vcpu *vcpu, unsigned long cr3)
-{
- gfn_t pdpt_gfn = cr3 >> PAGE_SHIFT;
- unsigned offset = ((cr3 & (PAGE_SIZE-1)) >> 5) << 2;
- int i;
- int ret;
- u64 pdpte[ARRAY_SIZE(vcpu->pdptrs)];
-
- mutex_lock(&vcpu->kvm->lock);
- ret = kvm_read_guest_page(vcpu->kvm, pdpt_gfn, pdpte,
- offset * sizeof(u64), sizeof(pdpte));
- if (ret < 0) {
- ret = 0;
- goto out;
- }
- for (i = 0; i < ARRAY_SIZE(pdpte); ++i) {
- if ((pdpte[i] & 1) && (pdpte[i] & 0xfff001e6ull)) {
- ret = 0;
- goto out;
- }
- }
- ret = 1;
-
- memcpy(vcpu->pdptrs, pdpte, sizeof(vcpu->pdptrs));
-out:
- mutex_unlock(&vcpu->kvm->lock);
-
- return ret;
-}
-
-void set_cr0(struct kvm_vcpu *vcpu, unsigned long cr0)
-{
- if (cr0 & CR0_RESERVED_BITS) {
- printk(KERN_DEBUG "set_cr0: 0x%lx #GP, reserved bits 0x%lx\n",
- cr0, vcpu->cr0);
- inject_gp(vcpu);
- return;
- }
-
- if ((cr0 & X86_CR0_NW) && !(cr0 & X86_CR0_CD)) {
- printk(KERN_DEBUG "set_cr0: #GP, CD == 0 && NW == 1\n");
- inject_gp(vcpu);
- return;
- }
-
- if ((cr0 & X86_CR0_PG) && !(cr0 & X86_CR0_PE)) {
- printk(KERN_DEBUG "set_cr0: #GP, set PG flag "
- "and a clear PE flag\n");
- inject_gp(vcpu);
- return;
- }
-
- if (!is_paging(vcpu) && (cr0 & X86_CR0_PG)) {
-#ifdef CONFIG_X86_64
- if ((vcpu->shadow_efer & EFER_LME)) {
- int cs_db, cs_l;
-
- if (!is_pae(vcpu)) {
- printk(KERN_DEBUG "set_cr0: #GP, start paging "
- "in long mode while PAE is disabled\n");
- inject_gp(vcpu);
- return;
- }
- kvm_x86_ops->get_cs_db_l_bits(vcpu, &cs_db, &cs_l);
- if (cs_l) {
- printk(KERN_DEBUG "set_cr0: #GP, start paging "
- "in long mode while CS.L == 1\n");
- inject_gp(vcpu);
- return;
-
- }
- } else
-#endif
- if (is_pae(vcpu) && !load_pdptrs(vcpu, vcpu->
Re: [kvm-devel] RFC/Patch 1/4 portability: split kvm_vm_ioctl v3
Izik Eidus wrote: > i think KVM_SET_MEMORY_ALIAS, is useful not just to x86, > > avi talked with the ia64 guys and they told him that they have use for > this function. > > is it that bad for you? KVM_SET_USER_MEMORY_REGION is a superset of KVM_SET_MEMORY_ALIAS, at least that's how I read Avi's reply to Xiantaos comment. Avi, could you clarify this? - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] RFC/Patch 1/4 portability: split kvm_vm_ioctl v3
Hollis Blanchard wrote: > AFAICS, you can just issue two KVM_SET_USER_MEMORY_REGION ioctls in a > row, changing 'guest_phys_addr' and leaving 'userspace_addr' the same. > That will create an alias. That was also my understanding of Avi's comment. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] RFC/patch portability: split kvm_vm_ioctl v3
Dong, Eddie wrote: > Why KVM_IRQ_LINE is X86b specific? The original idea are based on ACPI spec > which > I assume to be generic though S390 may not take. ACPI is not present on s390 and ppc. In fact, I doubt it is present on any architecture except those two intel ones: at least my mips router and my arm pda don't have it either. It's kind of based on the idea of having a bios alike code. so long, Carsten - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] RFC/patch portability: split kvm_vm_ioctl v3
Avi Kivity wrote: >> Why KVM_IRQ_LINE is X86b specific? The original idea are based on ACPI spec >> which >> I assume to be generic though S390 may not take. >> >> > > ia64 can probably share much. ppc will probably want KVM_IRQ_LINE with > with different parameters. s390, as far as I understand, will not. I think we'll have to come up with a more modular approach later on: various aspects are of interest to various architectures and/or platforms. The generic kernel has CONFIG_FEATURE toggles for that. The portability patches are not intended to split kvm into components at this stage, I believe that is something that we will have to come up when actual ports are being integrated. In my optinion, a reasonable next-step refinement here would be to come up with a generic interrupt injection call that can inject an interrupt on any architecture and platform. After userspace has adopted to use that one, we can keep the old call for backward compatibility reasons in a deprecated state for some time before removing it. For now, my goal is to seperate what is generic in a way that it is a functionality that a portable user space program that uses kvm can expect to work the same way on all architectures and platforms. so long, Carsten - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] RFC/patch portability: split kvm_vm_ioctl v3
Dong, Eddie wrote:
> BTW, how S390 user/kernel interrupt signal is communicated?
Our s90host prototype does inject it from userspace, so there is no
need to have a call for that.
Nevertheless, I really love the lightweight exits that kvm has
invented and I want to use it on s390 with kvm too. In that case,
we'll have an interrupt facility in the kernel that is in terms of
functionality close to the pic/lapic work for x86.
For that, I think we could encode an interrupt number in an __u64 that
has a platform specific helper function in userspace to generate that
interrupt number: for x86 that would just equal the irq line, for s390
that would be more complex. The common kvm code can then take that
__u64 number and call an architecture specific callback that injects
the interrupt.
In addition, I would love to be able to specify which target CPUs may
receive that interrupt because our IPI equivalent comes out just like
a regular interrupt on just one target CPU.
That boils down to something like this:
struct kvm_interrupt_data {
__u64interrupt_number;
cpuset_t possible_target_cpus;
}
and an KVM_INJECT_INTERRUPT common ioctl for the vm to provide this.
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] RFC/patch portability: split kvm_vm_ioctl v3
Dong, Eddie wrote: > OK, so how can a device inform kernel for an IRQ in S390? Oooh, that is a looong explanation. If you want to peek at it, see http://publibz.boulder.ibm.com/epubs/pdf/a2278324.pdf . Chapter 6 covers Interruptions. I'd recommend to start with reading external interruptions, because that is the one we'll be primarily be using with kvm. External interruptions are used for things like timers, hypercalls, and IPIs. The "Program Interruption Coditions" are also worth reading, they cover things similar to general protection fault on x86. Chapter 11 covers a different type of Interruptions, such as error detection of hardware failures and hot-standby component failover. Chapter 16 is also of interrest, it covers I/O interruptions. Whenever you see me in person (next kvm forum maybe?), you are invited to a lot of beer: I'll bring pen and paper and try to give you an overview while we get drunk :-). so long, Carsten - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] RFC/patch portability: split kvm_vm_ioctl v3
Avi Kivity wrote:
> But that doesn't make the code portable. The s390 userspace has to know
> how to encode the number, and x86 will do it differently.
>
> If it's really different, let's keep it different. Unless you can push
> the encoding so far back it's transparent to userspace (e.g. qemu).
I agree that we should keep it seperate unless it makes sense to have
commonality.
A paravirt driver for example could make use of this abstraction: it
could request an interrupt, and hand the __u64 that it got back to a
function that actually sends the interrupt over.
But for now, I agree we should keep it seperate. I am just thinking
loud here.
>> In addition, I would love to be able to specify which target CPUs may
>> receive that interrupt because our IPI equivalent comes out just like
>> a regular interrupt on just one target CPU.
>>
>> That boils down to something like this:
>> struct kvm_interrupt_data {
>> __u64 interrupt_number;
>> cpuset_t possible_target_cpus;
>> }
>> and an KVM_INJECT_INTERRUPT common ioctl for the vm to provide this.
>
> Are cpusets exported to userspace?
>
> x86 has something similar (IPI to a set of cpus) but it's handled 100%
> in the kernel these days.
>
No they are'nt. We'd need to come up with a different data structure
for that. Does IPI have an interrupt number too?
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] RFC/patch portability: split kvm_vm_ioctl v3
Avi Kivity wrote: > A bitmap would do it, but what size? Expandable ones are messy. We could have a #define KVM_CPU_BITMAP_SIZE in the arch specific header files that go to include/asm/. For s390, we have one of our rocket science virtualization accelerating facilities that limits us to 64 cpus per guest. This may well be extended later on, but for now that would be sufficient. Thinking about Christoph Lameter with his 4k CPU boxes, I believe ia64 would want fr more than that. > No, it's a command (mmio) to the APIC, you tell it which vector you want > and to which cpus you want it delivered. So you can have many IPI > interrupt vectors. I see. But the interrupt vector can be encoded in __u64? - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] RFC/patch portability: split kvm_vm_ioctl v3
Dong, Eddie wrote:
> IA64/KVM will handle interrupt in kernel including IPI IMO, so what
> user level need to tell kernel is which platform IRQ pin is set/cleared.
>
> Can't S390 do in similar way? From platform point of view, each
> irq can have a unique # and the device itself doesn;t need to know
> which CPU will receive it. Are talking about having your interrupt
> controller in user space? or I missed something.
We don't have interrupt controllers in the first place, and therefore
we don't need to emulate them. We want to handle IPI inside the kernel
too, and we also need to be able to inject interrupts from userspace.
Would you be able to encode your interrupt related information into an
__u64 data type? Do all CPUs have the same interrupts pending, or is
the information per-cpu? Does the data structure that Avi suggested
fit your interrupt injection needs?
struct kvm_interrupt {
__u64 vector;
__u32 size; /* bytes, must be multiple of 8 */
__u32 pad;
__u64 cpuset[0];
};
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] RFC/patch 1/3 portability: move kvm_get/set_msr[_common] to x86.c
This patch moves the implementation of the functions of kvm_get/set_msr,
kvm_get/set_msr_common, and set_efer from kvm_main.c to x86.c. The
definition of EFER_RESERVED_BITS is moved too.
Signed-off-by: Carsten Otte <[EMAIL PROTECTED]>
---
kvm_main.c | 133
x86.c | 134 +
2 files changed, 134 insertions(+), 133 deletions(-)
Index: kvm/drivers/kvm/kvm_main.c
===
--- kvm.orig/drivers/kvm/kvm_main.c 2007-10-30 11:28:41.0 +0100
+++ kvm/drivers/kvm/kvm_main.c 2007-10-30 14:30:34.0 +0100
@@ -90,8 +90,6 @@
static struct dentry *debugfs_dir;
-#define EFER_RESERVED_BITS 0xf2fe
-
static long kvm_vcpu_ioctl(struct file *file, unsigned int ioctl,
unsigned long arg);
@@ -1347,137 +1345,6 @@
}
}
-int kvm_get_msr_common(struct kvm_vcpu *vcpu, u32 msr, u64 *pdata)
-{
- u64 data;
-
- switch (msr) {
- case 0xc0010010: /* SYSCFG */
- case 0xc0010015: /* HWCR */
- case MSR_IA32_PLATFORM_ID:
- case MSR_IA32_P5_MC_ADDR:
- case MSR_IA32_P5_MC_TYPE:
- case MSR_IA32_MC0_CTL:
- case MSR_IA32_MCG_STATUS:
- case MSR_IA32_MCG_CAP:
- case MSR_IA32_MC0_MISC:
- case MSR_IA32_MC0_MISC+4:
- case MSR_IA32_MC0_MISC+8:
- case MSR_IA32_MC0_MISC+12:
- case MSR_IA32_MC0_MISC+16:
- case MSR_IA32_UCODE_REV:
- case MSR_IA32_PERF_STATUS:
- case MSR_IA32_EBL_CR_POWERON:
- /* MTRR registers */
- case 0xfe:
- case 0x200 ... 0x2ff:
- data = 0;
- break;
- case 0xcd: /* fsb frequency */
- data = 3;
- break;
- case MSR_IA32_APICBASE:
- data = kvm_get_apic_base(vcpu);
- break;
- case MSR_IA32_MISC_ENABLE:
- data = vcpu->ia32_misc_enable_msr;
- break;
-#ifdef CONFIG_X86_64
- case MSR_EFER:
- data = vcpu->shadow_efer;
- break;
-#endif
- default:
- pr_unimpl(vcpu, "unhandled rdmsr: 0x%x\n", msr);
- return 1;
- }
- *pdata = data;
- return 0;
-}
-EXPORT_SYMBOL_GPL(kvm_get_msr_common);
-
-/*
- * Reads an msr value (of 'msr_index') into 'pdata'.
- * Returns 0 on success, non-0 otherwise.
- * Assumes vcpu_load() was already called.
- */
-int kvm_get_msr(struct kvm_vcpu *vcpu, u32 msr_index, u64 *pdata)
-{
- return kvm_x86_ops->get_msr(vcpu, msr_index, pdata);
-}
-
-#ifdef CONFIG_X86_64
-
-static void set_efer(struct kvm_vcpu *vcpu, u64 efer)
-{
- if (efer & EFER_RESERVED_BITS) {
- printk(KERN_DEBUG "set_efer: 0x%llx #GP, reserved bits\n",
- efer);
- inject_gp(vcpu);
- return;
- }
-
- if (is_paging(vcpu)
- && (vcpu->shadow_efer & EFER_LME) != (efer & EFER_LME)) {
- printk(KERN_DEBUG "set_efer: #GP, change LME while paging\n");
- inject_gp(vcpu);
- return;
- }
-
- kvm_x86_ops->set_efer(vcpu, efer);
-
- efer &= ~EFER_LMA;
- efer |= vcpu->shadow_efer & EFER_LMA;
-
- vcpu->shadow_efer = efer;
-}
-
-#endif
-
-int kvm_set_msr_common(struct kvm_vcpu *vcpu, u32 msr, u64 data)
-{
- switch (msr) {
-#ifdef CONFIG_X86_64
- case MSR_EFER:
- set_efer(vcpu, data);
- break;
-#endif
- case MSR_IA32_MC0_STATUS:
- pr_unimpl(vcpu, "%s: MSR_IA32_MC0_STATUS 0x%llx, nop\n",
- __FUNCTION__, data);
- break;
- case MSR_IA32_MCG_STATUS:
- pr_unimpl(vcpu, "%s: MSR_IA32_MCG_STATUS 0x%llx, nop\n",
- __FUNCTION__, data);
- break;
- case MSR_IA32_UCODE_REV:
- case MSR_IA32_UCODE_WRITE:
- case 0x200 ... 0x2ff: /* MTRRs */
- break;
- case MSR_IA32_APICBASE:
- kvm_set_apic_base(vcpu, data);
- break;
- case MSR_IA32_MISC_ENABLE:
- vcpu->ia32_misc_enable_msr = data;
- break;
- default:
- pr_unimpl(vcpu, "unhandled wrmsr: 0x%x\n", msr);
- return 1;
- }
- return 0;
-}
-EXPORT_SYMBOL_GPL(kvm_set_msr_common);
-
-/*
- * Writes msr value into into the appropriate "register".
- * Returns 0 on success, non-0 otherwise.
- * Assumes vcpu_load() was already called.
- */
-int kvm_set_msr(struct kvm_vcpu *vcpu, u32 msr_index, u64 data)
-{
- return kvm_x86_ops->set_msr(vcpu, msr_index, data);
-}
-
void kvm_resched(struct kvm_vcpu *vcpu)
{
if (!need_resched())
Index: kvm/drivers/kv
[kvm-devel] RFC/patch 0/3 portability: please review
Thanks to Xiantao and Hollis for your quick review of last patch series. Thanks Avi for finding time to pick up last patches on your trip to Japan. This series of patches moves more code from kvm_main.c to x86.c. I start seeing the light at the end of the tunnel, I think these should be the last big blocks that don't fit into kvm_main.c for s390. From here on, I think I will use a much smaller hammer to get all the details right. :-) Please review the patches to make sure nothing gets moved out that should be common. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] RFC/patch 3/3 portability: move pio emulation functions to x86.c
This patch moves implementation of the following functions from
kvm_main.c to x86.c:
free_pio_guest_pages, vcpu_find_pio_dev, pio_copy_data, complete_pio,
kernel_pio, pio_string_write, kvm_emulate_pio, kvm_emulate_pio_string
The function inject_gp, which was duplicated by yesterday's patch
series, is removed from kvm_main.c now because it is not needed anymore.
Signed-off-by: Carsten Otte <[EMAIL PROTECTED]>
---
kvm_main.c | 248 -
x86.c | 243 +++
x86.h |1
3 files changed, 244 insertions(+), 248 deletions(-)
Signed-off-by: Carsten Otte <[EMAIL PROTECTED]>
---
Index: kvm/drivers/kvm/kvm_main.c
===
--- kvm.orig/drivers/kvm/kvm_main.c 2007-10-30 18:27:56.0 +0100
+++ kvm/drivers/kvm/kvm_main.c 2007-10-30 18:30:48.0 +0100
@@ -271,17 +271,6 @@
kvm_free_physmem_slot(&kvm->memslots[i], NULL);
}
-static void free_pio_guest_pages(struct kvm_vcpu *vcpu)
-{
- int i;
-
- for (i = 0; i < ARRAY_SIZE(vcpu->pio.guest_pages); ++i)
- if (vcpu->pio.guest_pages[i]) {
- kvm_release_page(vcpu->pio.guest_pages[i]);
- vcpu->pio.guest_pages[i] = NULL;
- }
-}
-
static void kvm_unload_vcpu_mmu(struct kvm_vcpu *vcpu)
{
vcpu_load(vcpu);
@@ -330,11 +319,6 @@
return 0;
}
-static void inject_gp(struct kvm_vcpu *vcpu)
-{
- kvm_x86_ops->inject_gp(vcpu, 0);
-}
-
void fx_init(struct kvm_vcpu *vcpu)
{
unsigned after_mxcsr_mask;
@@ -817,12 +801,6 @@
}
}
-static struct kvm_io_device *vcpu_find_pio_dev(struct kvm_vcpu *vcpu,
- gpa_t addr)
-{
- return kvm_io_bus_find_dev(&vcpu->kvm->pio_bus, addr);
-}
-
/*
* The vCPU has executed a HLT instruction with in-kernel mode enabled.
*/
@@ -1032,232 +1010,6 @@
}
EXPORT_SYMBOL_GPL(kvm_emulate_cpuid);
-static int pio_copy_data(struct kvm_vcpu *vcpu)
-{
- void *p = vcpu->pio_data;
- void *q;
- unsigned bytes;
- int nr_pages = vcpu->pio.guest_pages[1] ? 2 : 1;
-
- q = vmap(vcpu->pio.guest_pages, nr_pages, VM_READ|VM_WRITE,
-PAGE_KERNEL);
- if (!q) {
- free_pio_guest_pages(vcpu);
- return -ENOMEM;
- }
- q += vcpu->pio.guest_page_offset;
- bytes = vcpu->pio.size * vcpu->pio.cur_count;
- if (vcpu->pio.in)
- memcpy(q, p, bytes);
- else
- memcpy(p, q, bytes);
- q -= vcpu->pio.guest_page_offset;
- vunmap(q);
- free_pio_guest_pages(vcpu);
- return 0;
-}
-
-static int complete_pio(struct kvm_vcpu *vcpu)
-{
- struct kvm_pio_request *io = &vcpu->pio;
- long delta;
- int r;
-
- kvm_x86_ops->cache_regs(vcpu);
-
- if (!io->string) {
- if (io->in)
- memcpy(&vcpu->regs[VCPU_REGS_RAX], vcpu->pio_data,
- io->size);
- } else {
- if (io->in) {
- r = pio_copy_data(vcpu);
- if (r) {
- kvm_x86_ops->cache_regs(vcpu);
- return r;
- }
- }
-
- delta = 1;
- if (io->rep) {
- delta *= io->cur_count;
- /*
-* The size of the register should really depend on
-* current address size.
-*/
- vcpu->regs[VCPU_REGS_RCX] -= delta;
- }
- if (io->down)
- delta = -delta;
- delta *= io->size;
- if (io->in)
- vcpu->regs[VCPU_REGS_RDI] += delta;
- else
- vcpu->regs[VCPU_REGS_RSI] += delta;
- }
-
- kvm_x86_ops->decache_regs(vcpu);
-
- io->count -= io->cur_count;
- io->cur_count = 0;
-
- return 0;
-}
-
-static void kernel_pio(struct kvm_io_device *pio_dev,
- struct kvm_vcpu *vcpu,
- void *pd)
-{
- /* TODO: String I/O for in kernel device */
-
- mutex_lock(&vcpu->kvm->lock);
- if (vcpu->pio.in)
- kvm_iodevice_read(pio_dev, vcpu->pio.port,
- vcpu->pio.size,
- pd);
- else
- kvm_iodevice_write(pio_dev, vcpu->pio.port,
- vcpu->pio.size,
- pd);
- mutex_unlock(&vcpu->kvm->lock);
-}
-
-stati
[kvm-devel] RFC/patch 2/3 portability: move x86 emulation and mmio device hook to x86.c
This patch moves the following functions to from kvm_main.c to x86.c:
emulator_read/write_std, vcpu_find_pervcpu_dev, vcpu_find_mmio_dev,
emulator_read/write_emulated, emulator_write_phys,
emulator_write_emulated_onepage, emulator_cmpxchg_emulated,
get_setment_base, emulate_invlpg, emulate_clts, emulator_get/set_dr,
kvm_report_emulation_failure, emulate_instruction
The following data type is moved to x86.c:
struct x86_emulate_ops emulate_ops
Signed-off-by: Carsten Otte <[EMAIL PROTECTED]>
---
kvm_main.c | 358
x86.c | 359 +
2 files changed, 359 insertions(+), 358 deletions(-)
Index: kvm/drivers/kvm/kvm_main.c
===
--- kvm.orig/drivers/kvm/kvm_main.c 2007-10-30 18:06:24.0 +0100
+++ kvm/drivers/kvm/kvm_main.c 2007-10-30 18:27:56.0 +0100
@@ -817,370 +817,12 @@
}
}
-int emulator_read_std(unsigned long addr,
-void *val,
-unsigned int bytes,
-struct kvm_vcpu *vcpu)
-{
- void *data = val;
-
- while (bytes) {
- gpa_t gpa = vcpu->mmu.gva_to_gpa(vcpu, addr);
- unsigned offset = addr & (PAGE_SIZE-1);
- unsigned tocopy = min(bytes, (unsigned)PAGE_SIZE - offset);
- int ret;
-
- if (gpa == UNMAPPED_GVA)
- return X86EMUL_PROPAGATE_FAULT;
- ret = kvm_read_guest(vcpu->kvm, gpa, data, tocopy);
- if (ret < 0)
- return X86EMUL_UNHANDLEABLE;
-
- bytes -= tocopy;
- data += tocopy;
- addr += tocopy;
- }
-
- return X86EMUL_CONTINUE;
-}
-EXPORT_SYMBOL_GPL(emulator_read_std);
-
-static int emulator_write_std(unsigned long addr,
- const void *val,
- unsigned int bytes,
- struct kvm_vcpu *vcpu)
-{
- pr_unimpl(vcpu, "emulator_write_std: addr %lx n %d\n", addr, bytes);
- return X86EMUL_UNHANDLEABLE;
-}
-
-/*
- * Only apic need an MMIO device hook, so shortcut now..
- */
-static struct kvm_io_device *vcpu_find_pervcpu_dev(struct kvm_vcpu *vcpu,
- gpa_t addr)
-{
- struct kvm_io_device *dev;
-
- if (vcpu->apic) {
- dev = &vcpu->apic->dev;
- if (dev->in_range(dev, addr))
- return dev;
- }
- return NULL;
-}
-
-static struct kvm_io_device *vcpu_find_mmio_dev(struct kvm_vcpu *vcpu,
- gpa_t addr)
-{
- struct kvm_io_device *dev;
-
- dev = vcpu_find_pervcpu_dev(vcpu, addr);
- if (dev == NULL)
- dev = kvm_io_bus_find_dev(&vcpu->kvm->mmio_bus, addr);
- return dev;
-}
-
static struct kvm_io_device *vcpu_find_pio_dev(struct kvm_vcpu *vcpu,
gpa_t addr)
{
return kvm_io_bus_find_dev(&vcpu->kvm->pio_bus, addr);
}
-static int emulator_read_emulated(unsigned long addr,
- void *val,
- unsigned int bytes,
- struct kvm_vcpu *vcpu)
-{
- struct kvm_io_device *mmio_dev;
- gpa_t gpa;
-
- if (vcpu->mmio_read_completed) {
- memcpy(val, vcpu->mmio_data, bytes);
- vcpu->mmio_read_completed = 0;
- return X86EMUL_CONTINUE;
- }
-
- gpa = vcpu->mmu.gva_to_gpa(vcpu, addr);
-
- /* For APIC access vmexit */
- if ((gpa & PAGE_MASK) == APIC_DEFAULT_PHYS_BASE)
- goto mmio;
-
- if (emulator_read_std(addr, val, bytes, vcpu)
- == X86EMUL_CONTINUE)
- return X86EMUL_CONTINUE;
- if (gpa == UNMAPPED_GVA)
- return X86EMUL_PROPAGATE_FAULT;
-
-mmio:
- /*
-* Is this MMIO handled locally?
-*/
- mmio_dev = vcpu_find_mmio_dev(vcpu, gpa);
- if (mmio_dev) {
- kvm_iodevice_read(mmio_dev, gpa, bytes, val);
- return X86EMUL_CONTINUE;
- }
-
- vcpu->mmio_needed = 1;
- vcpu->mmio_phys_addr = gpa;
- vcpu->mmio_size = bytes;
- vcpu->mmio_is_write = 0;
-
- return X86EMUL_UNHANDLEABLE;
-}
-
-static int emulator_write_phys(struct kvm_vcpu *vcpu, gpa_t gpa,
- const void *val, int bytes)
-{
- int ret;
-
- ret = kvm_write_guest(vcpu->kvm, gpa, val, bytes);
- if (ret < 0)
- return 0;
- kvm_mmu_pte_write(vcpu, gpa, val, bytes);
- return 1;
-}
-
-static int emulator_wr
Re: [kvm-devel] RFC/patch 0/3 portability: please review
Zhang, Xiantao wrote: > Basically, It doesn't impact our side. For patch 2/3, we had better find > an approach to handle mmio-realted functions, becasue they may exist in > most archs. > For IA64, if this move happens, we have to duplicate them in IA64 side. Thanks for your feedback. This matches Hollis' view, I'll try to rework that patch. We're really the only platform without mmio, that's a s390 special case. I'll leave it in common and find a way around for s390. cheers, Carsten - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] RFC/patch 0/3 portability: please review
Hollis Blanchard wrote: > On Tue, 2007-10-30 at 22:53 +0100, Carsten Otte wrote: >> Zhang, Xiantao wrote: >>> Basically, It doesn't impact our side. For patch 2/3, we had better find >>> an approach to handle mmio-realted functions, becasue they may exist in >>> most archs. >>> For IA64, if this move happens, we have to duplicate them in IA64 side. >> Thanks for your feedback. This matches Hollis' view, I'll try to >> rework that patch. We're really the only platform without mmio, that's >> a s390 special case. I'll leave it in common and find a way around for >> s390. > > Well, those functions right now are hacks that assume the only in-kernel > device is an APIC. That won't even build for anybody who doesn't have > vcpu->apic... that's why I say go ahead and move them, and we can worry > about it later. Right. Xiantao, does ia64 have an apic? Or do you intend to use the code different from x86? - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] RFC/patch portability: split kvm_vm_ioctl v3
Dong, Eddie wrote: >> BTW, why we use vector here? shouldn't it be irq_line or irq_no? > > Maybe you mean the Channel Subsystem (1st piece of knowledge and > surprise known from s390 doc) are emulated in Qemu, correct? The vector field was introduced by Avi's comment. I just copied that over. On s390, we only have irq numbers, no vectors. For now, we don't want to emulate the channel subsystem, just paravirt. Technically, we could do a passthrough in the long term just like pci devices can be dedicated to a guest using an iommu in the memory mapped I/O world. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] RFC/patch portability: split kvm_vm_ioctl v3
Arnd Bergmann wrote: > On Monday 05 November 2007, Carsten Otte wrote: >> Dong, Eddie wrote: >>>> BTW, why we use vector here? shouldn't it be irq_line or irq_no? >>> Maybe you mean the Channel Subsystem (1st piece of knowledge and >>> surprise known from s390 doc) are emulated in Qemu, correct? >> The vector field was introduced by Avi's comment. I just copied that >> over. >> On s390, we only have irq numbers, no vectors. > > Actually, you have neither irq numbers nor vectors on s390 right now. > I/O subchannels are do not fit into the IRQ handling in Linux at > all, and external interrupts are sufficiently different that you > should not treat them as IRQ lines in Linux. We're not emulating the I/O subsystem, and thus no I/O subchannels. > However, I would suggest that you use either one external interrupt or > the "thin" interrupt as an event source for an interrupt controller for > all the virtio devices, and use the generic IRQ subsystem for that, > including interrupt lines and vectors. > > In case of the thin interrupt, your virtual interrupt controller would > more or less just consist of one lowcore address from which you can > read the pending interrupt vector after an interrupt has been caused, > as well as a single hcall that does a 'acknowledge interrupt, get > next pending irq vector into lowcore and tell me whether there was > one' operation. > > You'll also need an operation to associate a virtio device with an > interrupt vector, but that belongs into virtio. The irq subsystem does not fit the external interrupt model, and you'd definitely want to argue with Martin before suggesting to introduce the IRQ subsystem on s390. "Only over my dead body" was the last statement I do remember. Plus I don't see a benefit from pretending to have an interrupt controller: virtio abstracts from this, and can well be implemented over extint and hypercall like Christian has done it. What's the problem you're trying to solve? - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] A question about virtio and KVM
Christian Borntraeger wrote: >> It is not yet updated to latest virtio & latest kvm. >> This version uses a pci device for virtio. Since I'm think Rusty's >> config space does not matches >> pci config space I might consider changing it. (Preferably not, maybe >> I'll start using it until we'll have the windows >> implementation). >> I'll start work on it on Sunday. > > I currently try to use Rusty's config space as we dont have a PCI bus. > Carsten told me that HPA suggested to split CONFIG_PCI in a way to use > the hardware independent data structures without providing the hardware. > > Carsten do you still remember the full details? *Shrug*. I think Peter suggested that we'd use a PCI bus type, and PCI IDs for device identification. We're not going to use PCI to do I/O, and we're not going to use IRQ (HPA: irq == 0 is a valid value, which means that the PCI device does not have an irq). He suggested to look at the virtio bus that he contributed to Rusty's lguest code as an example. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [Patch]1/5 Move some includes to x86, since the related functions have been moved to x86.c
Acked-by: Carsten Otte <[EMAIL PROTECTED]> Zhang, Xiantao wrote: > From fc56bda0f599ccd00d992bf196654101e82d1413 Mon Sep 17 00:00:00 2001 > From: Zhang Xiantao <[EMAIL PROTECTED]> > Date: Wed, 7 Nov 2007 11:39:23 +0800 > Subject: [PATCH] move some header files form kvm_main.c to x86.c, since > the > related functions have been moved to x86.c > Signed-off-by: Zhang Xiantao <[EMAIL PROTECTED]> > --- > drivers/kvm/kvm_main.c |2 -- > drivers/kvm/x86.c |2 ++ > 2 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/kvm/kvm_main.c b/drivers/kvm/kvm_main.c > index 0b8edca..010f079 100644 > --- a/drivers/kvm/kvm_main.c > +++ b/drivers/kvm/kvm_main.c > @@ -17,7 +17,6 @@ > > #include "kvm.h" > #include "x86.h" > -#include "x86_emulate.h" > #include "irq.h" > > #include > @@ -44,7 +43,6 @@ > #include > > #include > -#include > #include > #include > #include > diff --git a/drivers/kvm/x86.c b/drivers/kvm/x86.c > index e905d46..7ea470e 100644 > --- a/drivers/kvm/x86.c > +++ b/drivers/kvm/x86.c > @@ -16,6 +16,7 @@ > > #include "kvm.h" > #include "x86.h" > +#include "x86_emulate.h" > #include "segment_descriptor.h" > #include "irq.h" > > @@ -25,6 +26,7 @@ > #include > > #include > +#include > > #define MAX_IO_MSRS 256 > #define CR0_RESERVED_BITS > \ - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH]0/5 Patch to split x86 specific code from kvm_main.c
Zhang, Xiantao wrote: > This series of patches are intended to further split x86 specific code > from kvm_main.c, and make kvm_main.c arch-independent. > For easy review, I splitted them into small patches. With these patches, > we almost finish the first stage work for code split. These patches don't apply on top of my git tree: Wende Patch 01-xiantao.patch an patching file drivers/kvm/kvm_main.c Hunk #1 succeeded at 17 with fuzz 2. Hunk #2 succeeded at 43 with fuzz 2. patching file drivers/kvm/x86.c Hunk #1 succeeded at 16 with fuzz 1. Hunk #2 FAILED at 26. 1 out of 2 hunks FAILED -- rejects in file drivers/kvm/x86.c - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] 2/5 mov kvm_x86_ops to x86.c
Acked-by: Carsten Otte <[EMAIL PROTECTED]>
Zhang, Xiantao wrote:
> From 7473192cc0c529b8ce35c13d0e83a9b663072831 Mon Sep 17 00:00:00 2001
> From: Zhang Xiantao <[EMAIL PROTECTED]>
> Date: Wed, 7 Nov 2007 11:41:50 +0800
> Subject: [PATCH] mov kvm_x86_ops to x86.c for next step's work
> Signed-off-by: Zhang Xiantao <[EMAIL PROTECTED]>
> ---
> drivers/kvm/kvm_main.c |1 -
> drivers/kvm/x86.c |2 ++
> drivers/kvm/x86.h |2 ++
> 3 files changed, 4 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/kvm/kvm_main.c b/drivers/kvm/kvm_main.c
> index 010f079..f1cf8f0 100644
> --- a/drivers/kvm/kvm_main.c
> +++ b/drivers/kvm/kvm_main.c
> @@ -55,7 +55,6 @@ static LIST_HEAD(vm_list);
>
> static cpumask_t cpus_hardware_enabled;
>
> -struct kvm_x86_ops *kvm_x86_ops;
> struct kmem_cache *kvm_vcpu_cache;
> EXPORT_SYMBOL_GPL(kvm_vcpu_cache);
>
> diff --git a/drivers/kvm/x86.c b/drivers/kvm/x86.c
> index 7ea470e..e26e46a 100644
> --- a/drivers/kvm/x86.c
> +++ b/drivers/kvm/x86.c
> @@ -44,6 +44,8 @@
>
> #define STAT_OFFSET(x) offsetof(struct kvm_vcpu, stat.x)
>
> +struct kvm_x86_ops *kvm_x86_ops;
> +
> struct kvm_stats_debugfs_item debugfs_entries[] = {
> { "pf_fixed", STAT_OFFSET(pf_fixed) },
> { "pf_guest", STAT_OFFSET(pf_guest) },
> diff --git a/drivers/kvm/x86.h b/drivers/kvm/x86.h
> index 663b822..ec32c26 100644
> --- a/drivers/kvm/x86.h
> +++ b/drivers/kvm/x86.h
> @@ -85,6 +85,8 @@ struct kvm_vcpu {
> struct x86_emulate_ctxt emulate_ctxt;
> };
>
> +extern struct kvm_x86_ops *kvm_x86_ops;
> +
> int kvm_mmu_page_fault(struct kvm_vcpu *vcpu, gva_t gva, u32
> error_code);
>
> static inline void kvm_mmu_free_some_pages(struct kvm_vcpu *vcpu)
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] 4/5 Combine kvm_init and kvm_init_x86 intoonefunction (Correction V3)
I agree with the gernal idea of this patch. Just a few minor things to
pick on:
Zhang, Xiantao wrote:
> diff --git a/drivers/kvm/kvm.h b/drivers/kvm/kvm.h
> index 4b2421a..33b4629 100644
> --- a/drivers/kvm/kvm.h
> +++ b/drivers/kvm/kvm.h
> @@ -494,9 +494,9 @@ void vcpu_load(struct kvm_vcpu *vcpu);
> void vcpu_put(struct kvm_vcpu *vcpu);
>
>
> -int kvm_init_x86(struct kvm_x86_ops *ops, unsigned int vcpu_size,
> +int kvm_init(struct kvm_x86_ops *ops, unsigned int vcpu_size,
> struct module *module);
> -void kvm_exit_x86(void);
> +void kvm_exit(void);
Renaming this makes sense to me.
> + r = kvm_mmu_module_init();
> + if (r)
> + goto out4;
This should go to kvm_arch_init. We don't want the shaddow-mmu module
on s390.
> + bad_page = alloc_page(GFP_KERNEL | __GFP_ZERO);
> +
> + if (bad_page == NULL) {
> + r = -ENOMEM;
> + goto out;
> + }
I don't think we need bad_page on s390, maybe I missed something. It's
only useful for mmu code as far as I can tell.
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH]3/5 Using kvm_arch prefix to define functions, and replace
Zhang, Xiantao wrote: > +void kvm_arch_vcpu_free(struct kvm_vcpu *vcpu); > +void kvm_arch_vcpu_decache(struct kvm_vcpu *vcpu); > +void kvm_arch_vcpu_load(struct kvm_vcpu *vcpu, int cpu); > +void kvm_arch_vcpu_put(struct kvm_vcpu *vcpu); > +struct kvm_vcpu *kvm_arch_vcpu_create(struct kvm *kvm, unsigned int > id); > + > +int kvm_arch_vcpu_reset(struct kvm_vcpu *vcpu); > +void kvm_arch_hardware_enable(void *garbage); > +void kvm_arch_hardware_disable(void *garbage); > +int kvm_arch_hardware_setup(void); > +void kvm_arch_hardware_unsetup(void); > +void kvm_arch_check_processor_compat(void *rtn); I don't like the generic introduction of all x86_ops wrappers into the arch callbacks. I would rather prefer to work out a different split between common and arch specifics - at least in the following cases: - unloading the mmu needs to be moved out of kvm_free_vcpus into the arch part, because we don't have a shaddow mmu on s390 - decache_vcpus_on_cpu should be arch-dependent alltogether, rather than having a per cpu callback. We've got nothing to decache, so the entire thing is a nop for us. - vcpu_reset works very different for our architecture, we'd need an initial processor status word. I'd prefer to keep the existence of this callback arch dependent. - hardware enable/disable/setup/unsetup/check_processor_compat does not make any sense for us: all CPUs that have been sold since the 1970s have proper hardware virtualization, and there's nothing to enable - it just works. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] 5/5 Make kvm_init as arch-indepenent
Acked-by: Carsten Otte <[EMAIL PROTECTED]>
Zhang, Xiantao wrote:
>>From 2d6ee07b96f1a91cef9327f241077af3698ed4dc Mon Sep 17 00:00:00 2001
> From: Zhang Xiantao <[EMAIL PROTECTED]>
> Date: Thu, 8 Nov 2007 13:37:38 +0800
> Subject: [PATCH] Make kvm_init as arch-indepenent, through defining a
> void
> pointer type variable. All archs will register their corresponding arch
> functions
> into kvm module. For example, x86 will use it to register vmx/svm's ops.
> Signed-off-by: Zhang Xiantao <[EMAIL PROTECTED]>
> ---
> drivers/kvm/kvm.h |5 +++--
> drivers/kvm/kvm_main.c | 26 ++
> drivers/kvm/x86.c | 27 ++-
> 3 files changed, 35 insertions(+), 23 deletions(-)
>
> diff --git a/drivers/kvm/kvm.h b/drivers/kvm/kvm.h
> index 33b4629..9b6087f 100644
> --- a/drivers/kvm/kvm.h
> +++ b/drivers/kvm/kvm.h
> @@ -494,7 +494,7 @@ void vcpu_load(struct kvm_vcpu *vcpu);
> void vcpu_put(struct kvm_vcpu *vcpu);
>
>
> -int kvm_init(struct kvm_x86_ops *ops, unsigned int vcpu_size,
> +int kvm_init(void *opaque, unsigned int vcpu_size,
> struct module *module);
> void kvm_exit(void);
>
> @@ -647,7 +647,8 @@ int kvm_arch_vcpu_ioctl_debug_guest(struct kvm_vcpu
> *vcpu,
> struct kvm_debug_guest *dbg);
> int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu, struct kvm_run
> *kvm_run);
>
> -__init void kvm_arch_init(void);
> +int kvm_arch_init(void *opaque);
> +void kvm_arch_exit(void);
>
>
> void kvm_arch_vcpu_free(struct kvm_vcpu *vcpu);
> diff --git a/drivers/kvm/kvm_main.c b/drivers/kvm/kvm_main.c
> index 8f09170..70bc4d4 100644
> --- a/drivers/kvm/kvm_main.c
> +++ b/drivers/kvm/kvm_main.c
> @@ -1503,7 +1503,7 @@ static void kvm_sched_out(struct preempt_notifier
> *pn,
> kvm_arch_vcpu_put(vcpu);
> }
>
> -int kvm_init(struct kvm_x86_ops *ops, unsigned int vcpu_size,
> +int kvm_init(void *opaque, unsigned int vcpu_size,
> struct module *module)
> {
> int r;
> @@ -1515,7 +1515,9 @@ int kvm_init(struct kvm_x86_ops *ops, unsigned int
> vcpu_size,
>
> kvm_init_debug();
>
> - kvm_arch_init();
> + r = kvm_arch_init(opaque);
> + if (r)
> + goto out4;
>
> bad_page = alloc_page(GFP_KERNEL | __GFP_ZERO);
>
> @@ -1524,22 +1526,6 @@ int kvm_init(struct kvm_x86_ops *ops, unsigned
> int vcpu_size,
> goto out;
> }
>
> - if (kvm_x86_ops) {
> - printk(KERN_ERR "kvm: already loaded the other
> module\n");
> - return -EEXIST;
> - }
> -
> - if (!ops->cpu_has_kvm_support()) {
> - printk(KERN_ERR "kvm: no hardware support\n");
> - return -EOPNOTSUPP;
> - }
> - if (ops->disabled_by_bios()) {
> - printk(KERN_ERR "kvm: disabled by bios\n");
> - return -EOPNOTSUPP;
> - }
> -
> - kvm_x86_ops = ops;
> -
> r = kvm_arch_hardware_setup();
> if (r < 0)
> goto out;
> @@ -1603,7 +1589,7 @@ out_free_1:
> out_free_0:
> kvm_arch_hardware_unsetup();
> out:
> - kvm_x86_ops = NULL;
> + kvm_arch_exit();
> kvm_exit_debug();
> kvm_mmu_module_exit();
> out4:
> @@ -1621,7 +1607,7 @@ void kvm_exit(void)
> unregister_cpu_notifier(&kvm_cpu_notifier);
> on_each_cpu(hardware_disable, NULL, 0, 1);
> kvm_arch_hardware_unsetup();
> - kvm_x86_ops = NULL;
> + kvm_arch_exit();
> kvm_exit_debug();
> __free_page(bad_page);
> kvm_mmu_module_exit();
> diff --git a/drivers/kvm/x86.c b/drivers/kvm/x86.c
> index 8aea240..22b3cc6 100644
> --- a/drivers/kvm/x86.c
> +++ b/drivers/kvm/x86.c
> @@ -1611,9 +1611,34 @@ int kvm_emulate_pio_string(struct kvm_vcpu *vcpu,
> struct kvm_run *run, int in,
> }
> EXPORT_SYMBOL_GPL(kvm_emulate_pio_string);
>
> -__init void kvm_arch_init(void)
> +int kvm_arch_init(void *opaque)
> {
> + struct kvm_x86_ops *ops = (struct kvm_x86_ops *)opaque;
> +
> kvm_init_msr_list();
> +
> + if (kvm_x86_ops) {
> + printk(KERN_ERR "kvm: already loaded the other
> module\n");
> + return -EEXIST;
> + }
> +
> + if (!ops->cpu_has_kvm_support()) {
> + printk(KERN_ERR "kvm: no hardware support\n");
> + return -EOPNOTSUPP;
> + }
> + if (ops->disabled_by_bios()) {
> + printk(KERN_ERR "kvm: disabled by bios\n");
> + retu
Re: [kvm-devel] [PATCH]3/5 Using kvm_arch prefix to define functions, and replace
Hollis Blanchard wrote: > On Thu, 2007-11-08 at 14:49 +0100, Carsten Otte wrote: >> Zhang, Xiantao wrote: >>> +void kvm_arch_vcpu_free(struct kvm_vcpu *vcpu); >>> +void kvm_arch_vcpu_decache(struct kvm_vcpu *vcpu); >>> +void kvm_arch_vcpu_load(struct kvm_vcpu *vcpu, int cpu); >>> +void kvm_arch_vcpu_put(struct kvm_vcpu *vcpu); >>> +struct kvm_vcpu *kvm_arch_vcpu_create(struct kvm *kvm, unsigned int >>> id); >>> + >>> +int kvm_arch_vcpu_reset(struct kvm_vcpu *vcpu); >>> +void kvm_arch_hardware_enable(void *garbage); >>> +void kvm_arch_hardware_disable(void *garbage); >>> +int kvm_arch_hardware_setup(void); >>> +void kvm_arch_hardware_unsetup(void); >>> +void kvm_arch_check_processor_compat(void *rtn); >> I don't like the generic introduction of all x86_ops wrappers into the >> arch callbacks. I would rather prefer to work out a different split >> between common and arch specifics - at least in the following cases: >> - unloading the mmu needs to be moved out of kvm_free_vcpus into the >> arch part, because we don't have a shaddow mmu on s390 >> - decache_vcpus_on_cpu should be arch-dependent alltogether, rather >> than having a per cpu callback. We've got nothing to decache, so the >> entire thing is a nop for us. >> - vcpu_reset works very different for our architecture, we'd need an >> initial processor status word. I'd prefer to keep the existence of >> this callback arch dependent. >> - hardware enable/disable/setup/unsetup/check_processor_compat does not >> make any sense for us: all CPUs that have been sold since the 1970s have >> proper hardware virtualization, and there's nothing to enable - it just >> works. > > Sounds fine to me: you're just proposing to move the abstraction one > level higher in some places. That's right, I'd like to drag the bar a little where the common code does something just to call a callback that is nop for us. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] IA64 KVM
Zhang, Xiantao wrote: >Thanks for your suggestions. It is a surely good idea to create a > IA64 mailing list to talk about the IA64-KVM. But now we have to rebase > them to latest commits before sending out, since the kvm source layout > changed much recently. Once the final source layout comes out, we will > send out the source code soon. I believe it should happen in very near > future. :-) I think this makes sense: we're shuffling the code around too much at the moment. It would be a big burden to have to keep the port up-to-date while doing that. We'll soon be done with our portability split, and I am sure Xiantao will be one of the first to present a port. Nevertheless, Akio, Alex and Caleb you're highly welcome to participate in the review process of our joined protability work to make sure we get everything right for ia64. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH]3/5 Using kvm_arch prefix to define functions, and replace
Avi Kivity wrote:
> For the present discussion, I agree, but in general we should be
> prepared to accept some no-op callouts.
Oh sure, I don't mind those. We'll have plenty of them, where other
architectures will need to take action and s390 won't. It's just that
in the current location, the common code would do
common_func() {
loop {
arch_callback();
}
}
And I suggested to make the whole thing a callback.
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] 2/5 move kvm_x86_ops to x86.c
Acked-by: Carsten Otte <[EMAIL PROTECTED]>
Zhang, Xiantao wrote:
> From: Zhang Xiantao <[EMAIL PROTECTED]>
> Move kvm_x86_ops to x86.c
> Signed-off-by: Zhang Xiantao <[EMAIL PROTECTED]>
> ---
> drivers/kvm/kvm_main.c |1 -
> drivers/kvm/x86.c |2 ++
> drivers/kvm/x86.h |2 ++
> 3 files changed, 4 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/kvm/kvm_main.c b/drivers/kvm/kvm_main.c
> index 3a72f58..71a3b7a 100644
> --- a/drivers/kvm/kvm_main.c
> +++ b/drivers/kvm/kvm_main.c
> @@ -55,7 +55,6 @@ static LIST_HEAD(vm_list);
>
> static cpumask_t cpus_hardware_enabled;
>
> -struct kvm_x86_ops *kvm_x86_ops;
> struct kmem_cache *kvm_vcpu_cache;
> EXPORT_SYMBOL_GPL(kvm_vcpu_cache);
>
> diff --git a/drivers/kvm/x86.c b/drivers/kvm/x86.c
> index 2fa4f13..92c0988 100644
> --- a/drivers/kvm/x86.c
> +++ b/drivers/kvm/x86.c
> @@ -44,6 +44,8 @@
>
> #define STAT_OFFSET(x) offsetof(struct kvm_vcpu, stat.x)
>
> +struct kvm_x86_ops *kvm_x86_ops;
> +
> struct kvm_stats_debugfs_item debugfs_entries[] = {
> { "pf_fixed", STAT_OFFSET(pf_fixed) },
> { "pf_guest", STAT_OFFSET(pf_guest) },
> diff --git a/drivers/kvm/x86.h b/drivers/kvm/x86.h
> index 663b822..ec32c26 100644
> --- a/drivers/kvm/x86.h
> +++ b/drivers/kvm/x86.h
> @@ -85,6 +85,8 @@ struct kvm_vcpu {
> struct x86_emulate_ctxt emulate_ctxt;
> };
>
> +extern struct kvm_x86_ops *kvm_x86_ops;
> +
> int kvm_mmu_page_fault(struct kvm_vcpu *vcpu, gva_t gva, u32
> error_code);
>
> static inline void kvm_mmu_free_some_pages(struct kvm_vcpu *vcpu)
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] 1/5 Move some includes to x86.c from kvm_main.c, since the related functions have been moved to x86.c
*Ouch*. Looks like I caused that. Very good. Acked-by: Carsten Otte <[EMAIL PROTECTED]> Zhang, Xiantao wrote: > From: Zhang Xiantao <[EMAIL PROTECTED]> > Move some includes to x86.c from kvm_main.c, since the related functions > have been moved to x86.c > Signed-off-by: Zhang Xiantao <[EMAIL PROTECTED]> > --- > drivers/kvm/kvm_main.c |2 -- > drivers/kvm/x86.c |2 ++ > 2 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/kvm/kvm_main.c b/drivers/kvm/kvm_main.c > index fb939ab..3a72f58 100644 > --- a/drivers/kvm/kvm_main.c > +++ b/drivers/kvm/kvm_main.c > @@ -17,7 +17,6 @@ > > #include "kvm.h" > #include "x86.h" > -#include "x86_emulate.h" > #include "irq.h" > > #include > @@ -44,7 +43,6 @@ > #include > > #include > -#include > #include > #include > #include > diff --git a/drivers/kvm/x86.c b/drivers/kvm/x86.c > index aa6c3d8..2fa4f13 100644 > --- a/drivers/kvm/x86.c > +++ b/drivers/kvm/x86.c > @@ -16,6 +16,7 @@ > > #include "kvm.h" > #include "x86.h" > +#include "x86_emulate.h" > #include "segment_descriptor.h" > #include "irq.h" > > @@ -25,6 +26,7 @@ > #include > > #include > +#include > > #define MAX_IO_MSRS 256 > #define CR0_RESERVED_BITS > \ - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [Patch]0/5 Rebase to latest commits V2
Zhang, Xiantao wrote: > I rebased this series of patches to further split kvm_main.c. In > this version, I mainly improved the 3th patch, and make > kvm_arch_vcpu_create to hold more logics according to community's > response. Thanks Hollis and Carsteno for Acks. :) Hi Xiantao, these patches don't apply after saving from the mailer. Could you please send them attached so that we can look at how it comes out after the patches applied? thanks, Carsten - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH]4/5 Combine kvm_init and kvm_init_x86
Acked-by: Carsten Otte <[EMAIL PROTECTED]>
Zhang, Xiantao wrote:
> From: Zhang Xiantao <[EMAIL PROTECTED]>
> Combine kvm_init and kvm_init_x86 into one function, and will be called
> when arch register.
> Signed-off-by: Zhang Xiantao <[EMAIL PROTECTED]>
> ---
> drivers/kvm/kvm.h |4 +-
> drivers/kvm/kvm_main.c | 61
> +--
> drivers/kvm/svm.c |4 +-
> drivers/kvm/vmx.c |4 +-
> 4 files changed, 28 insertions(+), 45 deletions(-)
>
> diff --git a/drivers/kvm/kvm.h b/drivers/kvm/kvm.h
> index 6c797ea..6e1bf8c 100644
> --- a/drivers/kvm/kvm.h
> +++ b/drivers/kvm/kvm.h
> @@ -493,9 +493,9 @@ void vcpu_load(struct kvm_vcpu *vcpu);
> void vcpu_put(struct kvm_vcpu *vcpu);
>
>
> -int kvm_init_x86(struct kvm_x86_ops *ops, unsigned int vcpu_size,
> +int kvm_init(struct kvm_x86_ops *ops, unsigned int vcpu_size,
> struct module *module);
> -void kvm_exit_x86(void);
> +void kvm_exit(void);
>
> int kvm_mmu_module_init(void);
> void kvm_mmu_module_exit(void);
> diff --git a/drivers/kvm/kvm_main.c b/drivers/kvm/kvm_main.c
> index 6a109e8..ae7ee77 100644
> --- a/drivers/kvm/kvm_main.c
> +++ b/drivers/kvm/kvm_main.c
> @@ -1470,11 +1470,26 @@ static void kvm_sched_out(struct
> preempt_notifier *pn,
> kvm_arch_vcpu_put(vcpu);
> }
>
> -int kvm_init_x86(struct kvm_x86_ops *ops, unsigned int vcpu_size,
> +int kvm_init(struct kvm_x86_ops *ops, unsigned int vcpu_size,
> struct module *module)
> {
> int r;
> int cpu;
> +
> + r = kvm_mmu_module_init();
> + if (r)
> + goto out4;
> +
> + kvm_init_debug();
> +
> + kvm_arch_init();
> +
> + bad_page = alloc_page(GFP_KERNEL | __GFP_ZERO);
> +
> + if (bad_page == NULL) {
> + r = -ENOMEM;
> + goto out;
> + }
>
> if (kvm_x86_ops) {
> printk(KERN_ERR "kvm: already loaded the other
> module\n");
> @@ -1556,11 +1571,14 @@ out_free_0:
> kvm_arch_hardware_unsetup();
> out:
> kvm_x86_ops = NULL;
> + kvm_exit_debug();
> + kvm_mmu_module_exit();
> +out4:
> return r;
> }
> -EXPORT_SYMBOL_GPL(kvm_init_x86);
> +EXPORT_SYMBOL_GPL(kvm_init);
>
> -void kvm_exit_x86(void)
> +void kvm_exit(void)
> {
> misc_deregister(&kvm_dev);
> kmem_cache_destroy(kvm_vcpu_cache);
> @@ -1571,43 +1589,8 @@ void kvm_exit_x86(void)
> on_each_cpu(hardware_disable, NULL, 0, 1);
> kvm_arch_hardware_unsetup();
> kvm_x86_ops = NULL;
> -}
> -EXPORT_SYMBOL_GPL(kvm_exit_x86);
> -
> -static __init int kvm_init(void)
> -{
> - int r;
> -
> - r = kvm_mmu_module_init();
> - if (r)
> - goto out4;
> -
> - kvm_init_debug();
> -
> - kvm_arch_init();
> -
> - bad_page = alloc_page(GFP_KERNEL | __GFP_ZERO);
> -
> - if (bad_page == NULL) {
> - r = -ENOMEM;
> - goto out;
> - }
> -
> - return 0;
> -
> -out:
> - kvm_exit_debug();
> - kvm_mmu_module_exit();
> -out4:
> - return r;
> -}
> -
> -static __exit void kvm_exit(void)
> -{
> kvm_exit_debug();
> __free_page(bad_page);
> kvm_mmu_module_exit();
> }
> -
> -module_init(kvm_init)
> -module_exit(kvm_exit)
> +EXPORT_SYMBOL_GPL(kvm_exit);
> diff --git a/drivers/kvm/svm.c b/drivers/kvm/svm.c
> index f54b2ea..11a0010 100644
> --- a/drivers/kvm/svm.c
> +++ b/drivers/kvm/svm.c
> @@ -1722,13 +1722,13 @@ static struct kvm_x86_ops svm_x86_ops = {
>
> static int __init svm_init(void)
> {
> - return kvm_init_x86(&svm_x86_ops, sizeof(struct vcpu_svm),
> + return kvm_init(&svm_x86_ops, sizeof(struct vcpu_svm),
> THIS_MODULE);
> }
>
> static void __exit svm_exit(void)
> {
> - kvm_exit_x86();
> + kvm_exit();
> }
>
> module_init(svm_init)
> diff --git a/drivers/kvm/vmx.c b/drivers/kvm/vmx.c
> index 0f48d23..ecb98c1 100644
> --- a/drivers/kvm/vmx.c
> +++ b/drivers/kvm/vmx.c
> @@ -2623,7 +2623,7 @@ static int __init vmx_init(void)
> memset(iova, 0xff, PAGE_SIZE);
> kunmap(vmx_io_bitmap_b);
>
> - r = kvm_init_x86(&vmx_x86_ops, sizeof(struct vcpu_vmx),
> THIS_MODULE);
> + r = kvm_init(&vmx_x86_ops, sizeof(struct vcpu_vmx),
> THIS_MODULE);
> if (r)
> goto out1;
>
> @@ -2644,7 +2644,7 @@ static void __exit vmx_exit(void)
> __free_page(vmx_io_bitmap_b);
> __free_page(vmx_io_bitmap_a);
>
> - kvm_exit_x86();
> + kvm_exit();
> }
>
> module_init(vmx_init)
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] Move KVM_CHECK_EXTENSIONMove case to arch
Zhang, Xiantao wrote: > Moving KVM_CHECK_EXTENSION case to arch, since different archs should > have different capabilities. Acked-by: Carsten Otte <[EMAIL PROTECTED]> - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] Move KVM_CHECK_EXTENSIONMove case to arch
Zhang, Xiantao wrote: > Moving KVM_CHECK_EXTENSION case to arch, since different archs should > have different capabilities. I believe we want to keep the existence of the ioctl KVM_CHECK_EXTENSION common. Just the extension flags should be arch specific. This patch has the danger, that we might end up with architectures that don't have KVM_CHECK_EXTENSION at all. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] 3/5 Using kvm arch support instead of kvm_x86_ops
I still do strongly agree with the general idea of this patch, and most of the split comes out just right now. However, there is one thing I'd like to pick on: decache_vcpus_on_cpu should be an arch callback, and rather than kvm_arch_vcpu_decache. There's no reason for s390 to grab locks and do the arch callback in a loop. The whole thing is nop for us, thus the whole thing should be a callback. I'd really like to see this changed before the patch gets merged. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] 5/5 Move-some-x86-specific-part-from-kvm_init-to-kvm_arch
I think two other functionalities need to be moved to kvm_arch_init
which are still in common: The call to kvm_mmu_set_nonpresent_ptes()
and the creation of kvm_vcpu_cache. This can well be done after
merging this patch. kvm_init looks very much cleaned up now, well done
Xiantao :-).
Acked-by: Carsten Otte <[EMAIL PROTECTED]>
Zhang, Xiantao wrote:
> From: Zhang Xiantao <[EMAIL PROTECTED]>
> Move-some-x86-specific-part-from-kvm_init-to-kvm_arch
> Signed-off-by: Zhang Xiantao <[EMAIL PROTECTED]>
> ---
> drivers/kvm/kvm.h |5 +++--
> drivers/kvm/kvm_main.c | 26 ++
> drivers/kvm/x86.c | 27 ++-
> 3 files changed, 35 insertions(+), 23 deletions(-)
>
> diff --git a/drivers/kvm/kvm.h b/drivers/kvm/kvm.h
> index 6e1bf8c..5162d29 100644
> --- a/drivers/kvm/kvm.h
> +++ b/drivers/kvm/kvm.h
> @@ -493,7 +493,7 @@ void vcpu_load(struct kvm_vcpu *vcpu);
> void vcpu_put(struct kvm_vcpu *vcpu);
>
>
> -int kvm_init(struct kvm_x86_ops *ops, unsigned int vcpu_size,
> +int kvm_init(void *opaque, unsigned int vcpu_size,
> struct module *module);
> void kvm_exit(void);
>
> @@ -647,7 +647,8 @@ int kvm_arch_vcpu_ioctl_debug_guest(struct kvm_vcpu
> *vcpu,
> struct kvm_debug_guest *dbg);
> int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu, struct kvm_run
> *kvm_run);
>
> -__init void kvm_arch_init(void);
> +int kvm_arch_init(void *opaque);
> +void kvm_arch_exit(void);
>
> int kvm_arch_vcpu_init(struct kvm_vcpu *vcpu);
> void kvm_arch_vcpu_uninit(struct kvm_vcpu *vcpu);
> diff --git a/drivers/kvm/kvm_main.c b/drivers/kvm/kvm_main.c
> index ae7ee77..1594e48 100644
> --- a/drivers/kvm/kvm_main.c
> +++ b/drivers/kvm/kvm_main.c
> @@ -1470,7 +1470,7 @@ static void kvm_sched_out(struct preempt_notifier
> *pn,
> kvm_arch_vcpu_put(vcpu);
> }
>
> -int kvm_init(struct kvm_x86_ops *ops, unsigned int vcpu_size,
> +int kvm_init(void *opaque, unsigned int vcpu_size,
> struct module *module)
> {
> int r;
> @@ -1482,7 +1482,9 @@ int kvm_init(struct kvm_x86_ops *ops, unsigned int
> vcpu_size,
>
> kvm_init_debug();
>
> - kvm_arch_init();
> + r = kvm_arch_init(opaque);
> + if (r)
> + goto out4;
>
> bad_page = alloc_page(GFP_KERNEL | __GFP_ZERO);
>
> @@ -1491,22 +1493,6 @@ int kvm_init(struct kvm_x86_ops *ops, unsigned
> int vcpu_size,
> goto out;
> }
>
> - if (kvm_x86_ops) {
> - printk(KERN_ERR "kvm: already loaded the other
> module\n");
> - return -EEXIST;
> - }
> -
> - if (!ops->cpu_has_kvm_support()) {
> - printk(KERN_ERR "kvm: no hardware support\n");
> - return -EOPNOTSUPP;
> - }
> - if (ops->disabled_by_bios()) {
> - printk(KERN_ERR "kvm: disabled by bios\n");
> - return -EOPNOTSUPP;
> - }
> -
> - kvm_x86_ops = ops;
> -
> r = kvm_arch_hardware_setup();
> if (r < 0)
> goto out;
> @@ -1570,7 +1556,7 @@ out_free_1:
> out_free_0:
> kvm_arch_hardware_unsetup();
> out:
> - kvm_x86_ops = NULL;
> + kvm_arch_exit();
> kvm_exit_debug();
> kvm_mmu_module_exit();
> out4:
> @@ -1588,7 +1574,7 @@ void kvm_exit(void)
> unregister_cpu_notifier(&kvm_cpu_notifier);
> on_each_cpu(hardware_disable, NULL, 0, 1);
> kvm_arch_hardware_unsetup();
> - kvm_x86_ops = NULL;
> + kvm_arch_exit();
> kvm_exit_debug();
> __free_page(bad_page);
> kvm_mmu_module_exit();
> diff --git a/drivers/kvm/x86.c b/drivers/kvm/x86.c
> index 2e0fded..4fe9f60 100644
> --- a/drivers/kvm/x86.c
> +++ b/drivers/kvm/x86.c
> @@ -1611,11 +1611,36 @@ int kvm_emulate_pio_string(struct kvm_vcpu
> *vcpu, struct kvm_run *run, int in,
> }
> EXPORT_SYMBOL_GPL(kvm_emulate_pio_string);
>
> -__init void kvm_arch_init(void)
> +int kvm_arch_init(void *opaque)
> {
> + struct kvm_x86_ops *ops = (struct kvm_x86_ops *)opaque;
> +
> kvm_init_msr_list();
> +
> + if (kvm_x86_ops) {
> + printk(KERN_ERR "kvm: already loaded the other
> module\n");
> + return -EEXIST;
> + }
> +
> + if (!ops->cpu_has_kvm_support()) {
> + printk(KERN_ERR "kvm: no hardware support\n");
> + return -EOPNOTSUPP;
> + }
> + if (ops->disabled_by_bios()) {
> + printk(KERN_ERR "kvm: disabled by bios\n");
> + return -EOPNOTSUPP;
&
Re: [kvm-devel] [PATCH] 3/5 Using kvm arch support instead ofkvm_x86_ops
Zhang, Xiantao wrote: > So we have to expose kvm_lock, and vm_list out. Is it OK? I think that should be ok. We're within the very same module. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] 5/5 Move-some-x86-specific-part-from-kvm_init-to-kvm_arch
Zhang, Xiantao wrote: > Agree. I am working on this now. I think we should move all mmu code > to arch specific. Yea, I think ppc does'nt need it as well. Hollis? - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] Move KVM_CHECK_EXTENSIONMove case to arch
Zhang, Xiantao wrote: > How about attached patch? Agree to keep this ioctl in common, and > instead define an arch-specific function in x86. Yea, that looks good to me. Acked-by: Carsten Otte <[EMAIL PROTECTED]> - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH][RFC] Struct kvm split
Zhang, Xiantao wrote: > Based on privious discussion, I made this patch to split struct kvm. > In this patch, strcut kvm only holds common fields, and struct kvm_x86 > will keep x86-specific fields. In this way, struct kvm will be a > sub-filed in struct kvm_x86, and we can use to_kvm_x86 to get kvm_x86 > from struct kvm. It is very similar with current to_vmx approach for > getting struct vmx from struct kvm_vcpu.This is a rough split based > on this idea. Any comments are welcome! Patch #2 does'nt apply for me, on top of #1 on today's kvm.git: [EMAIL PROTECTED]:~/kvm$ quilt push Wende Patch 0002-Move-strcut-kvm_x86_ops-defintion-to-x86.h.patch an (Stripping trailing CRs from patch.) patching file drivers/kvm/kvm.h (Stripping trailing CRs from patch.) patching file drivers/kvm/x86.h patch: malformed patch at line 169: int kvm_mmu_page_fault(struct kvm_vcpu *vcpu, gva_t gva, u32 error_code); Patch 0002-Move-strcut-kvm_x86_ops-defintion-to-x86.h.patch lässt sich nicht anwenden (erzwingen mit -f) - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH][1/3] Move kvm_vcpu_iotcl_get_dirty_log to arch
Zhang, Xiantao wrote:
> Move kvm_vcpu_ioctl_get_dirty_log to arch, and still keep the interface
> in common.
diff --git a/drivers/kvm/kvm_main.c b/drivers/kvm/kvm_main.c
index 45b18e1..3400265 100644
--- a/drivers/kvm/kvm_main.c
+++ b/drivers/kvm/kvm_main.c
@@ -419,19 +419,14 @@ int kvm_vm_ioctl_set_memory_region(struct kvm *kvm,
return kvm_set_memory_region(kvm, mem, user_alloc);
}
-/*
- * Get (and clear) the dirty memory log for a memory slot.
- */
-static int kvm_vm_ioctl_get_dirty_log(struct kvm *kvm,
- struct kvm_dirty_log *log)
+int kvm_get_dirty_log(struct kvm *kvm,
+ struct kvm_dirty_log *log, int *is_dirty)
Any reason to remove that comment? It looks helpful to me.
{
struct kvm_memory_slot *memslot;
int r, i;
int n;
unsigned long any = 0;
- mutex_lock(&kvm->lock);
-
r = -EINVAL;
if (log->slot >= KVM_MEMORY_SLOTS)
goto out;
@@ -450,17 +445,11 @@ static int kvm_vm_ioctl_get_dirty_log(struct kvm
*kvm,
if (copy_to_user(log->dirty_bitmap, memslot->dirty_bitmap, n))
goto out;
- /* If nothing is dirty, don't bother messing with page tables. */
- if (any) {
- kvm_mmu_slot_remove_write_access(kvm, log->slot);
- kvm_flush_remote_tlbs(kvm);
- memset(memslot->dirty_bitmap, 0, n);
- }
+ if (any)
+ *is_dirty = 1;
r = 0;
-
out:
- mutex_unlock(&kvm->lock);
return r;
}
This split won't work on s390. I think kvm_get_dirty_log should be
arch dependent alltogether: we're not going to have a dirty bitmap on
s390, we rather rely on our hardware support to update our storage
keys accordingly without guest/host intervention required. We'd want
to use that, and thus this implementation of kvm_get_dirty_log makes
no sense for us. On the other hand, I'd really want to keep the ioctl
common, so that guest migration code in userland can be common for all
archs.
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [Patch][2/3] Move kvm_mmu init and exit functionality to arch.
Zhang, Xiantao wrote: > Move kvm_mmu init and exit functionality to arch. Acked-by: Carsten Otte <[EMAIL PROTECTED]> - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] Add the hook kvm_arch_set_memory region to hold mmu-specific changes
Zhang, Xiantao wrote:
> Patch [3/3] Add the hook kvm_arch_set_memory_region. In this patch,
> introduce a function kvm_caculate_mmu_pages to compute mmu pages in
> total, once memory region changes.diff --git a/drivers/kvm/kvm_main.c
> b/drivers/kvm/kvm_main.c
index bda733a..a4a32bd 100644
--- a/drivers/kvm/kvm_main.c
+++ b/drivers/kvm/kvm_main.c
@@ -332,29 +332,9 @@ int __kvm_set_memory_region(struct kvm *kvm,
if (mem->slot >= kvm->nmemslots)
kvm->nmemslots = mem->slot + 1;
- 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);
- }
- }
*memslot = new;
- kvm_mmu_slot_remove_write_access(kvm, mem->slot);
- kvm_flush_remote_tlbs(kvm);
-
kvm_free_physmem_slot(&old, &new);
return 0;
@@ -374,6 +354,8 @@ int kvm_set_memory_region(struct kvm *kvm,
mutex_lock(&kvm->lock);
r = __kvm_set_memory_region(kvm, mem, user_alloc);
+ if (r == 0)
+ kvm_arch_set_memory_region(kvm, mem);
mutex_unlock(&kvm->lock);
return r;
}
This split of __kvm_set_memory_region assumes that all architectures
have physmem slots. I support Avi's suggestion to have user allocated
memory as new portable approach, and this old kernel-allocation based
one x86 only. If that's where we're heading, this split is the wrong
approach. I think we can come up with something smarter then "move the
whole thing to x86" in this case, but all cases that have user_alloc
== 1 should really be handled by x86.c code.
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH][1/3] Move kvm_vcpu_iotcl_get_dirty_log to arch
Avi Kivity wrote:
> Carsten Otte wrote:
>> Zhang, Xiantao wrote:
>>> Move kvm_vcpu_ioctl_get_dirty_log to arch, and still keep the interface
>>> in common.
>> diff --git a/drivers/kvm/kvm_main.c b/drivers/kvm/kvm_main.c
>> index 45b18e1..3400265 100644
>> --- a/drivers/kvm/kvm_main.c
>> +++ b/drivers/kvm/kvm_main.c
>> @@ -419,19 +419,14 @@ int kvm_vm_ioctl_set_memory_region(struct kvm *kvm,
>> return kvm_set_memory_region(kvm, mem, user_alloc);
>> }
>>
>> -/*
>> - * Get (and clear) the dirty memory log for a memory slot.
>> - */
>> -static int kvm_vm_ioctl_get_dirty_log(struct kvm *kvm,
>> - struct kvm_dirty_log *log)
>> +int kvm_get_dirty_log(struct kvm *kvm,
>> +struct kvm_dirty_log *log, int *is_dirty)
>>
>> Any reason to remove that comment? It looks helpful to me.
>>
>>
>> {
>> struct kvm_memory_slot *memslot;
>> int r, i;
>> int n;
>> unsigned long any = 0;
>>
>> -mutex_lock(&kvm->lock);
>> -
>> r = -EINVAL;
>> if (log->slot >= KVM_MEMORY_SLOTS)
>> goto out;
>> @@ -450,17 +445,11 @@ static int kvm_vm_ioctl_get_dirty_log(struct kvm
>> *kvm,
>> if (copy_to_user(log->dirty_bitmap, memslot->dirty_bitmap, n))
>> goto out;
>>
>> -/* If nothing is dirty, don't bother messing with page tables. */
>> -if (any) {
>> -kvm_mmu_slot_remove_write_access(kvm, log->slot);
>> -kvm_flush_remote_tlbs(kvm);
>> -memset(memslot->dirty_bitmap, 0, n);
>> -}
>> +if (any)
>> +*is_dirty = 1;
>>
>> r = 0;
>> -
>> out:
>> -mutex_unlock(&kvm->lock);
>> return r;
>> }
>>
>> This split won't work on s390. I think kvm_get_dirty_log should be
>> arch dependent alltogether: we're not going to have a dirty bitmap on
>> s390, we rather rely on our hardware support to update our storage
>> keys accordingly without guest/host intervention required. We'd want
>> to use that, and thus this implementation of kvm_get_dirty_log makes
>> no sense for us. On the other hand, I'd really want to keep the ioctl
>> common, so that guest migration code in userland can be common for all
>> archs.
>
> On the other hand, it will work for all others IIUC. Duplicating it in
> all other archs is not a good idea.
>
> We can special case it using #ifdef ARCH_HAS_KVM_GUEST_DIRTY_BITMAP or
> something.
>
> (hides from the #ifdef police)
Yea, I agree that it would make sense in case it works for power too.
We could have an
#ifdef CONFIG_ARCH_S390
return cool_big_iron_get_dirty_log(args);
#endif
at the beginning of that function. It would'nt hurt readability too much.
Hollis? Christian? How about ppc?
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH][1/3] Move kvm_vcpu_iotcl_get_dirty_log to arch
Carsten Otte wrote: > Yea, I agree that it would make sense in case it works for power too. We > could have an > #ifdef CONFIG_ARCH_S390 > return cool_big_iron_get_dirty_log(args); > #endif > at the beginning of that function. It would'nt hurt readability too much. Stupid suggestion. We could outsource the #ifdef to the caller, that would be much cleaner. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] Add the hook kvm_arch_set_memory region to hold mmu-specific changes
Zhang, Xiantao wrote: > User-allocation should be what we are heading. But considering > compatibility with old user-space support, I think kernel-allocation > approach should exist for a long time. That's right. This is why I would prefer to have the corresponding code out of kvm_main.c: it may exist for a long time for x86. > I think we don't need to consider > this case now. Once the kernel-allocation approach is abandoned in > future, as you say, we can move them all into x86. I'd rather prefer to move it upfront. Otherwise, I'd have to consider that case for s390 as long as it remains in common. At least I'd have to make sure it does'nt get used on s390 using an if() or #ifdef. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] Move x86 ioctl definitions from include/linux/kvm.h
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 0/7] Move x86 code out of include/linux/kvm.h
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] [RFC] virtio-blk PCI backend
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 Portability : Spliting kvm_set_memory_region.
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] [PATCH 0 of 3] create kvm_x86
Hollis Blanchard wrote: > 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. Looks like a clean approach with to to_kvm_x86 macro. Whole series: 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 0 of 3] create kvm_x86
Avi Kivity wrote:
> Well, I hate to say it, but the resulting code doesn't look too well
> (all the kvm_x86 variables), and it's entirely my fault as I recommended
> this approach. Not like it was difficult to predict.
>
> I'm thinking again of
>
> struct kvm {
> struct kvm_arch a;
> ...
> }
>
> Where each arch defines its own kvm_arch. Now the changes look like a
> bunch of "kvm->blah" to "kvm->a.blah" conversions.
>
> IIRC a downside was mentioned that it is easier to cause a build failure
> for another arch now.
>
> Opinions? In theory correctness should win over style every time, no?
It's a matter of taste. I favor embedding an kvm_arch too, but I
recommend to name member "a" different. "arch" maybe?
An advantage of this solution is, that some (not all) architectures
can share common code. If kvm_arch contains member foo for x86 and
ia64, a common function could do kvm->a.foo. With the posted approach,
we'd have
#ifdef CONFIG_ARCH_X86
val = to_kvm_x86(kvm).foo;
#else
val = to_kvm_ia74(kvm).foo;
#endif
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] Moving unalias_gfn to x86.c
Zhang, Xiantao wrote: > From: Zhang Xiantao <[EMAIL PROTECTED]> > Date: Thu, 22 Nov 2007 11:20:33 +0800 > Subject: [PATCH] KVM Portability: moving unalias_gfn to arch. > Non-x86 archs don't need this mechanism. Move it to arch, and > keep its interface in common. > Signed-off-by: Zhang Xiantao <[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
[kvm-devel] RFC/patch 1/2: remove desc.h include in kvm_main.c
This patch removes the include of asm/desc.h in kvm_main.c, which is
only available for x86 and not needed anymore.
Signed-off-by: Carsten Otte <[EMAIL PROTECTED]>
---
kvm_main.c |1 -
1 file changed, 1 deletion(-)
Index: kvm/drivers/kvm/kvm_main.c
===
--- kvm.orig/drivers/kvm/kvm_main.c 2007-11-22 15:15:54.0 +0100
+++ kvm/drivers/kvm/kvm_main.c 2007-11-22 15:22:51.0 +0100
@@ -45,7 +45,6 @@
#include
#include
#include
-#include
#include
MODULE_AUTHOR("Qumranet");
-
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] RFC/patch 2/2: remove irq.h include in kvm_main.c
This patch removes the include of "irq.h" in kvm_main.c, s390 does not
have irqs. For that, kvm_cpu_has_interrupt becomes an architecutre
specific function which can check for external or I/O interrupts on s390
and for irqs on x86 and others. In order to clarify wording, the
function defined by irq.h has been renamed to kvm_cpu_has_irq.
Signed-off-by: Carsten Otte <[EMAIL PROTECTED]>
---
irq.c |4 ++--
irq.h |2 +-
kvm_main.c |3 +--
svm.c |2 +-
vmx.c |2 +-
x86.c |4
x86.h |2 ++
7 files changed, 12 insertions(+), 7 deletions(-)
Index: kvm/drivers/kvm/irq.c
===
--- kvm.orig/drivers/kvm/irq.c 2007-11-22 15:24:42.0 +0100
+++ kvm/drivers/kvm/irq.c 2007-11-22 15:40:40.0 +0100
@@ -29,7 +29,7 @@
* check if there is pending interrupt without
* intack.
*/
-int kvm_cpu_has_interrupt(struct kvm_vcpu *v)
+int kvm_cpu_has_irq(struct kvm_vcpu *v)
{
struct kvm_pic *s;
@@ -42,7 +42,7 @@
}
return 1;
}
-EXPORT_SYMBOL_GPL(kvm_cpu_has_interrupt);
+EXPORT_SYMBOL_GPL(kvm_cpu_has_irq);
/*
* Read pending interrupt vector and intack.
Index: kvm/drivers/kvm/irq.h
===
--- kvm.orig/drivers/kvm/irq.h 2007-11-22 15:24:42.0 +0100
+++ kvm/drivers/kvm/irq.h 2007-11-22 15:37:43.0 +0100
@@ -58,7 +58,7 @@
void kvm_pic_set_irq(void *opaque, int irq, int level);
int kvm_pic_read_irq(struct kvm_pic *s);
int kvm_cpu_get_interrupt(struct kvm_vcpu *v);
-int kvm_cpu_has_interrupt(struct kvm_vcpu *v);
+int kvm_cpu_has_irq(struct kvm_vcpu *v);
void kvm_pic_update_irq(struct kvm_pic *s);
#define IOAPIC_NUM_PINS KVM_IOAPIC_NUM_PINS
Index: kvm/drivers/kvm/kvm_main.c
===
--- kvm.orig/drivers/kvm/kvm_main.c 2007-11-22 15:24:43.0 +0100
+++ kvm/drivers/kvm/kvm_main.c 2007-11-22 15:44:49.0 +0100
@@ -17,7 +17,6 @@
#include "kvm.h"
#include "x86.h"
-#include "irq.h"
#include
#include
@@ -656,7 +655,7 @@
/*
* We will block until either an interrupt or a signal wakes us up
*/
- while (!kvm_cpu_has_interrupt(vcpu)
+ while (!kvm_arch_cpu_has_interrupt(vcpu)
&& !signal_pending(current)
&& vcpu->mp_state != VCPU_MP_STATE_RUNNABLE
&& vcpu->mp_state != VCPU_MP_STATE_SIPI_RECEIVED) {
Index: kvm/drivers/kvm/svm.c
===
--- kvm.orig/drivers/kvm/svm.c 2007-11-22 15:24:43.0 +0100
+++ kvm/drivers/kvm/svm.c 2007-11-22 15:38:52.0 +0100
@@ -1338,7 +1338,7 @@
if (vmcb->control.int_ctl & V_IRQ_MASK)
return;
- if (!kvm_cpu_has_interrupt(vcpu))
+ if (!kvm_cpu_has_irq(vcpu))
return;
if (!(vmcb->save.rflags & X86_EFLAGS_IF) ||
Index: kvm/drivers/kvm/vmx.c
===
--- kvm.orig/drivers/kvm/vmx.c 2007-11-22 15:24:43.0 +0100
+++ kvm/drivers/kvm/vmx.c 2007-11-22 15:39:44.0 +0100
@@ -2244,7 +2244,7 @@
update_tpr_threshold(vcpu);
- has_ext_irq = kvm_cpu_has_interrupt(vcpu);
+ has_ext_irq = kvm_cpu_has_irq(vcpu);
intr_info_field = vmcs_read32(VM_ENTRY_INTR_INFO_FIELD);
idtv_info_field = vmcs_read32(IDT_VECTORING_INFO_FIELD);
if (intr_info_field & INTR_INFO_VALID_MASK) {
Index: kvm/drivers/kvm/x86.c
===
--- kvm.orig/drivers/kvm/x86.c 2007-11-22 15:24:43.0 +0100
+++ kvm/drivers/kvm/x86.c 2007-11-22 15:37:46.0 +0100
@@ -2917,6 +2917,10 @@
return kvm;
}
+int kvm_arch_cpu_has_interrupt(struct kvm_vcpu *v) {
+ return kvm_cpu_has_irq(v);
+}
+
static void kvm_unload_vcpu_mmu(struct kvm_vcpu *vcpu)
{
vcpu_load(vcpu);
Index: kvm/drivers/kvm/x86.h
===
--- kvm.orig/drivers/kvm/x86.h 2007-11-22 15:24:43.0 +0100
+++ kvm/drivers/kvm/x86.h 2007-11-22 15:37:47.0 +0100
@@ -315,6 +315,8 @@
int kvm_mmu_page_fault(struct kvm_vcpu *vcpu, gva_t gva, u32 error_code);
+int kvm_arch_cpu_has_interrupt(struct kvm_vcpu *v);
+
static inline void kvm_mmu_free_some_pages(struct kvm_vcpu *vcpu)
{
if (unlikely(vcpu->kvm->n_free_mmu_pages < KVM_MIN_FREE_MMU_PAGES))
-
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/patch 2/2: remove irq.h include in kvm_main.c
Avi Kivity wrote: > I generally understand "irq" to mean the interrupt request line, and > "interrupt" to mean a vectored interrupt (post interrupt controller). > In those terms the naming in correct. However I'm not at all certain > this naming convention is generally accepted. I think on s390 we'll have kvm_s390_vcpu_has_extint() kvm_s390_vcpu_has_ioint() and maybe kvm_s390_vcpu_has_machine_check() and kvm_arch_vcpu_has_interrupt() will check if any of above is pending. It would be great if the function names would clearly identify that one is the general portable "cpu needs to run an interrupt handler of whatever sort" and the other one is "we have a vectored interrupt to deliver" on x86 as well. If you'd like to keep the wording as is, I'll send a patch that just adds the kvm_arch_cpu_has_interrupt wrapper. - 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] Add the arg "module" for kvm_arch_init
Zhang, Xiantao wrote: > No, THIS_MODULE just stands for itself. But for IA64, we need another > module, and it will register some information to kvm module. So, we have > to keep it. That answer confuses me. kvm_arch_init() for ia64 will reside in kvm.ko just like kvm_init(), right? So THIS_MODULE will be the same in kvm_arch_init() and kvm_init(). So which module are you giving as argument? - 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] Add the arg "module" for kvm_arch_init
Zhang, Xiantao wrote: > Sorry for confusing you. Is it clear now? Thanks, yea this makes your intention clear to me. I think what you describe is an odd way to initialize both modules, and I'd like to suggest to try to come up with the reverse approach where kvm.ko loads your other module via request_module() in kvm_arch_init(). But as you said, this way does not confict with other archs, therefore I'm fine with it. - 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 wrote: > No, definitely not define a hypercall ABI. The feature bit should say > "this device understands a hypervisor-specific way of kicking. consult > your hypervisor manual and cpuid bits for further details. should you > not be satisfied with this method, port io is still available". ...unless you're lucky enough to be on s390 where pio is not available. I don't see why we'd have two different ways to talk to a virtio device. I think we should use a hypercall for interrupt injection, without support for grumpy old soldered pci features other than HPA-style Lguest PCI bus organization. There are no devices that we want to be backward compatible with. - 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 wrote: > Unfortunately, we have to care for platform differences, subarch > differences (vmx/svm), hypervisor differences (with virtio), and guest > differences (Linux/Windows/pvLinux, 32/64). Much care is needed when > designing the ABI here. Yea, I agree. > [actually thinking a bit, this is specific to the virtio pci binding; > s390 will never see any of it] You remember that we've lost the big debate around virtio in Tucson? We intend to bind our virtio devices to PCI too, so that they look the same in Linux userland across architectures. - 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 wrote: >> We intend to bind our virtio devices to PCI too, so that they look the >> same in Linux userland across architectures. > > Ouch. That was my initial opinion too, but HPA has come up with a lean and clean PCI binding for lguest. I think we should seriously consider using that over the current qemu device emulation based thing. - 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] Should we move kvm_vcpu_ioctl_interrupt to arch?
Zhang, Xiantao wrote: > Since IA64's irqchip is always in kernel side, so we don't need > kvm_vcpu_ioctl_interrupt for irq delivery. Should we moved it to arch? > Otherwise, we have to define two unnecessary fields(irq_summary and > irq_pending) for vcpu structure for compile pass. We don't have an irqchip at all. Nevertheless we have the need to inject interrupts from userspace. How does the in-kernel irqchip get triggered to present an interruption from userland? - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] Should we move kvm_vcpu_ioctl_interrupt to arch?
Zhang, Xiantao wrote: > You mean you also need these two fields to hold irqs ? No we don't. I think they can go to x86. - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
