On 10/12/2018 03:19 PM, Jan Beulich wrote: >>>> On 12.10.18 at 15:55, <andrew.coop...@citrix.com> wrote: >> On 11/09/18 14:10, Jan Beulich wrote: >>> Emulation requiring device model assistance uses a form of instruction >>> re-execution, assuming that the second (and any further) pass takes >>> exactly the same path. This is a valid assumption as far as use of CPU >>> registers goes (as those can't change without any other instruction >>> executing in between), but is wrong for memory accesses. In particular >>> it has been observed that Windows might page out buffers underneath >>> an instruction currently under emulation (hitting between two passes). >>> If the first pass translated a linear address successfully, any subsequent >>> pass needs to do so too, yielding the exact same translation. >>> >>> Introduce a cache (used just by guest page table accesses for now, i.e. >>> a form of "paging structure cache") to make sure above described >>> assumption holds. This is a very simplistic implementation for now: Only >>> exact matches are satisfied (no overlaps or partial reads or anything). >>> >>> There's also some seemingly unrelated cleanup here which was found >>> desirable on the way. >>> >>> 1: x86/mm: add optional cache to GLA->GFN translation >>> 2: x86/mm: use optional cache in guest_walk_tables() >>> 3: x86/HVM: implement memory read caching >>> 4: x86/HVM: prefill cache with PDPTEs when possible >>> >>> "VMX: correct PDPTE load checks" is omitted from v2, as I can't >>> currently find enough time to carry out the requested further >>> rework. >> >> Following the x86 call, I've had some thoughts and suggestions about how >> to make this work in a reasonable way, without resorting to the full >> caching approach. > > Thanks, but one question before I start thinking about this in > more detail: Before writing this, did you read my mail from the > 11th? I ask because what you suggest does not look to match > the behavior I've described there as what I think it ought to be.
I'm taking this off my to-review queue for now then -- let me know if you need me to review it anyway. -George _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
