[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] memory access atomicity during HVM insn emulation on x86
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? Thanks, Jan
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |