On 05/30/2017 12:48 AM, Paolo Bonzini wrote:
On 23/05/2017 04:23, Xiao Guangrong wrote:
Ping...
Sorry to disturb, just make this patchset not be missed. :)
It won't. :) I'm going to look at it and the dirty page ring buffer
this week.
Ping.. :)
On 05/30/2017 12:48 AM, Paolo Bonzini wrote:
On 23/05/2017 04:23, Xiao Guangrong wrote:
Ping...
Sorry to disturb, just make this patchset not be missed. :)
It won't. :) I'm going to look at it and the dirty page ring buffer
this week.
Ping.. :)
On 06/05/2017 03:36 PM, Jay Zhou wrote:
/* enable ucontrol for s390 */
struct kvm_s390_ucas_mapping {
diff --git a/memory.c b/memory.c
index 4c95aaf..b836675 100644
--- a/memory.c
+++ b/memory.c
@@ -809,6 +809,13 @@ static void address_space_update_ioeventfds(AddressSpace
*as)
On 06/05/2017 03:36 PM, Jay Zhou wrote:
/* enable ucontrol for s390 */
struct kvm_s390_ucas_mapping {
diff --git a/memory.c b/memory.c
index 4c95aaf..b836675 100644
--- a/memory.c
+++ b/memory.c
@@ -809,6 +809,13 @@ static void address_space_update_ioeventfds(AddressSpace
*as)
On 2017/5/3 18:52, guangrong.x...@gmail.com wrote:
From: Xiao Guangrong
Background
==
The original idea of this patchset is from Avi who raised it in
the mailing list during my vMMU development some years ago
This patchset introduces a extremely fast way to
On 2017/5/3 18:52, guangrong.x...@gmail.com wrote:
From: Xiao Guangrong
Background
==
The original idea of this patchset is from Avi who raised it in
the mailing list during my vMMU development some years ago
This patchset introduces a extremely fast way to write protect
all the guest
On 23/05/2017 04:23, Xiao Guangrong wrote:
>
> Ping...
>
> Sorry to disturb, just make this patchset not be missed. :)
It won't. :) I'm going to look at it and the dirty page ring buffer
this week.
Paolo
On 23/05/2017 04:23, Xiao Guangrong wrote:
>
> Ping...
>
> Sorry to disturb, just make this patchset not be missed. :)
It won't. :) I'm going to look at it and the dirty page ring buffer
this week.
Paolo
Ping...
Sorry to disturb, just make this patchset not be missed. :)
On 05/04/2017 03:06 PM, Paolo Bonzini wrote:
On 04/05/2017 05:36, Xiao Guangrong wrote:
Great.
As there is no conflict between these two patchsets except dirty
ring pages takes benefit from write-protect-all, i think they
Ping...
Sorry to disturb, just make this patchset not be missed. :)
On 05/04/2017 03:06 PM, Paolo Bonzini wrote:
On 04/05/2017 05:36, Xiao Guangrong wrote:
Great.
As there is no conflict between these two patchsets except dirty
ring pages takes benefit from write-protect-all, i think they
On 04/05/2017 05:36, Xiao Guangrong wrote:
> Great.
>
> As there is no conflict between these two patchsets except dirty
> ring pages takes benefit from write-protect-all, i think they
> can be developed and iterated independently, right?
I can certainly start reviewing this one.
Paolo
> Or
On 04/05/2017 05:36, Xiao Guangrong wrote:
> Great.
>
> As there is no conflict between these two patchsets except dirty
> ring pages takes benefit from write-protect-all, i think they
> can be developed and iterated independently, right?
I can certainly start reviewing this one.
Paolo
> Or
On 05/03/2017 10:57 PM, Paolo Bonzini wrote:
On 03/05/2017 16:50, Xiao Guangrong wrote:
Furthermore, userspace has no knowledge about if PML is enable (it
can be required from sysfs, but it is a good way in QEMU), so it is
difficult for the usespace to know when to use write-protect-all.
On 05/03/2017 10:57 PM, Paolo Bonzini wrote:
On 03/05/2017 16:50, Xiao Guangrong wrote:
Furthermore, userspace has no knowledge about if PML is enable (it
can be required from sysfs, but it is a good way in QEMU), so it is
difficult for the usespace to know when to use write-protect-all.
On 03/05/2017 16:50, Xiao Guangrong wrote:
> Furthermore, userspace has no knowledge about if PML is enable (it
> can be required from sysfs, but it is a good way in QEMU), so it is
> difficult for the usespace to know when to use write-protect-all.
> Maybe we can make
On 03/05/2017 16:50, Xiao Guangrong wrote:
> Furthermore, userspace has no knowledge about if PML is enable (it
> can be required from sysfs, but it is a good way in QEMU), so it is
> difficult for the usespace to know when to use write-protect-all.
> Maybe we can make
On 05/03/2017 08:28 PM, Paolo Bonzini wrote:
So if I understand correctly this relies on userspace doing:
1) KVM_GET_DIRTY_LOG without write protect
2) KVM_WRITE_PROTECT_ALL_MEM
Writes may happen between 1 and 2; they are not represented in the live
dirty bitmap but
On 05/03/2017 08:28 PM, Paolo Bonzini wrote:
So if I understand correctly this relies on userspace doing:
1) KVM_GET_DIRTY_LOG without write protect
2) KVM_WRITE_PROTECT_ALL_MEM
Writes may happen between 1 and 2; they are not represented in the live
dirty bitmap but
So if I understand correctly this relies on userspace doing:
1) KVM_GET_DIRTY_LOG without write protect
2) KVM_WRITE_PROTECT_ALL_MEM
Writes may happen between 1 and 2; they are not represented in the live
dirty bitmap but it's okay because they are in the snapshot and
So if I understand correctly this relies on userspace doing:
1) KVM_GET_DIRTY_LOG without write protect
2) KVM_WRITE_PROTECT_ALL_MEM
Writes may happen between 1 and 2; they are not represented in the live
dirty bitmap but it's okay because they are in the snapshot and
From: Xiao Guangrong
Background
==
The original idea of this patchset is from Avi who raised it in
the mailing list during my vMMU development some years ago
This patchset introduces a extremely fast way to write protect
all the guest memory. Comparing with
From: Xiao Guangrong
Background
==
The original idea of this patchset is from Avi who raised it in
the mailing list during my vMMU development some years ago
This patchset introduces a extremely fast way to write protect
all the guest memory. Comparing with the ordinary algorithm which
22 matches
Mail list logo