Re: [Xen-devel] xen-4.3 port

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Tue, 2014-01-28 at 23:45 +0400, Igor Kozhukhov wrote:
> On Jan 28, 2014, at 11:34 PM, Konrad Rzeszutek Wilk wrote:
> 
> > On Tue, Jan 28, 2014 at 11:21:34PM +0400, Igor Kozhukhov wrote:
> >> Hello All,
> >> 
> >> i'm working on port xen-4.3 to DilOS (illumos based platform).
> >> 
> >> i have problems with PV guest load.
> >> dom0 started, i can see info by 'xl info'.
> >> 
> >> first: i see platform ID=38, but i couldn't found it in 
> >> xen/public/platform.h
> >> 
> >> Jan 28 01:16:44 myhost privcmd: == HYPERVISOR_platform_op 38
> >> Jan 28 01:16:44 myhost privcmd: unrecognized HYPERVISOR_platform_op 38
> >> 
> >> could you please let me know - what is it the 38 platform hypercall ?
> > 
> > tmem_op
> 
> tmem_op defined at xen/public/xen.h, but 38 ID not defined at 
> xen/public/platform.h

platform.h only declares one subset of hypercall, the XENPF interfaces.
tmem_op is not one of those interfaces. You want include/public/tmem.h

> > 
> >> 
> >> do i need implement it first ?
> > 
> > No. But you should have stub functions in your hypercall page to at least
> > return -ENOSYS for everything you don't implement.
> 
> based on current code i see:
> return -X_EINVAL;
> will it be correct to return it if ID not implemented ?

This appears to be an illlumos return code. It is of course up to the OS
to decide what to return from an unimplemented ioctls, but the
hypervisor itself will return -ENOSYS to an unimplemented hypercall.

> > How do you construct your hyperpage?
> >> 
> 
> example here : 
> https://github.com/illumos/illumos-gate/blob/master/usr/src/uts/i86xpv/io/privcmd_hcall.c
> 
> from line: 379

It seems like illumos has chosen to implement the privcmd hypercall
piecemeal on a hypercall-by-hypercall basis (in fact on a subop by subop
basis). This is up to you but you might find it easier to just do as
Linux does and mirror all hypercalls made via this path through to the
hypervisor.

One downside of your approach is that you end up hardcoding
non-stable-ABIs into your kernel -- e.g. XEN_SYSCTL and XEN_DOMCTL.
These are not considered stable across Xen releases which means that you
will need to update your kernel whenever you update Xen. If you just
mirror the hypercalls through without inspection then when upgrading Xen
you only need to update the Xen tools and the hypervisor but not the
kernel.

I suppose you could also take the middle ground and only pass through
the non-stable interfaces but continue to check the rest.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel