[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v1 4/5] kvm/x86: Hyper-V VMBus hypercall userspa

From: Paolo Bonzini
Subject: Re: [Qemu-devel] [PATCH v1 4/5] kvm/x86: Hyper-V VMBus hypercall userspace exit
Date: Wed, 20 Jan 2016 18:02:25 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0

On 20/01/2016 16:20, 'Roman Kagan' wrote:
>> > 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)?

In this case we use hypercalls. :)

However, we use a separate exit instead of putting everything under
KVM_EXIT_HYPERCALL.  This, as you mentioned, has the advantage that you
can customize it according to the calling convention (which may help
avoiding TOCTTOU issues, too).

> 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.

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).


reply via email to

[Prev in Thread] Current Thread [Next in Thread]