Re: [Xen-devel] vpci: deferral of register write until p2m changes are done

[Roger Pau Monné <roger.pau@xxxxxxxxxx>]

On Wed, Nov 28, 2018 at 10:04:33AM -0700, Jan Beulich wrote:
> >>> On 28.11.18 at 17:54, <roger.pau@xxxxxxxxxx> wrote:
> > On Wed, Nov 28, 2018 at 09:22:16AM -0700, Jan Beulich wrote:
> >> >>> On 28.11.18 at 16:41, <roger.pau@xxxxxxxxxx> wrote:
> >> > My plan is that DomUs won't be allowed to toggle the memory decoding
> >> > bit, and it's going to be always enabled, like it's currently done for
> >> > pci-passthrough in QEMU. Toggling the memory decoding bit in a DomU is
> >> > going to trigger a change to the p2m (map or unmap) but the command
> >> > register will always have the memory decoding bit enabled.
> >> 
> >> But this isn't entirely correct, even if we've got away with this
> >> so far. But we're mostly considering well-behaved guests and
> >> devices. What if one actually triggers bus activity in parallel to
> >> a BAR change?
> > 
> > Well, that's likely to not work properly in any case with or without
> > disabling the memory decoding bit?
> 
> Of course not.
> 
> > But I don't see how that's going to affect Xen stability (or what the
> > domain is attempting to achieve with it).
> 
> "I don't see how ..." != "That's not going to ...". And in case my
> prior way of wording it was ambiguous: We very much need to
> think about malicious guests (once any of this is to be extended
> to DomU-s). Hence a goal of "I want to crash Xen" needs to be
> taken into consideration.

Right, so Xen might what to disable memory decoding for DomUs also.

But that's orthogonal to whether we agree that the write to the
command register can happen before the p2m modifications, both in the
map and the unmap case. I think so, but I would like to be sure you
agree before I code this.

Thanks, Roger.

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