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
next prev parent 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).