On 03.04.2020 01:12, Andrew Cooper wrote: > On 24/03/2020 12:34, Jan Beulich wrote: >> 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 <jbeul...@suse.com> > > Acked-by: Andrew Cooper <andrew.coop...@citrix.com>
Thanks much, but I'm puzzled by you providing this, and hence would like to double check: You specifically asked that I take care of the cachability issue for MOVDIRI before you would ack that change. How come you're not similarly concerned here? >> --- >> 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). 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. > > MOVDIR64B isn't the first instruction to demonstrate this corner case, > but we do need to organise something to solve this problem. I'm > confident it will cause real memory corruption issue for encrypted > memory VMs under introspection. Besides the named ones and MOVDIRI, which other ones are you talking about? Jan
