On Tue, Dec 22, 2015 at 03:51:52PM +0300, Pavel Fedin wrote: > Hello! > > > > 1. Is there any real need to distinguish between KVM_EXIT_MSR_WRITE and > > KVM_EXIT_MSR_AFTER_WRITE ? IMHO from userland's point of view these are the same. > > > > Indeed. Perhaps the kernel can set .handled to true to let userspace > > know it already took care of it, instead of introducing yet another > > exit_reason. The field would need to be marked in/out, then. > > I'm not sure that you need even this. Anyway, particular MSRs are function-specific, and if you're emulating an MSR in userspace, > then, i believe, you know the function behind it. And it's IMHO safe to just know that SynIC MSRs have some extra handling in > kernel. And i believe this has no direct impact on userland's behavior. It has: unlike the scenario that was the original motivation for Peter's patches, where the the userspace wanted to handle register accesses which the kernel *didn't*, in case of SynIC the userspace wants do something about MSR accesses *only* if the kernel *also* handles them. I guess that was the reason why Paolo suggested an extra exit_reason, and I think .handled field can be used to pass that information instead. You're probably right that, at least in SynIC case, it should be safe to assume that, if all the SynIC setup succeeded, the corresponding MSR accesses would only trigger exits when the kernel processed them appropriately. But the proposed use of .handled costs basically nothing, and it may prove useful in general (as a conisistency proof, if anything). Roman. -- 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
