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 */
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
23 matches
Mail list logo