[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH] x86/mtrr: recalculate P2M type for domains with iocaps



>>> On 25.04.19 at 18:22, <igor.druzhinin@xxxxxxxxxx> wrote:
> Although there are things that I'm not sure about:
> - whether iocaps are always used by software in Dom0 when passing
> through certain physical memory and whether their usage is enforced by Xen

I'm afraid I'm struggling to understand what exactly you mean.
Passing through a device without also registering the BARs
for use by the target guest simply wouldn't yield a functioning
device (in the guest). Arguably it shouldn't be a separate
domctl, but that's how the people originally implementing
pass-through chose to structure things. It has the advantage
of devices working where Dom0 knows about extra resources
(MMIO or I/O ports) when Xen doesn't. It has the
disadvantage of being dependent on Xen, Dom0 kernel, and
the tool stack interacting correctly (rather than all logic being
in a single component).

There was a similarly odd arrangement in the original
implementation of MSI-X, where Xen depended upon Dom0
reporting the MSI-X table base. Nowadays we read the BAR
ourselves and simply check that the value matches what
Dom0 has passed.

> - there are could be assumptions elsewhere that with IOMMU context
> assigned guest caching choice is in effect - since that fact has been
> perpetuated in Xen code for very long time

Agreed - there's a certain chance that other places in Xen have
similar logic. But there's an equal chance that other places in
Xen similarly check only one of the two, when, in the spirit of your
patch, they really mean to check both. This could only be clarified
by doing a full audit.

Jan



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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.