On 23/08/2019 00:06, Tamas K Lengyel wrote: > On Thu, Aug 22, 2019 at 4:40 PM Andrew Cooper <andrew.coop...@citrix.com> > wrote: >> On 22/08/2019 21:57, Rich Persaud wrote: >>>> On Aug 22, 2019, at 09:51, Andrew Cooper <andrew.coop...@citrix.com> wrote: >>>> >>>>> On 22/08/2019 03:06, Johnson, Ethan wrote: >>>>> >>>>> For HVM, obviously anything that can't be virtualized natively by the >>>>> hardware needs to be emulated by Xen/QEMU (since the guest kernel isn't >>>>> expected to be cooperative to issue PV hypercalls instead); but I would >>>>> expect emulation to be limited to the relatively small subset of the ISA >>>>> that VMX/SVM can't natively virtualize. Yet I see that x86_emulate.c >>>>> supports emulating just about everything. Under what circumstances does >>>>> Xen actually need to put all that emulation code to use? >>>> Introspection, as I said earlier, which is potentially any instruction. >>> Could introspection-specific emulation code be disabled via KConfig? >> Not really. >> >> At the point something has trapped for emulation, we must complete it in >> a manner consistent with the x86 architecture, or the guest will crash. >> >> If you don't want emulation from introspection, don't start >> introspecting in the first place, at which point guest actions won't >> trap in the first place. > That's incorrect, you can absolutely do introspection with vm_events > and NOT emulate anything. You can have altp2m in place with different > memory permissions set in different views and switch between the views > with MTF enabled to allow the system to continue executing. This does > not require emulation of anything. I would be behind a KCONFIG option > that turns off parts of the emulator that are only used by a subset of > introspection usecases. But this should not be an option that turns > off introspection itself, the two things are NOT inter-dependent.
I fear we are getting slightly off track here, but I'll bite... Introspection is a young technology, with vast potential. This is great - it means there is a lot of novel R&D going into it. It doesn't mean that all aspects of it are viable for use by customers today. I'll have an easier time believing that altp2m is close to being production ready when I no longer fine security-relevant bugs in it every time I go looking, and someone has made a coherent attempt to justify it being security supported. None of this alters the fact that introspection in general is one key factor as to why we have a mostly-complete x86_emulate() (even if "x86 emulate" is a slightly poor choice of name. "decode and replay" would be a far more apt description of what it does for the majority of instructions.) ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
