Re: [Xen-devel] More questions about Xen memory layout/usage, access to guest memory

[Tamas K Lengyel <tamas.k.lengyel@xxxxxxxxx>]

On Thu, Aug 22, 2019 at 4:40 PM Andrew Cooper <andrew.cooper3@xxxxxxxxxx> wrote:
>
> On 22/08/2019 21:57, Rich Persaud wrote:
> >> On Aug 22, 2019, at 09:51, Andrew Cooper <andrew.cooper3@xxxxxxxxxx> 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.

Tamas

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel