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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 28.11.18 at 18:48, <roger.pau@xxxxxxxxxx> wrote:
> 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.

Thing is, as said before, I'm not sure. I can be convinced by, well,
convincing arguments (which a proof that nothing bad can happen
would be, but anything less likely wouldn't).

Jan



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