On 02/08/2017 16:17, Mihai Donțu wrote: > On Wed, 2017-08-02 at 15:51 +0200, Paolo Bonzini wrote: >> On 02/08/2017 15:32, Mihai Donțu wrote: >>> We have currently identified three cases: >>> >>> * initial hooking of a guest >> >> What triggers the initial hooking, and how is it done? > > There are two types o hooks: dynamic (the guest is hooked as it boots) > and static (a fully booted guest is being hooked). They both start with > a notification from qemu or some other application that a guest is > available for introspection. After that we poke its vCPU-s a few times > to determine what type of hooking to continue with. I belive the > syscall entry point MSR-s are key here. Reads need not be transactional here, and the syscall entry point MSRs are generally immutable so I think it is fine not to pause. I'm curious how the introspector decides that the guest is ready to be hooked in, that is, that it's far enough in the boot process. I think a command to "pause" KVM_RUN is okay to add. That is, if in KVM_RUN it would e.g. return 1, trigger a 'paused' event immediately and halt the vCPU. If not in KVM_RUN, the command would return 0 and trigger the 'paused' event as soon as the hypervisor invokes KVM_RUN. The introspector then can decide whether to wait if the commands return 0. There is no need for an "unpause" command, as that is achieved simply by completing the 'paused' event. >> Have you thought about monitoring hardware registers, for example in >> order to check that IOMMU page tables protect from overwriting the kernel? > > Sorry, but I'm not sure I understand: are you thinking at a way to make > sure none of the IOMMU grups are configured with a "too generous" DMA > window? Yes, exactly. Optional, of course. Paolo
