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

Re: [Xen-devel] X86 Community Call: Wed March 14, 15:00 - 16:00 UTC - Meeting Minutes

On 04/11/2018 08:10 PM, Lars Kurth wrote:
> ### [PATCH RFC 00/14] EPT-Based Sub-page Write Protection Support
> ### (​Zhang Yi)
> RFC posted by Zhang Yi Oct 19, 2017
> https://marc.info/?l=xen-devel&m=
> https://xen.markmail.org/thread/m75h6b2aiwk5h7fx
> No acks, reviews only by memaccess maintainers / developers
> Issues: Use case for the feature is still not clear and needs discussion
> Lars: who needs to review?
> Andrew: mainly George, Tamas, Razvan - major changes to ept2pm structure 
> (different
> page table structure) and Andrew.
> Andrew: did take a quick look. Nothing egregious in it. Did not have a lot of 
> free time to look
> at it.
> George: was going to look at it, but focus on NVDIMM first and EPT stuff 
> second.
> Tamas: provides write protection on the sub-page - my tools don't have a 
> use-case for this.
> Also not sure how this would integrate into alt2pm. Razvan may have a 
> use-case.
> Andrew: no interaction with alt2pm, write protection 128 byte aligned 
> granularity instead of
> 4K for write tracking a substructure within a page
> Zhang Yi: I have a change in the patch which he wants to look at
> George: can look at modifying that or store the type information elsewhere
> Andrew: Have to shuffle the bits in the EPT tree
> Summary: the issue isn’t really about use-cases, but primarily about 
> prioritizing George’s
> bandwidth
> **ACTION (April):** ​ Andrew will poke Razvan (give some indication interface 
> ios going)
> **ACTION (April):** ​George will pick this up after NVDIMM has made some 
> progress

Indeed we do have use cases for this and are very interested in the
feature. As you might expect, this is about optimizing: in several cases
we're only interested in a narrow part of a page, but need to set
restrictions on 4096 bytes - this causes needless page fault exits /
mem_access events.

It would indeed need to play well with altp2m to be as useful as possible.

Our use case for altp2m (assuming a stable altp2m - I'm still debugging
the logdirty VGA issue) is to use it for 1) the cases where the emulator
doesn't know an instruction that has caused a page fault (in which case
we get an UNIMPLEMENTED vm_event), and 2) as a workaround for a
interrupt race issue that can happen with emulation.

2) is hopefully a temporary problem, 1) is probably not - new
instructions do appear with new hardware.


Xen-devel mailing list



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