[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. Thanks, Razvan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |