Dong, Eddie wrote:
> [EMAIL PROTECTED] wrote:
>> Hi,
>>
>> I'm seeing fairly high vm-exit latencies (300-400 us) during and only
>> during qemu/kvm startup and shutdown on a Core2 T5500 in 32-bit mode.
>> It's most probably while the VM runs inside bios code. During the rest
>> of the time, while s
This patch removes arch specific make rules for x86 & x86-64 out of the
main Makefile. These rules are now moved into config-$(ARCH) and a new
file config-x86-common has been created to consolidate common rules
amongst x86 & x86-64.
v1 changes:
*fix x86-64 building by removing redundant rules f
Hi
I tried to build kvm-48 on open suse 10.3 but configure is
giving me error. actually no virtual graphics card is getting selected
as SDL is giving error.
-
Install prefix/usr/local
BIOS directory/usr/local/share/qemu
binary directory /usr/local/bin
Manual dire
I fails to build the latest tip.
A .h file is missing.
error: asm/kvm_para.h: No such file or directory
-Original Message-
From: root [mailto:[EMAIL PROTECTED]
Sent: 2007年10月23日 10:49
Subject:
make -C kernel
make[1]: Entering directory
`/workspace/ia32e/nightly/kvm-master-2.6.22-rc4-20
[EMAIL PROTECTED] wrote:
> Hi,
>
> I'm seeing fairly high vm-exit latencies (300-400 us) during and only
> during qemu/kvm startup and shutdown on a Core2 T5500 in 32-bit mode.
> It's most probably while the VM runs inside bios code. During the rest
> of the time, while some Linux guest is running
The following patch implement a configure passthrough for qemu and
migrate all currently implemented qemu specific configuration flags
(enable-alsa, disable-vnc-tls and disable-gcc-check) to use it.
It uses qemu's configure to get a list of hints for additional options to
use and to keep backward
On Mon, Oct 22, 2007 at 09:51:24PM +0200, Avi Kivity wrote:
> Carlo Marcelo Arenas Belon wrote:
> > On Sun, Oct 21, 2007 at 01:25:34PM +0200, Avi Kivity wrote:
> >>>
> >> Is it possible in case of a failure due to an unrecognized option to
> >> call out usage() instead of qemu's?
> >
> > no
This patch removes arch specific make rules for x86 & x86-64 out of the
main Makefile. These rules are now moved into config-$(ARCH) and a new
file config-x86-common has been created to consolidate common rules
amongst x86 & x86-64.
Signed-off-by: Jerone Young <[EMAIL PROTECTED]>
diff -r 707451c
Hi,
I'm seeing fairly high vm-exit latencies (300-400 us) during and only
during qemu/kvm startup and shutdown on a Core2 T5500 in 32-bit mode.
It's most probably while the VM runs inside bios code. During the rest
of the time, while some Linux guest is running, the exit latencies are
within micro
As vmx_create_vcpu already makes use of start/end_special_insn, we need
to initialise the emulated preempt_notifier earlier. Let's move it to
kvm_vcpu_init. This should fix an oops I've seen here at least once
during kvm startup - so far the problem did not show up again.
Signed-off-by: Jan Kiszka
The recent paravirt refactoring broke external modules. This patch fixes that.
Signed-off-by: Anthony Liguori <[EMAIL PROTECTED]>
diff --git a/kernel/Makefile b/kernel/Makefile
index ebb2903..b78c81a 100644
--- a/kernel/Makefile
+++ b/kernel/Makefile
@@ -26,6 +26,8 @@ sync:
rsync "$(LINU
Carlo Marcelo Arenas Belon wrote:
> On Sun, Oct 21, 2007 at 01:25:34PM +0200, Avi Kivity wrote:
>
>> Why not call qemu's ./configure to get the help text?
>>
>
> can be done, I discarded it originally though as it seems pretty hacky as it
> needs the list to be reformatted and filtered fur
On Sun, 2007-10-21 at 08:40 +0200, Avi Kivity wrote:
>
> The usage of the macro is only for an intermediate stage, so this
> patch shows the changes in the data structures, while the next one
> will be littered with code changes due to the changes in the way
> fields are addressed.
OK.
What is t
The following patch Implement a configure passthrough for qemu and
migrate all current qemu specific configuration flags (enable-alsa,
disable-vnc-tls and disable-gcc-check) to use it.
It uses qemu's configure to get a list of hints for additional options to
use and to keep backward compatible des
On Sun, Oct 21, 2007 at 01:25:34PM +0200, Avi Kivity wrote:
>
> Why not call qemu's ./configure to get the help text?
can be done, I discarded it originally though as it seems pretty hacky as it
needs the list to be reformatted and filtered further as not all options are
relevant and some confli
Avi Kivity wrote:
> Carsten Otte wrote:
>
>> Laurent Vivier wrote:
>>
>>
>>> This patches can be applied only on kvm-updates-2.6.24 and
>>> kvm-updates-2.6.25
>>> as it needs smp_call_function_mask().
>>>
>>>
>> There's one thing I don't understand: How is this locked versus
Linus, please pull the kvm updates in
git://git.kernel.org/pub/scm/linux/kernel/git/avi/kvm.git for-linus
These fix bugs introduces in the latest update (except for two commits: one
adds support for the movnti instruction, used by Linus 2.6.16 for mmio,
and one makes use of smp_call_function_ma
Carsten Otte wrote:
> Laurent Vivier wrote:
>
>> This patches can be applied only on kvm-updates-2.6.24 and kvm-updates-2.6.25
>> as it needs smp_call_function_mask().
>>
> There's one thing I don't understand: How is this locked versus cpu
> hotplug? Isn't there an obvious race involved w
Laurent Vivier wrote:
> This patches can be applied only on kvm-updates-2.6.24 and kvm-updates-2.6.25
> as it needs smp_call_function_mask().
There's one thing I don't understand: How is this locked versus cpu
hotplug? Isn't there an obvious race involved where a cpu unplugged
after cpu_set()?
-
Avi Kivity a écrit :
> Laurent Vivier wrote:
>>
>>> Other than that the patch is very welcome -- the excessive register
>>> saving is very annoying to me.
>>>
>>
>> I think we can do the same thing with svm.c, but I can't test it.
>>
>>
>
> I can test it for you (but a separate patch pl
Laurent Vivier wrote:
>
>> Other than that the patch is very welcome -- the excessive register
>> saving is very annoying to me.
>>
>
> I think we can do the same thing with svm.c, but I can't test it.
>
>
I can test it for you (but a separate patch please -- these are likely
to cause
Avi Kivity a écrit :
> Laurent Vivier wrote:
>> As x86_64 ABI defines some registers saved by the calling function, it
>> is not
>> needed to save all registers in the called function when switching to
>> VCPU.
>> (see http://www.x86-64.org/documentation/abi.pdf, chapter 3.2.1)
>>
>> The best way
Laurent Vivier wrote:
> This patches can be applied only on kvm-updates-2.6.24 and kvm-updates-2.6.25
> as it needs smp_call_function_mask().
>
> In kvm_flush_remote_tlbs(), it replaces a loop using
> smp_call_function_single()
> by a single call to smp_call_function_mask().
>
>
Thanks; I pul
Carsten Otte wrote:
> Anthony Liguori wrote:
>
>> While both PPC and x86 may be able to use it, I doubt there will
>> actually be common code that ever touches it.
>>
> Common code could figure whether or not it needs to save/restore the
> fpu register set, and call back to an arch specif
Laurent Vivier wrote:
> Dor Laor a écrit :
>
>> Laurent Vivier wrote:
>>
>>> This patches can be applied only on kvm-updates-2.6.24 and
>>> kvm-updates-2.6.25
>>> as it needs smp_call_function_mask().
>>>
>>> In kvm_flush_remote_tlbs(), it replaces a loop using
>>> smp_call_function_singl
Laurent Vivier wrote:
> As x86_64 ABI defines some registers saved by the calling function, it is not
> needed to save all registers in the called function when switching to VCPU.
> (see http://www.x86-64.org/documentation/abi.pdf, chapter 3.2.1)
>
> The best way to do that is to inform GCC which r
Anthony Liguori wrote:
> While both PPC and x86 may be able to use it, I doubt there will
> actually be common code that ever touches it.
Common code could figure whether or not it needs to save/restore the
fpu register set, and call back to an arch specific callback to do so.
On the other hand,
Dor Laor a écrit :
> Laurent Vivier wrote:
>> This patches can be applied only on kvm-updates-2.6.24 and
>> kvm-updates-2.6.25
>> as it needs smp_call_function_mask().
>>
>> In kvm_flush_remote_tlbs(), it replaces a loop using
>> smp_call_function_single()
>> by a single call to smp_call_function
Laurent Vivier wrote:
>
> This patches can be applied only on kvm-updates-2.6.24 and
> kvm-updates-2.6.25
> as it needs smp_call_function_mask().
>
> In kvm_flush_remote_tlbs(), it replaces a loop using
> smp_call_function_single()
> by a single call to smp_call_function_mask().
>
Would you be ki
As x86_64 ABI defines some registers saved by the calling function, it is not
needed to save all registers in the called function when switching to VCPU.
(see http://www.x86-64.org/documentation/abi.pdf, chapter 3.2.1)
The best way to do that is to inform GCC which registers we use and let
it to s
Arnd Bergmann wrote:
> On Monday 22 October 2007, Dong, Eddie wrote:
>
>> Should fpu_active be X86 specific? Not sure about PPC & S390 (Hollis &
>> Carsten?), but for IA64
>> it is catagoried into low fp & high fp.
>>
>
> PPC can use that flag, on s390 it won't help.
>
While both PPC an
This patches can be applied only on kvm-updates-2.6.24 and kvm-updates-2.6.25
as it needs smp_call_function_mask().
In kvm_flush_remote_tlbs(), it replaces a loop using smp_call_function_single()
by a single call to smp_call_function_mask().
Signed-off-by: Laurent Vivier <[EMAIL PROTECTED]>
---
> -Ursprüngliche Nachricht-
> Von: Avi Kivity [mailto:[EMAIL PROTECTED]
> Gesendet: Monday, October 22, 2007 1:52 PM
> An: Back, Michael (ext)
> Cc: kvm-devel@lists.sourceforge.net
> Betreff: Re: AW: [kvm-devel] KVM and Prempt?
>
> Back, Michael (ext) wrote:
> >>>
> >>>
> >>
Hello All,
I have a Qemu image running WinXP. I originally set it up to use "User Mode
Networking" with Qemu under Ubuntu 7.04 "Feisty Fawn" on a non-VMT-capable
system.
I am now running a dual-core, VMT capable system using Ubuntu 7.10 "Gutsy
Gibbon".
I installed KVM and my virtual machine imag
Avi Kivity wrote:
> I pulled yesterday so it should be all right (and you don't need me for
> that; you can pull from Linus on top of kvm.git).
The machine runs kvm.git for a while now, seems to work ok.
-
This SF.net email i
Avi Kivity wrote:
> Maybe guard it with CONFIG_KVM_FPU_SWITCHING? Kconfig can set that up
> automatically.
Since there's nothing this flag breaks for us afaics, I think we
should just leave it in common.
-
This SF.net emai
Bart Trojanowski wrote:
> * Avi Kivity <[EMAIL PROTECTED]> [071021 07:23]:
>
>> Does 2.6.23 hang immediately? If so, these may be two separate problems
>> and it's worth bisecting to find out what's the fix in 2.6.24-rc.
>>
>> Of course we'll have to address the later hang as well.
>>
>
>
* Avi Kivity <[EMAIL PROTECTED]> [071021 07:23]:
> Does 2.6.23 hang immediately? If so, these may be two separate problems
> and it's worth bisecting to find out what's the fix in 2.6.24-rc.
>
> Of course we'll have to address the later hang as well.
Avi,
it does not hang immediately. It seem
Avi Kivity wrote:
> I pulled yesterday so it should be all right (and you don't need me for
> that; you can pull from Linus on top of kvm.git).
Thanks :-).
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping throu
Christian Borntraeger wrote:
> [PATCH/RFC] Per-architecture hypercall definitions
>
> Currently kvm provides hypercalls only for x86* architectures. To
> provide hypercall infrastructure for other kvm architectures I split
> kvm_para.h into a generic header file and architecture specific
> definiti
Back, Michael (ext) wrote:
>>>
>>>
>> Make sure CONFIG_PREEMPT_NOTIFIER is selected in your .config. You'll
>> have to adjust Kconfig or select the in-tree kvm for that.
>>
>
> Is there a possibility to check, if CONFIG_PREEMPT_NOTIFIER correct selected
> and compiled in the kernel
Arnd Bergmann wrote:
> On Monday 22 October 2007, Dong, Eddie wrote:
>
>> Should fpu_active be X86 specific? Not sure about PPC & S390 (Hollis &
>> Carsten?), but for IA64
>> it is catagoried into low fp & high fp.
>>
>
> PPC can use that flag, on s390 it won't help.
>
>
Maybe guard it
Carsten Otte wrote:
> Avi Kivity wrote:
>> kvm.git is actually 2.6.24-rc, pulled from -linus at a random point in
>> time, so it's not at all surprising if something is broken.
> Right. We have a backup now, so next time we'll be ok ;-). Would you
> please pull from Linus again to get the fix into
> -Ursprüngliche Nachricht-
> Von: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Im Auftrag
> von Avi Kivity
> Gesendet: Monday, October 22, 2007 9:40 AM
> An: Back, Michael (ext)
> Cc: kvm-devel@lists.sourceforge.net
> Betreff: Re: [kvm-devel] KVM and Prempt?
>
> Back, Michael (ext) wr
Hollis Blanchard wrote:
> This patch can now execute guest userspace (I'm not saying it's complete
> or stable or anything though). I need to put together a more
> full-featured ramdisk to test userspace more completely.
Congratulations Hollis, cool stuff :-).
-
SourceForge.net wrote:
> Bugs item #1817779, was opened at 2007-10-22 13:02
> Summary: KVM crash with Windows XP guest because of ACPI
>
> Initial Comment:
> Host: Fedora7, 64-bit, Intel CPU, KVM-48.
>
> When I start Windows XP guest, that was installed with ACPI enabled, without
> ACPI in KVM,
On Monday 22 October 2007, Dong, Eddie wrote:
> Should fpu_active be X86 specific? Not sure about PPC & S390 (Hollis &
> Carsten?), but for IA64
> it is catagoried into low fp & high fp.
PPC can use that flag, on s390 it won't help.
Arnd <><
--
Dong, Eddie wrote:
> Should fpu_active be X86 specific? Not sure about PPC & S390 (Hollis &
> Carsten?), but for IA64
> it is catagoried into low fp & high fp.
Our FPU is always "active", we restore FPU state on every context
switch. We don't need that flag.
Carsten
-
Bugs item #1817779, was opened at 2007-10-22 13:02
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=1817779&group_id=180599
Please note that this message will contain a full copy
Avi Kivity wrote:
> kvm.git is actually 2.6.24-rc, pulled from -linus at a random point in
> time, so it's not at all surprising if something is broken.
Right. We have a backup now, so next time we'll be ok ;-). Would you
please pull from Linus again to get the fix into kvm.git so that we
can use
Feng Wang wrote:
> When I started up two KVM VMs upon SLES 10 OS based on a multi-core hardware
> platform and ran some computing-intensive tasks (e.g. SPECjbb2005) within
> each VM,
> I found that something confusing me very much.
> The VM which is first started is running as well as it runs with
When I started up two KVM VMs upon SLES 10 OS based on a multi-core hardware
platform and ran some computing-intensive tasks (e.g. SPECjbb2005) within each
VM,
I found that something confusing me very much.
The VM which is first started is running as well as it runs without other VMs,
but
the sys
Yang, Sheng wrote:
> Yeah. We must map guest virtual address of apic page to some determined
> hpa(4k aligned), then we write this hpa to vmcs for cpu handling apic
> access vmexit.
>
>
Ah of course. The processor traps on the physical address, not the
virtual address.
--
error compiling c
Yeah. We must map guest virtual address of apic page to some determined
hpa(4k aligned), then we write this hpa to vmcs for cpu handling apic
access vmexit.
Avi Kivity wrote:
> Yang, Sheng wrote:
>> Thanks for your advice. :)
>>
>> It have nothing to do with smp, though each domain shares one
>>
Laurent Vivier wrote:
>
> Well, in fact it is not needed in 2.6.24, because this patch correct a
> bad behavior introduced by commit
> 57f4e446ebca4aad5c11364baf8477c8cfcb16a4 (which is not in
> kvm-update-2.6.24):
>
> KVM: Call x86_decode_insn() only when needed
>
> Move emulate_ctxt to kvm_vcp
Yang, Sheng wrote:
> Thanks for your advice. :)
>
> It have nothing to do with smp, though each domain shares one
> apic_access_page now. In fact, currently this page won't be accessed,
> just a address mark for cpu.
>
>
You mean, all that's necessary is that the virtual address be mapped
so
Thanks for your advice. :)
It have nothing to do with smp, though each domain shares one
apic_access_page now. In fact, currently this page won't be accessed,
just a address mark for cpu.
Avi Kivity wrote:
> Yang, Sheng wrote:
>> Hi Avi,
>>
>> I've been work on other things for long time, so t
Ingo Molnar wrote:
>>
>> Note the kvm part is already in my 2.6.24 queue.
>>
>
> ok, then please push the whole patch to Linus, the scheduler bits are:
>
> Acked-by: Ingo Molnar <[EMAIL PROTECTED]>
>
Sure, thanks.
--
error compiling committee.c: too many arguments to function
---
Yang, Sheng wrote:
> Hi Avi,
>
> I've been work on other things for long time, so this patch delayed for
> a while. I am planning to post it out recently, but found that, because
> of userspace allocate memory patch, rmap was moved to memslot. So your
> suggestion on deal it with gfn_to_page seems
* Avi Kivity <[EMAIL PROTECTED]> wrote:
> Ingo Molnar wrote:
> >* Laurent Vivier <[EMAIL PROTECTED]> wrote:
> >
> >
> >>According comments from Avi, we can clear PF_VCPU in kvm_guest_exit if
> >>we move it after local_irq_enable().
> >>
> >>http://lkml.org/lkml/2007/10/15/114
> >>
> >>To simpl
Hi Avi,
I've been work on other things for long time, so this patch delayed for
a while. I am planning to post it out recently, but found that, because
of userspace allocate memory patch, rmap was moved to memslot. So your
suggestion on deal it with gfn_to_page seems got a little trouble. And I
d
Ingo Molnar wrote:
> * Laurent Vivier <[EMAIL PROTECTED]> wrote:
>
>
>> According comments from Avi, we can clear PF_VCPU in kvm_guest_exit if
>> we move it after local_irq_enable().
>>
>> http://lkml.org/lkml/2007/10/15/114
>>
>> To simplify s390 port, we don't clear it in account_system_time(
Jan Frey wrote:
> On Tuesday 16 October 2007, Avi Kivity wrote:
>
>> Jan Frey wrote:
>>
Can you set up netconsole or serial console on that machine and grab
the kernel output?
>>> Currently I don't have really much time.. could you point me to some
>>> guide or manua
* Laurent Vivier <[EMAIL PROTECTED]> wrote:
> According comments from Avi, we can clear PF_VCPU in kvm_guest_exit if
> we move it after local_irq_enable().
>
> http://lkml.org/lkml/2007/10/15/114
>
> To simplify s390 port, we don't clear it in account_system_time().
>
> http://lkml.org/lkml/2
Back, Michael (ext) wrote:
>> -Ursprüngliche Nachricht-
>> Von: Gregory Haskins [mailto:[EMAIL PROTECTED]
>> Gesendet: Friday, October 19, 2007 5:27 PM
>> An: Back, Michael (ext)
>> Cc: kvm-devel@lists.sourceforge.net
>> Betreff: Re: AW: [kvm-devel] KVM and Prempt?
>>
>> On Fri, 2007-10-19
65 matches
Mail list logo
