Re: kvm device assignment and MSI-X masking

From: Alex Williamson <alex.williamson@redhat.com>
To: Jan Kiszka <jan.kiszka@siemens.com>
Cc: kvm <kvm@vger.kernel.org>
Subject: Re: kvm device assignment and MSI-X masking
Date: Tue, 14 Aug 2012 08:05:49 -0600	[thread overview]
Message-ID: <1344953149.4683.244.camel@ul30vt.home> (raw)
In-Reply-To: <502A572A.5040408@siemens.com>

On Tue, 2012-08-14 at 15:48 +0200, Jan Kiszka wrote:
> Hi Alex,
> 
> you once wrote this comment in device-assignment.c, msix_mmio_write:
> 
>     if (!msix_masked(&orig) && msix_masked(entry)) {
>         /*
>          * Vector masked, disable it
>          *
>          * XXX It's not clear if we can or should actually attempt
>          * to mask or disable the interrupt.  KVM doesn't have
>          * support for pending bits and kvm_assign_set_msix_entry
>          * doesn't modify the device hardware mask.  Interrupts
>          * while masked are simply not injected to the guest, so
>          * are lost.  Can we get away with always injecting an
>          * interrupt on unmask?
>          */
> 
> I'm wondering what made you think that we won't inject if the vector is
> masked like this (ie. in the shadow MSI-X table). Can you recall the
> details?
> 
> I'm trying to refactor this code to make the KVM interface a bit more
> encapsulating the kernel interface details, not fixing anything. Still,
> I would also like to avoid introducing regressions.

Yeah, I didn't leave a very good comment there.  I'm sure it made more
sense to me at the time.  I think I was trying to say that not only do
we not have a way to mask the physical hardware, but if we did, we don't
have a way to retrieve the pending bits, so any pending interrupts while
masked would be lost.  We might be able to deal with that by posting a
spurious interrupt on unmask, but for now we do nothing as masking is
usually done just to update the vector.  Thanks,

Alex