On Wed, Jan 20, 2016 at 02:59:08PM +0100, Paolo Bonzini wrote:
> >> --- a/Documentation/virtual/kvm/api.txt
> >> +++ b/Documentation/virtual/kvm/api.txt
> >> @@ -3359,6 +3359,14 @@ Hyper-V SynIC state change. Notification is used to remap SynIC
> >> event/message pages and to enable/disable SynIC messages/events processing
> >> in userspace.
> >>
> >> + /* KVM_EXIT_HYPERV_HCALL */
> >> + struct {
> >> + __u64 input;
> >> + __u64 params[2];
> >> + __u64 result;
> >> + } hv_hcall;
> >> +Indicates that the VCPU exits into userspace to process some guest
> >> +Hyper-V hypercalls.
> >
> > Why introducing this? We already have KVM_EXIT_HYPERCALL, which is
> > exactly the same. AFAIK it's not used at the moment.
> > Additionally, in theory we could have hypercalls handled in
> > userspace for something else except HyperV. And not only for x86.
>
> Because, as the docs say, we don't want to do that. We want to use
> KVM_EXIT_IO or KVM_EXIT_MMIO, with two exceptions: s390 and wherever we
> can't do that for compatibility purposes.
I must admit I saw this part in the docs but failed to understand it.
Is it supposed to mean that we want to avoid using hypercalls as a means
of guest communications with the host userspace in general, and use PIO
or MMIO instead, unless hypercalls are mandated by a guest implemenation
we can't affect (as is the case for Hyper-V)?
Because *implementing* Hyper-V hypercalls in terms of KVM_EXIT_IO or
KVM_EXIT_MMIO looked hard at best.
> So we should not add a new exit
Why? VCPU exit codes are not a scarse resource.
> (I suggested elsewhere the existing hyper-v exit)
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.
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
