On Wed, Jan 20, 2016 at 06:02:25PM +0100, Paolo Bonzini wrote: > > > On 20/01/2016 16:20, 'Roman Kagan' wrote: > >> > So we should not add a new exit > > Why? VCPU exit codes are not a scarse resource. > > Indeed, but grouping makes things easier to understand. > > > So far we've envisaged two reasons for VCPU exit related to hyper-v: one > > for hyper-v MSRs and the other for hypercalls. Since there was a > > discussion on implementing generic MSR access by Peter we thought it > > wiser to introduce a new VCPU exit for hyper-v hypercalls to avoid > > interfering with the MSR implementation. > > That's a good idea. However, I think I'm not going to accept the MSR > exit feature, and then the current Hyper-V exit API makes some sense > indeed (it's just 3 values, transferring them all at once is not > expensive at all). OK can we please sum up (as I'm now a bit confused) what we do now: 1) use a single vcpu exit for both Hyper-V cases (which implies we need to fix this patchset to add the subcode for hypercalls) or 2) use individual vcpu exits for Hyper-V MSRs and for Hyper-V hypercalls (which implies we need to submit an incremental patch dropping the subcode from Hyper-V MSR exit and renaming it to better describe the reality)? Thanks, 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
