Re: [Xen-devel] [PATCH 0/4] x86/MSI-X: XSA-120 follow-up

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 13.03.15 at 21:16, <andrew.cooper3@xxxxxxxxxx> wrote:
> Given these extra config accesses, I am seriously wondering whether it
> would be more efficient overall to trap&emulate dom0 completely and
> allow Xen to cache things like the current control register state,
> locations of capability structures, etc.  I genuinely don't know the
> answer, but I suspect the comparative expense of config accesses means
> that we don't need to replace many of the lookups for a net benefit. 

I would assume this depends on the access method: If Dom0 uses
port I/O (via ports CF8 and CFC), then the overhead needed for
caching would be quite low, and the original access be comparably
slow already anyway. If however we talk of MMCFG accesses, then
I'd expect these to be faster, and Dom0 right now has direct access.
I.e. emulation would first of all involve adding #PF interception and
instruction decoding, and hence the net loss in performance would
be quite a bit higher. Plus we'd all of the sudden make it a
requirement that Dom0 let us know about the usability of MMCFG
regions - right now this is optional, i.e. Dom0 might use MMCFG
while Xen doesn't and hence also would have no handle for
intercepting writes.

> (Of course, it doesn't protect against backdoor access, but all bets are
> already off at that point.)

As long as we read config space rather than cache its supposed
state, there's no problem with backdoor accesses. And we should
already be using cached r/o items like capability positions, at least
on code paths used not only for setup/teardown.

Jan


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