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

[George Dunlap <george.dunlap@eu.citrix.com>]

On 06/02/2014 03:27 PM, Jan Beulich wrote:
>>>> On 02.06.14 at 16:06, <George.Dunlap@eu.citrix.com> wrote:
>> On Mon, Jun 2, 2014 at 7:55 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>>>> On 31.05.14 at 03:26, <jun.nakajima@intel.com> wrote:
>>>> On Mon, May 26, 2014 at 2:04 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>>>>>> On 26.05.14 at 10:16, <yang.z.zhang@intel.com> 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