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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
