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

[George Dunlap <George.Dunlap@xxxxxxxxxxxxx>]

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?

 -George

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