Re: [kvm-devel] [PATCH 2/3] [PATCH] unregister pci device
Glauber Costa wrote: If we fail after we have allocated the pci device, we have to get rid of it. Otherwise, a bogus device will be found on the bus Maybe, alter the order so the device is registered last thing. This may help avoid races with pci passthrough hotplug. -- error compiling committee.c: too many arguments to function - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] KVM: MMU: Fix rmap_remove() race
Andrea Arcangeli wrote:
On Wed, Mar 26, 2008 at 08:22:31PM +0100, Andrea Arcangeli wrote:
what happens if invalidate_page runs after rmap_remove is returned
(the spte isn't visible anymore by the rmap code and in turn by
invalidate_page) but before the set_shadow_pte(nonpresent) runs.
Thinking some more the mmu_lock is meant to prevent this. So
invalidate_page should wait. As long as the kvm tlb flush happens
inside the mmu lock we should be safe.
Fixing it with mmu notifiers is the higher performance way too. This
would be the patch if we decide to do that.
Well, obviously mmu notifiers is the future and we should code for that,
instead of increasing code complexity.
Signed-off-by: Andrea Arcangeli [EMAIL PROTECTED]
diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index 95c12bc..80cf172 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -550,6 +550,7 @@ static void rmap_remove(struct kvm *kvm, u64 *spte)
sp = page_header(__pa(spte));
page = spte_to_page(*spte);
mark_page_accessed(page);
+ BUG_ON(page_count(page) = 1);
if (is_writeble_pte(*spte))
kvm_release_page_dirty(page);
else
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index 30bf832..a49987c 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -741,6 +741,10 @@ static struct vm_operations_struct kvm_vcpu_vm_ops = {
static int kvm_vcpu_mmap(struct file *file, struct vm_area_struct *vma)
{
vma-vm_ops = kvm_vcpu_vm_ops;
+#ifndef CONFIG_MMU_NOTIFIER
+ /* prevent the VM to release pages under sptes mappings */
+ vma-vm_flags |= VM_LOCKED;
+#endif
return 0;
}
That's sad, but I guess the only safe and simple option is to queue this
for 2.6.25 and remove it in 2.6.26.
--
error compiling committee.c: too many arguments to function
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH v2] x86: don't allow KVM_CLOCK on Voyager or Visual WS
Randy Dunlap wrote: From: Randy Dunlap [EMAIL PROTECTED] Prevent failed randconfig builds with KVM_CLOCK being enabled on Voyager or VISWS. Applies, thanks. -- error compiling committee.c: too many arguments to function - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] KVM: MMU: Fix rmap_remove() race
Andrea Arcangeli wrote:
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index 30bf832..a49987c 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -741,6 +741,10 @@ static struct vm_operations_struct kvm_vcpu_vm_ops = {
static int kvm_vcpu_mmap(struct file *file, struct vm_area_struct *vma)
{
vma-vm_ops = kvm_vcpu_vm_ops;
+#ifndef CONFIG_MMU_NOTIFIER
+ /* prevent the VM to release pages under sptes mappings */
+ vma-vm_flags |= VM_LOCKED;
+#endif
return 0;
}
Erm I don't think this means what you think it means. This is the
kernel/user communication area, used to pass exit data to userspace.
It's not the memslot vma.
--
error compiling committee.c: too many arguments to function
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] kvm causing memory corruption? ~2.6.25-rc6
Dave Hansen wrote: On Wed, 2008-03-26 at 18:58 +0200, Avi Kivity wrote: Dave Hansen wrote: On Wed, 2008-03-26 at 11:50 +0200, Avi Kivity wrote: Dave Hansen wrote: I was getting some kvm userspace crashes trying to run a Windows guest. So, I decided to try a recent kernel (2.6.25-rc6-00333-ga4083c9) with the kvm kernel code that shipped with that kernel. This is fixed in 2.6.25-rc7. I just updated to -rc7 and re-tested. Same symptoms: Bad. Which kvm userspace are you running? ~/src/kvm-userspace$ git describe kvm-63-118-g52be1a1 I dug out my i386 install and tried it. Doesn't reproduce for me on either kvm.git or -rc7. Do you have a working setup that we can bisect? -- error compiling committee.c: too many arguments to function - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] kvm causing memory corruption? ~2.6.25-rc6
Avi Kivity wrote: Dave Hansen wrote: On Wed, 2008-03-26 at 18:58 +0200, Avi Kivity wrote: Dave Hansen wrote: On Wed, 2008-03-26 at 11:50 +0200, Avi Kivity wrote: Dave Hansen wrote: I was getting some kvm userspace crashes trying to run a Windows guest. So, I decided to try a recent kernel (2.6.25-rc6-00333-ga4083c9) with the kvm kernel code that shipped with that kernel. [...] btw, is this with = 4GB RAM on the host? -- error compiling committee.c: too many arguments to function - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] KVM Test result, kernel c0af88e.., userspace 0342df6..
Yunfeng Zhao wrote: Hi Alll, This is today's KVM test result against kvm.git c0af88e9014019f6392b06c11e836ca58acc7ede and kvm-userspace.git 0342df67ec22f3d9aa663949b72694e061c2edb2. 3. slab error in kmem_cache_destroy(): cache `kvm_vcpu': https://sourceforge.net/tracker/?func=detailatid=893831aid=1925889group_id=180599 This should have been fixed by the commits mentioned. -- error compiling committee.c: too many arguments to function - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 2/3] [PATCH] unregister pci device
Glauber Costa wrote: Avi Kivity wrote: Glauber Costa wrote: If we fail after we have allocated the pci device, we have to get rid of it. Otherwise, a bogus device will be found on the bus Maybe, alter the order so the device is registered last thing. This may help avoid races with pci passthrough hotplug. That's the first thing I thought, but it makes things much more complicated. If really deserved, I can try again. I don't think it's that critical at this stage. -- error compiling committee.c: too many arguments to function - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [RFC/PATCH 00/15 v3] kvm on big iron
Carsten Otte wrote: Many thanks for the review feedback we have received so far, and many thanks to Andrew for reviewing our common code memory management changes. I do greatly appreciate that :-). All important parts have been reviewed, all review feedback has been integrated in the code. Therefore we would like to ask for inclusion of our work into kvm.git. Changes from Version 1: - include feedback from Randy Dunlap on the documentation - include feedback from Jeremy Fitzhardinge, the prototype for dup_mm has moved to include/linux/sched.h - rebase to current kvm.git hash g361be34. Thank you Avi for pulling in the fix we need, and for moving KVM_MAX_VCPUS to include/arch :-). Changes from Version 2: - include feedback from Rusty Russell on the virtio patch - include fix for race s390_enable_sie() versus ptrace spotted by Dave Hansen: we now do task_lock() to protect mm_users from update while we're growing the page table. Good catch, Dave :-). - rebase to current kvm.git hash g680615e Applied all, thanks. -- error compiling committee.c: too many arguments to function - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] ignore reads to the EOI register.
Andi Kleen wrote: Maciej W. Rozycki [EMAIL PROTECTED] writes: Linux performs reads to all registers written including this one deliberately using an RMW cycle to avoid triggering an erratum in some early Pentium integrated APICs. Obviously it does not matter for most of the world as the workaround is build-time conditional, but you'll get it if you build a generic runs everywhere kernel. It would be quite possible to make the cycle conditional on a cpufeatures.h quirk flag that is only set on P5. Just would need to out of line a few functions to avoid code bloat. Or, alternatives? xchg vs mov? -- error compiling committee.c: too many arguments to function - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] manage number of VCPU and memory
Břeťa Vomočil wrote: Thanks, it worked... But I have one more question, is there also some command for changing actual memory like cpu_set for setting number of VCPUs? There's the balloon driver, but that is not yet merged. -- error compiling committee.c: too many arguments to function - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] KVM: MMU: Fix rmap_remove() race
Andrea Arcangeli wrote: On Thu, Mar 27, 2008 at 10:11:42AM +0200, Avi Kivity wrote: Erm I don't think this means what you think it means. This is the kernel/user communication area, used to pass exit data to userspace. It's not the memslot vma. Yep... only the kvm_vm_vm_ops can run gfn_to_page, and I assume that was used by the old userland and not relevant anymore (smaps don't show it either), or the pages could not be unmapped. So btw, that kvm-vm anon inode must be disabled when mmu notifiers are configured in to guarantee that access to /dev/kvm won't lead to mlock behavior. That's not good. We need to support the older userspace, for a while yet. Why is there a problem? IIRC it's just anonymous memory. -- error compiling committee.c: too many arguments to function - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] kvm causing memory corruption? ~2.6.25-rc6
Dave Hansen wrote: On Thu, 2008-03-27 at 12:10 +0200, Avi Kivity wrote: btw, is this with = 4GB RAM on the host? Well, are you asking whether I have PAE on or not? :) No, I'm asking whether there is a possibility of address truncation :) PAE by itself doesn't affect kvm much, as it always runs the guest in pae mode. Can you try running with mem=2000M or something? -- error compiling committee.c: too many arguments to function - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [patch 1/3] QEMU/KVM: separate thread for IO handling
Marcelo Tosatti wrote: I still don't understand this. Timer expiration ought to be processed in the iothread, when SIGALRM is dequeued, and be completely unrelated to whatever vcpu 0 is doing. Yes, now it is unrelated. But before the patch it wasnt. So currently the SIGALRM handler... means the current code in kvm-userspace.git. I see now. Okay, will merge. - Processing of IO events will not be unnecessarily interrupted. What do you mean by this? That SIGIO, SIGALRM and SIGUSR2 signals will not interrupt main_loop_wait(), since they are now blocked. Better latency, less time holding the mutex lock Signals are blocked in current git, they can only interrupt the guest, not the host. -- error compiling committee.c: too many arguments to function - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] hugetlbfs not working
Anthony Liguori wrote: If you don't bail when ftruncate fails, does it work as expected for you? Perhaps older versions of hugetlbfs didn't support truncate. If you don't truncate, how can you change the file size? hugetlbfs doesn't support write(). I vaugely recall using ftruncate() on 2.4. -- error compiling committee.c: too many arguments to function - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] KVM Test result, kernel 680615e.., userspace 52be1a1..
Yunfeng Zhao wrote: Just find one new issue: *[ kvm-Bugs-1925889 ] slab error in kmem_cache_destroy(): cache `kvm_vcpu': https://sourceforge.net/tracker/?func=detailatid=893831aid=1925889group_id=180599 This error happened when reinsert kvm-intel.ko after creating and destroying several guests. It causes the host to hang. I saw this also. I think it only happens with the external module. I am looking into it. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] KVM Test result, kernel 680615e.., userspace 52be1a1..
Chris Wedgwood wrote: On Wed, Mar 26, 2008 at 02:25:11PM +0800, Yunfeng Zhao wrote: 2. booting smp windows guests has 30% chance of hang https://sourceforge.net/tracker/?func=detailatid=893831aid=1910923group_id=180599 Does it hang or bluescreen? What if you disable the FlexPriority optimization? There's a new module parameter for that (kvm_intel.ko): flexpriority_enabled=[0|1] -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] kvm causing memory corruption? ~2.6.25-rc6
Dave Hansen wrote: I was getting some kvm userspace crashes trying to run a Windows guest. So, I decided to try a recent kernel (2.6.25-rc6-00333-ga4083c9) with the kvm kernel code that shipped with that kernel. This is fixed in 2.6.25-rc7. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 0/20] dma_ops for i386
Glauber Costa wrote: Hello, Here there is a series of 20 patches that lays the foundations for using dma_ops in i386 in the very same way x86_64, as well as many other architectures already do. The functions themselves for i386 are placed in a pci-base_32.c, but just a few among them are actually implemented. Most were no-ops anyway. I see the headers are unified, but the .c files are duplicated. I presume unifying the implementation is deferred to later patches? The motivation for that is the ongoing work for pci-passthrough in KVM. So ingo, avi, what do you think it's the best way to handle these patches through? x86.git. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH][QEMU] Use a separate device for in-kernel PIT (v2)
Anthony Liguori wrote: Avi Kivity wrote: Please separate the code movement and changes into separate patches. I'm not sure there's a great way to do this that preserves bisectability and results in meaningful history. I could leave the #ifdef's in i8254-kvm.c and then have a second patch that removes them. That doesn't seem to be terribly valuable though from a history perspective as it still requires a bit of code change to keep things working. Were you thinking of something else? Nothing exotic. The patch moves some structure declarations to header files, that can be split off so we have one patch that paves the way (doing nothing but code movement) and the other actually introduces the new device, only adding new code (and possibly exporting functions). -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] Use QEMU functions to access guest memory for virtio
Anthony Liguori wrote: #define s_ld_u64(phys, field, type) \ ldq_phys(phys + offsetof(field, type)) And now we don't need individual accessors, or to encode the offsets as magic numbers. It's a nice thought but it doesn't work out in practice because most of these accessor functions are accessing array elements. However, I thought about using offsetof() to eliminate the magic constants and I don't think that's a bad idea. In the very least, it makes the code more readable. It'll be part of the next series. offsetof() should work for array members (i.e. offsetof(struct s, a[8])). -- error compiling committee.c: too many arguments to function - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [PATCH] KVM: MMU: Fix rmap_remove() race
Andrea notes that freeing the page before flushing the tlb is a race, as the
guest can sneak in one last write before the tlb is flushed, writing to a
page that may belong to someone else.
Fix be reversing the order of freeing and flushing the tlb. Since the tlb
flush is expensive, queue the pages to be freed so we need to flush just once.
Signed-off-by: Avi Kivity [EMAIL PROTECTED]
---
arch/x86/kvm/mmu.c | 66 +++
include/asm-x86/kvm_host.h |8 +
2 files changed, 67 insertions(+), 7 deletions(-)
diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index 95c12bc..2033879 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -536,6 +536,52 @@ static void rmap_desc_remove_entry(unsigned long *rmapp,
mmu_free_rmap_desc(desc);
}
+static void rmap_remove_complete(struct kvm *kvm)
+{
+ int i;
+ struct page *page;
+
+ if (!kvm-arch.nr_page_release_queue)
+ return;
+ kvm_flush_remote_tlbs(kvm);
+ for (i = 0; i kvm-arch.nr_page_release_queue; ++i) {
+ page = kvm-arch.page_release_queue[i].page;
+ if (kvm-arch.page_release_queue[i].dirty)
+ kvm_release_page_dirty(page);
+ else
+ kvm_release_page_clean(page);
+ }
+ kvm-arch.nr_page_release_queue = 0;
+}
+
+static void kvm_release_page_deferred(struct kvm *kvm,
+ struct page *page,
+ bool dirty)
+{
+ int i;
+
+ i = kvm-arch.nr_page_release_queue;
+ if (i == KVM_MAX_PAGE_RELEASE_QUEUE) {
+ rmap_remove_complete(kvm);
+ i = 0;
+ }
+ kvm-arch.page_release_queue[i].page = page;
+ kvm-arch.page_release_queue[i].dirty = dirty;
+ kvm-arch.nr_page_release_queue = i + 1;
+}
+
+static void kvm_release_page_dirty_deferred(struct kvm *kvm,
+ struct page *page)
+{
+ kvm_release_page_deferred(kvm, page, true);
+}
+
+static void kvm_release_page_clean_deferred(struct kvm *kvm,
+ struct page *page)
+{
+ kvm_release_page_deferred(kvm, page, true);
+}
+
static void rmap_remove(struct kvm *kvm, u64 *spte)
{
struct kvm_rmap_desc *desc;
@@ -551,9 +597,9 @@ static void rmap_remove(struct kvm *kvm, u64 *spte)
page = spte_to_page(*spte);
mark_page_accessed(page);
if (is_writeble_pte(*spte))
- kvm_release_page_dirty(page);
+ kvm_release_page_dirty_deferred(kvm, page);
else
- kvm_release_page_clean(page);
+ kvm_release_page_clean_deferred(kvm, page);
rmapp = gfn_to_rmap(kvm, sp-gfns[spte - sp-spt], is_large_pte(*spte));
if (!*rmapp) {
printk(KERN_ERR rmap_remove: %p %llx 0-BUG\n, spte, *spte);
@@ -585,6 +631,12 @@ static void rmap_remove(struct kvm *kvm, u64 *spte)
}
}
+static void rmap_remove_one(struct kvm *kvm, u64 *spte)
+{
+ rmap_remove(kvm, spte);
+ rmap_remove_complete(kvm);
+}
+
static u64 *rmap_next(struct kvm *kvm, unsigned long *rmapp, u64 *spte)
{
struct kvm_rmap_desc *desc;
@@ -650,7 +702,7 @@ static void rmap_write_protect(struct kvm *kvm, u64 gfn)
BUG_ON((*spte (PT_PAGE_SIZE_MASK|PT_PRESENT_MASK)) !=
(PT_PAGE_SIZE_MASK|PT_PRESENT_MASK));
pgprintk(rmap_write_protect(large): spte %p %llx %lld\n,
spte, *spte, gfn);
if (is_writeble_pte(*spte)) {
- rmap_remove(kvm, spte);
+ rmap_remove_one(kvm, spte);
--kvm-stat.lpages;
set_shadow_pte(spte, shadow_trap_nonpresent_pte);
write_protected = 1;
@@ -872,7 +924,7 @@ static void kvm_mmu_page_unlink_children(struct kvm *kvm,
rmap_remove(kvm, pt[i]);
pt[i] = shadow_trap_nonpresent_pte;
}
- kvm_flush_remote_tlbs(kvm);
+ rmap_remove_complete(kvm);
return;
}
@@ -891,7 +943,7 @@ static void kvm_mmu_page_unlink_children(struct kvm *kvm,
}
pt[i] = shadow_trap_nonpresent_pte;
}
- kvm_flush_remote_tlbs(kvm);
+ rmap_remove_complete(kvm);
}
static void kvm_mmu_put_page(struct kvm_mmu_page *sp, u64 *parent_pte)
@@ -1048,7 +1100,7 @@ static void mmu_set_spte(struct kvm_vcpu *vcpu, u64
*shadow_pte,
if (is_rmap_pte(*shadow_pte)) {
if (page != spte_to_page(*shadow_pte))
- rmap_remove(vcpu-kvm, shadow_pte);
+ rmap_remove_one(vcpu-kvm, shadow_pte);
else
was_rmapped = 1;
}
@@ -1583,7 +1635,7 @@ static void mmu_pte_write_zap_pte(struct kvm_vcpu *vcpu,
if (is_shadow_present_pte(pte
Re: [kvm-devel] buliding and testing PowerPC KVM
Jerone Young wrote: * Sorry was going for paste, and somehow hit send. The earlier post looked much simpler. So it's actually really easy using cross compiler to build everything. I use my laptop and then copy over to our nfs root that our boards use. Here are some instructions I wrote up for someone earlier. Excuse the fill me parts but it is enough to get you going: This is a run through of how to build kvmppc kernel kvm-userspace [snip huge howto] Since I have a ppc account, I'll just build on that. Once we support server-class hosts, I may do run testing with qemu. -- error compiling committee.c: too many arguments to function - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [RFC] QEMU/KVM: dedicated IO thread
Marcelo Tosatti wrote: QEMU/KVM: separate thread for IO handling Move IO processing from vcpu0 to a dedicated thread. This removes load on vcpu0 by allowing better cache locality and also improves latency. We can now block signal handling for IO events, so sigtimedwait won't race with handlers: - Currently the SIGALRM handler fails to set CPU_INTERRUPT_EXIT because the next_cpu variable is not initialized in the KVM path, meaning that processing of timer expiration might be delayed until the next vcpu0 exit. I think we call main_loop_wait() is called unconditionally after every signal. We exit the kvm_run() loop if CPU_INTERRUPT_EXIT is detected by pre_kvm_run(). But why do we need to exit the kvm_run() loop? As I understand it, the I/O thread wakes up when the signal is queued and calls main_loop_wait() to process any events (through qemu_run_timers()). If a timer needs to wake up a vcpu, it will raise an interrupt line which will wake the vcpu up, either in the kernel or in userspace depending on -no-kvm-irqchip. -- error compiling committee.c: too many arguments to function - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] kvm causing memory corruption? ~2.6.25-rc6
Dave Hansen wrote: On Wed, 2008-03-26 at 11:50 +0200, Avi Kivity wrote: Dave Hansen wrote: I was getting some kvm userspace crashes trying to run a Windows guest. So, I decided to try a recent kernel (2.6.25-rc6-00333-ga4083c9) with the kvm kernel code that shipped with that kernel. This is fixed in 2.6.25-rc7. I just updated to -rc7 and re-tested. Same symptoms: Bad. Which kvm userspace are you running? -- error compiling committee.c: too many arguments to function - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [RFC/PATCH 01/15] preparation: provide hook to enable pgstes in user pagetable
Carsten Otte wrote: Avi Kivity wrote: Well, dup_mm() can't work (and now that I think about it, for more reasons -- what if the process has threads?). We lock out multithreaded users already, -EINVAL. Would be much better if this can be avoided. It's surprising. -- Any sufficiently difficult bug is indistinguishable from a feature. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. 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] [GIT PULL] KVM fixes for 2.6.25-rc6
Linus, please pull from the repo and branch
git://git.kernel.org/pub/scm/linux/kernel/git/avi/kvm.git for-linus
The patches fix a memory leak, ioperm() failures on unrelated processes
on the host, a locking issue, and a host crash when host userspace changes
the memory map.
Diffstat, shortlog and individual patches follow:
arch/x86/kvm/mmu.c | 18 ++
arch/x86/kvm/vmx.c |7 ++-
2 files changed, 16 insertions(+), 9 deletions(-)
Avi Kivity (3):
KVM: VMX: Restore tss even on x86_64
KVM: MMU: Fix is_rmap_pte() with io ptes
KVM: MMU: Fix memory leak on guest demand faults
Marcelo Tosatti (2):
KVM: MMU: handle page removal with shadow mapping
KVM: VMX: convert init_rmode_tss() to slots_lock
From 5dc832628229d2736fab10523566855c3cda622d Mon Sep 17 00:00:00 2001
From: Avi Kivity [EMAIL PROTECTED]
Date: Sun, 16 Mar 2008 18:48:26 +0200
Subject: [PATCH] KVM: VMX: Restore tss even on x86_64
The vmx hardware state restore restores the tss selector and base address, but
not its length. Usually, this does not matter since most of the tss contents
is within the default length of 0x67. However, if a process is using ioperm()
to grant itself I/O port permissions, an additional bitmap within the tss,
but outside the default length is consulted. The effect is that the process
will receive a SIGSEGV instead of transparently accessing the port.
Fix by restoring the tss length. Note that i386 had this working already.
Closes bugzilla 10246.
Signed-off-by: Avi Kivity [EMAIL PROTECTED]
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 94ea724..f2df03c 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -349,8 +349,6 @@ static void update_exception_bitmap(struct kvm_vcpu *vcpu)
static void reload_tss(void)
{
-#ifndef CONFIG_X86_64
-
/*
* VT restores TR but not its size. Useless.
*/
@@ -361,7 +359,6 @@ static void reload_tss(void)
descs = (void *)gdt.base;
descs[GDT_ENTRY_TSS].type = 9; /* available TSS */
load_TR_desc();
-#endif
}
static void load_transition_efer(struct vcpu_vmx *vmx)
--
1.5.4.2
From 4b1a80fa65aa9e2ec5696998856136c886385538 Mon Sep 17 00:00:00 2001
From: Avi Kivity [EMAIL PROTECTED]
Date: Sun, 23 Mar 2008 12:18:19 +0200
Subject: [PATCH] KVM: MMU: Fix is_rmap_pte() with io ptes
is_rmap_pte() doesn't take into account io ptes, which have the avail bit set.
Signed-off-by: Avi Kivity [EMAIL PROTECTED]
diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index d8172aa..e49c4d4 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -222,8 +222,7 @@ static int is_io_pte(unsigned long pte)
static int is_rmap_pte(u64 pte)
{
- return pte != shadow_trap_nonpresent_pte
-pte != shadow_notrap_nonpresent_pte;
+ return is_shadow_present_pte(pte);
}
static gfn_t pse36_gfn_delta(u32 gpte)
--
1.5.4.2
From 15aaa819e20cb183f26392ed8ea16020630ef142 Mon Sep 17 00:00:00 2001
From: Marcelo Tosatti [EMAIL PROTECTED]
Date: Mon, 17 Mar 2008 10:08:18 -0300
Subject: [PATCH] KVM: MMU: handle page removal with shadow mapping
Do not assume that a shadow mapping will always point to the same host
frame number. Fixes crash with madvise(MADV_DONTNEED).
[avi: move after first printk(), add another printk()]
Signed-off-by: Marcelo Tosatti [EMAIL PROTECTED]
Signed-off-by: Avi Kivity [EMAIL PROTECTED]
diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index e49c4d4..4ba85d9 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -892,14 +892,25 @@ static void mmu_set_spte(struct kvm_vcpu *vcpu, u64
*shadow_pte,
int *ptwrite, gfn_t gfn, struct page *page)
{
u64 spte;
- int was_rmapped = is_rmap_pte(*shadow_pte);
+ int was_rmapped = 0;
int was_writeble = is_writeble_pte(*shadow_pte);
+ hfn_t host_pfn = (*shadow_pte PT64_BASE_ADDR_MASK) PAGE_SHIFT;
pgprintk(%s: spte %llx access %x write_fault %d
user_fault %d gfn %lx\n,
__FUNCTION__, *shadow_pte, pt_access,
write_fault, user_fault, gfn);
+ if (is_rmap_pte(*shadow_pte)) {
+ if (host_pfn != page_to_pfn(page)) {
+ pgprintk(hfn old %lx new %lx\n,
+host_pfn, page_to_pfn(page));
+ rmap_remove(vcpu-kvm, shadow_pte);
+ }
+ else
+ was_rmapped = 1;
+ }
+
/*
* We don't set the accessed bit, since we sometimes want to see
* whether the guest actually used the pte (in order to detect
--
1.5.4.2
From 707a18a51d83d9180a63b3cbaad8eda7764a8689 Mon Sep 17 00:00:00 2001
From: Marcelo Tosatti [EMAIL PROTECTED]
Date: Tue, 18 Mar 2008 17:42:34 -0300
Subject: [PATCH] KVM: VMX: convert init_rmode_tss() to slots_lock
init_rmode_tss was forgotten during the conversion from mmap_sem to
slots_lock.
INFO: task qemu-system
Re: [kvm-devel] KVM: register the kvm mmu cache with the shrinker.
Izik Eidus wrote:
this is the shrinker patch with all comments applied beside adding aging
mechanism
it look like the aging mechanism is not really needed and therefor for now it
isn't
implemented.
From 8503a57ae88ba819e4eac6371172772c98b485f0 Mon Sep 17 00:00:00 2001
From: Izik Eidus [EMAIL PROTECTED]
Date: Tue, 25 Mar 2008 14:03:27 +0200
Subject: [PATCH] KVM: register the kvm mmu cache with the shrinker.
Signed-off-by: Izik Eidus [EMAIL PROTECTED]
---
arch/x86/kvm/mmu.c | 54
1 files changed, 54 insertions(+), 0 deletions(-)
diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index c67ec62..c42c0db 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -1972,6 +1972,57 @@ void kvm_mmu_zap_all(struct kvm *kvm)
kvm_flush_remote_tlbs(kvm);
}
+static int mmu_shrink(int nr_to_scan, gfp_t gfp_mask)
+{
+ struct kvm *kvm;
+ struct kvm *kvm_freed = NULL;
+ int cache_count = 0;
+
+ spin_lock(kvm_lock);
+ if (list_empty(vm_list)) {
+ spin_unlock(kvm_lock);
+ return 0;
+ }
Unnecessary, if the list is empty the loop below doesn't execute and we
return 0 anyway.
+ list_for_each_entry(kvm, vm_list, vm_list) {
+ int npages;
+
+ spin_lock(kvm-mmu_lock);
+ npages = kvm-arch.n_alloc_mmu_pages -
+ kvm-arch.n_free_mmu_pages;
+ cache_count += npages - KVM_MIN_ALLOC_MMU_PAGES;
I think we should allow the shrinker to go below
KVM_MIN_ALLOC_MMU_PAGES; in particular, if the vm is inactive, we should
be able to shrink it to nothing.
When the VM starts executing again, it will reallocate those pages.
+ if (!kvm_freed nr_to_scan 0 npages
+ KVM_MIN_ALLOC_MMU_PAGES) {
Don't split an expression like that; the tightly binding expression
should stay on the same line:
if (!kvm_freed nr_to_scan 0
npages KVM_MN_ALLOC_MMU_PAGES) {
+ kvm_mmu_remove_one_alloc_mmu_page(kvm);
+ cache_count--;
+ kvm_freed = kvm;
+ }
+ nr_to_scan--;
+
+ spin_unlock(kvm-mmu_lock);
+ }
+ if (kvm_freed) {
+ list_del(kvm_freed-vm_list);
+ list_add_tail(kvm_freed-vm_list, vm_list);
+ }
list_move_tail()
+ spin_unlock(kvm_lock);
+
+ return cache_count;
+}
+
+static struct shrinker mmu_shrinker = {
+ .shrink = mmu_shrink,
+ .seeks = DEFAULT_SEEKS * 10,
+};
+
void kvm_mmu_module_exit(void)
{
if (pte_chain_cache)
@@ -1980,6 +2031,7 @@ void kvm_mmu_module_exit(void)
kmem_cache_destroy(rmap_desc_cache);
if (mmu_page_header_cache)
kmem_cache_destroy(mmu_page_header_cache);
I believe it is necessary to register the shrinker in order to have any
observable effect.
--
error compiling committee.c: too many arguments to function
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
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][QEMU] Use a separate device for in-kernel PIT (v2)
Anthony Liguori wrote: Part of the feedback we received from Fabrice about the KVM patches for QEMU is that we should create a separate device for the in-kernel APIC to avoid having lots of if (kvm_enabled()) within the APIC code that were difficult to understand why there were needed. This patch separates the in-kernel PIT into a separate device. It also introduces some configure logic to only compile in support for the in-kernel PIT if it's available. The result of this is that we now only need a single if (kvm_enabled()) to determine which device to use. Besides making it more upstream friendly, I think this makes the code much easier to understand. Since v1=v2, we make sure to use common code for save/restore between in-kernel pit and in-qemu pit. Please separate the code movement and changes into separate patches. -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [kvm-ppc-devel] [PATCH 0 of 7] [v6] PowerPC kvm-userspace patches
Jerone Young wrote: Fix big bug found by Anthony, as well formating comments that he commented on. Bombs away! This set of patches enables the following: -Device tree Support - Add libfdt to kvm-userspace - Add bamboo device tree to qemu source - Detection of host Device Tree attributes - Device tree loading - Ability to specify initrd on the command line - Ability to add kernel arguments on the command line - Ability to load compressed uImages - Ability to specify memory on the command line Applied all; thanks. -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. 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] QEMU/KVM: dedicated IO thread
Marcelo Tosatti wrote: Avi was concerned that this would cause problems with migration. I haven't specifically tested it yet, but it seems there will be no problems introduced by this change: the IO thread will stop all vcpu's in the same way the vcpu0 thread did before. I believe this is broken for smp_cpus 1, and will with this change will be broken even for non smp. The pause/resume logic is rotten. QEMU/KVM: separate thread for IO handling Move IO processing from vcpu0 to a dedicated thread. This removes load on vcpu0 by allowing better cache locality and also improves latency. We can now block signal handling for IO events, so sigtimedwait won't race with handlers: - Currently the SIGALRM handler fails to set CPU_INTERRUPT_EXIT because the next_cpu variable is not initialized in the KVM path, meaning that processing of timer expiration might be delayed until the next vcpu0 exit. I think we call main_loop_wait() is called unconditionally after every signal. - Processing of IO events will not be unnecessarily interrupted. Index: kvm-userspace.io/libkvm/libkvm.c === --- kvm-userspace.io.orig/libkvm/libkvm.c +++ kvm-userspace.io/libkvm/libkvm.c @@ -388,9 +388,6 @@ int kvm_create(kvm_context_t kvm, unsign if (r 0) return r; kvm_create_irqchip(kvm); - r = kvm_create_vcpu(kvm, 0); - if (r 0) - return r; return 0; } Please put this and the corresponding qemu change in a separate patch. [...lots more...] Looks good. -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. 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.h: __user requires compiler.h
Christian Borntraeger wrote:
Am Montag, 24. März 2008 schrieb Avi Kivity:
Christian Borntraeger wrote:
Am Freitag, 21. März 2008 schrieb Anthony Liguori:
This patch breaks QEMU build when doing a 'make sync'. When you do a
top-level ./configure, libkvm is built with kerneldir pointing to
kvm-userspace/kernel/include. While linux/kvm.h is present there,
[...]
Maybe we should generate the 'make sync' headers using 'make
headers_install'.
headers_install works because there is
# Eliminate the contents of (and inclusions of) compiler.h
HDRSED := sed -e s/ inline / __inline__ /g \
-e s/[[:space:]]__user[[:space:]]\{1,\}/ /g \
-e s/(__user[[:space:]]\{1,\}/ (/g \
-e s/[[:space:]]__force[[:space:]]\{1,\}/ /g \
-e s/(__force[[:space:]]\{1,\}/ (/g \
-e s/[[:space:]]__iomem[[:space:]]\{1,\}/ /g \
-e s/(__iomem[[:space:]]\{1,\}/ (/g \
-e s/[[:space:]]__attribute_const__[[:space:]]\{1,\}/\ /g
\
-e s/[[:space:]]__attribute_const__$$// \
-e /^\#include linux\/compiler.h/d
in scripts/Makefile.headersinst
If you dont want to do something like for make sync, what about providing a
dummy compiler.h, which has
only this line?
#define __user
I already added something similar, see
bcb30c8bafc7cac75c38981a57bc1f94521e83f4.
--
error compiling committee.c: too many arguments to function
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
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] buliding and testing PowerPC KVM
Hollis Blanchard wrote: On Fri, 2008-03-21 at 13:02 +0200, Avi Kivity wrote: Other than that, and the few minor comments that popped up, this (very nice) patchset will be very easy to merge. IIRC you mentioned it is possible for me to get an s390 account; this will be very useful in avoiding breaking this port, as happens quite often with ppc and ia64. I'd like to be able to do both build and run testing. As for building the PowerPC code, cross-compiling is easy with http://kegel.com/crosstool . There are also a number of servers offering remote PowerPC ssh access: see http://penguinppc.org/dev/#remote . I now have a ppc account. Once you point me at the ppc kernel repo I can start build testing. -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [kvm-ppc-devel] [PATCH] Add -Werror to libkvm compile
Jerone Young wrote: It does work with gcc 4.2.3 . Though no idea if gcc-4.3 4.4 would workout. Though they should. I'll need to to compile them and give them a try. While I'm a fan of -Werror, I have to agree with Anthony it can cause no end of pain to users if they have a slightly different configuration. Maybe enable it conditionally based on ./configure --developer as Anthony suggests (but I'll forget to use it myself, I'm sure). -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. 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 01/15] preparation: provide hook to enable pgstes in user pagetable
Martin Schwidefsky wrote: On Sun, 2008-03-23 at 12:15 +0200, Avi Kivity wrote: Can you convert the page tables at a later time without doing a wholesale replacement of the mm? It should be a bit easier to keep people off the pagetables than keep their grubby mitts off the mm itself. Yes, as far as I can see you're right. And whatever we do in arch code, after all it's just a work around to avoid a new clone flag. If something like clone() with CLONE_KVM would be useful for more architectures than just s390 then maybe we should try to get a flag. Oh... there are just two unused clone flag bits left. Looks like the namespace changes ate up a lot of them lately. Well, we could still play dirty tricks like setting a bit in current via whatever mechanism which indicates child-wants-extended-page-tables and then just fork and be happy. How about taking mmap_sem for write and converting all page tables in-place? I'd rather avoid the need to fork() when creating a VM. That was my initial approach as well. If all the page table allocations can be fullfilled the code is not too complicated. To handle allocation failures gets tricky. At this point I realized that dup_mmap already does what we want to do. It walks all the page tables, allocates new page tables and copies the ptes. In principle I would reinvent the wheel if we can not use dup_mmap Well, dup_mm() can't work (and now that I think about it, for more reasons -- what if the process has threads?). I don't think conversion is too bad. You'd need a four-level loop to allocate and convert, and another loop to deallocate in case of error. If, as I don't doubt, s390 hardware can modify the ptes, you'd need cmpxchg to read and clear a pte in one operation. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. 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] [Qemu-devel] [PATCH] [RFC] Fix time drift of rtc clock + general support
Paul Brook wrote:
On Sunday 23 March 2008, Dor Laor wrote:
--- a/qemu/hw/irq.c
+++ b/qemu/hw/irq.c
@@ -30,6 +30,8 @@ struct IRQState {
int n;
};
+uint32_t qemu_irq_acked[NR_IRQ_WORDS];
This is absolute rubbish. The whole point of the IRQ framework is that it
doesn't assume a single flat IRQ controller.
x86 does have a single irq space (even when using cascaded pics or
multiple ioapics), called gsi (for generalized system interrupt, or
something). It is possible to enumerate all irqs on all platforms that
have a finite number of them.
It may be better though to identify an irq by a (controller_id,
irq_line) pair instead.
--
Do not meddle in the internals of kernels, for they are subtle and quick to
panic.
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
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] [Qemu-devel] [PATCH] [RFC] Fix time drift of rtc clock + general support
Avi Kivity wrote: Paul Brook wrote: a new timer will be fired to try inject it again soon (==0.1msec) If the guest is missing interrupts, the chances of a 0.1ms interval working are not great. Most likely It's either going trigger immediately, or be delayed significantly and you're going to end up even further behind. If 0.1 ms is within qemu's timeslice, then qemu should get the wakeup on time (assuming a host with high resolution timers). If triggering immediately is OK then why not do that all the time? Triggering immediately doesn't help, the guest likely has interrupts blocked processing the same interrupt. If triggering immediately is not acceptable then you're still going to loose interrupts. You're still accounting for them, so if the load decreases eventually it's going to catch up. btw, the better solution here is to wait until the guest is ready for timer interrupt injection again, but that's not as easy as arming a timer. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. 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] Qemu-kvm is leaking my memory ???
Zdenek Kabelac wrote: 2008/3/23, Avi Kivity [EMAIL PROTECTED]: Avi Kivity wrote: I see the same issue too now, and am investigating. The attached patch should fix the issue. It is present in 2.6.25-rc6 only, and not in kvm.git, which is why few people noticed it. Hi Tested - and actually seeing no difference in my case of memory leak. Still it looks like over 30M per execution of qemu is lost. (tested with fresh 2.6.25-rc6 with your patch) Can you double check? 2.6.25-rc6 definitely leaks without, and here it doesn't with the patch. Also now I'd have said that before my dmsetup status loop test case was not causing big problems and it was just enough to run another dmsetup to unblock the loop - now it's usually leads to some wierd end of qemu itself - will explore more So it's probably fixing some bug - and exposing another. As I said before - in my debuger it was looping in page_fault hadler - i.e. memory should be paged_in - but as soon as the handler return to the code to continue memcopy - new page_fault is invoked and pointer couters are not changed. I'll add some code to make it possible to enable the mmu tracer in runtime. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. 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] [Qemu-devel] [PATCH] [RFC] Fix time drift of rtc clock + general support
Paul Brook wrote:
On Monday 24 March 2008, Avi Kivity wrote:
Paul Brook wrote:
On Sunday 23 March 2008, Dor Laor wrote:
--- a/qemu/hw/irq.c
+++ b/qemu/hw/irq.c
@@ -30,6 +30,8 @@ struct IRQState {
int n;
};
+uint32_t qemu_irq_acked[NR_IRQ_WORDS];
This is absolute rubbish. The whole point of the IRQ framework is that it
doesn't assume a single flat IRQ controller.
x86 does have a single irq space (even when using cascaded pics or
multiple ioapics), called gsi (for generalized system interrupt, or
something). It is possible to enumerate all irqs on all platforms that
have a finite number of them.
Sure, it's possible to enumerate all the possible IRQ inputs (it's
effectively
the same as enumerating all the IRQ sources). It's not possible to say
anything particularly useful about that enumeration though.
It's not uncommon for interrupts to be connected to GPIO pins, be inverted,
or
have interrupt routings that change dynamically.
Right, but...
It may be better though to identify an irq by a (controller_id,
irq_line) pair instead.
That's what qemu_irq is for. Anything else is IMHO wrong.
In the case of a kernel virtualization module (like kqemu of kvm) that
is able to handle interrupt injection, qemu_irq is not sufficient since
it is not visible to the kernel. We need some serialization that can
pass the user/kernel boundary. For x86 gsi is a satisfactory serialization.
Even for a pure qemu solution, qemu_irq is difficult to work with. For
the x86 case, we know which vector was successfully injected, and we
need to work out which qemu_irq caused it. This is not deterministic in
the general case (since several irq lines can cause the same vector to
be injected, and since the irq-vector mapping can change), so any
solution will involve heuristics.
--
error compiling committee.c: too many arguments to function
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
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] Qemu-kvm is leaking my memory ???
Avi Kivity wrote:
Tested - and actually seeing no difference in my case of memory leak.
Still it looks like over 30M per execution of qemu is lost.
(tested with fresh 2.6.25-rc6 with your patch)
Can you double check? 2.6.25-rc6 definitely leaks without, and here it
doesn't with the patch.
btw, there's an additional patch I have queued up that might have an
effect. please test the attached (which is my 2.6.25 queue).
--
error compiling committee.c: too many arguments to function
diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index d8172aa..e55af12 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -222,8 +222,7 @@ static int is_io_pte(unsigned long pte)
static int is_rmap_pte(u64 pte)
{
- return pte != shadow_trap_nonpresent_pte
- pte != shadow_notrap_nonpresent_pte;
+ return is_shadow_present_pte(pte);
}
static gfn_t pse36_gfn_delta(u32 gpte)
@@ -893,14 +892,25 @@ static void mmu_set_spte(struct kvm_vcpu *vcpu, u64 *shadow_pte,
int *ptwrite, gfn_t gfn, struct page *page)
{
u64 spte;
- int was_rmapped = is_rmap_pte(*shadow_pte);
+ int was_rmapped = 0;
int was_writeble = is_writeble_pte(*shadow_pte);
+ hfn_t host_pfn = (*shadow_pte PT64_BASE_ADDR_MASK) PAGE_SHIFT;
pgprintk(%s: spte %llx access %x write_fault %d
user_fault %d gfn %lx\n,
__FUNCTION__, *shadow_pte, pt_access,
write_fault, user_fault, gfn);
+ if (is_rmap_pte(*shadow_pte)) {
+ if (host_pfn != page_to_pfn(page)) {
+ pgprintk(hfn old %lx new %lx\n,
+ host_pfn, page_to_pfn(page));
+ rmap_remove(vcpu-kvm, shadow_pte);
+ }
+ else
+ was_rmapped = 1;
+ }
+
/*
* We don't set the accessed bit, since we sometimes want to see
* whether the guest actually used the pte (in order to detect
@@ -1402,7 +1412,7 @@ static void mmu_guess_page_from_pte_write(struct kvm_vcpu *vcpu, gpa_t gpa,
up_read(current-mm-mmap_sem);
vcpu-arch.update_pte.gfn = gfn;
- vcpu-arch.update_pte.page = gfn_to_page(vcpu-kvm, gfn);
+ vcpu-arch.update_pte.page = page;
}
void kvm_mmu_pte_write(struct kvm_vcpu *vcpu, gpa_t gpa,
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 94ea724..8e14628 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -349,8 +349,6 @@ static void update_exception_bitmap(struct kvm_vcpu *vcpu)
static void reload_tss(void)
{
-#ifndef CONFIG_X86_64
-
/*
* VT restores TR but not its size. Useless.
*/
@@ -361,7 +359,6 @@ static void reload_tss(void)
descs = (void *)gdt.base;
descs[GDT_ENTRY_TSS].type = 9; /* available TSS */
load_TR_desc();
-#endif
}
static void load_transition_efer(struct vcpu_vmx *vmx)
@@ -1436,7 +1433,7 @@ static int init_rmode_tss(struct kvm *kvm)
int ret = 0;
int r;
- down_read(current-mm-mmap_sem);
+ down_read(kvm-slots_lock);
r = kvm_clear_guest_page(kvm, fn, 0, PAGE_SIZE);
if (r 0)
goto out;
@@ -1459,7 +1456,7 @@ static int init_rmode_tss(struct kvm *kvm)
ret = 1;
out:
- up_read(current-mm-mmap_sem);
+ up_read(kvm-slots_lock);
return ret;
}
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
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.h: __user requires compiler.h
Christian Borntraeger wrote: Am Freitag, 21. März 2008 schrieb Anthony Liguori: This patch breaks QEMU build when doing a 'make sync'. When you do a top-level ./configure, libkvm is built with kerneldir pointing to kvm-userspace/kernel/include. While linux/kvm.h is present there, there isn't a linux/compiler.h. I checked with make headers_install, which strips out __user and compiler.h nicely. I never tried make sync since I was not aware of it. Maybe we should generate the 'make sync' headers using 'make headers_install'. -- Any sufficiently difficult bug is indistinguishable from a feature. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. 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] question: HPET for multiple VMs
Anthony Liguori wrote: Avi Kivity wrote: And I would like to ask right and wrong to implement the functionality in terms of need and efficiency (scalability and time accuracy). I think that for newer kernels we already have the desired accuracy. We're not always good at exploiting that accuracy; hence the recent movement of the PIT implementation from userspace to the kernel. But recent discussion leads me to believe it could have been implemented with the userspace PIT as well. What do you think is needed to get the same accuracy in userspace as in kernelspace? Some mechanism that allows us to implement kvm_inject_pit_timer_irqs() and kvm_pit_timer_intr_post(). Specifically, information about whether an interrupt was actually processed, and a window for injecting missed ticks. Better yet, do you think there is a reasonable kvmctl harness we could write to quantify the PIT accuracy? kvmctl doesn't implement a pit, so no. Of course we can test any infrastructure for counting missed interrupts. It's easy enough to count timer interrupts and use compare that to an external time source to get some notion of accuracy (on varying frequencies of course). I know you mentioned before that guest CPU consumption also comes into play... I'm not quite sure why though so I'm not sure how to simulate that. It's not so easy, the code is quite tricky since the cpu processes vectors, not interrupt lines. It's also heuristic; if the guest programs some random device to share interrupts with the pit, the heursitic breaks down. This never happens in practice, though. Problems show up when both the guest and host are loaded, as then the cpu is timesliced instead of being available on demand. The nice thing about the CAP infrastructure is we can always move the PIT back to userspace. I'll happily invest some cycles here as I'm a big fan of getting rid of unneeded kernel code :-) Yes. -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. 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.h: __user requires compiler.h
Anthony Liguori wrote: This patch breaks QEMU build when doing a 'make sync'. When you do a top-level ./configure, libkvm is built with kerneldir pointing to kvm-userspace/kernel/include. While linux/kvm.h is present there, there isn't a linux/compiler.h. The host kernelpath isn't normally part of the libkvm or QEMU build. So we have a couple options. 1) make the host kernelpath (/lib/modules/$(uname -r)/build/include) part of the libkvm/QEMU build. 2) Do something else about __user Suggestions? #1 might be a pain since there may be include conflicts between the host kernel include and kernel/include. We could hack 'make sync' to strip out __user (just like we run unifdef). Of course the reasons for including linux/compiler.h are still valid, so it needs to remain. -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. 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 kvm_get_pit to libkvm.c common code
Hollis Blanchard wrote: Don't compile kvm_*_pit() on architectures whose currently supported platforms do not contain a PIT. Signed-off-by: Hollis Blanchard [EMAIL PROTECTED] diff --git a/libkvm/libkvm.h b/libkvm/libkvm.h --- a/libkvm/libkvm.h +++ b/libkvm/libkvm.h @@ -539,6 +539,7 @@ int kvm_pit_in_kernel(kvm_context_t kvm) #ifdef KVM_CAP_PIT +#if defined(__i386__) || defined(__x86_64__) || defined(__ia64__) /*! * \brief Get in kernel PIT of the virtual domain * @@ -562,6 +563,8 @@ int kvm_set_pit(kvm_context_t kvm, struc #endif +#endif + #ifdef KVM_CAP_VAPIC ia64 doesn't have an in-kernel pit? (yet?) -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. 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][QEMU] Use a separate device for in-kernel PIT
Anthony Liguori wrote: Hollis Blanchard wrote: This patch solves annoying qemu build breakage hitting PowerPC around struct kvm_pit_state, so that's another vote in favor... I have an updated version of the patch but it's breaking the build b/c something fouled up right now with configure. libkvm pulls in linux/kvm.h which wants to pull in linux/compiler.h. We don't ship a linux/compiler.h though so it's pulling from /usr/include/linux which on my system doesn't have a compiler.h. The lack of this header is causing the configure test to fail. I've attached the patch here for you to use and I'll send it out again once I figure out the fix for this linux/compiler.h. The patch suffers from the same problem as the apic split; the save/restore code is needlessly duplicated. -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. 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] 'make clean' is eager to delete config.mak files
Ryota OZAKI wrote: Hi all, Current 'make clean' deletes config.mak files so that we have to ./configure again after doing that. This behavior is different from that of standard 'make clean'. This patch introduces 'make distclean' to delete config.mak files instead of 'make clean', following a standard manner of Makefile. Applied, thanks. -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. 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 1/5] lguest: mmap backing file
Anthony Liguori wrote: If we're going to mod the kernel, how about a mmap this part of their address space and having the kernel keep the mappings in sync. But I think that if we want to get speed, we should probably be doing the copy between address spaces in-kernel so we can do lightweight exits. I don't think lightweight exits help the situation very much. The difference between a light weight and heavy weight exit is only 3-4k cycles or so. On what host cpu? IIRC the difference was bigger on Intel (and in relative terms, set to increase). in-kernel doesn't make the situation much easier. You have to map pages in from a different task. It's a lot easier if you have both guest mapped in userspace. The kernel already has everything mapped (kmap_atomic() is an addition on x86_64). -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. 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] [ANNOUNCE] kvm-guest-drivers-windows-1
Avi Kivity wrote: Daniel P. Berrange wrote: On Tue, Mar 18, 2008 at 05:01:09PM +0200, Avi Kivity wrote: This is the first release of network drivers for Windows guests running on a kvm host. The drivers are intended for Windows 2000 and Windows XP 32-bit. kvm-61 or later is needed in the host. At the moment only binaries are available. There's no license file inside the ZIP file - what license are the binaries re-distributed under ? Good question. I'll find out. I imagine they'd be freely redistributable. The binaries are free for use and redistribution for commercial and non-commercial use. The sources will be released under an open-source license, provided the Windows DDK terms permit. -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. 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 01/15] preparation: provide hook to enable pgstes in user pagetable
Heiko Carstens wrote: What you've done with dup_mm() is probably the brute-force way that I would have done it had I just been trying to make a proof of concept or something. I'm worried that there are a bunch of corner cases that haven't been considered. What if someone else is poking around with ptrace or something similar and they bump the mm_users: + if (tsk-mm-context.pgstes) + return 0; + if (!tsk-mm || atomic_read(tsk-mm-mm_users) 1 || + tsk-mm != tsk-active_mm || tsk-mm-ioctx_list) + return -EINVAL; HERE + tsk-mm-context.pgstes = 1;/* dirty little tricks .. */ + mm = dup_mm(tsk); It'll race, possibly fault in some other pages, and those faults will be lost during the dup_mm(). I think you need to be able to lock out all of the users of access_process_vm() before you go and do this. You also need to make sure that anyone who has looked at task-mm doesn't go and get a reference to it and get confused later when it isn't the task-mm any more. Therefore, we need to reallocate the page table after fork() once we know that task is going to be a hypervisor. That's what this code does: reallocate a bigger page table to accomondate the extra information. The task needs to be single-threaded when calling for extended page tables. Btw: at fork() time, we cannot tell whether or not the user's going to be a hypervisor. Therefore we cannot do this in fork. Can you convert the page tables at a later time without doing a wholesale replacement of the mm? It should be a bit easier to keep people off the pagetables than keep their grubby mitts off the mm itself. Yes, as far as I can see you're right. And whatever we do in arch code, after all it's just a work around to avoid a new clone flag. If something like clone() with CLONE_KVM would be useful for more architectures than just s390 then maybe we should try to get a flag. Oh... there are just two unused clone flag bits left. Looks like the namespace changes ate up a lot of them lately. Well, we could still play dirty tricks like setting a bit in current via whatever mechanism which indicates child-wants-extended-page-tables and then just fork and be happy. How about taking mmap_sem for write and converting all page tables in-place? I'd rather avoid the need to fork() when creating a VM. -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. 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] Qemu-kvm is leaking my memory ???
Zdenek Kabelac wrote: 2008/3/19, Avi Kivity [EMAIL PROTECTED]: Zdenek Kabelac wrote: 2008/3/19, Avi Kivity [EMAIL PROTECTED]: Zdenek Kabelac wrote: 2008/3/16, Avi Kivity [EMAIL PROTECTED]: The -vnc switch, so there's no local X server. A remote X server should be fine as well. Use runlevel 3, which means network but no local X server. Ok I've finaly got some time to make a comparable measurements about memory - I'm attaching empty trace log which is from the level where most of processes were killed (as you can see in the 'ps' trace) Then there are attachments after using qemu 7 times (log of free before execution is also attached) Both logs are after 3/proc/sys/vm/drop_cache I see the same issue too now, and am investigating. -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. 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] Qemu-kvm is leaking my memory ???
Avi Kivity wrote: I see the same issue too now, and am investigating. The attached patch should fix the issue. It is present in 2.6.25-rc6 only, and not in kvm.git, which is why few people noticed it. -- error compiling committee.c: too many arguments to function diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c index 4ba85d9..e55af12 100644 --- a/arch/x86/kvm/mmu.c +++ b/arch/x86/kvm/mmu.c @@ -1412,7 +1412,7 @@ static void mmu_guess_page_from_pte_write(struct kvm_vcpu *vcpu, gpa_t gpa, up_read(current-mm-mmap_sem); vcpu-arch.update_pte.gfn = gfn; - vcpu-arch.update_pte.page = gfn_to_page(vcpu-kvm, gfn); + vcpu-arch.update_pte.page = page; } void kvm_mmu_pte_write(struct kvm_vcpu *vcpu, gpa_t gpa, - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. 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] [Qemu-devel] Coredump from qemu
Zdenek Kabelac wrote: Hi During execution of qemu I've got this crash: #0 0x00407a29 in qemu_mod_timer (ts=0x2e8cf90, expire_time=130685351465) at /usr/src/debug/kvm-63/qemu/vl.c:1073 #1 0x00425590 in pcnet_ioport_writew (opaque=0x0, addr=1836332585, val=8090216) at /usr/src/debug/kvm-63/qemu/hw/pcnet.c:1617 #2 0x00501cf1 in kvm_outw (opaque=value optimized out, addr=13865, data=29288) at /usr/src/debug/kvm-63/qemu/qemu-kvm.c:457 #3 0x0051e2a0 in kvm_run (kvm=0x2dbb030, vcpu=1) at libkvm.c:719 #4 0x00501646 in kvm_cpu_exec (env=value optimized out) at /usr/src/debug/kvm-63/qemu/qemu-kvm.c:127 #5 0x005021a5 in kvm_main_loop_cpu (env=0x2e8f010) at /usr/src/debug/kvm-63/qemu/qemu-kvm.c:307 #6 0x00502302 in ap_main_loop (_env=value optimized out) at /usr/src/debug/kvm-63/qemu/qemu-kvm.c:338 #7 0x00353420740a in start_thread () from /lib64/libpthread.so.0 #8 0x0035336e5d1d in clone () from /lib64/libc.so.6 (gdb) print alarm_timer $1 = (struct qemu_alarm_timer *) 0x0 It happend during detach of gdb and quit of the qemu itsell - I assume no all timers were probably stoped when quit_timers was executed ? Looks like. Maybe check for non NULL pointer is enough qemu_mod_timer? I think the correct solution is to allow devices to register a shutdown function, which would be called after main_loop() (but before quit_timers) , which would execute qemu_del_timer() in the case of pcnet. It's also necessary for device hotremove. -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. 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] question: HPET for multiple VMs
Ryota OZAKI wrote: Hi all, Current kvm allows only one VM to use HPET. Is there a plan to implement a functionality to allow multiple VMs to use HPET? If so, how about the status of that? If you use the dyntick clock option (the default, IIRC), and a newer host kernel, then the kernel provides high-resolution timers, very likely using HPET internally or some other high resolution clock and event source. And I would like to ask right and wrong to implement the functionality in terms of need and efficiency (scalability and time accuracy). I think that for newer kernels we already have the desired accuracy. We're not always good at exploiting that accuracy; hence the recent movement of the PIT implementation from userspace to the kernel. But recent discussion leads me to believe it could have been implemented with the userspace PIT as well. -- Any sufficiently difficult bug is indistinguishable from a feature. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. 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 05/15] KVM_MAX_VCPUS
Carsten Otte wrote: Hollis Blanchard wrote: On Thu, 2008-03-20 at 17:24 +0100, Carsten Otte wrote: Index: kvm/include/linux/kvm_host.h === --- kvm.orig/include/linux/kvm_host.h +++ kvm/include/linux/kvm_host.h @@ -24,7 +24,11 @@ #include asm/kvm_host.h +#ifdef CONFIG_S390 +#define KVM_MAX_VCPUS 64 +#else #define KVM_MAX_VCPUS 16 +#endif #define KVM_MEMORY_SLOTS 32 /* memory slots that does not exposed to userspace */ #define KVM_PRIVATE_MEM_SLOTS 4 Why don't we just define this in asm/kvm_host.h ? No problem with that, I just wanted to keep impact on common code very low and things like this seperated from the actual port. I have a few things like this that can safely be taken care about later. Since there were a few other comments, I went ahead and moved those #defines to asm-x86. -- Any sufficiently difficult bug is indistinguishable from a feature. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. 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 00/15] kvm on big iron
Carsten Otte wrote: This patch series introduces a backend for kvm to run on IBM System z machines that uses the mainframe's sie virtualization capability. This work runs 64bit guests on z800/z890/z900/z990/z9/z10 class machines with a 64bit linux host. Userspace will follow once we're done brushing it over. I'm slightly worried about the changes to non arch code. Perhaps Andrea or Rik can look over the mm/ changes and ack? Other than that, and the few minor comments that popped up, this (very nice) patchset will be very easy to merge. IIRC you mentioned it is possible for me to get an s390 account; this will be very useful in avoiding breaking this port, as happens quite often with ppc and ia64. I'd like to be able to do both build and run testing. -- Any sufficiently difficult bug is indistinguishable from a feature. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. 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 06/15] kvm-s390: sie intercept handling
Carsten Otte wrote:
/* for KVM_RUN, returned by mmap(vcpu_fd, offset=0) */
struct kvm_run {
@@ -138,6 +139,14 @@ struct kvm_run {
__u32 is_write;
__u32 pad;
} tpr_access;
+ /* KVM_EXIT_S390_SIEIC */
+ struct {
+ __u8 icptcode;
+ __u64 mask; /* psw upper half */
+ __u64 addr; /* psw lower half */
+ __u16 ipa;
+ __u32 ipb;
+ } s390_sieic;
/* Fix the size of the union. */
char padding[256];
};
Do you support 32-bit userspace on 64-bit kernel? If so, this is likely
badly aligned.
--
Any sufficiently difficult bug is indistinguishable from a feature.
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
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 15/15] guest: virtio device support, and kvm hypercalls
Carsten Otte wrote: Currently we dont have PCI on s390. Making virtio_pci usable for s390 seems more complicated that providing an own stub. This virtio stub is similar to the lguest one, the memory for the descriptors and the device detection is made via additional mapped memory on top of the guest storage. We use an external interrupt with extint code 1237 for host-guest notification. So, sanity won in the end. -- Any sufficiently difficult bug is indistinguishable from a feature. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [kvm-ia64-devel] Cross-arch support for make sync in userspace
Zhang, Xiantao wrote: Avi Kivity wrote: Zhang, Xiantao wrote: Avi Kivity wrote: Zhang, Xiantao wrote: Hi, Avi Currently, make sync in userspace only syncs x86-specific heads from kernel source due to hard-coded in Makefile. Do you have plan to provide cross-arch support for that? No plans. I'll apply patches though. But don't you need kernel changes which make it impossible to run kvm-ia64 on older kernels? Other archs may need it for save/restore :) Save/restore? Don't understand. You know, currently make sync would sync header files to userspace from include/asm-x86/, so kvm.h and kvm_host.h are always synced from there for any archs. Since some arch-specific stuff for save/restore should be defined in include/asm-$arch/(kvm.h; kvm_host.h), so ia64 or other archs should need it when they implement save/restore. I see. But is 'make sync' actually useful for you? Can you run kvm-ia64 on top of 2.6.24, which doesn't include your ia64 core API changes? Now we don't intend to provide support for kernel which is older than 2.6.24. And we don't want to compile kernel module in userspace. But at least we need to ensure make sync work first, because we need it to guarantee Qemu to use right header files for its compilation. Xiantao I see. ./configure --with-patched-kernel should work for that, but I have no issue with copying include/asm-ia64 either. -- Any sufficiently difficult bug is indistinguishable from a feature. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] kvm-guest-drivers patch for RHEL4
david ahern wrote: Backport of the virtio drivers to RHEL4. The patch applies against the kvm-guest-drivers-linux-1 release but also contains diffs for Anthony's spin_lock_irqsave/restore patch. Of note is that to build for RHEL4 Makefile is renamed to Makefile-2.6 so that Makefile can contain the build rules for the modules. RHEL4 (AFAIK) does not contain the Kbuild stuff. The make command is then make -f Makefile-2.6 Looks much better than I feared, the #ifdef COMPAT_RHEL4s are quite small. -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] KVM: MMU: add KVM_ZAP_GFN ioctl
Marcelo Tosatti wrote:
Add an ioctl to zap all mappings to a given gfn. This allows userspace
remove the QEMU process mappings and the page without causing
inconsistency.
I'm thinking of comitting rmap_nuke() to kvm.git, and the rest to the
external module, since this is only needed on kernels without mmu notifiers.
Andrea, is rmap_nuke() suitable for the mmu notifiers pte clear callback?
Oh, and a single gfn may have multiple hvas, so we need to iterate over
something here.
Signed-off-by: Marcelo Tosatti [EMAIL PROTECTED]
diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index f0cdfba..c41464f 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -642,6 +642,67 @@ static void rmap_write_protect(struct kvm *kvm, u64 gfn)
account_shadowed(kvm, gfn);
}
+static void rmap_nuke(struct kvm *kvm, u64 gfn)
+{
+ unsigned long *rmapp;
+ u64 *spte;
+ int nuked = 0;
+
+ gfn = unalias_gfn(kvm, gfn);
+ rmapp = gfn_to_rmap(kvm, gfn, 0);
+
+ spte = rmap_next(kvm, rmapp, NULL);
+ while (spte) {
+ BUG_ON(!spte);
+ BUG_ON(!(*spte PT_PRESENT_MASK));
+ rmap_printk(rmap_nuke: spte %p %llx\n, spte, *spte);
+ rmap_remove(kvm, spte);
+ set_shadow_pte(spte, shadow_trap_nonpresent_pte);
+nuked = 1;
+ spte = rmap_next(kvm, rmapp, spte);
+ }
+ /* check for huge page mappings */
+ rmapp = gfn_to_rmap(kvm, gfn, 1);
+ spte = rmap_next(kvm, rmapp, NULL);
+ while (spte) {
+ BUG_ON(!spte);
+ BUG_ON(!(*spte PT_PRESENT_MASK));
+ BUG_ON((*spte (PT_PAGE_SIZE_MASK|PT_PRESENT_MASK)) !=
(PT_PAGE_SIZE_MASK|PT_PRESENT_MASK));
+ pgprintk(rmap_nuke(large): spte %p %llx %lld\n, spte, *spte,
gfn);
+ rmap_remove(kvm, spte);
+ --kvm-stat.lpages;
+ set_shadow_pte(spte, shadow_trap_nonpresent_pte);
+ nuked = 1;
+ spte = rmap_next(kvm, rmapp, spte);
+ }
+
+ if (nuked)
+ kvm_flush_remote_tlbs(kvm);
+}
+
+int kvm_zap_single_gfn(struct kvm *kvm, gfn_t gfn)
+{
+ unsigned long addr;
+ int have_mmu_notifiers = 0;
+
+ down_read(kvm-slots_lock);
+ addr = gfn_to_hva(kvm, gfn);
+
+ if (kvm_is_error_hva(addr)) {
+ up_read(kvm-slots_lock);
+ return -EINVAL;
+ }
+
+ if (!have_mmu_notifiers) {
+ spin_lock(kvm-mmu_lock);
+ rmap_nuke(kvm, gfn);
+ spin_unlock(kvm-mmu_lock);
+ }
+ up_read(kvm-slots_lock);
+
+ return 0;
+}
+
#ifdef MMU_DEBUG
static int is_empty_shadow_page(u64 *spt)
{
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index e65a9d6..d982ca1 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -816,6 +816,9 @@ int kvm_dev_ioctl_check_extension(long ext)
case KVM_CAP_NR_MEMSLOTS:
r = KVM_MEMORY_SLOTS;
break;
+ case KVM_CAP_ZAP_GFN:
+ r = 1;
+ break;
default:
r = 0;
break;
@@ -1636,6 +1639,15 @@ long kvm_arch_vm_ioctl(struct file *filp,
r = 0;
break;
}
+ case KVM_ZAP_GFN: {
+ gfn_t gfn;
+
+ r = -EFAULT;
+ if (copy_from_user(gfn, argp, sizeof gfn))
+ goto out;
+ r = kvm_zap_single_gfn(kvm, gfn);
+ break;
+}
default:
;
}
diff --git a/include/asm-x86/kvm_host.h b/include/asm-x86/kvm_host.h
index 024b57c..4e45bd2 100644
--- a/include/asm-x86/kvm_host.h
+++ b/include/asm-x86/kvm_host.h
@@ -425,6 +425,7 @@ void kvm_mmu_set_nonpresent_ptes(u64 trap_pte, u64
notrap_pte);
int kvm_mmu_reset_context(struct kvm_vcpu *vcpu);
void kvm_mmu_slot_remove_write_access(struct kvm *kvm, int slot);
void kvm_mmu_zap_all(struct kvm *kvm);
+int kvm_zap_single_gfn(struct kvm *kvm, gfn_t gfn);
unsigned int kvm_mmu_calculate_mmu_pages(struct kvm *kvm);
void kvm_mmu_change_mmu_pages(struct kvm *kvm, unsigned int
kvm_nr_mmu_pages);
diff --git a/include/linux/kvm.h b/include/linux/kvm.h
index e92e703..9ea714f 100644
--- a/include/linux/kvm.h
+++ b/include/linux/kvm.h
@@ -236,6 +236,7 @@ struct kvm_vapic_addr {
#define KVM_CAP_CLOCKSOURCE 8
#define KVM_CAP_NR_VCPUS 9 /* returns max vcpus per vm */
#define KVM_CAP_NR_MEMSLOTS 10 /* returns max memory slots per vm */
+#define KVM_CAP_ZAP_GFN 11
/*
* ioctls for VM fds
@@ -258,6 +259,7 @@ struct kvm_vapic_addr {
#define KVM_IRQ_LINE _IOW(KVMIO, 0x61, struct kvm_irq_level)
#define KVM_GET_IRQCHIP_IOWR(KVMIO, 0x62, struct kvm_irqchip)
#define KVM_SET_IRQCHIP_IOR(KVMIO, 0x63, struct kvm_irqchip)
+#define KVM_ZAP_GFN_IOR(KVMIO, 0x64, unsigned long)
/*
* ioctls for vcpu
Re: [kvm-devel] KVM Test result, kernel f1080a0.., userspace 49cf2d2..
Yunfeng Zhao wrote: Following issues fixed: 1. qcow based smp linux guests likely hang https://sourceforge.net/tracker/index.php?func=detailaid=1901980group_id=180599atid=893831 2. smp windows installer crashes while rebooting https://sourceforge.net/tracker/index.php?func=detailaid=1877875group_id=180599atid=893831 No idea how these were fixed. 3. Timer of guest is inaccurate https://sourceforge.net/tracker/?func=detailatid=893831aid=1826080group_id=180599 This may be the in-kernel pit. 4. Installer of 64bit vista guest will pause for ten minutes after reboot https://sourceforge.net/tracker/?func=detailatid=893831aid=1836905group_id=180599 The pit again?! Confused. -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. 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 0/4] Inter-guest virtio I/O example with lguest
Anthony Liguori wrote: Avi Kivity wrote: Rusty Russell wrote: Hi all, Just finished my prototype of inter-guest virtio, using networking as an example. Each guest mmaps the other's address space and uses a FIFO for notifications. Isn't that a security hole (hole? chasm)? If the two guests can access each other's memory, they might as well be just one guest, and communicate internally. Each guest's host userspace mmaps the other guest's address space. The userspace then does a copy on both the tx and rx paths. Well, that's better security-wise (I'd still prefer to avoid it, so we can run each guest under a separate uid), but then we lose performance wise. Conceivably, this could be done as a read-only mapping so that each guest userspace copies only the rx packets. That's about as secure as you're going to get with this approach I think. Maybe we can terminate the virtio queue in the host kernel as a pipe, and splice pipes together. That gives us guest-guest and guest-process communications, and if you use aio the kernel can use a dma engine for the copy. -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. 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 0/4] Inter-guest virtio I/O example with lguest
Anthony Liguori wrote: Avi Kivity wrote: Anthony Liguori wrote: Avi Kivity wrote: Each guest's host userspace mmaps the other guest's address space. The userspace then does a copy on both the tx and rx paths. Well, that's better security-wise (I'd still prefer to avoid it, so we can run each guest under a separate uid), but then we lose performance wise. What performance win? I'm not sure the copies can be eliminated in the case of interguest IO. I guess not. But at least you can dma instead of busy-copying. Fast interguest IO means mmap()'ing the other guest's address space read-only. This implies trusting the other userspace, which is not a good thing. Let the kernel copy, we already trust it, and it has more resources to do the copy. If you had a pv dma registration api you could conceivably only allow the active dma entries to be mapped but my fear would be that the zap'ing on unregister would hurt performance. Yes, mmu games are costly. They also only work on page granularity which isn't always possible to guarantee. Conceivably, this could be done as a read-only mapping so that each guest userspace copies only the rx packets. That's about as secure as you're going to get with this approach I think. Maybe we can terminate the virtio queue in the host kernel as a pipe, and splice pipes together. That gives us guest-guest and guest-process communications, and if you use aio the kernel can use a dma engine for the copy. Ah, so you're looking to use a DMA engine for accelerated copy. Perhaps the answer is to expose the DMA engine via a userspace API? That's one option, but it still involves sharing all of memory. Splicing pipes might be better. -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. 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 1/5] lguest: mmap backing file
Anthony Liguori wrote: Rusty Russell wrote: From: Paul TBBle Hampson [EMAIL PROTECTED] This creates a file in $HOME/.lguest/ to directly back the RAM and DMA memory mappings created by map_zeroed_pages. I created a test program recently that measured the latency of a reads/writes to an mmap() file in /dev/shm and in a normal filesystem. Even after unlinking the underlying file, the write latency was much better with a mmap()'d file in /dev/shm. Surely the difference disappears once the pages have been faulted in? -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. 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 0/4] Inter-guest virtio I/O example with lguest
Anthony Liguori wrote: You can have the file descriptor be opened O_RDONLY so trust isn't an issue. Reading is just as bad as writing. This implies trusting the other userspace, which is not a good thing. Let the kernel copy, we already trust it, and it has more resources to do the copy. You're going to end up with the same trust issues no matter what unless you let the kernel look directly at the virtio ring queue. That's the only way to arbitrate what memory gets copied. That's what we need, then. There may be a generic API here for fast interprocess IO, I don't know. splice() is a little awkward though for this because you really don't want to sit in a splice() loop. What you want is for both sides to be kick'ing the kernel and the kernel to raise an event via eventfd() or something. Absent whatever this kernel API is (which is really just helpful with a DMA engine), I think the current userspace approach is pretty reasonable. Not just for interguest IO but also for driver domains which I think is a logical extension. I disagree. A driver domain is shared between multiple guests, and if one of the guests manages to break into qemu then it can see other guest's data. [Driver domains are a horrible idea IMO, but that's another story] -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. 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] windows acpi time drift
Anthony Liguori wrote: Why don't we just introduce a vm-ioctl interface for a one-shot programmable timer? It could be programmed in userspace, and when it fires, we can drop down to userspace with a special exit code. We could then introduce an interrupt queuing mechanism in the kernel specifically for timer interrupts as you mention. That lets us remove the in-kernel PIT, and makes all of our timer mechanisms more accurate. If userspace has a better time mechanism, like hrtimer, then it can just use that. If hrtimer is good enough in userspace, then we can contain these new ioctls to the compat-code only. The problems with timers are: - on a loaded machine, several timer ticks may be coalesced together on the host side; we need a way to detect overruns - with one-shot processing, there is inevitable drift. so we need to use periodic timers or to compensate for the drift - when we have accumulated missed interrupts, we need to inject them - we may need to coordinate tsc and timer values (like Xen) the first two problems seem to be resolvable via posix timers (timer_create() friends). The third issue can be resolved by adding an ioctl to queue a bunch of injections (raising and lowering a specific line after the ack). The fourth is probably impossible from userspace (and very difficult in the kernel). -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. 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] convert init_rmode_tss to slots_lock
Marcelo Tosatti wrote: init_rmode_tss was forgotten during the conversion from mmap_sem to slots_lock. Applied, thanks. There are several sites reading the slots data without taking slots_lock, including tdp_page_fault. I'll be sending a patch to move acquision to vcpu_run as suggested by Avi later today. You'll need to acquire it for KVM_SET_MSRS (since that can trigger a write, if writing to the clock base). -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. 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] script for watching kvm_stat
Christian Ehrhardt wrote: I added the kvm_stat support to ppc to watch my guest while executing e.g. to check things like what does my guest do when I see nothing ;-) To be able to do that I also needed a script that reports in a iostat/vmstat like style, because of that I wrote a small shell script. Additionally my colleague Christian Bornträger had the need for a top style output and wrote a script for that need. I attached both to help everyone experimenting with kvm_stat. They are just small helpers and might still contain issues, feel free to comment, correct, whatever ;-) Are you aware of the kvm_stat python script in kvm-userspace.git? -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. 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] manage number of VCPU and memory
břeťa wrote: Hi, I want to ask for a help in searching specific documetation. I am looking for any information about how to change the number of VCPU and amount of memory while the VM is running (or at least the magic keywords for google; I was successful in searching information about how to do that in Xen but not in the KVM). Thanks in advance for any advices or links. There is the cpu_set command in the qemu monitor. -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. 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] vmwarevga merge clash
Anthony Liguori wrote: Avi Kivity wrote: Trying to merge qemu-cvs, there's a conflict in vmwarevga between two changes that appear to be identical in purpose, only implemented differently: 6d262b07a2046ed1fa0ec3fd61f00efbfcd5a9ef (master) and 5aa90452c52e3a914e1f6bbf34331507fd7c5d52 (qemu-cvs). I think the correct action is to drop the local changes and accept the qemu-cvs commit. Can you confirm? qemu cvs still sets the BAR registers which KVM didn't seem to like. However, I believe that what is in QEMU CVS is correct and that removing explicit BAR register setting is simply hiding a KVM bug. I'd suggest dropping the local changes and I'll investigate further. Okay, did just that. vmwarevga.c is now identical to qemu-cvs. -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. 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] [ANNOUNCE] kvm-driver-disc-20080318
Anthony Liguori wrote: david ahern wrote: Are you interested in collecting ports of the drivers for various distributions? What we would like to do, is have the kvm-guest-drivers-linux.git tree autogenerate backports for as far back as we need them. Posting what you needed to do for RHEL4 would be helpful. What would be most helpful is actually submitting a patch to that repo that did the awk/cpp magic to generate the backport. It might be difficult for RHEL 4, which is 2.6.5 based IIRC. If the magic required is more that 500 millithaums, then an independent driver would be better. -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. 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] Fix sci irq set when acpi timer about to wrap
Dor Laor wrote: On Sun, 2008-03-16 at 19:08 +0200, Avi Kivity wrote: Dor Laor wrote: From 498f162fc9d9fb897c756273c481101a44a220de Mon Sep 17 00:00:00 2001 From: Dor Laor [EMAIL PROTECTED] Date: Thu, 13 Mar 2008 00:11:41 +0200 Subject: [PATCH] Fix sci irq set when acpi timer about to wrap. The acpi timer should generate sci irq when enabled and when bit 23 of the timer counter toogles. It fixes time reading by the performance counter api of windows guest. How does this relate to ce35c9534137b71327466fa9abc243cbe2d7e8dc? It was buggy with the above commit. The code not only fix it but also makes it more readable. Okay, applied, thanks. -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. 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] windows acpi time drift
Anthony Liguori wrote: Avi Kivity wrote: The fourth is probably impossible from userspace (and very difficult in the kernel). What makes it impossible to do in userspace? If you managed a tsc_offset in userspace, you would of course need to adjust that tsc_offset within the kernel for the particular PCPU that you were on. In the kernel you can to tricks like local_irq_disable(); rdtsc(); ktime_get(); local_irq_enable() to get a sense where the tsc is. Take a look at kvm_inject_pit_timer_irqs() and kvm_pit_timer_intr_post(). An attempt to have a accurate userspace pit needs to take into account what those functions do. I believe it's doable, but will require careful design of the interface (which should be usable for rtc and hpet as well). -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. 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] [ANNOUNCE] kvm-driver-disc-20080318
david ahern wrote: Avi Kivity wrote: It might be difficult for RHEL 4, which is 2.6.5 based IIRC. If the magic required is more that 500 millithaums, then an independent driver would be better. RHEL4 is based on 2.6.9. What do you mean by magic required is more that 500 millithaums? A Thaum is the amount of magic required to conjure one standard white pigeon. I meant that the amount of changes needed to port the driver to 2.6.9 is too large, the script to do automatic backporting might turn out to be less maintainable than keeping an independent source tree. We're not far from that point even for 2.6.18; for example running the script against 2.6.25-current will produce an unbuildable driver. -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. 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] Qemu-kvm is leaking my memory ???
Zdenek Kabelac wrote: 2008/3/16, Avi Kivity [EMAIL PROTECTED]: Zdenek Kabelac wrote: Hello Recently I'm using qemu-kvm on fedora-rawhide box with my own kernels (with many debug options) I've noticed that over the time my memory seems to disappear somewhere. Here is my memory trace after boot and some time of work - thus memory should be populated. No idea how these should add up. What does 'free' say? Ok - here goes my free log (I'm loggin free prior each start of my qemu-kvm so here is the log for this afternoon: (I'm running same apps all the time - except during kernel compilation I'm reading some www pages - and working with gnome-terminal - so some slightly more memory could have been eaten by them - but not in the range of hundreds of MB) Can you make sure that it isn't other processes? Go to runlevel 3 and start the VM using vnc or X-over-network? What host kernel and kvm version are you using? -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. 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] Qemu-kvm is leaking my memory ???
Zdenek Kabelac wrote: 2008/3/19, Avi Kivity [EMAIL PROTECTED]: Zdenek Kabelac wrote: 2008/3/16, Avi Kivity [EMAIL PROTECTED]: Zdenek Kabelac wrote: Hello Recently I'm using qemu-kvm on fedora-rawhide box with my own kernels (with many debug options) I've noticed that over the time my memory seems to disappear somewhere. Here is my memory trace after boot and some time of work - thus memory should be populated. No idea how these should add up. What does 'free' say? Ok - here goes my free log (I'm loggin free prior each start of my qemu-kvm so here is the log for this afternoon: (I'm running same apps all the time - except during kernel compilation I'm reading some www pages - and working with gnome-terminal - so some slightly more memory could have been eaten by them - but not in the range of hundreds of MB) Can you make sure that it isn't other processes? Go to runlevel 3 and start the VM using vnc or X-over-network? Hmmm not really sure what do you mean by external VNC - I could grab this info once I'll finish some work today and kill all the apps running in the system - so most of the memory should be released - will go to single mode for this - is this what do you want ? The -vnc switch, so there's no local X server. A remote X server should be fine as well. Use runlevel 3, which means network but no local X server. What host kernel and kvm version are you using? Usually running quite up-to-date Linus git tree kernel - Both host/guest are running 2.6.25-rc6 kernels For compiling using gcc-4.3 kvm itself is fedora rawhide package: kvm-63-2.fc9.x86_64 (somehow I've troubles to compile the kvm-userspace git tree as libkvm mismatches my kernel version - which probably means I would have to use kvm linux kernel to use kvm-userspace ??) If running kvm.git, do ./configure --with-patched-kernel. Please report kvm compiler errors. (actually why the gcc-3.x is preferred when this compiler is IMHO far more broken then 4.3 ?) qemu requires gcc 3. The kernel may be compiled with any gcc that it supports. -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. 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] windows acpi time drift
Dor Laor wrote: On Wed, 2008-03-19 at 17:39 +0200, Avi Kivity wrote: Anthony Liguori wrote: Avi Kivity wrote: The fourth is probably impossible from userspace (and very difficult in the kernel). What makes it impossible to do in userspace? If you managed a tsc_offset in userspace, you would of course need to adjust that tsc_offset within the kernel for the particular PCPU that you were on. In the kernel you can to tricks like local_irq_disable(); rdtsc(); ktime_get(); local_irq_enable() to get a sense where the tsc is. but you can also do it before the vcpu goes to userspace after vmexit. You only want to do it when needed. We might add an ioctl for it, but it's tricky. Take a look at kvm_inject_pit_timer_irqs() and kvm_pit_timer_intr_post(). An attempt to have a accurate userspace pit needs to take into account what those functions do. I believe it's doable, but will require careful design of the interface (which should be usable for rtc and hpet as well). Actually I'm coming to think we don't need a irq queue in the kernel. We just need to count the pending timer interrupts in userspace and change the qemu_set_irq interface to return a status when the irq was really injected by pic/apic (like kvm_pit_timer_intr_post). This way qemu timer devices will not inject another irq until the previous irq got ack by the kernel (or even userspace pic/acpi). Yes, I think you're right. We can return the information in the vcpu shared area, so it doesn't generate new exits. -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. 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] Cross-arch support for make sync in userspace
Zhang, Xiantao wrote: Hi, Avi Currently, make sync in userspace only syncs x86-specific heads from kernel source due to hard-coded in Makefile. Do you have plan to provide cross-arch support for that? No plans. I'll apply patches though. But don't you need kernel changes which make it impossible to run kvm-ia64 on older kernels? Other archs may need it for save/restore :) Save/restore? Don't understand. -- Any sufficiently difficult bug is indistinguishable from a feature. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. 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] tools to dump guest memory and generate core file
david ahern wrote: Attaching gdb to qemu you work with addresses as seen by the qemu process; the idea is to work with addresses as seen inside the guest. For example, in the qemu console you can examine guest kernel memory such as task structs using guest kernel based addresses: (qemu) x /128w 0xc0327a80 c0327a80: 0x 0xc039a000 0x0002 0x c0327a90: 0x 0x 0x008c 0x0078 c0327aa0: 0xc0327aa0 0xc0327aa0 0x 0x c0327ab0: 0xff9b 0xdae71a00 0x003d098c 0xdae71a00 c0327ac0: 0x003d098c 0x 0x 0x ... where 0xc0327a80 is the address of the first task (init_task symbol). This form is really painful to decipher much less follow the task list. Now, if you attach gdb to the qemu process, gdb /usr/local/bin/qemu-system-x86_64 2346 I meant connecting to the gdb stub in qemu that represents the guest: (gdb) target remote localhost:1234 Of course, it means starting qemu with the gdb stub enabled. We might add a monitor command to start it after the fact. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. 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] shrinker support for the mmu cache
Marcelo Tosatti wrote: On Mon, Mar 17, 2008 at 04:41:18PM +0200, Avi Kivity wrote: Marcelo Tosatti wrote: While aging is not too hard to do, I don't think it would add much in practice; we rarely observe mmu shadow pages being recycled due to memory pressure. So this is mostly helpful for preventing a VM from pinning memory when under severe memory pressure, where we don't expect good performance anyway. Issue is that the shrinker callback will not be called only under severe memory pressure, but for normal system pressure too. How much shrinkage goes on under normal pressure? It depends on the number of LRU pages scanned and the size of the cache. Roughly the number of LRU pages scanned divided by shrinker-seeks, relative to cache size (mm/vmscan.c shrink_slab). Since the maximum cache size is a small fraction of memory size, I think we should be okay here. Rebuilding a single shadow page costs a maximum of 512 faults (so about 1 msec). If the shrinker evicts one entry per second, this is a performance hiy of 0.1%. Perhaps if we set the cost high enough, the normal eviction rate will be low enough. I think its pretty easy to check for the referenced bit on pages to avoid recently used ones from being zapped. Not so easy: - the pages don't have an accessed bit, the parent ptes do, so we need to scan the parent ptes list - pages start out referenced, so we need to age them in two stages: first clear the accessed bits (and move them back to the tail of the queue); if we find a page on the head with all accessed bits clear, we can throw it away. - root pages don't have parent ptes, so we need to track access to them manually - if the accessed bit clearing rate is too high, it loses its meaning Nothing horribly hard, but not trivial either. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [patch 0/3] QEMU: virtio should register power of two sized regions
Marcelo Tosatti wrote: Otherwise the guest will miscalculate the region size. Applied all, thanks. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. 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] use slots_lock to protect writes to the wall clock
Glauber Costa wrote: As Marcelo pointed out, we need slots_lock to protect against slots changing under our nose during wall clock writing. This patch address this issue. Applied, thanks. This lock is fairly annoying. What do you think about taking it in vcpu_run unconditionally and only dropping it while in guest mode? Most exits are mmu (or with npt, mmio) so they need to take it anyway. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 0/3] kvmclock: shutdown clock before reboot
Glauber Costa wrote: Avi, This series now apply ontop of kvm.git. Only the needed function from machine_ops is made non-static. Applied, thanks. Ingo, can you carry the first two patches as well? They are 602ac559a208ba44d5879a8e6381a379b376a8b7 and 0c7f95e535a02caba52f944f067fbc05a0608cc1 in kvm.git (git://git.kernel.org/pub/scm/linux/kernel/git/avi/kvm.git). -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. 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.h: __user requires compiler.h
Christian Borntraeger wrote:
include/linux/kvm.h defines struct kvm_dirty_log to
[...]
union {
void __user *dirty_bitmap; /* one bit per page */
__u64 padding;
};
__user requires compiler.h to compile. Currently, this works on x86
only coincidentally due to other include files. This patch makes
kvm.h compile in all cases.
Applied, thanks.
--
Do not meddle in the internals of kernels, for they are subtle and quick to
panic.
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
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] vmwarevga merge clash
Trying to merge qemu-cvs, there's a conflict in vmwarevga between two changes that appear to be identical in purpose, only implemented differently: 6d262b07a2046ed1fa0ec3fd61f00efbfcd5a9ef (master) and 5aa90452c52e3a914e1f6bbf34331507fd7c5d52 (qemu-cvs). I think the correct action is to drop the local changes and accept the qemu-cvs commit. Can you confirm? -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 0/3] kvmclock: shutdown clock before reboot
Avi Kivity wrote: Glauber Costa wrote: Avi, This series now apply ontop of kvm.git. Only the needed function from machine_ops is made non-static. Applied, thanks. Er, compilation breaks if CONFIG_KEXEC is not set (i386). -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. 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] use slots_lock to protect writes to the wall clock
Glauber Costa wrote: This lock is fairly annoying. What do you think about taking it in vcpu_run unconditionally and only dropping it while in guest mode? Most exits are mmu (or with npt, mmio) so they need to take it anyway. Can't see the point. This is taken before updates to the wall clock, not system time. I mean in general, not related to wall clock. [EMAIL PROTECTED] linux-2.6 (master)]$ git grep down_read.*slots_lock arch/x86/kvm/ | wc -l 16 We take the lock for read 16 times, could be narrowed down to probably once (with a drop and re-take around guest mode). -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. 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] use slots_lock to protect writes to the wall clock
Glauber Costa wrote: [EMAIL PROTECTED] linux-2.6 (master)]$ git grep down_read.*slots_lock arch/x86/kvm/ | wc -l 16 We take the lock for read 16 times, could be narrowed down to probably once (with a drop and re-take around guest mode). Since it will be written to so rarely, that's probably fine. Moreover, the time setting up guest entry and handling exits is bounded and usually short. [We need to drop the lock when emulating hlt, too, for this to hold] -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 0/3 - resend] kvmclock reboot
Glauber Costa wrote: Avi, Hope this series is okay now. Thanks for the testing Applied, thanks. [Once a patchset has been applied and pushed (as seen on kvm-commits), I prefer incremental patches] -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 0/3 - resend] kvmclock reboot
Glauber Costa wrote: [Once a patchset has been applied and pushed (as seen on kvm-commits), I prefer incremental patches] But I think this is a very good case of an exception, since the applied patches would break bisect. I prefer to hear damn glommer! because of that than damn glommer!! because of a broken bisect. I fold them up before sending to Linus anyway, so upstream bisect continues to work. For kvm.git, it's a choice between rewinding it a bit (which may confuse anyone who pulls) and breaking bisect. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [ANNOUNCE] kvm-guest-drivers-windows-1
This is the first release of network drivers for Windows guests running on a kvm host. The drivers are intended for Windows 2000 and Windows XP 32-bit. kvm-61 or later is needed in the host. At the moment only binaries are available. The drivers are available from the download page of the kvm website, below. To use, download the drivers into the guest (using one of the emulated network cards), and unpack the package. Reboot with '-net nic,model=virtio' instead of the usual setting, and when Windows prompts you for a driver location, select the appropriate directory in the package (Windows XP or Windows 2000). Initial release: - kvm network drivers for Windows 2000 and Windows XP (Yan Vugenfirer, Dor Laor) http://kvm.qumranet.com/ -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. 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] [ANNOUNCE] kvm-guest-drivers-windows-1
Daniel P. Berrange wrote: On Tue, Mar 18, 2008 at 05:01:09PM +0200, Avi Kivity wrote: This is the first release of network drivers for Windows guests running on a kvm host. The drivers are intended for Windows 2000 and Windows XP 32-bit. kvm-61 or later is needed in the host. At the moment only binaries are available. There's no license file inside the ZIP file - what license are the binaries re-distributed under ? Good question. I'll find out. I imagine they'd be freely redistributable. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. 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 17/24] QEMU/KVM: add cpu_unregister_io_memory and make io mem table index dynamic
Amit Shah wrote: So does the following fix the problem? Yes, it does. Thanks. Okay, applied. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [ANNOUNCE] kvm-driver-disc-20080318
This is the first release of the kvm drivers disc -- a collection of kvm guest drivers packaged as an ISO 9660 CD-ROM for easy installation. The driver disc can be obtained from the kvm download page, below. Initial release: - kvm-guest-drivers-linux-1 - kvm-guest-drivers-windows-1 http://kvm.qumranet.com -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. 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] [ANNOUNCE] kvm-guest-drivers-windows-1
Ian Kirk wrote: Avi Kivity wrote: This is the first release of network drivers for Windows guests running on a kvm host. Any plans for Windows Server IIUC the XP drivers should also work for Windows 2003 Server. Windows 2008 Server and x64 variants are planned. and block support? No plans at this point. SCSI emulation should provide decent performance. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH/RFC 1/2] anon-inodes: Remove fd_install() from anon_inode_getfd()
Christoph Hellwig wrote:
On Sat, Mar 08, 2008 at 06:45:34PM -0800, Roland Dreier wrote:
spin_lock(kvm_lock);
+ if (--kvm-refcount) {
+ spin_lock(kvm_lock);
obvious typo here...
Indeed. Any comments from the kvm developers in this approach? The
current multi-level file refcounting seems rather bogus so I'd like
to make some progress on this.
I'm okay with switching away from the file-based refcounts to a refcount
embedded in the kvm structures, though I'm not particularly thrilled by
it. Any reason not to use krefs for this?
--
error compiling committee.c: too many arguments to function
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
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] tools to dump guest memory and generate core file
david ahern wrote: Does anyone know of tools that can dump memory for a qemu guest with addresses as seen by the guest and generate a core file? For instance, say you know the guest is running a 32-bit linux kernel with a 1G/3G split. Then you would want to dump 1G of memory starting 0xc000 and create an ELF core file. The core file could then be analyzed using tools like crash (or gdb for the truly adventurous). I know VMware can take a snapshot and generate such a core file. Does a similar tool exist for qemu? I see that the qemu console supports a raw memory dump, so it should be possible. (Note I am not talking about a core file of the qemu process, but rather a core file based on guest memory addressing.) You might try connecting with gdb and using the generate-core-file command. -- Any sufficiently difficult bug is indistinguishable from a feature. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [patch 0/3] QEMU balloon support
Marcelo Tosatti wrote:
Hi Avi,
Good that you're back.
On Sun, Mar 16, 2008 at 04:00:06PM +0200, Avi Kivity wrote:
Marcelo Tosatti wrote:
This patchset resends Anthony's QEMU balloon support plus:
- Truncates the target size to ram size
- Enables madvise() conditioned on KVM_ZAP_GFN ioctl
Once mmu notifiers are in, KVM_ZAP_GFN isn't needed. So we have three
possible situations:
- zap needed, but not available: don't madvise()
- zap needed and available: zap and madvise()
- zap unneeded: madvise()
Right. That is what the patch does. You just have to fill in
have_mmu_notifiers here:
+int kvm_zap_single_gfn(struct kvm *kvm, gfn_t gfn)
+{
+ unsigned long addr;
+ int have_mmu_notifiers = 0;
+
+ down_read(kvm-slots_lock);
+ addr = gfn_to_hva(kvm, gfn);
+
+ if (kvm_is_error_hva(addr)) {
+ up_read(kvm-slots_lock);
+ return -EINVAL;
+ }
+
+ if (!have_mmu_notifiers) {
+ spin_lock(kvm-mmu_lock);
+ rmap_nuke(kvm, gfn);
+ spin_unlock(kvm-mmu_lock);
+ }
+ up_read(kvm-slots_lock);
So as to avoid rmap_nuke, since that will be done through the madvise()
path.
Why not do it in userspace?
I'll likely merge zap directly into the backwards compatibility support
(it won't ever appear in mainline since mmu notifiers will be merged
sooner).
Did you find out what's causing the errors in the first place (if zap is
not used)? It worries me greatly.
Yes, the problem is that the rmap code does not handle the qemu process
mappings from vanishing while there is a present rmap. If that happens,
and there is a fault for a gfn whose qemu mapping has been removed, a
different physical zero page will be allocated:
rmap a - gfn 0 - physical host page 0
mapping for gfn 0 gets removed
guest faults in gfn 0 through the same pte chain
rmap a - gfn 0 - physical host page 1
When instantiating the shadow mapping for the second time, the
is_rmap_pte check succeeds, so we release the reference grabbed by
gfn_to_page() at mmu_set_spte(). We now have a shadow mapping pointing
to a physical page without having an additional reference on that page.
The following makes the host not crash under such a condition, but the
condition itself is invalid leading to inconsistent state on the guest.
So IMHO it shouldnt be allowed to happen in the first place.
The only way to prevent it is with mmu notifiers, which we may not have
for 2.6.25. So I'd like to send this for 2.6.25-rc.
Please add a signoff.
diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index f0cdfba..4c93b79 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -1009,6 +1009,21 @@ struct page *gva_to_page(struct kvm_vcpu *vcpu, gva_t
+gva)
return page;
}
+static int was_spte_rmapped(struct kvm *kvm, u64 *spte, struct page *page)
+{
+ int ret = 0;
+ unsigned long host_pfn = (*spte PT64_BASE_ADDR_MASK) PAGE_SHIFT;
hfn_t hfn
+
+ if (is_rmap_pte(*spte)) {
+ if (host_pfn != page_to_pfn(page))
+ rmap_remove(kvm, spte);
+ else
+ ret = 1;
+ }
+
+ return ret;
+}
+
static void mmu_set_spte(struct kvm_vcpu *vcpu, u64 *shadow_pte,
unsigned pt_access, unsigned pte_access,
int user_fault, int write_fault, int dirty,
@@ -1016,7 +1031,7 @@ static void mmu_set_spte(struct kvm_vcpu *vcpu, u64
+*shadow_pte,
struct page *page)
{
u64 spte;
- int was_rmapped = is_rmap_pte(*shadow_pte);
+ int was_rmapped = was_spte_rmapped(vcpu-kvm, shadow_pte, page);
int was_writeble = is_writeble_pte(*shadow_pte);
Calling code with side effects in an initializer is a bit confusing. I
suggest simply inlining the code into mmu_set_spte().
--
error compiling committee.c: too many arguments to function
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
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] debugfs directory for each VM
Ryota OZAKI wrote: Hi all, This patch allows a VM to have own directory on debugfs, that contains statics only for the VM. Each directory is identified by the pid of the VM (ie qemu). I tried this patch under several host kernel versions, .22, .23, and .24, and confirmed things work out well. Nice patch; it's certainly useful to improve per-vm trace capabilities. It would be nice to keep the summary, since that allows running kvm_stat with no arguments. On the other hand, the kvmtrace patchset recently posted adds much more detailed data; we should probably concentrate on that as a means of improving performance tracing. -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] KVM Test result, kernel a16664b.., userspace 3017d05.. one new issue
Yunfeng Zhao wrote: Hi All, This is today's KVM test result against kvm.git a16664b59065b8ae877b213e68a6f962ac359ca4 and kvm-userspace.git 3017d054a6a9f37bfffee4ebf0bf52a51c9860b5. One new issue: 1. booting smp windows guests has 30% chance of hang https://sourceforge.net/tracker/?func=detailatid=893831aid=1910923group_id=180599 Is this a regression? What was the last known good commit? -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. 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
