Bugs item #2971075, was opened at 2010-03-16 07:02
Message generated for change (Tracker Item Submitted) made by zaphodbrx
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=893831aid=2971075group_id=180599
Please note that this message will contain a full copy of the
On 03/16/2010 02:20 AM, Jason wrote:
In comparing KVM 2.6.31.6b to XenServer 5.5.0, it seems KVM has fewer overall
VMREADs and VMWRITEs, but there are a lot of VMWRITEs to Host FS_SEL, Host
GS_SEL, Host FS_BASE, and Host GS_BASE that don't appear in Xen.
Ugh, these should definitely be
Please send in any agenda items you are interested in covering.
thanks,
-chris
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
* Avi Kivity a...@redhat.com wrote:
On 03/16/2010 07:27 AM, Zhang, Yanmin wrote:
From: Zhang, Yanminyanmin_zh...@linux.intel.com
Based on the discussion in KVM community, I worked out the patch to support
perf to collect guest os statistics from host side. This patch is implemented
with
On Tue, 2010-03-16 at 07:41 +0200, Avi Kivity wrote:
On 03/16/2010 07:27 AM, Zhang, Yanmin wrote:
From: Zhang, Yanminyanmin_zh...@linux.intel.com
Based on the discussion in KVM community, I worked out the patch to support
perf to collect guest os statistics from host side. This patch is
On Mon, Mar 15, 2010 at 08:27:25PM -0500, Anthony Liguori wrote:
Actually cache=writeback is as safe as any normal host is with a
volatile disk cache, except that in this case the disk cache is
actually a lot larger. With a properly implemented filesystem this
will never cause corruption.
On 03/15/2010 08:48 PM, Anthony Liguori wrote:
On 03/15/2010 04:27 AM, Avi Kivity wrote:
That's only beneficial if the cache is shared. Otherwise, you could
use the balloon to evict cache when memory is tight.
Shared cache is mostly a desktop thing where users run similar
workloads. For
Chris Wright chr...@redhat.com wrote:
Please send in any agenda items you are interested in covering.
Migration:
- flexible migration: I hope to sent an RFC patch on time for the
call. idea is to use subsections.
- callbacks. block migration introduced several callbacks:
* cancel()
*
On 03/15/2010 10:23 PM, Chris Webb wrote:
Avi Kivitya...@redhat.com writes:
On 03/15/2010 10:07 AM, Balbir Singh wrote:
Yes, it is a virtio call away, but is the cost of paying twice in
terms of memory acceptable?
Usually, it isn't, which is why I recommend cache=off.
On 03/16/2010 09:24 AM, Ingo Molnar wrote:
* Avi Kivitya...@redhat.com wrote:
On 03/16/2010 07:27 AM, Zhang, Yanmin wrote:
From: Zhang, Yanminyanmin_zh...@linux.intel.com
Based on the discussion in KVM community, I worked out the patch to support
perf to collect guest os
On Tue, 2010-03-16 at 15:48 +0800, Zhang, Yanmin wrote:
On Tue, 2010-03-16 at 07:41 +0200, Avi Kivity wrote:
On 03/16/2010 07:27 AM, Zhang, Yanmin wrote:
From: Zhang, Yanminyanmin_zh...@linux.intel.com
Based on the discussion in KVM community, I worked out the patch to
support
On Tue, Mar 16, 2010 at 10:18:03AM +0100, Juan Quintela wrote:
Chris Wright chr...@redhat.com wrote:
Please send in any agenda items you are interested in covering.
Migration:
- flexible migration: I hope to sent an RFC patch on time for the
call. idea is to use subsections.
-
The vhost-net backend now only supports synchronous send/recv
operations. The patch provides multiple submits and asynchronous
notifications. This is needed for zero-copy case.
Signed-off-by: Xin Xiaohui xiaohui@intel.com
---
Michael,
I don't use the kiocb comes from the sendmsg/recvmsg,
Bugs item #2971166, was opened at 2010-03-16 09:32
Message generated for change (Tracker Item Submitted) made by theneb
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=893831aid=2971166group_id=180599
Please note that this message will contain a full copy of the
On 03/16/2010 09:48 AM, Zhang, Yanmin wrote:
Excellent, support for guest kernel != host kernel is critical (I can't
remember the last time I ran same kernels).
How would we support multiple guests with different kernels?
With the patch, 'perf kvm report --sort pid could show
summary
On 03/16/2010 11:28 AM, Zhang, Yanmin wrote:
Sorry. I found currently --pid isn't process but a thread (main thread).
Ingo,
Is it possible to support a new parameter or extend --inherit, so 'perf record'
and
'perf top' could collect data on all threads of a process when the process is
On 03/15/2010 08:10 PM, Gleb Natapov wrote:
On Mon, Mar 15, 2010 at 04:46:20PM +0100, Andre Przywara wrote:
Gleb Natapov wrote:
If LOCK prefix is used dest arg should be memory, otherwise instruction
should generate #UD.
Well, there is one exception:
There is an AMD specific
On Tue, Mar 16, 2010 at 11:37:35AM +0200, Avi Kivity wrote:
On 03/15/2010 08:10 PM, Gleb Natapov wrote:
On Mon, Mar 15, 2010 at 04:46:20PM +0100, Andre Przywara wrote:
Gleb Natapov wrote:
If LOCK prefix is used dest arg should be memory, otherwise instruction
should generate #UD.
Well, there
On 03/16/2010 11:29 AM, Daniel P. Berrange wrote:
On Tue, Mar 16, 2010 at 10:18:03AM +0100, Juan Quintela wrote:
Chris Wrightchr...@redhat.com wrote:
Please send in any agenda items you are interested in covering.
Migration:
- flexible migration: I hope to sent an RFC
* Zhang, Yanmin yanmin_zh...@linux.intel.com wrote:
On Tue, 2010-03-16 at 15:48 +0800, Zhang, Yanmin wrote:
On Tue, 2010-03-16 at 07:41 +0200, Avi Kivity wrote:
On 03/16/2010 07:27 AM, Zhang, Yanmin wrote:
From: Zhang, Yanminyanmin_zh...@linux.intel.com
Based on the discussion
* Avi Kivity a...@redhat.com wrote:
On 03/16/2010 09:24 AM, Ingo Molnar wrote:
* Avi Kivitya...@redhat.com wrote:
On 03/16/2010 07:27 AM, Zhang, Yanmin wrote:
From: Zhang, Yanminyanmin_zh...@linux.intel.com
Based on the discussion in KVM community, I worked out the patch to support
Am 16.03.2010 10:17, schrieb Avi Kivity:
On 03/15/2010 10:23 PM, Chris Webb wrote:
Avi Kivitya...@redhat.com writes:
On 03/15/2010 10:07 AM, Balbir Singh wrote:
Yes, it is a virtio call away, but is the cost of paying twice in
terms of memory acceptable?
Usually, it
On Tue, Mar 16, 2010 at 09:29:44AM +, Daniel P. Berrange wrote:
On Tue, Mar 16, 2010 at 10:18:03AM +0100, Juan Quintela wrote:
Chris Wright chr...@redhat.com wrote:
Please send in any agenda items you are interested in covering.
Migration:
- flexible migration: I hope to sent an
On 03/16/2010 11:53 AM, Ingo Molnar wrote:
* Avi Kivitya...@redhat.com wrote:
On 03/16/2010 09:24 AM, Ingo Molnar wrote:
* Avi Kivitya...@redhat.com wrote:
On 03/16/2010 07:27 AM, Zhang, Yanmin wrote:
From: Zhang, Yanminyanmin_zh...@linux.intel.com
Based on
On 03/16/2010 11:54 AM, Kevin Wolf wrote:
Is this with qcow2, raw file, or direct volume access?
I can understand it for qcow2, but for direct volume access this
shouldn't happen. The guest schedules as many writes as it can,
followed by a sync. The host (and disk) can then reschedule them
* Avi Kivity a...@redhat.com wrote:
On 03/16/2010 11:53 AM, Ingo Molnar wrote:
* Avi Kivitya...@redhat.com wrote:
On 03/16/2010 09:24 AM, Ingo Molnar wrote:
* Avi Kivitya...@redhat.com wrote:
On 03/16/2010 07:27 AM, Zhang, Yanmin wrote:
From: Zhang,
Avi,
cache=writeback can be faster than cache=none for the same reasons
a disk cache speeds up access. As long as the I/O mix contains more
asynchronous then synchronous writes it allows the host to do much
more reordering, only limited by the cache size (which can be quite
huge when using the
On Tue, Mar 16, 2010 at 11:43:48AM +0200, Avi Kivity wrote:
On 03/16/2010 11:29 AM, Daniel P. Berrange wrote:
On Tue, Mar 16, 2010 at 10:18:03AM +0100, Juan Quintela wrote:
Chris Wrightchr...@redhat.com wrote:
Please send in any agenda items you are interested in covering.
On 03/16/2010 12:26 PM, Christoph Hellwig wrote:
Avi,
cache=writeback can be faster than cache=none for the same reasons
a disk cache speeds up access. As long as the I/O mix contains more
asynchronous then synchronous writes it allows the host to do much
more reordering, only limited by the
On 03/16/2010 12:31 PM, Daniel P. Berrange wrote:
Polling loops are an indication that something is wrong.
Except when people suggest they are the right answer, qcow high
watermark ;-P
I liked Anthony's suggestion of an lvm2 block format driver. No polling.
--
error compiling
On 03/16/2010 12:20 PM, Ingo Molnar wrote:
The symbol server's client can certainly access the bits through vmchannel.
Ok, that would work i suspect.
Would be nice to have the symbol server in tools/perf/ and also make it easy
to add it to the initrd via a .config switch or so.
On Tue, Mar 16, 2010 at 12:38:02PM +0200, Avi Kivity wrote:
On 03/16/2010 12:31 PM, Daniel P. Berrange wrote:
Polling loops are an indication that something is wrong.
Except when people suggest they are the right answer, qcow high
watermark ;-P
I liked Anthony's suggestion of an
On Tue, Mar 16, 2010 at 12:38:02PM +0200, Avi Kivity wrote:
On 03/16/2010 12:31 PM, Daniel P. Berrange wrote:
Polling loops are an indication that something is wrong.
Except when people suggest they are the right answer, qcow high
watermark ;-P
I liked Anthony's suggestion of an
On Tue, Mar 16, 2010 at 12:36:31PM +0200, Avi Kivity wrote:
Are you talking about direct volume access or qcow2?
Doesn't matter.
For direct volume access, I still don't get it. The number of barriers
issues by the host must equal (or exceed, but that's pointless) the
number of barriers
* Avi Kivity a...@redhat.com wrote:
On 03/16/2010 12:20 PM, Ingo Molnar wrote:
The symbol server's client can certainly access the bits through
vmchannel.
Ok, that would work i suspect.
Would be nice to have the symbol server in tools/perf/ and also make it
easy
to add it to the
The dirty and non-dirty pages are checked one by one in vl.c.
When the most of the memory is not dirty,
checking the dirty and non-dirty pages by multiple page size
should be much faster than checking them one by one.
We introduced bit-based phys_ram_dirty for VGA, CODE and MIGRATION, and
Introduces cpu_physical_memory_get_dirty_range().
It checks the first row and puts dirty addr in the array.
If the first row is empty, it skips to the first non-dirty row
or the end addr, and put the length in the first entry of the array.
Signed-off-by: Yoshiaki Tamura
Modifies wrapper functions for byte-based phys_ram_dirty bitmap to
bit-based phys_ram_dirty bitmap, and adds more wrapper functions to prevent
direct access to the phys_ram_dirty bitmap.
Signed-off-by: Yoshiaki Tamura tamura.yoshi...@lab.ntt.co.jp
Signed-off-by: OHMURA Kei
Replaces direct phys_ram_dirty access with wrapper functions to prevent
direct access to the phys_ram_dirty bitmap.
Signed-off-by: Yoshiaki Tamura tamura.yoshi...@lab.ntt.co.jp
Signed-off-by: OHMURA Kei ohmura@lab.ntt.co.jp
---
exec.c | 45 -
1
Modifies ram_save_block() and ram_save_remaining() to use
cpu_physical_memory_get_dirty_range() to check multiple dirty and non-dirty
pages at once.
Signed-off-by: Yoshiaki Tamura tamura.yoshi...@lab.ntt.co.jp
Signed-off-by: OHMURA Kei ohmura@lab.ntt.co.jp
---
vl.c | 55
Replaces byte-based phys_ram_dirty bitmap with
three bit-based phys_ram_dirty bitmap.
On allocation, it sets all bits in the bitmap.
Signed-off-by: Yoshiaki Tamura tamura.yoshi...@lab.ntt.co.jp
Signed-off-by: OHMURA Kei ohmura@lab.ntt.co.jp
---
exec.c | 22 +-
1 files
Modifies kvm_get_dirty_pages_log_range to use
cpu_physical_memory_set_dirty_range() to update the row of
the bit-based phys_ram_dirty bitmap at once.
Signed-off-by: Yoshiaki Tamura tamura.yoshi...@lab.ntt.co.jp
Signed-off-by: OHMURA Kei ohmura@lab.ntt.co.jp
---
qemu-kvm.c | 19
On 03/16/2010 12:44 PM, Christoph Hellwig wrote:
On Tue, Mar 16, 2010 at 12:36:31PM +0200, Avi Kivity wrote:
Are you talking about direct volume access or qcow2?
Doesn't matter.
For direct volume access, I still don't get it. The number of barriers
issues by the host must
On 03/16/2010 12:50 PM, Ingo Molnar wrote:
I'm confused - initrd seems to be guest-side. I was talking about the host
side.
host side doesnt need much support - just some client capability in perf
itself. I suspect vmchannels are sufficiently flexible and configuration-free
for such
On 03/16/2010 12:45 PM, Daniel P. Berrange wrote:
On Tue, Mar 16, 2010 at 12:38:02PM +0200, Avi Kivity wrote:
On 03/16/2010 12:31 PM, Daniel P. Berrange wrote:
Polling loops are an indication that something is wrong.
Except when people suggest they are the right answer,
* Avi Kivity a...@redhat.com wrote:
On 03/16/2010 12:50 PM, Ingo Molnar wrote:
I'm confused - initrd seems to be guest-side. I was talking about the host
side.
host side doesnt need much support - just some client capability in perf
itself. I suspect vmchannels are sufficiently flexible
On Tue, Mar 16, 2010 at 05:32:17PM +0800, Xin Xiaohui wrote:
The vhost-net backend now only supports synchronous send/recv
operations. The patch provides multiple submits and asynchronous
notifications. This is needed for zero-copy case.
Signed-off-by: Xin Xiaohui xiaohui@intel.com
---
On 03/16/2010 01:25 PM, Ingo Molnar wrote:
I haven't followed vmchannel closely, but I think it is. vmchannel is
terminated in qemu on the host side, not in the host kernel. So perf would
need to connect to qemu.
Hm, that sounds rather messy if we want to use it to basically expose
On 03/16/2010 12:53 PM, Yoshiaki Tamura wrote:
Replaces byte-based phys_ram_dirty bitmap with
three bit-based phys_ram_dirty bitmap.
On allocation, it sets all bits in the bitmap.
Signed-off-by: Yoshiaki Tamuratamura.yoshi...@lab.ntt.co.jp
Signed-off-by: OHMURA Keiohmura@lab.ntt.co.jp
---
* Avi Kivity a...@redhat.com wrote:
On 03/16/2010 01:25 PM, Ingo Molnar wrote:
I haven't followed vmchannel closely, but I think it is. vmchannel is
terminated in qemu on the host side, not in the host kernel. So perf would
need to connect to qemu.
Hm, that sounds rather messy if we
On 03/16/2010 02:29 PM, Ingo Molnar wrote:
* Avi Kivitya...@redhat.com wrote:
On 03/16/2010 01:25 PM, Ingo Molnar wrote:
I haven't followed vmchannel closely, but I think it is. vmchannel is
terminated in qemu on the host side, not in the host kernel. So perf would
need
Add test for opcodes 0x90-0x9f emulation
Signed-off-by: Gleb Natapov g...@redhat.com
diff --git a/kvm/user/test/x86/realmode.c b/kvm/user/test/x86/realmode.c
index bc6b27f..bfc2942 100644
--- a/kvm/user/test/x86/realmode.c
+++ b/kvm/user/test/x86/realmode.c
@@ -141,6 +141,90 @@ int
On 03/16/2010 12:53 PM, Yoshiaki Tamura wrote:
Modifies wrapper functions for byte-based phys_ram_dirty bitmap to
bit-based phys_ram_dirty bitmap, and adds more wrapper functions to prevent
direct access to the phys_ram_dirty bitmap.
+
+static inline int
On 03/16/2010 12:53 PM, Yoshiaki Tamura wrote:
Introduces cpu_physical_memory_get_dirty_range().
It checks the first row and puts dirty addr in the array.
If the first row is empty, it skips to the first non-dirty row
or the end addr, and put the length in the first entry of the array.
+/* It
On 03/16/2010 02:42 PM, Gleb Natapov wrote:
Add test for opcodes 0x90-0x9f emulation
Reviewed-by: Avi Kivity a...@redhat.com
+ MK_INSN(xchg_test1, xchg %eax,%eax\n\t);
AKA 'nop'.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this
On Tue, Mar 16, 2010 at 02:50:58PM +0200, Avi Kivity wrote:
On 03/16/2010 02:42 PM, Gleb Natapov wrote:
Add test for opcodes 0x90-0x9f emulation
Reviewed-by: Avi Kivity a...@redhat.com
+MK_INSN(xchg_test1, xchg %eax,%eax\n\t);
AKA 'nop'.
Yep, but we still emulate it.
--
On 03/16/2010 02:52 PM, Gleb Natapov wrote:
+ MK_INSN(xchg_test1, xchg %eax,%eax\n\t);
AKA 'nop'.
Yep, but we still emulate it.
And well too.
Note that 'xchg eax, ebx' will clear the top 32-bits of rax and rbx, but
'xchg eax, eax' will not.
--
error compiling
Avi Kivity wrote:
On 03/16/2010 12:53 PM, Yoshiaki Tamura wrote:
Replaces byte-based phys_ram_dirty bitmap with
three bit-based phys_ram_dirty bitmap.
On allocation, it sets all bits in the bitmap.
Signed-off-by: Yoshiaki Tamuratamura.yoshi...@lab.ntt.co.jp
Signed-off-by: OHMURA
On 03/16/2010 03:01 PM, Yoshiaki Tamura wrote:
-uint8_t *phys_ram_dirty;
+unsigned long *phys_ram_vga_dirty;
+unsigned long *phys_ram_code_dirty;
+unsigned long *phys_ram_migration_dirty;
Would be nice to make this an array.
Thanks for pointing out.
I have a question regarding the index of
* Avi Kivity a...@redhat.com wrote:
On 03/16/2010 02:29 PM, Ingo Molnar wrote:
I mean, i can trust a kernel service and i can trust /proc/kallsyms.
Can perf trust a random process claiming to be Qemu? What's the trust
mechanism here?
Obviously you can't trust anything you get from
On 03/16/2010 12:53 PM, Yoshiaki Tamura wrote:
Experimental results:
Cond1: 1.9 ~ 61 times speed up
Cond2: 1.9 ~ 56 times speed up
Cond3: 1.9 ~ 59 times speed up
Cond4: 1.7 ~ 59 times speed up
Impressive results. What's the typical speedup? Closer to 1.9 or 61?
Note the issue with the
On 03/16/2010 03:08 PM, Ingo Molnar wrote:
I mean, i can trust a kernel service and i can trust /proc/kallsyms.
Can perf trust a random process claiming to be Qemu? What's the trust
mechanism here?
Obviously you can't trust anything you get from a guest, no matter how you
get it.
Avi Kivity wrote:
On 03/16/2010 12:53 PM, Yoshiaki Tamura wrote:
Modifies wrapper functions for byte-based phys_ram_dirty bitmap to
bit-based phys_ram_dirty bitmap, and adds more wrapper functions to
prevent
direct access to the phys_ram_dirty bitmap.
+
+static inline int
On 03/16/2010 03:17 PM, Yoshiaki Tamura wrote:
Avi Kivity wrote:
On 03/16/2010 12:53 PM, Yoshiaki Tamura wrote:
Modifies wrapper functions for byte-based phys_ram_dirty bitmap to
bit-based phys_ram_dirty bitmap, and adds more wrapper functions to
prevent
direct access to the phys_ram_dirty
* Avi Kivity a...@redhat.com wrote:
On 03/16/2010 03:08 PM, Ingo Molnar wrote:
I mean, i can trust a kernel service and i can trust /proc/kallsyms.
Can perf trust a random process claiming to be Qemu? What's the trust
mechanism here?
Obviously you can't trust anything you get from a
On 03/16/2010 07:45 AM, Avi Kivity wrote:
On 03/16/2010 12:53 PM, Yoshiaki Tamura wrote:
Modifies wrapper functions for byte-based phys_ram_dirty bitmap to
bit-based phys_ram_dirty bitmap, and adds more wrapper functions to
prevent
direct access to the phys_ram_dirty bitmap.
+
+static
On 03/16/2010 03:31 PM, Ingo Molnar wrote:
You can do that through libvirt, but that only works for guests started
through libvirt. libvirt provides command-line tools to list and manage
guests (for example autostarting them on startup), and tools built on top of
libvirt can manage guests
Avi Kivity wrote:
On 03/16/2010 12:53 PM, Yoshiaki Tamura wrote:
Experimental results:
Cond1: 1.9 ~ 61 times speed up
Cond2: 1.9 ~ 56 times speed up
Cond3: 1.9 ~ 59 times speed up
Cond4: 1.7 ~ 59 times speed up
Impressive results. What's the typical speedup? Closer to 1.9 or 61?
To be
Avi Kivity wrote:
On 03/16/2010 03:17 PM, Yoshiaki Tamura wrote:
Avi Kivity wrote:
On 03/16/2010 12:53 PM, Yoshiaki Tamura wrote:
Modifies wrapper functions for byte-based phys_ram_dirty bitmap to
bit-based phys_ram_dirty bitmap, and adds more wrapper functions to
prevent
direct access to the
On 03/16/2010 08:29 AM, Avi Kivity wrote:
On 03/16/2010 03:17 PM, Yoshiaki Tamura wrote:
Avi Kivity wrote:
On 03/16/2010 12:53 PM, Yoshiaki Tamura wrote:
Modifies wrapper functions for byte-based phys_ram_dirty bitmap to
bit-based phys_ram_dirty bitmap, and adds more wrapper functions to
On 03/16/2010 03:51 PM, Anthony Liguori wrote:
On 03/16/2010 08:29 AM, Avi Kivity wrote:
On 03/16/2010 03:17 PM, Yoshiaki Tamura wrote:
Avi Kivity wrote:
On 03/16/2010 12:53 PM, Yoshiaki Tamura wrote:
Modifies wrapper functions for byte-based phys_ram_dirty bitmap to
bit-based phys_ram_dirty
* Avi Kivity a...@redhat.com [2010-03-16 13:08:28]:
On 03/16/2010 12:44 PM, Christoph Hellwig wrote:
On Tue, Mar 16, 2010 at 12:36:31PM +0200, Avi Kivity wrote:
Are you talking about direct volume access or qcow2?
Doesn't matter.
For direct volume access, I still don't get it. The number
On 03/16/2010 08:57 AM, Avi Kivity wrote:
On 03/16/2010 03:51 PM, Anthony Liguori wrote:
On 03/16/2010 08:29 AM, Avi Kivity wrote:
On 03/16/2010 03:17 PM, Yoshiaki Tamura wrote:
Avi Kivity wrote:
On 03/16/2010 12:53 PM, Yoshiaki Tamura wrote:
Modifies wrapper functions for byte-based
KVM module:
modinfo kvm :
filename: /lib/modules/2.6.33-30-default/kernel/arch/x86/kvm/kvm.ko
license:GPL
author: Qumranet
srcversion: 611CD56E712705875D0E7BB
depends:
vermagic: 2.6.33-30-default SMP mod_unload modversions
parm: oos_shadow:bool
parm:
On 03/16/2010 05:45 AM, Daniel P. Berrange wrote:
On Tue, Mar 16, 2010 at 12:38:02PM +0200, Avi Kivity wrote:
On 03/16/2010 12:31 PM, Daniel P. Berrange wrote:
Polling loops are an indication that something is wrong.
Except when people suggest they are the right answer,
Ingo Molnar mi...@elte.hu writes:
[...]
I.e. we really want to be able users to:
1) have it all working with a single guest, without having to specify
'which'
guest (qemu PID) to work with. That is the dominant usecase both for
developers and for a fair portion of testers.
On Tue, Mar 16, 2010 at 10:05:40AM -0500, Anthony Liguori wrote:
On 03/16/2010 05:45 AM, Daniel P. Berrange wrote:
On Tue, Mar 16, 2010 at 12:38:02PM +0200, Avi Kivity wrote:
On 03/16/2010 12:31 PM, Daniel P. Berrange wrote:
Polling loops are an indication that something is wrong.
PS: It just occurred to me , that it does indeed freeze and cause a
100% CPU usage. At least i can say for sure that network, serial line,
keyboard, nor mouse work. If loadvm is loaded from the command line.
If loaded from the monitor, everything seams to work, except the
mouse. After a
On 03/16/2010 10:23 AM, Daniel P. Berrange wrote:
In the context of the RHEV management application, iSCSI/SCSI Fibre are
providing the raw storage, with LVM VGs on top and the carving LVs for
the guests. In the common case the admin/app would monitor VG usage LV
rate of increase to ensure
* Frank Ch. Eigler f...@redhat.com wrote:
Ingo Molnar mi...@elte.hu writes:
[...]
I.e. we really want to be able users to:
1) have it all working with a single guest, without having to specify
'which'
guest (qemu PID) to work with. That is the dominant usecase both for
On 03/16/2010 04:27 PM, Balbir Singh wrote:
Let's assume the guest has virtio (I agree with IDE we need
reordering on the host). The guest sends batches of I/O separated
by cache flushes. If the batches are smaller than the virtio queue
length, ideally things look like:
io_submit(...,
Hi -
On Tue, Mar 16, 2010 at 04:52:21PM +0100, Ingo Molnar wrote:
[...]
Perhaps the fact that kvm happens to deal with an interesting application
area (virtualization) is misleading here. As far as the host kernel or
other host userspace is concerned, qemu is just some random
Avi Kivity avi at redhat.com writes:
On 03/16/2010 02:20 AM, Jason wrote:
In comparing KVM 2.6.31.6b to XenServer 5.5.0, it seems KVM has fewer
overall
VMREADs and VMWRITEs, but there are a lot of VMWRITEs to Host FS_SEL, Host
GS_SEL, Host FS_BASE, and Host GS_BASE that don't appear
* Frank Ch. Eigler f...@redhat.com wrote:
Hi -
On Tue, Mar 16, 2010 at 04:52:21PM +0100, Ingo Molnar wrote:
[...]
Perhaps the fact that kvm happens to deal with an interesting application
area (virtualization) is misleading here. As far as the host kernel or
other host
On 03/16/2010 06:33 PM, Jason wrote:
Avi Kivityaviat redhat.com writes:
On 03/16/2010 02:20 AM, Jason wrote:
In comparing KVM 2.6.31.6b to XenServer 5.5.0, it seems KVM has fewer overall
VMREADs and VMWRITEs, but there are a lot of VMWRITEs to Host FS_SEL, Host
GS_SEL, Host
On 03/16/2010 08:08 AM, Ingo Molnar wrote:
* Avi Kivitya...@redhat.com wrote:
On 03/16/2010 02:29 PM, Ingo Molnar wrote:
I mean, i can trust a kernel service and i can trust /proc/kallsyms.
Can perf trust a random process claiming to be Qemu? What's the trust
mechanism here?
On 03/16/2010 10:52 AM, Ingo Molnar wrote:
You are quite mistaken: KVM isnt really a 'random unprivileged application' in
this context, it is clearly an extension of system/kernel services.
( Which can be seen from the simple fact that what started the discussion was
'how do we get
* Anthony Liguori anth...@codemonkey.ws wrote:
On 03/16/2010 08:08 AM, Ingo Molnar wrote:
* Avi Kivitya...@redhat.com wrote:
On 03/16/2010 02:29 PM, Ingo Molnar wrote:
I mean, i can trust a kernel service and i can trust /proc/kallsyms.
Can perf trust a random process claiming to be
* Anthony Liguori aligu...@linux.vnet.ibm.com wrote:
On 03/16/2010 10:52 AM, Ingo Molnar wrote:
You are quite mistaken: KVM isnt really a 'random unprivileged application'
in
this context, it is clearly an extension of system/kernel services.
( Which can be seen from the simple fact that
On Mon, Mar 15, 2010 at 01:59:52PM +0200, Avi Kivity wrote:
Currently when we emulate a locked operation into a shadowed guest page
table, we perform a write rather than a true atomic. This is indicated
by the emulating exchange as write message that shows up in dmesg.
In addition, the pte
On 03/16/2010 12:52 PM, Ingo Molnar wrote:
* Anthony Liguorialigu...@linux.vnet.ibm.com wrote:
On 03/16/2010 10:52 AM, Ingo Molnar wrote:
You are quite mistaken: KVM isnt really a 'random unprivileged application' in
this context, it is clearly an extension of system/kernel
Hi!
I'm running kvm / qemu-kvm on a couple of production servers everything (or at
least most things) works as it should.
However today someone thought it was a good idea to restart one of the
servers and after that the windows 2k3 guest on that server don't boot anymore.
kvm on this server is
On 16.03.2010, at 17:36, Marcelo Tosatti wrote:
On Mon, Mar 15, 2010 at 01:59:52PM +0200, Avi Kivity wrote:
Currently when we emulate a locked operation into a shadowed guest page
table, we perform a write rather than a true atomic. This is indicated
by the emulating exchange as write
* Anthony Liguori aligu...@linux.vnet.ibm.com wrote:
On 03/16/2010 12:52 PM, Ingo Molnar wrote:
* Anthony Liguorialigu...@linux.vnet.ibm.com wrote:
On 03/16/2010 10:52 AM, Ingo Molnar wrote:
You are quite mistaken: KVM isnt really a 'random unprivileged
application' in
this context, it
On Tue, Mar 16, 2010 at 07:22:55PM +0100, Alexander Graf wrote:
On 16.03.2010, at 17:36, Marcelo Tosatti wrote:
On Mon, Mar 15, 2010 at 01:59:52PM +0200, Avi Kivity wrote:
Currently when we emulate a locked operation into a shadowed guest page
table, we perform a write rather than a
Bugs item #2971166, was opened at 2010-03-16 05:32
Message generated for change (Comment added) made by jimatjtan
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=893831aid=2971166group_id=180599
Please note that this message will contain a full copy of the comment
On 3/16/10, Anthony Liguori anth...@codemonkey.ws wrote:
On 03/16/2010 08:57 AM, Avi Kivity wrote:
On 03/16/2010 03:51 PM, Anthony Liguori wrote:
On 03/16/2010 08:29 AM, Avi Kivity wrote:
On 03/16/2010 03:17 PM, Yoshiaki Tamura wrote:
Avi Kivity wrote:
On
On Tue, Mar 16, 2010 at 12:25:00PM +0100, Ingo Molnar wrote:
Hm, that sounds rather messy if we want to use it to basically expose kernel
functionality in a guest/host unified way. Is the qemu process discoverable
in
some secure way? Can we trust it? Is there some proper tooling available
On 03/16/2010 01:10 PM, Blue Swirl wrote:
Just a tangential note: a long time ago, I tried to disable self
modifying code detection for Sparc. On most RISC architectures, SMC
needs explicit flushing so in theory we need not track code memory
writes. However, during exceptions the translator
Anthony Liguori wrote:
On 03/16/2010 07:45 AM, Avi Kivity wrote:
On 03/16/2010 12:53 PM, Yoshiaki Tamura wrote:
Modifies wrapper functions for byte-based phys_ram_dirty bitmap to
bit-based phys_ram_dirty bitmap, and adds more wrapper functions to
prevent
direct access to the phys_ram_dirty
1 - 100 of 119 matches
Mail list logo
