Re: [PATCH 3/3] KVM: Add documents for MSI-X MMIO API

[Sheng Yang <sheng@linux.intel.com>]

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
>