[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 1:20 PM, Christian Limpach
<christian.limpach@xxxxxxxxx> wrote:
> On Thu, Apr 26, 2012 at 11:33 AM, Aravindh Puthiyaparambil
> <aravindh@xxxxxxxxxxxx> wrote:
>> When the mem_access type needs to be changed for multiple discontiguous 
>> gfns, calling xc_hvm_set_mem_access() multiple times does not perform very 
>> well. The main pain points are the multiple libxc calls themselves plus the 
>> multiple map_domain_page() / unmap_domain_page() and ept_sync_domain() calls 
>> for each ept_set_entry(gfn). The following patches adds a new mem_access API 
>> that sets the mem_access type for an array of guest physical addresses in 
>> one libxc call with minimal map_domain_page() / unmap_domain_page() and 
>> ept_sync_domain() calls.
>
>
> Are you sure that your bulk code actually works?  It seems to me that
> your __ept_set_entry function assumes that table still points to the
> top of the p2m.  The "for ( i = ept_get_wl(d); i > target; i-- )" loop
> will walk the table, and so in the subsequent calls from your bulk
> loop, this won't work?
>
> I think you need something like an iterator, the context of which can
> be passed around...

Duh! You are right. My test code has been giving me a false positive.
I completely misread how ept_next_level() works.

> Also, the call to ept_get_entry in your bulk loop will do a walk in
> every iteration, it seems a bit arbitrary to only (try to) avoid one
> and not the other.  But I guess the "win" is from reducing the number
> of ept_sync_domain calls.

You are right. I was mainly focusing on removing the multiple libxc
calls and reducing the ept_sync_domain calls. I thought removing the
map and unmap of the p2m top page was an extra optimization which I
obviously messed up. I will rework the patch to only stick with the
original optimization I had in mind.

Thanks,
Aravindh

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