[kvm-devel] www.prestocash.com.ar
Please see this site in Subject - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] [PATCH 1/3] virtio infrastructure
Anthony Liguori wrote: > Dor Laor wrote: >> Anthony Liguori wrote: >> >>> Hi Dor, >>> >>> I can't tell if you made any changes to this series. I have to look >>> back to my notes, but I believe it would be okay to pull this series >>> into KVM. I still need to spend some time updating the patchset to >>> be more friendly for QEMU though before resubmitting to qemu-devel. >>> Any help on making it more cross-architecture friendly would be >>> appreciated! >>> >>> >> Hi, >> >> I didn't do any change (except maybe very very minor adjustments for >> it to match existing version, nothing risky). >> The reason I sent it as it is + non-qemu-standard performance >> optimization is to finally have descent performance for KVM IO. >> My next step is to add backward compatibility support for older >> guests and then to implement host kernel module for network. >> > > I have backports up to 2.6.18 although I need to write the awk scripts > to make it automatic. If you can wait until the middle of the week > when I get back into the office, I'll post it. > > Regards, > > Anthony Liguori > Superb, I'll happily wait. >> I hope that someone will pick up the qemu part since it's important >> too, especially the block device and new devices too. >> There is also work in progress to move the balloon driver over virtio. >> Thanks, >> Dor. >> >>> Regards, >>> >>> Anthony Liguori >>> >>> [EMAIL PROTECTED] wrote: >>> From: Dor Laor <[EMAIL PROTECTED]> This patch implements the basic infrastructure for virtio devices. These devices are exposed to the guest as real PCI devices. The PCI vendor/device IDs have been donated by Qumranet and the subsystem IDs are used to distinguish the virtio device itself. Virtio provides an abstraction for performing guest=>host and host=>guest communications. It also provides a standard ring queue interface and discovery mechanism. Finally, virtio provides a simple mechanism for passing configuration between host and guest. In this virtio implementation, we provide these things via normal PCI operations. The Linux kernel support for this virtio device is pending in Rusty's virtio patch queue[1]. They should be submitted once the merge window opens again. Some future TODOs are to use endian/alignment safe routines when accessing the virtqueue so that mixed mode host/guests are supported. [1] http://ozlabs.org/~rusty/kernel/hg Signed-off-by: Anthony Liguori <[EMAIL PROTECTED]> Cc: Rusty Russell <[EMAIL PROTECTED]> Cc: Avi Kivity <[EMAIL PROTECTED]> Cc: Dor Laor <[EMAIL PROTECTED]> --- qemu/Makefile.target |3 + qemu/hw/virtio.c | 422 ++ qemu/hw/virtio.h | 143 + 3 files changed, 568 insertions(+), 0 deletions(-) create mode 100644 qemu/hw/virtio.c create mode 100644 qemu/hw/virtio.h diff --git a/qemu/Makefile.target b/qemu/Makefile.target index 12fb043..8b5853b 100644 --- a/qemu/Makefile.target +++ b/qemu/Makefile.target @@ -463,6 +463,9 @@ VL_OBJS += rtl8139.o # PCI Hypercall VL_OBJS+= hypercall.o +# virtio devices +VL_OBJS += virtio.o + ifeq ($(TARGET_BASE_ARCH), i386) # Hardware support VL_OBJS+= ide.o pckbd.o ps2.o vga.o $(SOUND_HW) dma.o diff --git a/qemu/hw/virtio.c b/qemu/hw/virtio.c new file mode 100644 index 000..6a1d380 --- /dev/null +++ b/qemu/hw/virtio.c @@ -0,0 +1,422 @@ +/* + * Virtio Support + * + * Copyright IBM, Corp. 2007 + * + * Authors: + * Anthony Liguori <[EMAIL PROTECTED]> + * + * This work is licensed under the terms of the GNU GPL, version 2. See + * the COPYING file in the top-level directory. + * + */ + +#include +#include + +#include "virtio.h" +#include "sysemu.h" + +/* from Linux's linux/virtio_pci.h */ + +/* A 32-bit r/o bitmask of the features supported by the host */ +#define VIRTIO_PCI_HOST_FEATURES0 + +/* A 32-bit r/w bitmask of features activated by the guest */ +#define VIRTIO_PCI_GUEST_FEATURES4 + +/* A 32-bit r/w PFN for the currently selected queue */ +#define VIRTIO_PCI_QUEUE_PFN8 + +/* A 16-bit r/o queue size for the currently selected queue */ +#define VIRTIO_PCI_QUEUE_NUM12 + +/* A 16-bit r/w queue selector */ +#define VIRTIO_PCI_QUEUE_SEL14 + +/* A 16-bit r/w queue notifier */ +#define VIRTIO_PCI_QUEUE_NOTIFY16 + +/* An 8-bit device status register. */ +#define VIRTIO_PCI_STATUS18 + +/* An 8-bit r/o interrupt status register. Reading the valu
Re: [kvm-devel] [PATCH 0/4] Updated kvm mmu scaling patch
Avi Kivity wrote:
The following patchset, based on Marcelo's original mmu scaling patch,
allows the kvm guest walker to run concurrently. Shadow pagetable
manipulation is still single threaded.
Handling pte writes is similar to an early version of the patchset: the page
is derived from the guest pte being written. Unlike the original version,
we only "guess" the gfn (based on the current paging mode), and if we are
wrong, we just throw the page away.
The attached patch is needed as well.
--
error compiling committee.c: too many arguments to function
>From 53015fc9df345a58f96375e082083a108eaaf1da Mon Sep 17 00:00:00 2001
From: Avi Kivity <[EMAIL PROTECTED]>
Date: Mon, 31 Dec 2007 15:27:49 +0200
Subject: [PATCH] KVM: MMU: Move kvm_free_some_pages() into critical section
If some other cpu steals mmu pages between our check and an attempt to
allocate, we can run out of mmu pages. Fix by moving the check into the
same critical section as the allocation.
Signed-off-by: Avi Kivity <[EMAIL PROTECTED]>
---
arch/x86/kvm/mmu.c |9 +++--
arch/x86/kvm/paging_tmpl.h |1 +
2 files changed, 4 insertions(+), 6 deletions(-)
diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index 356e361..1e6d928 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -291,7 +291,6 @@ static int mmu_topup_memory_caches(struct kvm_vcpu *vcpu)
{
int r;
- kvm_mmu_free_some_pages(vcpu);
r = mmu_topup_memory_cache(&vcpu->arch.mmu_pte_chain_cache,
pte_chain_cache, 4);
if (r)
@@ -569,9 +568,6 @@ static struct kvm_mmu_page *kvm_mmu_alloc_page(struct kvm_vcpu *vcpu,
{
struct kvm_mmu_page *sp;
- if (!vcpu->kvm->arch.n_free_mmu_pages)
- return NULL;
-
sp = mmu_memory_cache_alloc(&vcpu->arch.mmu_page_header_cache, sizeof *sp);
sp->spt = mmu_memory_cache_alloc(&vcpu->arch.mmu_page_cache, PAGE_SIZE);
sp->gfns = mmu_memory_cache_alloc(&vcpu->arch.mmu_page_cache, PAGE_SIZE);
@@ -1025,6 +1021,7 @@ static int nonpaging_map(struct kvm_vcpu *vcpu, gva_t v, int write, gfn_t gfn)
up_read(¤t->mm->mmap_sem);
spin_lock(&vcpu->kvm->mmu_lock);
+ kvm_mmu_free_some_pages(vcpu);
r = __nonpaging_map(vcpu, v, write, gfn, page);
spin_unlock(&vcpu->kvm->mmu_lock);
return r;
@@ -1273,6 +1270,7 @@ int kvm_mmu_load(struct kvm_vcpu *vcpu)
if (r)
goto out;
spin_lock(&vcpu->kvm->mmu_lock);
+ kvm_mmu_free_some_pages(vcpu);
mmu_alloc_roots(vcpu);
spin_unlock(&vcpu->kvm->mmu_lock);
kvm_x86_ops->set_cr3(vcpu, vcpu->arch.mmu.root_hpa);
@@ -1414,6 +1412,7 @@ void kvm_mmu_pte_write(struct kvm_vcpu *vcpu, gpa_t gpa,
pgprintk("%s: gpa %llx bytes %d\n", __FUNCTION__, gpa, bytes);
mmu_guess_page_from_pte_write(vcpu, gpa, new, bytes);
spin_lock(&vcpu->kvm->mmu_lock);
+ kvm_mmu_free_some_pages(vcpu);
++vcpu->kvm->stat.mmu_pte_write;
kvm_mmu_audit(vcpu, "pre pte write");
if (gfn == vcpu->arch.last_pt_write_gfn
@@ -1506,7 +1505,6 @@ int kvm_mmu_unprotect_page_virt(struct kvm_vcpu *vcpu, gva_t gva)
void __kvm_mmu_free_some_pages(struct kvm_vcpu *vcpu)
{
- spin_lock(&vcpu->kvm->mmu_lock);
while (vcpu->kvm->arch.n_free_mmu_pages < KVM_REFILL_PAGES) {
struct kvm_mmu_page *sp;
@@ -1515,7 +1513,6 @@ void __kvm_mmu_free_some_pages(struct kvm_vcpu *vcpu)
kvm_mmu_zap_page(vcpu->kvm, sp);
++vcpu->kvm->stat.mmu_recycled;
}
- spin_unlock(&vcpu->kvm->mmu_lock);
}
int kvm_mmu_page_fault(struct kvm_vcpu *vcpu, gva_t cr2, u32 error_code)
diff --git a/arch/x86/kvm/paging_tmpl.h b/arch/x86/kvm/paging_tmpl.h
index 73ff66b..6208325 100644
--- a/arch/x86/kvm/paging_tmpl.h
+++ b/arch/x86/kvm/paging_tmpl.h
@@ -404,6 +404,7 @@ static int FNAME(page_fault)(struct kvm_vcpu *vcpu, gva_t addr,
up_read(¤t->mm->mmap_sem);
spin_lock(&vcpu->kvm->mmu_lock);
+ kvm_mmu_free_some_pages(vcpu);
shadow_pte = FNAME(fetch)(vcpu, addr, &walker, user_fault, write_fault,
&write_pt, page);
pgprintk("%s: shadow pte %p %llx ptwrite %d\n", __FUNCTION__,
--
1.5.3.7
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 3/4] KVM: MMU: Avoid calling gfn_to_page() in mmu_set_spte()
On Sun, Dec 30, 2007 at 01:17:18PM +0200, Avi Kivity wrote:
> Since gfn_to_page() is a sleeping function, and we want to make the core mmu
> spinlocked, we need to pass the page from the walker context (which can sleep)
> to the shadow context (which cannot).
>
> Signed-off-by: Avi Kivity <[EMAIL PROTECTED]>
> ---
> arch/x86/kvm/mmu.c | 58
>
> arch/x86/kvm/paging_tmpl.h | 25 +++
> include/asm-x86/kvm_host.h |5
> 3 files changed, 78 insertions(+), 10 deletions(-)
>
> diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
> index 3b91227..1b68f07 100644
> --- a/arch/x86/kvm/mmu.c
> +++ b/arch/x86/kvm/mmu.c
> +static void mmu_guess_page_from_pte_write(struct kvm_vcpu *vcpu, gpa_t gpa,
> + const u8 *new, int bytes)
> +{
> + gfn_t gfn;
> + int r;
> + u64 gpte = 0;
> +
> + if (bytes != 4 && bytes != 8)
> + return;
> +
> + down_read(¤t->mm->mmap_sem);
kvm_mmu_pte_write() already holds mmap_sem in read-mode, so this is not
required (and is deadlock prone actually).
Other than that the patchset looks good, thanks.
--- mmu.c.orig 2007-12-31 09:34:50.0 -0500
+++ mmu.c 2007-12-31 09:34:52.0 -0500
@@ -1360,7 +1360,6 @@ static void mmu_guess_page_from_pte_writ
if (bytes != 4 && bytes != 8)
return;
- down_read(¤t->mm->mmap_sem);
/*
* Assume that the pte write on a page table of the same type
* as the current vcpu paging mode. This is nearly always true
@@ -1372,7 +1371,7 @@ static void mmu_guess_page_from_pte_writ
if ((bytes == 4) && (gpa % 4 == 0)) {
r = kvm_read_guest(vcpu->kvm, gpa & ~(u64)7, &gpte, 8);
if (r)
- goto out;
+ return;
memcpy((void *)&gpte + (gpa % 8), new, 4);
} else if ((bytes == 8) && (gpa % 8 == 0)) {
memcpy((void *)&gpte, new, 8);
@@ -1382,12 +1381,10 @@ static void mmu_guess_page_from_pte_writ
memcpy((void *)&gpte, new, 4);
}
if (!is_present_pte(gpte))
- goto out;
+ return;
gfn = (gpte & PT64_BASE_ADDR_MASK) >> PAGE_SHIFT;
vcpu->arch.update_pte.gfn = gfn;
vcpu->arch.update_pte.page = gfn_to_page(vcpu->kvm, gfn);
-out:
- up_read(¤t->mm->mmap_sem);
}
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 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 3/4] KVM: MMU: Avoid calling gfn_to_page() in mmu_set_spte()
Marcelo Tosatti wrote: > kvm_mmu_pte_write() already holds mmap_sem in read-mode, so this is not > required (and is deadlock prone actually). > > Thanks, I merged your fix into the patch. -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 4/4] KVM: MMU: Switch to mmu spinlock
On Sun, Dec 30, 2007 at 01:17:19PM +0200, Avi Kivity wrote:
> From: Marcelo Tosatti <[EMAIL PROTECTED]>
>
> Convert the synchronization of the shadow handling to a separate mmu_lock
> spinlock.
>
> Also guard fetch() by mmap_sem in read-mode to protect against alias
> and memslot changes.
>
> Signed-off-by: Marcelo Tosatti <[EMAIL PROTECTED]>
> Signed-off-by: Avi Kivity <[EMAIL PROTECTED]>
> ---
> arch/x86/kvm/mmu.c | 46 ++-
> arch/x86/kvm/paging_tmpl.h | 10 +---
> arch/x86/kvm/vmx.c |2 -
> include/linux/kvm_host.h |3 +-
> virt/kvm/kvm_main.c|3 +-
> 5 files changed, 33 insertions(+), 31 deletions(-)
>
> diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
> index 1b68f07..356e361 100644
> --- a/arch/x86/kvm/mmu.c
> +++ b/arch/x86/kvm/mmu.c
> @@ -971,16 +971,12 @@ static void nonpaging_new_cr3(struct kvm_vcpu *vcpu)
> {
> }
>
> -static int __nonpaging_map(struct kvm_vcpu *vcpu, gva_t v, int write, gfn_t
> gfn)
> +static int __nonpaging_map(struct kvm_vcpu *vcpu, gva_t v, int write,
> +gfn_t gfn, struct page *page)
> {
> int level = PT32E_ROOT_LEVEL;
> hpa_t table_addr = vcpu->arch.mmu.root_hpa;
> int pt_write = 0;
> - struct page *page;
> -
> - down_read(¤t->mm->mmap_sem);
> - page = gfn_to_page(vcpu->kvm, gfn);
> - up_read(¤t->mm->mmap_sem);
>
> for (; ; level--) {
> u32 index = PT64_INDEX(v, level);
> @@ -1022,9 +1018,15 @@ static int nonpaging_map(struct kvm_vcpu *vcpu, gva_t
> v, int write, gfn_t gfn)
> {
> int r;
>
> - mutex_lock(&vcpu->kvm->lock);
> - r = __nonpaging_map(vcpu, v, write, gfn);
> - mutex_unlock(&vcpu->kvm->lock);
> + struct page *page;
> +
> + down_read(¤t->mm->mmap_sem);
> + page = gfn_to_page(vcpu->kvm, gfn);
> + up_read(¤t->mm->mmap_sem);
> +
> + spin_lock(&vcpu->kvm->mmu_lock);
> + r = __nonpaging_map(vcpu, v, write, gfn, page);
> + spin_unlock(&vcpu->kvm->mmu_lock);
> return r;
> }
And its better to hold mmap_sem across __nonpaging_map() in similarity
to the paging fault path, to protect against memslot and alias changes.
--- mmu.c.orig 2007-12-31 09:34:50.0 -0500
+++ mmu.c 2007-12-31 09:59:46.0 -0500
@@ -1018,12 +1018,12 @@ static int nonpaging_map(struct kvm_vcpu
down_read(¤t->mm->mmap_sem);
page = gfn_to_page(vcpu->kvm, gfn);
- up_read(¤t->mm->mmap_sem);
spin_lock(&vcpu->kvm->mmu_lock);
kvm_mmu_free_some_pages(vcpu);
r = __nonpaging_map(vcpu, v, write, gfn, page);
spin_unlock(&vcpu->kvm->mmu_lock);
+ up_read(¤t->mm->mmap_sem);
return r;
}
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] www.renovaciones.com.ar
Please see this site in Subject - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] kvm/qemu: Fix ia64 build broken.
On Fri, Dec 21, 2007 at 10:58:23PM +0800, Zhang, Xiantao wrote: > Due to last merge with Qemu upstream, some interfaces are changed, and > leads to build fail kvm-58 as released doesn't build in ia64 either because of the tpr/vapic changes that were done at release date as shown by : gcc -Wl,-G0 -Wl,-T,/house/cmarenas/kvm-58/qemu/ia64.ld -L /house/cmarenas/kvm-58/qemu/../libkvm -g -o qemu-system-ia64 vl.o osdep.o monitor.o pci.o loader.o isa_mmio.o migration.o block-raw-posix.o lsi53c895a.o usb-ohci.o eeprom93xx.o eepro100.o ne2000.o pcnet.o rtl8139.o hypercall.o ide.o pckbd.o ps2.o vga.o sb16.o es1370.o dma.o fdc.o mc146818rtc.o serial.o i8259.o ipf.o cirrus_vga.o parallel.o acpi.o piix_pci.o usb-uhci.o /house/cmarenas/kvm-58/qemu/smbus_eeprom.o ../libqemu_common.a libqemu.a /house/cmarenas/kvm-58/qemu/../libkvm/libkvm.a -lm -lz -lkvm -lrt -lpthread -lutil libqemu.a(kvm-tpr-opt.o): In function `kvm_tpr_opt_setup': /house/cmarenas/kvm-58/qemu/kvm-tpr-opt.c:287: undefined reference to `kvm_enable_tpr_access_reporting' libqemu.a(kvm-tpr-opt.o): In function `enable_vapic': /house/cmarenas/kvm-58/qemu/kvm-tpr-opt.c:221: undefined reference to `kvm_enable_vapic' Xiantao, are there any plans to merge into qemu all changes required to get host/guest support for ia64?, if for nothing else that could help with problems due to qemu merges. Avi, how would you like patches to fix build issues in ia64 to be handled?, should be expected that kvm releases build for ia64? is there any system that could be used as part of a compile farm / testing for ia64? if nothing is available hp's testdrive have some itanium systems that could be used at least to validate the userspace part builds (as I did) : http://www.testdrive.hp.com/systems/itanium.shtml Carlo PS. there are more warnings and other issues in that build that the ones shown above. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
