Re: [Xen-devel] Xen EPT modifications and interceptions

[Tim Deegan <Tim.Deegan@xxxxxxxxxx>]

Hi,

At 03:00 +0000 on 03 Feb (1265166046), ken mark wrote:
> We use map_domain_page to map the ept table that contains the target
> entry. After changing the access bits in that entry, we use
> unmap_domain_page to activate the modification.

unmap_domain_page() won't "activate" anything; it just indicates that
you're done with the mapping.  On 64-bit Xen it's a no-op.

> But it seems that when we again map the ept table and fetch the exact
> entry we've modified just before, our modifications haven't taken
> effect.

Sorry to ask the obvious questions, but:
 - Are you sure you're mapping the right entry?  Is it the same MFN
   both times?
 - Have you tried tracking all other mappings of the same page to see if 
   it's put back in between?
 - Are you running a multiprocessor system?  Do you hve sufficient locking
   around the operation to stop confusion from simultaneous changes on
   other CPUs?  The EPT code has historically been lacking in this area.

> Any sometimes the modification will cause interception while in some
> cases it doesn'. Is there anything to do which our using of map/unmap
> functions? Or do we need to flush something when we have made the
> modifications? 

Yes, you need to flush the EPT entries from TLBs before changes will
take place.  You need to call hvm_flush_guest_tlbs() on every CPU in the
guest's domain_dirty_cpumask.  Xen's normal flush_tlb_mask() operation
does this as a side-effect.

Cheers,

Tim.

-- 
Tim Deegan <Tim.Deegan@xxxxxxxxxx>
Principal Software Engineer, Citrix Systems (R&D) Ltd.
[Company #02300071, SL9 0DZ, UK.]

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel