Re: [PATCH 7/8] KVM: assigned dev: Introduce io_device for MSI-X MMIO accessing

["Michael S. Tsirkin" <mst@redhat.com>]

On Thu, Oct 21, 2010 at 11:47:18AM +0200, Avi Kivity wrote:
>  On 10/21/2010 11:24 AM, Michael S. Tsirkin wrote:
> >On Thu, Oct 21, 2010 at 11:27:30AM +0200, Avi Kivity wrote:
> >>   On 10/21/2010 08:46 AM, Sheng Yang wrote:
> >>  >>   >   +		r = -EOPNOTSUPP;
> >>  >>
> >>  >>   If the guest assigned the device to another guest, it allows the nested
> >>  >>   guest to kill the non-nested guest.  Need to exit in a graceful fashion.
> >>  >
> >>  >Don't understand... It wouldn't result in kill but return to QEmu/userspace.
> >>
> >>  What would qemu do on EOPNOTSUPP?  It has no way of knowing that
> >>  this was triggered by an unsupported msix access.  What can it do?
> >>
> >>  Best to just ignore the write.
> >>
> >>  If you're worried about debugging, we can have a trace_kvm_discard()
> >>  tracepoint that logs the address and a type enum field that explains
> >>  why an access was discarded.
> >
> >The issue is that the same page is used for mask and entry programming.
> 
> Yeah.  For that use the normal mmio exit_reason.  I was referring to
> misaligned writes.

Yes, I think we can just drop them if we like. Might be a good idea to
stick a trace point there for debugging.

> I'm not happy with partial emulation, but I'm not happy either with
> yet another interface to communicate the decoded MSI BAR writes to
> userspace.  Shall we just reprogram the irq routing table?

Well we don't need to touch the routing table at all.
We have the MSI mask, address and data in kernel.
That is enough to interrupt the guest.

For vhost-net, we would need an interface that maps an irqfd
to a vector # (not gsi), or alternatively map gsi to
a pair device/vector number. This is easy to implement.

For VFIO, we have a problem if we try to work especially without
interrupt remapping as we can't just program all entries for all
devices.  So solution could be some combination of requiring interrupt
remapping, looking at addresses and looking at the pending bit.

New vectors are added/removed rarely. So maybe we can get away with 
1. interface to read MSIX table from userspace (good for debugging anyway)
2. an eventfd to signal on MSIX table writes


> 
> -- 
> error compiling committee.c: too many arguments to function