Hi,
While booting a non-Linux OS under kvm-46, I noticed that reading
APIC_TMCCT before initializing APIC_TDCR to something other than its
boot time value would lead to a host kernel divide by zero exception.
It's due to apic->timer.divide_count being set to 0 at boot... it should
be set to 2 sinc
Carsten Otte wrote:
> Zhang, Xiantao wrote:
>> diff --git a/drivers/kvm/ioapic.c b/drivers/kvm/ioapic.c
>> index 3b69541..df67292 100644
>> --- a/drivers/kvm/ioapic.c
>> +++ b/drivers/kvm/ioapic.c
>> @@ -156,7 +156,7 @@ static u32 ioapic_get_delivery_bitmask(struct
>> kvm_ioapic *ioapic, u8 de
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 othe
Yes, it also happened before kvm-46.
Guest with 1.5GB mem hasn't the problem.
>-Original Message-
>From: Izik Eidus [mailto:[EMAIL PROTECTED]
>Sent: 2007年10月13日 10:24
>To: Zhao, Yunfeng
>Cc: kvm-devel
>Subject: Re: [kvm-devel] Test for KVM, kernel 33aaf..., userspace, 803145...
>
>Zhao, Yu
Zhao, Yunfeng wrote:
>
> Three Linux guest issues:
> 6. segfault while booting 64bit linux with 4GB mem
> https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1812050&gro
> up_id=180599
>
did it happen to you before kvm-46?
> -
this patch just remove the memset from kvmctl, so the vm will load much
faster now
>From dc0164113041c2f2bf22fc066ca99b9b8531d627 Mon Sep 17 00:00:00 2001
From: Izik Eidus <[EMAIL PROTECTED](none)>
Date: Sat, 13 Oct 2007 02:56:25 +0200
Subject: [PATCH] now that gfn_to_page get called at run time,
this patch make the guest non shadowed pages swappedable
>From 8e25e215b8ed95ca4ff51cbfcf5bdc438bb799f4 Mon Sep 17 00:00:00 2001
From: Izik Eidus <[EMAIL PROTECTED](none)>
Date: Sat, 13 Oct 2007 04:03:28 +0200
Subject: [PATCH] make the guest non shadowed memory swappable
Signed-off-by: Izik Eidu
this patch make gfn_to_page always safe function (return bad_page in
case there is no such page in the guest)
>From 51a8851a2805f5b61d3fbe506ab317ecb677c3da Mon Sep 17 00:00:00 2001
From: Izik Eidus <[EMAIL PROTECTED](none)>
Date: Sat, 13 Oct 2007 02:01:54 +0200
Subject: [PATCH] change gfn_to_page
this make the rmap keep reverse mapping on all the present shadow pages
>From 3b5821a55836f82f987b878982cbc6fc8336371f Mon Sep 17 00:00:00 2001
From: Izik Eidus <[EMAIL PROTECTED](none)>
Date: Sat, 13 Oct 2007 01:47:44 +0200
Subject: [PATCH] modify the rmap so it will hold reverse mapping to all p
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 not using -kvm-shadow-memory, i
On Fri, 2007-10-12 at 13:08 -0300, Glauber de Oliveira Costa wrote:
> +
> +/* The hypervisor will put information about time periodically here */
> +struct kvm_hv_clock hv_clock;
...
> +void __init kvmclock_init(void)
> +{
> +
> + unsigned long shared_page = (unsigned long)&hv_clock;
What
Hollis Blanchard wrote:
> On Fri, 2007-10-12 at 15:02 -0500, Anthony Liguori wrote:
>
>> Hollis Blanchard wrote:
>>
>>> On Fri, 2007-10-12 at 13:08 -0300, Glauber de Oliveira Costa wrote:
>>>
>>>
+config KVM_CLOCK
+ bool "KVM paravirtualized clock"
+ dep
On Fri, 2007-10-12 at 15:02 -0500, Anthony Liguori wrote:
> Hollis Blanchard wrote:
> > On Fri, 2007-10-12 at 13:08 -0300, Glauber de Oliveira Costa wrote:
> >
> >> +config KVM_CLOCK
> >> + bool "KVM paravirtualized clock"
> >> + depends on PARAVIRT && GENERIC_CLOCKEVENTS
> >> +
Hi,
I've applied the patch now the kernel detects:
cpu0: Intel Pentium Pro, II or III...
cpu0: FPU,V86,...
But I get in the next line:
kernel: page fault trap, code=0
Stopped at trap+0x16f: testb $0x3,0x38(%ecx)
I don't know what that means.
Hopefuly you could help.
kind regards, Oliver
Am Donners
Not much detail here but I'll post all I can.
KVM-46 (from tarball, using kvm-46 modules), ubuntu gutsy
2.6.22-14-generic amd64, Turion X2 with SVM, 1GB total memory on
laptop.
Was in the middle of an windows xp pro sp2 install using this command
line:
sudo ~/kvm46/bin/qemu-system-x86_64 -m
Hollis Blanchard wrote:
> On Fri, 2007-10-12 at 13:08 -0300, Glauber de Oliveira Costa wrote:
>
>> +config KVM_CLOCK
>> + bool "KVM paravirtualized clock"
>> + depends on PARAVIRT && GENERIC_CLOCKEVENTS
>> + help
>> + Turning on this option will allow you to run a parav
On Fri, 2007-10-12 at 13:08 -0300, Glauber de Oliveira Costa wrote:
> +config KVM_CLOCK
> + bool "KVM paravirtualized clock"
> + depends on PARAVIRT && GENERIC_CLOCKEVENTS
> + help
> + Turning on this option will allow you to run a paravirtualized clock
> + when ru
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 since if it
> minimal there's
Jeremy Fitzhardinge wrote:
> Glauber de Oliveira Costa wrote:
>
>> My next TODOs with it are:
>> * Get SMP working
>> * Try something for stolen time, as jeremy's last suggestion for anthony's
>> patch
>> * Measure the time it takes for a hypercall, and subtract this time
>> for calculating the
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 kernel may or may not swap it. To reclaim
>> ballo
Glauber de Oliveira Costa wrote:
> My next TODOs with it are:
> * Get SMP working
> * Try something for stolen time, as jeremy's last suggestion for anthony's
> patch
> * Measure the time it takes for a hypercall, and subtract this time
> for calculating the expiry time for the timer event.
>
Glauber de Oliveira Costa wrote:
> Hi,
>
> Attached is a first draft to a paravirt implementation for a timer to
> KVM. It is inspired in anthony's last patch about it, but not that
> much based on it.
>
> I'm not using hypercalls to get the current time, but rather,
> registering an address that w
Hi,
Attached is a first draft to a paravirt implementation for a timer to
KVM. It is inspired in anthony's last patch about it, but not that
much based on it.
I'm not using hypercalls to get the current time, but rather,
registering an address that will get timer updates once in a while.
Also, i
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:
> diff --git a/drivers/kvm/ioapic.c b/drivers/kvm/ioapic.c
> index 3b69541..df67292 100644
> --- a/drivers/kvm/ioapic.c
> +++ b/drivers/kvm/ioapic.c
> @@ -156,7 +156,7 @@ static u32 ioapic_get_delivery_bitmask(struct
> kvm_ioapic *ioapic, u8 dest,
> if (dest_mode == 0) {
Am Freitag, den 12.10.2007, 15:37 +0200 schrieb Arnd Bergmann:
> I assume the contents are ok, since you're just moving code around, but
> please
> write this 'Signed-off-by' and 'Reviewed-by' (capital letters), and
> include a diffstat for any patch that doesn't fit on a few pages
> of mail client
On Friday 12 October 2007, 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.
>
I assume the contents are ok, since you're just moving code around, but
please
> signed-off-by: Carsten Otte <
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 others did not fit
our needs. I would
Carsten Otte wrote:
> Zhang, Xiantao wrote:
So, every
architecture can defines its own kvm_arch.h for their arch, and
compile will choose it per ARCH when compile time. But for now, we
can just put it here before another real new arch in. Then, we can
remove x86.h, since i
Zhang, Xiantao wrote:
>>> So, every
>>> architecture can defines its own kvm_arch.h for their arch, and
>>> compile will choose it per ARCH when compile time. But for now, we
>>> can just put it here before another real new arch in. Then, we can
>>> remove x86.h, since it is not so common for all
Carsten Otte wrote:
> Zhang, Xiantao wrote:
>> According to our previous discuss, we proposed a source layout,
>> which contains an "include" directory to hold header files for all
>> archs under drivers/kvm/, and kvm_arch.h will finally go into
>> drivers/kvm/include/kvm-x86/(linked as kvm when c
Cam Macdonell wrote:
>
>
> Dor Laor wrote:
>> Cam Macdonell wrote:
>>
>> You may choose the interactivity improvements:in
>> http://kvm.qumranet.com/kvmwiki/TODO
>> Dor
>
> Thanks Dor, I'll look into it. Beyond the description, can you
> elaborate on the problem with frame rate during interactiv
Carsten Otte wrote:
> Zhang, Xiantao wrote:
>> Thank you, I will resend it :)
> I do greatly appreciate it. We'll do this together, please do also
> pick on my patches whenever you see something that does'nt fit what
> you need for ia64.
Sure:)
Xiantao
> thanks,
> Carsten
Zhang, Xiantao wrote:
> Thank you, I will resend it :)
I do greatly appreciate it. We'll do this together, please do also
pick on my patches whenever you see something that does'nt fit what
you need for ia64.
thanks,
Carsten
--
>> int vcpu_id;
>> struct mutex mutex;
>> int cpu;
>> -u64 host_tsc;
>> struct kvm_run *run;
>> int interrupt_window_open;
> I am not sure if this is the right thing for all archs. We have
> various forms of interrupts (I/O, external etc) which can all be
> masked se
Zhang, Xiantao wrote:
> According to our previous discuss, we proposed a source layout, which
> contains an "include" directory to hold header files for all archs
> under drivers/kvm/, and kvm_arch.h will finally go into
> drivers/kvm/include/kvm-x86/(linked as kvm when compile).
Right. The thing
Add new-line at end of debug strings.
Signed-off-by: Laurent Vivier <[EMAIL PROTECTED]>
---
drivers/kvm/ioapic.c | 25 ++---
1 files changed, 14 insertions(+), 11 deletions(-)
diff --git a/drivers/kvm/ioapic.c b/drivers/kvm/ioapic.c
index 3b69541..1a5e59a 100644
--- a/drive
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 sec
Christian Ehrhardt wrote:
> Zhang, Xiantao wrote:
>> --- /dev/null
>> +++ b/drivers/kvm/kvm_arch.h
> [...]
>> +struct kvm_arch_vcpu{
>> +
>> +u64 host_tsc;
>> +
>> +unsigned long regs[NR_VCPU_REGS]; /* for rsp:
>> vcpu_load_rsp_rip() */
>> +unsigned long rip; /* needs vcpu_load_rsp
Hi,
Here is the summary for current KVM quality, kernel
33aafecf3f106ba6aa8847dfdae033a73e5d1b50, userspace,
80314525755d89861c6709c5ba6104fbe34a64ea.
4 old issues have been fixed in this week. And 3 new issues have been
found.
Totally 8 major issues still exist.
Five fixed old issues:
1. 64bit li
Zhang, Xiantao wrote:
> --- /dev/null
> +++ b/drivers/kvm/kvm_arch.h
[...]
> +struct kvm_arch_vcpu{
> +
> + u64 host_tsc;
> +
> + unsigned long regs[NR_VCPU_REGS]; /* for rsp:
> vcpu_load_rsp_rip() */
> + unsigned long rip; /* needs vcpu_load_rsp_rip() */
> +
> + unsi
Zhang, Xiantao wrote:
> I orgirnally mean we have to wrap all functions related to kvm_x86_ops.
> But seems it doesn't introduce
> extra maintain effort, if other architectures implment these functions
> directly. Good method!
That was my idea at first too, until Hollis has beaten me up on this.
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 set_crX(), which don't even
>
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
that?
cheers,
Gerd
---
Bugs item #1812072, was opened at 2007-10-12 15:36
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1812072&group_id=180599
Please note that this message will contain a full copy
> 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 which
is not there yet. And this is
Bugs item #1812050, was opened at 2007-10-12 15:00
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1812050&group_id=180599
Please note that this message will contain a full copy
47 matches
Mail list logo
