On 04/08/2017 17:29, Mihai Donțu wrote: > On Fri, 2017-08-04 at 10:35 +0200, Paolo Bonzini wrote: >> 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 might be misunderstanding. Entry point MSR-s (and maybe others) are > generally immutable in well behaving guests. We are, however, looking > for signs that something is breaking this pattern. Right but you can always set up an MSR write intercept even before the guest starts. The MSRs are written rarely-enough that the intercept doesn't add any noticeable overhead. Reading the MSR while the guest runs is okay. If races are important, the introspectors can detect them through the intercepts it sets up. In many cases races are not an issue even (for example, in MTRRs). >> 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. > > This mechanism will allow exposing a KVMI_PAUSE_VCPU to introspectors, > something that maybe some future users can leverage. I, however, was > trying to justify a "slow" KVMI_PAUSE_VM and "fast" kvm_pause_vcpu(), > the latter existing only in KVM (kernel). The event-based mecanism for > pausing a vCPU feels like it has too much overhead for what one usually > needs it (read some registers). My point is that usually even register reads (actually MSRs) do not require a pause. The event-based mechanism would be used only for the initial hooking. KVMI_PAUSE_VM would require QEMU communication, wouldn't it? > Also, I belive we have refined a number of ideas on this thread and > more remain to clarify. I would like to update the design document with > what we have agreed on so far, add some more details to what felt > 'under explained' and continue again from there. Is it OK for you? Yes. Pausing is the last issue that needs to be clarified. Paolo
