WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

[Xen-devel] Re: [XenPPC] RFC: xencomm - linux side

On Fri, 2006-08-25 at 09:02 +0200, Tristan Gingold wrote:
> Le Jeudi 24 Août 2006 17:43, Hollis Blanchard a écrit :
> > On Thu, 2006-08-24 at 09:51 +0200, Tristan Gingold wrote:
> > > > My suggestion: have xencomm_create() test IS_KERNEL_ADDR() (in whatever
> > > > way is best for portability) and if it is, do the "inline" stuff. On
> > > > the free side, if the descriptor was inline, free can just return. That
> > > > would also make me happy because it removes the need to think about
> > > > whether callers can/should call "create_inline" or not; the code just
> > > > does the right thing.
> > >
> > > We definitly disagree here.  One whole point of xencomm_create_inline is
> > > it doesn't allocate memory and can't fail.  Because of that we don't need
> > > to worry about failure and freeing memory.  This makes the code a lot
> > > easier to write and to read.
> >
> > It would simplify the code even more to fold xencomm_create_inline()
> > into xencomm_create(), as I suggest above. That way, the developer never
> > needs to consider if the particular hypercall could ever be called
> > before the page allocator works. Proving that assumption for some
> > hypercall, and guaranteeing it will remain true in the future no matter
> > what Linux changes occur, is a lot more difficult than remembering to
> > call free() after create().
> Could you modify the ppc code, I will be happy to fetch directly the code for 
> this new idea.

I'm looking at this now, and I'm brought back to the fact that I don't
like the "inline" idea because practically speaking it requires that the
kernel stack is physically contiguous. That is true for Linux, but is
that really true for all OSs? Since we're defining a Xen interface, I
don't want to hardcode Linux assumptions.

Without that, an OS with a physically discontiguous stack would be
forced to do the equivalen of get_free_page() to do all communication
(including console output). Before the page allocator works that
wouldn't be possible, but I think we can assume a physically contiguous
stack early in the boot process before the page allocator works. So then
you're requiring a test:

hcall_console_write(char *str) {
        if (page_allocator_done()) {
                desc = (desc *)get_free_page();
                xencomm_map(desc, str);
                hcall(desc);
                free_page(desc);
        } else {
                desc = xencomm_create_inline(str);
                hcall(desc);
        }
}

That seems lame. The "mini" xencomm stuff always works.

Actually... I guess the "mini" stuff will always work, and any OS that
needs it can use it. The "inline" stuff is an optimization that Linux
can take advantage of.

Summary: I've changed my mind, and I only send this email to illustrate
my thought process. :)

-- 
Hollis Blanchard
IBM Linux Technology Center


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

<Prev in Thread] Current Thread [Next in Thread>
  • [Xen-devel] Re: [XenPPC] RFC: xencomm - linux side, Hollis Blanchard <=