qemu-devel
[Top][All Lists]
Advanced

[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: 'Roman Kagan'
Subject: Re: [Qemu-devel] [PATCH v1 4/5] kvm/x86: Hyper-V VMBus hypercall userspace exit
Date: Thu, 14 Jan 2016 14:52:23 +0300
User-agent: Mutt/1.5.24 (2015-08-30)

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.



reply via email to

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