--- Day changed

--- Log opened Wed Mar 30 23:59:02 2005
00:35  * riel starts AIM7 on a "3 CPU" xenU guest
00:37 < caker> Is it the unstable branch that has support for MP guests?
00:38 < riel> yes
00:38 < caker> wow.. What's the status?  Fairly stable at this point?
00:40 < riel> it often is
00:41 < riel> I think I ran into a little smp bug in page table handling
00:41 < riel> I'll send a patch to xen-devel tomorrow, for discussion
00:41  * riel zzzzzzz
00:41 < riel> really time to sleep now ;)
00:41 < riel> aim7 will run by itself just fine
01:23 < riel> ok, aim7 is chugging along nicely
01:23 < riel> this is pretty cool
02:24 -!- cw [cw@adsl-67-124-117-212.dsl.snfc21.pacbell.net] has quit [Ping timeout: 480 seconds]
02:28 -!- cw [cw@adsl-63-202-174-57.dsl.snfc21.pacbell.net] has joined #xen
03:09 -!- rusty [~rusty@bh02i525f01.au.ibm.com] has quit [Quit: Client exiting]
04:06 -!- LaidBack_01 [~jax@69.146.20.246] has joined #xen
04:13 -!- Beaky [~chatzilla@ncg-adsl.demon.co.uk] has joined #xen
05:08 -!- muli [~muli@alhambra.mulix.org] has quit [Ping timeout: 480 seconds]

--- Log opened Thu Mar 31 14:16:35 2005
14:32 < riel> hummm, big interdiff
14:32  * riel reads
14:32 -!- totempole [~chatzilla@lawn-199-77-210-154.lawn.gatech.edu] has joined #xen
14:33 -!- totempole [~chatzilla@lawn-199-77-210-154.lawn.gatech.edu] has quit [Quit: ]
14:33 < riel> it might be later tonight before I upgrade the xen code in rawhide ;)
14:33 < riel> almost 5000 lines of patch to go through
14:34 < riel> luckily most of it seems to be the removal of the batched pagetable updates, so that's easy
14:35 -!- niv [~niv@bi01p1.co.us.ibm.com] has joined #xen
14:37 < rocket> I am interested in getting an understanding of xen and kernel internals and things like that is there anywhere you guys suggest I start looking for information to get up to speed?
14:38 -!- caker [~caker@ns.theshore.net] has joined #xen
14:38 < hollis> rocket: have a look at the papers on the Xen website
14:39 < rocket> hollis: sounds good .. and for the kernel internals, etc? is there a good book to read? online docs?  
14:39 < riel> Understanding The Linux Kernel
14:39 < rocket> riel: I am assuming thats a book title
14:39 < riel> yeah, it is
14:40 < rocket> ok 
14:40 < rocket> sorry I am such a newbie in this area .. its just something I have always been interested in .. and need to find a place to start :p
14:46 < riel> do you know what syscalls are ?
14:46 < riel> xenolinux makes "hypercalls" into xen - very similar to syscalls
14:47 < LaidBack_01> hey, everytime I try to get xen 2.0.5 to work, my kernel hangs.
14:47 < LaidBack_01> now 2.0.4 worked fine.
14:47 < LaidBack_01> anyone else run into issues similar?
14:47 < rocket> yeah .. I have a rudimentary understanding of syscalls ..
14:47 < LaidBack_01> I've read the mailing list on this, but only one other had the problem it seemed.
14:48 < rocket> riel: "understanding the linux kernel" is kind of old is that ok?
14:48 < riel> it explains the concepts behind the code
14:48 < riel> instead of just explaining the code
14:49 < rocket> ah ok .. thats better anyway :p
14:49 < riel> if you want a nice explanation of the code, and don't need an explanation of the concepts behind it, Robert Love's book is great
14:49 < riel> but if you're new to OS hacking, you may want a book with a bit more background info
14:49 < rocket> probably want the background info .. :p
14:50 < rocket> and do these books cover the assembly parts very much? 
14:52 < riel> only a little bit, I think
14:54 < rocket> ok
14:54  * rocket is attempting to get grsecurity working with xen .. but knows at the moment I am out of my league :/
14:58 -!- greenrd [~greenrd@66-188-75-198.cpe.ga.charter.com] has quit [Read error: Operation timed out]
15:01 < riel> rocket: why?
15:01 < rocket> why am I out of my league or why am I trying to get grsecurity working? 
15:02 < riel> why are you trying to get grsecurity working ?
15:02 < riel> and, which parts ? ;)
15:02 < riel> if you get stuck on PaX, you can just take the execshield patches from fedora rawhide
15:03 < rocket> well mostly the acl's and process listing parts ..
15:03 < rocket> but I thought it would be cool to have grsecurity enabled xen kernels .. to build more secure firewall xen instances etc
15:05 < rocket> I was trying to look at the grsecurity patch and just grab the i386 arch specific stuff and apply it to the xen arch .. but there are some files missing/changed that I dont understand what I need to do .. so I know I need a better understanding of the kernel
15:05 < rocket> basically its a pet project to learn OS hacking better :)
15:06 < riel> you can do much better than that
15:06 < riel> run a bridging firewall, without any IP addresses at all
15:06 < riel> access it via the xen console
15:06 -!- greenrd [~greenrd@66-188-75-198.cpe.ga.charter.com] has joined #xen
15:07 < rocket> yeah I know I can do that .. but i was also thinking of more secure dns/web/mail server instances .. etc .. since I dont have a ton of hardware .. I like the virtualization concepts ..
15:07 < knewt> is acpi support in -unstable yet? it's that that's stopping me from putting it on my laptop
15:10 < riel> rocket: there's no security like read only filesystems, enforced by the hypervisor ;)
15:11 < riel> rocket: ideally even a kernel exploit should not compromise the virtual machine's most important things
15:11 < rocket> riel: true :)
15:13 < rocket> but when you get into needing rw filesystems etc or giving greater control .. there are some nice features in grsecurity .. and again it is a pet project .. 
15:13 < riel> it'll be a good learning experience, true
15:13 < riel> so you should probably try porting it
15:14 < jeroney> rocket: this is RBAC just use SELinux and do MAC
15:14 < jeroney> rocket: you can get the same effect
15:15 < rocket> jeroney: I dont doubt that one bit .. in fact I totally agree .. but i want to learn how to do it .. if that makes sense?
15:16 < riel> rocket: you may want to talk with some of the people on #kernelnewbies
15:16 < riel> they're doing similar projects
15:16 < jeroney> hmm...well I would say start with the books, and a couple months from now you'll be be able to just jump into it...I would start by writing an LSM for the kernel
15:16 < rocket> ok
15:17 < rocket> jeroney: sounds good
15:23 < eigood> ladbac: well, considering you haven't told us anything
15:23 -!- Surferdude [~Surferdud@pcp08365167pcs.lndsd201.pa.comcast.net] has joined #xen
15:23 < eigood> LaidBack_01: well, considering you haven't told us anything
15:24 -!- Surferdude [~Surferdud@pcp08365167pcs.lndsd201.pa.comcast.net] has left #xen []
15:24 < eigood> riel: I've got a new dbs-ng(patch management tool used by several debian packageS) that makes upgrading to new upstreams fairly easy
15:25 < eigood> it's destined to become dpkg-source v2, once I finish rewriting it from perl to c
15:25 < eigood> </pimp>
15:25 < riel> eigood: oh, applying patches isn't the problem
15:25 < riel> eigood: I just read the patch to make sure the content doesn't conflict with eg. my execshield changes
15:26 < riel> or with the page table changes introduced in 2.6.12-rc1
15:28 < eigood> I maintain separate debian patches against upstream(in debian/patches), so removing ones applied upstream is simple(in theory)
15:28 < eigood> my patch system also supports 'dependencies', which is used for ordering
15:29 < eigood> of course, I hardly ever release stuff, ...
15:31 -!- anthill333 [~larsr@palwebproxy2.core.hp.com] has joined #xen
15:33 -!- jeroney [~jeroney@pixpat.austin.ibm.com] has quit [Quit: Leaving]
15:34 -!- greenrd [~greenrd@66-188-75-198.cpe.ga.charter.com] has quit [Ping timeout: 480 seconds]
15:38 -!- greenrd [~greenrd@66-188-75-198.cpe.ga.charter.com] has joined #xen
15:46 -!- GN [~tjf@pat.foulston.com] has joined #xen
15:47 -!- GN [~tjf@pat.foulston.com] has left #xen [Leaving]
15:52 -!- Sir_Ahzz [~ahzz@c-24-0-215-3.client.comcast.net] has quit [Ping timeout: 480 seconds]
15:52 -!- Sir_Ahzz [~ahzz@c-24-0-215-3.client.comcast.net] has joined #xen
15:52 -!- mode/#xen [+o Sir_Ahzz] by ChanServ
16:00 -!- Sir_Ahzz [~ahzz@c-24-0-215-3.client.comcast.net] has quit [kinetic.oftc.net jupiter.oftc.net]
16:00 -!- hollis [~hollis@pixpat.austin.ibm.com] has quit [kinetic.oftc.net jupiter.oftc.net]
16:00 -!- muligone [~muli@192.114.107.4] has quit [kinetic.oftc.net jupiter.oftc.net]
16:00 -!- greenrd [~greenrd@66-188-75-198.cpe.ga.charter.com] has quit [kinetic.oftc.net jupiter.oftc.net]
16:00 -!- caker [~caker@ns.theshore.net] has quit [kinetic.oftc.net jupiter.oftc.net]
16:00 -!- niv [~niv@bi01p1.co.us.ibm.com] has quit [kinetic.oftc.net jupiter.oftc.net]
16:00 -!- rocket [~rocket@c-66-41-176-53.hsd1.mn.comcast.net] has quit [kinetic.oftc.net jupiter.oftc.net]
16:00 -!- Method [~Method@stanford.columbia.tresys.com] has quit [kinetic.oftc.net jupiter.oftc.net]
16:00 -!- Nigelenki [~bluefox@pcp484971pcs.whtmrs01.md.comcast.net] has quit [kinetic.oftc.net jupiter.oftc.net]
16:00 -!- Tv [~Tv@hq.inoi.fi] has quit [kinetic.oftc.net jupiter.oftc.net]
16:00 -!- cw [cw@adsl-63-202-174-57.dsl.snfc21.pacbell.net] has quit [kinetic.oftc.net jupiter.oftc.net]
16:00 -!- crisen [~crisen@spank.terdmonk.com] has quit [kinetic.oftc.net jupiter.oftc.net]
16:00 -!- mikegrb [~michael@mikegrb.netop.oftc.net] has quit [kinetic.oftc.net jupiter.oftc.net]
16:00 -!- sunny [sunny@opencurve.org] has quit [kinetic.oftc.net jupiter.oftc.net]
16:00 -!- anthill333 [~larsr@palwebproxy2.core.hp.com] has quit [kinetic.oftc.net jupiter.oftc.net]
16:00 -!- Mark [~MarkWilli@hebble.cl.cam.ac.uk] has quit [kinetic.oftc.net jupiter.oftc.net]
16:00 -!- plars [~plars@pixpat.austin.ibm.com] has quit [kinetic.oftc.net jupiter.oftc.net]
16:00 -!- knewt [~jmb@zeus.pimb.org] has quit [kinetic.oftc.net jupiter.oftc.net]
16:00 -!- aliguori [~anthony@cpe-70-112-81-91.austin.res.rr.com] has quit [kinetic.oftc.net jupiter.oftc.net]
16:00 -!- JViz [Anomaly@gso167-184-225.triad.rr.com] has quit [kinetic.oftc.net jupiter.oftc.net]
16:00 -!- jonmason [~jonmason@pixpat.austin.ibm.com] has quit [kinetic.oftc.net jupiter.oftc.net]
16:00 -!- riel [~riel@riel.netop.oftc.net] has quit [kinetic.oftc.net jupiter.oftc.net]
16:00 -!- apw [~apw@212.104.150.41] has quit [kinetic.oftc.net jupiter.oftc.net]
16:00 -!- greenrd [~greenrd@66-188-75-198.cpe.ga.charter.com] has joined #xen
16:00 -!- anthill333 [~larsr@palwebproxy2.core.hp.com] has joined #xen
16:00 -!- caker [~caker@ns.theshore.net] has joined #xen
16:00 -!- niv [~niv@bi01p1.co.us.ibm.com] has joined #xen
16:00 -!- mikegrb [~michael@mikegrb.netop.oftc.net] has joined #xen
16:00 -!- rocket [~rocket@c-66-41-176-53.hsd1.mn.comcast.net] has joined #xen
16:00 -!- Mark [~MarkWilli@hebble.cl.cam.ac.uk] has joined #xen
16:00 -!- Method [~Method@stanford.columbia.tresys.com] has joined #xen
16:00 -!- Nigelenki [~bluefox@pcp484971pcs.whtmrs01.md.comcast.net] has joined #xen
16:00 -!- plars [~plars@pixpat.austin.ibm.com] has joined #xen
16:00 -!- knewt [~jmb@zeus.pimb.org] has joined #xen
16:00 -!- Tv [~Tv@hq.inoi.fi] has joined #xen
16:00 -!- cw [cw@adsl-63-202-174-57.dsl.snfc21.pacbell.net] has joined #xen
16:00 -!- crisen [~crisen@spank.terdmonk.com] has joined #xen
16:00 -!- aliguori [~anthony@cpe-70-112-81-91.austin.res.rr.com] has joined #xen
16:00 -!- JViz [Anomaly@gso167-184-225.triad.rr.com] has joined #xen
16:00 -!- sunny [sunny@opencurve.org] has joined #xen
16:00 -!- jonmason [~jonmason@pixpat.austin.ibm.com] has joined #xen
16:00 -!- riel [~riel@riel.netop.oftc.net] has joined #xen
16:00 -!- apw [~apw@212.104.150.41] has joined #xen
16:00 -!- mode/#xen [+o riel   ] by uranium.oftc.net
16:02 -!- DEac- [~deac@xdsl-213-196-206-77.netcologne.de] has quit [Quit: Leaving]
16:02 -!- Sir_Ahzz [~ahzz@c-24-0-215-3.client.comcast.net] has joined #xen
16:02 -!- hollis [~hollis@pixpat.austin.ibm.com] has joined #xen
16:02 -!- muligone [~muli@192.114.107.4] has joined #xen
16:02 -!- mode/#xen [+o Sir_Ahzz   ] by arion.oftc.net
16:08 -!- DEac- [~deac@xdsl-81-173-139-25.netcologne.de] has joined #xen
16:19 < Mark> Sir_Ahzz: you still about?
16:19 < Sir_Ahzz> yeah
16:19 < Sir_Ahzz> just came back inside.
16:19 < Sir_Ahzz> finished repairing the chainsaw.
16:19 < Mark> That's not something you can say every day!
16:20 < Mark> (well maybe *you* can - but I can't :-)
16:21 < Sir_Ahzz> heh
16:21 < Sir_Ahzz> the stump get's it later.
16:21 < Mark> sooo, nickserv...  what exactly do I have to do?  this IRC business is somewhat new fangled and unfamiliar ;-)
16:21 < Sir_Ahzz> previous homeowners left a 5' tall stump right next to the front door. complete with moldy and peeling bark. 8-P
16:21 < Sir_Ahzz> do /msg nickserv help 
16:21 < Sir_Ahzz> it'll reply with instructions. :)
16:22 < Mark> oooh!
16:23 -!- greenrd [~greenrd@66-188-75-198.cpe.ga.charter.com] has quit [Ping timeout: 480 seconds]
16:24 -!- Mark [~MarkWilli@hebble.cl.cam.ac.uk] has left #xen [Kopete 0.9.2 : http://kopete.kde.org]
16:24 < riel> Patch #701 (linux-2.6.9-xen-compile.patch):
16:24 < riel> + patch -p1 -s
16:24 < riel> 2 out of 5 hunks FAILED -- saving rejects to file include/asm-xen/asm-i386/pgtable.h.rej
16:24 < riel> 1 out of 1 hunk FAILED -- saving rejects to file include/asm-xen/asm-i386/pgtable-2level.h.rej
16:24 < riel> 1 out of 1 hunk FAILED -- saving rejects to file arch/xen/i386/kernel/Makefile.rej
16:24 < riel> ok, close enough ;)
16:25 < Sir_Ahzz> fun. :)
16:25 -!- Mark [~MarkWilli@hebble.cl.cam.ac.uk] has joined #xen
16:25 -!- Mark [~MarkWilli@hebble.cl.cam.ac.uk] has left #xen [Kopete 0.9.2 : http://kopete.kde.org]
16:25 -!- mode/#xen [+o surriel] by riel
16:25 -!- MarkW [~MarkWilli@hebble.cl.cam.ac.uk] has joined #xen
16:25 < Sir_Ahzz> mark, problems?
16:26 < MarkW> sorted now
16:27 < Sir_Ahzz> ah
16:27 < MarkW> Should be registered with nickserv as MarkW
16:27 < Sir_Ahzz> so is it mark or markw that you registered?
16:27 < Sir_Ahzz> ok
16:27 < MarkW> there was another Mark :-(
16:27 < MarkW> now why would someone be named after me...?
16:27 < Sir_Ahzz> you'r added.
16:27 < Sir_Ahzz> should get auto-oped upon joining if you have been verified by nickserv
16:28 -!- mode/#xen [+o MarkW] by Sir_Ahzz
16:28  * MarkW feels his new superpowers appear
16:28 < riel> easily testabe with /cycle or /kick ;)
16:29 < MarkW> :-)
16:29 -!- riel was kicked from #xen by riel [test]
16:29 -!- riel [~riel@riel.netop.oftc.net] has joined #xen
16:29 < riel> mmmm nope
16:29 < Sir_Ahzz> you verified with nickserv?
16:29 < riel> yes
16:30 < Sir_Ahzz> hunh.
16:31 < Sir_Ahzz> there.
16:31 < Sir_Ahzz> fixed in the list.
16:31 < Sir_Ahzz> it lost your entry for some reason.
16:31 < Sir_Ahzz> *shrug*
16:31 -!- riel [~riel@riel.netop.oftc.net] has left #xen []
16:31 -!- riel [~riel@riel.netop.oftc.net] has joined #xen
16:31 -!- mode/#xen [+o riel] by ChanServ
16:31 < riel> ty
16:31 < Sir_Ahzz> ahh well, back to cutting this stump outa the ground. 8-P
16:32 -!- riel was kicked from #xen by riel [foo]
16:32 -!- riel [~riel@riel.netop.oftc.net] has joined #xen
16:32 -!- mode/#xen [+o riel] by ChanServ
16:32 < Sir_Ahzz> I *think* level 10 access grants chanserv admin rights, eg adding/removing users from the list.
16:32 < Sir_Ahzz> i'll figure it out later. :)
16:32  * Sir_Ahzz is gone. work to do.
16:32 -!- mode/#xen [-o riel] by ChanServ
16:32 -!- mode/#xen [+o riel] by ChanServ
16:32 < riel> cool, that works too
16:49 < knewt> Sir_Ahzz: "level #xen list" should tell you what levels are needed for different rights
16:50 < knewt> ah, no. levels, not level, on this network
16:59 -!- greenrd [~greenrd@66-188-75-198.cpe.ga.charter.com] has joined #xen
17:02 < Sir_Ahzz> bah! damn chainsaw vaporlocked on me.
17:02 < Sir_Ahzz> the thing is 12 years old at least.
17:02 < Sir_Ahzz> lots of crud in the carb I bet.
17:24 -!- mdday [~mdday@bi01p1.nc.us.ibm.com] has left #xen [/dev/stomach]
17:31 -!- Method [~Method@stanford.columbia.tresys.com] has quit [Ping timeout: 480 seconds]
17:31 < knewt> MarkW: i was looking through the current xend, and it opens /proc/xen/privcmd several times. there's no problem with actually only opening it once, right? it's just how the code has been structured?
17:33 < MarkW> right
17:33 < hollis> I think aliguori said it wasn't really being opened several times; it just looks like it
17:33 < MarkW> the only reason you open it is you can do ioctl()s on it.  as long as you have *a* file descriptor to it, it doesn't matter where you got it from
17:34 < MarkW> hollis: seems quite possible
17:34 < knewt> and if a process running as root opens /proc/xen/privcmd and then gives up root privs then everything will still work?
17:34 < hollis> something about "lazy opening"... but maybe that was vm-tools and not xend? I didn't pay attention
17:34 < knewt> hollis: i think you're thinking about vm-tools
17:34 < hollis> ok
17:34 < MarkW> hollis: that was libxen, not the current tools
17:35 < MarkW> knewt: you need to be able to mlock stuff in order to use the privcmd interface
17:35 < MarkW> no good passing stuff to Xen that's been paged out...
17:35 -!- riel is now known as unriel
17:35 < knewt> hollis: xend creates multiple instances of the python xc object with xen.lowlevel.xc.new(), each one calling xc_interface_open
17:36 < MarkW> knewt: in that case it really is opening it multiple times, i agree
17:36 < knewt> MarkW: ah, so need to keep hold of root privs then?
17:36 -!- MarkW [~MarkWilli@hebble.cl.cam.ac.uk] has quit [Remote host closed the connection]
17:36 -!- MarkW [~MarkWilli@hebble.cl.cam.ac.uk] has joined #xen
17:36 < MarkW> oops, my irc client died
17:41 -!- Method [Method@pcp0010742058pcs.howard01.md.comcast.net] has joined #xen
17:41 -!- Nigelenki [~bluefox@pcp484971pcs.whtmrs01.md.comcast.net] has quit [Read error: Connection reset by peer]
17:42 -!- Nigelenki [~bluefox@pcp484971pcs.whtmrs01.md.comcast.net] has joined #xen
17:43 < knewt> MarkW: ok, so i need mlock. is that it? if so then i can just drop all capabilities other than CAP_IPC_LOCK once i've opened /proc/xen/privcmd
17:43 < MarkW> knewt: i think that should work, yes
17:44 < knewt> since i don't need to execve at any point, so i won't fall foul of the issues with capabilities
18:07 -!- surriel is now known as riel
18:09 -!- hollis [~hollis@pixpat.austin.ibm.com] has quit [Quit: leaving]
18:10 < aliguori> knewt: an alternative approach would be using mlockall(MCL_FUTURE) and then dropping privileges
18:10 < aliguori> that should work
18:11 < aliguori> knewt: i'm not sure you're all that much better off though dropping privileges if you can write to privcmd.  You can find creative ways to map the full address space of dom0 and do whatever evil things you'd like to do
18:12 < aliguori> having access to privcmd is far more dangerous than being root.
18:14 < knewt> yeah, i guess
18:20 < eigood> nothing is more dangerous than being root
18:23 < MarkW> eigood: in dom0, i guess that's true
18:24 < MarkW> which implies that privcmd access === dom0's root === everyone else's root, after a fashion
18:24 < eigood> since root can open privcmd, being not root but having access to privcmd doesn't make you more dangerous that root
18:25 < eigood> if domU can open privcmd and access dom0's mem, then xen is broken.
18:25 < eigood> now, if the request goes to dom0, which can arbitrate it, then that's fine
18:25 < MarkW> eigood: it can't unless you make the domU privileged
18:25 < eigood> but, in all honest, domU should not be able to open control c hannels with other domains; data channels, yes, if you already have a control channel open
18:26 < MarkW> not sure what you mean there...
18:27 < eigood> dom0 sets up control channels between different domU, then those domU can communicate with each other
18:27 < eigood> think advanced cluster applications
18:27 < cw> eigood: if you root a domU and send spasticaed messages to another domain via Xen it shouldn't break things.  if it does then it's a bug and should be reported and fixed.
18:27 < eigood> I'm speaking hypothetical
18:28 < MarkW> eigood: yeah ok.  domUs can't get at each other's control channels directly, so it's ok.
18:29 < MarkW> opening inter-domU data channels will need the grant tables stuff, which is still being baked right now
18:39 < cw> probably there are ways if you try hard and long enough to break things from domU --- but as these get discovered they will be fixed over time
18:43 < MarkW> cw: there are at least 1 or 2 vulnerabilities in Xend, if you count DoS attacks from a domU
18:47 < cw> sure, and im sure given time people will fix these and/or post patches
18:47 < cw> speaking of which is there a bug-db on xensource.com ... i didnt see one but i wasn't looking either
18:48 < MarkW> yes.  the new control tools will hopefully eliminate these problems
18:48 < MarkW> i don't think the bug tracker is online yet, i'm not sure what's happening with that
18:49  * cw hopes it's not bugzilla
18:50 < eigood> the latest bugzilla has some nice features
18:50 < eigood> time tracking, better permissions/separator
19:04 -!- rharper [~rharper@pixpat.austin.ibm.com] has quit [Quit: Leaving]
19:06 -!- rocket [~rocket@c-66-41-176-53.hsd1.mn.comcast.net] has quit [Read error: Connection reset by peer]
19:07 < eigood> internal/external user support
19:12 < cw> it's just very complicated and overdesigned for some uses, whatever works though
19:15 < eigood> we haven't used the new version yet tho
19:17 < riel> I'm not aware of any nice bug tracking software
19:17 < aliguori> yeah, neither am i.  it's harder to get right than you'd think
19:19 < aliguori> it's hard to denoise a bug tracking system in open source projects too.. we get tons of duplicates in samba because users don't search for a bug before they report it
19:20 -!- hbaum [~hbaum@bi01p1.co.us.ibm.com] has quit [Quit: Client exiting]
19:23 < riel> lets just fix the bugs before users run into them ;)
19:23 < riel> or let the distributions and xensource support people keep track of bugs
19:27 < aliguori> :-)  that's fine by me
19:29 < aliguori> riel: are you guys taking xen-related bugs yet in fedora?
19:30 < aliguori> ah, quick search looks like you are :-)
19:30 < eigood> debian has been for a long time
19:32 < aliguori> debian's had good xen support.. i can't figure out what gentoo's doing about xen though.  there was a bug with an ebuild but that seems to have disappeared
19:48 -!- cw [cw@adsl-63-202-174-57.dsl.snfc21.pacbell.net] has left #xen []
19:48 -!- cw [cw@adsl-63-202-174-57.dsl.snfc21.pacbell.net] has joined #xen
20:00 -!- rusty [~rusty@bh02i525f01.au.ibm.com] has joined #xen
20:16 < riel> hey rusty
20:18 -!- rusty [~rusty@bh02i525f01.au.ibm.com] has quit [Ping timeout: 480 seconds]
20:20 < riel> mmm, I'll try that again when he rejoins
20:20 < riel> ;)
20:24 -!- cw [cw@adsl-63-202-174-57.dsl.snfc21.pacbell.net] has left #xen []
20:24 -!- cw [cw@adsl-63-202-174-57.dsl.snfc21.pacbell.net] has joined #xen
20:25 < cw> riel: do you use a registered nick with oftc? and if so do you have working access lists?
20:25 < riel> yes
20:25 < cw> hrm... buggered if i know what im doing wrong then, i have a fairly generous access list and it never recognises me
20:26 -!- mode/#xen [-o unriel] by ChanServ
20:26 -!- mode/#xen [-o riel] by riel
20:29 -!- Beirdo [~gjhurlbu@beirdo.usercloak.oftc.net] has left #xen [Leaving]
20:44 < LaidBack_01> aliguori, gentoo doesn't have a xen maintainer currently - so the project fell off the map for gentoo.
20:46  * riel upgrades rawhide's kernel to today's Xen code
20:46 < riel> (I'll commit it after I've tested it)
20:47 < cw> riel: you run aim7 nightly on smp guests?
20:47 < riel> cw: no
20:47 < riel> I need to automate my tests
20:48 < riel> but it's more important to have the packages out there, so other people can run automated tests ;)
20:50 < Method> riel: a few weeks ago the fedora kernel apparently had a newer version of xen than the xen cvs did, the xen cvs was identifying itself as version 2 but the fedora one was 3, what was the deal with that?
20:51 < riel> I track xen-unstable
20:51 -!- rusty [~rusty@bh02i525f01.au.ibm.com] has joined #xen
20:51 < riel> hi rusty
20:51 < Method> i'm pretty sure thats what cvs i had but maybe not
20:51  * riel waits for the ping timeout ;)
20:52 < riel> Method: I often package the kernel part fresh from the bitkeeper tree
20:52 < MarkW> Method: there's three bitkeeper trees, -stable, -testing, -unstable
20:52 < Method> s/cvs/bk/
20:52 < Method> yea, i had unstable
20:52 < cw> riel: have you seen the performance regression/problems others are reporting on dumU with vbd?
20:52 < Method> i was fairly confused
20:52 < riel> cw: I haven't tested
20:52 < riel> cw: but Jens Axboe's patch should help
20:52 < MarkW> -stable and -testing are the 2.0 series, -unstable is where the 3.0 series is being developed
20:52 < riel> (and is part of the code changes I want to put into rawhide tonight)
20:53 < Method> $ bk parent
20:53 < Method> Parent repository is bk://xen.bkbits.net/xeno-unstable.bk
20:53 < Method> yea.. maybe it was wierd timing
20:54 < riel> if you've seen a patch on xen-changelog, it's available on bkbits.net
20:55 < riel> (that's where I pull from for the changelog mails)
20:56 < MarkW> Method: something weird must have happened :-)
20:57 < cw> actually, sometimes i notice the parent repo changes to something inconsistent
20:58 < cw> ive had to rm and reclone, pull just barfs or finds conflicts... think that was for xen-2.0-testing.bk but not 100% sure
20:58 < MarkW> cw: could be a bitkeeper bug i guess
20:59 < MarkW> i have (very occasionally) wedged my repo into states that confuse BK
21:14 < cw> MarkW: looks more like the parent was recreated / resynced from somewhere else
21:14 < cw> MarkW: 'bk changes -L' would show i had things the parent didn't --- yet i never made those changes
21:14 < MarkW> ooh, that's a bit weird
21:14 < riel> indeed, Ian did a 'bk undo' once
21:14 < riel> by accident
21:14 < cw> MarkW: maybe the parent has undo's done at times? that would explain it
21:14 < MarkW> the parent being at bkbits?
21:14 < cw> yeah, that's would bo it
21:14 < cw> do it
21:15 < cw> bk cset -x, not undo :)
21:15 < cw> MarkW: yeah, bk://xen.bkbits.net/xeno-unstable.bk or similar... i forget now
21:15 < MarkW> ok
21:15  * MarkW has one more bug to squash before sleep
21:16 < riel> cw: exactly
21:18 < MarkW> is there actually anyone else here on London time?
21:18 < MarkW> (just curious)
21:20 < riel> not this week ;)
21:20 < MarkW> right :-) where are you based usually / on average / nominally (delete as appropriate)?
21:24 -!- Gollum [~gollum@pcp01411681pcs.phnixv01.pa.comcast.net] has joined #xen
21:41 < niv> MarkW: whom are you asking? riel? (EST?). Some of us are in Oregon (PST) where it is now 6:41PM
21:42 < MarkW> anyone and everyone :-)  just curious....  on british summer time (where I am) it's 3.42am
21:43 < niv> MarkW: they're working you much too hard up there, laddie ;)
21:43 < MarkW> of course I actually have my own personal timezone, so it's not as bad as it sounds ;-)
21:43 -!- Gollum [~gollum@pcp01411681pcs.phnixv01.pa.comcast.net] has quit [Read error: Operation timed out]
21:44 < MarkW> niv: i have one more bug that i'm determined to squash tonight...  it's really bugging me!
21:44 < niv> always handy, yer own time and space :)
21:44 < niv> me too
21:44 < niv> what are you working on?
21:44 < MarkW> I'm hacking on XenFS most of the time now
21:45 < niv> ah
21:45 < niv> how's that coming along? 
21:45 < MarkW> (for those who haven't heard of it XenFS is a bit like NFS but exploiting all all the servers / clients being able to share memory directly)
21:46 < MarkW> it's coming along OK now I'm concentrating on it
21:46 < aliguori> MarkW: is a copy available yet? :-) I'm very anxious to see it
21:46 < MarkW> aliguori: it's not ready for other people to look at the code yet - might make them queasy
21:46 < aliguori> heh, i hope it's not too much like NFS :-)
21:46 < MarkW> aliguori: so do I :-D
21:47 < MarkW> i'll make some code available as soon as it's reasonably sane.
21:47 < MarkW> the really interesting stuff is the optimisations i can do later on, however...
21:47 < aliguori> is it a point-to-point file system or can it be shared between 2 or more domains?
21:48 < niv> the world is very short of a good network file system. Xen lends itself to a lot more exploitation and gain here - should be really interesting
21:48 < MarkW> aliguori: the sharing is where things get rather interesting
21:48 < aliguori> niv: yup, it's becomes particularly interesting when you try to match the semantics of multiple platforms
21:48 < aliguori> MarkW: that's what I figured :-)
21:48 < MarkW> things I may look at:
21:49 < MarkW> providing CoW functionality in the server to minimise disk usage
21:50 < MarkW> sharing common memory pages between domains to minimise IO / save memory
21:50 < MarkW> write sharing (i'd like to do this by direct memory sharing but i don't know if that's sane yet)
21:51 < MarkW> but first I have to make the basics sane :-D
21:51 < aliguori> CoW at what level?  on a per-block basis or per-inode?
21:51 < MarkW> per inode
21:51 < aliguori> we've been looking at unionfs.. even though it's file-level CoW it's quite useful in a virtualized environment
21:52 < MarkW> we had an NFS server that did CoW at filesystem level but that didn't perform well...
21:52 < MarkW> aliguori: yes that would do the job nicely - whose implementation are you using?
21:52 < aliguori> the FiST one.
21:53 < aliguori> http://www.fsl.cs.sunysb.edu/project-unionfs.html
21:53 < MarkW> ah, ok
21:53 < aliguori> it's quite neat in with xen because you can just share a common read-only device and give each domain a small rw device for CoW
21:53 < niv> aliguori: thanks for the url
21:54 < niv> what are you using it for?
21:54 < aliguori> the only real performance problem i can think of is reading a directory (because unionfs has to merge two directories--if there's a ton of files in both directories it could be expensive)
21:55 < aliguori> niv: we've been looking at it for our ols proposal
21:55 < niv> are you going to present that at ols?
21:55 < aliguori> niv: i've gotta give credit to rharper, i had given up on it but he showed me that i was just being a stupid user :-)
21:56 < aliguori> niv: i don't know.  we're looking at a lot of things right now
21:56 < aliguori> the problem with unionfs is that it's not really practical.  the code base won't likely make it into the kernel
21:56 < aliguori> the FiST stuff is too clunky
21:57 < niv> aliguori: what else is there on the horizon in this space, though, that you know of?
21:57 < aliguori> niv: well, i've got a personal bias to content-addressable solutions like Venti
21:57 < aliguori> :-)
21:58 < aliguori> there was an old linux CoW filesystem called IFS that eventually was removed from the kernel for lack of maintainership
21:58 < aliguori> sun has one (tranparent file system or something like that i believe)
21:59 < niv> nothing that seems to have really gotten mindshare
21:59 < aliguori> translucent, sorry
21:59 < aliguori> not that i know of.  i think TFS is perhaps the most well known
22:00 < aliguori> unless you of course count the copy-on-write features in CIFS :-)
22:01 < riel> MarkW: I'm in Nashua, NH, US - it's 22:02 here
22:01 < riel> (and the kernel RPM compile seems to have finished - testing time in a bit)
22:02 < aliguori> man, i guess i'm the only one in CST.. there normally are a bunch of texas folks here though :-)
22:02 < niv> is SMP compile broken? there were rumors to that effect here which I wasn't paying close attention to
22:03 -!- Nigelenki [~bluefox@pcp484971pcs.whtmrs01.md.comcast.net] has quit [Read error: Connection reset by peer]
22:03 < niv> aliguori: ah, CST, where it's neither too late nor too early :)
22:04 < riel> Subject: [Xen-changelog] Fix queue unplugging in blkback driver.
22:04 < riel> oh great
22:04 < riel> I thought that one was committed way earlier today
22:04 < aliguori> time to rebuild kernel rpms :-)
22:04 < riel> Subject: [Xen-changelog] Patch from Jens Axboe to synchronously flush block
22:04 < riel> oh n/m, it was
22:08 < riel> two patches in the same area
22:10 < riel> if this stuff breaks, I'll try again tomorrow morning ;)
22:10 < riel> with newer code
22:13 < niv> riel: i  think you have everything so far, this might work
22:13 < riel> I only have the second one - not the first one
22:15 < riel> ok, looks like I need a newer xen, too
22:16 < riel> NET: Registered protocol family 17
22:16 < riel> inst3: 0000 [#1]
22:16 < riel> SMP end_stop disable_local_APIC
22:16 < riel> (XEN)
22:16 < riel>       Domain 0 shutdown: rebooting machine.
22:16 < riel> this is annoying too
22:17 < riel> ok, I'll look at this tomorrow
22:17 < riel> enough for today
22:18  * niv is going to get some dinner..
22:18 -!- niv [~niv@bi01p1.co.us.ibm.com] has quit [Quit: ChatZilla 0.9.61 [Mozilla rv:1.7.5/20041217]]
22:18  * MarkW has conquered another xenfs bug
22:19 < MarkW> time for bed :-)
22:19 -!- Nigelenki [~bluefox@pcp484971pcs.whtmrs01.md.comcast.net] has joined #xen
22:19 -!- MarkW [~MarkWilli@hebble.cl.cam.ac.uk] has quit [Quit: Kopete 0.9.2 : http://kopete.kde.org]
22:37 < riel> ok cool, the kernel boots with a new xen
22:45  * riel pushes both xen and the new kernel into the build system
22:47 < schweeb> riel: which version of python are you using with the userspace stuff?
22:47 < riel> oh crud !
22:47 < schweeb> we've had a couple problems with 2.4 on ubuntu
22:47 < riel> Call Trace:
22:47 < riel>  [<c025638a>] blk_run_queue+0x1a/0x50
22:47 < riel>  [<c0265744>] blkio_schedule+0x134/0x160
22:47 < riel>  [<c011a730>] default_wake_function+0x0/0x20
22:47 < riel>  [<c0265610>] blkio_schedule+0x0/0x160
22:47 < riel>  [<c01080cd>] kernel_thread_helper+0x5/0x18
22:47 < riel> shit
22:47 < schweeb> heh
22:47 < riel> so I do need both patches
22:54 < rusty> Hi Rik!
22:56 -!- jeroney [~jeroney@rrcs-24-173-250-83.sw.biz.rr.com] has joined #xen
22:59 < riel> rusty: time to put the latest (and greatest?) xen code in rawhide ;)
22:59  * riel just pulled and fixed up linux-2.6.11-xen.patch
23:00 < rusty> riel: cool.
23:02 < riel> (for the second time today)
23:02 < riel> the code I had yesterday was stable
23:02 < riel> it survived an overnight aim7 run, on a xenU guest with 3 cpus
23:22 < jeroney> riel: good to see xen back in rawhide :-)
23:23 < riel> yeah
--- Log closed Thu Mar 31 23:59:00 2005