Hi.
I''ve got linux system running on it''s own box that I want to
convert to a
PV domU in xen. The kernel panics after adding the xenblk module.
Here''s what I''ve done:
1) tar''ed up the running non-xen system and copy to dom0
2) created new LV on dom0
3) fdisked, kpartx -a , pvcreate, vgcreate, lvcreate, mount etc...
that LV into a normal file hierarchy.
4) untar''ed the tar file from step 1 onto my new file heirarchy.
5) chroot to new file hierarchy
6) fiddle with /dev, /etc/modprobe, network config etc..
7) run mkinitrd with --with=xenblk
8) exit chroot
9) umount, vgchange -an, kpartx -d the new file hierarchy
10) copy kernel & new initrd out of new file hierarchy onto somewhere
handy on Dom0.
11) build xm config file with kernel= and ramdisk= kernel and initrd
from step 10
Obviously, this is not a detailed explanation, just an overview so
you see the general method I''m using.
When I run ''xm create -c'', it runs along nicely for a bit and
then...
...
Loading ext3.ko module
Loading xenblk.ko module
Registering block device major 8
blkfront: sda: barriers enabled
sda:end_request: I/O error, dev sda, sector 0
Buffer I/O error on device sda, logical block 0
BUG: unable to handle kernel paging request at virtual address
a031dcc8
printing eip:
ee02e928
01c96000 -> *pde = 00000000:38cda027
01c99000 -> *pme = 00000000:00000000
Oops: 0000 [#1]
SMP
last sysfs file: /block/ram0/dev
Modules linked in: xenblk ext3 jbd mbcache ehci_hcd ohci_hcd uhci_hcd
CPU: 0
EIP: 0061:[<ee02e928>] Not tainted VLI
EFLAGS: 00010887 (2.6.20-2925.11.fc7xen #1)
EIP is at blkif_int+0x5a/0x18c [xenblk]
eax: e0009c00 ebx: c0314000 ecx: 000002c2 edx: 08000100
esi: 00000000 edi: c17160ac ebp: c135cfc8 esp: c135cf9c
ds: 007b es: 007b ss: 0069
Process swapper (pid: 0, ti=c135c000 task=c12bd2e0 task.ti=c1307000)
Stack: 00000000 c135cfc8 c1036df8 00000001 00000002 00000001 08000100 c12fa6b8
c1d22980 00000000 00000000 c135cfe0 c1047682 00000105 c12fa680 00000105
c1d22980 c135cff8 c1048a74 c12fa6a8 c1307f18 00000105 c10489da c1307f34
Call Trace:
[<c1005d3a>] show_trace_log_lvl+0x1a/0x2f
[<c1005dea>] show_stack_log_lvl+0x9b/0xa3
[<c1005f86>] show_registers+0x194/0x26a
[<c100618d>] die+0x131/0x246
[<c11f79d5>] do_page_fault+0xaf7/0xc7b
[<c11f5cf5>] error_code+0x35/0x3c
[<c1047682>] handle_IRQ_event+0x1a/0x45
[<c1048a74>] handle_level_irq+0x9a/0xea
[<c1007018>] do_IRQ+0xba/0xe2
======================Code: e8 89 f6 8b 43 20 89 45 e0 e9 ed 00 00 00 8b 43 24
31 f6 48 23
45 e0 6b c0 6c 8d 78 40 03 7b 28 8b 17 69 c2 9c 00 00 00 89 55 ec <8b>
94 18 c8 00 00 00 8d 44 18 5c 89 45 f0 89 55 dc eb 11 8b 55
EIP: [<ee02e928>] blkif_int+0x5a/0x18c [xenblk] SS:ESP 0069:c135cf9c
<0>Kernel panic - not syncing: Fatal exception in interrupt
Any ideas?
-Dylan
_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users
Oy! I think I figured it out. Xen box = 64bit Tar archive = 32bit Me = ouch!> Hi. > > I''ve got linux system running on it''s own box that I want to convert to a > PV domU in xen. The kernel panics after adding the xenblk module. > > Here''s what I''ve done: > > 1) tar''ed up the running non-xen system and copy to dom0 > 2) created new LV on dom0 > 3) fdisked, kpartx -a , pvcreate, vgcreate, lvcreate, mount etc... > that LV into a normal file hierarchy. > 4) untar''ed the tar file from step 1 onto my new file heirarchy. > 5) chroot to new file hierarchy > 6) fiddle with /dev, /etc/modprobe, network config etc.. > 7) run mkinitrd with --with=xenblk > 8) exit chroot > 9) umount, vgchange -an, kpartx -d the new file hierarchy > 10) copy kernel & new initrd out of new file hierarchy onto somewhere > handy on Dom0. > 11) build xm config file with kernel= and ramdisk= kernel and initrd > from step 10 > > Obviously, this is not a detailed explanation, just an overview so > you see the general method I''m using. > > When I run ''xm create -c'', it runs along nicely for a bit and then... > > ... > Loading ext3.ko module > Loading xenblk.ko module > Registering block device major 8 > blkfront: sda: barriers enabled > sda:end_request: I/O error, dev sda, sector 0 > Buffer I/O error on device sda, logical block 0 > BUG: unable to handle kernel paging request at virtual address > a031dcc8 > printing eip: > ee02e928 > 01c96000 -> *pde = 00000000:38cda027 > 01c99000 -> *pme = 00000000:00000000 > Oops: 0000 [#1] > SMP > last sysfs file: /block/ram0/dev > Modules linked in: xenblk ext3 jbd mbcache ehci_hcd ohci_hcd uhci_hcd > CPU: 0 > EIP: 0061:[<ee02e928>] Not tainted VLI > EFLAGS: 00010887 (2.6.20-2925.11.fc7xen #1) > EIP is at blkif_int+0x5a/0x18c [xenblk] > eax: e0009c00 ebx: c0314000 ecx: 000002c2 edx: 08000100 > esi: 00000000 edi: c17160ac ebp: c135cfc8 esp: c135cf9c > ds: 007b es: 007b ss: 0069 > Process swapper (pid: 0, ti=c135c000 task=c12bd2e0 task.ti=c1307000) > Stack: 00000000 c135cfc8 c1036df8 00000001 00000002 00000001 08000100 c12fa6b8 > c1d22980 00000000 00000000 c135cfe0 c1047682 00000105 c12fa680 00000105 > c1d22980 c135cff8 c1048a74 c12fa6a8 c1307f18 00000105 c10489da c1307f34 > Call Trace: > [<c1005d3a>] show_trace_log_lvl+0x1a/0x2f > [<c1005dea>] show_stack_log_lvl+0x9b/0xa3 > [<c1005f86>] show_registers+0x194/0x26a > [<c100618d>] die+0x131/0x246 > [<c11f79d5>] do_page_fault+0xaf7/0xc7b > [<c11f5cf5>] error_code+0x35/0x3c > [<c1047682>] handle_IRQ_event+0x1a/0x45 > [<c1048a74>] handle_level_irq+0x9a/0xea > [<c1007018>] do_IRQ+0xba/0xe2 > ======================> Code: e8 89 f6 8b 43 20 89 45 e0 e9 ed 00 00 00 8b 43 24 31 f6 48 23 > 45 e0 6b c0 6c 8d 78 40 03 7b 28 8b 17 69 c2 9c 00 00 00 89 55 ec <8b> > 94 18 c8 00 00 00 8d 44 18 5c 89 45 f0 89 55 dc eb 11 8b 55 > EIP: [<ee02e928>] blkif_int+0x5a/0x18c [xenblk] SS:ESP 0069:c135cf9c > <0>Kernel panic - not syncing: Fatal exception in interrupt > > Any ideas? > > -Dylan > > > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xensource.com > http://lists.xensource.com/xen-users_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Hello, Should not 32bit linux DomU also work under 64bit Xen? I thought it is possible... With regards, Artur -----Original Message----- From: xen-users-bounces@lists.xensource.com [mailto:xen-users-bounces@lists.xensource.com] On Behalf Of Dylan Martin Sent: Thursday, July 12, 2007 2:09 AM To: Xen Users Subject: Re: [Xen-users] baremetal to PV troubles Oy! I think I figured it out. Xen box = 64bit Tar archive = 32bit Me = ouch!> Hi. > > I''ve got linux system running on it''s own box that I want to convert to a > PV domU in xen. The kernel panics after adding the xenblk module. > > Here''s what I''ve done: > > 1) tar''ed up the running non-xen system and copy to dom0 > 2) created new LV on dom0 > 3) fdisked, kpartx -a , pvcreate, vgcreate, lvcreate, mount etc... > that LV into a normal file hierarchy. > 4) untar''ed the tar file from step 1 onto my new file heirarchy. > 5) chroot to new file hierarchy > 6) fiddle with /dev, /etc/modprobe, network config etc.. > 7) run mkinitrd with --with=xenblk > 8) exit chroot > 9) umount, vgchange -an, kpartx -d the new file hierarchy > 10) copy kernel & new initrd out of new file hierarchy onto somewhere > handy on Dom0. > 11) build xm config file with kernel= and ramdisk= kernel and initrd > from step 10 > > Obviously, this is not a detailed explanation, just an overview so > you see the general method I''m using. > > When I run ''xm create -c'', it runs along nicely for a bit and then... > > ... > Loading ext3.ko module > Loading xenblk.ko module > Registering block device major 8 > blkfront: sda: barriers enabled > sda:end_request: I/O error, dev sda, sector 0 > Buffer I/O error on device sda, logical block 0 > BUG: unable to handle kernel paging request at virtual address > a031dcc8 > printing eip: > ee02e928 > 01c96000 -> *pde = 00000000:38cda027 > 01c99000 -> *pme = 00000000:00000000 > Oops: 0000 [#1] > SMP > last sysfs file: /block/ram0/dev > Modules linked in: xenblk ext3 jbd mbcache ehci_hcd ohci_hcd uhci_hcd > CPU: 0 > EIP: 0061:[<ee02e928>] Not tainted VLI > EFLAGS: 00010887 (2.6.20-2925.11.fc7xen #1) > EIP is at blkif_int+0x5a/0x18c [xenblk] > eax: e0009c00 ebx: c0314000 ecx: 000002c2 edx: 08000100 > esi: 00000000 edi: c17160ac ebp: c135cfc8 esp: c135cf9c > ds: 007b es: 007b ss: 0069 > Process swapper (pid: 0, ti=c135c000 task=c12bd2e0 task.ti=c1307000) > Stack: 00000000 c135cfc8 c1036df8 00000001 00000002 00000001 08000100c12fa6b8> c1d22980 00000000 00000000 c135cfe0 c1047682 00000105 c12fa68000000105> c1d22980 c135cff8 c1048a74 c12fa6a8 c1307f18 00000105 c10489dac1307f34> Call Trace: > [<c1005d3a>] show_trace_log_lvl+0x1a/0x2f > [<c1005dea>] show_stack_log_lvl+0x9b/0xa3 > [<c1005f86>] show_registers+0x194/0x26a > [<c100618d>] die+0x131/0x246 > [<c11f79d5>] do_page_fault+0xaf7/0xc7b > [<c11f5cf5>] error_code+0x35/0x3c > [<c1047682>] handle_IRQ_event+0x1a/0x45 > [<c1048a74>] handle_level_irq+0x9a/0xea > [<c1007018>] do_IRQ+0xba/0xe2 > ======================> Code: e8 89 f6 8b 43 20 89 45 e0 e9 ed 00 00 00 8b 43 24 31 f6 48 23 > 45 e0 6b c0 6c 8d 78 40 03 7b 28 8b 17 69 c2 9c 00 00 00 89 55 ec <8b> > 94 18 c8 00 00 00 8d 44 18 5c 89 45 f0 89 55 dc eb 11 8b 55 > EIP: [<ee02e928>] blkif_int+0x5a/0x18c [xenblk] SS:ESP 0069:c135cf9c > <0>Kernel panic - not syncing: Fatal exception in interrupt > > Any ideas? > > -Dylan > > > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xensource.com > http://lists.xensource.com/xen-users_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users __________ Informace od NOD32 2394 (20070711) __________ Tato zprava byla proverena antivirovym systemem NOD32. http://www.nod32.cz _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Yeah, you know I had that thought this morning as I was waking up. Basically, any time I tried to boot with a 32 bit kernel & initrd, it panicked. I tried with my own kernel & initrd and with the i386 Fedora 7 xen install kernel & initrd and got crashes every time. When I tried the x86_64 Fedora 7 xen install initrd and kernel, it worked fine. So, why is that? It seems to be croaking on the xenblk module specifically. Does anyone know if there are other xm config settings that you must put in place to make a 32 bit linux pv domU run on a 64 bit linux dom0? That''s my best theory as of this moment. -Dylan> Hello, > > Should not 32bit linux DomU also work under 64bit Xen? I thought it > is possible... > > With regards, > > Artur > > -----Original Message----- > From: xen-users-bounces@lists.xensource.com > [mailto:xen-users-bounces@lists.xensource.com] On Behalf Of Dylan Martin > Sent: Thursday, July 12, 2007 2:09 AM > To: Xen Users > Subject: Re: [Xen-users] baremetal to PV troubles > > Oy! I think I figured it out. > > Xen box = 64bit > Tar archive = 32bit > Me = ouch! > > > Hi. > > > > I''ve got linux system running on it''s own box that I want to convert to a > > PV domU in xen. The kernel panics after adding the xenblk module. > > > > Here''s what I''ve done: > > > > 1) tar''ed up the running non-xen system and copy to dom0 > > 2) created new LV on dom0 > > 3) fdisked, kpartx -a , pvcreate, vgcreate, lvcreate, mount etc... > > that LV into a normal file hierarchy. > > 4) untar''ed the tar file from step 1 onto my new file heirarchy. > > 5) chroot to new file hierarchy > > 6) fiddle with /dev, /etc/modprobe, network config etc.. > > 7) run mkinitrd with --with=xenblk > > 8) exit chroot > > 9) umount, vgchange -an, kpartx -d the new file hierarchy > > 10) copy kernel & new initrd out of new file hierarchy onto somewhere > > handy on Dom0. > > 11) build xm config file with kernel= and ramdisk= kernel and initrd > > from step 10 > > > > Obviously, this is not a detailed explanation, just an overview so > > you see the general method I''m using. > > > > When I run ''xm create -c'', it runs along nicely for a bit and then... > > > > ... > > Loading ext3.ko module > > Loading xenblk.ko module > > Registering block device major 8 > > blkfront: sda: barriers enabled > > sda:end_request: I/O error, dev sda, sector 0 > > Buffer I/O error on device sda, logical block 0 > > BUG: unable to handle kernel paging request at virtual address > > a031dcc8 > > printing eip: > > ee02e928 > > 01c96000 -> *pde = 00000000:38cda027 > > 01c99000 -> *pme = 00000000:00000000 > > Oops: 0000 [#1] > > SMP > > last sysfs file: /block/ram0/dev > > Modules linked in: xenblk ext3 jbd mbcache ehci_hcd ohci_hcd uhci_hcd > > CPU: 0 > > EIP: 0061:[<ee02e928>] Not tainted VLI > > EFLAGS: 00010887 (2.6.20-2925.11.fc7xen #1) > > EIP is at blkif_int+0x5a/0x18c [xenblk] > > eax: e0009c00 ebx: c0314000 ecx: 000002c2 edx: 08000100 > > esi: 00000000 edi: c17160ac ebp: c135cfc8 esp: c135cf9c > > ds: 007b es: 007b ss: 0069 > > Process swapper (pid: 0, ti=c135c000 task=c12bd2e0 task.ti=c1307000) > > Stack: 00000000 c135cfc8 c1036df8 00000001 00000002 00000001 08000100 > c12fa6b8 > > c1d22980 00000000 00000000 c135cfe0 c1047682 00000105 c12fa680 > 00000105 > > c1d22980 c135cff8 c1048a74 c12fa6a8 c1307f18 00000105 c10489da > c1307f34 > > Call Trace: > > [<c1005d3a>] show_trace_log_lvl+0x1a/0x2f > > [<c1005dea>] show_stack_log_lvl+0x9b/0xa3 > > [<c1005f86>] show_registers+0x194/0x26a > > [<c100618d>] die+0x131/0x246 > > [<c11f79d5>] do_page_fault+0xaf7/0xc7b > > [<c11f5cf5>] error_code+0x35/0x3c > > [<c1047682>] handle_IRQ_event+0x1a/0x45 > > [<c1048a74>] handle_level_irq+0x9a/0xea > > [<c1007018>] do_IRQ+0xba/0xe2 > > ======================> > Code: e8 89 f6 8b 43 20 89 45 e0 e9 ed 00 00 00 8b 43 24 31 f6 48 23 > > 45 e0 6b c0 6c 8d 78 40 03 7b 28 8b 17 69 c2 9c 00 00 00 89 55 ec <8b> > > 94 18 c8 00 00 00 8d 44 18 5c 89 45 f0 89 55 dc eb 11 8b 55 > > EIP: [<ee02e928>] blkif_int+0x5a/0x18c [xenblk] SS:ESP 0069:c135cf9c > > <0>Kernel panic - not syncing: Fatal exception in interrupt > > > > Any ideas? > > > > -Dylan > > > > > > > > _______________________________________________ > > Xen-users mailing list > > Xen-users@lists.xensource.com > > http://lists.xensource.com/xen-users > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xensource.com > http://lists.xensource.com/xen-users > > __________ Informace od NOD32 2394 (20070711) __________ > > Tato zprava byla proverena antivirovym systemem NOD32. > http://www.nod32.cz > >_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Thanks for answering! I have loads more questions... Okay, I think I understand. I''d use the 64 bit kernel & modules but the 32 bit libs, right? How does the 64 bit kernel know the userland is 32 bit? Won''t it try and find the 64 bit libs and freak out? Does it use memory like a 64 bit machine? Is there any reason to run a 32 bit domU in a 64 bit dom0? Thanks! -Dylan> 32 bit USERSPACE is fine, but for paravirtual, the KERNELS must match. You > can go do the 32 bit install somewhere and tar/rsync/copy/whatever the > files accross and the install should work somewhere, but you can''t use the > 32 bit kernel from that install. > > At least "kernels must match" for PV has been the way things are in the > past, maybe things have changed now. I haven''t used 3.1 yet. > > -Tom > > On Thu, 12 Jul 2007, Dylan Martin wrote: > > >Yeah, you know I had that thought this morning as I was waking up. > > > >Basically, any time I tried to boot with a 32 bit kernel & initrd, it > >panicked. I tried with my own kernel & initrd and with the i386 > >Fedora 7 xen install kernel & initrd and got crashes every time. When > >I tried the x86_64 Fedora 7 xen install initrd and kernel, it worked > >fine. So, why is that? It seems to be croaking on the xenblk module > >specifically. > > > >Does anyone know if there are other xm config settings that you must > >put in place to make a 32 bit linux pv domU run on a 64 bit linux > >dom0? That''s my best theory as of this moment. > > > >-Dylan > > > >>Hello, > >> > >> Should not 32bit linux DomU also work under 64bit Xen? I thought it > >>is possible... > >> > >> With regards, > >> > >> Artur > >> > >>-----Original Message----- > >>From: xen-users-bounces@lists.xensource.com > >>[mailto:xen-users-bounces@lists.xensource.com] On Behalf Of Dylan Martin > >>Sent: Thursday, July 12, 2007 2:09 AM > >>To: Xen Users > >>Subject: Re: [Xen-users] baremetal to PV troubles > >> > >>Oy! I think I figured it out. > >> > >>Xen box = 64bit > >>Tar archive = 32bit > >>Me = ouch! > >> > >>>Hi. > >>> > >>>I''ve got linux system running on it''s own box that I want to convert to a > >>>PV domU in xen. The kernel panics after adding the xenblk module. > >>> > >>> Here''s what I''ve done: > >>> > >>>1) tar''ed up the running non-xen system and copy to dom0 > >>>2) created new LV on dom0 > >>>3) fdisked, kpartx -a , pvcreate, vgcreate, lvcreate, mount etc... > >>> that LV into a normal file hierarchy. > >>>4) untar''ed the tar file from step 1 onto my new file heirarchy. > >>>5) chroot to new file hierarchy > >>>6) fiddle with /dev, /etc/modprobe, network config etc.. > >>>7) run mkinitrd with --with=xenblk > >>>8) exit chroot > >>>9) umount, vgchange -an, kpartx -d the new file hierarchy > >>>10) copy kernel & new initrd out of new file hierarchy onto somewhere > >>>handy on Dom0. > >>>11) build xm config file with kernel= and ramdisk= kernel and initrd > >>>from step 10 > >>> > >>>Obviously, this is not a detailed explanation, just an overview so > >>>you see the general method I''m using. > >>> > >>>When I run ''xm create -c'', it runs along nicely for a bit and then... > >>> > >>>... > >>>Loading ext3.ko module > >>>Loading xenblk.ko module > >>>Registering block device major 8 > >>>blkfront: sda: barriers enabled > >>> sda:end_request: I/O error, dev sda, sector 0 > >>>Buffer I/O error on device sda, logical block 0 > >>>BUG: unable to handle kernel paging request at virtual address > >>>a031dcc8 > >>> printing eip: > >>>ee02e928 > >>>01c96000 -> *pde = 00000000:38cda027 > >>>01c99000 -> *pme = 00000000:00000000 > >>>Oops: 0000 [#1] > >>>SMP > >>>last sysfs file: /block/ram0/dev > >>>Modules linked in: xenblk ext3 jbd mbcache ehci_hcd ohci_hcd uhci_hcd > >>>CPU: 0 > >>>EIP: 0061:[<ee02e928>] Not tainted VLI > >>>EFLAGS: 00010887 (2.6.20-2925.11.fc7xen #1) > >>>EIP is at blkif_int+0x5a/0x18c [xenblk] > >>>eax: e0009c00 ebx: c0314000 ecx: 000002c2 edx: 08000100 > >>>esi: 00000000 edi: c17160ac ebp: c135cfc8 esp: c135cf9c > >>>ds: 007b es: 007b ss: 0069 > >>>Process swapper (pid: 0, ti=c135c000 task=c12bd2e0 task.ti=c1307000) > >>>Stack: 00000000 c135cfc8 c1036df8 00000001 00000002 00000001 08000100 > >>c12fa6b8 > >>> c1d22980 00000000 00000000 c135cfe0 c1047682 00000105 c12fa680 > >>00000105 > >>> c1d22980 c135cff8 c1048a74 c12fa6a8 c1307f18 00000105 c10489da > >>c1307f34 > >>>Call Trace: > >>> [<c1005d3a>] show_trace_log_lvl+0x1a/0x2f > >>> [<c1005dea>] show_stack_log_lvl+0x9b/0xa3 > >>> [<c1005f86>] show_registers+0x194/0x26a > >>> [<c100618d>] die+0x131/0x246 > >>> [<c11f79d5>] do_page_fault+0xaf7/0xc7b > >>> [<c11f5cf5>] error_code+0x35/0x3c > >>> [<c1047682>] handle_IRQ_event+0x1a/0x45 > >>> [<c1048a74>] handle_level_irq+0x9a/0xea > >>> [<c1007018>] do_IRQ+0xba/0xe2 > >>> ======================> >>>Code: e8 89 f6 8b 43 20 89 45 e0 e9 ed 00 00 00 8b 43 24 31 f6 48 23 > >>>45 e0 6b c0 6c 8d 78 40 03 7b 28 8b 17 69 c2 9c 00 00 00 89 55 ec <8b> > >>>94 18 c8 00 00 00 8d 44 18 5c 89 45 f0 89 55 dc eb 11 8b 55 > >>>EIP: [<ee02e928>] blkif_int+0x5a/0x18c [xenblk] SS:ESP 0069:c135cf9c > >>> <0>Kernel panic - not syncing: Fatal exception in interrupt > >>> > >>>Any ideas? > >>> > >>>-Dylan > >>> > >>> > >>> > >>>_______________________________________________ > >>>Xen-users mailing list > >>>Xen-users@lists.xensource.com > >>>http://lists.xensource.com/xen-users > >> > >>_______________________________________________ > >>Xen-users mailing list > >>Xen-users@lists.xensource.com > >>http://lists.xensource.com/xen-users > >> > >>__________ Informace od NOD32 2394 (20070711) __________ > >> > >>Tato zprava byla proverena antivirovym systemem NOD32. > >>http://www.nod32.cz > >> > >> > > > >_______________________________________________ > >Xen-users mailing list > >Xen-users@lists.xensource.com > >http://lists.xensource.com/xen-users > > > > ---------------------------------------------------------------------- > tbrown@BareMetal.com | "The Internet is a world of ends. You''re at one > http://BareMetal.com/ | end, and everybody and everything else are at the > web hosting since ''95 | other ends." - http://www.worldofends.com/_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Tom Brown
2007-Jul-12 17:27 UTC
Re: [Xen-users] baremetal to PV troubles (32/64 bit PV hybrid)
On Thu, 12 Jul 2007, Dylan Martin wrote:> Thanks for answering! I have loads more questions... > > Okay, I think I understand. I''d use the 64 bit kernel & modules but > the 32 bit libs, right? > > How does the 64 bit kernel know the userland is 32 bit? Won''t it try > and find the 64 bit libs and freak out?AFAIK, kernels don''t find libraries... userspace programs do. The 64 bit kernels provide all the 32 bit system calls (as long as the default option to do that wasn''t turned off when the kernel was built).> Does it use memory like a 64 bit machine?yes, raw memory allocation is a kernel thing.> Is there any reason to run a 32 bit domU in a 64 bit dom0?yes/no. 32 bit code is generally in more common use and better tested. If you''re using precompiled binaries you might not even have an option of running 64 bit code. Or you might simply have a 32 bit install on a physical machine that you want to move to a paravirt on a big machine without rebuilding from scratch and consequently breaking things. The one gotcha you will run into with the 32/64 bit hybrid is that some kernel related tools can get upset (iptables being an example, the simplest solution is to build a statically linked binary on a 64 bit machine and copy that across to your 32 bit userspace domU) -Tom _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Dylan Martin
2007-Jul-12 17:46 UTC
Re: [Xen-users] baremetal to PV troubles (32/64 bit PV hybrid)
Thanks! That answers all my questions!> On Thu, 12 Jul 2007, Dylan Martin wrote: > > >Thanks for answering! I have loads more questions... > > > >Okay, I think I understand. I''d use the 64 bit kernel & modules but > >the 32 bit libs, right? > > > >How does the 64 bit kernel know the userland is 32 bit? Won''t it try > >and find the 64 bit libs and freak out? > > AFAIK, kernels don''t find libraries... userspace programs do. The 64 bit > kernels provide all the 32 bit system calls (as long as the default option > to do that wasn''t turned off when the kernel was built). > > >Does it use memory like a 64 bit machine? > > yes, raw memory allocation is a kernel thing. > > >Is there any reason to run a 32 bit domU in a 64 bit dom0? > > yes/no. 32 bit code is generally in more common use and better tested. If > you''re using precompiled binaries you might not even have an option of > running 64 bit code. Or you might simply have a 32 bit install on a > physical machine that you want to move to a paravirt on a big machine > without rebuilding from scratch and consequently breaking things. > > The one gotcha you will run into with the 32/64 bit hybrid is that some > kernel related tools can get upset (iptables being an example, the > simplest solution is to build a statically linked binary on a 64 bit > machine and copy that across to your 32 bit userspace domU) > > -Tom > > >_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
jonr@destar.net
2007-Jul-12 18:41 UTC
Re: [Xen-users] baremetal to PV troubles (32/64 bit PV hybrid)
And mine! Thanks Tom. Jon Quoting Dylan Martin <dmartin@sccd.ctc.edu>:> Thanks! That answers all my questions! > >> On Thu, 12 Jul 2007, Dylan Martin wrote: >> >> >Thanks for answering! I have loads more questions... >> > >> >Okay, I think I understand. I''d use the 64 bit kernel & modules but >> >the 32 bit libs, right? >> > >> >How does the 64 bit kernel know the userland is 32 bit? Won''t it try >> >and find the 64 bit libs and freak out? >> >> AFAIK, kernels don''t find libraries... userspace programs do. The 64 bit >> kernels provide all the 32 bit system calls (as long as the default option >> to do that wasn''t turned off when the kernel was built). >> >> >Does it use memory like a 64 bit machine? >> >> yes, raw memory allocation is a kernel thing. >> >> >Is there any reason to run a 32 bit domU in a 64 bit dom0? >> >> yes/no. 32 bit code is generally in more common use and better tested. If >> you''re using precompiled binaries you might not even have an option of >> running 64 bit code. Or you might simply have a 32 bit install on a >> physical machine that you want to move to a paravirt on a big machine >> without rebuilding from scratch and consequently breaking things. >> >> The one gotcha you will run into with the 32/64 bit hybrid is that some >> kernel related tools can get upset (iptables being an example, the >> simplest solution is to build a statically linked binary on a 64 bit >> machine and copy that across to your 32 bit userspace domU) >> >> -Tom >> >> >> > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xensource.com > http://lists.xensource.com/xen-users >_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Dylan Martin wrote:> Thanks for answering! I have loads more questions... > > Okay, I think I understand. I''d use the 64 bit kernel & modules but > the 32 bit libs, right? > > How does the 64 bit kernel know the userland is 32 bit? Won''t it try > and find the 64 bit libs and freak out? > > Does it use memory like a 64 bit machine? Is there any reason to run > a 32 bit domU in a 64 bit dom0? > > Thanks! > -Dylan >The reason is to do your testing, and avoid compatibility issues, with 32-bit code. This is especially important for Q/A and development environments whose software will be bundled or ported to 32-bit userlands. _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users