[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH v5 2/4] x86/HVM: implement memory read caching for insn emulation

On 10.03.2020 03:39, Tian, Kevin wrote:
>> From: Jan Beulich <jbeulich@xxxxxxxx>
>> Sent: Tuesday, March 3, 2020 6:17 PM
>> 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
> ah, I was not aware of such form. I thought the emulation is split
> into two phases: decoding and send i/o request to device model, and
> then completing inst emulation with device model's response and
> previously-decoded information... 

In theory this would be an option, but would require storing quite
a bit more information to be able to resume without going through
decode again. Plus it's not decode alone which matters, page walks
during the execution phase, for example, also need to match.

>> registers goes (as those can't change without any other instruction
>> executing in between [1]), 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 read a memory operand successfully, any
>> subsequent pass needs to get to see the exact same value.
>> Introduce a 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); this is sufficient
>> for the immediate purpose of making re-execution an exact replay. The
>> cache also won't be used just yet for guest page walks; that'll be the
>> subject of a subsequent change.
> a cache implies that the aforementioned two-pass problem is only
> mitigated instead of completely fixed?

No, aiui the English word "cache" is broader than what it's typically
used for with computers in mind - see e.g. its use in "geocaching". I
realize the use of the word here may cause misunderstandings, but my
seek of a better term in earlier versions hasn't really led to any
suggestions I'd consider strictly better.

> btw is there any performance impact from this patch?

Since correctness is the goal, I didn't think I'd need to measure
things to support the utility of the changes.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.