stubdom questions

stubdom questions

[Zhai, Edwin]

[-- Attachment #1: Type: text/plain, Size: 4140 bytes --]

samuel,
I have a try with HVM stubdomain on r17062, but failed to make on 32b platform.
Attached patch can fix it, but don't know if okay.

After installation, I failed to start stubdom. So I created it manually and got 
following debug mesg(both HVMdomain and stubdom are created)

Can you give some lights on following questions:
1. I use default vnclisten. Does it matter?
2. Seems qemu in stubdom has some issue and couldn't update the 'vnc-port' in 
xenstore. Or the stubdom didn't run at all. How can I debug it?
3. "Create /etc/xen/stubdom-hvmconfig" in readme -- seems "hvmconfig" should 
match the domain name rather than config file.

Thanks,


=================== running error =============================
# xm list
Name                                        ID   Mem VCPUs      State   Time(s)
Domain-0                                     0  1813     2     r-----   2489.0
EdwinHVMDomainVtd2                          44   128     1     ------      0.0
stubdom-EdwinHVMDomainVtd2                  45    32     1     -b----      0.0


[root@vt-gang32 ~]# /usr/lib/xen/bin/stubdom-dm -d 44 -domain-name EdwinHVMDomai
nVtd2 -m 128 -vnc 127.0.0.1:0 -vncunused -monitor vc -vcpus 1 -boot c -serial pt
y -acpi -M xenfv
xenstore-read: couldn't read path /local/domain/44/console/vnc-port
Using config file "./stubdom-EdwinHVMDomainVtd2".
Started domain stubdom-EdwinHVMDomainVtd2
xenstore-read: couldn't read path /local/domain/44/console/vnc-port
Failed to read /local/domain/0/backend/vbd/45/768/feature-flush-cache.
16777216 sectors of 512 bytes
**************************
blk_open(/local/domain/45/device/vbd/768) -> 5
xs_read(/local/domain/45/device/vbd/5632/phantom_vbd): ENOENT
xs_watch(/local/domain/0/backend/vbd/45/5632/params, hdc)
******************* BLKFRONT for /local/domain/45/device/vbd/5632 **********


backend at /local/domain/0/backend/vbd/45/5632
xenstore-read: couldn't read path /local/domain/44/console/vnc-port
xenstore-read: couldn't read path /local/domain/44/console/vnc-port
xenstore-read: couldn't read path /local/domain/44/console/vnc-port

====================================================================

================== compile error ===================================
make[2]: Entering directory 
`/home/another/gzhai/srcs/hg/xen-dev/hv/extras/mini-os/arch/x86'
make[2]: Nothing to be done for `all'.
make[2]: Leaving directory 
`/home/another/gzhai/srcs/hg/xen-dev/hv/extras/mini-os/arch/x86'
i686-xen-elf-ld -r  -m elf_i386 arch/x86/x86_32.o blkfront.o events.o fs-front.o 
gnttab.o hypervisor.o kernel.o main.o mm.o netfront.o sched.o lib/ctype.o 
lib/math.o lib/printf.o lib/string.o lib/sys.o lib/xmalloc.o lib/xs.o 
xenbus/xenbus.o console/console.o console/xencons_ring.o lwip.a 
/home/another/gzhai/srcs/hg/xen-dev/hv/stubdom/ioemu/i386-dm-stubdom/qemu.a 
/home/another/gzhai/srcs/hg/xen-dev/hv/stubdom/ioemu/i386-dm-stubdom/libqemu.a 
-Larch/x86 -lx86_32  -L../../stubdom/libxc -lxenctrl -lxenguest -lpci -lz -lc -o 
mini-os.o
i686-xen-elf-objcopy -w -G xenos_* -G _start mini-os.o mini-os.o
i686-xen-elf-ld  -m elf_i386 -T arch/x86/minios-x86_32.lds mini-os.o  -o mini-os
mini-os.o: In function `bdrv_snapshot_dump':
/home/gzhai/srcs/hg/xen-dev/hv/stubdom/ioemu/block.c:1042: undefined reference 
to `__moddi3'
/home/gzhai/srcs/hg/xen-dev/hv/stubdom/ioemu/block.c:1042: undefined reference 
to `__moddi3'
mini-os.o: In function `vmdk_is_allocated':
/home/gzhai/srcs/hg/xen-dev/hv/stubdom/ioemu/block-vmdk.c:547: undefined 
reference to `__moddi3'
mini-os.o: In function `vmdk_read':
/home/gzhai/srcs/hg/xen-dev/hv/stubdom/ioemu/block-vmdk.c:563: undefined 
reference to `__moddi3'
mini-os.o: In function `cloop_read':
/home/gzhai/srcs/hg/xen-dev/hv/stubdom/ioemu/block-cloop.c:143: undefined 
reference to `__moddi3'
mini-os.o:/home/gzhai/srcs/hg/xen-dev/hv/stubdom/ioemu/block-bochs.c:182: more 
undefined references to `__moddi3' follow
make[1]: *** [mini-os] Error 1
make[1]: Leaving directory 
`/home/another/gzhai/srcs/hg/xen-dev/hv/extras/mini-os'
make: *** [qemu-stubdom] Error 2
===================================================================


-- 
best rgds,
edwin

[-- Attachment #2: stubdom_fix.patch --]
[-- Type: text/plain, Size: 684 bytes --]

diff -r bdc4d718bef7 extras/mini-os/lib/math.c
--- a/extras/mini-os/lib/math.c	Tue Feb 19 16:19:51 2008 +0800
+++ b/extras/mini-os/lib/math.c	Tue Feb 19 17:00:34 2008 +0800
@@ -388,6 +388,23 @@ __umoddi3(u_quad_t a, u_quad_t b)
         return (r);
 }
 
+/*
+ * Remainder of signed quad division.
+ * Truncates towards zero, as required by C99:
+ *  11 %  5 =  1
+ * -11 %  5 = -1
+ *  11 % -5 =  1
+ * -11 % -5 =  1
+ */
+s64 __moddi3(s64 a, s64 b)
+{
+    u64 ua, ub, urem;
+    int neg = (a < 0);
+    ua = neg ? -(u64)a : a;
+    ub = (b < 0) ? -(u64)b : b;
+    __qdivrem(ua, ub, &urem);
+    return (neg ? -urem : urem);
+}
 #endif /* !defined(__ia64__) */
 
 #ifndef HAVE_LIBC

[-- Attachment #3: xmexamplestub --]
[-- Type: text/plain, Size: 7644 bytes --]

# Python configuration setup for 'xm create'.
# This script sets the parameters used when a domain is created using 'xm create'.
# You use a separate script for each domain you want to create, or 
# you can set the parameters for the domain on the xm command line.
#============================================================================

import os, re
arch = os.uname()[4]
if re.search('64', arch):
    arch_libdir = 'lib64'
else:
    arch_libdir = 'lib'

#----------------------------------------------------------------------------
# Kernel image file.
kernel = "/usr/lib/xen/boot/hvmloader"

# The domain build function. HVM domain uses 'hvm'.
builder='hvm'

# Initial memory allocation (in megabytes) for the new domain.
#
# WARNING: Creating a domain with insufficient memory may cause out of
#          memory errors. The domain needs enough memory to boot kernel
#          and modules. Allocating less than 32MBs is not recommended.
memory = 128

# Shadow pagetable memory for the domain, in MB.
# If not explicictly set, xend will pick an appropriate value.  
# Should be at least 2KB per MB of domain memory, plus a few MB per vcpu.
# shadow_memory = 8

# A name for your domain. All domains must have different names.
name = "EdwinHVMDomainVtd2"

# 128-bit UUID for the domain.  The default behavior is to generate a new UUID
# on each call to 'xm create'.
#uuid = "06ed00fe-1162-4fc4-b5d8-11993ee4a8b9"

#-----------------------------------------------------------------------------
# The number of cpus guest platform has, default=1
#vcpus=2

# Enable/disable HVM guest PAE, default=1 (enabled)
pae=1

# Enable/disable HVM guest ACPI, default=1 (enabled)
acpi=1

# Enable/disable HVM APIC mode, default=1 (enabled)
# Note that this option is ignored if vcpus > 1
apic=1

# List of which CPUS this domain is allowed to use, default Xen picks
#cpus = ""         # leave to Xen to pick
#cpus = "0"        # all vcpus run on CPU0
#cpus = "0-3,5,^1" # run on cpus 0,2,3,5

# Optionally define mac and/or bridge for the network interfaces.
# Random MACs are assigned if not given.
#vif = [ 'type=ioemu, mac=00:16:3e:00:00:88, bridge=xenbr0' ]

#----------------------------------------------------------------------------
# Define the disk devices you want the domain to have access to, and
# what you want them accessible as.
# Each disk entry is of the form phy:UNAME,DEV,MODE
# where UNAME is the device, DEV is the device name the domain will see,
# and MODE is r for read-only, w for read-write.

#disk = [ 'file:/var/img/rhel5-ins.img,hda,w', ',hdc:cdrom,r' ]
#disk = [ 'file:/var/img/qcow/rhel4u2_ia32.img.vtd-lm.qcow,hda,w', ',hdc:cdrom,r' ]

#----------------------------------------------------------------------------
# Configure the behaviour when a domain exits.  There are three 'reasons'
# for a domain to stop: poweroff, reboot, and crash.  For each of these you
# may specify:
#
#   "destroy",        meaning that the domain is cleaned up as normal;
#   "restart",        meaning that a new domain is started in place of the old
#                     one;
#   "preserve",       meaning that no clean-up is done until the domain is
#                     manually destroyed (using xm destroy, for example); or
#   "rename-restart", meaning that the old domain is not cleaned up, but is
#                     renamed and a new domain started in its place.
#
# The default is
#
#   on_poweroff = 'destroy'
#   on_reboot   = 'restart'
#   on_crash    = 'restart'
#
# For backwards compatibility we also support the deprecated option restart
#
# restart = 'onreboot' means on_poweroff = 'destroy'
#                            on_reboot   = 'restart'
#                            on_crash    = 'destroy'
#
# restart = 'always'   means on_poweroff = 'restart'
#                            on_reboot   = 'restart'
#                            on_crash    = 'restart'
#
# restart = 'never'    means on_poweroff = 'destroy'
#                            on_reboot   = 'destroy'
#                            on_crash    = 'destroy'

#on_poweroff = 'destroy'
#on_reboot   = 'restart'
#on_crash    = 'restart'

#============================================================================

# New stuff
#device_model = '/usr/' + arch_libdir + '/xen/bin/qemu-dm'
device_model = '/boot/edwin/qemu-dm.debug'
#device_model = '/usr/lib/xen/bin/stubdom-dm'

#-----------------------------------------------------------------------------
# boot on floppy (a), hard disk (c), Network (n) or CD-ROM (d) 
# default: hard disk, cd-rom, floppy
#boot="cda"

#-----------------------------------------------------------------------------
#  write to temporary files instead of disk image files
#snapshot=1

#----------------------------------------------------------------------------
# enable SDL library for graphics, default = 0
sdl=0

#----------------------------------------------------------------------------
# enable VNC library for graphics, default = 1
vnc=1

#----------------------------------------------------------------------------
# address that should be listened on for the VNC server if vnc is set.
# default is to use 'vnc-listen' setting from /etc/xen/xend-config.sxp
#vnclisten="localhost"

#----------------------------------------------------------------------------
# set VNC display number, default = domid
#vncdisplay=1

#----------------------------------------------------------------------------
# try to find an unused port for the VNC server, default = 1
#vncunused=1

#----------------------------------------------------------------------------
# enable spawning vncviewer for domain's console
# (only valid when vnc=1), default = 0
#vncconsole=1

#----------------------------------------------------------------------------
# set password for domain's VNC console
# default is depents on vncpasswd in xend-config.sxp
vncpasswd=''

#----------------------------------------------------------------------------
# no graphics, use serial port
#nographic=0

#----------------------------------------------------------------------------
# enable stdvga, default = 0 (use cirrus logic device model)
stdvga=0

#-----------------------------------------------------------------------------
#   serial port re-direct to pty deivce, /dev/pts/n 
#   then xm console or minicom can connect
serial='pty'


#-----------------------------------------------------------------------------
#   Qemu Monitor, default is disable
#   Use ctrl-alt-2 to connect
monitor=1


#-----------------------------------------------------------------------------
#   enable sound card support, [sb16|es1370|all|..,..], default none
#soundhw='sb16'


#-----------------------------------------------------------------------------
#    set the real time clock to local time [default=0 i.e. set to utc]
#localtime=1


#-----------------------------------------------------------------------------
#    set the real time clock offset in seconds [default=0 i.e. same as dom0]
#rtc_timeoffset=3600

#-----------------------------------------------------------------------------
#    start in full screen
#full-screen=1   


#-----------------------------------------------------------------------------
#   Enable USB support (specific devices specified at runtime through the
#			monitor window)
#usb=1

#   Enable USB mouse support (only enable one of the following, `mouse' for
#			      PS/2 protocol relative mouse, `tablet' for
#			      absolute mouse)
#usbdevice='mouse'
#usbdevice='tablet'

#-----------------------------------------------------------------------------
#   Set keyboard layout, default is en-us keyboard. 
#keymap='ja'

[-- Attachment #4: stubdom-EdwinHVMDomainVtd2 --]
[-- Type: text/plain, Size: 327 bytes --]

kernel = "/usr/lib/xen/boot/stubdom.gz"


#vif = [ 'ip=10.239.36.188,', 'type=ioemu,  mac=00:16:3e:00:00:88, bridge=xenbr0' ]
vif = [ 'type=ioemu,  mac=00:16:3e:00:00:88, bridge=xenbr0' ]


disk = [ 'file:/var/img/rhel5-ins.img,hda,w', ',hdc:cdrom,r' ]
#disk = [ 'file:/var/img/qcow/rhel5-ins.img.qcow,hda,w', ',hdc:cdrom,r' ]

[-- Attachment #5: Type: text/plain, Size: 138 bytes --]

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

Re: stubdom questions

[Samuel Thibault]

Hello,

Zhai, Edwin, le Tue 19 Feb 2008 19:39:41 +0800, a écrit :
> I have a try with HVM stubdomain on r17062, but failed to make on 32b platform.
> Attached patch can fix it, but don't know if okay.

That is how such issues have usually been solved so I guess in principle
it is.  Is your code coming from freebsd too?

> After installation, I failed to start stubdom. So I created it manually

See the commented "xm create" line in the stubdom-dm script, to enable
debugging.

> 1. I use default vnclisten. Does it matter?

Yes:

> #----------------------------------------------------------------------------
> # address that should be listened on for the VNC server if vnc is set.
> # default is to use 'vnc-listen' setting from /etc/xen/xend-config.sxp
> #vnclisten="localhost"

So if your vnc-listen setting is e.g. localhost, the VNC server of the
stubdom will be restricted to the stub domain itself, and you won't be
able to connect.


> 2. Seems qemu in stubdom has some issue and couldn't update the 'vnc-port' in 
> xenstore.

Actually mini-os has no name resolving support so that it won't be able
to understand the default "localhost" for vnclisten and hence not start
VNC.

> Or the stubdom didn't run at all.

It did: messages like

******************* BLKFRONT for /local/domain/45/device/vbd/5632 **********

come from Mini-OS and mean that qemu is currently connecting to the
block backend.

> 3. "Create /etc/xen/stubdom-hvmconfig" in readme -- seems "hvmconfig" should 
> match the domain name rather than config file.

Oh indeed, here is a patch to fix that and other documentation/debugging
issues:


- Document that for vnclisten names and 127.0.0.1 should not be used.
- Documentation cosmetic fixes
- Dump qemu output to the usual logs

Signed-off-by: Samuel Thibault <samuel.thibault@eu.citrix.com>

diff -r e85399173769 stubdom/README
--- a/stubdom/README	Tue Feb 12 16:59:08 2008 +0000
+++ b/stubdom/README	Mon Feb 25 11:51:48 2008 +0000
@@ -16,10 +16,12 @@
 
 In your HVM config "hvmconfig",
 
-- use VNC, set vnclisten to "172.30.206.1" for instance:
+- use VNC, set vnclisten to "172.30.206.1" for instance.  Do not use a host name
+as Mini-OS does not have a name resolver.  Do not use 127.0.0.1 since then you
+will not be able to connect to it.
 
-vnc=1 
-vnclisten="172.30.206.1" 
+vnc = 1
+vnclisten = "172.30.206.1"
 
 - use /usr/lib/xen/bin/stubdom-dm as dm script
 
@@ -28,14 +30,15 @@
 - comment the disk statement:
 #disk = [  'file:/tmp/install.iso,hdc:cdrom,r', 'phy:/dev/sda6,hda,w', 'file:/tmp/test,hdb,r' ]
 
-Create /etc/xen/stubdom-hvmconfig ("hvmconfig" must match your main config file)
-with
+Create /etc/xen/stubdom-hvmconfig (where "hvmconfig" is your HVM guest domain
+name) with
 
-kernel="/usr/lib/xen/boot/stubdom.gz"
-vif=[ 'ip=172.30.206.1', 'ip=10.0.1.1,mac=aa:00:00:12:23:34']
+kernel = "/usr/lib/xen/boot/stubdom.gz"
+vif = [ 'ip=172.30.206.1', 'ip=10.0.1.1,mac=aa:00:00:12:23:34']
 disk = [  'file:/tmp/install.iso,hdc:cdrom,r', 'phy:/dev/sda6,hda,w', 'file:/tmp/test,hdb,r' ]
 
 where
 - 172.30.206.1 is the IP for vnc,
-- 'ip=10.0.1.1,mac=' is the same net configuration as in the hvmconfig script,
+- 'ip=10.0.1.1,mac= etc...' is the same net configuration as in the hvmconfig
+script,
 - and disk = is the same block configuration as in the hvmconfig script.
--- a/stubdom/stubdom-dm	Tue Feb 12 16:59:08 2008 +0000
+++ b/stubdom/stubdom-dm	Mon Feb 25 11:51:48 2008 +0000
@@ -62,11 +62,12 @@
 
 creation="xm create -c stubdom-$domname target=$domid memory=32"
 
-(while true ; do sleep 60 ; done) | $creation &
+(while true ; do sleep 60 ; done) | $creation > /var/log/xen/qemu-dm-$domid.log &
 #xterm -geometry +0+0 -e /bin/sh -c "$creation ; echo ; echo press ENTER to shut down ; read" &
 consolepid=$!
 
 
+# Wait for vnc server to appear
 while ! vnc_port=`xenstore-read /local/domain/$domid/console/vnc-port`
 do
         # Check that the stubdom job is still alive

Re: stubdom questions

[Zhai, Edwin]

Samuel,
Thanks for your reply.

On Mon, Feb 25, 2008 at 12:56:35PM +0100, Samuel Thibault wrote:
> Hello,
> 
> Zhai, Edwin, le Tue 19 Feb 2008 19:39:41 +0800, a écrit :
> > I have a try with HVM stubdomain on r17062, but failed to make on 32b platform.
> > Attached patch can fix it, but don't know if okay.
> 
> That is how such issues have usually been solved so I guess in principle
> it is.  Is your code coming from freebsd too?

Maybe. I copy this code from xen/common/lib.c

> 
> > After installation, I failed to start stubdom. So I created it manually
> 
> See the commented "xm create" line in the stubdom-dm script, to enable
> debugging.
> 

I have enabled this to pop up a xterm for debug, but got same result.

> > 1. I use default vnclisten. Does it matter?
> 
> Yes:
> 
> > #----------------------------------------------------------------------------
> > # address that should be listened on for the VNC server if vnc is set.
> > # default is to use 'vnc-listen' setting from /etc/xen/xend-config.sxp
> > #vnclisten="localhost"
> 
> So if your vnc-listen setting is e.g. localhost, the VNC server of the
> stubdom will be restricted to the stub domain itself, and you won't be
> able to connect.

vnclisten = "172.30.206.1""
I still have issue with the IP addr. How to select it, the dom0 ip or whatever 
in the subnet?


vif = [ 'ip=172.30.206.1', 'ip=10.0.1.1,mac=aa:00:00:12:23:34']
Does it mean the stubdom would create an extra vnif with the ip and start a VNC 
server on it? So I need ping 172.30.206.1 first to see if the vnif works?

I saw "changeset 17122 -- minios: add PVFB support". Is it a must for stubdom 
vnc?

> 
> 
> > 2. Seems qemu in stubdom has some issue and couldn't update the 'vnc-port' in 
> > xenstore.
> 
> Actually mini-os has no name resolving support so that it won't be able
> to understand the default "localhost" for vnclisten and hence not start
> VNC.
> 
> > Or the stubdom didn't run at all.
> 
> It did: messages like
> 
> ******************* BLKFRONT for /local/domain/45/device/vbd/5632 **********
> 
> come from Mini-OS and mean that qemu is currently connecting to the
> block backend.
> 
> > 3. "Create /etc/xen/stubdom-hvmconfig" in readme -- seems "hvmconfig" should 
> > match the domain name rather than config file.
> 
> Oh indeed, here is a patch to fix that and other documentation/debugging
> issues:
> 
> 

-- 
best rgds,
edwin

Re: stubdom questions

[Samuel Thibault]

Hello,

Zhai, Edwin, le Wed 27 Feb 2008 10:05:13 +0800, a écrit :
> > > After installation, I failed to start stubdom. So I created it manually
> > 
> > See the commented "xm create" line in the stubdom-dm script, to enable
> > debugging.
> > 
> 
> I have enabled this to pop up a xterm for debug, but got same result.

Well, that was expected :)
The popup of xterm is just to make it easier to get the logs.

> > > 1. I use default vnclisten. Does it matter?
> > 
> > Yes:
> > 
> > > #----------------------------------------------------------------------------
> > > # address that should be listened on for the VNC server if vnc is set.
> > > # default is to use 'vnc-listen' setting from /etc/xen/xend-config.sxp
> > > #vnclisten="localhost"
> > 
> > So if your vnc-listen setting is e.g. localhost, the VNC server of the
> > stubdom will be restricted to the stub domain itself, and you won't be
> > able to connect.
> 
> vnclisten = "172.30.206.1""
> I still have issue with the IP addr. How to select it, the dom0 ip or whatever 
> in the subnet?

That depends on your network configuration.  You need to be able to
connect to it.

> vif = [ 'ip=172.30.206.1', 'ip=10.0.1.1,mac=aa:00:00:12:23:34']
> Does it mean the stubdom would create an extra vnif with the ip and start a VNC 
> server on it?

Yes.

> So I need ping 172.30.206.1 first to see if the vnif works?

For instance yes.

> I saw "changeset 17122 -- minios: add PVFB support". Is it a must for stubdom 
> vnc?

No.

Samuel

stubdom questions

[Lu, Guanqun]

[-- Attachment #1: Type: text/plain, Size: 453 bytes --]

Hi list,

1. There's an inconsistency between the newly modified code (changeset 18226) and the stubdom README file.
Lines:
	Create /etc/xen/stubdom-hvmconfig (where "hvmconfig" is the name of your HVM
	guest) with

should be "/etc/xen/hvmconfig-dm", and of course all the occurrences should be substituted.


2. in order to boot hvm in the stubdom way, should i use dom0_mem= option in the grub or should i not?


Thanks.

--
Guanqun 

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

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

stubdom questions

[Jan Beulich]

Is it intentional that
- large parts of stubdom build with -j1 only irrespective of the original
make invocation?
- all imported packages are out of date?
- pciutils is being built without 64-bit support (visible via warnings issued
from the qemu build)?
- the build produces dozens of compiler warnings quite a few of which
don't look benign at all?
- can't be built with a read-only and/or symlinked source tree?

Also, what's the point of the install-stubdom dependency on
install-tools? Shouldn't the individual components' builds be
independent of one another?

Thanks, Jan

Re: stubdom questions

[Ian Jackson]

Jan Beulich writes ("[Xen-devel] stubdom questions"):
> Is it intentional that
> - large parts of stubdom build with -j1 only irrespective of the original
>    make invocation?

I think we had some makefile concurrency bugs and this is the workaround.

> - all imported packages are out of date?

Yes, this is intentional.  We don't want to update these unless
necessary, really.

> - pciutils is being built without 64-bit support (visible via warnings issued
>   from the qemu build)?

Does this have any other adverse consequence ?

> - the build produces dozens of compiler warnings quite a few of which
>   don't look benign at all?

No, that not intentional.

> - can't be built with a read-only and/or symlinked source tree?

No, that not intentional.

> Also, what's the point of the install-stubdom dependency on
> install-tools? Shouldn't the individual components' builds be
> independent of one another?

I don't know.  The stubdom build system is a bit of a mess,
unfortunately.

Ian.

Re: stubdom questions

[Jan Beulich]

>>> On 09.11.10 at 18:00, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote:
> Jan Beulich writes ("[Xen-devel] stubdom questions"):
>> - pciutils is being built without 64-bit support (visible via warnings issued
>>   from the qemu build)?
> 
> Does this have any other adverse consequence ?

Pass-through may not work for devices with 64-bit resources (I
don't think any virtual devices would try to use 64-bit addresses)?

Jan

Re: stubdom questions

[Stefano Stabellini]

On Tue, 9 Nov 2010, Jan Beulich wrote:
> >>> On 09.11.10 at 18:00, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote:
> > Jan Beulich writes ("[Xen-devel] stubdom questions"):
> >> - pciutils is being built without 64-bit support (visible via warnings issued
> >>   from the qemu build)?
> > 
> > Does this have any other adverse consequence ?
> 
> Pass-through may not work for devices with 64-bit resources (I
> don't think any virtual devices would try to use 64-bit addresses)?
> 

Good point.
However the current qemu-xen is incapable of dealing with 64 bit BARS
anyway AKAIK.
It could become a problem when we start using upstream qemu though.

Re: stubdom questions

[Samuel Thibault]

Jan Beulich, le Tue 09 Nov 2010 10:44:23 +0000, a écrit :
> - the build produces dozens of compiler warnings quite a few of which
> don't look benign at all?

On which parts? I guess updating them might fix these warnings, and if
not, issues should rather be reported upstream.

> - can't be built with a read-only and/or symlinked source tree?

I've never tried, actually.

> Also, what's the point of the install-stubdom dependency on
> install-tools? Shouldn't the individual components' builds be
> independent of one another?

I don't know why, but it's

changeset:   21760:84719437205c
user:        Keir Fraser <keir.fraser@citrix.com>
date:        Fri Jul 09 12:22:52 2010 +0100
summary:     Makefile: Serialise stubdom build after tools

Samuel

Re: stubdom questions

[Jan Beulich]

>>> On 09.11.10 at 21:48, Samuel Thibault <samuel.thibault@ens-lyon.org> wrote:
> Jan Beulich, le Tue 09 Nov 2010 10:44:23 +0000, a écrit :
>> - the build produces dozens of compiler warnings quite a few of which
>> don't look benign at all?
> 
> On which parts? I guess updating them might fix these warnings, and if
> not, issues should rather be reported upstream.

Some of them in qemu, many in newlib, I don't recall detail right now
for the others.

Updating is, as IanJ responded, not an option (and hence eventual
reporting upstream is also not useful from stubdom building
perspective).

Jan

Re: stubdom questions

[Jan Beulich]

>>> On 09.11.10 at 18:00, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote:
> Jan Beulich writes ("[Xen-devel] stubdom questions"):
>> - all imported packages are out of date?
> 
> Yes, this is intentional.  We don't want to update these unless
> necessary, really.

So even security problems fixed in upstream packages are deemed
to be of no concern (or if they are, need to be handled manually by
adding patches)?

> The stubdom build system is a bit of a mess, unfortunately.

Are there intentions to get this cleaned up?

Jan

Re: stubdom questions

[Gianni Tedesco]

On Wed, 2010-11-10 at 10:01 +0000, Jan Beulich wrote:
> >>> On 09.11.10 at 18:00, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote:
> > Jan Beulich writes ("[Xen-devel] stubdom questions"):
> >> - all imported packages are out of date?
> > 
> > Yes, this is intentional.  We don't want to update these unless
> > necessary, really.
> 
> So even security problems fixed in upstream packages are deemed
> to be of no concern (or if they are, need to be handled manually by
> adding patches)?
> 
> > The stubdom build system is a bit of a mess, unfortunately.
> 
> Are there intentions to get this cleaned up?

Sadly intentions are no substitute for time/manpower.

Sounds like a good idea to me though.

Gianni

Re: stubdom questions

[Ian Jackson]

Jan Beulich writes ("Re: [Xen-devel] stubdom questions"):
> On 09.11.10 at 18:00, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote:
> > Yes, this is intentional.  We don't want to update these unless
> > necessary, really.
> 
> So even security problems fixed in upstream packages are deemed
> to be of no concern (or if they are, need to be handled manually by
> adding patches)?

The libraries underlying stubdom aren't exposed directly to hostile
data; they communicate only with the qemu in stubdom, and dom0.
Communication with the untrusted guest is done by the qemu code.
Furthermore, the stubdom itself is supposed to be no more trusted than
the guest it is servicing.  So I think in theory almost all security
bugs in these libraries should be unexploitable in the stubdom
context.

If you could point to a counterexample that would be very interesting.

> > The stubdom build system is a bit of a mess, unfortunately.
> 
> Are there intentions to get this cleaned up?

In the long term yes, but I don't think we have it as a priority.

Ian.