Re: [Xen-devel] Ping: [PATCH v3 3/4] x86/HVM: implement memory read caching

["Tian, Kevin" <kevin.tian@xxxxxxxxx>]

> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
> Sent: Tuesday, October 2, 2018 6:39 PM
> 
> >>> On 25.09.18 at 16:25, <JBeulich@xxxxxxxx> 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 <jbeulich@xxxxxxxx>
> > Acked-by: Tim Deegan <tim@xxxxxxx>
> > Reviewed-by: Paul Durrant <paul.durrant@xxxxxxxxxx>
> 
> SVM and VMX maintainers?
> 

Reviewed-by: Kevin Tian <kevin.tian@xxxxxxxxx>

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel