On 10/2/18 6:39 AM, Jan Beulich wrote: >>>> On 25.09.18 at 16:25, <jbeul...@suse.com> 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 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 by just guest page table accesses for now) 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). >> >> As to the actual data page in this scenario, there are a couple of >> aspects to take into consideration: >> - We must be talking about an insn accessing two locations (two memory >> ones, one of which is MMIO, or a memory and an I/O one). >> - If the non I/O / MMIO side is being read, the re-read (if it occurs at >> all) is having its result discarded, by taking the shortcut through >> the first switch()'s STATE_IORESP_READY case in hvmemul_do_io(). Note >> how, among all the re-issue sanity checks there, we avoid comparing >> the actual data. >> - If the non I/O / MMIO side is being written, it is the OSes >> responsibility to avoid actually moving page contents to disk while >> there might still be a write access in flight - this is no different >> in behavior from bare hardware. >> - Read-modify-write accesses are, as always, complicated, and while we >> deal with them better nowadays than we did in the past, we're still >> not quite there to guarantee hardware like behavior in all cases >> anyway. Nothing is getting worse by the changes made here, afaict. >> >> Signed-off-by: Jan Beulich <jbeul...@suse.com> >> Acked-by: Tim Deegan <t...@xen.org> >> Reviewed-by: Paul Durrant <paul.durr...@citrix.com> > SVM and VMX maintainers?
Reviewed-by: Boris Ostrovsky <boris.ostrov...@oracle.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
