Re: [PATCH 6/8] KVM: assigned dev: Preparation for mask support in userspace

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

On Sunday 24 October 2010 20:23:20 Michael S. Tsirkin wrote:
> On Sun, Oct 24, 2010 at 08:19:09PM +0800, Sheng Yang wrote:
> > > You need a guarantee that MSIX per-vector mask is used for
> > > disable_irq/enable_irq, right? I can't see how this provides it.
> > 
> > This one meant to directly operate the mask/unmask bit of the MSI-X
> > table, to emulate the mask/unmask behavior that guest want. In the
> > previous patch I used enable_irq()/disable_irq(), but they won't
> > directly operate the MSI-X table unless it's necessary, and Michael want
> > to read the table in userspace then he prefer using mask/unmask
> > directly.
> 
> As I said, the main problem was really that the implementation
> proposed only works for interrupts used by assigned devices.
> I would like for it to work for irqfd as well.

I think we can't let QEmu access mask or pending bit directly. It must communicate 
with kernel to get the info if kernel owned mask.

That's because in fact guest supposed mask/unmask operation has nothing todo with 
what host would do. Maybe we can emulate it by do the same thing on the device, 
but it's two layer in fact. Also we know host kernel would does disabling/enabling 
according to its own mechanism, e.g. it may disable interrupt temporarily if there 
are too many interrupts. What host does should be transparent to guest. Directly 
accessing the data from device should be prohibited. 

And pending bit case is the same. In fact kernel knows which IRQ is pending, we 
can check IRQ_PENDING bit of desc, though we don't have such interface now. But we 
can do it in the future if it's necessary.

I'm purposing an new interface like "kvm_get_msix_entry", to return the mask bit 
of specific entry. The pending bit support can be added in the future if it's 
needed. But we can't directly access the MSI-X table/PBA in theory.

--
regards
Yang, Sheng