Re: [Xen-devel] [PATCH v2 06/11] ioreq: allow dispatching ioreqs to internal servers

[Jan Beulich <jbeulich@xxxxxxxx>]

On 26.09.2019 13:14, Roger Pau Monné  wrote:
> On Fri, Sep 20, 2019 at 01:35:13PM +0200, Jan Beulich wrote:
>> Having said this, as a result of having looked at some of the
>> involved code, and with the cover letter not clarifying this,
>> what's the reason for going this seemingly more complicated
>> route, rather than putting vPCI behind the hvm_io_intercept()
>> machinery, just like is the case for other internal handling?
> 
> If vPCI is handled at the hvm_io_intercept level (like its done ATM)
> then it's not possible to have both (external) ioreq servers and vPCI
> handling accesses to different devices in the PCI config space, since
> vPCI would trap all accesses to the PCI IO ports and the MCFG regions
> and those would never reach the ioreq processing.

Why would vPCI (want to) do that? The accept() handler should
sub-class the CF8-CFF port range; there would likely want to
be another struct hvm_io_ops instance dealing with config
space accesses (and perhaps with ones through port I/O and
through MCFG at the same time). In the end this would likely
more similar to how chipsets handle this on real hardware
than your "internal server" solution (albeit I agree to a
degree it's in implementation detail anyway).

Jan

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