Re: memory access atomicity during HVM insn emulation on x86

[Jan Beulich <jbeulich@xxxxxxxx>]

On 02.03.2023 10:23, Paul Durrant wrote:
> 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?

The question isn't the guest RAM access, but the guest accessing non-RAM
(which is why the device model is being engaged). Both a RAM and an MMIO
access can happen with a pretty limited set of insns only anyway. Among
those are none of the 16-byte accessing insns (they're all loads from or
stores to memory, with the other operand being an XMM register).

Jan