Currently, the guest can not know the NUMA info of the vcpu, which will
result in performance drawback. For example:
Supposing vcpu-a on nodeA, vcpu-b on nodeB, when load balance,
the tasks' pull and push between these vcpus will cost more. But
unfortunately, currently, the guest is just blind
From: Liu Ping Fan pingf...@linux.vnet.ibm.com
The guest's scheduler can not see the numa info on the host and
this will result to the following scene:
Supposing vcpu-a on nodeA, vcpu-b on nodeB, when load balance,
the tasks' pull and push between these vcpus will cost more. But
unfortunately,
From: Liu Ping Fan pingf...@linux.vnet.ibm.com
A driver plays with Qemu's emulated virt domain device. They aims to
export the host numa info to the guest.
--todo:
A more proper place to archive this driver?
Signed-off-by: Liu Ping Fan pingf...@linux.vnet.ibm.com
---
drivers/virtio/Kconfig
From: Liu Ping Fan pingf...@linux.vnet.ibm.com
The guest's scheduler can not see the numa info on the host and
this will result to the following scene:
Supposing vcpu-a on nodeA, vcpu-b on nodeB, when load balance,
the tasks' pull and push between these vcpus will cost more. But
From: Liu Ping Fan pingf...@linux.vnet.ibm.com
The device will demand the collection of vcpus' numa info, and
trigger the guest to rebuild the sched domain.
Signed-off-by: Liu Ping Fan pingf...@linux.vnet.ibm.com
---
Makefile.target |1 +
hmp-commands.hx | 16 +
On Wed, 2012-05-23 at 14:32 +0800, Liu Ping Fan wrote:
From: Liu Ping Fan pingf...@linux.vnet.ibm.com
The guest's scheduler can not see the numa info on the host and
this will result to the following scene:
Supposing vcpu-a on nodeA, vcpu-b on nodeB, when load balance,
the tasks' pull and
On Wed, May 23, 2012 at 3:54 PM, Peter Zijlstra pet...@infradead.org wrote:
On Wed, 2012-05-23 at 14:32 +0800, Liu Ping Fan wrote:
From: Liu Ping Fan pingf...@linux.vnet.ibm.com
The guest's scheduler can not see the numa info on the host and
this will result to the following scene:
On Wed, 2012-05-23 at 16:10 +0800, Liu ping fan wrote:
the movement of vcpu
threads among host nodes will break the topology initialized by -numa
option.
You want to remap vcpu to nodes? Are you bloody insane? cpu:node maps
are assumed static, you cannot make that a dynamic map and pray
On Wed, May 23, 2012 at 4:23 PM, Peter Zijlstra pet...@infradead.org wrote:
On Wed, 2012-05-23 at 16:10 +0800, Liu ping fan wrote:
the movement of vcpu
threads among host nodes will break the topology initialized by -numa
option.
You want to remap vcpu to nodes? Are you bloody insane?
On 05/23/2012 12:05 AM, Christian Borntraeger wrote:
Folks,
today we discussed the situation of a qemu crash (with coredump) and big
guests.
Quite often the guest pages are not needed but make the core file pretty big.
The most appealing proposal that we had was to adopt the core file
On Wed, 2012-05-23 at 16:34 +0800, Liu ping fan wrote:
so we need to migrate some of vcpus from node-B to node-A, or to
node-C.
This is absolutely broken, you cannot do that.
A guest task might want to be node affine, it looks at the topology sets
a cpu affinity mask and expects to stay on
The reture value of __rmap_write_protect is either 1 or 0, use
true/false instead of these
Signed-off-by: Xiao Guangrong xiaoguangr...@linux.vnet.ibm.com
---
arch/x86/kvm/mmu.c | 13 +++--
1 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/arch/x86/kvm/mmu.c
Export the present bit of page fault error code, the later patch
will use it
Signed-off-by: Xiao Guangrong xiaoguangr...@linux.vnet.ibm.com
---
arch/x86/kvm/vmx.c |9 -
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index
mmu_spte_update() is the common function, we can easily audit the path
Signed-off-by: Xiao Guangrong xiaoguangr...@linux.vnet.ibm.com
---
arch/x86/kvm/mmu.c | 33 -
1 files changed, 20 insertions(+), 13 deletions(-)
diff --git a/arch/x86/kvm/mmu.c
Introduce a common function to abstract spte write-protect to
cleanup the code
Signed-off-by: Xiao Guangrong xiaoguangr...@linux.vnet.ibm.com
---
arch/x86/kvm/mmu.c | 58 +++
1 files changed, 31 insertions(+), 27 deletions(-)
diff --git
qemu-kvm-1.1-rc3 is now available. This release is based on the upstream
qemu 1.1-rc3, plus kvm-specific enhancements. Please see the
original QEMU 1.1-rc3 release announcement [1] for details.
This release can be used with the kvm kernel modules provided by your
distribution kernel, or by the
The P bit of page fault error code is missed in this tracepoint, fix it by
passing the full error code
Signed-off-by: Xiao Guangrong xiaoguangr...@linux.vnet.ibm.com
---
arch/x86/kvm/mmutrace.h|7 +++
arch/x86/kvm/paging_tmpl.h |3 +--
2 files changed, 4 insertions(+), 6
Document fast page fault and mmu-lock in locking.txt
Signed-off-by: Xiao Guangrong xiaoguangr...@linux.vnet.ibm.com
---
Documentation/virtual/kvm/locking.txt | 136 -
1 files changed, 135 insertions(+), 1 deletions(-)
diff --git
On Wed, May 23, 2012 at 4:48 PM, Peter Zijlstra pet...@infradead.org wrote:
On Wed, 2012-05-23 at 16:34 +0800, Liu ping fan wrote:
so we need to migrate some of vcpus from node-B to node-A, or to
node-C.
This is absolutely broken, you cannot do that.
A guest task might want to be node
On Wed, 2012-05-23 at 17:58 +0800, Liu ping fan wrote:
Please go do something else, I'll do this.
OK so that was to say never, as in dynamic cpu:node relations aren't
going to happen. but tip/sched/numa contain the bits needed to make
vnuma work.
--
To unsubscribe from this list: send the line
On Wed, 23 May 2012, Andreas Färber wrote:
Hello,
This series, based on qom-next and the two pending ARM cleanup patches, starts
moving fields from CPUArchState (CPU_COMMON) to QOM CPUState. It stops short
of moving all easily possible fields (i.e., those not depending on
target_ulong
or
On 05/23/2012 11:55 AM, Xiao Guangrong wrote:
If the the present bit of page fault error code is set, it indicates
the shadow page is populated on all levels, it means what we do is
only modify the access bit which can be done out of mmu-lock
Currently, in order to simplify the code, we only
On 05/23/2012 11:51 AM, Xiao Guangrong wrote:
Changlog:
This are some changes from Marcelo's review:
- drop SPTE_WRITE_PROTECT bit, now, only one bit is needed to do
lockless update.
- always atomicly update spte if it can be updated out of mmu-lock.
- flod the judgement of tlb flush
Hi,
To support linux guests with old kernel version, vitio driver backport
is needed. But I cannot find kvm-guest-drivers-linux.git now.
From linux distributions' virtio backport versions, such as
virtio-0.1-18.el3.src.rpm for RHEl3 hat and
novell-virtio-drivers-2.6.27-sle10sp3.iso for SLES 10
On 05/23/2012 03:03 PM, Zang Hongyong wrote:
Hi,
To support linux guests with old kernel version, vitio driver backport
is needed. But I cannot find kvm-guest-drivers-linux.git now.
It is dead.
From linux distributions' virtio backport versions, such as
virtio-0.1-18.el3.src.rpm for RHEl3
Hi, Avi
Will these patches be accepted if no other comments?
Thanks,
-Xudong
-Original Message-
From: Hao, Xudong
Sent: Tuesday, May 22, 2012 11:23 AM
To: a...@redhat.com
Cc: kvm@vger.kernel.org; linux-ker...@vger.kernel.org; mtosa...@redhat.com;
takuya.yoshik...@gmail.com;
With this patches loading 100M initrd takes ~10s instead of ~40s without.
Gleb Natapov (2):
Provide userspace IO exit completion callback.
Provide fast path for rep ins emulation if possible.
arch/x86/include/asm/kvm_host.h |6 ++
arch/x86/kvm/svm.c | 20 +++-
Current code assumes that IO exit was due to instruction emulation
and handles execution back to emulator directly. This patch adds new
userspace IO exit completion callback that can be set by any other code
that caused IO exit to userspace.
Signed-off-by: Gleb Natapov g...@redhat.com
---
rep ins emulation is going through emulator now. This is slow because
emulator knows how to write back only one datum at a time. This patch
provides fast path for the instruction in certain conditions. The
conditions are: DF flag is not set, destination memory is RAM and single
datum does not
On 05/23/2012 05:08 PM, Gleb Natapov wrote:
rep ins emulation is going through emulator now. This is slow because
emulator knows how to write back only one datum at a time. This patch
provides fast path for the instruction in certain conditions. The
conditions are: DF flag is not set,
* Avi Kivity a...@redhat.com wrote:
On 05/22/2012 02:01 AM, Thomas Gleixner wrote:
Others are not my fault :)
Seriously, if Avi/Marcelo want to rewrite the ISR emulation
Interesting POV, really.
Did you ever notice that the kernel is a collaborative effort and not
On 05/23/2012 05:40 PM, Avi Kivity wrote:
On 05/23/2012 05:08 PM, Gleb Natapov wrote:
rep ins emulation is going through emulator now. This is slow because
emulator knows how to write back only one datum at a time. This patch
provides fast path for the instruction in certain conditions. The
On 05/22/2012 04:28 AM, Liu ping fan wrote:
On Sat, May 19, 2012 at 12:14 AM, Shirley Mamashi...@us.ibm.com wrote:
On Thu, 2012-05-17 at 17:20 +0800, Liu Ping Fan wrote:
Currently, the guest can not know the NUMA info of the vcpu, which
will
result in performance drawback.
This is the
On 05/22/2012 11:14 PM, Tejun Heo wrote:
Hello,
On Tue, May 22, 2012 at 03:30:37PM +0800, Asias He wrote:
On 05/21/2012 11:42 PM, Tejun Heo wrote:
1) if the queue is stopped, q-request_fn() will never call called.
we will be stuck in the loop forever. This can happen if the remove
method is
On 05/23/2012 05:48 PM, Ingo Molnar wrote:
This is silly. Most of the time the kernel is advanced by
incremental patches. Sometimes it is advanced by minor or
major refactoring. It is never advanced by personal attacks
on contributors.
Thomas wasn't so much doing a personal attack,
On 05/22/2012 08:26 PM, Thomas Gleixner wrote:
On Tue, 22 May 2012, Avi Kivity wrote:
On 05/22/2012 12:04 AM, Thomas Gleixner wrote:
The only justification for having the same layout as the actual
hardware is when you are going to map the memory into the guest space,
which is not the case
On Wed, May 23, 2012 at 04:48:46PM +0200, Ingo Molnar wrote:
there's just so many hours in the merge window, so you asked to be
flamed ...
I can handle flames just fine :) But I'll try to buffer x86 things up
until the window closes next time.
--
MST
--
To unsubscribe from this list: send the
Am 23.05.2012 05:07, schrieb Andreas Färber:
This series, based on qom-next and the two pending ARM cleanup patches, [...]
Update: I've applied the aforementioned patches, so this series applies
unchanged to qom-next now.
Available for testing and cherry-picking (not pulling!) from:
From: Stefan Hajnoczi stefa...@linux.vnet.ibm.com
There is no longer a distinction between vlan clients and non-vlan
clients in the net core. The net core only knows about point-to-point
clients which are connected to a peer. It's time to rename the global
list of net clients since it no longer
From: Stefan Hajnoczi stefa...@linux.vnet.ibm.com
The vlan implementation in net.c has been replaced by hubs so we can
remove the code.
Signed-off-by: Stefan Hajnoczi stefa...@linux.vnet.ibm.com
Signed-off-by: Zhi Yong Wu wu...@linux.vnet.ibm.com
---
hw/xen_nic.c |1 -
net.c| 108
From: Zhi Yong Wu wu...@linux.vnet.ibm.com
Signed-off-by: Zhi Yong Wu wu...@linux.vnet.ibm.com
---
net.c | 35 +++
net.h | 11 +++
net/queue.c | 13 -
net/queue.h | 17 ++---
4 files changed, 28 insertions(+), 48
From: Stefan Hajnoczi stefa...@linux.vnet.ibm.com
Checks can be performed to make sure that hubs have at least one NIC and
one host device, warning the user if this is not the case.
Configurations which do not meet this rule tend to be broken but just
emit a warning. This patch preserves
On Wed, May 23, 2012 at 09:52:15AM -0500, Andrew Theurer wrote:
On 05/22/2012 04:28 AM, Liu ping fan wrote:
On Sat, May 19, 2012 at 12:14 AM, Shirley Mamashi...@us.ibm.com wrote:
On Thu, 2012-05-17 at 17:20 +0800, Liu Ping Fan wrote:
Currently, the guest can not know the NUMA info of the
From: Zhi Yong Wu wu...@linux.vnet.ibm.com
Signed-off-by: Zhi Yong Wu wu...@linux.vnet.ibm.com
---
net.c |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/net.c b/net.c
index 61dc28d..8c8e703 100644
--- a/net.c
+++ b/net.c
@@ -1079,7 +1079,6 @@ void do_info_network(Monitor
From: Stefan Hajnoczi stefa...@linux.vnet.ibm.com
Now that VLANClientState has been renamed to NetClientState all 'vc'
local variables should be 'nc'. Much of the code already used 'nc' but
there are places where 'vc' needs to be renamed.
Signed-off-by: Stefan Hajnoczi
On 2012-05-23 12:14, zwu.ker...@gmail.com wrote:
From: Zhi Yong Wu wu...@linux.vnet.ibm.com
Signed-off-by: Zhi Yong Wu wu...@linux.vnet.ibm.com
---
net.c |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/net.c b/net.c
index 61dc28d..8c8e703 100644
--- a/net.c
From: Stefan Hajnoczi stefa...@linux.vnet.ibm.com
Signed-off-by: Stefan Hajnoczi stefa...@linux.vnet.ibm.com
Signed-off-by: Zhi Yong Wu wu...@linux.vnet.ibm.com
---
net.c | 28 +---
net/hub.c | 24
net/hub.h |2 ++
net/slirp.c |
From: Zhi Yong Wu wu...@linux.vnet.ibm.com
The patchset implements network hub stead of vlan. The main work was done by
stefan, and i rebased it to latest QEMU upstream, did some testings and am
responsible for pushing it to QEMU upstream.
Changelog from v1:
1.) cleanup some obsolete vlan
From: Stefan Hajnoczi stefa...@linux.vnet.ibm.com
Since hubs are now used to implement the 'vlan' feature and the vlan
argument is always NULL, remove the argument entirely and update all net
clients that use qemu_new_net_client().
Signed-off-by: Stefan Hajnoczi stefa...@linux.vnet.ibm.com
From: Zhi Yong Wu wu...@linux.vnet.ibm.com
Signed-off-by: Zhi Yong Wu wu...@linux.vnet.ibm.com
---
net/queue.c |4 ++--
net/slirp.c |7 ---
net/tap.c|2 +-
slirp/if.c |5 -
slirp/libslirp.h |1 -
5 files changed, 3 insertions(+), 16
On Wed, 2012-05-23 at 08:23 -0700, Dave Hansen wrote:
On 05/23/2012 01:48 AM, Peter Zijlstra wrote:
On Wed, 2012-05-23 at 16:34 +0800, Liu ping fan wrote:
so we need to migrate some of vcpus from node-B to node-A, or to
node-C.
This is absolutely broken, you cannot do that.
A guest
From: Stefan Hajnoczi stefa...@linux.vnet.ibm.com
The vlan feature can be implemented in terms of hubs. By introducing a
hub net client it becomes possible to remove the special case vlan code
from net.c and push the vlan feature out of generic networking code.
Signed-off-by: Stefan Hajnoczi
From: Stefan Hajnoczi stefa...@linux.vnet.ibm.com
Stop using the special-case vlan code in net.c. Instead use the hub net
client to implement the vlan feature. The next patch will remove vlan
code from net.c completely.
Signed-off-by: Stefan Hajnoczi stefa...@linux.vnet.ibm.com
Signed-off-by:
On 05/23/2012 01:48 AM, Peter Zijlstra wrote:
On Wed, 2012-05-23 at 16:34 +0800, Liu ping fan wrote:
so we need to migrate some of vcpus from node-B to node-A, or to
node-C.
This is absolutely broken, you cannot do that.
A guest task might want to be node affine, it looks at the topology
From: Stefan Hajnoczi stefa...@linux.vnet.ibm.com
Another step in moving the vlan feature out of net core. Users only
deal with NetClientState and therefore qemu_del_vlan_client() should be
named qemu_del_net_client().
Signed-off-by: Stefan Hajnoczi stefa...@linux.vnet.ibm.com
Signed-off-by:
From: Stefan Hajnoczi stefa...@linux.vnet.ibm.com
VLANState is no longer used and can be removed.
Signed-off-by: Stefan Hajnoczi stefa...@linux.vnet.ibm.com
Signed-off-by: Zhi Yong Wu wu...@linux.vnet.ibm.com
---
net.c | 127 ++---
From: Stefan Hajnoczi stefa...@linux.vnet.ibm.com
The vlan feature is implemented using hubs and no longer uses
special-purpose VLANState structs that are accessible as qdev
properties.
Signed-off-by: Stefan Hajnoczi stefa...@linux.vnet.ibm.com
Signed-off-by: Zhi Yong Wu wu...@linux.vnet.ibm.com
Il 23/05/2012 17:14, zwu.ker...@gmail.com ha scritto:
From: Zhi Yong Wu wu...@linux.vnet.ibm.com
Signed-off-by: Zhi Yong Wu wu...@linux.vnet.ibm.com
---
net/queue.c |4 ++--
net/slirp.c |7 ---
net/tap.c|2 +-
slirp/if.c |5 -
The logic in find_highest_vector looks
strange until you realize the reason for the
weird memory layout, which is because this is
what the CPU microcode expects.
Add a comment so this stops tripping people up.
Signed-off-by: Michael S. Tsirkin m...@redhat.com
---
arch/x86/kvm/lapic.h |5
If the the present bit of page fault error code is set, it indicates
the shadow page is populated on all levels, it means what we do is
only modify the access bit which can be done out of mmu-lock
Currently, in order to simplify the code, we only fix the page fault
caused by write-protect on the
This bit indicates whether the spte can be writable on MMU, that means
the corresponding gpte is writable and the corresponding gfn is not
protected by shadow page protection
Signed-off-by: Xiao Guangrong xiaoguangr...@linux.vnet.ibm.com
---
arch/x86/kvm/mmu.c | 43
To see what happen on this path and help us to optimize it
Signed-off-by: Xiao Guangrong xiaoguangr...@linux.vnet.ibm.com
---
arch/x86/kvm/mmu.c |2 ++
arch/x86/kvm/mmutrace.h | 41 +
2 files changed, 43 insertions(+), 0 deletions(-)
diff --git
On Wed, 23 May 2012, Avi Kivity wrote:
On 05/22/2012 08:26 PM, Thomas Gleixner wrote:
On Tue, 22 May 2012, Avi Kivity wrote:
On 05/22/2012 12:04 AM, Thomas Gleixner wrote:
The only justification for having the same layout as the actual
hardware is when you are going to map the memory
On 05/23/2012 08:14 AM, Michael S. Tsirkin wrote:
On Wed, May 23, 2012 at 04:48:46PM +0200, Ingo Molnar wrote:
there's just so many hours in the merge window, so you asked to be
flamed ...
I can handle flames just fine :) But I'll try to buffer x86 things up
until the window closes next
On 05/23/2012 11:37 AM, Thomas Gleixner wrote:
That works, but replaces one problem with another: now we have two
sources for the same data, and need to juggle between them depending on
register number (either synchronizing in both directions, or special
casing); so you're simplifying one
On Wed, May 23, 2012 at 3:07 AM, Andreas Färber afaer...@suse.de wrote:
Hello,
This series, based on qom-next and the two pending ARM cleanup patches, starts
moving fields from CPUArchState (CPU_COMMON) to QOM CPUState. It stops short
of moving all easily possible fields (i.e., those not
On Wed, 23 May 2012, Avi Kivity wrote:
On 05/23/2012 05:48 PM, Ingo Molnar wrote:
This is silly. Most of the time the kernel is advanced by
incremental patches. Sometimes it is advanced by minor or
major refactoring. It is never advanced by personal attacks
on contributors.
On Wed, May 23, 2012 at 10:10:27PM +0200, Thomas Gleixner wrote:
Replying on a still polite reminder with a sloppy I just took what's
there and implemeted the optimization which I was tasked with is even
more of an offense.
Ow. That 'not my fault' line was a joke.
--
MST
--
To unsubscribe
On Wed, 23 May 2012, H. Peter Anvin wrote:
On 05/23/2012 11:37 AM, Thomas Gleixner wrote:
That works, but replaces one problem with another: now we have two
sources for the same data, and need to juggle between them depending on
register number (either synchronizing in both directions,
On Wed, 23 May 2012, Michael S. Tsirkin wrote:
On Wed, May 23, 2012 at 10:10:27PM +0200, Thomas Gleixner wrote:
Replying on a still polite reminder with a sloppy I just took what's
there and implemeted the optimization which I was tasked with is even
more of an offense.
Ow. That 'not
This adds/modifies ifdefs etc. and moves code to make sure that
x86-specific code doesn't get compiled on non-x86 platforms.
These changes all relate to code that is in the qemu-kvm tree and
not in the qemu tree.
The change from KVM_CAP_IRQCHIP to KVM_IRQCHIP_PIC_MASTER is because
the
This allows the i8259 emulation to be compiled without the i8254
emulation.
Currently the i8259 emulation code references some variables defined
in i8254.c for the time-drift fix. This moves the definitions from
i8254.c to i8259.c so that i8259.c becomes independent of i8254.c.
Signed-off-by:
Qemu-1.0 included some code to use a new get/set one register interface
to KVM which unfortunately hadn't settled, and in the end the code that
went into the kernel provides a different interface. This updates qemu
to use the new interface.
Since the 3.3 kernel doesn't provide this interface, in
On Wed, May 23, 2012 at 11:41 PM, Jan Kiszka jan.kis...@siemens.com wrote:
On 2012-05-23 12:14, zwu.ker...@gmail.com wrote:
From: Zhi Yong Wu wu...@linux.vnet.ibm.com
Signed-off-by: Zhi Yong Wu wu...@linux.vnet.ibm.com
---
net.c | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
On 2012-05-23 23:14, Benjamin Herrenschmidt wrote:
This adds/modifies ifdefs etc. and moves code to make sure that
x86-specific code doesn't get compiled on non-x86 platforms.
These changes all relate to code that is in the qemu-kvm tree and
not in the qemu tree.
The change from
An equivalent of this is already in qemu-kvm master as commit id
20ad1def644494f5055d129961d46b050c0a6158
What is the interest of patching qemu-kvm for non-x86? It is not
supposed to be used for this. And the affected bits are history in 1.1
(or 1.2 latest). Are there distros proving
for it?
The patch is made on top of
git://github.com/awilliam/linux-vfio.git iommu-group-vfio-20120523
(which is iommu-group-vfio-20120521 + some fixes)
Signed-off-by: Alexey Kardashevskiy a...@ozlabs.ru
---
arch/powerpc/Kconfig |6 +
arch/powerpc/include/asm/iommu.h |3 +
arch/powerpc
On Thu, May 24, 2012 at 12:00 AM, Paolo Bonzini pbonz...@redhat.com wrote:
Il 23/05/2012 17:14, zwu.ker...@gmail.com ha scritto:
From: Zhi Yong Wu wu...@linux.vnet.ibm.com
Signed-off-by: Zhi Yong Wu wu...@linux.vnet.ibm.com
---
net/queue.c | 4 ++--
net/slirp.c | 7 ---
78 matches
Mail list logo
