From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: Re: [PATCH v3 10/10] x86/MSI-X: provide hypercall interface for mask-all control Date: Thu, 11 Jun 2015 09:35:51 +0100 Message-ID: <557964870200007800083706@mail.emea.novell.com> References: <55719F9D0200007800081425@mail.emea.novell.com> <5571A3F202000078000814CA@mail.emea.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Z2xyV-0005cG-TQ for xen-devel@lists.xenproject.org; Thu, 11 Jun 2015 08:36:36 +0000 In-Reply-To: <5571A3F202000078000814CA@mail.emea.novell.com> Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Andrew Cooper , Roger Pau Monne , Wei Liu , Ian Campbell , Ian Jackson , Stefano Stabellini , Konrad Rzeszutek Wilk Cc: xen-devel , dgdegra@tycho.nsa.gov, Keir Fraser List-Id: xen-devel@lists.xenproject.org >>> On 05.06.15 at 13:28, 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