Re: [PATCH 3/5] booke: define reset and shutdown hcalls

[Scott Wood <scottwood@freescale.com>]

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