Replaces direct phys_ram_dirty access with wrapper functions to prevent
direct access to the phys_ram_dirty bitmap.
Signed-off-by: Yoshiaki Tamura
Signed-off-by: OHMURA Kei
---
exec.c | 45 -
1 files changed, 20 insertions(+), 25 deletions(-)
diff
Adds wrapper functions to prevent direct access to the phys_ram_dirty bitmap.
Signed-off-by: Yoshiaki Tamura
Signed-off-by: OHMURA Kei
---
cpu-all.h | 25 +
1 files changed, 25 insertions(+), 0 deletions(-)
diff --git a/cpu-all.h b/cpu-all.h
index 9bc01b9..c279c0a 100
Before replacing byte-based dirty bitmap with bit-based dirty bitmap,
clearing direct accesses to the bitmap first seems to be good point to
start with.
This patch set is based on the following discussion.
http://www.mail-archive.com/kvm@vger.kernel.org/msg30724.html
Thanks,
Yoshi
--
To unsubs
Hi all
Does anybody know exact important date, such as paper deadline
for KVM Forum 2010?
I can find this
blog(http://www.linux-kvm.com/content/kvm-forum-2010-scheduled-august-9-10-2010)
but the blog only say about the date of the conference.
Regards,
Kazushi Takahashi
--
To unsubscribe from th
Takuya Yoshikawa wrote:
> Xiao Guangrong wrote:
>> Using bitmap_empty() to see whether memslot->dirty_bitmap is empty
>>
>
> You can do this for arch specific get_dirty_log() too.
OK, i'll do it in the next version
>
>> Signed-off-by: Xiao Guangrong
>> ---
>> virt/kvm/kvm_main.c |6 ++--
Xiao Guangrong wrote:
Using bitmap_empty() to see whether memslot->dirty_bitmap is empty
You can do this for arch specific get_dirty_log() too.
Signed-off-by: Xiao Guangrong
---
virt/kvm/kvm_main.c |6 ++
1 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/virt/kvm/kvm_m
On 03/16/2010 10:10 PM, Blue Swirl wrote:
Yes, and is what tlb_protect_code() does and it's called from
tb_alloc_page() which is what's code when a TB is created.
Just a tangential note: a long time ago, I tried to disable self
modifying code detection for Sparc. On most RISC architect
On 03/16/2010 09:33 PM, Marcelo Tosatti wrote:
How relevant is this for -stable? Races don't sound good to me :)
The race mentioned above is not existant on -stable since prefetch is
disabled for invlpg.
The atomic fixes seem like a candidate, since lack of them can trigger
pagetable co
On 03/17/2010 02:41 AM, Frank Ch. Eigler wrote:
Hi -
On Tue, Mar 16, 2010 at 06:04:10PM -0500, Anthony Liguori wrote:
[...]
The only way to really address this is to change the interaction.
Instead of running perf externally to qemu, we should support a perf
command in the qemu monitor that
Using bitmap_empty() to see whether memslot->dirty_bitmap is empty
Signed-off-by: Xiao Guangrong
---
virt/kvm/kvm_main.c |6 ++
1 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index bcd08b8..497ae14 100644
--- a/virt/kvm/kvm_main.c
- The RSV bit is possibility set in error code when #PF occurred
only if CR4.PSE=1 or CR4.PAE=1
- context->rsvd_bits_mask[1][0] is always 0
Changlog:
Move this operation to reset_rsvds_bits_mask() address Avi Kivity's suggestion
Signed-off-by: Xiao Guangrong
---
arch/x86/kvm/mmu.c | 12 +
On Tue, 2010-03-16 at 11:32 +0200, Avi Kivity wrote:
> 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
David Miller wrote:
> From: "Hao, Xudong"
> Date: Wed, 17 Mar 2010 10:14:50 +0800
>
>> I installed a latest kvm based on kernel 2.6.34-rc1, after I load
>> kvm kvm_i= ntel module, and start /etc/init.d/kvm, a few minutes
>> later, the system wil= l panic. The panic is easy to reproduce when
>> I
From: "Hao, Xudong"
Date: Wed, 17 Mar 2010 10:14:50 +0800
> I installed a latest kvm based on kernel 2.6.34-rc1, after I load kvm kvm_i=
> ntel module, and start /etc/init.d/kvm, a few minutes later, the system wil=
> l panic. The panic is easy to reproduce when I use tcpdump in host.
> However,
Hi -
On Tue, Mar 16, 2010 at 06:04:10PM -0500, Anthony Liguori wrote:
> [...]
> The only way to really address this is to change the interaction.
> Instead of running perf externally to qemu, we should support a perf
> command in the qemu monitor that can then tie directly to the perf
> toolin
> Where does the translator need access to this original code? I was
> just thinking about this problem today, wondering how much overhead
> there is with this SMC page protection thing.
When an MMU fault occurs qemu re-translates the TB with additional annotations
to determine which guest instr
On 03/16/2010 12:39 PM, Ingo Molnar wrote:
If we look at the use-case, it's going to be something like, a user is
creating virtual machines and wants to get performance information about
them.
Having to run a separate tool like perf is not going to be what they would
expect they had to do. Inst
On 03/16/2010 01:28 PM, Ingo Molnar wrote:
* Anthony Liguori wrote:
On 03/16/2010 12:52 PM, Ingo Molnar wrote:
* Anthony Liguori wrote:
On 03/16/2010 10:52 AM, Ingo Molnar wrote:
You are quite mistaken: KVM isnt really a 'random unprivileged application' in
th
oerg Roedel wrote:
> 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 som
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 bitm
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
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 availabl
On 3/16/10, Anthony Liguori 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:
> > > > >
> > > >
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=detail&atid=893831&aid=2971166&group_id=180599
Please note that this message will contain a full copy of the comment
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
* Anthony Liguori wrote:
> On 03/16/2010 12:52 PM, Ingo Molnar wrote:
> >* Anthony Liguori 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/
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 writ
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 i
On 03/16/2010 12:52 PM, Ingo Molnar wrote:
* Anthony Liguori 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
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, th
* Anthony Liguori 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 what started the
* Anthony Liguori wrote:
> On 03/16/2010 08:08 AM, Ingo Molnar wrote:
> >* Avi Kivity 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 tr
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 /proc/kall
On 03/16/2010 08:08 AM, Ingo Molnar wrote:
* Avi Kivity 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?
Obviousl
On 03/16/2010 06:33 PM, Jason wrote:
Avi Kivity 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, an
* Frank Ch. Eigler 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 userspace
Avi Kivity 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
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 unpr
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(..., batc
* Frank Ch. Eigler wrote:
>
> Ingo Molnar 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 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 extr
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 -loadv
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 somet
Ingo Molnar 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 test
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, qc
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 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 phys_ra
* Avi Kivity [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 of
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
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
preve
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
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 honest
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 grap
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 inlin
* Avi Kivity 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
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 bitm
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 cpu_physical_memory_
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.
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 ca
* Avi Kivity 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 a gue
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 t
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 Tamura
Signed-off-by: OHMURA Kei
---
exec.c | 22 +-
1
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 c
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
>
> >+MK_INSN(xchg_test1, "xchg %eax,%eax\n\t");
>
> AKA 'nop'.
>
Yep, but we still emulate it.
--
On 03/16/2010 02:42 PM, Gleb Natapov wrote:
Add test for opcodes 0x90-0x9f emulation
Reviewed-by: Avi Kivity
+ MK_INSN(xchg_test1, "xchg %eax,%eax\n\t");
AKA 'nop'.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the li
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 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 cpu_physical_memory_get_dirty_flags
Add test for opcodes 0x90-0x9f emulation
Signed-off-by: Gleb Natapov
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 regs_equal(const struct regs *
On 03/16/2010 02:29 PM, Ingo Molnar wrote:
* Avi Kivity 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 qem
* Avi Kivity 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 want
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 Tamura
Signed-off-by: OHMURA Kei
---
exec.c | 22 +-
1 files change
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 ker
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
> ---
>
> Michael,
>
* Avi Kivity 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 and
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, qc
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 pur
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 equal
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
Signed-off-by: OHMURA Kei
---
qemu-kvm.c | 19 ++-
1 files changed, 6 insertions(+), 13 deleti
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
Signed-off-by: OHMURA Kei
---
exec.c | 22 +-
1 files changed, 17 insertions(+), 5 deletions(-)
diff --git
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
Signed-off-by: OHMURA Kei
---
vl.c | 55 +++
1 files changed
Replaces direct phys_ram_dirty access with wrapper functions to prevent
direct access to the phys_ram_dirty bitmap.
Signed-off-by: Yoshiaki Tamura
Signed-off-by: OHMURA Kei
---
exec.c | 45 -
1 files changed, 20 insertions(+), 25 deletions(-)
diff
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
Signed-off-by: OHMURA Kei
---
cpu-all.h | 94 ++
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
Signed-off-by: OHMURA Kei
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
cpu_phys
* Avi Kivity 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
> >>>
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 su
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
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 sug
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.
That
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 commi
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 ca
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 Wright wrote:
> >>
> >>>Please send in any agenda items you are interested in covering.
> >>>
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 ho
* Avi Kivity wrote:
> On 03/16/2010 11:53 AM, Ingo Molnar wrote:
> >* Avi Kivity wrote:
> >
> >>On 03/16/2010 09:24 AM, Ingo Molnar wrote:
> >>>* Avi Kivity wrote:
> >>>
> On 03/16/2010 07:27 AM, Zhang, Yanmin wrote:
> >From: Zhang, Yanmin
> >
> >Based on the discussion in KVM
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
w
On 03/16/2010 11:53 AM, Ingo Molnar wrote:
* Avi Kivity wrote:
On 03/16/2010 09:24 AM, Ingo Molnar wrote:
* Avi Kivity wrote:
On 03/16/2010 07:27 AM, Zhang, Yanmin wrote:
From: Zhang, Yanmin
Based on the discussion in KVM community, I worked out the patch to
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 wrote:
> > > Please send in any agenda items you are interested in covering.
> >
> > Migration:
> > - flexible migration: I hope to sent an RFC pa
Am 16.03.2010 10:17, schrieb Avi Kivity:
> On 03/15/2010 10:23 PM, Chris Webb wrote:
>> Avi Kivity 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?
>>
* Avi Kivity wrote:
> On 03/16/2010 09:24 AM, Ingo Molnar wrote:
> >* Avi Kivity wrote:
> >
> >>On 03/16/2010 07:27 AM, Zhang, Yanmin wrote:
> >>>From: Zhang, Yanmin
> >>>
> >>>Based on the discussion in KVM community, I worked out the patch to support
> >>>perf to collect guest os statistics f
* Zhang, Yanmin 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, Yanmin
> > > >
> > > > Based on the discussion in KVM community, I worked out the patc
1 - 100 of 117 matches
Mail list logo
