On Sun, 2011-05-29 at 22:54 -0400, Mathieu Desnoyers wrote:
Please note that what I currently have is a normal rbtree, not an
interval rbtree. Can you elaborate on your use-case so I can try to
figure out how we could augment it to support the interval rbtree you
need ?
We don't need anything
On Sat, 28 May 2011 23:02:04 +0300, Michael S. Tsirkin m...@redhat.com
wrote:
On Thu, May 26, 2011 at 12:58:23PM +0930, Rusty Russell wrote:
ie. free two packets for every one we're about to add. For steady state
that would work really well.
Sure, with indirect buffers, but if we
don't
Hello,
I just wanted to give kvm-tool a try and it unfortunately seems to be
stuck somewhere:
$ ./kvm run --disk linux-0.2.img --kernel
../../../linux-2.6/arch/x86/boot/bzImage
# kvm run -k ../../../linux-2.6/arch/x86/boot/bzImage -m 448 -c 4
Warning: Unable to open /dev/net/tun
PPrroobbiinngg
Hi Francis,
[ Please remember to CC me and/or other tools/kvm developers for bug reports. ]
On Mon, May 30, 2011 at 9:55 AM, Francis Moreau francis.m...@gmail.com wrote:
I just wanted to give kvm-tool a try and it unfortunately seems to be
stuck somewhere:
$ ./kvm run --disk linux-0.2.img
Hello Pekka,
On Mon, May 30, 2011 at 9:18 AM, Pekka Enberg penb...@kernel.org wrote:
[ Please remember to CC me and/or other tools/kvm developers for bug reports.
]
Ok, I'll do.
On Mon, May 30, 2011 at 9:55 AM, Francis Moreau francis.m...@gmail.com
wrote:
I just wanted to give kvm-tool
Hi,
If I am not mistaken then the graphics card needs 2 bars, one with 256MB
and one with 128K. The sound card then needs 1 bar with 16K of PCI memory.
How big is the PCI memory with seabios?
Some comments on that (apply to the kraxel.q35 branch):
You can add this to the qemu command line
From: BrillyWu brill...@viatech.com.cn
Hi, Jan
I'm very sorry for these bugs in the patch. Now I have made a
new patch based on the
newest uq/master where the patch has been applied to fix these bugs,
is it feasible? If it is
not acceptable, should I re-generate a patch based on previous
* Yang, Wei Y wei.y.y...@intel.com wrote:
This patch removes SMEP bit from CR4_RESERVED_BITS.
I'm wondering, what is the best-practice way for tools/kvm/ to set
SMEP for the guest kernel automatically, even if the guest kernel
itsef has not requested SMEP?
The portion i'm worried about are
Hi Francis,
On Mon, May 30, 2011 at 10:30 AM, Francis Moreau francis.m...@gmail.com wrote:
Nothing. That looks like a bug. Could you try to do
kill -3 `pidof kvm`
Here it is:
#
# vCPU #0's dump:
#
Registers:
--
rip: rsp: 7e3a flags:
On 2011-05-30 09:40, BrillyWu wrote:
From: BrillyWu brill...@viatech.com.cn
Hi, Jan
I'm very sorry for these bugs in the patch. Now I have made a
new patch based on the
newest uq/master where the patch has been applied to fix these bugs,
is it feasible? If it is
not acceptable,
On 05/30/2011 10:40 AM, Ingo Molnar wrote:
* Yang, Wei Ywei.y.y...@intel.com wrote:
This patch removes SMEP bit from CR4_RESERVED_BITS.
I'm wondering, what is the best-practice way for tools/kvm/ to set
SMEP for the guest kernel automatically, even if the guest kernel
itsef has not
* Avi Kivity a...@redhat.com wrote:
On 05/30/2011 10:40 AM, Ingo Molnar wrote:
* Yang, Wei Ywei.y.y...@intel.com wrote:
This patch removes SMEP bit from CR4_RESERVED_BITS.
I'm wondering, what is the best-practice way for tools/kvm/ to set
SMEP for the guest kernel automatically, even
* Paul E. McKenney paul...@linux.vnet.ibm.com wrote:
The stop_machine_run()-alike thing is for brlocks - for which
Sasha sent patches already, see these patches on the
kvm@vger.kernel.org list:
[PATCH 3/4] kvm tools: Add a brlock
[PATCH 4/4] kvm tools: Use brlock in MMIO and
Signed-off-by: Sasha Levin levinsasha...@gmail.com
---
tools/kvm/include/kvm/kvm.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/tools/kvm/include/kvm/kvm.h b/tools/kvm/include/kvm/kvm.h
index f951f2d..6a17362 100644
--- a/tools/kvm/include/kvm/kvm.h
+++
Signed-off-by: Sasha Levin levinsasha...@gmail.com
---
tools/kvm/include/kvm/mptable.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/tools/kvm/include/kvm/mptable.h b/tools/kvm/include/kvm/mptable.h
index 3c8362d..8557ae8 100644
--- a/tools/kvm/include/kvm/mptable.h
Allow pausing and unpausing guests running on the host.
Pausing a guest means that none of the VCPU threads are running
KVM_RUN until they are unpaused.
Signed-off-by: Sasha Levin levinsasha...@gmail.com
---
tools/kvm/include/kvm/kvm-cpu.h |1 +
tools/kvm/include/kvm/kvm.h |4 +++
brlock is a lock which is very cheap for reads, but very expensive
for writes.
This lock will be used when updates are very rare and reads are
common.
This lock is currently implemented by stopping the guest while
performing the updates. We assume that the only threads which
read from the locked
Adds a rwlock wrapper which like the mutex wrapper makes rwlock calls
similar to their kernel counterparts.
Signed-off-by: Sasha Levin levinsasha...@gmail.com
---
tools/kvm/include/kvm/rwsem.h | 39 +++
1 files changed, 39 insertions(+), 0 deletions(-)
Use brlock to protect mmio and ioport modules and make them
update-safe.
Signed-off-by: Sasha Levin levinsasha...@gmail.com
---
tools/kvm/ioport.c | 10 +-
tools/kvm/mmio.c | 17 +++--
2 files changed, 24 insertions(+), 3 deletions(-)
diff --git a/tools/kvm/ioport.c
Adds a debug mode which allows to switch the brlock into
a big rwlock.
This can be used to verify we don't end up with a BKL kind
of lock with the current brlock implementation.
Signed-off-by: Sasha Levin levinsasha...@gmail.com
---
tools/kvm/include/kvm/brlock.h | 16
1 files
* Sasha Levin levinsasha...@gmail.com wrote:
Signed-off-by: Sasha Levin levinsasha...@gmail.com
---
tools/kvm/include/kvm/mptable.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/tools/kvm/include/kvm/mptable.h b/tools/kvm/include/kvm/mptable.h
index
* Sasha Levin levinsasha...@gmail.com wrote:
Allow pausing and unpausing guests running on the host.
Pausing a guest means that none of the VCPU threads are running
KVM_RUN until they are unpaused.
When adding new APIs please mention them in the changelog. Just
listing them is enough:
https://bugzilla.kernel.org/show_bug.cgi?id=36222
Summary: kvm: 100% CPU usage after 3.0.0-rc1 guest shutdown
Product: Virtualization
Version: unspecified
Kernel Version: 3.0.0-rc1
Platform: All
OS/Version: Linux
Tree: Mainline
On 05/30/2011 11:05 AM, Ingo Molnar wrote:
* Avi Kivitya...@redhat.com wrote:
On 05/30/2011 10:40 AM, Ingo Molnar wrote:
* Yang, Wei Ywei.y.y...@intel.com wrote:
This patch removes SMEP bit from CR4_RESERVED_BITS.
I'm wondering, what is the best-practice way for tools/kvm/
https://bugzilla.kernel.org/show_bug.cgi?id=36222
Avi Kivity a...@redhat.com changed:
What|Removed |Added
CC||a...@redhat.com
---
* Sasha Levin levinsasha...@gmail.com wrote:
On Mon, 2011-05-30 at 10:35 +0200, Ingo Molnar wrote:
* Sasha Levin levinsasha...@gmail.com wrote:
Signed-off-by: Sasha Levin levinsasha...@gmail.com
---
tools/kvm/include/kvm/kvm.h |2 +-
1 files changed, 1 insertions(+), 1
On 05/30/2011 06:01 AM, Yang, Wei Y wrote:
This patchset enables a new CPU feature SMEP (Supervisor Mode Execution
Protection) in KVM. SMEP prevents kernel from executing code in application.
Updated Intel SDM describes this CPU feature. The document will be
published soon.
This patchset is
* Avi Kivity a...@redhat.com wrote:
Another option would be to try to set the SMEP bit *before* we
enable paging. In theory this should not confuse a Linux guest -
and while i have not tested it i *think* we let it survive in the
saved_cr4_features shadow variable. That would make
On 05/30/2011 11:52 AM, Ingo Molnar wrote:
* Avi Kivitya...@redhat.com wrote:
Another option would be to try to set the SMEP bit *before* we
enable paging. In theory this should not confuse a Linux guest -
and while i have not tested it i *think* we let it survive in the
* Avi Kivity a...@redhat.com wrote:
On 05/30/2011 11:52 AM, Ingo Molnar wrote:
* Avi Kivitya...@redhat.com wrote:
Another option would be to try to set the SMEP bit *before* we
enable paging. In theory this should not confuse a Linux guest -
and while i have not tested it i
On Mon, 2011-05-30 at 10:47 +0200, Ingo Molnar wrote:
* Sasha Levin levinsasha...@gmail.com wrote:
@@ -55,41 +56,53 @@ static const char *to_direction(u8 is_write)
bool kvm__register_mmio(u64 phys_addr, u64 phys_addr_len, void
(*kvm_mmio_callback_fn)(u64 addr, u8 *data, u32 len, u8
From brill...@viatech.com.cn
Hi, Jan
Thank you for you review and guide.
I have fixed the bugs and re-generated a clean patch which has
been checked. It can be compiled
without any error and work normally.
The patch v3 is here now.
Signed-off-by:
On Mon, 2011-05-30 at 10:38 +0200, Ingo Molnar wrote:
* Sasha Levin levinsasha...@gmail.com wrote:
Signed-off-by: Sasha Levin levinsasha...@gmail.com
---
tools/kvm/include/kvm/mptable.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git
From: Avi Kivity
Sent: Monday, May 30, 2011 4:52 PM
On 05/30/2011 06:01 AM, Yang, Wei Y wrote:
This patchset enables a new CPU feature SMEP (Supervisor Mode Execution
Protection) in KVM. SMEP prevents kernel from executing code in application.
Updated Intel SDM describes this CPU
On 05/30/2011 12:08 PM, Tian, Kevin wrote:
From: Avi Kivity
Sent: Monday, May 30, 2011 4:52 PM
On 05/30/2011 06:01 AM, Yang, Wei Y wrote:
This patchset enables a new CPU feature SMEP (Supervisor Mode Execution
Protection) in KVM. SMEP prevents kernel from executing code in
https://bugzilla.kernel.org/show_bug.cgi?id=36222
--- Comment #2 from Török Edwin edwinto...@gmail.com 2011-05-30 09:18:31 ---
Created an attachment (id=60032)
-- (https://bugzilla.kernel.org/attachment.cgi?id=60032)
kvm_stat output
when the 100% cpu usage happens
--
Configure bugmail:
From: Avi Kivity [mailto:a...@redhat.com]
Sent: Monday, May 30, 2011 5:14 PM
On 05/30/2011 12:08 PM, Tian, Kevin wrote:
From: Avi Kivity
Sent: Monday, May 30, 2011 4:52 PM
On 05/30/2011 06:01 AM, Yang, Wei Y wrote:
This patchset enables a new CPU feature SMEP (Supervisor
https://bugzilla.kernel.org/show_bug.cgi?id=36222
--- Comment #3 from Török Edwin edwinto...@gmail.com 2011-05-30 09:20:06 ---
Created an attachment (id=60042)
-- (https://bugzilla.kernel.org/attachment.cgi?id=60042)
trace-cmd record -e kvm; ^C; trace-cmd report
(In reply to comment #1)
https://bugzilla.kernel.org/show_bug.cgi?id=36222
--- Comment #4 from Török Edwin edwinto...@gmail.com 2011-05-30 09:25:58 ---
(In reply to comment #1)
- qemu monitor
(qemu) info registers
(qemu) x/40i $eip - 32
Hmm libvirt doesn't provide access to qemu monitor on purpose.
Run
On Mon, May 30, 2011 at 11:43 AM, Ingo Molnar mi...@elte.hu wrote:
Testing idea: for example 'make test locking' could do the bzImage
test-bootup, with rwlocks built instead of the brlocksj?
Pekka might have more ideas about how a good locking test-suite
should be done, as JATO has one,
On Mon, 2011-05-30 at 12:29 +0300, Pekka Enberg wrote:
On Mon, May 30, 2011 at 11:43 AM, Ingo Molnar mi...@elte.hu wrote:
Testing idea: for example 'make test locking' could do the bzImage
test-bootup, with rwlocks built instead of the brlocksj?
Pekka might have more ideas about how a
Hi Sasha,
On Mon, May 30, 2011 at 12:34 PM, Sasha Levin levinsasha...@gmail.com wrote:
It would mean we need that many VCPUs: current br_read_lock() doesn't
really do anything, which means that running these tests with dummy
threads won't work.
Heh, sure they're doing something - they're
I get the following
In file included from arch/x86/kvm/mmu.c:2856:
arch/x86/kvm/paging_tmpl.h: In function ‘paging32_walk_addr_generic’:
arch/x86/kvm/paging_tmpl.h:124: warning: ‘ptep_user’ may be used uninitialized
in this function
In file included from arch/x86/kvm/mmu.c:2852:
On Mon, 2011-05-30 at 12:40 +0300, Pekka Enberg wrote:
Hi Sasha,
On Mon, May 30, 2011 at 12:34 PM, Sasha Levin levinsasha...@gmail.com wrote:
It would mean we need that many VCPUs: current br_read_lock() doesn't
really do anything, which means that running these tests with dummy
threads
On Mon, May 30, 2011 at 12:46 PM, Sasha Levin levinsasha...@gmail.com wrote:
I'm just saying that we're limited to as many VCPU threads as we can
create. br_read_lock() won't do anything on a non-VCPU thread, which
makes it impossible to test it on non-VCPUs.
It sure would be useful to be able
* Pekka Enberg penb...@kernel.org wrote:
On Mon, May 30, 2011 at 12:46 PM, Sasha Levin levinsasha...@gmail.com wrote:
I'm just saying that we're limited to as many VCPU threads as we can
create. br_read_lock() won't do anything on a non-VCPU thread, which
makes it impossible to test it on
On 05/30/2011 12:20 PM, bugzilla-dae...@bugzilla.kernel.org wrote:
https://bugzilla.kernel.org/show_bug.cgi?id=36222
--- Comment #3 from Török Edwinedwinto...@gmail.com 2011-05-30 09:20:06 ---
Created an attachment (id=60042)
-- (https://bugzilla.kernel.org/attachment.cgi?id=60042)
On 05/30/2011 11:57 AM, Ingo Molnar wrote:
Oh, it wasn't clear to me that this was your preference as well - and
i didnt see such a capability in this series [let me know if i
blindly missed it] so i was wondering what the battle plan was fr
that :-)
There is no plan. If someone is
* Sasha Levin levinsasha...@gmail.com wrote:
I'm just saying that we're limited to as many VCPU threads as we
can create. br_read_lock() won't do anything on a non-VCPU thread,
which makes it impossible to test it on non-VCPUs.
btw., i wondered about that limit - don't we want to fix it?
Hi,
At the end of the day I want the pci address space allocation code have
no hard-coded addresses in there but use the e820 table instead to
figure how big the address space hole is. Maybe even use multiple holes
(i.e. also use the memory below mmconfig @ 0xe000 with q35).
First cut
On 05/30/2011 12:18 PM, Tian, Kevin wrote:
From: Avi Kivity [mailto:a...@redhat.com]
Sent: Monday, May 30, 2011 5:14 PM
On 05/30/2011 12:08 PM, Tian, Kevin wrote:
From: Avi Kivity
Sent: Monday, May 30, 2011 4:52 PM
On 05/30/2011 06:01 AM, Yang, Wei Y wrote:
On Mon, 2011-05-30 at 11:56 +0200, Ingo Molnar wrote:
* Sasha Levin levinsasha...@gmail.com wrote:
I'm just saying that we're limited to as many VCPU threads as we
can create. br_read_lock() won't do anything on a non-VCPU thread,
which makes it impossible to test it on non-VCPUs.
On Mon, 30 May 2011 11:46:04 +0200
Borislav Petkov b...@alien8.de wrote:
I get the following
In file included from arch/x86/kvm/mmu.c:2856:
arch/x86/kvm/paging_tmpl.h: In function ‘paging32_walk_addr_generic’:
arch/x86/kvm/paging_tmpl.h:124: warning: ‘ptep_user’ may be used
uninitialized
* Sasha Levin levinsasha...@gmail.com wrote:
On Mon, 2011-05-30 at 11:56 +0200, Ingo Molnar wrote:
* Sasha Levin levinsasha...@gmail.com wrote:
I'm just saying that we're limited to as many VCPU threads as we
can create. br_read_lock() won't do anything on a non-VCPU thread,
On Mon, 2011-05-30 at 12:13 +0200, Ingo Molnar wrote:
* Sasha Levin levinsasha...@gmail.com wrote:
On Mon, 2011-05-30 at 11:56 +0200, Ingo Molnar wrote:
* Sasha Levin levinsasha...@gmail.com wrote:
I'm just saying that we're limited to as many VCPU threads as we
can create.
* Sasha Levin levinsasha...@gmail.com wrote:
On Mon, 2011-05-30 at 12:13 +0200, Ingo Molnar wrote:
* Sasha Levin levinsasha...@gmail.com wrote:
On Mon, 2011-05-30 at 11:56 +0200, Ingo Molnar wrote:
* Sasha Levin levinsasha...@gmail.com wrote:
I'm just saying that we're
https://bugzilla.kernel.org/show_bug.cgi?id=36222
--- Comment #5 from Avi Kivity a...@redhat.com 2011-05-30 10:31:43 ---
On 05/30/2011 12:20 PM, bugzilla-dae...@bugzilla.kernel.org wrote:
https://bugzilla.kernel.org/show_bug.cgi?id=36222
--- Comment #3 from Török
From: Avi Kivity [mailto:a...@redhat.com]
Sent: Monday, May 30, 2011 6:00 PM
On 05/30/2011 12:18 PM, Tian, Kevin wrote:
From: Avi Kivity [mailto:a...@redhat.com]
Sent: Monday, May 30, 2011 5:14 PM
On 05/30/2011 12:08 PM, Tian, Kevin wrote:
From: Avi Kivity
On Mon, 2011-05-30 at 12:30 +0200, Ingo Molnar wrote:
* Sasha Levin levinsasha...@gmail.com wrote:
On Mon, 2011-05-30 at 12:13 +0200, Ingo Molnar wrote:
* Sasha Levin levinsasha...@gmail.com wrote:
On Mon, 2011-05-30 at 11:56 +0200, Ingo Molnar wrote:
* Sasha Levin
On 2011-05-30 10:59, BrillyWu wrote:
From brill...@viatech.com.cn
Hi, Jan
Thank you for you review and guide.
I have fixed the bugs and re-generated a clean patch which has
been checked. It can be compiled
without any error and work normally.
The patch v3 is here
https://bugzilla.kernel.org/show_bug.cgi?id=36222
--- Comment #6 from Avi Kivity a...@redhat.com 2011-05-30 10:55:39 ---
On 05/30/2011 12:26 PM, bugzilla-dae...@bugzilla.kernel.org wrote:
https://bugzilla.kernel.org/show_bug.cgi?id=36222
--- Comment #4 from Török
https://bugzilla.kernel.org/show_bug.cgi?id=36222
--- Comment #7 from Török Edwin edwinto...@gmail.com 2011-05-30 10:58:47 ---
It says:
Will now halt.
_
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are
On Sat, 28 May 2011 14:12:30 +0300
Sasha Levin levinsasha...@gmail.com wrote:
Document KVM_IOEVENTFD that can be used to receive
notifications of PIO/MMIO events without triggering
an exit.
Cc: Avi Kivity a...@redhat.com
Cc: Marcelo Tosatti mtosa...@redhat.com
Signed-off-by: Sasha Levin
https://bugzilla.kernel.org/show_bug.cgi?id=36222
--- Comment #8 from Török Edwin edwinto...@gmail.com 2011-05-30 11:01:00 ---
And that corresponds to this script:
log_action_msg Will now halt
halt -d -f $netdown $poweroff $hddown
--
Configure bugmail:
On Mon, 30 May 2011 11:54:51 +0200
Ingo Molnar mi...@elte.hu wrote:
* Pekka Enberg penb...@kernel.org wrote:
On Mon, May 30, 2011 at 12:46 PM, Sasha Levin levinsasha...@gmail.com
wrote:
I'm just saying that we're limited to as many VCPU threads as we can
create. br_read_lock()
https://bugzilla.kernel.org/show_bug.cgi?id=36222
--- Comment #9 from Török Edwin edwinto...@gmail.com 2011-05-30 11:09:45 ---
Using -serial stdio, and console=ttyS0 I see an Oops when running 'halt -f -p'
in the guest:
/[ 36.308445] invalid opcode: [#1] SMP
[ 36.308445] CPU 1
[
On Mon, 2011-05-30 at 20:11 +0900, Takuya Yoshikawa wrote:
On Mon, 30 May 2011 11:54:51 +0200
Ingo Molnar mi...@elte.hu wrote:
* Pekka Enberg penb...@kernel.org wrote:
On Mon, May 30, 2011 at 12:46 PM, Sasha Levin levinsasha...@gmail.com
wrote:
I'm just saying that we're
* Paul E. McKenney (paul...@linux.vnet.ibm.com) wrote:
On Sun, May 29, 2011 at 01:01:04PM -0400, Mathieu Desnoyers wrote:
* Mathieu Desnoyers (mathieu.desnoy...@efficios.com) wrote:
* Sasha Levin (levinsasha...@gmail.com) wrote:
[...]
Hi Mathieu!
In tools/kvm/ we use a rb-tree
On Mon, 30 May 2011 14:12:34 +0300
Sasha Levin levinsasha...@gmail.com wrote:
On Mon, 2011-05-30 at 20:11 +0900, Takuya Yoshikawa wrote:
On Mon, 30 May 2011 11:54:51 +0200
Ingo Molnar mi...@elte.hu wrote:
* Pekka Enberg penb...@kernel.org wrote:
On Mon, May 30, 2011 at
* Sasha Levin (levinsasha...@gmail.com) wrote:
On Sun, 2011-05-29 at 22:54 -0400, Mathieu Desnoyers wrote:
Please note that what I currently have is a normal rbtree, not an
interval rbtree. Can you elaborate on your use-case so I can try to
figure out how we could augment it to support the
https://bugzilla.kernel.org/show_bug.cgi?id=36222
--- Comment #10 from Avi Kivity a...@redhat.com 2011-05-30 11:38:09 ---
On 05/30/2011 02:09 PM, bugzilla-dae...@bugzilla.kernel.org wrote:
[ 36.308445] [810018ae] cpu_idle+0x9e/0xb0
[ 36.308445] [8162c73b]
On 05/30/2011 02:26 PM, Takuya Yoshikawa wrote:
qemu also allows having more VCPUs than cores.
I have to check again, then :) Thank you!
I will try both with many VCPUs.
Note, with cpu overcommit the results are going to be bad.
--
error compiling committee.c: too many arguments to
* Avi Kivity a...@redhat.com wrote:
On 05/30/2011 02:26 PM, Takuya Yoshikawa wrote:
qemu also allows having more VCPUs than cores.
I have to check again, then :) Thank you!
I will try both with many VCPUs.
Note, with cpu overcommit the results are going to be bad.
And that is
On Mon, 2011-05-30 at 14:55 +0300, Pekka Enberg wrote:
On Mon, May 30, 2011 at 2:49 PM, Ingo Molnar mi...@elte.hu wrote:
[*] Would be nice if tools/kvm/ had a debug option to simulate 'lots
of RAM' as well somehow - perhaps by not pre-initializing it and
somehow catching all-zeroes
On 05/30/2011 02:49 PM, Ingo Molnar wrote:
* Avi Kivitya...@redhat.com wrote:
On 05/30/2011 02:26 PM, Takuya Yoshikawa wrote:
qemu also allows having more VCPUs than cores.
I have to check again, then :) Thank you!
I will try both with many VCPUs.
Note, with cpu
On Thu, 26 May 2011, Joerg Roedel wrote:
On Thu, May 26, 2011 at 05:20:32PM +0200, Markus Schade wrote:
On 05/26/2011 01:28 PM, Markus Schade wrote:
On 05/26/2011 08:44 AM, Avi Kivity wrote:
On 05/25/2011 09:49 AM, Markus Schade wrote:
Git bisect tells me that this is the first bad commit:
* Sasha Levin levinsasha...@gmail.com wrote:
On Mon, 2011-05-30 at 14:55 +0300, Pekka Enberg wrote:
On Mon, May 30, 2011 at 2:49 PM, Ingo Molnar mi...@elte.hu wrote:
[*] Would be nice if tools/kvm/ had a debug option to simulate 'lots
of RAM' as well somehow - perhaps by not
On Mon, 2011-05-30 at 14:20 +0200, Ingo Molnar wrote:
* Sasha Levin levinsasha...@gmail.com wrote:
On Mon, 2011-05-30 at 14:55 +0300, Pekka Enberg wrote:
On Mon, May 30, 2011 at 2:49 PM, Ingo Molnar mi...@elte.hu wrote:
[*] Would be nice if tools/kvm/ had a debug option to simulate
On 05/30/2011 03:20 PM, Ingo Molnar wrote:
How does this work in practice - i thought we memset() all of RAM
during guest kernel bootup. That might have changed with the memblock
allocator ... So the guest kernel does not touch all of that 64 GB of
RAM, so your box wont OOM straight away?
IIRC
A logic error in mwait_play_dead() causes the kernel to use mwait
even on cpus which don't support it, such as KVM virtual cpus.
Introduced by 349c004e3d31fd.
Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=36222
Reported-by: Török Edwin edwinto...@gmail.com
Signed-off-by: Avi Kivity
On 05/30/2011 03:22 PM, Sasha Levin wrote:
Oh, that's neat. Btw., i think there should be an option to actually
*force* blatant overcommit: if i typo the option i'd like the tool to
tell me that i'm probably stupid and refuse to run with that (and
suggest the force-overcommit option),
https://bugzilla.kernel.org/show_bug.cgi?id=36222
--- Comment #12 from Török Edwin edwinto...@gmail.com 2011-05-30 12:26:19 ---
Bisection tells me this is the offending commit (see below), but I see you
found it too.
commit 349c004e3d31fda23ad225b61861be38047fff16
Author: Christoph Lameter
On Mon, May 30, 2011 at 3:23 PM, Avi Kivity a...@redhat.com wrote:
IIRC there never was a memset() of all RAM, at least since kvm started
booting Linux. Windows has a zeroing thread which causes all of RAM to be
committed shortly after boot, though.
Yup, I haven't heard of such thing either.
On Mon, 2011-05-30 at 14:36 +0200, Ingo Molnar wrote:
* Avi Kivity a...@redhat.com wrote:
On 05/30/2011 02:49 PM, Ingo Molnar wrote:
* Avi Kivitya...@redhat.com wrote:
On 05/30/2011 02:26 PM, Takuya Yoshikawa wrote:
qemu also allows having more VCPUs than cores.
* Avi Kivity a...@redhat.com wrote:
On 05/30/2011 05:10 PM, Ingo Molnar wrote:
[...] Windows has a zeroing thread which causes all of RAM to be
committed shortly after boot, though.
heh, maybe they read lkml and copied my ancient idea:
On 2011-05-30 17:10, Roedel, Joerg wrote:
On Mon, May 30, 2011 at 11:04:02AM -0400, Jan Kiszka wrote:
On 2011-05-30 16:38, Nadav Har'El wrote:
On Mon, May 30, 2011, Jan Kiszka wrote about drop -enable-nesting (was:
[PATCH 3/7] cpu model bug fixes and definition corrections...):
On 2011-05-30
On Mon, May 30, 2011, Jan Kiszka wrote about Re: drop -enable-nesting:
-enable-nesting could remain as a synonym for enabling either VMX or SVM
in the guest, depending on what was available in the host (because KVM now
supports both nested SVM and nested VMX, but not SVM-on-VMX or vice
This patch masks CPUID leaf 7 ebx against host capability word9.
Signed-off-by: Yang, Wei wei.y.y...@intel.com
Signed-off-by: Shan, Haitao haitao.s...@intel.com
Signed-off-by: Li, Xin xin...@intel.com
---
arch/x86/kvm/x86.c | 15 ++-
1 files changed, 14 insertions(+), 1
This patch adds SMEP handling when setting CR4.
Signed-off-by: Yang, Wei wei.y.y...@intel.com
Signed-off-by: Shan, Haitao haitao.s...@intel.com
Signed-off-by: Li, Xin xin...@intel.com
---
arch/x86/kvm/x86.c | 15 +--
1 files changed, 13 insertions(+), 2 deletions(-)
diff --git
This patch adds instruction fetch checking when walking guest page table.
Signed-off-by: Yang, Wei wei.y.y...@intel.com
Signed-off-by: Shan, Haitao haitao.s...@intel.com
Signed-off-by: Li, Xin xin...@intel.com
---
arch/x86/kvm/paging_tmpl.h |9 -
1 files changed, 8 insertions(+),
This patchset enables a new CPU feature SMEP (Supervisor Mode Execution
Protection) in QEMU-KVM. SMEP prevents kernel from executing code in
application.
Updated Intel SDM describes this CPU feature. The document will be published
soon.
SMEP is identified by CPUID leaf 7 EBX[7], which is 0
This patchset enables a new CPU feature SMEP (Supervisor Mode Execution
Protection) in KVM. SMEP prevents kernel from executing code in application.
Updated Intel SDM describes this CPU feature. The document will be
published soon.
This patchset is based on Fenghua's SMEP patch series, as
This patch removes SMEP bit from CR4_RESERVED_BITS.
Signed-off-by: Yang, Wei wei.y.y...@intel.com
Signed-off-by: Shan, Haitao haitao.s...@intel.com
Signed-off-by: Li, Xin xin...@intel.com
---
arch/x86/include/asm/kvm_host.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff
On 05/30/2011 06:15 PM, Jan Kiszka wrote:
On 2011-05-30 17:10, Roedel, Joerg wrote:
On Mon, May 30, 2011 at 11:04:02AM -0400, Jan Kiszka wrote:
On 2011-05-30 16:38, Nadav Har'El wrote:
On Mon, May 30, 2011, Jan Kiszka wrote about drop -enable-nesting (was: [PATCH
3/7] cpu model bug fixes
On 2011-05-30 17:19, Avi Kivity wrote:
On 05/30/2011 06:15 PM, Jan Kiszka wrote:
On 2011-05-30 17:10, Roedel, Joerg wrote:
On Mon, May 30, 2011 at 11:04:02AM -0400, Jan Kiszka wrote:
On 2011-05-30 16:38, Nadav Har'El wrote:
On Mon, May 30, 2011, Jan Kiszka wrote about drop -enable-nesting
Jan Kiszka jan.kis...@web.de writes:
On 2011-05-29 17:26, Avi Kivity wrote:
On 05/29/2011 06:21 PM, Jan Kiszka wrote:
[...]
We also need a better interface to discover and track legacy IRQ routes
for device assignment. Markus is currently collecting requirements for
qdev enhancements, and I
On 2011-05-30 17:27, Jan Kiszka wrote:
On 2011-05-30 17:19, Avi Kivity wrote:
I think it's safe to drop -enable-nesting immediately. Dan, does
libvirt make use of it?
I'm currently checking with some customer who played with Proxmox and
nesting if that stack was aware of the switch or
On 2011-05-30 17:16, Nadav Har'El wrote:
On Mon, May 30, 2011, Jan Kiszka wrote about Re: drop -enable-nesting:
-enable-nesting could remain as a synonym for enabling either VMX or SVM
in the guest, depending on what was available in the host (because KVM now
supports both nested SVM and
The bug has caused us to exit gracefully when receiving SIGUSR2.
Signed-off-by: Sasha Levin levinsasha...@gmail.com
---
tools/kvm/include/kvm/kvm.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/tools/kvm/include/kvm/kvm.h b/tools/kvm/include/kvm/kvm.h
index
Signed-off-by: Sasha Levin levinsasha...@gmail.com
---
tools/kvm/include/kvm/mptable.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/tools/kvm/include/kvm/mptable.h b/tools/kvm/include/kvm/mptable.h
index 3c8362d..8557ae8 100644
--- a/tools/kvm/include/kvm/mptable.h
1 - 100 of 125 matches
Mail list logo
