This patch does:
- call vcpu->arch.mmu.update_pte directly
- use gfn_to_pfn_atomic in update_pte path
The suggestion is from Avi.
Signed-off-by: Xiao Guangrong
---
arch/x86/include/asm/kvm_host.h |7 +---
arch/x86/kvm/mmu.c | 69 +--
arch/x
Cleanup the code of pte_prefetch_gfn_to_memslot and mapping_level_dirty_bitmap
Signed-off-by: Xiao Guangrong
---
arch/x86/kvm/mmu.c | 37 +
1 files changed, 17 insertions(+), 20 deletions(-)
diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index 88d3689
We can get memslot id from memslot->id directly
Signed-off-by: Xiao Guangrong
---
include/linux/kvm_host.h |6 +-
virt/kvm/kvm_main.c | 17 -
2 files changed, 5 insertions(+), 18 deletions(-)
diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
index a
fix:
[ 3494.671786] stack backtrace:
[ 3494.671789] Pid: 10527, comm: qemu-system-x86 Not tainted 2.6.38-rc6+ #23
[ 3494.671790] Call Trace:
[ 3494.671796] [] ? lockdep_rcu_dereference+0x9d/0xa5
[ 3494.671826] [] ? kvm_memslots+0x6b/0x73 [kvm]
[ 3494.671834] [] ? gfn_to_memslot+0x16/0x4f [kvm]
[
09.03.2011 10:26, Stefan Weil wrote:
> Am 08.03.2011 23:53, schrieb Peter Lieven:
>> Hi,
>>
>> during testing of qemu-kvm-0.14.0 i can reproduce the following
>> segfault. i have seen similar crash already in 0.13.0, but had no time
>> to debug.
>> my guess is that this segfault is related to the t
On 2011-03-08 23:53, Peter Lieven wrote:
> Hi,
>
> during testing of qemu-kvm-0.14.0 i can reproduce the following segfault. i
> have seen similar crash already in 0.13.0, but had no time to debug.
> my guess is that this segfault is related to the threaded vnc server which
> was introduced in q
Am 08.03.2011 23:53, schrieb Peter Lieven:
Hi,
during testing of qemu-kvm-0.14.0 i can reproduce the following
segfault. i have seen similar crash already in 0.13.0, but had no time
to debug.
my guess is that this segfault is related to the threaded vnc server
which was introduced in qemu 0.1
On Mon, Mar 07, 2011 at 04:31:41PM -0600, Tom Lendacky wrote:
> I used the uperf tool to do this after verifying the results against netperf.
>
> Uperf allows the specification of the number of connections as a parameter in
> an XML file as opposed to launching, in this case, 100 separate insta
On Mon, Mar 07, 2011 at 04:31:41PM -0600, Tom Lendacky wrote:
> We've been doing some more experimenting with the small packet network
> performance problem in KVM. I have a different setup than what Steve D. was
> using so I re-baselined things on the kvm.git kernel on both the host and
> gues
On Tue, Mar 8, 2011 at 11:53 PM, Peter Lieven wrote:
> Hi,
>
> during testing of qemu-kvm-0.14.0 i can reproduce the following segfault. i
> have seen similar crash already in 0.13.0, but had no time to debug.
> my guess is that this segfault is related to the threaded vnc server which
> was int
Hi,
On Sun, Mar 6, 2011 at 4:08 PM, Avi Kivity wrote:
> On 03/06/2011 05:02 PM, Avi Kivity wrote:
>>
>> (for #TS we need additional logic... will this arch never end?)
>>
>
> Actually these instructions don't generate #TS.
>
I just wanted to know if this issue is going to be fixed before 2.6.38
ya su wrote:
Yoshi:
I think event-tap is a great idea, it remove the reading from disk
which will increase ft effiency much better as your plan in later
series.
one question: IO read/write may dirty rams, but it is difficute to
differ them from other dirty pages like caused by runnin
"Michael S. Tsirkin" wrote on 03/08/2011 09:11:04 PM:
> Also, could you post your current version of the qemu code pls?
> It's useful for testing and to see the whole picture.
Sorry for the delay on this.
I am attaching the qemu changes. Some parts of the patch are
completely redundant, eg MAX_
Yoshi:
I think event-tap is a great idea, it remove the reading from disk
which will increase ft effiency much better as your plan in later
series.
one question: IO read/write may dirty rams, but it is difficute to
differ them from other dirty pages like caused by running of
softwares,
2011/3/8 Yoshiaki Tamura :
> ya su wrote:
>>
>> Yokshiaki:
>>
>> event-tap record block and io wirte events, and replay these on
>> the other side, so block_save_live is useless during the latter ft
>> phase, right? if so, I think it need to process the following code in
>> block_save_live func
Hi Tom,
My two cents. Please look for [Chaks]
>
>Comparing the transmit path to the receive path, the guest disables
>notifications after the first kick and vhost re-enables notifications
>after
>completing processing of the tx ring. Can a similar thing be done for
>the
>receive path? Once vhos
On Tue, 2011-03-08 at 13:57 -0800, Shirley Ma wrote:
> On Wed, 2011-02-09 at 11:07 +1030, Rusty Russell wrote:
> > I've finally read this thread... I think we need to get more serious
> > with our stats gathering to diagnose these kind of performance issues.
> >
> > This is a start; it should tell
Hi Avi,
This patch set got lost in the shuffle, and I'm not looking to include
it.
On Wed, 2010-12-08 at 11:18 +0200, Avi Kivity wrote:
> On 12/07/2010 11:16 PM, David Sharp wrote:
> > >
> > > I don't understand this. Can you elaborate? What does "32-bit
> > > addressable"
> > > mean?
> >
>
Hi,
during testing of qemu-kvm-0.14.0 i can reproduce the following segfault. i
have seen similar crash already in 0.13.0, but had no time to debug.
my guess is that this segfault is related to the threaded vnc server which was
introduced in qemu 0.13.0. the bug is only triggerable if a vnc
clie
On Wed, 2011-02-09 at 11:07 +1030, Rusty Russell wrote:
> I've finally read this thread... I think we need to get more serious
> with our stats gathering to diagnose these kind of performance issues.
>
> This is a start; it should tell us what is actually happening to the
> virtio ring(s) without
On 03/07/2011 05:18 AM, Nikola Ciprich wrote:
e48672fa25e879f7ae21785c7efd187738139593 removed
kvm_request_guest_time_update(vcpu);
this breaks 32bit SMP guests using virtio-clock.
thus add unconditional call to kvm_make_request(KVM_REQ_CLOCK_UPDATE, vcpu) to
fix the
problem.
Signed-off-by: Ni
On 03/08/2011 07:43 PM, Jan Kiszka wrote:
>
> Something else - 27f368604a3d27ca4d.
I already thought so. But that is understood, fixed, and will be
obsoleted by the merge.
Ok, will look at your new stuff.
More interesting are open issues. Any news from that front?
None known.
--
error c
On 2011-03-08 18:40, Avi Kivity wrote:
> On 03/08/2011 07:21 PM, Jan Kiszka wrote:
>> On 2011-03-08 18:15, Paolo Bonzini wrote:
>>> On 03/08/2011 06:10 PM, Jan Kiszka wrote:
> The qemu.git bit seen with my win32 patch series should also be a
> regression from qemu-kvm.git to qemu.git,
On 2011-03-08 18:41, Avi Kivity wrote:
> On 03/08/2011 07:40 PM, Avi Kivity wrote:
>> On 03/08/2011 07:21 PM, Jan Kiszka wrote:
>>> On 2011-03-08 18:15, Paolo Bonzini wrote:
On 03/08/2011 06:10 PM, Jan Kiszka wrote:
>> The qemu.git bit seen with my win32 patch series should also be a
>>
On 03/08/2011 07:40 PM, Avi Kivity wrote:
On 03/08/2011 07:21 PM, Jan Kiszka wrote:
On 2011-03-08 18:15, Paolo Bonzini wrote:
> On 03/08/2011 06:10 PM, Jan Kiszka wrote:
>>> The qemu.git bit seen with my win32 patch series should also be a
>>> regression from qemu-kvm.git to qemu.git, no?
>
On 03/08/2011 07:21 PM, Jan Kiszka wrote:
On 2011-03-08 18:15, Paolo Bonzini wrote:
> On 03/08/2011 06:10 PM, Jan Kiszka wrote:
>>> The qemu.git bit seen with my win32 patch series should also be a
>>> regression from qemu-kvm.git to qemu.git, no?
>>
>> Can't follow. What do you mean?
>
>
On 2011-03-08 18:15, Paolo Bonzini wrote:
> On 03/08/2011 06:10 PM, Jan Kiszka wrote:
>>> The qemu.git bit seen with my win32 patch series should also be a
>>> regression from qemu-kvm.git to qemu.git, no?
>>
>> Can't follow. What do you mean?
>
> I didn't understand very well Avi and Marcelo's
On 03/08/2011 06:10 PM, Jan Kiszka wrote:
> The qemu.git bit seen with my win32 patch series should also be a
> regression from qemu-kvm.git to qemu.git, no?
Can't follow. What do you mean?
I didn't understand very well Avi and Marcelo's exchange, but this test
definitely 1) fails with qemu
On 2011-03-08 17:58, Paolo Bonzini wrote:
> On 03/08/2011 05:51 PM, Jan Kiszka wrote:
iothread merge?
- progressing slowly, marcelo working on it
- have found regressions (signal handling code) (ifdef'd away for now)
>> The regressions will automagically go away (to be replaced wi
On 03/08/2011 05:51 PM, Jan Kiszka wrote:
> iothread merge?
> - progressing slowly, marcelo working on it
> - have found regressions (signal handling code) (ifdef'd away for now)
The regressions will automagically go away (to be replaced with others
then...) when the switch of qemu-kvm to ups
On 2011-03-08 16:50, Chris Wright wrote:
> iothread merge?
> - progressing slowly, marcelo working on it
> - have found regressions (signal handling code) (ifdef'd away for now)
The regressions will automagically go away (to be replaced with others
then...) when the switch of qemu-kvm to upstream
Hi all,
I've found a usb ehci patch here in the mailing list (begin of january) but
it does not fit for 0.14.0.
Is there an updated patch for the latest qemu-kvm version?
Thanks a lot.
Best regards,
Erik
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a mess
On Tue, Mar 8, 2011 at 4:00 PM, Anthony Liguori wrote:
> http://wiki.qemu.org/Features/QAPI/VirtAgent
That page does not exist. I think you meant this one:
http://wiki.qemu.org/Features/QAPI/GuestAgent
Stefan
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a mes
On 03/08/2011 09:50 AM, Chris Wright wrote:
QAPI merge plans
- should be 100% back compat
- qmp moved over
- hmp moved over
- 1st pass, core infrastructure (includes test framework)
- 2nd pass, command conversion
- 3rd pass, more controversial bits
- adds dependencies: glib and python
- some test
QAPI merge plans
- should be 100% back compat
- qmp moved over
- hmp moved over
- 1st pass, core infrastructure (includes test framework)
- 2nd pass, command conversion
- 3rd pass, more controversial bits
- adds dependencies: glib and python
- some testing based on kvm-unit-test micro-os instance (
On Tue, Mar 08, 2011 at 09:02:38PM +0530, Krishna Kumar2 wrote:
> "Michael S. Tsirkin" wrote on 03/02/2011 03:36:00 PM:
>
> Sorry for the delayed response, I have been sick the last few days.
> I am responding to both your posts here.
>
> > > Both virtio-net and vhost need some check to make sur
"Michael S. Tsirkin" wrote on 03/02/2011 03:36:00 PM:
Sorry for the delayed response, I have been sick the last few days.
I am responding to both your posts here.
> > Both virtio-net and vhost need some check to make sure very
> > high values are not passed by userspace. Is this not required?
>
On Tue, Mar 08, 2011 at 04:29:10PM +0200, Avi Kivity wrote:
> On 03/08/2011 04:20 PM, Gleb Natapov wrote:
> >On Tue, Mar 08, 2011 at 03:57:40PM +0200, Avi Kivity wrote:
> >> We may read the cpl quite often in the same vmexit (instruction privilege
> >> check, memory access checks for instruction
On 03/08/2011 04:20 PM, Gleb Natapov wrote:
On Tue, Mar 08, 2011 at 03:57:40PM +0200, Avi Kivity wrote:
> We may read the cpl quite often in the same vmexit (instruction privilege
> check, memory access checks for instruction and operands), so we gain
> a bit if we cache the value.
>
Shouldn't
On Tue, Mar 08, 2011 at 09:13:11AM -0500, Avi Kivity wrote:
> With CONFIG_CC_STACKPROTECTOR, we need a valid %gs at all times, so disable
> lazy reload and do an eager reload immediately after the vmexit.
>
Reported-by: IVAN ANGELOV
> Signed-off-by: Avi Kivity
Acked-By: Joerg Roedel
> ---
>
On Tue, Mar 08, 2011 at 03:57:40PM +0200, Avi Kivity wrote:
> We may read the cpl quite often in the same vmexit (instruction privilege
> check, memory access checks for instruction and operands), so we gain
> a bit if we cache the value.
>
Shouldn't VCPU_EXREG_CPL be cleared in vmx_set_efer too?
With CONFIG_CC_STACKPROTECTOR, we need a valid %gs at all times, so disable
lazy reload and do an eager reload immediately after the vmexit.
Signed-off-by: Avi Kivity
---
arch/x86/kvm/svm.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/arch/x86/kvm/svm.c b/arch/x86
Move the exit reason checks to the front of the function, for early
exit in the common case.
Signed-off-by: Avi Kivity
---
arch/x86/kvm/vmx.c | 15 +--
1 files changed, 9 insertions(+), 6 deletions(-)
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 6eadeaf..36fbe11 1006
Check for the exit reason first; this allows us, later,
to avoid a VMREAD for VM_EXIT_INTR_INFO_FIELD.
Signed-off-by: Avi Kivity
---
arch/x86/kvm/vmx.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index e84aa05..6eadeaf 100644
Only read it if we're going to use it later.
Signed-off-by: Avi Kivity
---
arch/x86/kvm/vmx.c |9 +++--
1 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 36fbe11..36c889e 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@
When we haven't injected an interrupt, we don't need to recover
the nmi blocking state (since the guest can't set it by itself).
This allows us to avoid a VMREAD later on.
Signed-off-by: Avi Kivity
---
arch/x86/kvm/vmx.c | 16 +++-
1 files changed, 15 insertions(+), 1 deletions(-)
vmx_complete_atomic_exit() cached it for us, so we can use it here.
Signed-off-by: Avi Kivity
---
arch/x86/kvm/vmx.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 36c889e..4b4dfc2 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch
We may read the cpl quite often in the same vmexit (instruction privilege
check, memory access checks for instruction and operands), so we gain
a bit if we cache the value.
Signed-off-by: Avi Kivity
---
arch/x86/include/asm/kvm_host.h |1 +
arch/x86/kvm/vmx.c | 17
Some rflags bits are owned by the host, not guest, so we need to use
kvm_get_rflags() to strip those bits away or kvm_set_rflags() to add them
back.
Signed-off-by: Avi Kivity
---
arch/x86/kvm/svm.c | 14 +++---
arch/x86/kvm/vmx.c |2 +-
arch/x86/kvm/x86.c |8
3 files c
If called several times within the same exit, return cached results.
Signed-off-by: Avi Kivity
---
arch/x86/include/asm/kvm_host.h |1 +
arch/x86/kvm/vmx.c | 20 ++--
2 files changed, 15 insertions(+), 6 deletions(-)
diff --git a/arch/x86/include/asm/kvm_host.
In long mode, vm86 mode is disallowed, so we need not check for
it. Reading rflags.vm may require a VMREAD, so it is expensive.
Signed-off-by: Avi Kivity
---
arch/x86/kvm/vmx.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
ind
The following patchset drops almost 200 cycles from a VMCALL vmexit on a
(fairly old) Intel, by reducing some needless VMREADs. Should also speed
up instruction emulation by a small amount.
It's a little tricky, so copying lots of people.
Avi Kivity (9):
KVM: Use kvm_get_rflags() and kvm_set_r
On Fri, Mar 04, 2011 at 10:39:05AM +0100, Jean-Philippe Menil wrote:
> Yes, it's a 2.6.37.2 kernel.
OK, here's a debugging patch.
Please run with slab debugging as previously until you see
'eventfd bug detected!' in dmesg or until there is a crash.
It might be also useful to enable timestampts on
On 03/08/2011 08:43 AM, Thomas Løcke wrote:
Hey all,
I have 9 Windows XP guests running on a KVM host. The host is
Slackware 13.1 x86_64 with kernel 2.6.35.11.
All the guests are being accessed using the built-in RDP server in
Windows XP. This worked perfectly with qemu-kvm 0.13.0, but with
0.1
On Tue, Mar 8, 2011 at 10:40 AM, Michael Tokarev wrote:
>> 2.6.35.11 + 0.13.0 = Flawless operation. It just hums along.
>> 2.6.35.11 + 0.14.0 = The connection to the internal Windows XP RDP
>> server breaks every 5-10 minutes.
>
> I ran winXP with 4 parallel RDP connections for over a hour
08.03.2011 09:43, Thomas Løcke wrote:
[]
> 2.6.35.11 + 0.13.0 = Flawless operation. It just hums along.
> 2.6.35.11 + 0.14.0 = The connection to the internal Windows XP RDP
> server breaks every 5-10 minutes.
I ran winXP with 4 parallel RDP connections for over a hour
here, "watching" some
On 03/08/2011 11:28 AM, Paolo Bonzini wrote:
On 03/08/2011 10:17 AM, Avi Kivity wrote:
Memory map can be protected by a read-write lock initially, so that
vcpu
thread holds it for read. Later can be converted to URCU.
rwlock is insufficient, need a way to force the vcpu off so a writer can
ac
On 03/08/2011 10:17 AM, Avi Kivity wrote:
Memory map can be protected by a read-write lock initially, so that vcpu
thread holds it for read. Later can be converted to URCU.
rwlock is insufficient, need a way to force the vcpu off so a writer can
actually do something.
So we need some kind of p
On 03/07/2011 06:13 PM, Marcelo Tosatti wrote:
On Sun, Mar 06, 2011 at 12:38:44PM +0200, Avi Kivity wrote:
> On 03/05/2011 06:35 PM, Marcelo Tosatti wrote:
> >Regarding global mutex, TCG and KVM execution behaviour can become more
> >similar wrt locking by dropping qemu_global_mutex during gen
On Tue, Mar 8, 2011 at 9:42 AM, Michael Tokarev wrote:
> -netdev type=tap,ifname=tap_15,script=no,downscript=no,id=foo
> -device virtio-net-pci,macaddr=de:ad:be:ef:00:15,netdev=foo
>
> (the "foo" thing is the key to join them together, can be an
> arbitrary string).
Obviously it had to be so s
08.03.2011 11:08, Thomas Løcke wrote:
[]
>>> -net nic,macaddr=de:ad:be:ef:00:15,model=virtio \
>>> -net tap,ifname=tap_15,script=no,downscript=no \
>>
>> Try switching from the obsolete -net tap to current
>> -netdev syntax. See docs/qdev-device-use.txt in the
>> qemu(-kvm) source tarball.
ya su wrote:
Yokshiaki:
event-tap record block and io wirte events, and replay these on
the other side, so block_save_live is useless during the latter ft
phase, right? if so, I think it need to process the following code in
block_save_live function:
Actually no. It just replays the last
On Tue, Mar 8, 2011 at 8:22 AM, Michael Tokarev wrote:
>> -drive
>> file=/storage_slow_one/fd_acs2_sa2.raw,snapshot=off,if=virtio,media=disk,cache=none,format=raw,boot=on
>> \
>
> Slow ;)
Yea, well. I had to name it something, and slow seemed appropriate,
given the kind of drives used in th
63 matches
Mail list logo
