Re: [kvm-devel] Where are vmentry failure caugth?
On Sat, 12 Jan 2008 14:34:12 -0600 Anthony Liguori <[EMAIL PROTECTED]> wrote: > What version of gfxboot does openSUSE 10.3 use? gfxboot was broken for > KVM until very recently. This is probably what you're seeing. I don't know what version it is but do you talk about the bug due to the wrong RPL value in the SS selector that produces a VMentry failure? Because my problem is here. I thought that I could catch the VMentry failure by added a test like "if (unlikely(exit_reason & VMX_EXIT_REASONS_FAILED_VMENTRY))" in kvm_handle_exit(). Thus I tried to start the openSUSE 10.3 with the "old" gfxboot to test the VMentry failure but I cannot catch it and that's why I'm a little lost. I will try to understand the first handle_exception message as suggested by Avi. - 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-ppc-devel] RFC: MMIO endianness flag
> kvm_run->mmio.is_bigendian = vcpu->arch.some_register &
>From your example code, I can know is_bigendian indicate whether guest
is in bigendian mode when accessing MMIO.
Qemu is responsible for handling MMIO emulation, Qemus always assume it
is running on littleendian mode.
So if guest accesses MMIO in bigendian mode,
kvm need to transform it to littleendian before delivering this
MMIO request to Qemu.
This works for IA64 side.
Thanks,
- Anthony
Hollis Blanchard wrote:
> We're just talking about a flag in the kvm_run.mmio structure, so it
> does not represent the state of any software, guest or host, other
> than that single MMIO access.
>
> This flag is only used for communication between host kernel and host
> userland, so the host kernel is always responsible for setting it.
>
> "is_bigendian" is just one more necessary piece of information for
> MMIO emulation. kvm_run already tells you that you are loading 4
> bytes from address 0. What you don't know today is if byte 0 is the
> least significant or most significant byte. If "is_bigendian" is set,
> you know that byte 0 is the MSB and byte 3 is the LSB. If not, the
> opposite is true.
>
> In the simplest case, IA64's in-kernel MMIO emulation code could look
> something like:
> kvm_run->mmio.phys_addr = addr;
> kvm_run->mmio.len = len;
> ...
> kvm_run->mmio.is_bigendian = vcpu->arch.some_register &
> BIGENDIAN;
>
> If IA64 has reverse-endian load/store instructions like PowerPC, then
> you would also need to consider the particular instruction used as
> well as the guest state.
>
>
> On Fri, 2008-01-11 at 10:02 +0800, Xu, Anthony wrote:
>> Hi all,
>>
>> That's a good start to consider BE.
>> Yes, IA64 support BE and LE.
>>
>> I have below comments.
>>
>> What does is_bigendian mean?
>> Host is runing with BE or guest is running with BE.
>> Who will set is_bigendian?
>>
>> For supporing BE,
>> We need to consider host BE and guest BE.
>> For IA64, most OS is running with LE, and
>> Application can run with BE or LE,
>> For example, Qemu can run with BE or LE.
>>
>> IMHO, we need two flags,
>> host_is_bigendian indicates Qemu is running with BE
>> Guest_is_bigendian indecates the guest application who is accessing
>> MMIO
>>
>> Is running with LE.
>>
>>
>> - Anthony
>>
>>
>>
>>
>>
>>
>> Hollis Blanchard wrote:
>>> On Thu, 2008-01-10 at 17:28 +0200, Avi Kivity wrote:
I'll apply that patch (with a #ifdef CONFIG_PPC so other archs
don't use it by mistake).
>>>
>>> I don't think that's the right ifdef. For example, I believe IA64
>>> can run in BE mode and so will have the same issue, and there are
>>> certainly other architectures (less relevant to the current code)
>>> that definitely are in the same situation.
>>>
>>> We need to plumb this through to the libkvm users anyways. Take a
>>> look at the patch below and tell me if you think it's not the right
>>> approach. x86 simply won't consider 'is_bigendian'. I spent a lot
>>> of time on this, and it's by far the cleanest solution I could come
>>> up with.
>>>
>>>
>>>
>>> diff --git a/libkvm/config-i386.mak b/libkvm/config-i386.mak ---
>>> a/libkvm/config-i386.mak +++ b/libkvm/config-i386.mak
>>> @@ -2,5 +2,6 @@ LIBDIR := /lib
>>> LIBDIR := /lib
>>> CFLAGS += -m32
>>> CFLAGS += -D__i386__
>>> +CFLAGS += -DARCH_MMIO_ENDIAN_LITTLE
>>>
>>> libkvm-$(ARCH)-objs := libkvm-x86.o
>>> diff --git a/libkvm/config-ia64.mak b/libkvm/config-ia64.mak ---
>>> a/libkvm/config-ia64.mak +++ b/libkvm/config-ia64.mak
>>> @@ -1,5 +1,6 @@
>>>
>>> LIBDIR := /lib
>>> CFLAGS += -D__ia64__
>>> +CFLAGS += -DARCH_MMIO_ENDIAN_LITTLE -DARCH_MMIO_ENDIAN_BIG
>>>
>>> libkvm-$(ARCH)-objs := libkvm-ia64.o
>>> diff --git a/libkvm/config-powerpc.mak b/libkvm/config-powerpc.mak
>>> --- a/libkvm/config-powerpc.mak
>>> +++ b/libkvm/config-powerpc.mak
>>> @@ -2,5 +2,6 @@ LIBDIR := /lib
>>> LIBDIR := /lib
>>> CFLAGS += -m32
>>> CFLAGS += -D__powerpc__
>>> +CFLAGS += -DARCH_MMIO_ENDIAN_BIG -DARCH_MMIO_ENDIAN_LITTLE
>>>
>>> libkvm-$(ARCH)-objs := libkvm-powerpc.o
>>> diff --git a/libkvm/config-x86_64.mak b/libkvm/config-x86_64.mak
>>> --- a/libkvm/config-x86_64.mak
>>> +++ b/libkvm/config-x86_64.mak
>>> @@ -2,5 +2,6 @@ LIBDIR := /lib64
>>> LIBDIR := /lib64
>>> CFLAGS += -m64
>>> CFLAGS += -D__x86_64__
>>> +CFLAGS += -DARCH_MMIO_ENDIAN_LITTLE
>>>
>>> libkvm-$(ARCH)-objs := libkvm-x86.o
>>> diff --git a/libkvm/libkvm.c b/libkvm/libkvm.c
>>> --- a/libkvm/libkvm.c
>>> +++ b/libkvm/libkvm.c
>>> @@ -774,21 +774,56 @@ int kvm_set_sregs(kvm_context_t kvm, int
>>> return ioctl(kvm->vcpu_fd[vcpu], KVM_SET_SREGS, sregs); }
>>>
>>> +#ifdef ARCH_MMIO_ENDIAN_BIG
>>> +static int handle_mmio_bigendian(kvm_context_t kvm, struct kvm_run
>>> *kvm_run) +{ + if (kvm_run->mmio.is_write)
>>> + return kvm->callbacks->mmio_write_be(kvm->opaque,
>>> +
>> kvm_run->mmio.phys_addr,
>>> +k
Re: [kvm-devel] Setting hardware breakpoints in guest OS
>While we tried to make debugging inside the guest work, this >was never really tested, so it's likely broken. I'll try to >look at what it will take to make it work; I don't think there's >much needed. That sounds encouraging -- I had imagined there might be some "impossibility factor" in sharing something like hardware breakpoints between host and guest. For now I'm simply sticking to QEMU+kqemu when I expect deliberate trickiness or need to do hard-breakpoint debugging, and QEMU/KVM (which is up to 50% faster when doing Windows software builds on my PC, nice!) when I don't care. I haven't had any problems loading and using the kvm drivers and kqemu at the same time, and I have assumed that there ought to be no issues in doing so, since they work quite differently and (from my very dangerously limited understanding) ought not to be competing for any mutually exclusive hardware resources. Is that a reasonable assumption? >What hardware are you using? If you have both AMD and Intel >hardware, you might have better luck switching, since this is >very subarch dependent. Intel Core Duo (T2400 @ 1.83GHz according to /proc/cpuinfo), running 32-bit Linux 2.6.21.5 using KVM drivers built from the kvm-59 sourceball. Sorry, I don't have other vendors or CPU bitnesses to test on. PS: When I build KVM "out of the box," I get a qemu binary called qemu-system-x86_64, though I have a 32-bit CPU and a 32-bit OS. Forgive my ignorance on this, but...why does the name of the binary imply a 64-bit flavour? - 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-59 doesn't work
Anthony Liguori wrote: > Izik Eidus wrote: >> Anthony Liguori wrote: >>> Avi Kivity wrote: Andi Kleen wrote: > When I try my 64bit kernel with -kernel ... on kvm-59 I get before > the kernel outputs anything: > > Yes, I think -kernel is broken. >>> >>> If you are using a guest with more than 3.75GB or so. The >>> load_kernel function uses phys_ram_base + addr and that assumption >>> is violated in KVM with guests > ~3.75GB of memory. We either need >>> to allocate memory for the hole and never touch it or change >>> load_kernel to use cpu_physical_memory_rw. I know we discussed this >>> before but I don't remember if we came to a consensus about what the >>> correct fix is? >>> >> we can do munmap on the pci hole memory area, >> btw Anthony virtio will need this too right? > > Yup. I don't think you want to munmap memory allocated by glibc. i was thinking about allocate the memory with mmap instead of the qemu qemu_malloc... > > I think a better thing to do would be to madvise(MADV_DONTNEED) > although I don't think it's strictly needed. If you never touch the > memory, then does it really matter? why to keep the virtual address size of a program 300mb larger than it really is? > > Regards, > > Anthony Liguori > >>> Regards, >>> >>> Anthony Liguori Izik? >>> >> > - 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] mmu notifiers #v2
On Sun, 2008-01-13 at 17:24 +0100, Andrea Arcangeli wrote: > Hello, > > This patch is last version of a basic implementation of the mmu > notifiers. > > In short when the linux VM decides to free a page, it will unmap it > from the linux pagetables. However when a page is mapped not just by > the regular linux ptes, but also from the shadow pagetables, it's > currently unfreeable by the linux VM. > > This patch allows the shadow pagetables to be dropped and the page to > be freed after that, if the linux VM decides to unmap the page from > the main ptes because it wants to swap out the page. Another potential user of that I can see is the DRM. Nowadays, graphic cards essentially have an MMU on chip, and can do paging. It would be nice to be able to map user objects in them without having to lock them down using your callback to properly mark them cast out on the card. Ben. - 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-59 doesn't work
Izik Eidus wrote: > Anthony Liguori wrote: >> Avi Kivity wrote: >>> Andi Kleen wrote: >>> When I try my 64bit kernel with -kernel ... on kvm-59 I get before the kernel outputs anything: >>> >>> Yes, I think -kernel is broken. >>> >> >> If you are using a guest with more than 3.75GB or so. The >> load_kernel function uses phys_ram_base + addr and that assumption is >> violated in KVM with guests > ~3.75GB of memory. We either need to >> allocate memory for the hole and never touch it or change load_kernel >> to use cpu_physical_memory_rw. I know we discussed this before but I >> don't remember if we came to a consensus about what the correct fix is? >> > we can do munmap on the pci hole memory area, > btw Anthony virtio will need this too right? Yup. I don't think you want to munmap memory allocated by glibc. I think a better thing to do would be to madvise(MADV_DONTNEED) although I don't think it's strictly needed. If you never touch the memory, then does it really matter? Regards, Anthony Liguori >> Regards, >> >> Anthony Liguori >>> Izik? >>> >>> >> > - 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-59 doesn't work
Hi Andi, Please give us the _complete_ command line: how do you launch Qemu/KVM, and which Host and Guest OSes are? -- -Alexey Eremenko "Technologov" - 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-59 doesn't work II
... and eventually it oopsed:
Unable to handle kernel NULL pointer dereference at RIP:
[] :kvm:x86_emulate_memop+0x2c62/0x4527
PGD 11c8ae067 PUD 0
Oops: 0002 [1] SMP
CPU 0
Modules linked in: xfrm_user xfrm4_tunnel af_key xfs kvm_intel kvm usblp deflate
zlib_deflate zlib_inflate twofish_x86_64 twofish_common des_generic md5 sha1_ge
neric tunnel4 ipcomp esp4 ah4 cifs sha256_generic serpent pppoe pppox ppp_generi
c slhc autofs4 snd_pcm_oss snd_mixer_oss snd_seq ipt_MASQUERADE iptable_nat nf_n
at_sip nf_conntrack_sip nf_nat_ftp nf_nat_irc nf_nat ip6t_LOG ip6t_REJECT ip6tab
le_filter ip6_tables xt_tcpudp nf_conntrack_ipv4 xt_state nf_conntrack_ftp nf_co
nntrack_irc cbc nf_conntrack blkcipher cpufreq_conservative ipt_LOG ipt_REJECT i
ptable_filter ip_tables dm_crypt x_tables binfmt_misc aes_x86_64 eeprom lm85 hwm
on_vid snd_usb_audio pl2303 snd_usb_lib usbserial snd_rawmidi appledisplay snd_h
da_intel snd_seq_device snd_hwdep snd_pcm snd_timer snd snd_page_alloc i2c_i801
i2c_core
Pid: 10723, comm: qemu-system-x86 Not tainted 2.6.24-rc5-git5-BASIL #1
RIP: 0010:[] [] :kvm:x86_emulate_memop+0x2c
62/0x4527
RSP: 0018:81011d575738 EFLAGS: 00010246
RAX: RBX: RCX: 0044
RDX: RSI: 81011d5757d8 RDI:
RBP: R08: 11b4b000 R09: 0001
R10: 7fff581ec280 R11: 8823c388 R12: 0031
R13: R14: 81011d575908 R15:
FS: 2ac9553fd6e0() GS:80761000() knlGS:
CS: 0010 DS: 002b ES: 002b CR0: 80050033
CR2: CR3: 00010ef6e000 CR4: 26e0
DR0: DR1: DR2:
DR3: DR6: 4ff0 DR7: 0400
Process qemu-system-x86 (pid: 10723, threadinfo 81011d574000, task 81009
e5d6000)
Stack:
88237d20 0340 034e
Call Trace:
[] :kvm:emulate_instruction+0xf6/0x21a
[] :kvm_intel:handle_exception+0x19f/0x210
[] :kvm:kvm_vcpu_ioctl_run+0x29c/0x3ad
[] :kvm:kvm_vcpu_ioctl+0x10d/0xd7c
[] do_ioctl+0x21/0x6b
[] vfs_ioctl+0x243/0x25c
[] sys_ioctl+0x3c/0x5d
[] system_call+0x7e/0x83
[<2ac9538b8b57>]
Code: 66 89 10 eb 7b 8b 94 24 28 01 00 00 48 8b 84 24 38 01 00 00
RIP [] :kvm:x86_emulate_memop+0x2c62/0x4527
RSP
CR2:
-Andi
-
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-59 doesn't work
FWIW it seems things are broken even without -kernel in -59 too. If I try to boot an existing image with just -hda ... the VGA screen just stays black while the process runs at 99% CPU. Again with -49 it works fine. -Andi - 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-59 doesn't work
Avi Kivity wrote: > Andi Kleen wrote: >>> Are you using the modules that come with kvm or from an upstream >>> kernel? (which?) >>> >> >> kvm from 2.6.24-rc5-gitXXX upstream kernels (see my original mail) > > This points the finger at the memory allocation backward compatibility > logic. > > Izik, can you take a look there? > > yes i will look on this tomorrow (as i said) (what weird about it that the new code is actualy protected by: kvm_qemu_check_extension(KVM_CAP_USER_MEMORY) call, so it shouldnt run i will see it tomorrow. - 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-59 doesn't work
Andi Kleen wrote: >> Are you using the modules that come with kvm or from an upstream kernel? >> (which?) >> > > kvm from 2.6.24-rc5-gitXXX upstream kernels (see my original mail) > This points the finger at the memory allocation backward compatibility logic. Izik, can you take a look there? -- 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-59 doesn't work
> Are you using the modules that come with kvm or from an upstream kernel? > (which?) kvm from 2.6.24-rc5-gitXXX upstream kernels (see my original mail) -Andi - 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-59 doesn't work
Andi Kleen wrote: >> If you are using a guest with more than 3.75GB or so. The load_kernel >> function uses phys_ram_base + addr and that assumption is violated in >> KVM with guests > ~3.75GB of memory. We either need to allocate memory >> for the hole and never touch it or change load_kernel to use >> cpu_physical_memory_rw. I know we discussed this before but I don't >> remember if we came to a consensus about what the correct fix is? >> > > I used the default 128MB of RAM and the kernel also wasn't that big > and also not linked to a high address (everything definitely < 16MB) > > Just tried it and it works without a problem. Using kvm*.git though, not kvm-59. Are you using the modules that come with kvm or from an upstream kernel? (which?) -- 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-59 doesn't work
> If you are using a guest with more than 3.75GB or so. The load_kernel > function uses phys_ram_base + addr and that assumption is violated in > KVM with guests > ~3.75GB of memory. We either need to allocate memory > for the hole and never touch it or change load_kernel to use > cpu_physical_memory_rw. I know we discussed this before but I don't > remember if we came to a consensus about what the correct fix is? I used the default 128MB of RAM and the kernel also wasn't that big and also not linked to a high address (everything definitely < 16MB) -andi - 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] current kvm userspace git doesn't compile on i386
On Sun, Jan 13, 2008 at 01:37:11PM +0200, Uri Lublin wrote: > Try to build the kernel modules too (remove '--with-patched-kernel' from > ./configure arguments ): > ./configure --prefix=/opt/kvm --qemu-cc=/usr/bin/gcc-3.4 ; make -C > kernel LINUX= sync; make > You will have to rmmod current kvm modules and insmod the built modules > under /kernel. This doesn't work with rsync complaining. But I don't really want new kernel code anyway, and I would be very surprised if building a different kernel would fix a userspace link error given the obvious boundary between kernel and userspace code. - 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-59 doesn't work
Anthony Liguori wrote: > Avi Kivity wrote: >> Andi Kleen wrote: >> >>> When I try my 64bit kernel with -kernel ... on kvm-59 I get before >>> the kernel outputs anything: >>> >>> >> >> Yes, I think -kernel is broken. >> > > If you are using a guest with more than 3.75GB or so. The load_kernel > function uses phys_ram_base + addr and that assumption is violated in > KVM with guests > ~3.75GB of memory. We either need to allocate > memory for the hole and never touch it or change load_kernel to use > cpu_physical_memory_rw. I know we discussed this before but I don't > remember if we came to a consensus about what the correct fix is? > we can do munmap on the pci hole memory area, btw Anthony virtio will need this too right? > Regards, > > Anthony Liguori >> Izik? >> >> > - 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-59 doesn't work
Izik Eidus wrote: > Avi Kivity wrote: > >> Andi Kleen wrote: >> >>> When I try my 64bit kernel with -kernel ... on kvm-59 I get before >>> the kernel outputs anything: >>> >>> >>> >> Yes, I think -kernel is broken. >> >> Izik? >> > > wasnt it was fixed with the qemu_ram_alloc(0xa) patch ??? > (i remembred someone sent patch to fix it) > Yes, but that only fixes it for guests that don't cross the 4GB boundary. Regards, Anthony Liguori > i will check it tomorrow > > - > 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 > - 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-59 doesn't work
Avi Kivity wrote: > Andi Kleen wrote: > >> When I try my 64bit kernel with -kernel ... on kvm-59 I get before >> the kernel outputs anything: >> >> >> > > Yes, I think -kernel is broken. > If you are using a guest with more than 3.75GB or so. The load_kernel function uses phys_ram_base + addr and that assumption is violated in KVM with guests > ~3.75GB of memory. We either need to allocate memory for the hole and never touch it or change load_kernel to use cpu_physical_memory_rw. I know we discussed this before but I don't remember if we came to a consensus about what the correct fix is? Regards, Anthony Liguori > Izik? > > - 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-59 doesn't work
Avi Kivity wrote: > Andi Kleen wrote: >> When I try my 64bit kernel with -kernel ... on kvm-59 I get before >> the kernel outputs anything: >> >> > > Yes, I think -kernel is broken. > > Izik? wasnt it was fixed with the qemu_ram_alloc(0xa) patch ??? (i remembred someone sent patch to fix it) i will check it tomorrow - 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-59 doesn't work
Andi Kleen wrote: > When I try my 64bit kernel with -kernel ... on kvm-59 I get before > the kernel outputs anything: > > Yes, I think -kernel is broken. Izik? -- 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] Fix compilation of kvm-59 with older kernel includes
Andi Kleen wrote: > I needed the following patch to make kvm-59 compile on SUSE 10.2. Yes it's > a bug in the standard includes. > > Applied, 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
[kvm-devel] kvm-59 doesn't work
When I try my 64bit kernel with -kernel ... on kvm-59 I get before the kernel outputs anything: exception 13 (0) rax rbx rcx rdx 0600 rsi rdi rsp rbp r8 r9 r10 r11 r12 r13 r14 r15 rip 0001 rflags 00033046 cs f000 (000f/ p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) ds (/ p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) es (/ p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) ss (/ p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) fs (/ p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) gs (/ p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) tr (08c0/2088 p 1 dpl 0 db 0 s 0 type b l 0 g 0 avl 0) ldt (/ p 1 dpl 0 db 0 s 0 type 2 l 0 g 0 avl 0) gdt 0/ idt 0/ cr0 6010 cr2 0 cr3 0 cr4 0 cr8 0 efer 0 code: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 --> fc f6 86 11 02 00 00 40 75 10 fa b8 18 00 00 00 8e d8 8e c0 8e e0 8e e8 8e d0 8d a6 e8 01 Aborted (core dumped) With kvm-49 user land it works just fine. Host is Intel-VT (Core2), kernel 2.6.24-rc5-git5 with the KVM modules out of the source tree. -Andi - 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] mmu notifiers #v2
Hello,
This patch is last version of a basic implementation of the mmu
notifiers.
In short when the linux VM decides to free a page, it will unmap it
from the linux pagetables. However when a page is mapped not just by
the regular linux ptes, but also from the shadow pagetables, it's
currently unfreeable by the linux VM.
This patch allows the shadow pagetables to be dropped and the page to
be freed after that, if the linux VM decides to unmap the page from
the main ptes because it wants to swap out the page.
In my basic initial patch I only track the tlb flushes which should be
the minimum required to have a nice linux-VM controlled swapping
behavior of the KVM gphysical memory. The shadow-ptes works much like
a TLB, so the same way we flush the tlb after clearing the ptes, we
should also issue the mmu_notifier invalidate_page/range/release
methods. Quadrics needs much more than that to optimize things to
preload secondary-ptes after main-pte instantiation (to prevent page
faults) and other similar optimizations, but it's easy to add more
methods to the below code to fit their needs if the basic
infrastructure is ok. Furthermore the best would be to use
self-modifying code to implement the notifiers as a nop inst when
disarmed but such an optimization is a low priority for now.
This follows the model of Avi's original patch, however I guess it
would also be possible to track when the VM shrink_cache methods wants
to free a certain host-page_t instead of tracking when the tlb is
flushed. Not sure if other ways are feasible or better, but the below
is the most important bit we need for KVM to swap nicely with minimal
overhead to the host kernel even if KVM is unused.
About the locking perhaps I'm underestimating it, but by following the
TLB flushing analogy, by simply clearing the shadow ptes (with kvm
mmu_lock spinlock to avoid racing with other vcpu spte accesses of
course) and flushing the shadow-pte after clearing the main linux pte,
it should be enough to serialize against shadow-pte page faults that
would call into get_user_pages. Flushing the host TLB before or after
the shadow-ptes shouldn't matter.
Comments welcome... especially from SGI/IBM/Quadrics and all other
potential users of this functionality.
Patch is running on my desktop and swapping out a 3G non-linux VM, smp
guest and smp host as I write this, it seems to work fine (only
tested with SVM so far).
If you're interested in the KVM usage of this feature, in the below
link you can see how it enables full KVM swapping using the core linux
kernel virtual memory algorithms using the KVM rmap (like pte-chains)
to unmap shadow-ptes in addition to the mm/rmap.c for the regular
ptes.
http://marc.info/?l=kvm-devel&m=120023119710198&w=2
This is a zero-risk patch when unused. So I hope we can quickly
concentrate on finalize the interface and merge it ASAP. It's mostly a
matter of deciding if this is the right way of getting notification of
VM mapping invalidations, mapping instantiations for secondary
TLBs/MMUs/RDMA/Shadow etc...
There are also certain details I'm uncertain about, like passing 'mm'
to the lowlevel methods, my KVM usage of the invalidate_page()
notifier for example only uses 'mm' for a BUG_ON for example:
void kvm_mmu_notifier_invalidate_page(struct mmu_notifier *mn,
struct mm_struct *mm,
[..]
BUG_ON(mm != kvm->mm);
[..]
BTW, if anybody needs 'mm' the mm could also be stored in the
container of the 'mn', incidentally like in KVM case. containerof is
an efficient and standard way to do things. OTOH I kept passing down
the 'mm' like below just in case others don't have 'mm' saved in the
container for other reasons like we have in struct kvm, and they
prefer to get it through registers/stack. In practice it won't make
any measurable difference, it's mostly a style issue.
Signed-off-by: Andrea Arcangeli <[EMAIL PROTECTED]>
diff --git a/include/asm-generic/pgtable.h b/include/asm-generic/pgtable.h
--- a/include/asm-generic/pgtable.h
+++ b/include/asm-generic/pgtable.h
@@ -86,6 +86,7 @@ do {
\
pte_t __pte;\
__pte = ptep_get_and_clear((__vma)->vm_mm, __address, __ptep); \
flush_tlb_page(__vma, __address); \
+ mmu_notifier(invalidate_page, (__vma)->vm_mm, __address); \
__pte; \
})
#endif
diff --git a/include/linux/mm.h b/include/linux/mm.h
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -13,6 +13,7 @@
#include
#include
#include
+#include
struct mempolicy;
struct anon_vma;
diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
--- a/include/linux/mm_types.h
+++ b/include/linux/mm_types.h
@@ -219,6 +219,10 @@ struct mm_struct {
/* aio bits */
rwlock_tioctx_list_lock;
[kvm-devel] [PATCH] Fix compilation of kvm-59 with older kernel includes
I needed the following patch to make kvm-59 compile on SUSE 10.2. Yes it's a bug in the standard includes. -Andi diff -u kvm-59/qemu/usb-linux.c-o kvm-59/qemu/usb-linux.c --- kvm-59/qemu/usb-linux.c-o 2008-01-01 10:20:24.0 +0100 +++ kvm-59/qemu/usb-linux.c 2008-01-13 17:16:46.0 +0100 @@ -26,6 +26,8 @@ #include "console.h" #if defined(__linux__) +#define __user + #include #include #include -Andi - 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] report revision 3 of the ACPI/SMBus PIIX4 controller
Marcelo Tosatti <[EMAIL PROTECTED]> writes: > On Sun, Jan 13, 2008 at 12:19:20PM +0100, Anders wrote: [...] >> How do you get that high consumption? What combination of clocks/hz on >> host/guest are you using? > > CONFIG_HZ=250 Okay, with nohz=off (in the guest) I also see some higher load. I didn't try the patch, though. > UP guests use TSC as a clocksource by default, and TSC reads won't > cause a VMExit. So for the lightest load (power saving), I should use UP and TSC? Thanks, Anders. - 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 swapping with mmu notifiers
Andrea Arcangeli wrote:
> Hi everyone,
>
> So far KVM swapping has been a limited feature. Depending on the
> workloads huge chunks of the anonymous memory simulating the guest
> physical memory could get pinned and unswappable for extended periods
> of time. Whenever a spte mapps a host physical page, KVM has to pin
> the page to prevent it to be swapped out. The page could still be
> unmapped from the Linux VM ptes, it could go in swapcache, but the
> boosted reference count (due to the spte pointing to the host physical
> page) would prevent the page to be freed (and rightfully so). The big
> difference is that the mmu notifier patch now allows KVM to know when
> the the main Linux VM wants to unmap a certain host physical
> page. When that happens KVM now make sure to release all sptes and to
> drop the reference count of the page, so the page can finally be
> swapped out for real in any case. This way the KVM task can now be
> swapped out fully and at any time regardless of the guest OS activity
> and regardless the size of the readonly shadow-pte cache generated by
> the guest-OS.
>
> Last test I run on this code was to run two VM on dual core SVM host,
> SMP guest (4 vcpus). The linux vm was ~400M the other VM was 3G. Host
> system has 2G ram + 4G swap.
>
> Starting a heavy VM job both VM are swapped out quite nicely (one VM
> was running my oom deadlock testcase for the linux-mm oom patches, the
> other was playing a youtube video):
>
> andrea9742 57.7 2.5 588536 50104
> andrea9809 69.3 9.4 3211172 182448
>
> After sigstopping both and running the same heavy VM job again I get:
>
> andrea9742 42.6 0.0 588536 644
> andrea9809 48.2 0.0 3211172 848
>
> So when sigstopped less than 1M of rss remains allocated in ram.
>
> After sigcont and after killing the heavy VM job (that released lots
> of ram and swap) both VM gracefully restarts with only swapins firing
> in the host:
>
> andrea9742 57.6 2.0 588536 39308
> andrea9809 61.6 61.4 3211172 1186256
>
Very cool!
> No idea why the non-linux VM after a while grows back to a 1G working
> set despite a single youtube playback is playing in the guest... ;),
> the linux vm OTOH has only a 39M working set when idling in the oom
> loops.
>
Perhaps the non-Linux guest has a page scrubber that runs while the
system is otherwise idle.
Regards,
Anthony Liguori
> Host must be compiled with CONFIG_MMU_NOTIFIERS=y of course, or this
> won't work.
>
> Here the patch to kvm.git (there's some room for optimization in doing
> a single tlb flush in the unmap_spte for all sptes pointing to the
> page, or even more aggressively for the whole range in the
> invalidate_range case, but the invalidate_range isn't an interesting
> path for kvm so I guess not worth optimizing in the short/mid term,
> but by optimizing the invalidate_page case we may halve the number of
> tlb flushes for some common case. I leave it for later, the swapping
> is heavily I/O bound anyway so a some more ipi in smp host shouldn't
> be very measurable (on UP host it makes no difference to flush
> multiple times in practice).
>
> Signed-off-by: Andrea Arcangeli <[EMAIL PROTECTED]>
>
> diff --git a/arch/x86/kvm/Kconfig b/arch/x86/kvm/Kconfig
> index 4086080..c527d7d 100644
> --- a/arch/x86/kvm/Kconfig
> +++ b/arch/x86/kvm/Kconfig
> @@ -18,6 +18,7 @@ config KVM
> tristate "Kernel-based Virtual Machine (KVM) support"
> depends on ARCH_SUPPORTS_KVM && EXPERIMENTAL
> select PREEMPT_NOTIFIERS
> + select MMU_NOTIFIER
> select ANON_INODES
> ---help---
> Support hosting fully virtualized guest machines using hardware
> diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
> index 324ff9a..103c270 100644
> --- a/arch/x86/kvm/mmu.c
> +++ b/arch/x86/kvm/mmu.c
> @@ -532,6 +532,36 @@ static void rmap_write_protect(struct kvm *kvm, u64 gfn)
> kvm_flush_remote_tlbs(kvm);
> }
>
> +static void unmap_spte(struct kvm *kvm, u64 *spte)
> +{
> + struct page *page = pfn_to_page((*spte & PT64_BASE_ADDR_MASK) >>
> PAGE_SHIFT);
> + get_page(page);
> + rmap_remove(kvm, spte);
> + set_shadow_pte(spte, shadow_trap_nonpresent_pte);
> + kvm_flush_remote_tlbs(kvm);
> + __free_page(page);
> +}
> +
> +void kvm_rmap_unmap_gfn(struct kvm *kvm, gfn_t gfn)
> +{
> + unsigned long *rmapp;
> + u64 *spte, *curr_spte;
> +
> + spin_lock(&kvm->mmu_lock);
> + gfn = unalias_gfn(kvm, gfn);
> + rmapp = gfn_to_rmap(kvm, gfn);
> +
> + spte = rmap_next(kvm, rmapp, NULL);
> + while (spte) {
> + BUG_ON(!(*spte & PT_PRESENT_MASK));
> + rmap_printk("rmap_swap_page: spte %p %llx\n", spte, *spte);
> + curr_spte = spte;
> + spte = rmap_next(kvm, rmapp, spte);
> + unmap_spte(kvm, curr_spte);
> + }
> + spin_unlock(&kvm->mmu_lock);
> +}
> +
> #ifdef MMU_DEBUG
> static int is_empty_shadow_page(u64 *spt)
> {
> diff --git a/arch/x86/kvm/x86.c b/a
Re: [kvm-devel] [PATCH] report revision 3 of the ACPI/SMBus PIIX4 controller
On Sun, Jan 13, 2008 at 12:19:20PM +0100, Anders wrote: > Marcelo Tosatti <[EMAIL PROTECTED]> writes: > > > This reduces idle guest CPU consumption from 14% to 8% on 4-way KVM > > guest. > > How do you get that high consumption? What combination of clocks/hz on > host/guest are you using? CONFIG_HZ=250 4-way SMP guest, 8-way Intel host (without the VMX TSC sync patch posted previously). > I am cursious, since my idle KVM process is at less than 1%. You have an UP guest right? The problem is that the TSC synchronization check on boot is only performed on SMP guests. Intel hosts usually have their TSC synchronized, whereas AMD ones don't, so they fall back to use the ACPI PM timer (until the HPET QEMU/KVM support is in place). UP guests use TSC as a clocksource by default, and TSC reads won't cause a VMExit. - 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] add acpi powerbutton support
Avi Kivity wrote: > Guido Guenther wrote: >> On Tue, Jan 08, 2008 at 10:50:00AM +0200, Avi Kivity wrote: >> >>> Yes, you can press the VM's power button (system_powerdown in the >>> monitor) and it will invoke the OS shutdown sequence. >>> >>> Only worked on Linux in my testing though. >>> >> It works for me _when_ I pass --no-kvm-irqchip. So it seems Windows >> ignores the MADT entries or something. >> > > -no-kvm-irqchip implies ignoring the polarity, since qemu doesn't > implement ioapic polarity. > > I think we need to go back to active low pci irqs, and to have > no-ioapic working we need to insert an inverter between the pci irq > links and the pic. I base this on the following: > > - piix doesn't contain an ioapic, so the actual lines must be active low > - the piix pic elcr is documented as active-high for level-triggered irqs > Okay, this is likely right as I was able to shutdown both Windows and Linux with the following: - backout the madt interrupt source override changes - declare all interrupts as active low - negate pci irq interrupts in qemu just before forwarding to kvm (so they become active low) - negate pci irq interrupts in the kernel just before forwarding to the pic (so that they become active high, but leaving the ioapic interrupts active low) There's quite a bit of work before that can be committed, though. I want to generalize interrupt routing in the kernel, and we need tons of backward compatibility in the dsdt so that older hosts can still function. -- 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] KVM swapping with mmu notifiers
Hi everyone,
So far KVM swapping has been a limited feature. Depending on the
workloads huge chunks of the anonymous memory simulating the guest
physical memory could get pinned and unswappable for extended periods
of time. Whenever a spte mapps a host physical page, KVM has to pin
the page to prevent it to be swapped out. The page could still be
unmapped from the Linux VM ptes, it could go in swapcache, but the
boosted reference count (due to the spte pointing to the host physical
page) would prevent the page to be freed (and rightfully so). The big
difference is that the mmu notifier patch now allows KVM to know when
the the main Linux VM wants to unmap a certain host physical
page. When that happens KVM now make sure to release all sptes and to
drop the reference count of the page, so the page can finally be
swapped out for real in any case. This way the KVM task can now be
swapped out fully and at any time regardless of the guest OS activity
and regardless the size of the readonly shadow-pte cache generated by
the guest-OS.
Last test I run on this code was to run two VM on dual core SVM host,
SMP guest (4 vcpus). The linux vm was ~400M the other VM was 3G. Host
system has 2G ram + 4G swap.
Starting a heavy VM job both VM are swapped out quite nicely (one VM
was running my oom deadlock testcase for the linux-mm oom patches, the
other was playing a youtube video):
andrea9742 57.7 2.5 588536 50104
andrea9809 69.3 9.4 3211172 182448
After sigstopping both and running the same heavy VM job again I get:
andrea9742 42.6 0.0 588536 644
andrea9809 48.2 0.0 3211172 848
So when sigstopped less than 1M of rss remains allocated in ram.
After sigcont and after killing the heavy VM job (that released lots
of ram and swap) both VM gracefully restarts with only swapins firing
in the host:
andrea9742 57.6 2.0 588536 39308
andrea9809 61.6 61.4 3211172 1186256
No idea why the non-linux VM after a while grows back to a 1G working
set despite a single youtube playback is playing in the guest... ;),
the linux vm OTOH has only a 39M working set when idling in the oom
loops.
Host must be compiled with CONFIG_MMU_NOTIFIERS=y of course, or this
won't work.
Here the patch to kvm.git (there's some room for optimization in doing
a single tlb flush in the unmap_spte for all sptes pointing to the
page, or even more aggressively for the whole range in the
invalidate_range case, but the invalidate_range isn't an interesting
path for kvm so I guess not worth optimizing in the short/mid term,
but by optimizing the invalidate_page case we may halve the number of
tlb flushes for some common case. I leave it for later, the swapping
is heavily I/O bound anyway so a some more ipi in smp host shouldn't
be very measurable (on UP host it makes no difference to flush
multiple times in practice).
Signed-off-by: Andrea Arcangeli <[EMAIL PROTECTED]>
diff --git a/arch/x86/kvm/Kconfig b/arch/x86/kvm/Kconfig
index 4086080..c527d7d 100644
--- a/arch/x86/kvm/Kconfig
+++ b/arch/x86/kvm/Kconfig
@@ -18,6 +18,7 @@ config KVM
tristate "Kernel-based Virtual Machine (KVM) support"
depends on ARCH_SUPPORTS_KVM && EXPERIMENTAL
select PREEMPT_NOTIFIERS
+ select MMU_NOTIFIER
select ANON_INODES
---help---
Support hosting fully virtualized guest machines using hardware
diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index 324ff9a..103c270 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -532,6 +532,36 @@ static void rmap_write_protect(struct kvm *kvm, u64 gfn)
kvm_flush_remote_tlbs(kvm);
}
+static void unmap_spte(struct kvm *kvm, u64 *spte)
+{
+ struct page *page = pfn_to_page((*spte & PT64_BASE_ADDR_MASK) >>
PAGE_SHIFT);
+ get_page(page);
+ rmap_remove(kvm, spte);
+ set_shadow_pte(spte, shadow_trap_nonpresent_pte);
+ kvm_flush_remote_tlbs(kvm);
+ __free_page(page);
+}
+
+void kvm_rmap_unmap_gfn(struct kvm *kvm, gfn_t gfn)
+{
+ unsigned long *rmapp;
+ u64 *spte, *curr_spte;
+
+ spin_lock(&kvm->mmu_lock);
+ gfn = unalias_gfn(kvm, gfn);
+ rmapp = gfn_to_rmap(kvm, gfn);
+
+ spte = rmap_next(kvm, rmapp, NULL);
+ while (spte) {
+ BUG_ON(!(*spte & PT_PRESENT_MASK));
+ rmap_printk("rmap_swap_page: spte %p %llx\n", spte, *spte);
+ curr_spte = spte;
+ spte = rmap_next(kvm, rmapp, spte);
+ unmap_spte(kvm, curr_spte);
+ }
+ spin_unlock(&kvm->mmu_lock);
+}
+
#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 8a90403..e9a3f6e 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -3159,6 +3159,36 @@ void kvm_arch_vcpu_uninit(struct kvm_vcpu *vcpu)
free_page((unsigned long)vcpu->arch.pio_data);
}
+static inline struct kvm *mmu_notifier_to_kvm(struct mmu_notifier *mn)
+{
+ return container_of(mn,
Re: [kvm-devel] boot stops after console handover?
Carlo Marcelo Arenas Belon wrote: > On Sat, Jan 12, 2008 at 06:07:19PM +, Antoine Martin wrote: If that doesn't work, maybe you can upload an image for me to debug. >>> http://194.145.196.85/kvm/vmlinuz-2.6.24-rc7.bz2 >>> >> Any luck? Any other ideas for me to try? > > see if the problem goes away with -no-kvm-irqchip and using "nolapic" in the > guest kernel No change. > if that doesn't fix it, use the last kvm code as an external module No change. :( Antoine - 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] mmu notifiers
Robin Holt wrote: > On Sat, Jan 12, 2008 at 09:51:56PM +0200, Avi Kivity wrote: > >> Christoph Lameter wrote: >> >>> On Thu, 10 Jan 2008, Avi Kivity wrote: >>> >>> >>> Actually sharing memory is possible even without this patch; one simply mmap()s a file into the address space of both guests. Or are you referring to something else? >>> A file from where? If a file is read by two guests then they will have >>> distinct page structs. >>> >>> >>> >> Two kvm instances mmap() the file (from anywhere) into the guest address >> space. That memory is shared, and will be backed by the same page structs >> at the same offset. >> > > That sounds nice, but... > > For larger machine configurations, we have different memory access > capabilities. When a partition that is located close to the home node > of the memory accesses memory, it is normal access. When it is further > away, they get special access to the line. Before the shared line is > sent to the reading node, it is converted by the memory controller into > an exclusive request and the reading node is handed the only copy of > the line. If we gave a remote kernel access to the page, we would also > open the entire owning nodes page tables up to speculative references > which effectively would be viewed by hardware as cache-line contention. > > Additionally, we have needs beyond memory backed by files. Including > special devices which do not have struct pages at all (see mspec.c). > I don't understand. I was just explaining how kvm shares memory among guests (which does not require mmu notifiers); if you have some other configuration that can benefit from mmu notifiers, then, well, great. -- 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] fix VMX TSC synchronicity
Marcelo Tosatti wrote:
> The boot TSC sync check is failing on recent Linux SMP guests on TSC
> stable hosts.
>
>
What about tsc unstable hosts? If your patch convinces the guest its
tsc is table, while the host tsc is not, then it may cause confusion
later on.
> Following patch attempts to address the problems, which are:
>
> 1) APIC_DM_STARTUP, which is only called for vcpu's other than vcpu0,
> will trigger ->vcpu_reset(), setting the TSC to 0. Fix that by moving
> the guest_write_tsc(0) to vcpu_load.
>
> 2) vcpu's are initialized at different times by QEMU (vcpu0 init happens
> way earlier than the rest). Fix that by initializing the TSC of vcpu's >
> 0 with reference to vcpu0 init tsc value. This way TSC synchronization
> is kept (apparently Xen does something similar).
>
> 3) The code which adjusts the TSC of a VCPU on physical CPU switch is
> meant to guarantee that the guest sees a monotonically increasing value.
> However there is a large gap, in terms of clocks, between the time which
> the source CPU TSC is read and the time the destination CPU TSC is read.
> So move those two reads to happen at vcpu_clear.
>
> I believe that 3) is the reason for the -no-kvm-irqchip problems
> reported by Avi on RHEL5, with kernels < 2.6.21 (where vcpu->cpu pinning
> would fix the problem). Unfortunately I could reproduce that problem.
>
> 4-way guest with constant tick at 250Hz now reliably sees the TSC's
> synchronized, and idle guest CPU consumption is reduced by 50% (3-4%
> instead of 8%, the latter with acpi_pm_good boot parameter).
>
>
> diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
> index 4741806..e1c8cf4 100644
> --- a/arch/x86/kvm/vmx.c
> +++ b/arch/x86/kvm/vmx.c
> @@ -47,6 +47,8 @@ struct vcpu_vmx {
> struct kvm_vcpu vcpu;
> int launched;
> u8fail;
> + u64 first_tsc;
> + u64 tsc_this;
> u32 idt_vectoring_info;
> struct kvm_msr_entry *guest_msrs;
> struct kvm_msr_entry *host_msrs;
> @@ -254,6 +256,7 @@ static void vcpu_clear(struct vcpu_vmx *vmx)
> if (vmx->vcpu.cpu == -1)
> return;
> smp_call_function_single(vmx->vcpu.cpu, __vcpu_clear, vmx, 0, 1);
> + rdtscll(vmx->tsc_this);
> vmx->launched = 0;
> }
>
> @@ -480,6 +483,8 @@ static void vmx_load_host_state(struct vcpu_vmx *vmx)
> reload_host_efer(vmx);
> }
>
> +static void guest_write_tsc(u64 host_tsc, u64 guest_tsc);
> +
> /*
> * Switches to specified vcpu, until a matching vcpu_put(), but assumes
> * vcpu mutex is already taken.
> @@ -488,7 +493,7 @@ static void vmx_vcpu_load(struct kvm_vcpu *vcpu, int cpu)
> {
> struct vcpu_vmx *vmx = to_vmx(vcpu);
> u64 phys_addr = __pa(vmx->vmcs);
> - u64 tsc_this, delta;
> + u64 delta;
>
> if (vcpu->cpu != cpu) {
> vcpu_clear(vmx);
> @@ -511,6 +516,19 @@ static void vmx_vcpu_load(struct kvm_vcpu *vcpu, int cpu)
> struct descriptor_table dt;
> unsigned long sysenter_esp;
>
> + if (unlikely(vcpu->cpu == -1)) {
>
This can happen after migration, I believe.
> + rdtscll(vcpu->arch.host_tsc);
> + vmx->tsc_this = vcpu->arch.host_tsc;
> + if (vcpu->vcpu_id == 0) {
> + guest_write_tsc(vcpu->arch.host_tsc, 0);
> + vmx->first_tsc = vcpu->arch.host_tsc;
> + } else {
> + struct vcpu_vmx *cpu0;
> + cpu0 = to_vmx(vcpu->kvm->vcpus[0]);
> + guest_write_tsc(cpu0->first_tsc, 0);
> + }
> + }
> +
>
Depending on vcpu_id == 0 can cause problems (for example, if vcpu 0 is
somehow not the first to run).
We might initialize the tsc base on vm creation, and if the host tsc is
synced, then the guest tsc should also be.
> vcpu->cpu = cpu;
> /*
>* Linux uses per-cpu TSS and GDT, so set these when switching
> @@ -526,8 +544,7 @@ static void vmx_vcpu_load(struct kvm_vcpu *vcpu, int cpu)
> /*
>* Make sure the time stamp counter is monotonous.
>*/
> - rdtscll(tsc_this);
> - delta = vcpu->arch.host_tsc - tsc_this;
> + delta = vcpu->arch.host_tsc - vmx->tsc_this;
> vmcs_write64(TSC_OFFSET, vmcs_read64(TSC_OFFSET) + delta);
>
This is a little roundabout, how about moving the delta calculation
immediately after the call to vcpu_clear()?
I don't think this is the cause of the problem, it can't account for
more than a few hundred cycles, compared to the much greater vmentry cost.
Anyway it should be in a separate patch.
--
error compiling committee.c: too many arguments to function
---
Re: [kvm-devel] mmu notifiers
On Sat, Jan 12, 2008 at 09:51:56PM +0200, Avi Kivity wrote: > Christoph Lameter wrote: >> On Thu, 10 Jan 2008, Avi Kivity wrote: >> >> >>> Actually sharing memory is possible even without this patch; one simply >>> mmap()s a file into the address space of both guests. Or are you >>> referring to >>> something else? >>> >> >> A file from where? If a file is read by two guests then they will have >> distinct page structs. >> >> > > Two kvm instances mmap() the file (from anywhere) into the guest address > space. That memory is shared, and will be backed by the same page structs > at the same offset. That sounds nice, but... For larger machine configurations, we have different memory access capabilities. When a partition that is located close to the home node of the memory accesses memory, it is normal access. When it is further away, they get special access to the line. Before the shared line is sent to the reading node, it is converted by the memory controller into an exclusive request and the reading node is handed the only copy of the line. If we gave a remote kernel access to the page, we would also open the entire owning nodes page tables up to speculative references which effectively would be viewed by hardware as cache-line contention. Additionally, we have needs beyond memory backed by files. Including special devices which do not have struct pages at all (see mspec.c). Thanks, Robin - 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] portability: configure top level dependencies per architecture
Christian Ehrhardt wrote: > This includes the comments from Avi to "[PATCH] portability: add top level > config-$arch files v2". Putting the arch dependencies into if's saves us 4 > config-$arch files which are not essential to fix the current issue. > Since this is copy&paste from Avis response to v2 I added him to the From list > > changes to v2: > - remove config-$arch files > - put arch dep in if's checking the arch to add more dependencies to a >target directly in the top level Makefile > > Applied, 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] current kvm userspace git doesn't compile on i386
Christoph Hellwig wrote: > Current kvm userspace git configured with ./configure --prefix=/opt/kvm > --with-patched-kernel --qemu-cc=/usr/bin/gcc-3.4 gives: > > /usr/bin/gcc-3.4 -L /home/hch/work/kvm-userspace/qemu/../libkvm -g -o > qemu-system-x86_64 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 virtio.o virtio-net.o virtio-blk.o > ide.o pckbd.o ps2.o vga.o sb16.o es1370.o dma.o fdc.o mc146818rtc.o serial.o > i8259.o i8254.o pcspk.o pc.o cirrus_vga.o apic.o parallel.o acpi.o piix_pci.o > usb-uhci.o vmmouse.o vmport.o vmware_vga.o extboot.o gdbstub.o > ../libqemu_common.a libqemu.a > /home/hch/work/kvm-userspace/qemu/../libkvm/libkvm.a -lm -lz -lkvm -lgnutls > -L/usr/lib -lSDL -lrt -lpthread -lutil > libqemu.a(kvm-tpr-opt.o): In function `enable_vapic': > /home/hch/work/kvm-userspace/qemu/kvm-tpr-opt.c:221: undefined reference to > `kvm_enable_vapic' > libqemu.a(kvm-tpr-opt.o): In function `kvm_tpr_opt_setup': > /home/hch/work/kvm-userspace/qemu/kvm-tpr-opt.c:287: undefined reference to > `kvm_enable_tpr_access_reporting' > collect2: ld returned 1 exit status > make[2]: *** [qemu-system-x86_64] Error 1 > make[2]: Leaving directory > `/home/hch/work/kvm-userspace/qemu/x86_64-softmmu' > make[1]: *** [subdir-x86_64-softmmu] Error 2 > make[1]: Leaving directory `/home/hch/work/kvm-userspace/qemu' > make: *** [qemu] Error 2 > Try to build the kernel modules too (remove '--with-patched-kernel' from ./configure arguments ): ./configure --prefix=/opt/kvm --qemu-cc=/usr/bin/gcc-3.4 ; make -C kernel LINUX= sync; make You will have to rmmod current kvm modules and insmod the built modules under /kernel. - 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] report revision 3 of the ACPI/SMBus PIIX4 controller
Marcelo Tosatti <[EMAIL PROTECTED]> writes: > This reduces idle guest CPU consumption from 14% to 8% on 4-way KVM > guest. How do you get that high consumption? What combination of clocks/hz on host/guest are you using? I am cursious, since my idle KVM process is at less than 1%. Regards, Anders. - 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] report revision 3 of the ACPI/SMBus PIIX4 controller
Marcelo Tosatti wrote: > The PIIX4 ACPI controller prior to revision 0x3 contains a bug where > reading of the timer port is unreliable, so the kernel reads it three > times for consistency check. > > QEMU does not suffer from that problem :) > > The datasheet for PIIX4, PIIX4E, and PIIX4M is the same. I failed to > find any indication that the revision increase could affect anything > other than the PMTimer port read. > > This reduces idle guest CPU consumption from 14% to 8% on 4-way KVM > guest. > > Applied (to kvm's qemu), 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] [kvm-ppc-devel] RFC: MMIO endianness flag
Hollis Blanchard wrote:
> On Thu, 2008-01-10 at 17:28 +0200, Avi Kivity wrote:
>
>> I'll apply that patch (with a #ifdef CONFIG_PPC so other archs don't
>> use it by mistake).
>>
>
> I don't think that's the right ifdef. For example, I believe IA64 can
> run in BE mode and so will have the same issue, and there are certainly
> other architectures (less relevant to the current code) that definitely
> are in the same situation.
>
> We need to plumb this through to the libkvm users anyways. Take a look
> at the patch below and tell me if you think it's not the right approach.
> x86 simply won't consider 'is_bigendian'. I spent a lot of time on this,
> and it's by far the cleanest solution I could come up with.
>
>
>
>
> +#ifdef ARCH_MMIO_ENDIAN_BIG
> +static int handle_mmio_bigendian(kvm_context_t kvm, struct kvm_run *kvm_run)
> +{
> + if (kvm_run->mmio.is_write)
> + return kvm->callbacks->mmio_write_be(kvm->opaque,
> + kvm_run->mmio.phys_addr,
> + kvm_run->mmio.data,
> + kvm_run->mmio.len);
> + else
> + return kvm->callbacks->mmio_read_be(kvm->opaque,
> + kvm_run->mmio.phys_addr,
> + kvm_run->mmio.data,
> + kvm_run->mmio.len);
> +}
> +#endif
>
Do we really need to propagate endianness all the way to the user?
Perhaps libkvm could call the regular mmio functions and do the
transformation itself.
Or maybe even the kernel can do this by itself?
--
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] add acpi powerbutton support
Guido Guenther wrote: > On Tue, Jan 08, 2008 at 10:50:00AM +0200, Avi Kivity wrote: > >> Yes, you can press the VM's power button (system_powerdown in the >> monitor) and it will invoke the OS shutdown sequence. >> >> Only worked on Linux in my testing though. >> > It works for me _when_ I pass --no-kvm-irqchip. So it seems Windows > ignores the MADT entries or something. > -no-kvm-irqchip implies ignoring the polarity, since qemu doesn't implement ioapic polarity. I think we need to go back to active low pci irqs, and to have no-ioapic working we need to insert an inverter between the pci irq links and the pic. I base this on the following: - piix doesn't contain an ioapic, so the actual lines must be active low - the piix pic elcr is documented as active-high for level-triggered irqs -- 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] fill kvm_callback with arch specific dcr_read/dcr_write callbacks v2
Avi Kivity wrote: > Christian Ehrhardt wrote: >> Subject: [PATCH] fill kvm_callback with arch specific >> dcr_read/dcr_write callbacks v2 >> From: Christian Ehrhardt <[EMAIL PROTECTED]> >> >> This Patch adds the callback assignment and handlers for >> powerpc_dcr_read >> and ppc_dcr_write which are called from libkvm. >> This is the part of the patch that changes already submitted code. >> Changes in v2: >> The function arguments of powerpc_dcr_read/write changed. Since >> main-ppc.c >> is not yet upstream when you check out from kvm-userspace.git I >> didn't see it. >> But Avi replied with "Applied all, thanks." to the three patches from >> 01/09/2008 bringing main-ppc.c into kvm-userspace this v2 patch >> includes the >> needed code for that file too. >> > > Sorry, I forgot to push after applying. I'll apply this incrementally. > Or rather, please send a new patch. I'd rather not risk mucking with code I can't compile. -- 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] fill kvm_callback with arch specific dcr_read/dcr_write callbacks v2
Christian Ehrhardt wrote: > Subject: [PATCH] fill kvm_callback with arch specific dcr_read/dcr_write > callbacks v2 > From: Christian Ehrhardt <[EMAIL PROTECTED]> > > This Patch adds the callback assignment and handlers for powerpc_dcr_read > and ppc_dcr_write which are called from libkvm. > This is the part of the patch that changes already submitted code. > Changes in v2: > The function arguments of powerpc_dcr_read/write changed. Since main-ppc.c > is not yet upstream when you check out from kvm-userspace.git I didn't see it. > But Avi replied with "Applied all, thanks." to the three patches from > 01/09/2008 bringing main-ppc.c into kvm-userspace this v2 patch includes the > needed code for that file too. > Sorry, I forgot to push after applying. I'll apply this incrementally. -- 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
