[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: memory access atomicity during HVM insn emulation on x86
On 02/03/2023 08:35, Jan Beulich wrote:
Hello,
in (I think) Intel SDM version 076 a new guarantee of atomicity of certain
aligned 16-byte accesses appeared. While initially I thought this would be
another special case we need to invent a solution for (it still is, in
certain cases, as per further down), I had to realize that we don't even
guarantee atomicity of smaller accesses, including as simple ones as plain
16-, 32-, or 64-bit moves. All read/write operations are handled by the
very generic __hvm_copy(), which invokes memcpy() / memset(), which in
turn do byte-wise copies unless the compiler decides to inline the
operations (which from all I can tell it won't normally do for the uses in
__hvm_copy()).
The question here is whether to make __hvm_copy() handle the guaranteed-
aligned cases specially, or whether to avoid making use of that function
in those cases (i.e. deal with the cases in linear_{read,write}()). Both
options have their downsides (complicating a core function vs duplicating
a certain amount of code).
As to 16-byte atomic accesses: The SDM doesn't restrict this to WB memory.
As a result, in order to implement this correctly, we cannot just utilize
the rmw() or blk() hooks, as these expect to operate on guest RAM (which
they can map and then access directly). Instead the path invoking the
device model will also need to cope. Yet the ioreq interface is limited
to 64 bits of data at a time (except for the data_is_ptr case, which imo
has to be considered inherently non-atomic). So it looks to me that as a
prereq to fully addressing the issue in the hypervisor we need an
extension to the ioreq interface.
Thoughts anyone?
Does the interface need modification? As long as 16-bytes are copied
to/from guest RAM in an atomic way then how that data is passed to/from
a device model shouldn't affect it, should it? (As you say, data_is_ptr
is a different problem).
Paul
|
