Xen devel - May 2006 - PATCH: fix transparent virtualization issue

Hi,

this patch fixes a few transparent virtualization (ie running xenolinux on 
bare platform) issues for xen/ia64.

Tristan.


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

On 17 May 2006, at 12:17, Tristan Gingold wrote:
> this patch fixes a few transparent virtualization (ie running 
> xenolinux on
> bare platform) issues for xen/ia64.
Why not call xen_init() in the two places you added NULL check for 
xen_start_info? Especially in netfront -- you already call xen_init() 
in blkfront, so it seems weird not to do so in netfront. I see no 
reason not to call it in swiotlb.c too.

xen_init() is a pretty bad name by the way, seeing as it''s called all 
over the place so it''s not really initialising xen state at every call 
site. Given that it is used in most places for the caller to determine 
if you are running on Xen or not, why not call it running_on_xen() and 
have the initialisation on the first call just be a hidden side effect?

  -- Keir


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

Le Jeudi 18 Mai 2006 00:35, Keir Fraser a écrit :
> On 17 May 2006, at 12:17, Tristan Gingold wrote:
> > this patch fixes a few transparent virtualization (ie running
> > xenolinux on
> > bare platform) issues for xen/ia64.
>
> Why not call xen_init() in the two places you added NULL check for
> xen_start_info? Especially in netfront -- you already call xen_init()
> in blkfront, so it seems weird not to do so in netfront. I see no
> reason not to call it in swiotlb.c too.
>
> xen_init() is a pretty bad name by the way, seeing as it''s called
all
> over the place so it''s not really initialising xen state at every
call
> site. Given that it is used in most places for the caller to determine
> if you are running on Xen or not, why not call it running_on_xen() and
> have the initialisation on the first call just be a hidden side effect?
Sure.

Tristan.

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

Le Jeudi 18 Mai 2006 00:35, Keir Fraser a écrit :
> On 17 May 2006, at 12:17, Tristan Gingold wrote:
> > this patch fixes a few transparent virtualization (ie running
> > xenolinux on
> > bare platform) issues for xen/ia64.
>
> Why not call xen_init() in the two places you added NULL check for
> xen_start_info? Especially in netfront -- you already call xen_init()
> in blkfront, so it seems weird not to do so in netfront. I see no
> reason not to call it in swiotlb.c too.
>
> xen_init() is a pretty bad name by the way, seeing as it''s called
all
> over the place so it''s not really initialising xen state at every
call
> site. Given that it is used in most places for the caller to determine
> if you are running on Xen or not, why not call it running_on_xen() and
> have the initialisation on the first call just be a hidden side effect?
Hi,

here are two patches for transparent virtualization.
xen-transvirt4.diffs replaces uses of xen_init() by running_on_xen on common 
and x86 code.

xen-transvirt3.diffs is for xen/ia64: it add a call to xen_init() very early.

I think this is cleaner than previous way.

Tristan.



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

On 18 May 2006, at 13:10, Tristan Gingold wrote:
> here are two patches for transparent virtualization.
> xen-transvirt4.diffs replaces uses of xen_init() by running_on_xen on 
> common
> and x86 code.
>
> xen-transvirt3.diffs is for xen/ia64: it add a call to xen_init() very 
> early.
>
> I think this is cleaner than previous way.
Please make running_on_xen a function rather than a variable. I see you 
end up turning it into a function for modules anyway, and I''d rather 
have a function wrapper around a variable than a variable wrapper 
around a function. :-) It''ll give us a bit more flexibility in future 
too.

  -- Keir


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

Le Jeudi 18 Mai 2006 14:32, Keir Fraser a écrit :
> On 18 May 2006, at 13:10, Tristan Gingold wrote:
> > here are two patches for transparent virtualization.
> > xen-transvirt4.diffs replaces uses of xen_init() by running_on_xen on
> > common
> > and x86 code.
> >
> > xen-transvirt3.diffs is for xen/ia64: it add a call to xen_init() very
> > early.
> >
> > I think this is cleaner than previous way.
>
> Please make running_on_xen a function rather than a variable. I see you
> end up turning it into a function for modules anyway, and I''d
rather
> have a function wrapper around a variable than a variable wrapper
> around a function. :-) It''ll give us a bit more flexibility in
future
> too.
Hi,

here is the updated patch.
The function is now: is_running_on_xen().

Tested on ia64 bare box and on xen/ia64.

Tristan.



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