Re: [PATCH v1 4/5] kvm/x86: Hyper-V VMBus hypercall userspace exit

From: 'Roman Kagan' <rkagan@virtuozzo.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: Pavel Fedin <p.fedin@samsung.com>,
	'Andrey Smetanin' <asmetanin@virtuozzo.com>,
	<kvm@vger.kernel.org>, 'Gleb Natapov' <gleb@kernel.org>,
	'Joerg Roedel' <joro@8bytes.org>,
	"'K. Y. Srinivasan'" <kys@microsoft.com>,
	'Haiyang Zhang' <haiyangz@microsoft.com>,
	"'Denis V. Lunev'" <den@openvz.org>, <qemu-devel@nongnu.org>
Subject: Re: [PATCH v1 4/5] kvm/x86: Hyper-V VMBus hypercall userspace exit
Date: Wed, 20 Jan 2016 18:20:35 +0300	[thread overview]
Message-ID: <20160120152034.GA3947@rkaganb.sw.ru> (raw)
In-Reply-To: <569F92AC.4030506@redhat.com>

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.