Re: [Xen-devel] [PATCH v5 05/10] x86emul: support MOVDIR64B insn

[Jan Beulich <jbeulich@xxxxxxxx>]

On 25.03.2020 12:19, Paul Durrant wrote:
>> -----Original Message-----
>> From: Xen-devel <xen-devel-bounces@xxxxxxxxxxxxxxxxxxxx> On Behalf Of Jan 
>> Beulich
>> Sent: 24 March 2020 12:34
>> To: xen-devel@xxxxxxxxxxxxxxxxxxxx
>> Cc: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>; Paul Durrant 
>> <Paul.Durrant@xxxxxxxxxx>; Wei Liu
>> <wl@xxxxxxx>; Roger Pau Monne <roger.pau@xxxxxxxxxx>
>> Subject: [Xen-devel] [PATCH v5 05/10] x86emul: support MOVDIR64B insn
>>
>> Introduce a new blk() hook, paralleling the rmw() on in certain way, but
>> being intended for larger data sizes, and hence its HVM intermediate
>> handling function doesn't fall back to splitting the operation if the
>> requested virtual address can't be mapped.
>>
>> Note that SDM revision 071 doesn't specify exception behavior for
>> ModRM.mod == 0b11; assuming #UD here.
>>
>> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
>> ---
>> TBD: If we want to avoid depending on correct MTRR settings,
>>      hvmemul_map_linear_addr() may need to gain a parameter to allow
>>      controlling cachability of the produced mapping(s).
> 
> Or could we deal with this by adding an optional cache flush into the unmap?

But (non-)cachability of a range can't generally by covered by
simply flushing the cache.

>> Of course the
>>      function will also need to be made capable of mapping at least
>>      p2m_mmio_direct pages for this and the two ENQCMD insns to be
>>      actually useful.
> 
> 
> I/O emulation parts LGTM so...
> 
> Reviewed-by: Paul Durrant <paul@xxxxxxx>

Thanks much.

Jan