Re: [Xen-devel] [PATCH v6 5/6] xen/x86: add PHYSDEVOP_interrupt_control

[Jan Beulich <jbeulich@xxxxxxxx>]

On 20.09.2019 18:02, Marek Marczykowski-Górecki  wrote:
> 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).

Well, not using pciback _at all_ in this case would be another option.
What I dislike is the furthering of hybrid-ness.

> 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).

I'm afraid I don't agree: How would allowing writes to more config space
registers by a stubdom be safe?

Jan

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