Re: [Xen-devel] xen-4.3 port

[Igor Kozhukhov <ikozhukhov@xxxxxxxxx>]

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

>>> 
>>>> 
>>>> 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 ?

> 
>>> 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.

> I suppose you could also take the middle ground and only pass through
> the non-stable interfaces but continue to check the rest.
thanks - i'll take a look.

> Ian.
> 


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