From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christian Limpach Subject: Re: [PATCH 0 of 2] Add libxc API that sets mem_access type for an array of gfns Date: Fri, 27 Apr 2012 10:37:55 -0700 Message-ID: References: Reply-To: Christian.Limpach@gmail.com Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Aravindh Puthiyaparambil Cc: tim@xen.org, xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org On Thu, Apr 26, 2012 at 6:36 PM, Aravindh Puthiyaparambil wrote: > > On Apr 26, 2012 6:06 PM, "Christian Limpach" > wrote: >> >> Maybe you can do something similar, for example passing in a hint >> whether ept_sync_domain needs to be done or not. =A0In 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. =A0I 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