Re: [Xen-devel] xen-4.3 port

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Wed, 2014-01-29 at 18:35 +0400, Igor Kozhukhov wrote:
> On Jan 29, 2014, at 1:46 PM, Ian Campbell wrote:
> 
> > 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
> Am i right here - i have to add to platform.h:
> #define XENPF_tmem_op 38
> ?
> i have no found ID 38 at xen-instable at xen/include/public/platform.h

No. tmem is not a platform op suboperation, it is a top level hypercall
in its own right.

I think Konrad & I may have misunderstood what you are seeing though: If
you are seeing hypercall 7 (== __HYPERVISOR_platform_op) with subop 38
then I'm afraid I don't know where this has come from. I can see no
reference to it in the Xen history.

I think I would be inclined as a debugging aid to inject an error (e.g a
SIGSEGV) into the calling process at this point so that it can be
trapped at the place making the call.

> 
> >>> 
> >>>> 
> >>>> 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 hyper call.
> you mean - hypervisor = dom0 ?
> or hypervisor = xen.gz + xen-syms ?

hypervisor == xen.

> >>> 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.
> if it is possible - could you please point me take a look some files with 
> realization on Linux ?
> where it located ?
> thanks for this info.

drivers/xen/privcmd.c in the upstream Linux source.

Ian.


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