Gerd Hoffmann wrote:
> Avi Kivity wrote:
>
>> We've now switched to allocating guest memory in userspace rather than
>> in the kernel.
>>
>
> Hmm, a quick glimpse over kvmctl.h doesn't show an obvious way how to
> use that. If I want to back vm memory with a file mapping, how can I do
> th
Dong, Eddie wrote:
>> I'll try writing a patch that does what I mean and post it.
>> Either I'll
>> convince you that in-kernel is simpler, or I'll convince myself that
>> it is harder.
>>
>>
> OK, let us see which one is simple.
>
> BTW, you have swapped to N+1 SMP model in this discussion w
Farkas Levente wrote:
> Avi Kivity wrote:
>
>> Farkas Levente wrote:
>>
> we did a quick test against this version and it's turn out the smp
> guests are still not working. even if we start only one linux guest
> with
> 4cpu on 4cpu host the guest kernel hangs at random stag
Anthony Liguori wrote:
> Avi Kivity wrote:
>
>> Anthony Liguori wrote:
>>
>>
>>> Now that we have userspace memory allocation, I wanted to play with
>>> ballooning.
>>> The idea is that when a guest "balloons" down, we simply unpin the
>>> underlying
>>> physical memory and the host ke
Anthony Liguori wrote:
>> While the pic/apic related functions are obviously x86 specific, some
>> other ioctls seem to be common at a first glance.
>> KVM_SET_(USER)_MEMORY_REGION for example. We've got a total different
>> address layout on s390: we cannot support multiple slots, and a user
>> me
Zhang, Xiantao wrote:
> >From 12457e0fb85ef32f1a1f808be294bebe8d22667c Mon Sep 17 00:00:00 2001
> From: Zhang xiantao <[EMAIL PROTECTED]>
> Date: Fri, 12 Oct 2007 13:29:30 +0800
> Subject: [PATCH] Split kvm_vcpu to support new archs. Define a new sub
> field
> kvm_arch_vcpu to hold arch-specific se
Zhang, Xiantao wrote:
> I don't know why we not put KVM_SET_MEMORY_REGION,
> KVM_SET_USER_MEMORY_REGION as common, although
> I have read the reasons you listed. I think they should work for most of
> archs, although it is not very friendly with s390. If we put them
> as arch-specific ones, we h
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.
>
> Common ioctls for all architectures are:
> KVM_CREATE_VCPU, KVM_GET_DIRTY_LOG
>
> I'd really like to see more commonalities, but all other
Zhang, Xiantao wrote:
>>> struct kvm_vcpu {
>>> struct kvm *kvm;
>>> struct preempt_notifier preempt_notifier;
>>> int vcpu_id;
>>> struct mutex mutex;
>>> int cpu;
>>> - u64 host_tsc;
>>> struct kvm_run *run;
>>> int interrupt_window_open;
>> This one should go to
Avi Kivity wrote:
> We need to distinguish between x86 specific (only x86 has this) and s390
> special (everyone has it except s390). In the latter case it should
> still be in common code to avoid duplication, with a guard to disable
> compilation on s390.
>
> KVM_SET_MEMORY_REGION is in theory a
Carsten Otte wrote:
>
>> int mmio_needed;
>> int mmio_read_completed;
> Not all architectures have mmio, please put this into arch specific part.
>
Using previous terminology, mmio is s390 special. Everyone else does
have them. We can #ifndef them on s390, but we won't duplicate mmio o
Carsten Otte wrote:
> Avi Kivity wrote:
>> I agree 100%, I'm just using the "keep the patch dead simple" excuse to
>> delay the change. We can have a 'add kvm_ prefix' patch round later.
>> Let's complete the separation first.
> Okay, fine with me.
>
>> There are some bigger offenders too, like se
Avi Kivity wrote:
> Using previous terminology, mmio is s390 special. Everyone else does
> have them. We can #ifndef them on s390, but we won't duplicate mmio on
> all other archs.
No need to duplicate the code for all other archs: we should think
about a functional split here, like having an mm
Linus, please pull from the repo and branch at
git://git.kernel.org/pub/scm/linux/kernel/git/avi/kvm.git for-linus
to receive the 2.6.24 episode of KVM. Highlights include in-kernel
pic/lapic/ioapic emulation, improved guest support, preemptibility,
an improved x86 emulator, and a fair amount
Hi,
thanks for your reply:
Am Dienstag 09 Oktober 2007 01:55:16 schrieb Dong, Eddie:
> If you can get latest KVM up + clock=pit, I bet you will get a much much
> accurate guest time. If you still see > 0.1% shift, please file a bug.
> thx,eddie
I have just installed KVM 46 into my Ubuntu 7.04 k
Cam Macdonell wrote:
> Dor Laor wrote:
>> Cam Macdonell wrote:
>>>
>> It's a simple test, when there are keyboard/mouse/display changes
>> keep the refresh rate high. When there are no changes start decrease
>> the rate until a minimum
>> reached. The performance benefit should also be checked si
Izik Eidus wrote:
> this patchs allow the guest not shadowed memory to be swapped out.
>
> to make it the must effective you should run -kvm-shadow-memory 1 (witch
> will make your machine slow)
> with -kvm-shadow-memory 1, 3giga memory guest can get to be just 32mb
> on physical host!
>
> when
Izik Eidus wrote:
> this patch make the guest non shadowed pages swappedable
>
>
>
> -
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping t
Anthony Liguori wrote:
> Izik Eidus wrote:
>> this patchs allow the guest not shadowed memory to be swapped out.
>>
>> to make it the must effective you should run -kvm-shadow-memory 1
>> (witch will make your machine slow)
>> with -kvm-shadow-memory 1, 3giga memory guest can get to be just
>> 3
Anthony Liguori wrote:
> Izik Eidus wrote:
>> this patch make the guest non shadowed pages swappedable
>>
>>
>>
>> -
>>
>> This SF.net email is sponsored
Izik Eidus wrote:
> Anthony Liguori wrote:
>> Izik Eidus wrote:
>>> this patchs allow the guest not shadowed memory to be swapped out.
>>>
>>> to make it the must effective you should run -kvm-shadow-memory 1
>>> (witch will make your machine slow)
>>> with -kvm-shadow-memory 1, 3giga memory gues
Izik Eidus wrote:
> Anthony Liguori wrote:
>> Izik Eidus wrote:
>>>
>>> @@ -1058,8 +1038,27 @@ struct page *gfn_to_page(struct kvm *kvm,
>>> gfn_t gfn)
>>>
>>> gfn = unalias_gfn(kvm, gfn);
>>> slot = __gfn_to_memslot(kvm, gfn);
>>> -if (!slot)
>>> +if (!slot) {
>>> +get
On Sat, Oct 13, 2007 at 01:36:56AM +0200, Oliver Kowalke wrote:
> Hopefuly you could help.
> kind regards, Oliver
Oliver
several of us are using the newer kvm module with OpenBSD successfully, the
version of kvm included in the debian kernel is the problematic one.
To fix that, remove kvm from y
On Sat, 13 Oct 2007 12:39:15 +0200
Izik Eidus <[EMAIL PROTECTED]> wrote:
> Cam Macdonell wrote:
> > Dor Laor wrote:
> >> Cam Macdonell wrote:
> >>>
> >> It's a simple test, when there are keyboard/mouse/display changes
> >> keep the refresh rate high. When there are no changes start
> >> decrease
Izik Eidus wrote:
> Izik Eidus wrote:
>> Anthony Liguori wrote:
>>> Izik Eidus wrote:
@@ -1058,8 +1038,27 @@ struct page *gfn_to_page(struct kvm *kvm,
gfn_t gfn)
gfn = unalias_gfn(kvm, gfn);
slot = __gfn_to_memslot(kvm, gfn);
-if (!slot)
+
Izik Eidus wrote:
> Izik Eidus wrote:
>> Anthony Liguori wrote:
>>> Izik Eidus wrote:
this patchs allow the guest not shadowed memory to be swapped out.
to make it the must effective you should run -kvm-shadow-memory 1
(witch will make your machine slow)
with -kvm-shadow-m
ok, i change some things as Anthony noted me, but the most important
thing is that i changed here:
is setting the dirty bit after using the page (i forgat to do it before)
>From 9088fb6a35517bdafe7a7066f60fab56f98c9127 Mon Sep 17 00:00:00 2001
From: Izik Eidus <[EMAIL PROTECTED]>
Date: Sun, 14 Oc
Anthony Liguori wrote:
> Izik Eidus wrote:
>> Izik Eidus wrote:
>>> Anthony Liguori wrote:
Izik Eidus wrote:
>
> @@ -1058,8 +1038,27 @@ struct page *gfn_to_page(struct kvm *kvm,
> gfn_t gfn)
>
> gfn = unalias_gfn(kvm, gfn);
> slot = __gfn_to_memslot(kvm, gf
Izik Eidus wrote:
> Anthony Liguori wrote:
>> Izik Eidus wrote:
>>> Izik Eidus wrote:
Anthony Liguori wrote:
> Izik Eidus wrote:
>>
>> @@ -1058,8 +1038,27 @@ struct page *gfn_to_page(struct kvm *kvm,
>> gfn_t gfn)
>>
>> gfn = unalias_gfn(kvm, gfn);
>> s
Anthony Liguori wrote:
> Izik Eidus wrote:
>> Anthony Liguori wrote:
>>> Izik Eidus wrote:
Izik Eidus wrote:
> Anthony Liguori wrote:
>> Izik Eidus wrote:
>>>
>>> @@ -1058,8 +1038,27 @@ struct page *gfn_to_page(struct kvm *kvm,
>>> gfn_t gfn)
>>>
>>> gfn = u
Very nice!
I've tested this series (with your new 3/4) with win2k, winxp, ubuntu
7.10, and opensuse. Everything seemed to work just fine.
I also was able to create four 1G VMs on my 2G laptop :-) That was very
neat.
Regards,
Anthony Liguori
Izik Eidus wrote:
> this patchs allow the guest n
Anthony Liguori wrote:
> Very nice!
>
> I've tested this series (with your new 3/4) with win2k, winxp, ubuntu
> 7.10, and opensuse. Everything seemed to work just fine.
Spoke too soon, found the following in dmesg:
[35078.913071] BUG: scheduling while atomic:
qemu-system-x86/0x1001/21612
[
>Hi,
>
>is there any option to reenable virtualisation support (AMD-CPU) if it
>is disabled by bios (and Bios does not show an option to enable
>virtualisation support)?
>Elmar
Hi, i'm having the same problem, my bios doesn't have an option to
enable virtualization support, and I already upgrade
Izik Eidus wrote:
Anthony Liguori wrote:
I think it's just a matter of calling do_mmap() with the appropriate
parameters. It looks likes there's some drivers call do_mmap()
directly.
yea, i think you right, this is excellent idea!, when we will merge
the swapping to kvm, we will add swapp
Anthony Liguori wrote:
> Izik Eidus wrote:
>
>> Anthony Liguori wrote:
>>
>>> Izik Eidus wrote:
>>>
Izik Eidus wrote:
> Anthony Liguori wrote:
>
>> Izik Eidus wrote:
>>
>>> @@ -1058,8 +1038,27 @@ struct page *gfn_to_page(
Carsten Otte wrote:
> Avi Kivity wrote:
>
>> Using previous terminology, mmio is s390 special. Everyone else does
>> have them. We can #ifndef them on s390, but we won't duplicate mmio on
>> all other archs.
>>
> No need to duplicate the code for all other archs: we should think
> about
Anthony Liguori wrote:
> Anthony Liguori wrote:
>> Very nice!
>>
>> I've tested this series (with your new 3/4) with win2k, winxp, ubuntu
>> 7.10, and opensuse. Everything seemed to work just fine.
>
> Spoke too soon, found the following in dmesg:
>
> [35078.913071] BUG: scheduling while atomic:
Anthony Liguori wrote:
> Izik Eidus wrote:
>> Anthony Liguori wrote:
>>>
>>> I think it's just a matter of calling do_mmap() with the appropriate
>>> parameters. It looks likes there's some drivers call do_mmap()
>>> directly.
>>>
>> yea, i think you right, this is excellent idea!, when we will
Am Samstag, 13. Oktober 2007 22:56:08 schrieben Sie:
> On Sat, Oct 13, 2007 at 01:36:56AM +0200, Oliver Kowalke wrote:
> > Hopefuly you could help.
> > kind regards, Oliver
>
> Oliver
>
> several of us are using the newer kvm module with OpenBSD successfully, the
> version of kvm included in the de
39 matches
Mail list logo
