[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

 


Rackspace

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