[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH] Don't track all memory when enabling log dirty to track vram



On 06/02/2014 03:27 PM, Jan Beulich wrote:
On 02.06.14 at 16:06, <George.Dunlap@xxxxxxxxxxxxx> wrote:
On Mon, Jun 2, 2014 at 7:55 AM, Jan Beulich <JBeulich@xxxxxxxx> wrote:
On 31.05.14 at 03:26, <jun.nakajima@xxxxxxxxx> wrote:
On Mon, May 26, 2014 at 2:04 AM, Jan Beulich <JBeulich@xxxxxxxx> wrote:
On 26.05.14 at 10:16, <yang.z.zhang@xxxxxxxxx> wrote:
Jan Beulich wrote on 2014-05-23:
Btw., I think I just spotted a second thing not working without split page
tables:
mem-access (which doesn't and imo shouldn't depend on !need_iommu(),
other than mem-sharing and mem-paging) likewise has the potential of
creating entries resulting in IOMMU faults.

I don't know what mem-access is? Do you mean Xenaccess? If not, can you
elaborate it or provide a link to help me to understand how it works?
The (example) tool indeed is named xen-access. See XENMEM_access_op
(used to be HVMOP_{get,set}_mem_access).

The tool xen-access is located in tools/tests, and I think that this
is used mostly by developers who know what they are doing.
The tool is, indeed. But the underlying feature clearly isn't limited
to or solely intended for developers.

If we had separate VT-d page tables, they might observe confusing
results; even if they write-protect pages, somebody (i.e. I/O devices)
modifies those pages.
To me, observing IOMMU faults seems consistent with the consequence of
changes to guest memory permission.
And I would agree if these faults were restartable. You're certainly
aware that a not too large amount of faults within a reasonably short
period of time will lead to the device being turned off, with quite likely
fatal consequences to the guest.
Sure -- but there are a number of features (PoD, paging, page sharing,
even migration) which are incompatible with pass-through, and the user
is simply not allowed to use them together.  Why not just add this one
to the list?
Considering that mem-access came at about the same time or even
later than mem-paging and mem-sharing, I was silently assuming that
it wasn't enforcing the same restrictions as the other two for a reason.
Maybe it was just forgotten...

Well one can certainly imagine someone wanting to run it in that mode, and "knowing" that it would be safe because they were going to be careful not going to use memaccess on pages on which a DMA was going to happen. I think in that situation, a developer would probably want to know that their assumption was wrong immediately (by having the IOMMU fault perhaps crash the domain), than have to figure out that their assumption was wrong by having unexplainable results.

If memaccess + passthru is enabled by default at the moment, there may be an argument for disabling it by default, perhaps with an override for those who want the ability to shoot themselves in the foot. But I don't think that silent violations of the memaccess "promise" is better than just having the IOMMU faults; so I don't think that's an argument for implementing non-shared IOMMU superpages.

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

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