Re: [Xen-devel] [PATCH v3 10/10] x86/MSI-X: provide hypercall interface for mask-all control

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 05.06.15 at 13:28, <JBeulich@xxxxxxxx> wrote:
> Qemu shouldn't be fiddling with this bit directly, as the hypervisor
> may (and now does) use it for its own purposes. Provide it with a
> replacement interface, allowing the hypervisor to track host and guest
> masking intentions independently (clearing the bit only when both want
> it clear).

Originally I merely meant to ping the tools side changes here
(considering that the original issue has been pending for months,
delayed by various security issues as well as slow turnaround on
understanding the nature and validity of that original issue, I'd
_really_ like to see this go in now), but thinking about it once
again over night I realized that what we do here to allow qemu
to be fixed would then also be made use of by the kernels
running pciback: While Dom0 fiddling with the MSI-X mask-all bit
for its own purposes is at least not a security problem, it doing
so on behalf of (and directed by) a guest would be as soon as
the hypervisor side patches making use of that bit went in.

While I continue to be of the opinion that all direct writes to
interrupt masking bits (MSI-X mask-all, MSI-X per-entry mask,
MSI per entry mask) outside of the hypervisor are wrong and
should be eliminated, the scope of the problem now clearly
going beyond qemu made me reconsider whether we shouldn't,
as advocated by Stefano, follow the trap-and-emulate route
instead. This would not only mean adding code to x86's existing
port CF8/CFC intercepts, but also write-protecting the MMCFG
pages for all PCI devices being MSI or MSI-X capable, emulating
writes with inspection / modification of writes to any of the mask
bits located in PCI config space. (A subsequent optimization to
this may then be a hypercall to do config space writes,
eliminating the emulation overhead, accompanied by a bitmap
indicating which devices' CFG space can be written directly.)

For a (from now on) timely resolution of the original problem I'd
really appreciate opinions (or alternative suggestions).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel