On Fri, Dec 18, 2015 at 8:01 AM, Paolo Bonzini <pbonzini@xxxxxxxxxx> wrote: > > > On 18/12/2015 16:19, Pavel Fedin wrote: >> As far as i understand this code, KVM_EXIT_HYPERV is called when one >> of three MSRs are accessed. But, shouldn't we have implemented >> instead something more generic, like KVM_EXIT_REG_IO, which would >> work similar to KVM_EXIT_PIO or KVM_EXIT_MMIO, but carry register >> code and value? > > Yes, we considered that. There were actually patches for this as well. > However, in this case the register is still emulated in the kernel, and > userspace just gets informed of the new value. On brief inspection of Andrey's patch (I have not been following closely) it looks like the kvm_hyperv_exit struct that's returned to userspace contains more data (control, evt_page, and msg_page fields) than simply the value of the MSR, so would the desired SynIC exit fit into a general-purpose exit for MSR emulation? >> This would allow us to solve the same task which we have done here, >> but this solution would be reusable for other devices and other >> archirectures. What if in future we have more system registers to >> emulate in userspace? > > If we do get that, we will just rename KVM_EXIT_HYPERV to > KVM_EXIT_MSR_ACCESS, and KVM_EXIT_HYPERV_SYNIC to > KVM_EXIT_MSR_HYPERV_SYNIC, and struct kvm_hyperv_exit to kvm_msr_exit. > > Actually, we can do it now. What do you guys think? Peter? I might > even be convinced to document the capability (in Documentation/ and > uapi/) even if the upstream kernel doesn't provide it. We still have a > lot of time until 4.5 is out, it can be done after the merge window even. I will update and re-send that patchset for discussion. > > Paolo > >> I write this because at one point i suggested similar thing for ARM64 >> (but i never actually wrote it), to emulate physical CP15 timer. And >> it would require exactly the same capability - process some trapped >> system register accesses in userspace. Peter -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
