Problems with latest unstable 1.3

Problems with latest unstable 1.3

[Barry Silverman]

I have been trying out the latest unstable with the new i/o and have found
the following issue. I created a xen.gz with nodev=y set, and tried it out
with all my devices in xenolinux.

The "machine" I am running on is "qemu", and it doesn't have emulation for
PCI. Therefore xenolinux is doing its ideprobes independent of the pci ide
code.
It is calling the routine "probe_irq_on" in irq.c, and it is failing with
the following messages:

ide: Assuming 50MHz system bus speed for PIO modes; override with idebus=xx
Kernel panic: Failed to obtain physical IRQ 127

"Probe_irq_on" is used to enable ALL unallocated irqs, the caller code will
then twig the device you are probing (in my case it is the ide drives for
ide0 disk, and ide0 cdrom) - and then will record the irq that actually got
the interrupt thus figuring out which irq belongs to which device.

The reasons it is failing seem to be the following:
1) The probe enables 127 physical IRQs (NR_PIRQS), but xen fails to bind any
pirq > 63. This is because sched.h only defines pirq_to_evtchn with a size
of 64
2) When I tried making that constant from 64->128, it still failed on IRQ 12
(which I think was already allocated to another device).

I was able to get much much further by setting "ide0=0x1f0,0x3f6,14
ide1=noprobe ide2=noprobe ide3=noprobe" on the command line. It still failed
much later on with an MMU update failure. I am currently tracking that one
down further before reporting it.


Barry Silverman



-------------------------------------------------------
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: Problems with latest unstable 1.3

[Keir Fraser]

The PCI- and IRQ-virtualisation is not quite there yet -- but hopefully
it will be in a couple of days.

Issues at the moment are:
 - probing and routing of device interrupt pins -> IRQs is broken.
 - passing of physical interrupts to guest OSes is untested and thus
   probably broken in some way or another.

I'm currently addressing all these problems.

 -- Keir

> I have been trying out the latest unstable with the new i/o and have found
> the following issue. I created a xen.gz with nodev=y set, and tried it out
> with all my devices in xenolinux.
> 
> The "machine" I am running on is "qemu", and it doesn't have emulation for
> PCI. Therefore xenolinux is doing its ideprobes independent of the pci ide
> code.
> It is calling the routine "probe_irq_on" in irq.c, and it is failing with
> the following messages:
> 
> ide: Assuming 50MHz system bus speed for PIO modes; override with idebus=xx
> Kernel panic: Failed to obtain physical IRQ 127
> 
> "Probe_irq_on" is used to enable ALL unallocated irqs, the caller code will
> then twig the device you are probing (in my case it is the ide drives for
> ide0 disk, and ide0 cdrom) - and then will record the irq that actually got
> the interrupt thus figuring out which irq belongs to which device.
> 
> The reasons it is failing seem to be the following:
> 1) The probe enables 127 physical IRQs (NR_PIRQS), but xen fails to bind any
> pirq > 63. This is because sched.h only defines pirq_to_evtchn with a size
> of 64
> 2) When I tried making that constant from 64->128, it still failed on IRQ 12
> (which I think was already allocated to another device).
> 
> I was able to get much much further by setting "ide0=0x1f0,0x3f6,14
> ide1=noprobe ide2=noprobe ide3=noprobe" on the command line. It still failed
> much later on with an MMU update failure. I am currently tracking that one
> down further before reporting it.
> 
> 
> Barry Silverman
> 
> 
> 
> -------------------------------------------------------
> 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: Problems with latest unstable 1.3

[Keir Fraser]

Okay, I checked in a patch to sort out all these problems. Please try
it out on QEMU again and let me know if probing fails.

Note that only DOM0 will be useful in such a setup right now --- there
is no way for other domains to access devices that are controlled by
DOM0. New inter-domain virtual device drivers to cope with this are in
the pipeline...

 -- Keir

> 
> The PCI- and IRQ-virtualisation is not quite there yet -- but hopefully
> it will be in a couple of days.
> 
> Issues at the moment are:
>  - probing and routing of device interrupt pins -> IRQs is broken.
>  - passing of physical interrupts to guest OSes is untested and thus
>    probably broken in some way or another.
> 
> I'm currently addressing all these problems.
> 
>  -- Keir
> 
> > I have been trying out the latest unstable with the new i/o and have found
> > the following issue. I created a xen.gz with nodev=y set, and tried it out
> > with all my devices in xenolinux.
> > 
> > The "machine" I am running on is "qemu", and it doesn't have emulation for
> > PCI. Therefore xenolinux is doing its ideprobes independent of the pci ide
> > code.
> > It is calling the routine "probe_irq_on" in irq.c, and it is failing with
> > the following messages:
> > 
> > ide: Assuming 50MHz system bus speed for PIO modes; override with idebus=xx
> > Kernel panic: Failed to obtain physical IRQ 127
> > 
> > "Probe_irq_on" is used to enable ALL unallocated irqs, the caller code will
> > then twig the device you are probing (in my case it is the ide drives for
> > ide0 disk, and ide0 cdrom) - and then will record the irq that actually got
> > the interrupt thus figuring out which irq belongs to which device.
> > 
> > The reasons it is failing seem to be the following:
> > 1) The probe enables 127 physical IRQs (NR_PIRQS), but xen fails to bind any
> > pirq > 63. This is because sched.h only defines pirq_to_evtchn with a size
> > of 64
> > 2) When I tried making that constant from 64->128, it still failed on IRQ 12
> > (which I think was already allocated to another device).
> > 
> > I was able to get much much further by setting "ide0=0x1f0,0x3f6,14
> > ide1=noprobe ide2=noprobe ide3=noprobe" on the command line. It still failed
> > much later on with an MMU update failure. I am currently tracking that one
> > down further before reporting it.
> > 
> > 
> > Barry Silverman
> > 
> > 
> > 
> > -------------------------------------------------------
> > 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
> _______________________________________________
> 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: Problems with latest unstable 1.3

[Rolf Neugebauer]

On Tue, 2004-03-30 at 16:46, Barry Silverman wrote:
> In the new I/O world if xen owns the network interface, what does xenolinux
> have to use as eth0?

the aim is that xen won't own any devices. for transition and boot
strapping purposes we may initially still have some devices owned by Xen
and some being assigned to some other VMs.

What a domain then sees as eth0 depends on how it will be configured and
in which order it probes for devices (virtual devices before physical or
vice versa).

> Are there any devices (such as virtual disks) that I can use with the code
> as is on a non-0 guest?

at the moment the physical devices used by a VM (dom0 only at the
moment) are not exported to other VMs, so you can not use them for now.
However, as Keir pointed out the exporting of physical devices as
virtual devices to other domains is in the pipeline.

HTH

rolf


> Barry Silverman
> 
> -----Original Message-----
> From: xen-devel-admin@lists.sourceforge.net
> [mailto:xen-devel-admin@lists.sourceforge.net]On Behalf Of Keir Fraser
> Sent: Monday, March 29, 2004 9:49 AM
> To: Keir Fraser
> Cc: Barry Silverman; xen-devel@lists.sourceforge.net
> Subject: Re: [Xen-devel] Problems with latest unstable 1.3
> 
> 
> 
> Okay, I checked in a patch to sort out all these problems. Please try
> it out on QEMU again and let me know if probing fails.
> 
> Note that only DOM0 will be useful in such a setup right now --- there
> is no way for other domains to access devices that are controlled by
> DOM0. New inter-domain virtual device drivers to cope with this are in
> the pipeline...
> 
>  -- Keir
> 
> >
> > The PCI- and IRQ-virtualisation is not quite there yet -- but hopefully
> > it will be in a couple of days.
> >
> > Issues at the moment are:
> >  - probing and routing of device interrupt pins -> IRQs is broken.
> >  - passing of physical interrupts to guest OSes is untested and thus
> >    probably broken in some way or another.
> >
> > I'm currently addressing all these problems.
> >
> >  -- Keir
> >
> > > I have been trying out the latest unstable with the new i/o and have
> found
> > > the following issue. I created a xen.gz with nodev=y set, and tried it
> out
> > > with all my devices in xenolinux.
> > >
> > > The "machine" I am running on is "qemu", and it doesn't have emulation
> for
> > > PCI. Therefore xenolinux is doing its ideprobes independent of the pci
> ide
> > > code.
> > > It is calling the routine "probe_irq_on" in irq.c, and it is failing
> with
> > > the following messages:
> > >
> > > ide: Assuming 50MHz system bus speed for PIO modes; override with
> idebus=xx
> > > Kernel panic: Failed to obtain physical IRQ 127
> > >
> > > "Probe_irq_on" is used to enable ALL unallocated irqs, the caller code
> will
> > > then twig the device you are probing (in my case it is the ide drives
> for
> > > ide0 disk, and ide0 cdrom) - and then will record the irq that actually
> got
> > > the interrupt thus figuring out which irq belongs to which device.
> > >
> > > The reasons it is failing seem to be the following:
> > > 1) The probe enables 127 physical IRQs (NR_PIRQS), but xen fails to bind
> any
> > > pirq > 63. This is because sched.h only defines pirq_to_evtchn with a
> size
> > > of 64
> > > 2) When I tried making that constant from 64->128, it still failed on
> IRQ 12
> > > (which I think was already allocated to another device).
> > >
> > > I was able to get much much further by setting "ide0=0x1f0,0x3f6,14
> > > ide1=noprobe ide2=noprobe ide3=noprobe" on the command line. It still
> failed
> > > much later on with an MMU update failure. I am currently tracking that
> one
> > > down further before reporting it.
> > >
> > >
> > > Barry Silverman
> > >
> > >
> > >
> > > -------------------------------------------------------
> > > 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
> > _______________________________________________
> > 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
> _______________________________________________
> 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
> _______________________________________________
> 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: Problems with latest unstable 1.3

[Barry Silverman]

In the new I/O world if xen owns the network interface, what does xenolinux
have to use as eth0?

Are there any devices (such as virtual disks) that I can use with the code
as is on a non-0 guest?

Barry Silverman

-----Original Message-----
From: xen-devel-admin@lists.sourceforge.net
[mailto:xen-devel-admin@lists.sourceforge.net]On Behalf Of Keir Fraser
Sent: Monday, March 29, 2004 9:49 AM
To: Keir Fraser
Cc: Barry Silverman; xen-devel@lists.sourceforge.net
Subject: Re: [Xen-devel] Problems with latest unstable 1.3



Okay, I checked in a patch to sort out all these problems. Please try
it out on QEMU again and let me know if probing fails.

Note that only DOM0 will be useful in such a setup right now --- there
is no way for other domains to access devices that are controlled by
DOM0. New inter-domain virtual device drivers to cope with this are in
the pipeline...

 -- Keir

>
> The PCI- and IRQ-virtualisation is not quite there yet -- but hopefully
> it will be in a couple of days.
>
> Issues at the moment are:
>  - probing and routing of device interrupt pins -> IRQs is broken.
>  - passing of physical interrupts to guest OSes is untested and thus
>    probably broken in some way or another.
>
> I'm currently addressing all these problems.
>
>  -- Keir
>
> > I have been trying out the latest unstable with the new i/o and have
found
> > the following issue. I created a xen.gz with nodev=y set, and tried it
out
> > with all my devices in xenolinux.
> >
> > The "machine" I am running on is "qemu", and it doesn't have emulation
for
> > PCI. Therefore xenolinux is doing its ideprobes independent of the pci
ide
> > code.
> > It is calling the routine "probe_irq_on" in irq.c, and it is failing
with
> > the following messages:
> >
> > ide: Assuming 50MHz system bus speed for PIO modes; override with
idebus=xx
> > Kernel panic: Failed to obtain physical IRQ 127
> >
> > "Probe_irq_on" is used to enable ALL unallocated irqs, the caller code
will
> > then twig the device you are probing (in my case it is the ide drives
for
> > ide0 disk, and ide0 cdrom) - and then will record the irq that actually
got
> > the interrupt thus figuring out which irq belongs to which device.
> >
> > The reasons it is failing seem to be the following:
> > 1) The probe enables 127 physical IRQs (NR_PIRQS), but xen fails to bind
any
> > pirq > 63. This is because sched.h only defines pirq_to_evtchn with a
size
> > of 64
> > 2) When I tried making that constant from 64->128, it still failed on
IRQ 12
> > (which I think was already allocated to another device).
> >
> > I was able to get much much further by setting "ide0=0x1f0,0x3f6,14
> > ide1=noprobe ide2=noprobe ide3=noprobe" on the command line. It still
failed
> > much later on with an MMU update failure. I am currently tracking that
one
> > down further before reporting it.
> >
> >
> > Barry Silverman
> >
> >
> >
> > -------------------------------------------------------
> > 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
> _______________________________________________
> 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
_______________________________________________
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: Problems with latest unstable 1.3

[Barry Silverman]

So, with the current 1.3 - should I put the network device in xen, or in
xenolinux for domain 0?

I tried put eth0 in xen, and xenolinux doesn't seem to see it (even though
it used to before that last couple of major code drops). Do I have to
configure something different in domain 0?

Barry Silverman

-----Original Message-----
From: xen-devel-admin@lists.sourceforge.net
[mailto:xen-devel-admin@lists.sourceforge.net]On Behalf Of Rolf
Neugebauer
Sent: Tuesday, March 30, 2004 12:05 PM
To: Barry Silverman
Cc: rolf.neugebauer@intel.com; Keir Fraser;
xen-devel@lists.sourceforge.net
Subject: RE: [Xen-devel] Problems with latest unstable 1.3


On Tue, 2004-03-30 at 16:46, Barry Silverman wrote:
> In the new I/O world if xen owns the network interface, what does
xenolinux
> have to use as eth0?

the aim is that xen won't own any devices. for transition and boot
strapping purposes we may initially still have some devices owned by Xen
and some being assigned to some other VMs.

What a domain then sees as eth0 depends on how it will be configured and
in which order it probes for devices (virtual devices before physical or
vice versa).

> Are there any devices (such as virtual disks) that I can use with the code
> as is on a non-0 guest?

at the moment the physical devices used by a VM (dom0 only at the
moment) are not exported to other VMs, so you can not use them for now.
However, as Keir pointed out the exporting of physical devices as
virtual devices to other domains is in the pipeline.

HTH

rolf


> Barry Silverman
>
> -----Original Message-----
> From: xen-devel-admin@lists.sourceforge.net
> [mailto:xen-devel-admin@lists.sourceforge.net]On Behalf Of Keir Fraser
> Sent: Monday, March 29, 2004 9:49 AM
> To: Keir Fraser
> Cc: Barry Silverman; xen-devel@lists.sourceforge.net
> Subject: Re: [Xen-devel] Problems with latest unstable 1.3
>
>
>
> Okay, I checked in a patch to sort out all these problems. Please try
> it out on QEMU again and let me know if probing fails.
>
> Note that only DOM0 will be useful in such a setup right now --- there
> is no way for other domains to access devices that are controlled by
> DOM0. New inter-domain virtual device drivers to cope with this are in
> the pipeline...
>
>  -- Keir
>
> >
> > The PCI- and IRQ-virtualisation is not quite there yet -- but hopefully
> > it will be in a couple of days.
> >
> > Issues at the moment are:
> >  - probing and routing of device interrupt pins -> IRQs is broken.
> >  - passing of physical interrupts to guest OSes is untested and thus
> >    probably broken in some way or another.
> >
> > I'm currently addressing all these problems.
> >
> >  -- Keir
> >
> > > I have been trying out the latest unstable with the new i/o and have
> found
> > > the following issue. I created a xen.gz with nodev=y set, and tried it
> out
> > > with all my devices in xenolinux.
> > >
> > > The "machine" I am running on is "qemu", and it doesn't have emulation
> for
> > > PCI. Therefore xenolinux is doing its ideprobes independent of the pci
> ide
> > > code.
> > > It is calling the routine "probe_irq_on" in irq.c, and it is failing
> with
> > > the following messages:
> > >
> > > ide: Assuming 50MHz system bus speed for PIO modes; override with
> idebus=xx
> > > Kernel panic: Failed to obtain physical IRQ 127
> > >
> > > "Probe_irq_on" is used to enable ALL unallocated irqs, the caller code
> will
> > > then twig the device you are probing (in my case it is the ide drives
> for
> > > ide0 disk, and ide0 cdrom) - and then will record the irq that
actually
> got
> > > the interrupt thus figuring out which irq belongs to which device.
> > >
> > > The reasons it is failing seem to be the following:
> > > 1) The probe enables 127 physical IRQs (NR_PIRQS), but xen fails to
bind
> any
> > > pirq > 63. This is because sched.h only defines pirq_to_evtchn with a
> size
> > > of 64
> > > 2) When I tried making that constant from 64->128, it still failed on
> IRQ 12
> > > (which I think was already allocated to another device).
> > >
> > > I was able to get much much further by setting "ide0=0x1f0,0x3f6,14
> > > ide1=noprobe ide2=noprobe ide3=noprobe" on the command line. It still
> failed
> > > much later on with an MMU update failure. I am currently tracking that
> one
> > > down further before reporting it.
> > >
> > >
> > > Barry Silverman
> > >
> > >
> > >
> > > -------------------------------------------------------
> > > 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
> > _______________________________________________
> > 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
> _______________________________________________
> 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
> _______________________________________________
> 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
_______________________________________________
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: Problems with latest unstable 1.3

[Keir Fraser]

> So, with the current 1.3 - should I put the network device in xen, or in
> xenolinux for domain 0?
> 
> I tried put eth0 in xen, and xenolinux doesn't seem to see it (even though
> it used to before that last couple of major code drops). Do I have to
> configure something different in domain 0?
> 
> Barry Silverman

For normal use you should leave the device drivers in Xen --- this is
because as yet there is no way to export device access from DOM0 to
other non-privileged guests.

However, it was useful to get debugging feedback when you ran device
drivers in DOM0 --- but right now it's not actually much use to anyone
except for debugging.

Give it a week or two and this will change. :-)

 -- Keir



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