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

[Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>]

On 10/2/18 6:39 AM, Jan Beulich wrote:
>>>> 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: Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>

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