Re: [PATCH 3/3] KVM: Add documents for MSI-X MMIO API
On 01/26/2011 11:05 AM, Sheng Yang wrote: On Tuesday 25 January 2011 20:47:38 Avi Kivity wrote: On 01/19/2011 10:21 AM, Sheng Yang wrote: We already got an guest MMIO address for that in the exit information. I've created a chain of handler in qemu to handle it. But we already decoded the table and entry... But the handler is still wrapped by vcpu_mmio_write(), as a part of MMIO. So it's not quite handy to get the table and entry out. The kernel handler can create a new kvm_run exit description. Also the updater in the userspace can share the most logic with ordinary userspace MMIO handler, which take address as parameter. So I think we don't need to pass the decoded table_id and entry to userspace. It's mixing layers, which always leads to trouble. For one, the user handler shouldn't do anything with the write since the kernel already wrote it into the table. For another, if two vcpus write to the same entry simultaneously, you could see different ordering in the kernel and userspace, and get inconsistent results. The shared logic is not about writing, but about interpret what's written. Old MMIO handler would write the data, then interpret it; and our new MMIO would only share the logic of interpretation. I think that's fair enough? It dosn't make sense for an API point of view. You registered a table of entries, you expect an exit on that table to point to the table and entry that got changed. -- error compiling committee.c: too many arguments to function -- 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
Re: [PATCH 3/3] KVM: Add documents for MSI-X MMIO API
On Mon, Jan 31, 2011 at 03:24:27PM +0200, Avi Kivity wrote: On 01/26/2011 11:05 AM, Sheng Yang wrote: On Tuesday 25 January 2011 20:47:38 Avi Kivity wrote: On 01/19/2011 10:21 AM, Sheng Yang wrote: We already got an guest MMIO address for that in the exit information. I've created a chain of handler in qemu to handle it. But we already decoded the table and entry... But the handler is still wrapped by vcpu_mmio_write(), as a part of MMIO. So it's not quite handy to get the table and entry out. The kernel handler can create a new kvm_run exit description. Also the updater in the userspace can share the most logic with ordinary userspace MMIO handler, which take address as parameter. So I think we don't need to pass the decoded table_id and entry to userspace. It's mixing layers, which always leads to trouble. For one, the user handler shouldn't do anything with the write since the kernel already wrote it into the table. For another, if two vcpus write to the same entry simultaneously, you could see different ordering in the kernel and userspace, and get inconsistent results. The shared logic is not about writing, but about interpret what's written. Old MMIO handler would write the data, then interpret it; and our new MMIO would only share the logic of interpretation. I think that's fair enough? It dosn't make sense for an API point of view. You registered a table of entries, you expect an exit on that table to point to the table and entry that got changed. OK, I would update this when I come back to work(about two weeks later...). -- regards Yang, Sheng -- error compiling committee.c: too many arguments to function -- 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
[PATCH 3/3] KVM: Add documents for MSI-X MMIO API
Signed-off-by: Sheng Yang sh...@linux.intel.com
---
Documentation/kvm/api.txt | 47 +
1 files changed, 47 insertions(+), 0 deletions(-)
diff --git a/Documentation/kvm/api.txt b/Documentation/kvm/api.txt
index e1a9297..e6b7a1d 100644
--- a/Documentation/kvm/api.txt
+++ b/Documentation/kvm/api.txt
@@ -1263,6 +1263,53 @@ struct kvm_assigned_msix_entry {
__u16 padding[3];
};
+4.54 KVM_REGISTER_MSIX_MMIO
+
+Capability: KVM_CAP_MSIX_MMIO
+Architectures: x86
+Type: vm ioctl
+Parameters: struct kvm_msix_mmio_user (in)
+Returns: 0 on success, -1 on error
+
+This API indicates an MSI-X MMIO address of a guest device. Then all MMIO
+operation would be handled by kernel. When necessary(e.g. MSI data/address
+changed), KVM would exit to userspace using KVM_EXIT_MSIX_ROUTING_UPDATE to
+indicate the MMIO modification and require userspace to update IRQ routing
+table.
+
+NOTICE: Writing the MSI-X MMIO page after it was registered with this API may
+be dangerous for userspace program. The writing during VM running may result
+in synchronization issue therefore the assigned device can't work properly.
+The writing is allowed when VM is not running and can be used as save/restore
+mechanism.
+
+struct kvm_msix_mmio_user {
+ __u32 dev_id;
+ __u16 type; /* Device type and MMIO address type */
+ __u16 max_entries_nr; /* Maximum entries supported */
+ __u64 base_addr;/* Guest physical address of MMIO */
+ __u64 base_va; /* Host virtual address of MMIO mapping */
+ __u64 flags;/* Reserved for now */
+ __u64 reserved[4];
+};
+
+Current device type can be:
+#define KVM_MSIX_MMIO_TYPE_ASSIGNED_DEV(1 0)
+
+Current MMIO type can be:
+#define KVM_MSIX_MMIO_TYPE_BASE_TABLE (1 8)
+
+4.55 KVM_UNREGISTER_MSIX_MMIO
+
+Capability: KVM_CAP_MSIX_MMIO
+Architectures: x86
+Type: vm ioctl
+Parameters: struct kvm_msix_mmio_user (in)
+Returns: 0 on success, -1 on error
+
+This API would unregister the specific MSI-X MMIO, indicated by dev_id and
+type fields of struct kvm_msix_mmio_user.
+
5. The kvm_run structure
Application code obtains a pointer to the kvm_run structure by
--
1.7.0.1
--
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
Re: [PATCH 3/3] KVM: Add documents for MSI-X MMIO API
On Tuesday 25 January 2011 20:47:38 Avi Kivity wrote: On 01/19/2011 10:21 AM, Sheng Yang wrote: We already got an guest MMIO address for that in the exit information. I've created a chain of handler in qemu to handle it. But we already decoded the table and entry... But the handler is still wrapped by vcpu_mmio_write(), as a part of MMIO. So it's not quite handy to get the table and entry out. The kernel handler can create a new kvm_run exit description. Also the updater in the userspace can share the most logic with ordinary userspace MMIO handler, which take address as parameter. So I think we don't need to pass the decoded table_id and entry to userspace. It's mixing layers, which always leads to trouble. For one, the user handler shouldn't do anything with the write since the kernel already wrote it into the table. For another, if two vcpus write to the same entry simultaneously, you could see different ordering in the kernel and userspace, and get inconsistent results. The shared logic is not about writing, but about interpret what's written. Old MMIO handler would write the data, then interpret it; and our new MMIO would only share the logic of interpretation. I think that's fair enough? -- regards Yang, Sheng -- 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
Re: [PATCH 3/3] KVM: Add documents for MSI-X MMIO API
On 01/19/2011 10:21 AM, Sheng Yang wrote: We already got an guest MMIO address for that in the exit information. I've created a chain of handler in qemu to handle it. But we already decoded the table and entry... But the handler is still wrapped by vcpu_mmio_write(), as a part of MMIO. So it's not quite handy to get the table and entry out. The kernel handler can create a new kvm_run exit description. Also the updater in the userspace can share the most logic with ordinary userspace MMIO handler, which take address as parameter. So I think we don't need to pass the decoded table_id and entry to userspace. It's mixing layers, which always leads to trouble. For one, the user handler shouldn't do anything with the write since the kernel already wrote it into the table. For another, if two vcpus write to the same entry simultaneously, you could see different ordering in the kernel and userspace, and get inconsistent results. -- error compiling committee.c: too many arguments to function -- 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
Re: [PATCH 3/3] KVM: Add documents for MSI-X MMIO API
On Monday 17 January 2011 20:45:55 Avi Kivity wrote:
On 01/17/2011 02:35 PM, Sheng Yang wrote:
On Monday 17 January 2011 20:21:45 Avi Kivity wrote:
On 01/06/2011 12:19 PM, Sheng Yang wrote:
Signed-off-by: Sheng Yangsh...@linux.intel.com
---
Documentation/kvm/api.txt | 41
+ 1 files changed, 41
insertions(+), 0 deletions(-)
diff --git a/Documentation/kvm/api.txt b/Documentation/kvm/api.txt
index e1a9297..4978b94 100644
--- a/Documentation/kvm/api.txt
+++ b/Documentation/kvm/api.txt
@@ -1263,6 +1263,47 @@ struct kvm_assigned_msix_entry {
__u16 padding[3];
};
+4.54 KVM_REGISTER_MSIX_MMIO
+
+Capability: KVM_CAP_MSIX_MMIO
+Architectures: x86
+Type: vm ioctl
+Parameters: struct kvm_msix_mmio_user (in)
+Returns: 0 on success, -1 on error
+
+This API indicates an MSI-X MMIO address of a guest device. Then
all MMIO +operation would be handled by kernel. When
necessary(e.g. MSI data/address +changed), KVM would exit to
userspace using
KVM_EXIT_MSIX_ROUTING_UPDATE to +indicate the MMIO modification and
require userspace to update IRQ routing +table.
+
+struct kvm_msix_mmio_user {
+ __u32 dev_id;
+ __u16 type; /* Device type and MMIO address type */
+ __u16 max_entries_nr; /* Maximum entries supported */
+ __u64 base_addr;/* Guest physical address of MMIO */
+ __u64 base_va; /* Host virtual address of MMIO mapping
*/
+ __u64 flags;/* Reserved for now */
+ __u64 reserved[4];
+};
+
+Current device type can be:
+#define KVM_MSIX_MMIO_TYPE_ASSIGNED_DEV (1 0)
+
+Current MMIO type can be:
+#define KVM_MSIX_MMIO_TYPE_BASE_TABLE(1 8)
+
How does userspace know which entry of which table changed? Need a
field in struct kvm_run for that.
We already got an guest MMIO address for that in the exit information.
I've created a chain of handler in qemu to handle it.
But we already decoded the table and entry...
But the handler is still wrapped by vcpu_mmio_write(), as a part of MMIO. So
it's
not quite handy to get the table and entry out. Also the updater in the
userspace
can share the most logic with ordinary userspace MMIO handler, which take
address
as parameter. So I think we don't need to pass the decoded table_id and entry
to
userspace.
--
regards
Yang, Sheng
--
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
Re: [PATCH 3/3] KVM: Add documents for MSI-X MMIO API
On 01/06/2011 12:19 PM, Sheng Yang wrote:
Signed-off-by: Sheng Yangsh...@linux.intel.com
---
Documentation/kvm/api.txt | 41 +
1 files changed, 41 insertions(+), 0 deletions(-)
diff --git a/Documentation/kvm/api.txt b/Documentation/kvm/api.txt
index e1a9297..4978b94 100644
--- a/Documentation/kvm/api.txt
+++ b/Documentation/kvm/api.txt
@@ -1263,6 +1263,47 @@ struct kvm_assigned_msix_entry {
__u16 padding[3];
};
+4.54 KVM_REGISTER_MSIX_MMIO
+
+Capability: KVM_CAP_MSIX_MMIO
+Architectures: x86
+Type: vm ioctl
+Parameters: struct kvm_msix_mmio_user (in)
+Returns: 0 on success, -1 on error
+
+This API indicates an MSI-X MMIO address of a guest device. Then all MMIO
+operation would be handled by kernel. When necessary(e.g. MSI data/address
+changed), KVM would exit to userspace using KVM_EXIT_MSIX_ROUTING_UPDATE to
+indicate the MMIO modification and require userspace to update IRQ routing
+table.
+
+struct kvm_msix_mmio_user {
+ __u32 dev_id;
+ __u16 type; /* Device type and MMIO address type */
+ __u16 max_entries_nr; /* Maximum entries supported */
+ __u64 base_addr;/* Guest physical address of MMIO */
+ __u64 base_va; /* Host virtual address of MMIO mapping */
+ __u64 flags;/* Reserved for now */
+ __u64 reserved[4];
+};
+
+Current device type can be:
+#define KVM_MSIX_MMIO_TYPE_ASSIGNED_DEV(1 0)
+
+Current MMIO type can be:
+#define KVM_MSIX_MMIO_TYPE_BASE_TABLE (1 8)
+
How does userspace know which entry of which table changed? Need a
field in struct kvm_run for that.
--
error compiling committee.c: too many arguments to function
--
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
Re: [PATCH 3/3] KVM: Add documents for MSI-X MMIO API
On Monday 17 January 2011 20:21:45 Avi Kivity wrote:
On 01/06/2011 12:19 PM, Sheng Yang wrote:
Signed-off-by: Sheng Yangsh...@linux.intel.com
---
Documentation/kvm/api.txt | 41
+ 1 files changed, 41
insertions(+), 0 deletions(-)
diff --git a/Documentation/kvm/api.txt b/Documentation/kvm/api.txt
index e1a9297..4978b94 100644
--- a/Documentation/kvm/api.txt
+++ b/Documentation/kvm/api.txt
@@ -1263,6 +1263,47 @@ struct kvm_assigned_msix_entry {
__u16 padding[3];
};
+4.54 KVM_REGISTER_MSIX_MMIO
+
+Capability: KVM_CAP_MSIX_MMIO
+Architectures: x86
+Type: vm ioctl
+Parameters: struct kvm_msix_mmio_user (in)
+Returns: 0 on success, -1 on error
+
+This API indicates an MSI-X MMIO address of a guest device. Then all
MMIO +operation would be handled by kernel. When necessary(e.g. MSI
data/address +changed), KVM would exit to userspace using
KVM_EXIT_MSIX_ROUTING_UPDATE to +indicate the MMIO modification and
require userspace to update IRQ routing +table.
+
+struct kvm_msix_mmio_user {
+ __u32 dev_id;
+ __u16 type; /* Device type and MMIO address type */
+ __u16 max_entries_nr; /* Maximum entries supported */
+ __u64 base_addr;/* Guest physical address of MMIO */
+ __u64 base_va; /* Host virtual address of MMIO mapping */
+ __u64 flags;/* Reserved for now */
+ __u64 reserved[4];
+};
+
+Current device type can be:
+#define KVM_MSIX_MMIO_TYPE_ASSIGNED_DEV(1 0)
+
+Current MMIO type can be:
+#define KVM_MSIX_MMIO_TYPE_BASE_TABLE (1 8)
+
How does userspace know which entry of which table changed? Need a
field in struct kvm_run for that.
We already got an guest MMIO address for that in the exit information. I've
created a chain of handler in qemu to handle it.
--
regards
Yang, Sheng
--
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
Re: [PATCH 3/3] KVM: Add documents for MSI-X MMIO API
On 01/17/2011 02:35 PM, Sheng Yang wrote:
On Monday 17 January 2011 20:21:45 Avi Kivity wrote:
On 01/06/2011 12:19 PM, Sheng Yang wrote:
Signed-off-by: Sheng Yangsh...@linux.intel.com
---
Documentation/kvm/api.txt | 41
+ 1 files changed, 41
insertions(+), 0 deletions(-)
diff --git a/Documentation/kvm/api.txt b/Documentation/kvm/api.txt
index e1a9297..4978b94 100644
--- a/Documentation/kvm/api.txt
+++ b/Documentation/kvm/api.txt
@@ -1263,6 +1263,47 @@ struct kvm_assigned_msix_entry {
__u16 padding[3];
};
+4.54 KVM_REGISTER_MSIX_MMIO
+
+Capability: KVM_CAP_MSIX_MMIO
+Architectures: x86
+Type: vm ioctl
+Parameters: struct kvm_msix_mmio_user (in)
+Returns: 0 on success, -1 on error
+
+This API indicates an MSI-X MMIO address of a guest device. Then all
MMIO +operation would be handled by kernel. When necessary(e.g. MSI
data/address +changed), KVM would exit to userspace using
KVM_EXIT_MSIX_ROUTING_UPDATE to +indicate the MMIO modification and
require userspace to update IRQ routing +table.
+
+struct kvm_msix_mmio_user {
+ __u32 dev_id;
+ __u16 type; /* Device type and MMIO address type */
+ __u16 max_entries_nr; /* Maximum entries supported */
+ __u64 base_addr;/* Guest physical address of MMIO */
+ __u64 base_va; /* Host virtual address of MMIO mapping */
+ __u64 flags;/* Reserved for now */
+ __u64 reserved[4];
+};
+
+Current device type can be:
+#define KVM_MSIX_MMIO_TYPE_ASSIGNED_DEV(1 0)
+
+Current MMIO type can be:
+#define KVM_MSIX_MMIO_TYPE_BASE_TABLE (1 8)
+
How does userspace know which entry of which table changed? Need a
field in struct kvm_run for that.
We already got an guest MMIO address for that in the exit information. I've
created a chain of handler in qemu to handle it.
But we already decoded the table and entry...
--
error compiling committee.c: too many arguments to function
--
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
[PATCH 3/3] KVM: Add documents for MSI-X MMIO API
Signed-off-by: Sheng Yang sh...@linux.intel.com
---
Documentation/kvm/api.txt | 41 +
1 files changed, 41 insertions(+), 0 deletions(-)
diff --git a/Documentation/kvm/api.txt b/Documentation/kvm/api.txt
index e1a9297..4978b94 100644
--- a/Documentation/kvm/api.txt
+++ b/Documentation/kvm/api.txt
@@ -1263,6 +1263,47 @@ struct kvm_assigned_msix_entry {
__u16 padding[3];
};
+4.54 KVM_REGISTER_MSIX_MMIO
+
+Capability: KVM_CAP_MSIX_MMIO
+Architectures: x86
+Type: vm ioctl
+Parameters: struct kvm_msix_mmio_user (in)
+Returns: 0 on success, -1 on error
+
+This API indicates an MSI-X MMIO address of a guest device. Then all MMIO
+operation would be handled by kernel. When necessary(e.g. MSI data/address
+changed), KVM would exit to userspace using KVM_EXIT_MSIX_ROUTING_UPDATE to
+indicate the MMIO modification and require userspace to update IRQ routing
+table.
+
+struct kvm_msix_mmio_user {
+ __u32 dev_id;
+ __u16 type; /* Device type and MMIO address type */
+ __u16 max_entries_nr; /* Maximum entries supported */
+ __u64 base_addr;/* Guest physical address of MMIO */
+ __u64 base_va; /* Host virtual address of MMIO mapping */
+ __u64 flags;/* Reserved for now */
+ __u64 reserved[4];
+};
+
+Current device type can be:
+#define KVM_MSIX_MMIO_TYPE_ASSIGNED_DEV(1 0)
+
+Current MMIO type can be:
+#define KVM_MSIX_MMIO_TYPE_BASE_TABLE (1 8)
+
+4.55 KVM_UNREGISTER_MSIX_MMIO
+
+Capability: KVM_CAP_MSIX_MMIO
+Architectures: x86
+Type: vm ioctl
+Parameters: struct kvm_msix_mmio_user (in)
+Returns: 0 on success, -1 on error
+
+This API would unregister the specific MSI-X MMIO, indicated by dev_id and
+type fields of struct kvm_msix_mmio_user.
+
5. The kvm_run structure
Application code obtains a pointer to the kvm_run structure by
--
1.7.0.1
--
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
