On 04/23/2010 08:29 AM, Alexander Graf wrote:
On 22.04.2010, at 08:09, Fernando Luis Vázquez Cao wrote:
On 04/22/2010 11:45 AM, Fernando Luis Vázquez Cao wrote:
On 04/21/2010 06:41 PM, Alexander Graf wrote:
On 21.04.2010, at 10:29, Fernando Luis Vázquez Cao wrote:
On 04/20/2010 08:03 PM,
On 23.04.2010, at 12:17, Fernando Luis Vázquez Cao wrote:
On 04/23/2010 08:29 AM, Alexander Graf wrote:
On 22.04.2010, at 08:09, Fernando Luis Vázquez Cao wrote:
On 04/22/2010 11:45 AM, Fernando Luis Vázquez Cao wrote:
On 04/21/2010 06:41 PM, Alexander Graf wrote:
On 21.04.2010, at
On 04/23/2010 01:20 PM, Alexander Graf wrote:
I would say the reason is that if we did not convert the user-space pointer to
a void * kvm_get_dirty_log() would end up copying the dirty log to
(log-dirty_bitmap 32) | 0x
Well yes, that was the problem. If we always set the __u64
On 04/22/2010 12:34 PM, Takuya Yoshikawa wrote:
Thanks, I can know basic rules about kvm/api .
(2010/04/21 20:46), Avi Kivity wrote:
+Type: vm ioctl
+Parameters: struct kvm_dirty_log (in/out)
+Returns: 0 on success, -1 on error
+
+/* for KVM_SWITCH_DIRTY_LOG */
+struct kvm_dirty_log {
+
On 23.04.2010, at 13:57, Avi Kivity wrote:
On 04/23/2010 01:20 PM, Alexander Graf wrote:
I would say the reason is that if we did not convert the user-space pointer
to
a void * kvm_get_dirty_log() would end up copying the dirty log to
(log-dirty_bitmap 32) | 0x
Well
On Friday 23 April 2010, Avi Kivity wrote:
On 04/23/2010 01:20 PM, Alexander Graf wrote:
I would say the reason is that if we did not convert the user-space
pointer to
a void * kvm_get_dirty_log() would end up copying the dirty log to
(log-dirty_bitmap 32) | 0x
On 04/23/2010 03:27 PM, Arnd Bergmann wrote:
Using a 64-bit integer avoids the problem (though perhaps not sufficient
for s390, Arnd?)
When there is only a __u64 for the address, it will work on s390 as well,
gcc is smart enough to clear the upper bit on a cast from long to pointer.
On Friday 23 April 2010, Avi Kivity wrote:
On 04/23/2010 03:27 PM, Arnd Bergmann wrote:
Using a 64-bit integer avoids the problem (though perhaps not sufficient
for s390, Arnd?)
When there is only a __u64 for the address, it will work on s390 as well,
gcc is smart enough to
On 04/23/2010 03:46 PM, Arnd Bergmann wrote:
On Friday 23 April 2010, Avi Kivity wrote:
On 04/23/2010 03:27 PM, Arnd Bergmann wrote:
Using a 64-bit integer avoids the problem (though perhaps not sufficient
for s390, Arnd?)
When there is only a __u64 for the
On 23.04.2010, at 14:53, Avi Kivity wrote:
On 04/23/2010 03:46 PM, Arnd Bergmann wrote:
On Friday 23 April 2010, Avi Kivity wrote:
On 04/23/2010 03:27 PM, Arnd Bergmann wrote:
Using a 64-bit integer avoids the problem (though perhaps not sufficient
for s390, Arnd?)
On Friday 23 April 2010, Avi Kivity wrote:
Ah so the 31st bit is optional as far as userspace is concerned? What
does it mean? (just curious)
On data pointers it's ignored. When you branch to a function, this bit
determines whether the target function is run in 24 or 31 bit mode.
This allows
On 04/23/2010 03:59 PM, Alexander Graf wrote:
Ah so the 31st bit is optional as far as userspace is concerned? What does it
mean? (just curious)
The 0x8000 bit declares that a pointer is in 24-bit mode, so that
applications can use the spare upper bits for random data.
See
On 04/22/2010 11:45 AM, Fernando Luis Vázquez Cao wrote:
On 04/21/2010 06:41 PM, Alexander Graf wrote:
On 21.04.2010, at 10:29, Fernando Luis Vázquez Cao wrote:
On 04/20/2010 08:03 PM, Takuya Yoshikawa wrote:
@@ -318,7 +318,7 @@ struct kvm_dirty_log {
__u32 padding1;
union {
Thanks, I can know basic rules about kvm/api .
(2010/04/21 20:46), Avi Kivity wrote:
+Type: vm ioctl
+Parameters: struct kvm_dirty_log (in/out)
+Returns: 0 on success, -1 on error
+
+/* for KVM_SWITCH_DIRTY_LOG */
+struct kvm_dirty_log {
+ __u32 slot;
+ __u32 padding;
Please put a flags
On 22.04.2010, at 08:09, Fernando Luis Vázquez Cao wrote:
On 04/22/2010 11:45 AM, Fernando Luis Vázquez Cao wrote:
On 04/21/2010 06:41 PM, Alexander Graf wrote:
On 21.04.2010, at 10:29, Fernando Luis Vázquez Cao wrote:
On 04/20/2010 08:03 PM, Takuya Yoshikawa wrote:
@@ -318,7 +318,7 @@
On 04/20/2010 08:03 PM, Takuya Yoshikawa wrote:
@@ -318,7 +318,7 @@ struct kvm_dirty_log {
__u32 padding1;
union {
void __user *dirty_bitmap; /* one bit per page */
- __u64 padding2;
+ __u64 addr;
This can break on x86_32 and x86_64-compat.
On 21.04.2010, at 10:29, Fernando Luis Vázquez Cao wrote:
On 04/20/2010 08:03 PM, Takuya Yoshikawa wrote:
@@ -318,7 +318,7 @@ struct kvm_dirty_log {
__u32 padding1;
union {
void __user *dirty_bitmap; /* one bit per page */
-__u64 padding2;
+
On 04/20/2010 02:03 PM, Takuya Yoshikawa wrote:
We can now export the addree of the bitmap created by do_mmap()
to user space. For the sake of this, we introduce a new API:
KVM_SWITCH_DIRTY_LOG: application can use this to trigger the
switch of the bitmaps and get the address of the
On 04/21/2010 06:41 PM, Alexander Graf wrote:
On 21.04.2010, at 10:29, Fernando Luis Vázquez Cao wrote:
On 04/20/2010 08:03 PM, Takuya Yoshikawa wrote:
@@ -318,7 +318,7 @@ struct kvm_dirty_log {
__u32 padding1;
union {
void __user *dirty_bitmap; /* one bit per page */
We can now export the addree of the bitmap created by do_mmap()
to user space. For the sake of this, we introduce a new API:
KVM_SWITCH_DIRTY_LOG: application can use this to trigger the
switch of the bitmaps and get the address of the bitmap which
has been used until now. This reduces the
On 20.04.2010, at 13:03, Takuya Yoshikawa wrote:
We can now export the addree of the bitmap created by do_mmap()
to user space. For the sake of this, we introduce a new API:
KVM_SWITCH_DIRTY_LOG: application can use this to trigger the
switch of the bitmaps and get the address of the
(2010/04/20 20:15), Alexander Graf wrote:
On 20.04.2010, at 13:03, Takuya Yoshikawa wrote:
We can now export the addree of the bitmap created by do_mmap()
to user space. For the sake of this, we introduce a new API:
KVM_SWITCH_DIRTY_LOG: application can use this to trigger the
switch of
On 20.04.2010, at 13:33, Takuya Yoshikawa wrote:
(2010/04/20 20:15), Alexander Graf wrote:
On 20.04.2010, at 13:03, Takuya Yoshikawa wrote:
We can now export the addree of the bitmap created by do_mmap()
to user space. For the sake of this, we introduce a new API:
(2010/04/20 20:33), Alexander Graf wrote:
-#define KVM_API_VERSION 12
+#define KVM_API_VERSION 13
Is there a way to keep both interfaces around for some time at least? I'd
prefer the API version not to change if not _really_ necessary.
To enable the new dirty mapping you could for example
24 matches
Mail list logo
