Re: [Xen-devel] [PATCH v6 5/6] xen/x86: add PHYSDEVOP_interrupt_control - Marek Marczykowski-Górecki

From: "Marek Marczykowski-Górecki" <marmarek@invisiblethingslab.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: "Stefano Stabellini" <sstabellini@kernel.org>,
	"Wei Liu" <wl@xen.org>,
	"Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>,
	"George Dunlap" <George.Dunlap@eu.citrix.com>,
	"Andrew Cooper" <andrew.cooper3@citrix.com>,
	"Ian Jackson" <ian.jackson@eu.citrix.com>,
	"Tim Deegan" <tim@xen.org>, "Julien Grall" <julien.grall@arm.com>,
	xen-devel@lists.xenproject.org,
	"Daniel De Graaf" <dgdegra@tycho.nsa.gov>,
	"Roger Pau Monné" <roger.pau@citrix.com>
Subject: Re: [Xen-devel] [PATCH v6 5/6] xen/x86: add PHYSDEVOP_interrupt_control
Date: Fri, 20 Sep 2019 18:02:50 +0200	[thread overview]
Message-ID: <20190920160250.GA8065@mail-itl> (raw)
In-Reply-To: <fc4dcc0e-fd7a-a25d-0f6f-b722f6ba8122@suse.com>

[-- Attachment #1.1: Type: text/plain, Size: 2641 bytes --]

On Fri, Sep 20, 2019 at 12:10:09PM +0200, Jan Beulich wrote:
> On 14.09.2019 17:37, Marek Marczykowski-Górecki  wrote:
> > Allow device model running in stubdomain to enable/disable INTx/MSI(-X),
> > bypassing pciback. While pciback is still used to access config space
> > from within stubdomain, it refuse to write to
> > PCI_MSI_FLAGS_ENABLE/PCI_MSIX_FLAGS_ENABLE/PCI_COMMAND_INTX_DISABLE
> > in non-permissive mode. Which is the right thing to do for PV domain
> > (the main use case for pciback), as PV domain should use XEN_PCI_OP_*
> > commands for that. Unfortunately those commands are not good for
> > stubdomain use, as they configure MSI in dom0's kernel too, which should
> > not happen for HVM domain.
> 
> Why the "for HVM domain" here? I.e. why would this be correct for
> a PV domain? Besides my dislike for such a bypass (imo all of the
> handling should go through pciback, or none of it) I continue to
> wonder whether the problem can't be addressed by a pciback change.
> And even if not, I'd still wonder whether the request shouldn't go
> through pciback, to retain proper layering. Ultimately it may be
> better to have even the map/unmap go through pciback (it's at
> least an apparent violation of the original physdev-op model that
> these two are XSM_DM_PRIV).

Technically it should be possible to move this part to pciback, and in
fact this is what I've considered in the first version of this series.
But Roger points out on each version[1] of this series that pciback is
meant to serve *PV* domains, where a PCI passthrough is a completely
different different beast. In fact, I even consider that using pcifront
in a Linux stubdomain as a proxy for qemu there may be a bad idea (one
needs to be careful to avoid stubdomain kernel fighting with qemu about
device state).

Roger, what is the state of Xen internal vPCI? If handling PCI
passthrough in Xen (or maybe standalone emulator), without qemu help is
going to happen sooner than later (I guess not 4.13, but maybe 4.14?),
then maybe this whole patch doesn't make sense as a temporary measure?

Anyway, if you all agree that pciback should be the way to go, I can go
that route too. In practice, it would be a flag (set by the toolstack?)
allowing writes to appropriate config space registers directly (with
appropriate checks, as in this patch).

[1] https://lists.xenproject.org/archives/html/xen-devel/2019-08/msg00486.html

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 157 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel