[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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

     christian

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.