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

["Nakajima, Jun" <jun.nakajima@xxxxxxxxx>]

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:
>>>>>> On 21.05.14 at 10:37, <yang.z.zhang@xxxxxxxxx> wrote:
>>>> Jan Beulich wrote on 2014-05-21:
>>>>> You didn't in any way negate the condition of superpage support to
>>>>> be added post-4.4 in order for your other change to go in: Neither
>>>>> http://lists.xenproject.org/archives/html/xen-devel/2014-02/msg01230.
>>>>> html
>>>>>  nor
>>>>> http://lists.xenproject.org/archives/html/xen-devel/2014-02/msg01236.
>>>>> html  have been responded to by you. By not doing so, to me at
>>>>> least you implicitly accepted the condition. And by now refusing to
>>>>> meet it, you basically tell us that we shouldn't be doing
>>>>> compromises like this with you in the future.
>>>>
>>>> I have said before I am totally unware of it. And I know it only two
>>>> days ago after someone told me. So please do not confuse this with
>>>> the thing what we are discussing now. If you think I gave a promise
>>>> implicitly at that time, I am sorry to let you think so.
>>>>
>>>> As I said in previous thread, if we can prove that add hugepage for
>>>> the separate VT-d page table is the only choice to solve problem,
>>>> then now I am promising that I will do it ASAP. But till now, I
>>>> didn't see any point that we must to have it. To me, it is still a nice to
>> have feature.
>>>
>>> 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.
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.

-- 
Jun
Intel Open Source Technology Center

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