On Thu, Jan 14, 2016 at 01:50:20PM +0300, Pavel Fedin wrote: > > We thought reusing KVM_EXIT_HYPERCALL was a bad idea exactly because of > > that. Hypercalls are not universal, the calling and return conventions > > are hypervisor-specific. > > Treatment of them is hypervisor-specific, but from CPUs point of view they are the same. You load something into registers, and > execute hypercall instruction. ... and you get something in the registers on return (all that is from guest POV). Right. The differences are, however, which registers are used for parameters and return values, how they are encoded, etc. > So, you just need to pass registers in your structure. Which ones? This is going to be hypervisor- and arch-specific. > Or, you could even use generic register access APIs. With an extra ioctl? This is going to be expensive. > > KVM already has to make the decision that the > > particular vmexit is a HyperV hypercall; it appears unnatural to then > > pass the data on to userspace in a generic structure and have them make > > that decision again. > > Is it so difficult to make such a decision? The userland already knows what we are emulating. It isn't terribly difficult, but KVM has to do all that already, as it handles some of the hypercalls in the kernel. I don't think duplicating this (and also designing a generic marshalling scheme) is profitable compared to saving a vcpu exit code. > I'm afraid that in future we can end up in having 10 versions of KVM_EXIT_xxx_HYPERCALL with very small difference between them. > Will it be good? I don't see it to be a problem. 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
