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 Yang<sheng@xxxxxxxxxxxxxxx>
> > > > ---
> > > >
> > > > 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
