On 07/16/2013 01:35:55 AM, Gleb Natapov wrote:
On Mon, Jul 15, 2013 at 01:17:33PM -0500, Scott Wood wrote:
> On 07/15/2013 06:30:20 AM, Gleb Natapov wrote:
> >There is no much sense to share hypercalls between architectures.
> >There
> >is zero probability x86 will implement those for instance
>
> This is similar to the question of whether to keep device API
> enumerations per-architecture... It costs very little to keep it in
> a common place, and it's hard to go back in the other direction if
> we later realize there are things that should be shared.
>
This is different from device API since with device API all arches
have
to create/destroy devices, so it make sense to put device lifecycle
management into the common code, and device API has single entry point
to the code - device fd ioctl - where it makes sense to handle common
tasks, if any, and despatch others to specific device implementation.
This is totally unlike hypercalls which are, by definition, very
architecture specific (the way they are triggered, the way parameter
are passed from guest to host, what hypercalls arch needs...).
The ABI is architecture specific. The API doesn't need to be, any more
than it does with syscalls (I consider the architecture-specific
definition of syscall numbers and similar constants in Linux to be
unfortunate, especially for tools such as strace or QEMU's linux-user
emulation).
> Keeping it in a common place also makes it more visible to people
> looking to add new hcalls, which could cut down on reinventing the
> wheel.
I do not want other arches to start using hypercalls in the way
powerpc
started to use them: separate device io space, so it is better to hide
this as far away from common code as possible :) But on a more serious
note hypercalls should be a last resort and added only when no other
possibility exists, so people should not look what hcalls others
implemented, so they can add them to their favorite arch, but they
should have a problem at hand that they cannot solve without hcall,
but
at this point they will have pretty good idea what this hcall should
do.
Why are hcalls such a bad thing?
Should new Linux syscalls be avoided too, in favor of new emulated
devices exposed via vfio? :-)
> >(not sure why PPC will want them either instead of emulating
> >devices that do
> >shutdown/reset).
>
> Besides what Alex said, for shutdown we don't have any existing
> device to emulate (our real hardware just doesn't have that
> functionality). For reset we currently do emulate, but it's awkward
> to describe in the device tree what we actually emulate since the
> reset functionality is part of a kitchen-sink "device" of which we
> emulate virtually nothing other than the reset. Currently we
> advertise the entire thing and just ignore the rest, but that causes
> problems with the guest seeing the node and trying to use that
> functionality.
>
What about writing virtio device for shutdown
That sounds like quite a bit more work than hcalls. It also ties up a
virtual PCI slot -- some machines don't have very many (mpc8544ds has
2, though we could and should expand that in the paravirt e500 machine).
and add missing emulation
to kitchen-sink device (yeah I know easily said that done),
Not going to happen... there's lots of low-level and chip-specific
stuff in there. We'd have to make several versions, even for the
paravirt platform so it would correspond to some chip that goes with
the cpu being used. Even then we couldn't do everything, at least with
KVM -- one of the things in there is the ability to freeze the
timebase, but reading the timebase doesn't trap, and we aren't going to
freeze the host timebase.
-Scott
--
To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
