On Wednesday 02 March 2011 04:18:58 Marcelo Tosatti wrote:
> On Fri, Feb 25, 2011 at 10:29:38AM +0200, Michael S. Tsirkin wrote:
> > On Fri, Feb 25, 2011 at 02:28:02PM +0800, Sheng Yang wrote:
> > > On Thursday 24 February 2011 18:45:08 Michael S. Tsirkin wrote:
> > > > On Thu, Feb 24, 2011 at 05:51:04PM +0800, Sheng Yang wrote:
> > > > > Then we can support mask bit operation of assigned devices now.
> > > > >
> > > > > Signed-off-by: Sheng Yang <sheng@xxxxxxxxxxxxxxx>
> > > >
> > > > Doesn't look like all comments got addressed.
> > > > E.g. gpa_t entry_base is still there and in reality
> > > > you said it's a host virtual address so
> > > > should be void __user *;
> > >
> > > Would update it.
> > >
> > > > And ENOTSYNC meaning 'MSIX' is pretty hacky.
> > >
> > > I'd like to discuss it later. We may need some work on all MMIO
> > > handling side to make it more straightforward. But I don't want to
> > > bundle it with this one...
> >
> > It's not PCI related so I'll defer to Avi/Marcelo on this.
> > Are you guys happy with the ENOTSYNC meaning 'MSIX'
>
> What would be a better alternative to ENOTSYNC? Can't see any.
>
> > and userspace_exit_needed hacks in this code?
>
> I thought this was handled by mmio_needed in a previous patch?
>
> Since x86_emulate_instruction does
>
> } else if (vcpu->mmio_needed) {
> if (vcpu->mmio_is_write)
> vcpu->mmio_needed = 0;
> r = EMULATE_DO_MMIO;
>
> It should be fine. Sheng why did you introduce userspace_exit_needed?
Because strictly speaking it's not MMIO exit, I don't know if Avi would object the
confusing concept here, so I introduced another type of exit.
But if it's OK, I still would use mmio_needed in the next version, which is also
more simple.
--
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
