[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 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).


Xen-devel mailing list



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