Xen devel - Apr 2009 - [RfC / Patch] xenner: event channel implementation.

Hi,

Merging the xen bits seems to be on a good way.  Time to look at 
un-bitrotting the xenner bits ...

Here is a first patch for comments.  Not useful on its own.  Right now 
I''m looking more for comments on the way the integration is done.

Event channels on Xen are managed by calling the xc_evtchn_* functions 
provided by libxenctrl.  The library in turn does does hypercalls into 
the xen kernel.  xenner obviously has to provide an alternative 
implementation for these functions.  Also for others.  This patch starts 
with just the event channels though.

It works this way:  There is a struct with function pointers to the 
event channel functions.  The struct can be switched at runtime to the 
xen or xenner version of the functions depending on the qemu operation mode.

The struct is named "xc_evtchn", the function pointer are named like
the
xc_evtchn_* functions, but without the xc_evtchn_ prefix, i.e. 
"xc_evtchn_open(...)" becomes xc_evtchn.open(...).

The function calls in the source code (xen backend drivers) are not 
changed directly, but using a include file with a bunch of #defines. 
That way I don''t have to change s/xc_evtchn_/xc_evtchn./ all over the 
place.  Also xenner can easily be disabled at compile time and the 
indirect function pointer calls simply go away then.

Comments?

cheers,
   Gerd


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Gerd Hoffmann wrote:
>   Hi,
>
> Merging the xen bits seems to be on a good way.  Time to look at 
> un-bitrotting the xenner bits ...
>
> Here is a first patch for comments.  Not useful on its own.  Right now 
> I''m looking more for comments on the way the integration is done.
>
> Event channels on Xen are managed by calling the xc_evtchn_* functions 
> provided by libxenctrl.  The library in turn does does hypercalls into 
> the xen kernel.  xenner obviously has to provide an alternative 
> implementation for these functions.  Also for others.  This patch 
> starts with just the event channels though.
>
> It works this way:  There is a struct with function pointers to the 
> event channel functions.  The struct can be switched at runtime to the 
> xen or xenner version of the functions depending on the qemu operation 
> mode.
>
> The struct is named "xc_evtchn", the function pointer are named
like
> the xc_evtchn_* functions, but without the xc_evtchn_ prefix, i.e. 
> "xc_evtchn_open(...)" becomes xc_evtchn.open(...).
>
> The function calls in the source code (xen backend drivers) are not 
> changed directly, but using a include file with a bunch of #defines. 
> That way I don''t have to change s/xc_evtchn_/xc_evtchn./ all over
the
> place.  Also xenner can easily be disabled at compile time and the 
> indirect function pointer calls simply go away then.
>
I don''t think the last bit is worthwhile.  Function pointers these days
are pretty fast, their cost will be dwarfed by the syscall and hypercall 
overhead.
> pecific
> @@ -422,7 +423,9 @@ for opt do
>    ;;
>    --disable-kqemu) kqemu="no"
>    ;;
> -  --disable-xen) xen="no"
> +  --disable-xen) xen="no"; xenner="no"
> +  ;;
> +  --disable-xenner) xenner="no"
It would be nice to be able to build without the original Xen libraries.
>
> +
> +static struct domain *get_domain(int domid)
> +{
> +    struct domain *domain;
> +
> +    TAILQ_FOREACH(domain, &domains, list) {
> +    if (domain->domid == domid)
> +        goto done;
> +    }
> +
> +    domain = qemu_mallocz(sizeof(*domain));
> +    if (domid)
> +    domain->domid = domid;
> +    TAILQ_INSERT_TAIL(&domains, domain, list);
> +    if (debug)
> +    qemu_log("xen ev:  ?: new domain id %d\n",
domain->domid);
> +
> +done:
> +    domain->refcount++;
> +    return domain;
> +}
Curious, can there be any domain other than the guest and the fake dom0 
you''re emulating?



-- 
error compiling committee.c: too many arguments to function


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Gerd Hoffmann wrote:
>   Hi,
>
> Merging the xen bits seems to be on a good way.  Time to look at 
> un-bitrotting the xenner bits ...
>
> Here is a first patch for comments.  Not useful on its own.  Right now 
> I''m looking more for comments on the way the integration is done.
>
> Event channels on Xen are managed by calling the xc_evtchn_* functions 
> provided by libxenctrl.  The library in turn does does hypercalls into 
> the xen kernel.  xenner obviously has to provide an alternative 
> implementation for these functions.  Also for others.  This patch 
> starts with just the event channels though.
With xenner, do you still use xenstore/xenconsoled?  If so, don''t you 
need some LD_PRELOAD magic to make that work?

Regards,

Anthony Liguori
> It works this way:  There is a struct with function pointers to the 
> event channel functions.  The struct can be switched at runtime to the 
> xen or xenner version of the functions depending on the qemu operation 
> mode.
>
> The struct is named "xc_evtchn", the function pointer are named
like
> the xc_evtchn_* functions, but without the xc_evtchn_ prefix, i.e. 
> "xc_evtchn_open(...)" becomes xc_evtchn.open(...).
>
> The function calls in the source code (xen backend drivers) are not 
> changed directly, but using a include file with a bunch of #defines. 
> That way I don''t have to change s/xc_evtchn_/xc_evtchn./ all over
the
> place.  Also xenner can easily be disabled at compile time and the 
> indirect function pointer calls simply go away then.
>
> Comments?
>
> cheers,
>   Gerd

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 04/22/09 18:23, Avi Kivity wrote:
> Gerd Hoffmann wrote:
>> The function calls in the source code (xen backend drivers) are not
>> changed directly, but using a include file with a bunch of #defines.
>> That way I don''t have to change s/xc_evtchn_/xc_evtchn./ all
over the
>> place. Also xenner can easily be disabled at compile time and the
>> indirect function pointer calls simply go away then.
>
> I don''t think the last bit is worthwhile. Function pointers these
days
> are pretty fast, their cost will be dwarfed by the syscall and hypercall
> overhead.
>
>> - --disable-xen) xen="no"
>> + --disable-xen) xen="no"; xenner="no"
>
> It would be nice to be able to build without the original Xen libraries.
Hmm.  I''ll at least need the xen header files (at build time) anyway. 
Making xen and xenner independent config options and don''t link the xen
libraries for the !xen case should work without too much hassle (have to 
make the function pointers mandatory then though).
>> +
>> +static struct domain *get_domain(int domid)
>> +{
>> + struct domain *domain;
>
> Curious, can there be any domain other than the guest and the fake dom0
> you''re emulating?
No.  It is the case for the current xenner implementation.  The event 
channels are handled by a daemon then and the guests can talk to each 
other.  This code is derived from the daemon.  When moving xenner into 
qemu the event channels allow only host <=> guest communication, so that 
can probably simplified a bit.  Not sure that would save that much code 
though.  I''ll have a look.

cheers,
   Gerd

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 04/22/09 18:45, Anthony Liguori wrote:
> Gerd Hoffmann wrote:
>> Event channels on Xen are managed by calling the xc_evtchn_* functions
>> provided by libxenctrl. The library in turn does does hypercalls into
>> the xen kernel. xenner obviously has to provide an alternative
>> implementation for these functions. Also for others. This patch starts
>> with just the event channels though.
>
> With xenner, do you still use xenstore/xenconsoled?
The current standalone version does.  The qemu-merged version will not.

cheers,
   Gerd


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 04/22/09 18:23, Avi Kivity wrote:
> Gerd Hoffmann wrote:
>> The function calls in the source code (xen backend drivers) are not
>> changed directly, but using a include file with a bunch of #defines.
>> That way I don''t have to change s/xc_evtchn_/xc_evtchn./ all
over the
>> place. Also xenner can easily be disabled at compile time and the
>> indirect function pointer calls simply go away then.
>
> I don''t think the last bit is worthwhile. Function pointers these
days
> are pretty fast, their cost will be dwarfed by the syscall and hypercall
> overhead.
New revision of the patch.
>> - --disable-xen) xen="no"
>> + --disable-xen) xen="no"; xenner="no"
>
> It would be nice to be able to build without the original Xen libraries.
Planned for.  Will not work (yet) though as I''ll have to emulate all
xen
bits, and the event channels are only a part of the whole story.
> Curious, can there be any domain other than the guest and the fake dom0
> you''re emulating?
Simplified that.

cheers,
   Gerd


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel