Xen+coLinux

Xen+coLinux

[Digital Infra, Inc.]

Hello Xen team.

I think Xen and coLinux have similarity in its algorithm.
How about combining two technologies?
I mean, for example, making XEN.SYS - which makes WindowsXP/2K as Xen host.
(coLinux has LINUX.SYS, which makes Windows as coLinux host.)

With this, we can do cool stuff like this:
  you usually run your VM on Xenoserver. and doing daily jobs on it.
  but if you go to a province which has no network connection,
  you transfer your VM to your Windows note book.

The poing is, you can do it by "live migration".
you dont have to stop your VM.

 

          Best Regards,

                    Okajima, Jun.
                    President, Digital Infra, Inc. Tokyo, Japan.
                    http://www.digitalinfra.co.jp/
                    Member of coLinux Development Team.
                    http://www.colinux.org/



-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click

Re: Xen+coLinux

[Digital Infra, Inc.]

>
>The poing is, you can do it by "live migration".
>

poing -> point. sorry.


-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click

Re: Xen+coLinux

[Jacob Gorm Hansen]

On Fri, 2004-03-19 at 13:29, Digital Infra, Inc. wrote:
> 
> Hello Xen team.
> 
> I think Xen and coLinux have similarity in its algorithm.
> How about combining two technologies?
> I mean, for example, making XEN.SYS - which makes WindowsXP/2K as Xen host.
> (coLinux has LINUX.SYS, which makes Windows as coLinux host.)

> The poing is, you can do it by "live migration".
> you dont have to stop your VM.

I am currently working on live migration in Xen. I agree that getting
Xen to run within/alongside Windows would be extremely useful. Are you
involved with the coLinux project?

Jacob



-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click

Re: Xen+coLinux

[Digital Infra, Inc.]

Hello Hansen.

Please check this:

http://www.colinux.org/?section=devteam

               --- Okajima.

>> 
>> Hello Xen team.
>> 
>> I think Xen and coLinux have similarity in its algorithm.
>> How about combining two technologies?
>> I mean, for example, making XEN.SYS - which makes WindowsXP/2K as Xen host.
>> (coLinux has LINUX.SYS, which makes Windows as coLinux host.)
>
>> The poing is, you can do it by "live migration".
>> you dont have to stop your VM.
>
>I am currently working on live migration in Xen. I agree that getting
>Xen to run within/alongside Windows would be extremely useful. Are you
>involved with the coLinux project?
>
>Jacob
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by: IBM Linux Tutorials
>Free Linux tutorial presented by Daniel Robbins, President and CEO of
>GenToo technologies. Learn everything from fundamentals to system
>administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
>_______________________________________________
>Xen-devel mailing list
>Xen-devel@lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/xen-devel
>


-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click

Re: Xen+coLinux

[Dan Aloni]

On Fri, Mar 19, 2004 at 04:01:38PM +0100, Jacob Gorm Hansen wrote:
> On Fri, 2004-03-19 at 13:29, Digital Infra, Inc. wrote:
> > 
> > Hello Xen team.
> > 
> > I think Xen and coLinux have similarity in its algorithm.
> > How about combining two technologies?
> > I mean, for example, making XEN.SYS - which makes WindowsXP/2K as Xen host.
> > (coLinux has LINUX.SYS, which makes Windows as coLinux host.)
> 
> > The poing is, you can do it by "live migration".
> > you dont have to stop your VM.
> 
> I am currently working on live migration in Xen. I agree that getting
> Xen to run within/alongside Windows would be extremely useful. Are you
> involved with the coLinux project?

According to what I understand, a machine running Xen, runs using a  
Xen-patched Linux kernel, right? So, if the coLinux patch doesn't 
conflict much with the Xen patch, you'd be able to easily create a 
coXenoLinux that runs under Windows just like the regular coLinux 
does.

-- 
Dan Aloni
da-x@colinux.org


-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click

Re: Xen+coLinux

[Steven Hand]

>On Fri, Mar 19, 2004 at 04:01:38PM +0100, Jacob Gorm Hansen wrote:
>> On Fri, 2004-03-19 at 13:29, Digital Infra, Inc. wrote:
>> > 
>> > Hello Xen team.
>> > 
>> > I think Xen and coLinux have similarity in its algorithm.
>> > How about combining two technologies?
>> > I mean, for example, making XEN.SYS - which makes WindowsXP/2K as Xen host
.
>> > (coLinux has LINUX.SYS, which makes Windows as coLinux host.)
>> 
>> > The poing is, you can do it by "live migration".
>> > you dont have to stop your VM.
>> 
>> I am currently working on live migration in Xen. I agree that getting
>> Xen to run within/alongside Windows would be extremely useful. Are you
>> involved with the coLinux project?
>
>According to what I understand, a machine running Xen, runs using a  
>Xen-patched Linux kernel, right? So, if the coLinux patch doesn't 
>conflict much with the Xen patch, you'd be able to easily create a 
>coXenoLinux that runs under Windows just like the regular coLinux 
>does.

Not really; XenoLinux runs on top of Xen rather than on the bare metal; 
the changes made to linux are to replace some of the low-level parts 
which interact with the real machine (e.g. cli/sti, raw device access, 
raw cr3 and page table access) with code which interfaces with Xen. 

To get XenoLinux working in a manner similar to coLoinux, it would be
necessary to get Xen working alongside Windows. If this could be achieved, 
then 1 or more XenoLinux instances should be able to run on top of that. 
I've not looked at the coLinux work in detail, but doing "coXen" may well
be possible, although it'd need to be somewhat lobotimized I believe (e.g.
I'm guessing coLinux is uniprocessor). 

cheers, 

S.



-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click

Re: Xen+coLinux

[Jacob Gorm Hansen]

On Fri, 2004-04-09 at 21:10, Dan Aloni wrote:
> On Fri, Mar 19, 2004 at 04:01:38PM +0100, Jacob Gorm Hansen wrote:

> According to what I understand, a machine running Xen, runs using a  
> Xen-patched Linux kernel, right? So, if the coLinux patch doesn't 
> conflict much with the Xen patch, you'd be able to easily create a 
> coXenoLinux that runs under Windows just like the regular coLinux 
> does.

I think what you would do would be either a) revive the existing port of
XP to run within Xen, or b) port Xen to run as a driver in ring0 just as
coLinux does, and then run multiple XenoLinuxes on top of that. There is
probably not much point in running XenoLinux without Xen.

Jacob



-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click

Re: Xen+coLinux

[Digital Infra, Inc.]

Hello Aloni, Hansen.


I think coXenoLinux, which can run on both XEN and Windows, has its place.
if it comes, we can make "multi host distribution" which same distribution
can run on XEN and Windows and normal Linux. Good.
and this hack would be not so difficult. good. good.
but this way has one drawback -
it is difficult to do "live migration" between
XEN server and Windows , except you invent a very funny technic like
"suspend image converter" or such.

So, yes, basically Hansen's opinion is right.

our ULTIMATE goal (not milestones on the development)  should be 
adding these functionality to linux.sys/linux.ko. and making
XEN gesut OS ( e.g. XenoLinux) runnable on Windows.

   1. XEN API.
      I mean, linux.sys should accept both coLinux API and XEN API.
   2. ring 1.
      using ring 1 has a little performance penalty, but it offers
      resource isolation which coLinux lacks and is the biggest
      ( and probably only) fault of coLinux as its fundamental algorithm.
      of course, linux.sys can accepct coLinux API, if you love performace,
      you can run your VM on ring0. the problem of current coLinux
      implementation is, you have to choose only performance and never security.

and if these two functionality comes,
I think we can do "live migration" between
Windows PC and virtual server.

I believe that someday this new computing style is possible.

when we go out, we can migrate a VM from Windows desktop PC
to virtual server on the net. of course, you dont shut it down.
everything is done by "live". 
and we can use the VM from mobile phone with remote protocol like VNC.
and when you go back, you bring the VM back to your PC.

dont you think this is very good?

                 --- Okajima.



>On Fri, 2004-04-09 at 21:10, Dan Aloni wrote:
>> On Fri, Mar 19, 2004 at 04:01:38PM +0100, Jacob Gorm Hansen wrote:
>
>> According to what I understand, a machine running Xen, runs using a  
>> Xen-patched Linux kernel, right? So, if the coLinux patch doesn't 
>> conflict much with the Xen patch, you'd be able to easily create a 
>> coXenoLinux that runs under Windows just like the regular coLinux 
>> does.
>
>I think what you would do would be either a) revive the existing port of
>XP to run within Xen, or b) port Xen to run as a driver in ring0 just as
>coLinux does, and then run multiple XenoLinuxes on top of that. There is
>probably not much point in running XenoLinux without Xen.
>
>Jacob
>


-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click

Re: Xen+coLinux / terminology

[Digital Infra, Inc.]

Hello Aloni.

I felt that probably there is misunderstanding
about terminology of Xen.

Okay, lets start a private lesson from a bad student.

  Xen        --- Host OS. Modified version of Linux.
  Xeno*      --- Prefix for Guest OS.
  XenoLinux  --- Linux Guest.
  XenoXP     --- Windows XP Guest. We can not touch it due to NDA.
  XenoBSD    --- Planned BSD Guest name which the Xen team suggested
                 in a their paper.
  NetBSD/Xen --- Actual NetBSD Guest. Why it is not XenoNetBSD?
  XenoServer --- A server which runs Xen.
                 I dont understand why this is not XenServer.
                 probably, most people call it so.

These are right? Professor.
And Aloni, you did understand these definition?


BTW, we have to fix the definition about coLinux term.

what coLinux means? patched vmlinux? or the whole system? or linux.sys?
if it is a whole system, what we call it when coBSD comes?
   "coBSD is one of the guest OS of coLinux total virtualizing system..."
ummm... a bit funny.

            --- Okajima.




-------------------------------------------------------
This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek
For a limited time only, get FREE Ground shipping on all orders of $35
or more. Hurry up and shop folks, this offer expires April 30th!
http://www.thinkgeek.com/freeshipping/?cpg=12297

Re: Xen+coLinux / terminology

[Brian Wolfe]

I have added these to the xen WIki at
http://xen.terrabox.com/index.php/Xen%20Terminology

Could a Xen developer please confirm these definitions for me? If they are
incorrect, please feel free to either email the correct definitions, or
update the wiki. :)

Thanks!
-- 
Brian Wolfe           | Phone 1-(214)-764-1204
President,            | Email  brianw@terrabox.com
TerraBox.com Inc.     |


pub  1024D/73C5A2DF 2003-03-18 Brian Wolfe <brianw@terrabox.com>
     Key fingerprint = 050E 5E3C CF65 4C1E A183  F48F E3E3 5B22 73C5 A2DF
sub  1024g/BB87A3DD 2003-03-18


Digital Infra, Inc. said:
>
> Hello Aloni.
>
> I felt that probably there is misunderstanding
> about terminology of Xen.
>
> Okay, lets start a private lesson from a bad student.
>
>   Xen        --- Host OS. Modified version of Linux.
>   Xeno*      --- Prefix for Guest OS.
>   XenoLinux  --- Linux Guest.
>   XenoXP     --- Windows XP Guest. We can not touch it due to NDA.
>   XenoBSD    --- Planned BSD Guest name which the Xen team suggested
>                  in a their paper.
>   NetBSD/Xen --- Actual NetBSD Guest. Why it is not XenoNetBSD?
>   XenoServer --- A server which runs Xen.
>                  I dont understand why this is not XenServer.
>                  probably, most people call it so.
>
> These are right? Professor.
> And Aloni, you did understand these definition?
>
>
> BTW, we have to fix the definition about coLinux term.
>
> what coLinux means? patched vmlinux? or the whole system? or linux.sys?
> if it is a whole system, what we call it when coBSD comes?
>    "coBSD is one of the guest OS of coLinux total virtualizing system..."
> ummm... a bit funny.
>
>             --- Okajima.
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek
> For a limited time only, get FREE Ground shipping on all orders of $35
> or more. Hurry up and shop folks, this offer expires April 30th!
> http://www.thinkgeek.com/freeshipping/?cpg=12297
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/xen-devel
>



-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. 
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click

Re: Xen+coLinux / terminology

[Ian Pratt]

> > I felt that probably there is misunderstanding
> > about terminology of Xen.

> >   Xen        --- Host OS. Modified version of Linux.

It's incorrect to think of Xen as a modified version of Linux. It
may share some start of day initialisation code with Linux, and
even some device drivers, but the core is very different, and
much, much smaller -- it's a Virtual Machine Monitor, not a
full-blown OS.


>   Xeno*      --- Prefix for Guest OS.
>   XenoLinux  --- Linux Guest.
>   XenoXP     --- Windows XP Guest. We can not touch it due to NDA.
>   XenoBSD    --- Planned BSD Guest name which the Xen team suggested
>                  in a their paper.
>   NetBSD/Xen --- Actual NetBSD Guest. Why it is not XenoNetBSD?

The Xeno prefixes come from Xen's heritage in the XenoServer
project. "XenLinux" would be a better name were we to pick it
today, but I can't muster enthusiasm to change it.

>   XenoServer --- A server which runs Xen.
>                  I dont understand why this is not XenServer.
>                  probably, most people call it so.

The XenoServer project is just one of many different uses of
Xen. It's developing a whole load of extra control-plane software
that runs on top of Xen, with the aim of building an open
infrastructure for global distributed computing. The goal is to
enable any suitably authenticated member of the public or other
entity to be able to reserve and *purchase* resources on a
network of XenoServer execution platforms distributed across the
globe.  Thus, users (or agents acting on their behalf) will be
able to arrange for computation to take place at the most
advantageous place in the Internet, avoiding long round trip
latencies or bandwidth bottlenecks.

You can call a machine that runs Xen anything you like ;-)

Cheers,
Ian



-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. 
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click

Re: Xen+coLinux / coXen

[Digital Infra, Inc.]

Hello Aloni, Hansen.

a lecture of terminology ended.
so far is Okay?
and we can go to actual discussion.

I had been browsing the Xen code and I found that it is not so difficult
to combine Xen( not Xeno) and coLinux. I call it coXen as a working title.
In other words, Xen can run on Windows and unmodified Linux with a little
hack. this means you have four layers.

coXen architecture overview:
-----------------------------------------------------------------------
 Apps | guest (Xeno) | hacked Xen (coXen) | linux.sys/ko | real host
-----------------------------------------------------------------------

this architecture increase an overhead comparing from normal Xen, but I
estimate that it is not serious. because most overhead of coLinux comes
from virtual I/O, but Xen already suffers from it.

and the biggest point is, I think this can make very same suspending image
as normal Xen.

and this hack adds isolation. it can solve only fundamental problem of
coLinux -- it lacks isolation between VMs.

is this really possible?, everyone.
I hope your opinion.

            --- Okajima.




-------------------------------------------------------
This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek
For a limited time only, get FREE Ground shipping on all orders of $35
or more. Hurry up and shop folks, this offer expires April 30th!
http://www.thinkgeek.com/freeshipping/?cpg=12297

Re: Xen+coLinux / coXen

[Jacob Gorm Hansen]

On Tue, 2004-04-27 at 19:08, Digital Infra, Inc. wrote:
> Hello Aloni, Hansen.

Okajima-san,

> coXen architecture overview:
> -----------------------------------------------------------------------
>  Apps | guest (Xeno) | hacked Xen (coXen) | linux.sys/ko | real host
> -----------------------------------------------------------------------

Does linux.sys contain a full vmlinux? In that case, why not just:

coXen architecture overview:
> ---------------------------------------------------------------
>  Apps | guest (Xeno) | hacked Xen (coXen) + (winnt) | real host
> ---------------------------------------------------------------

Best regards,
Jacob



-------------------------------------------------------
This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek
For a limited time only, get FREE Ground shipping on all orders of $35
or more. Hurry up and shop folks, this offer expires April 30th!
http://www.thinkgeek.com/freeshipping/?cpg=12297

Re: Xen+coLinux / coXen

[Digital Infra, Inc.]

Hello Hansen.


if you want to know right details, my answer is "go Canada and attend OLS".
Aloni will hold a lecture of coLinux there.
but quick answer is below.

first, I give you a quick overview of coLinux architecture.

 - vmlinux of coLinux is modified version of Linux.
   very interesting point is, you can same binary image for both
   linux.sys and linux.ko.
   this means, you can "live migrate" between Windows and Linux.
 - linux.sys is virtualizing driver for Windows XP/2k/4.0
   and probably not only 4.0, but also 3.1 and 3.5 and 3.51.
   someone prove it!.
 - linux.ko is for linux host.
   this is kernel module, so you dont have to modify your kernel.
   basically, what you have to do is, just "# insmod linux.ko".

then, the answer for you is, "no, linux.sys does not contain any of linux kernel."


          --- Okajima.




>On Tue, 2004-04-27 at 19:08, Digital Infra, Inc. wrote:
>> Hello Aloni, Hansen.
>
>Okajima-san,
>
>> coXen architecture overview:
>> -----------------------------------------------------------------------
>>  Apps | guest (Xeno) | hacked Xen (coXen) | linux.sys/ko | real host
>> -----------------------------------------------------------------------
>
>Does linux.sys contain a full vmlinux? In that case, why not just:
>
>coXen architecture overview:
>> ---------------------------------------------------------------
>>  Apps | guest (Xeno) | hacked Xen (coXen) + (winnt) | real host
>> ---------------------------------------------------------------
>
>Best regards,
>Jacob
>


-------------------------------------------------------
This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek
For a limited time only, get FREE Ground shipping on all orders of $35
or more. Hurry up and shop folks, this offer expires April 30th!
http://www.thinkgeek.com/freeshipping/?cpg=12297

Re: Xen+coLinux / coXen

[Digital Infra, Inc.]

sorry, wrong english.

you can same -> you can use same.

-----
Hello Hansen.


if you want to know right details, my answer is "go Canada and attend OLS".
Aloni will hold a lecture of coLinux there.
but quick answer is below.

first, I give you a quick overview of coLinux architecture.

 - vmlinux of coLinux is modified version of Linux.
   very interesting point is, you can same binary image for both
   linux.sys and linux.ko.
   this means, you can "live migrate" between Windows and Linux.
 - linux.sys is virtualizing driver for Windows XP/2k/4.0
   and probably not only 4.0, but also 3.1 and 3.5 and 3.51.
   someone prove it!.
 - linux.ko is for linux host.
   this is kernel module, so you dont have to modify your kernel.
   basically, what you have to do is, just "# insmod linux.ko".

then, the answer for you is, "no, linux.sys does not contain any of linux kernel."


          --- Okajima.




>On Tue, 2004-04-27 at 19:08, Digital Infra, Inc. wrote:
>> Hello Aloni, Hansen.
>
>Okajima-san,
>
>> coXen architecture overview:
>> -----------------------------------------------------------------------
>>  Apps | guest (Xeno) | hacked Xen (coXen) | linux.sys/ko | real host
>> -----------------------------------------------------------------------
>
>Does linux.sys contain a full vmlinux? In that case, why not just:
>
>coXen architecture overview:
>> ---------------------------------------------------------------
>>  Apps | guest (Xeno) | hacked Xen (coXen) + (winnt) | real host
>> ---------------------------------------------------------------
>
>Best regards,
>Jacob
>


-------------------------------------------------------
This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek
For a limited time only, get FREE Ground shipping on all orders of $35
or more. Hurry up and shop folks, this offer expires April 30th!
http://www.thinkgeek.com/freeshipping/?cpg=12297

pdb entered even when set to none

[Kip Macy]

In traps.c pdb_handle_exception is called on an int3:

asmlinkage void do_int3(struct pt_regs *regs, long error_code)
{
    struct task_struct *p = current;
    struct guest_trap_bounce *gtb =
guest_trap_bounce+smp_processor_id();
    trap_info_t *ti;

    if ( pdb_handle_exception(3, regs) == 0 )
        return;
<...>

It in turn goes through some elaborate checks that don't evaluate to
true when FreeBSD panics:

<...>
    if ( exceptionVector == 3 &&
	 (xen_regs->xcs & 3) == 3 &&
	 xen_regs->eip != pdb_system_call_next_addr + 1)
    {
        TRC(printf("pdb: user bkpt (0x%x) at 0x%x:0x%lx:0x%lx\n",
		   exceptionVector, xen_regs->xcs & 3, cr3,
xen_regs->eip));
	return 1;
    }

    /*
     * If PDB didn't set the breakpoint, is not single stepping,
     * is not entering a system call in a domain,
     * the user didn't press the magic debug key,
     * then we don't handle the exception.
     */
    bkpt = pdb_bkpt_search(cr3, xen_regs->eip - 1);
    if ( (bkpt == NULL) &&
         !pdb_stepping &&
	 !pdb_system_call &&
	 xen_regs->eip != pdb_system_call_next_addr + 1 &&
	 (exceptionVector != KEYPRESS_EXCEPTION) &&
	 xen_regs->eip < 0xc0000000)                   /* xenolinux for
now! */
    {
        TRC(printf("pdb: user bkpt (0x%x) at 0x%lx:0x%lx\n",
		   exceptionVector, cr3, xen_regs->eip));
	return 1;
    }
<...>

As far as I can tell, what you should be doing is returning 1
immediately if pdb_initialized is equal to zero.

Thanks.


				-Kip





-------------------------------------------------------
This SF.Net email is sponsored by: GNOME Foundation
Hackers Unite!  GUADEC: The world's #1 Open Source Desktop Event.
GNOME Users and Developers European Conference, 28-30th June in Norway
http://2004/guadec.org

Re: pdb entered even when set to none

[Alex Ho]

oops.  good point.  the alternative is to always run with
pdb initialized :)

i'll check in a fix later this morning.

.a


-- begin message
 
 In traps.c pdb_handle_exception is called on an int3:
 
 asmlinkage void do_int3(struct pt_regs *regs, long error_code)
 {
     struct task_struct *p = current;
     struct guest_trap_bounce *gtb =
 guest_trap_bounce+smp_processor_id();
     trap_info_t *ti;
 
     if ( pdb_handle_exception(3, regs) == 0 )
         return;
 <...>
 
 It in turn goes through some elaborate checks that don't evaluate to
 true when FreeBSD panics:
 
 <...>
     if ( exceptionVector == 3 &&
 	 (xen_regs->xcs & 3) == 3 &&
 	 xen_regs->eip != pdb_system_call_next_addr + 1)
     {
         TRC(printf("pdb: user bkpt (0x%x) at 0x%x:0x%lx:0x%lx\n",
 		   exceptionVector, xen_regs->xcs & 3, cr3,
 xen_regs->eip));
 	return 1;
     }
 
     /*
      * If PDB didn't set the breakpoint, is not single stepping,
      * is not entering a system call in a domain,
      * the user didn't press the magic debug key,
      * then we don't handle the exception.
      */
     bkpt = pdb_bkpt_search(cr3, xen_regs->eip - 1);
     if ( (bkpt == NULL) &&
          !pdb_stepping &&
 	 !pdb_system_call &&
 	 xen_regs->eip != pdb_system_call_next_addr + 1 &&
 	 (exceptionVector != KEYPRESS_EXCEPTION) &&
 	 xen_regs->eip < 0xc0000000)                   /* xenolinux for
 now! */
     {
         TRC(printf("pdb: user bkpt (0x%x) at 0x%lx:0x%lx\n",
 		   exceptionVector, cr3, xen_regs->eip));
 	return 1;
     }
 <...>
 
 As far as I can tell, what you should be doing is returning 1
 immediately if pdb_initialized is equal to zero.
 
 Thanks.
 
 
 				-Kip
 
 
 
-- end message


-------------------------------------------------------
This SF.Net email is sponsored by: GNOME Foundation
Hackers Unite!  GUADEC: The world's #1 Open Source Desktop Event.
GNOME Users and Developers European Conference, 28-30th June in Norway
http://2004/guadec.org