Re: [Xen-devel] [PATCH-for-4.13] x86/mm: don't needlessly veto migration

[Paul Durrant <pdurrant@xxxxxxxxx>]

On Tue, 1 Oct 2019 at 15:24, Jan Beulich <jbeulich@xxxxxxxx> wrote:
>
> On 01.10.2019 15:29, Paul Durrant wrote:
> > The changes in XAPI are not vast; the main complexity is in the device
> > emulator (to provide information during the live phase of migration)
> > but I still don't see why Citrix's choice of closed vs. open source
> > implementation of the emulator really has anything to do with this. It
> > is still my opinion that Xen's only valid reason for refusing to
> > enable logdirty for a domain is one of host safety and I still haven't
> > heard an argument as to why Xen *is* right to refuse in other
> > circumstances.
>
> Let me take a completely different example for comparison:
> There's no risk to the host in assigning the same, say, USB
> controller to two guests. Yet Xen refuses to do so, even if the
> tool stack didn't already filter such attempts, and even if the
> admin may know that the two domains are cooperating, and hence
> wouldn't get in the way of one another. (There are, I think,
> many other similar examples.)

That sounds like a perfectly valid thing to do if the s/w running in
the domains is trusted to co-operate as you say. For NVIDIA vGPU
implementations different MMIO regions of the same PCI device are
mapped into different guests.

>
> That said I can certainly see the validity of your and Andrew's
> argumentation. It's just that, as in various other cases, I
> don't think that's the only reasonable way of arranging things.
> Hence at the very least your change would imo need to come with
> an extended description.
>

Ok, I will expand on the reasoning in the commit comment and post v2.

  Paul

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