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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> 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.

Jan


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