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

Sheng Yang
2010-10-28T08:21:31Z

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