Re: [kvm-devel] Testing Results for TPR optimization tarball

On 10/26/07, Anthony Liguori <[EMAIL PROTECTED]> wrote: > > Haydn Solomon wrote: > > Yeah.. I also got BSOD with windows xp sp2. I'll continue to run with > > the tpr + rmap patch with one vcpu as that's running perfectly fine > > for me. Thanks. > > I don't think it's a regression. With the lates

Re: [kvm-devel] Testing Results for TPR optimization tarball

Haydn Solomon wrote: > Yeah.. I also got BSOD with windows xp sp2. I'll continue to run with > the tpr + rmap patch with one vcpu as that's running perfectly fine > for me. Thanks. I don't think it's a regression. With the latest git, I cannot install Windows XP with -smp 2. Regards, Anthony

[kvm-devel] [PATCH] Move libkvm (v2)

17 files changed, 64 insertions(+), 35 deletions(-) Makefile | 14 -- configure |4 ++-- libkvm/Makefile| 37 + libkvm/config-i386.mak |2 ++ libkvm/config-x86_64.mak |2 ++ libkvm/libkvm

[kvm-devel] [PATCH] Move libkvm into its own directory. No functional changes

16 files changed, 62 insertions(+), 33 deletions(-) Makefile | 14 -- configure |4 ++-- libkvm/Makefile| 37 + libkvm/config-i386.mak |2 ++ libkvm/config-x86_64.mak |2 ++ libkvm/libkvm

Re: [kvm-devel] RFC/patch portability: split kvm_vm_ioctl v3

Acked-by: Hollis Blanchard <[EMAIL PROTECTED]> On Fri, 2007-10-26 at 14:01 +0200, Carsten Otte wrote: > This patch splits kvm_vm_ioctl into archtecture independent parts, and > x86 specific parts which go to kvm_arch_vcpu_ioctl in x86.c. > The patch has been updated to current git, and it leaves

Re: [kvm-devel] Testing Results for TPR optimization tarball

Haydn Solomon wrote: > Were you able to do this with -smp 2 or more? I get a BSOD with -smp 2. But I haven't yet been able to confirm that this is a regression. Since the TPR optimization makes the install go over 2x as fast, it's throwing off my automated tests. Regards, Anthony Liguori >

Re: [kvm-devel] [kvm-ppc-devel] RFC/patch portability: split kvm_vm_ioctl v2

Carsten Otte wrote: > Hollis Blanchard wrote: > >> Izik's idea (as I understand it) is to have one ioctl registering all of >> RAM, and then multiple "configure slot" ioctls that tell the kernel how >> to divide that area into the guest physical address space. That seems >> more awkward to me an

Re: [kvm-devel] Testing Results for TPR optimization tarball

Haydn Solomon wrote: > Were you able to do this with -smp 2 or more? I haven't tried doing smp testing yet. But I can do that now. Regards, Anthony Liguori > On 10/26/07, *Anthony Liguori* <[EMAIL PROTECTED] > > wrote: > > With the patch to increase the minimum r

Re: [kvm-devel] Testing Results for TPR optimization tarball

Were you able to do this with -smp 2 or more? On 10/26/07, Anthony Liguori <[EMAIL PROTECTED]> wrote: > > With the patch to increase the minimum rmap cache, I've been able to > successful install and boot with kvm-test: > > Windows XP Professional (i386) > Windows Vista Enterprise Edition (i386) >

Re: [kvm-devel] kvm-48: kernel BUG at mmu.c:307! - invalid opcode: 0000 [#1]

On Fri, Oct 26, 2007 at 03:09:06PM +0100, Pedro Alves wrote: > > > Hello. > > I've been using kvm for a while, and it's been working great so far. Today > I got a kernel error pasted below. Strangely I got the same problem one or two hours ago. Here are some info about the host: - Distribution

Re: [kvm-devel] RFC/patch portability: split kvm_vm_ioctl v2

Zhang, Xiantao wrote: > I don't think we can move the whole function to arch-specific part, > because it should work well (or with few issues) for most archs. > Basically, IA64 mostly can use it directly. If we move them as > arch-specific, it will introduces many duplicates. As you said, S390 has

Re: [kvm-devel] [kvm-ppc-devel] RFC/patch portability: split kvm_vm_ioctl v2

Hollis Blanchard wrote: > Izik's idea (as I understand it) is to have one ioctl registering all of > RAM, and then multiple "configure slot" ioctls that tell the kernel how > to divide that area into the guest physical address space. That seems > more awkward to me and I don't seem a benefit. I thi

Re: [kvm-devel] [kvm-ppc-devel] RFC/patch portability: split kvm_vm_ioctl v2

On Fri, 2007-10-26 at 10:21 +0200, Carsten Otte wrote: > > As Xiantao pointed out, x86 and ia64 can share the same memory setup > code. But s390 and ppc don't. Therefore, I vote for putting it into > x86 for now, and come up with an approach to share between x86 and > ia64 later on. The only t

[kvm-devel] Testing Results for TPR optimization tarball

With the patch to increase the minimum rmap cache, I've been able to successful install and boot with kvm-test: Windows XP Professional (i386) Windows Vista Enterprise Edition (i386) Fedora 8 test 3 (i386) openSUSE 10.3 (x86_64) RHEL5 Server (x86_64) SLES10 (x86_64) Ubuntu 6.06.1 server (i386) Ub

[kvm-devel] kvm-48: kernel BUG at mmu.c:307! - invalid opcode: 0000 [#1]

Hello. I've been using kvm for a while, and it's been working great so far. Today I got a kernel error pasted below. Some system infos: Host: Slackware $ uname -a Linux nicola 2.6.23.1-smp #2 SMP Mon Oct 15 17:49:01 CDT 2007 i686 Intel(R) Core(TM)2 Duo CPU T7300 @ 2.00GHz GenuineIntel G

Re: [kvm-devel] [RFT] kvm with Windows optimization

Dong, Eddie wrote: >> BTW, is it wise to enable this by default for all guests? >> Ignoring the >> fact that we're modifying guest's memory without its knowledge, if a >> guest unmaps the VA mappings for the BIOS then all sorts of problems >> could occur. >> >> > Good movement! > > But, Vista

Re: [kvm-devel] [RFT] kvm with Windows optimization

Avi Kivity wrote: > Anthony Liguori wrote: >> Avi Kivity wrote: >> >>> Anthony Liguori wrote: >>> >> static int mmu_topup_memory_caches(struct kvm_vcpu *vcpu) >> { >> int r; >> >> kvm_mmu_free_some_pages(vcpu); >> r = mmu_topup_memory_cache(&vcpu->mmu_pte_c

Re: [kvm-devel] [PATCH 4/4] Let gcc to choose which registers to save (vmx-i386)

Laurent Vivier wrote: > This patch lets GCC to determine which registers to save when we > switch to/from a VCPU in the case of intel i386. > > I don't know if its patch is really usefull as it replaces <<< a popa/pusha by several pop/push. <<< I

Re: [kvm-devel] [PATCH 0/4] Let gcc to choose which registers to save

Laurent Vivier wrote: > This patch lets GCC to determine which registers to save when we > switch to/from a VCPU. > Applied all, thanks. Hopefully all the gccs out there will like it. -- error compiling committee.c: too many arguments to function ---

Re: [kvm-devel] [RFT] kvm with Windows optimization

Avi Kivity wrote: > Anthony Liguori wrote: >> Avi Kivity wrote: >>> Anthony Liguori wrote: > > Good movement! > > But, Vista won't work with patching. The memory guard in vista > will make the system refuse to service. Maybe we need a option > to check if it is vista. >

Re: [kvm-devel] [RFT] kvm with Windows optimization

Anthony Liguori wrote: > Avi Kivity wrote: >> Anthony Liguori wrote: Good movement! But, Vista won't work with patching. The memory guard in vista will make the system refuse to service. Maybe we need a option to check if it is vista. >>> >>> Are you sure

Re: [kvm-devel] [RFT] kvm with Windows optimization

Avi Kivity wrote: > Anthony Liguori wrote: >>> >>> Good movement! >>> >>> But, Vista won't work with patching. The memory guard in vista will >>> make the system refuse to service. Maybe we need a option >>> to check if it is vista. >>> >> >> Are you sure that Vista isn't just verifying mem

Re: [kvm-devel] [RFT] kvm with Windows optimization

Anthony Liguori wrote: >> >> Good movement! >> >> But, Vista won't work with patching. The memory guard in vista >> will make the system refuse to service. Maybe we need a option >> to check if it is vista. >> >> > > Are you sure that Vista isn't just verifying memory during > startup/dri

Re: [kvm-devel] [RFT] kvm with Windows optimization

Dong, Eddie wrote: >> BTW, is it wise to enable this by default for all guests? >> Ignoring the >> fact that we're modifying guest's memory without its knowledge, if a >> guest unmaps the VA mappings for the BIOS then all sorts of problems >> could occur. >> >> > Good movement! > > But, Vista

[kvm-devel] Remove hardware from host and add to guest?

Hi, is it with kvm possible to remove a hardware (for example: a second PCI-E Graphiccard)- mybe on boottime like by xen. And add dedicated this removed hardware (for example: a second PCI-E Graphiccard) to a guest system (for example: to improve the 3D-Graphic). With best regards, Michael --

Re: [kvm-devel] [kvm-ppc-devel] RFC/patch portability: split kvm_vm_ioctl v2

Carsten Otte wrote: > Avi Kivity wrote: > >> Carsten Otte wrote: >> >>> Avi Kivity wrote: >>> Why aren't memory slots common too? Only their number is different, while the implementation is the same. >>> Your approach makes the meaning of memory slot somewha

Re: [kvm-devel] [kvm-ppc-devel] RFC/patch portability: split kvm_vm_ioctl v2

Avi Kivity wrote: > Carsten Otte wrote: >> Avi Kivity wrote: >>> Why aren't memory slots common too? Only their number is different, >>> while the implementation is the same. >> Your approach makes the meaning of memory slot somewhat useless on >> s390, if that one may be sparse and may be resul

Re: [kvm-devel] High vm-exit latencies during kvm boot-up/shutdown

Dong, Eddie wrote: > Jan Kiszka wrote: > >> So if you want the higher performance of PCIe you need >> performance-killing wbindv (not to speak of latency)? That sounds a >> bit contradictory to me. So this is also true for native PCIe usage? >> >> > > Mmm, I won't say so. When you want to g

Re: [kvm-devel] [PATCH] kvm-userspace: Make tests compile on x86_64

Laurent Vivier wrote: > These modification are needed to allow me to compile kvm-userspace > on my x86_64 system. > oops, saw this too late and worked out a similar fix. -- error compiling committee.c: too many arguments to function ---

Re: [kvm-devel] [kvm-ppc-devel] RFC/patch portability: split kvm_vm_ioctl v2

Avi Kivity wrote: > Why aren't memory slots common too? Only their number is different, > while the implementation is the same. Your approach makes the meaning of memory slot somewhat useless on s390, if that one may be sparse and may be result of different allocations: On x86, there has to be

Re: [kvm-devel] RFC/patch portability: split kvm_vm_ioctl v3

This patch splits kvm_vm_ioctl into archtecture independent parts, and x86 specific parts which go to kvm_arch_vcpu_ioctl in x86.c. The patch has been updated to current git, and it leaves out memory slot registration work which is currently subject to a detailed discussion. Common ioctls for all

Re: [kvm-devel] [kvm-ppc-devel] RFC/patch portability: split kvm_vm_ioctl v2

Carsten Otte wrote: > Avi Kivity wrote: >> Why aren't memory slots common too? Only their number is different, >> while the implementation is the same. > Your approach makes the meaning of memory slot somewhat useless on > s390, if that one may be sparse and may be result of different > allocat

Re: [kvm-devel] [kvm-ppc-devel] RFC/patch portability: split kvm_vm_ioctl v2

Carsten Otte wrote: > Avi Kivity wrote: >> I was talking about x86. >> >> On x86, you need contiguous userspace, contiguous guest, but again, >> what's the problem with one memory slot? > There is no problem with one memory slot: it works. It's just that > Izik's idea gives us the opportunity to

Re: [kvm-devel] [kvm-ppc-devel] RFC/patch portability: split kvm_vm_ioctl v2

Avi Kivity wrote: > I was talking about x86. > > On x86, you need contiguous userspace, contiguous guest, but again, > what's the problem with one memory slot? There is no problem with one memory slot: it works. It's just that Izik's idea gives us the opportunity to have common code for all four

Re: [kvm-devel] [kvm-ppc-devel] RFC/patch portability: split kvm_vm_ioctl v2

Carsten Otte wrote: > Avi Kivity wrote: >> I don't really see a big difference between what we have now (sparse >> userspace, sparse guest) and Izik's idea (contiguous userspace, >> sparse guest). In both cases you need something like memory slots to >> describe the different sections. > We don

Re: [kvm-devel] [RFT] kvm with Windows optimization

Gildas wrote: >>> >> Right, installs seem not to like this release, but running an existing >> VM seems to work fine (mostly). >> > > A windows 2000 sp4 installation crashes as well (this time with > WORKER_THREAD_RETURNED_A_BAD_IRQL). This was reproduceable. I've > restarted the instal

Re: [kvm-devel] [kvm-ppc-devel] RFC/patch portability: split kvm_vm_ioctl v2

Avi Kivity wrote: > I don't really see a big difference between what we have now (sparse > userspace, sparse guest) and Izik's idea (contiguous userspace, sparse > guest). In both cases you need something like memory slots to describe > the different sections. We don't on s390: we receive a pag

Re: [kvm-devel] [RFT] kvm with Windows optimization

2007/10/26, Avi Kivity <[EMAIL PROTECTED]>: > Gildas wrote: > > 2007/10/25, Avi Kivity <[EMAIL PROTECTED]>: > > > >> This is a request for testing of an experimental kvm feature that > >> dramatically accelerates some Windows releases (when running with the > >> ACPI HAL, and especially with guest

Re: [kvm-devel] FW: [kvm-commits] KVM: Move interrupt injection out of interruptdisabled section

Dong, Eddie wrote: >>> >>> >> So you could set instruction length to 1 and adjust rip >> backwards by 1 :) >> >> Though you may need to remember the adjustment and undo it if >> you get a >> page fault on the IVT. >> >> >> > What I mean is HW implicitly take SW interrupt as what i

Re: [kvm-devel] FW: [kvm-commits] KVM: Move interrupt injection out of interruptdisabled section

>-Original Message- >From: Avi Kivity [mailto:[EMAIL PROTECTED] >Sent: 2007年10月26日 18:14 >To: Dong, Eddie >Cc: kvm-devel@lists.sourceforge.net >Subject: Re: [kvm-devel] FW: [kvm-commits] KVM: Move interrupt >injection out of interruptdisabled section > >Dong, Eddie wrote: >>> I didn't se

Re: [kvm-devel] FW: [kvm-commits] KVM: Move interrupt injection out of interruptdisabled section

Dong, Eddie wrote: >> I didn't see anything in 20.8.3 regarding injection of software >> interrupts to vm86 mode. And other sections in the manual (22.5.1) >> imply that it is possible. >> >> Maybe it's failing on something else? VM-entry instruction length? I >> see that it must be in the rang

Re: [kvm-devel] FW: [kvm-commits] KVM: Move interrupt injection out of interruptdisabled section

> > I didn't see anything in 20.8.3 regarding injection of software > interrupts to vm86 mode. And other sections in the manual (22.5.1) > imply that it is possible. > > Maybe it's failing on something else? VM-entry instruction length? I > see that it must be in the range 1-15. > It is VM

Re: [kvm-devel] [RFT] kvm with Windows optimization

Avi Kivity wrote: Jindrich Makovicka wrote: On Thu, 25 Oct 2007 13:39:33 -0400 "Haydn Solomon" <[EMAIL PROTECTED]> wrote: Thanks, that was quick. Finally, this (pre)release solved the long standing Java IE Plugin lockup problem for me. Thanks a lot! No, this

Re: [kvm-devel] [RFT] kvm with Windows optimization

Gildas wrote: > 2007/10/25, Avi Kivity <[EMAIL PROTECTED]>: > >> This is a request for testing of an experimental kvm feature that >> dramatically accelerates some Windows releases (when running with the >> ACPI HAL, and especially with guest SMP). The feature detects accesses >> by the guest t

Re: [kvm-devel] [RFT] kvm with Windows optimization

Dong, Eddie wrote: >>> >>> >> Thanks for the hint; I'll add that. I think Vista hits the tpr much >> less frequently, so it can work well without the optimization. >> >> > Curious: How do u know ROM is mapped 0xf in Windows? > Eddie > > > kvm_get_sregs(kvm_context, env->cpu

Re: [kvm-devel] High vm-exit latencies during kvm boot-up/shutdown

Dong, Eddie wrote: >>> >> Okay. In that case the host can emulate wbinvd by using the clflush >> instruction, which is much faster (although overall execution time may >> be higher), maintaining real-time response times. >> > > Faster? maybe. > The issue is clflush take va parameter. S

Re: [kvm-devel] FW: [kvm-commits] KVM: Move interrupt injection out of interruptdisabled section

Dong, Eddie wrote: > Avi Kivity wrote: > >> Dong, Eddie wrote: >> >>> Avi Kivity wrote: >>> >>> [we can try to improve it by using vm86 interrupt redirection which may allow event injection using VT instead of writing to the guest stack]. >>> A

Re: [kvm-devel] [RFT] kvm with Windows optimization

2007/10/25, Avi Kivity <[EMAIL PROTECTED]>: > This is a request for testing of an experimental kvm feature that > dramatically accelerates some Windows releases (when running with the > ACPI HAL, and especially with guest SMP). The feature detects accesses > by the guest to the Task Priority Regis

Re: [kvm-devel] [RFT] kvm with Windows optimization

Avi Kivity wrote: > Dong, Eddie wrote: >>> BTW, is it wise to enable this by default for all guests? >>> Ignoring the >>> fact that we're modifying guest's memory without its knowledge, if a >>> guest unmaps the VA mappings for the BIOS then all sorts of >>> problems could occur. >>> >>> >> Good

Re: [kvm-devel] High vm-exit latencies during kvm boot-up/shutdown

Avi Kivity wrote: > Dong, Eddie wrote: >> Avi Kivity wrote: >> >>> Dong, Eddie wrote: >>> > There's a two-liner required to make it work. I'll add it soon. > > > But you still needs to issue WBINVD to all pCPUs which just move non-response time from one place to anot

Re: [kvm-devel] High vm-exit latencies during kvm boot-up/shutdown

Dong, Eddie wrote: > > Jan Kiszka wrote: > > > > So if you want the higher performance of PCIe you need > > performance-killing wbindv (not to speak of latency)? That sounds a > > bit contradictory to me. So this is also true for native PCIe usage? > > > > Mmm, I won't say so. When you want to get

[kvm-devel] wbinvd

[no direct reply because gmane still breaks it] WBINVD or CLFLUSH is also needed to safely change caching attributes of pages that are already mapped. Since CLFLUSH is somewhat hard to use for this near all Linux kernels use WBINVD for this. Examples where this happens are ioremap() using PAT,

Re: [kvm-devel] FW: [kvm-commits] KVM: Move interrupt injection out of interruptdisabled section

Avi Kivity wrote: > Dong, Eddie wrote: >> Avi Kivity wrote: >> >>> [we can try to improve it by using vm86 interrupt redirection which >>> may allow event injection using VT instead of writing to the guest >>> stack]. >>> >>> >> Avi: >> I did an investigation to try to find a way if we can

[kvm-devel] [PATCH] kvm-userspace: Make tests compile on x86_64

These modification are needed to allow me to compile kvm-userspace on my x86_64 system. Signed-off-by: Laurent Vivier <[EMAIL PROTECTED]> --- user/config-x86-common.mak |2 +- user/config-x86_64.mak |2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/user/config-x86-

Re: [kvm-devel] High vm-exit latencies during kvm boot-up/shutdown

Dong, Eddie wrote: > Avi Kivity wrote: >> Dong, Eddie wrote: There's a two-liner required to make it work. I'll add it soon. >>> But you still needs to issue WBINVD to all pCPUs which just move >>> non-response time from one place to another, not? >>> >> You don't actually need to e

Re: [kvm-devel] [PATCH 1/2]KVM: x86_emulator: Decode the memory operand for 'mov'

Yang, Sheng wrote: > >From ebfc23b71051e5ab19d22fb3f9c3d57721566ea9 Mon Sep 17 00:00:00 2001 > From: Sheng Yang <[EMAIL PROTECTED]> > Date: Fri, 26 Oct 2007 13:41:28 +0800 > Subject: [PATCH] KVM: x86_emulator: Decode the memory operand for 'mov' > > For the following TPR patch, we must get gva for

Re: [kvm-devel] [PATCH 1/2]KVM: x86_emulator: Decode the memory operand for 'mov'

>From 3ceb677ffee889880020d8ccb6b9f2c5bfb05644 Mon Sep 17 00:00:00 2001 From: Sheng Yang <[EMAIL PROTECTED]> Date: Fri, 26 Oct 2007 17:15:36 +0800 Subject: [PATCH 1/2] KVM: x86_emulator: Decode the memory operand for 'mov' For the following TPR patch, we must get gva for executing instructions. Mo

Re: [kvm-devel] High vm-exit latencies during kvm boot-up/shutdown

Jan Kiszka wrote: > Dong, Eddie wrote: > >> Avi Kivity wrote: >> >>> Dong, Eddie wrote: >>> > There's a two-liner required to make it work. I'll add it soon. > > > But you still needs to issue WBINVD to all pCPUs which just move non-response time

Re: [kvm-devel] [kvm-ppc-devel] RFC/patch portability: split kvm_vm_ioctl v2

Carsten Otte wrote: > Carsten Otte wrote: > >> That's why memory allocation/preparation needs to be arch dependent: >> i386 needs a memory layout different from userspace page table due to >> your argument, and s390 needs to use the userspace page table due to >> hardware features we want to

Re: [kvm-devel] High vm-exit latencies during kvm boot-up/shutdown

Dong, Eddie wrote: > Avi Kivity wrote: > >> Dong, Eddie wrote: >> There's a two-liner required to make it work. I'll add it soon. >>> But you still needs to issue WBINVD to all pCPUs which just move >>> non-response time from one place to another, not? >>> >>>

Re: [kvm-devel] High vm-exit latencies during kvm boot-up/shutdown

Jan Kiszka wrote: > > So if you want the higher performance of PCIe you need > performance-killing wbindv (not to speak of latency)? That sounds a > bit contradictory to me. So this is also true for native PCIe usage? > Mmm, I won't say so. When you want to get RT performance, you won't use unkn

Re: [kvm-devel] FW: [kvm-commits] KVM: Move interrupt injection out of interruptdisabled section

Dong, Eddie wrote: > Avi Kivity wrote: > >> [we can try to improve it by using vm86 interrupt redirection >> which may >> allow event injection using VT instead of writing to the guest stack]. >> >> > Avi: > I did an investigation to try to find a way if we can deliver > IRQ to guest

Re: [kvm-devel] [PATCH 1/2]KVM: x86_emulator: Decode the memory operand for 'mov'

Avi Kivity wrote: > Yang, Sheng wrote: >>> From ebfc23b71051e5ab19d22fb3f9c3d57721566ea9 Mon Sep 17 00:00:00 2001 >> From: Sheng Yang <[EMAIL PROTECTED]> >> Date: Fri, 26 Oct 2007 13:41:28 +0800 >> Subject: [PATCH] KVM: x86_emulator: Decode the memory operand for 'mov' >> >> For the following TPR

Re: [kvm-devel] [kvm-ppc-devel] RFC/patch portability: split kvm_vm_ioctl v2

Carsten Otte wrote: > Avi Kivity wrote: > >> Hollis Blanchard wrote: >> >>> On Fri, 2007-10-26 at 00:12 +0200, Izik Eidus wrote: >>> >>> ok i was thinking, maybe we can rewrite the way kvm hold memory so more code would be shared, lets say we throw away all the slot

Re: [kvm-devel] somthing new for shared memory???

Izik Eidus wrote: > beside moving the memory allocation to userspace (this is first step in > share memory between VMs using smart file system) > there is not much advance. > > about sharing memory between VM and host, we improved it by adding > partial swapping support, > so the host can take m

Re: [kvm-devel] [RFT] kvm with Windows optimization

Dong, Eddie wrote: >> BTW, is it wise to enable this by default for all guests? >> Ignoring the >> fact that we're modifying guest's memory without its knowledge, if a >> guest unmaps the VA mappings for the BIOS then all sorts of problems >> could occur. >> >> > Good movement! > > But, Vista

Re: [kvm-devel] compile kvm on fc6

Zhao, Yunfeng wrote: > Kvm cannot be compiled on fc6 which doesn't define CONFIG_HAS_IOMEM. > > I added a fix in kernel/external-module-compat.h. Should work now. -- error compiling committee.c: too many arguments to function ---

Re: [kvm-devel] [kvm-ppc-devel] RFC/patch portability: split kvm_vm_ioctl v2

Carsten Otte wrote: > That's why memory allocation/preparation needs to be arch dependent: > i386 needs a memory layout different from userspace page table due to > your argument, and s390 needs to use the userspace page table due to > hardware features we want to exploit. > As Xiantao pointed o

Re: [kvm-devel] High vm-exit latencies during kvm boot-up/shutdown

Avi Kivity wrote: > Dong, Eddie wrote: >>> There's a two-liner required to make it work. I'll add it soon. >>> >>> >> But you still needs to issue WBINVD to all pCPUs which just move >> non-response time from one place to another, not? >> > > You don't actually need to emulate wbinvd, you can

Re: [kvm-devel] RFC/patch portability: split kvm_vm_ioctl v2

Izik Eidus wrote: > ok i was thinking, > maybe we can rewrite the way kvm hold memory so more code would be shared, > lets say we throw away all the slots and arch depended stuff, and we let kvm > just hold the userspace allocated memory address, > > then we will will have to each arch "arch speci

Re: [kvm-devel] FW: [kvm-commits] KVM: Move interrupt injection out of interruptdisabled section

Avi Kivity wrote: > [we can try to improve it by using vm86 interrupt redirection > which may > allow event injection using VT instead of writing to the guest stack]. > Avi: I did an investigation to try to find a way if we can deliver IRQ to guest real mode using VM_ENTRY_INTR_INFO like w

Re: [kvm-devel] [kvm-ppc-devel] RFC/patch portability: split kvm_vm_ioctl v2

Avi Kivity wrote: > Hollis Blanchard wrote: >> On Fri, 2007-10-26 at 00:12 +0200, Izik Eidus wrote: >> >>> ok i was thinking, >>> maybe we can rewrite the way kvm hold memory so more code would be shared, >>> lets say we throw away all the slots and arch depended stuff, and we let kvm >>> just h

Re: [kvm-devel] High vm-exit latencies during kvm boot-up/shutdown

Dong, Eddie wrote: >> There's a two-liner required to make it work. I'll add it soon. >> >> > But you still needs to issue WBINVD to all pCPUs which just move > non-response time from one place to another, not? > You don't actually need to emulate wbinvd, you can just ignore it. The onl

Re: [kvm-devel] [kvm-ppc-devel] RFC/patch portability: split kvm_vm_ioctl v2

Izik Eidus wrote: > btw, if you look at kvmctl, we already do it, > so it is good question if it better to leave this work to userspace > (like it do now) > or do the mapping to userspace from the kernel to userspace (using the > mmap syscall) > > (i like the secoend option beacuse it would be e

Re: [kvm-devel] [RFT] kvm with Windows optimization

Anthony Liguori wrote: > Avi Kivity wrote: > >> Anthony Liguori wrote: >> > static int mmu_topup_memory_caches(struct kvm_vcpu *vcpu) > { > int r; > > kvm_mmu_free_some_pages(vcpu); > r = mmu_topup_memory_cache(&vcpu->mmu_pte_chain_cache, >

Re: [kvm-devel] [kvm-ppc-devel] RFC/patch portability: split kvm_vm_ioctl v2

Hollis Blanchard wrote: > On Fri, 2007-10-26 at 00:12 +0200, Izik Eidus wrote: > >> ok i was thinking, >> maybe we can rewrite the way kvm hold memory so more code would be shared, >> lets say we throw away all the slots and arch depended stuff, and we let kvm >> just hold the userspace allocate