Re: [Xen-devel] [PATCH 0 of 2] Add libxc API that sets mem_access type for an array of gfns

[Aravindh Puthiyaparambil <aravindh@xxxxxxxxxxxx>]

On Fri, Apr 27, 2012 at 10:37 AM, Christian Limpach
<christian.limpach@xxxxxxxxx> wrote:
> On Thu, Apr 26, 2012 at 6:36 PM, Aravindh Puthiyaparambil
> <aravindh@xxxxxxxxxxxx> wrote:
>>
>> On Apr 26, 2012 6:06 PM, "Christian Limpach" <christian.limpach@xxxxxxxxx>
>> wrote:
>>>
>>> Maybe you can do something similar, for example passing in a hint
>>> whether ept_sync_domain needs to be done or not.  In my case, the
>>> reasoning is that all the entries changed from hap_clean_vram_tracking
>>> are leaf entries, so ept_free_entry will never be called and thus
>>> ept_sync_domain can be deferred.  I didn't think through/consider the
>>> iommu case since that code is commented out in my tree.
>>
>> I thought about doing that initially. But then in the bulk case I would
>> always have to call ept_sync_domain() to be on the safe side. But if the
>> iommu case forces me down that path, then I guess I have no choice.
>
> I think you should re-consider.  It would avoid adding the extra
> wrapper, which makes this code a lot less readable.  Plus it avoids
> the need for the old_entries array.
>
> Let me re-iterate:
> - if it's a leaf entry, then there's no need to call ept_free_entry
> - if you don't need to call ept_free_entry, then you can defer
> ept_sync_domain (subject to the iommu case)
> - you could pass in a pointer to a bool to indicate to the caller that
> ept_sync_domain was deferred and that the caller needs to do it, with
> a NULL pointer indicating that the caller doesn't support defer

I understand now and like this approach. I will rework the patch and
send it out.

Thanks,
Aravindh

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