[PATCH] kvm: bios: use windows pcr to get cpu number rather than tr

From: Avi Kivity [EMAIL PROTECTED] using tr to hold the current cpu number interferes with hibernate/resume in smp. so instead, get the cpu number directly from the windows pcr at fs:0x51. use byte 4 of the per-cpu vapic region to check whether vapic is enabled. Signed-off-by: Avi Kivity

[PATCH] kvm: qemu: stop using tr as cpu id for vtpr

From: Avi Kivity [EMAIL PROTECTED] instead, use byte 4 of the vtpr region. Signed-off-by: Avi Kivity [EMAIL PROTECTED] diff --git a/qemu/kvm-tpr-opt.c b/qemu/kvm-tpr-opt.c index 6677741..f2a3a1e 100644 --- a/qemu/kvm-tpr-opt.c +++ b/qemu/kvm-tpr-opt.c @@ -225,15 +225,11 @@ static int

[PATCH] kvm: qemu: regenerate bios for vtpr using windows pcr

From: Avi Kivity [EMAIL PROTECTED] Signed-off-by: Avi Kivity [EMAIL PROTECTED] diff --git a/qemu/pc-bios/bios.bin b/qemu/pc-bios/bios.bin index 6aecdd7..dd21049 100644 Binary files a/qemu/pc-bios/bios.bin and b/qemu/pc-bios/bios.bin differ -- To unsubscribe from this list: send the line

Re: [patch 07/13] KVM: MMU: mode specific sync_page

On Sun, Sep 07, 2008 at 12:52:21PM +0300, Avi Kivity wrote: What if vcpu0 is in mode X, while vcpu1 is in mode Y. vcpu0 writes to some pagetable, causing both mode X and mode Y shadows to become unsynced, so on the next resync (either by vcpu0 or vcpu1) we need to sync both modes. From

Re: [patch 01/13] x86/mm: get_user_pages_fast_atomic

On Sun, Sep 07, 2008 at 11:42:18AM +0300, Avi Kivity wrote: Marcelo Tosatti wrote: From: Nick Piggin [EMAIL PROTECTED] Provide a lockless pagetable walk function without fallback to mmap_sem on error. I would like to avoid this if possible. Not only is this a change to the core

Re: gdb and kvm status?

Tim Pepper wrote: (not on list, so please cc: replies and I'm new to kvm and qemu so forgive my ignorance of things) I was trying to play recently with a kvm guest and gdb and am experiencing bad behavior. I'm curious if this is expected to work currently or if there's newer code upstream

Re: [patch 09/13] KVM: MMU: out of sync shadow core

On Sun, Sep 07, 2008 at 02:01:42PM +0300, Avi Kivity wrote: Marcelo Tosatti wrote: Allow global and single-root, single-role-per-gfn leaf shadowed pagetables to be unsynced. Global unsync pages are saved into a per-vm array, synced on cr4/cr0 writes. Why not a list? Could be. I'm

8139cp problems - steps to reproduce

Hello Avi and everybody, (and in advance, sorry for cross-posting). As it was already reported, some people (including me :)) have problems with network getting stuck from time to time in KVM guests. According to

[PATCH] KVM: VMX: Add MTRR support for EPT

Signed-off-by: Sheng Yang [EMAIL PROTECTED] --- arch/x86/kvm/mmu.c | 115 +++- arch/x86/kvm/svm.c |6 ++ arch/x86/kvm/vmx.c | 24 - arch/x86/kvm/x86.c |2 +- include/asm-x86/kvm_host.h |3 +- 5 files

[PATCH] KVM: VMX: Allocate MSR Bitmap for each vcpu

Separate msr_bitmap for each vcpu, prepared for guest PAT support. Signed-off-by: Sheng Yang [EMAIL PROTECTED] --- arch/x86/kvm/vmx.c | 53 +-- 1 files changed, 30 insertions(+), 23 deletions(-) diff --git a/arch/x86/kvm/vmx.c

Re: massive performance drop after a while when using virtio nics

Fabian Deutsch a écrit : Hey. When running a guest in the following setup, I observ a massive performance decrease after a couple of gigabytes of transfrerred data. other guests keep running fine (no regressions) and nothing unusual is observed on the host. fedora 8 host, kvm-72 (user and

[PATCH 0/4] Memory type support for EPT

Hi, Avi This patchset add memory type support for EPT, including MTRR and PAT. The patch restruct the MTRR structure to make it easy to use, also take host kernel MTRR as a reference. The function guest_mtrr_type_lookup() is copied from host kernel rather than reuse, for I think it may be much

Re: massive performance drop after a while when using virtio nics

Am Montag, den 08.09.2008, 14:07 +0200 schrieb Yann Dupont: Fabian Deutsch a écrit : Hey. When running a guest in the following setup, I observ a massive performance decrease after a couple of gigabytes of transfrerred data. other guests keep running fine (no regressions) and nothing

Re: massive performance drop after a while when using virtio nics

Fabian Deutsch a écrit : We just saw the very same issue. guest host : 2.6.25.3, debian etch 64 bits ... Are you also using model=vortio? If so, you might want to switch to e1000. Less performance but stable. The issues seems to be related to virtio/tap. And a little bit more to the

Re: PLIP doesn't work under kvm

* On Sunday 07 September 2008 08:52:29 holio-dslab wrote: Hi all, I'm trying to communicate between two computers, said A and B, with PLIP (Parallel Line IP). It works correct(both can ping each other) when both run the PLIP on the physical host os, so the cable and the configurations should

Re: [patch 09/13] KVM: MMU: out of sync shadow core

Marcelo Tosatti wrote: I'm worried about the complexity this (and the rest) introduces. A possible alternative is: - for non-leaf pages, including roots, add a 'unsync_children' flag. - when marking a page unsync, set the flag recursively on all parents - when switching cr3, recursively

Re: [patch 02/13] KVM: MMU: switch to get_user_pages_fast

Marcelo Tosatti wrote: static int kvm_vm_fault(struct vm_area_struct *vma, struct vm_fault *vmf) { + struct page *page[1]; + unsigned long addr; + int npages; + gfn_t gfn = vmf-pgoff; struct kvm *kvm = vma-vm_file-private_data; - struct page *page; -

Re: [PATCH] Fix up pxe boot

On Sun, Sep 07, 2008 at 09:42:07AM +0300, Avi Kivity wrote: Glauber Costa wrote: After a second look, here's what it seems to me: It's not in a generic place, such as ldl, because in general, we may want to grab a 32-bit value from a 64-bit address. This is perfectly valid. It's a

Re: [PATCH 4/4 v2] PCI: document the change

On Mon, 1 Sep 2008 19:21:06 +0800 Zhao, Yu wrote: Complete the hotplug ABI document, and add SR-IOV HOWTO. Signed-off-by: Yu Zhao [EMAIL PROTECTED] Signed-off-by: Eddie Dong [EMAIL PROTECTED] --- Documentation/ABI/testing/sysfs-bus-pci | 67

Re: gdb and kvm status?

On Sat 06 Sep at 00:22:16 +0300 [EMAIL PROTECTED] said: On Fri, Sep 5, 2008 at 11:28 PM, Tim Pepper [EMAIL PROTECTED] wrote: snip The host specifics are standard current fedora/livna: kernel-2.6.25.14-108.fc9.i686 qemu-0.9.1-6.fc9.i386 kmod-kqemu-1.3.0-0.38.lvn9.i686

KVM: x86: do not execute halted vcpus (resend)

Offline or uninitialized vcpu's can be executed if requested to perform userspace work. Follow Avi's suggestion to handle halted vcpu's in the main loop, simplifying kvm_emulate_halt(). Introduce a new vcpu-requests bit to indicate events that promote state from halted to running. Also

[PATCH] kvm: testsuite: Add test for 'call near absolute'

Add test for 'call near abolsute' instruction to the real mode test harness Signed-off-by: Mohammed Gamal [EMAIL PROTECTED] --- user/test/x86/realmode.c | 19 +++ 1 files changed, 19 insertions(+), 0 deletions(-) diff --git a/user/test/x86/realmode.c b/user/test/x86/realmode.c

[PATCH] x86 emulator: Add call near absolute instruction (group5: opcode 0xff mod r/m 2)

Add call near absolute instruction Signed-off-by: Mohammed Gamal [EMAIL PROTECTED] --- arch/x86/kvm/x86_emulate.c | 11 ++- 1 files changed, 10 insertions(+), 1 deletions(-) diff --git a/arch/x86/kvm/x86_emulate.c b/arch/x86/kvm/x86_emulate.c index 3ac2f14..0630d21 100644 ---

[PATCH] remove kernel memory allocation code from ipf.c

From: Glauber Costa [EMAIL PROTECTED] Signed-off-by: Glauber Costa [EMAIL PROTECTED] --- qemu/hw/ipf.c | 25 + 1 files changed, 5 insertions(+), 20 deletions(-) diff --git a/qemu/hw/ipf.c b/qemu/hw/ipf.c index 2f7054c..d979d4d 100644 --- a/qemu/hw/ipf.c +++

[PATCH] remove KVM_CAP_USER_MEMORY from libkvm.c.

From: Glauber Costa [EMAIL PROTECTED] One of them is left, which is the initial check. Code that does ioctl checking is left to be removed in a future commit. Signed-off-by: Glauber Costa [EMAIL PROTECTED] --- libkvm/libkvm.c | 18 -- 1 files changed, 0 insertions(+), 18

[PATCH] start removing kernel memory functions

From: Glauber Costa [EMAIL PROTECTED] kvm_arch_create_default_phys_mem and kvm_alloc_kernel_memory are legacy. Remove them, and their callers. The whole removal will be split for bisectability. These ones goes first because they are only called at initialization Signed-off-by: Glauber Costa

[PATCH] get rid of kvm_create_userspace_phys_mem

From: Glauber Costa [EMAIL PROTECTED] It is just kvm_create_phys_mem() right now. Signed-off-by: Glauber Costa [EMAIL PROTECTED] --- libkvm/libkvm.c | 15 --- 1 files changed, 4 insertions(+), 11 deletions(-) diff --git a/libkvm/libkvm.c b/libkvm/libkvm.c index 5b48240..5d42b43

[PATCH 0/12] Get rid of kernel memory allocation

Hey guys, Some eons before the dinosaurs went extinct, we used to support a method of memory allocation different than the one advertised by KVM_CAP_USER_MEMORY. This series of patches attempt on removing the support for it in kvm-userspace entirely. It will make the job of integrating kvm and

[PATCH] remove tests of user memory from vl.c

From: Glauber Costa [EMAIL PROTECTED] kvm_qemu_create_context() will fail if we don't have userspace memory capability, so no need to check it here. Signed-off-by: Glauber Costa [EMAIL PROTECTED] --- qemu/vl.c | 18 +- 1 files changed, 5 insertions(+), 13 deletions(-) diff

[PATCH] coalesce memory allocation

From: Glauber Costa [EMAIL PROTECTED] Put all memory allocation under qemu_alloc_physram(). Protect the mem_area code with #ifdef USE_KVM. Although it is not really needed, it help us keep track of the fact that this is a kvm-only feature to the moment. Signed-off-by: Glauber Costa [EMAIL

[PATCH] remove KVM_CAP_USER_MEMORY reference from qemu-kvm.c

From: Glauber Costa [EMAIL PROTECTED] kvm_cpu_register_physical_memory() is its only user. Remove it. Signed-off-by: Glauber Costa [EMAIL PROTECTED] --- qemu/qemu-kvm.c | 52 +--- 1 files changed, 21 insertions(+), 31 deletions(-) diff --git

[PATCH] remove kernel memory code from hw/pc.c

From: Glauber Costa [EMAIL PROTECTED] Signed-off-by: Glauber Costa [EMAIL PROTECTED] --- qemu/hw/pc.c | 19 ++- 1 files changed, 2 insertions(+), 17 deletions(-) diff --git a/qemu/hw/pc.c b/qemu/hw/pc.c index 026e96d..8a50096 100644 --- a/qemu/hw/pc.c +++ b/qemu/hw/pc.c @@

Re: [Qemu-devel] 8139cp problems - steps to reproduce

On Mon, Sep 8, 2008 at 11:57 AM, Nikola Ciprich [EMAIL PROTECTED] wrote: Hello Avi and everybody, (and in advance, sorry for cross-posting). As it was already reported, some people (including me :)) have problems with network getting stuck from time to time in KVM guests. According to

KVM bridge Networking and openvpn

Hi I have a openvpn network using *tap* interfaces. On the machines on the vpn network, I want to create VMs in such a way that they should all get on the vpn network. -- I have tap0 as the openvpn interface -- br0 as the bridge. -- script to setup bridge and the add tap0 ifconfig tap0

Re: KVM bridge Networking and openvpn

jd wrote: Now when I create new VM, using the command line... qemu-system-x86_64 -net nic,vlan=0,macaddr=00:16:3e:70:8f:33 -net tap,vlan=0 -hda /mnt/vm_data/test_xp.hda.disk.xm -m 256 The VM does not seem to get the IP address :( (may be dhcp request is failing) You aren't providing ifname

[PATCH] virtio-blk: change config to guest endian

Since virtio-blk in kernel has already changed, qemu needs to be updated. see http://thread.gmane.org/gmane.linux.kernel.virtualization/5776/focus=580 Only tested it on branch kvm-70rc1 for e500/powerpc platform. Signed-off-by: Liu Yu [EMAIL PROTECTED] Acked-by: Anthony Liguori [EMAIL PROTECTED]