Linux kernel's msi_domain_deactivate() operation

[Jan Beulich <jbeulich@xxxxxxxx>]

Hello,

I notice that from its introduction in 3.19 this function simply clears
message address and data. I wonder in how far this is "deactivation":
Aiui the device might still signal interrupts this way, by writing
32 bits of zeroes to address zero. (That's not going to result in an
interrupt, of course.) Shouldn't deactivation rather mean masking (if
the entry is maskable; looks like this is happening in an earlier step
when possible) or disabling of MSI (which unfortunately would then also
affect other interrupts, if multiple are in use) or some software means
replacing masking?

Background: For PVH Dom0 under Xen we check (in Xen) whether address
fields written actually fall in the designated 0xFEEnnnnn range (as
long as MSI / MSI-X is enabled at the time of writing of these fields),
logging outliers. As it turns out the message appears quite a few times
per session, primarily - but not only - during shutdown. We log these
instances not because they're wrong (as said above, this is in principle
a valid mode of operation), but because proper handling would require
further code in Xen which we were hoping we would never have to write.
(Thinking about this again, it shouldn't be all that much code.)

In a small subset of the cases the operation actually occurs with the
respective entry masked (in all other cases there's no maskbit support);
we may want to consider suppressing the log message in such cases, yet
then we may need to watch for this case the next time the mask bit gets
cleared.

Of course in the kernel you may have reassurance that the device driver
has actually disabled the interrupt source at the device before this
deactivation. We don't have such secondary knowledge in the hypervisor,
i.e. we can't use that to suppress the log message.

Any insight would be much appreciated, including the possible pointing
out of us not having understood the underlying idea.

Thanks, Jan