Mailing List Archive

RE: [Xen-devel] Run X in other domains?
( Replying to xen-users instead of old sourceforge list. )

On Mon, 2005-04-18 at 17:53 +0100, Ian Pratt wrote:
> > Initially I made some progress with the pre-built kernel
> > binaries (from the current 2.0.5 release). The xenU kernel
> > lacks PCI support, and X reports "Cannot open /dev/tty0"
> > using it in domain 1. I switched to the xen0 kernel for PCI
> > support, and then X reported "Cannot find a free VT".
> >
> > The output from lspci lists everything but the VGA card in
> > domain 0, unless "lspci -H 1" is used. In other domains,
> > lspci reports only the VGA card and "lspci -H 1" reports "You
> > need to be root to have access to I/O ports". However X
> > still starts OK in domain 0, which surprised my.
> > I've confirmed that "xm dmesg" includes "Hiding PCI device
> > 01:00.0 from DOM0" after passing "physdev_dom0_hide=01:00.1" to Xen.
>
> I can see how you could start a very simple VGA-only Xserver -- by
> default dom0 happens to have access to the bottom 1MB of memory, which
> is enough to get a VGA Xserver working.

OK, I wasn't familiar with this. However I've checked XFree86.0.log
from domain 0 for memory reports, and these two lines indicate more than
1MB is available, which may be a problem:

(II) SIS(0): Using 15808K of framebuffer memory
...
(II) SIS(0): VESA VBE Total Mem: 16384 kB

> > I've followed Ian's advice, rebuilding Linux 2.6.10 with the
> > default xenU configuration eith XEN_PHSDEV_ACCESS added (to
> > automatically enable
> > DUMMY_CONSOLE) plus PCI support. However my kernel crashes
> > immediately after "Freeing unused kernel memory", even when I
> > pass "xencons=ttyS".
> > Perhaps the build broke somehow, or it's configuration is invalid?
>
> I think you'll need to look through the oops message to see what's going
> on.

I've included a relevant section below - I could post the whole output
as a gzip attachment if it would help?

> You could try setting xencons=off just to rule xencons out.

The domain still exits, albeit silently without console output. However
I have found that I need the suggested "xencons=ttyS" to avoid an
additional line of kernel output "Warning: unable to open an initial
console".

> I presume you've granted the PCI device to the other domain in it's
> config file?

I hoped that the line "pci = [ '01,00,00' ]" in my previous post was
sufficient?

Cheers,

Sean.


Xen console output section from new domain:

Oops: 0000 [#1]
PREEMPT
Modules linked in:
CPU: 0
EIP: 0061:[<c0227a02>] Not tainted VLI
EFLAGS: 00010246 (2.6.10xenU-mod)
EIP is at visual_init+0x72/0x1c0
eax: 00000000 ebx: c00e6e00 ecx: 00000000 edx: c00e6e00
esi: 00000000 edi: 00000001 ebp: 00000000 esp: c0023e94
ds: 007b es: 007b ss: 0069
Process init (pid: 1, threadinfo=c0022000 task=c03b69e0)
Stack: 00000000 000000d0 c00e6e00 00000000 c0227bf1 00000000 00000001
00000000
c00c9bc0 00000000 00000000 c1365000 00400000 c022b1e8 00000000
ffffffed
c00dab80 00000001 c021aa6d c1365000 c00dab80 c0023ef0 00000102
c1365000
Call Trace:
[<c0227bf1>] vc_allocate+0xa1/0x1b0
[<c022b1e8>] con_open+0x48/0xc0
[<c021aa6d>] tty_open+0x24d/0x2d0
[<c021a820>] tty_open+0x0/0x2d0
[<c015e96a>] chrdev_open+0xea/0x1d0
[<c0343324>] free_area_init_core+0xb4/0x300
[<c0343324>] free_area_init_core+0xb4/0x300
[<c015486a>] dentry_open+0x15a/0x240
[<c0343324>] free_area_init_core+0xb4/0x300
[<c0154708>] filp_open+0x68/0x70
[<c0154989>] get_unused_fd+0x39/0xe0
[<c0154af9>] sys_open+0x49/0x90
[<c0109658>] syscall_call+0x7/0xb
Code: 40 6d 36 c0 a1 2c 6d 36 c0 89 42 28 8b 14 b5 80 7e 36 c0 85 d2 74
0a 8b 04 b5 40 6d 36 c0 89 50 28 8b 14 b5 40 6d 36 c0 8b 42 28 <8b> 18
85 db 74 35 89 1c 24 e8 80 8c f0 ff 85 c0 0f 84 09 01 00
<0>Kernel panic - not syncing: Attempted to kill init!
<0>Rebooting in 1 seconds..

--
Sean Atkinson <sean@netproject.com>
Netproject


_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users
RE: [Xen-devel] Run X in other domains? [ In reply to ]
> > I can see how you could start a very simple VGA-only Xserver -- by
> > default dom0 happens to have access to the bottom 1MB of
> memory, which
> > is enough to get a VGA Xserver working.
>
> OK, I wasn't familiar with this. However I've checked
> XFree86.0.log from domain 0 for memory reports, and these two
> lines indicate more than 1MB is available, which may be a problem:
>
> (II) SIS(0): Using 15808K of framebuffer memory ...
> (II) SIS(0): VESA VBE Total Mem: 16384 kB

Ah, OK. Thinking about this further, this still doesn't worry me as the
VESA BIOS isn't using the pci device table to find the card. As dom0 is
fully privileged its able to map the memory.

> > > I've followed Ian's advice, rebuilding Linux 2.6.10 with
> the default
> > > xenU configuration eith XEN_PHSDEV_ACCESS added (to automatically
> > > enable
> > > DUMMY_CONSOLE) plus PCI support. However my kernel crashes
> > > immediately after "Freeing unused kernel memory", even
> when I pass
> > > "xencons=ttyS".
> > > Perhaps the build broke somehow, or it's configuration is invalid?
> >
> > I think you'll need to look through the oops message to see what's
> > going on.
>
> I've included a relevant section below - I could post the
> whole output as a gzip attachment if it would help?

I think you'll need to add a bit of debugging to the relevant functions,
or better, use the gdb server to have a poke around.

> > You could try setting xencons=off just to rule xencons out.
>
> The domain still exits, albeit silently without console
> output. However I have found that I need the suggested
> "xencons=ttyS" to avoid an additional line of kernel output
> "Warning: unable to open an initial console".

Can you login via ssh? What does dmesg show?

> > I presume you've granted the PCI device to the other domain in it's
> > config file?
>
> I hoped that the line "pci = [ '01,00,00' ]" in my previous
> post was sufficient?

Is that really the bus location of the graphics card?

Ian

_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users
RE: [Xen-devel] Run X in other domains? [ In reply to ]
On Tue, 2005-04-19 at 09:29 +0100, Ian Pratt wrote:
> > > default dom0 happens to have access to the bottom 1MB of
> > memory, which
> > > is enough to get a VGA Xserver working.
> >
> > OK, I wasn't familiar with this. However I've checked
> > XFree86.0.log from domain 0 for memory reports, and these two
> > lines indicate more than 1MB is available, which may be a problem:
> >
> > (II) SIS(0): Using 15808K of framebuffer memory ...
> > (II) SIS(0): VESA VBE Total Mem: 16384 kB
>
> Ah, OK. Thinking about this further, this still doesn't worry me as the
> VESA BIOS isn't using the pci device table to find the card. As dom0 is
> fully privileged its able to map the memory.

Fair enough.

> > > I think you'll need to look through the oops message to see what's
> > > going on.
> >
> > I've included a relevant section below - I could post the
> > whole output as a gzip attachment if it would help?
>
> I think you'll need to add a bit of debugging to the relevant functions,
> or better, use the gdb server to have a poke around.

I'm afraid I've only recently caught up with Xen so I probably can't
help too much with development just yet, and I guess that would belong
on xen-devel anyway. Also I haven't noticed any details regarding gdb
server usage anywhere, so I'm not sure about that either.

> > > You could try setting xencons=off just to rule xencons out.
> >
> > The domain still exits, albeit silently without console
> > output. However I have found that I need the suggested
> > "xencons=ttyS" to avoid an additional line of kernel output
> > "Warning: unable to open an initial console".
>
> Can you login via ssh? What does dmesg show?

With my modified kernel new domains crash before init, so SSH never gets
a chance. The console output only ever shows the initial boot as far as
"Freeing unused kernel memory" before the debug output about the crash.
I could include all this in full but wasn't sure if the attachment would
be OK.

> > > I presume you've granted the PCI device to the other domain in it's
> > > config file?
> >
> > I hoped that the line "pci = [ '01,00,00' ]" in my previous
> > post was sufficient?
>
> Is that really the bus location of the graphics card?

As far as I can tell - X, scanpci & lspci all seem to agree.

Cheers,

Sean.

--
Sean Atkinson <sean@netproject.com>
Netproject


_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users
Re: [Xen-devel] Run X in other domains? [ In reply to ]
Hi,


Nice to see more interest in this issue ;-), I'm still trying to look into
this as well, but I have so little time to play with it :-(

> > Can you login via ssh? What does dmesg show?
>
> With my modified kernel new domains crash before init, so SSH never gets
> a chance. The console output only ever shows the initial boot as far as
> "Freeing unused kernel memory" before the debug output about the crash.
> I could include all this in full but wasn't sure if the attachment would
> be OK.

What settings are you including in your domU kernel config? I had similar
problems when I was building with fbcon included, do you have vesafb
built-in? And fbcon?
I had more luck when I went for a more modular kernel, (matroxfb, and fbcon
build as modules, no vesa built-in framebuffer).

I am able to boot into dom1, and am able to insert the matroxfb module, thus I
can cat data to /dev/fb0, showing that it is accessable. However, as soon as
I insmod fbcon, it oopses. The system was still working though, so I was able
to track it down, it seems VT subsystem is not properly initialised :-(
When I have some time, I'll be looking into VT initialisation to see where it
goes wrong.
Anyways, this was all on -unstable, so not sure about 2.0.5 right now.

Basically my experiments have shown two problems when trying to start X:
1) X needs a VT to run, and I've been unable to get a working dom1 with VT.
2) After patching X to not need a VT, I ran into some IO access problem (not
sure about the message anymore, but should be in the devel list archives
somewhere, as well as a reference to the patch). It did not seem like a big
problem, but I've not been able to get past it yet :-( I tried to patch and
rebuilt X again, but could not get a stable version anymore...


Regards,
Mark.

_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users
Re: [Xen-devel] Run X in other domains? [ In reply to ]
On Tue, 2005-04-19 at 22:15 +0000, Mark Hurenkamp wrote:

> What settings are you including in your domU kernel config? I had similar
> problems when I was building with fbcon included, do you have vesafb
> built-in? And fbcon?

All I deliberately changed from the default xenU config was enabling
CONFIG_XEN_PHYSDEV_ACCESS & CONFIG_PCI. This automatically set a bunch
of other options to 'y', including _INPUT, _VT, _VT_CONSOLE,
_VGA_CONSOLE & _DUMMY_CONSOLE (as recommended). No VESA/FB configs set.

> I had more luck when I went for a more modular kernel, (matroxfb, and fbcon
> build as modules, no vesa built-in framebuffer).
>
> I am able to boot into dom1, and am able to insert the matroxfb module, thus I
> can cat data to /dev/fb0, showing that it is accessable. However, as soon as
> I insmod fbcon, it oopses. The system was still working though, so I was able
> to track it down, it seems VT subsystem is not properly initialised :-(
> When I have some time, I'll be looking into VT initialisation to see where it
> goes wrong.
> Anyways, this was all on -unstable, so not sure about 2.0.5 right now.

I'm afraid I have to move onto other things right now, so I can't look
into these details either I'm afraid.

> Basically my experiments have shown two problems when trying to start X:
> 1) X needs a VT to run, and I've been unable to get a working dom1 with VT.
> 2) After patching X to not need a VT, I ran into some IO access problem (not
> sure about the message anymore, but should be in the devel list archives
> somewhere, as well as a reference to the patch). It did not seem like a big
> problem, but I've not been able to get past it yet :-( I tried to patch and
> rebuilt X again, but could not get a stable version anymore...

Your experience seems similar to Gerd Knorr's, both indicating X is at
least partly to blame. I plan to wait until the X fixes are available
before testing Xen against them, so we might at least hope that X is
behaving before worrying about debugging Xen.

In the mean time of course if anybody makes any progress it would be
great to hear about it ...

Cheers,

Sean.

--
Sean Atkinson <sean@netproject.com>
Netproject


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