On 13/03/17 11:05, Jan Beulich wrote: > When an FPU instruction with a memory destination fails during the > memory write, it should not affect FPU register state. Due to the way > we emulate FPU (and SIMD) instructions, we can only guarantee this by > - backing out changes to the FPU register state in such a case or > - doing a descriptor read and/or page walk up front, perhaps with the > stubs accessing the actual memory location then. > The latter would require a significant change in how the emulator does > its guest memory accessing, so for now the former variant is being > chosen. > > Signed-off-by: Jan Beulich <jbeul...@suse.com>
Reviewed-by: Andrew Cooper <andrew.coop...@citrix.com> > --- > Note that the state save overhead (unless state hadn't been loaded at > all before, which should only be possible if a guest is fiddling with > the instruction stream under emulation) is taken for every FPU insn > hitting the emulator. We could reduce this to just the ones writing to > memory, but that would involve quite a few further changes and > resulting code where even more code paths need to match up with one > another. An FPU save isn't the slow part of hitting emulation. I don't expect this will be a meaningful overhead. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
