xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Jan Beulich <jbeulich@suse.com>
To: Paul Durrant <paul.durrant@citrix.com>
Cc: "Juergen Gross" <jgross@suse.com>, "Wei Liu" <wl@xen.org>,
	"George Dunlap" <george.dunlap@eu.citrix.com>,
	"Andrew Cooper" <andrew.cooper3@citrix.com>,
	xen-devel@lists.xenproject.org,
	"Roger Pau Monné" <roger.pau@citrix.com>
Subject: Re: [Xen-devel] [PATCH-for-4.13 v2] x86/mm: don't needlessly veto migration
Date: Wed, 2 Oct 2019 10:40:44 +0200	[thread overview]
Message-ID: <2857a023-87ed-8220-7b22-51f1048f9de6@suse.com> (raw)
In-Reply-To: <20191001151159.861-1-paul.durrant@citrix.com>

On 01.10.2019 17:11, Paul Durrant wrote:
> Now that xl.cfg has an option to explicitly enable IOMMU mappings for a
> domain, migration may be needlessly vetoed due to the check of
> is_iommu_enabled() in paging_log_dirty_enable().
> There is actually no need to prevent logdirty from being enabled unless
> devices are assigned to a domain and that domain is sharing HAP mappings
> with the IOMMU (in which case disabling write permissions in the P2M may
> cause DMA faults). It is quite possible that some assigned devices may
> provide information about which pages may have been dirtied by DMA via
> an API exported by their managing emulator. Thus Xen's logdirty map is only
> one source of information that may be available to the toolstack when
> performing a migration and hence it is the toolstack that is best placed
> to decide under what circumstances it can be performed, not the hypervisor.

While I'm happy about the extended description, it's still written in
a way suggesting that this is the only possible way of viewing things.
As expressed by George and me, putting the hypervisor in a position to
be able to judge is at least an alternative worth considering.

What's worse though - you don't go all the way to the end of what your
argumentation would lead to: There's no reason for Xen to veto the
request then even in the shared page table case. The only device
assigned to a guest in question may be doing DMA reads only. Following
your reasoning, Xen shouldn't be getting in the way then either. Once
again the situation could be taken care of by informing Xen about this
property of a device (assuming it can't tell all by itself).

Jan

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

  reply	other threads:[~2019-10-02  8:40 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-01 15:11 [Xen-devel] [PATCH-for-4.13 v2] x86/mm: don't needlessly veto migration Paul Durrant
2019-10-02  8:40 ` Jan Beulich [this message]
2019-10-02  8:59   ` Paul Durrant
2019-10-02  9:26     ` Jan Beulich
2019-10-02  9:30       ` Paul Durrant
2019-10-02  9:10   ` Andrew Cooper
2019-10-02  9:32     ` Paul Durrant
2019-10-02  9:40     ` Jan Beulich
2019-10-02  9:55       ` Paul Durrant
2019-10-04 16:48     ` George Dunlap
2019-10-08  8:25 ` Jan Beulich
2019-10-08  9:54   ` Paul Durrant

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2857a023-87ed-8220-7b22-51f1048f9de6@suse.com \
    --to=jbeulich@suse.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=george.dunlap@eu.citrix.com \
    --cc=jgross@suse.com \
    --cc=paul.durrant@citrix.com \
    --cc=roger.pau@citrix.com \
    --cc=wl@xen.org \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).