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

["Jan Beulich" <JBeulich@xxxxxxxx>]

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

Jan


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