On 01/07/2019 12:56, Jan Beulich wrote: > The hook is already in use for other purposes, and emulating e.g. > CLFLUSH by issuing WBINVD is, well, not very nice. Rename the hook and > add parameters. Use lighter weight flushing insns when possible in > hvmemul_cache_op(). > > hvmemul_cache_op() treating x86emul_invd the same as x86emul_wbinvd is > to retain original behavior, but I'm not sure this is what we want in > the long run.
There is no use for INVD in a VM, as it is never running with the memory controllers yet-to-be configured. The only place it may be found is at the reset vector for a firmware which doesn't start in a virtualisation-aware way. Given how big a hammer WBINVD is, I reckon we should just nop it out. > > Signed-off-by: Jan Beulich <[email protected]> Reviewed-by: Andrew Cooper <[email protected]> > --- > v2: Use cache_op() as hook name. Convert macros to inline functions in > system.h. Re-base. > --- > I was unsure about PREFETCH* and CLDEMOTE - both are cache management > insns too, but the emulator currently treats them as a NOP without > invoking any hooks. They are just hints. Nothing architecturally may depend on them having any effect. CLDEMOTE in particular is for reducing cache coherency overhead on a producer/consumer setup, but any potential optimisation is dwarfed by the VMExit. > I was also uncertain about the new cache_flush_permitted() instance - > generally I think it wouldn't be too bad if we allowed line flushes in > all cases, in which case the checks in the ->wbinvd_intercept() handlers > would suffice (as they did until now). This is a more general issue which we need to address. To support encrypted memory in VM's, we must guarantee that WC mappings which the guest creates are really WC, which means we must not use IPAT or play any "fall back to WB" games. Furthermore, AMD's encrypt-in-place algorithm requires the guest to be able to use WBINVD. Fixing this properly will be a good thing, and will fix the fact that at the moment, any time you give a PCI device to a guest, its blk/net perf becomes glacial, due to having the grant table being uncached. > + > + if ( hvmemul_ctxt->seg_reg[x86_seg_ss].dpl == 3 ) > + pfec |= PFEC_user_mode; As a note, this is fine here, but this whole system of choosing pfec needs to be adjusted when we add support for WRUSS, which is a CPL0 instruction that executed as a user mode write, for adjusting the user shadow stack. ~Andrew _______________________________________________ Xen-devel mailing list [email protected] https://lists.xenproject.org/mailman/listinfo/xen-devel
