[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] vpci: deferral of register write until p2m changes are done
>>> 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. Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |