--- Day changed

--- Log opened Tue May 17 23:59:03 2005
00:13 -!- b2s [~b2s@66.111.53.150] has quit [Ping timeout: 480 seconds]
00:14 -!- b2s [~b2s@66.111.53.150] has joined #xen
01:16 -!- DEac- [~deac@xdsl-213-196-201-68.netcologne.de] has joined #xen
02:02 -!- Squink [~purple@S010600131077a67e.vc.shawcable.net] has quit [Ping timeout: 480 seconds]
02:08 -!- yarihm [~yarihm@217-162-112-86.dclient.hispeed.ch] has quit [Quit: Leaving]
02:49 -!- rusty [~rusty@bh02i525f01.au.ibm.com] has quit [Quit: Client exiting]
03:42 -!- muli [~muli@pat.zurich.ibm.com] has joined #xen
04:04 -!- nub2 [~nub2@lez.mag.keio.ac.jp] has quit [Remote host closed the connection]
04:25 -!- cfreak [cfreak@dsl-084-056-106-011.arcor-ip.net] has joined #xen
04:30 -!- lilo [debian-tor@lilo.usercloak.oftc.net] has quit [Remote host closed the connection]
04:32 -!- lilo [~lilo@lilo.usercloak.oftc.net] has joined #xen
05:01 -!- cfreak [cfreak@dsl-084-056-106-011.arcor-ip.net] has quit [Quit: .]
05:05 -!- athomas [~athomas@ppp-0-81.lond-b-2.access.uk.tiscali.com] has joined #xen
05:36 -!- muli [~muli@pat.zurich.ibm.com] has quit [Read error: Operation timed out]
05:38 -!- muli [~muli@pat.zurich.ibm.com] has joined #xen
06:19 -!- tim [~tim@cpe-66-67-139-238.rochester.res.rr.com] has joined #xen
08:32 -!- cc [~cc2@c210-49-121-44.eburwd3.vic.optusnet.com.au] has quit [Quit: Leaving]
08:33 -!- drbyte [~cc2@c210-49-121-44.eburwd3.vic.optusnet.com.au] has joined #xen
08:53 < tessier> tim: Do you have any idea when those chips that support virtualization will be coming out?
08:56 -!- cfreak [cfreak@dsl-084-056-106-011.arcor-ip.net] has joined #xen
09:25 -!- MarkWilliamson [~MarkWilli@maw48.kings.cam.ac.uk] has joined #xen
09:31 -!- unriel is now known as riel
09:38 -!- hollis [~hollis@user-0vvde2g.cable.mindspring.com] has joined #xen
10:08 -!- rharper [~rharper@pixpat.austin.ibm.com] has joined #xen
10:18 -!- athomas [~athomas@ppp-0-81.lond-b-2.access.uk.tiscali.com] has quit [Quit: Leaving]
10:41 -!- aliguori [~anthony@cpe-70-112-81-91.austin.res.rr.com] has joined #xen
10:42 -!- athomas [~athomas@ppp-0-39.lond-b-2.access.uk.tiscali.com] has joined #xen
11:00 -!- hollis [~hollis@user-0vvde2g.cable.mindspring.com] has quit [Quit: leaving]
11:05 -!- Tv [~Tv@hq.inoi.fi] has joined #xen
11:07 < Tv> Hi guys. Any news on USB support?
11:08 < Tv> or, alternatively, a way to pass a serial port from dom0 to domU with a system similar to disk and network drivers?
11:27 < hebutterworth> I'm working on 2.6 USB support right now.  Still a few weeks off I think.
11:30 -!- hollis [~hollis@pixpat.austin.ibm.com] has joined #xen
11:44 < aliguori> hebutterworth: are you still working on -unstable or have you moved over to mike wray's tree?
11:44 < aliguori> the xend code is much better in mike wray's tree...
11:45 < hebutterworth> I'm working on a snapshot of unstable from a month or so ago.
11:45 < hebutterworth> I've finished the usb specific xend bits that I needed.
11:45 < hebutterworth> I'm back working on the USB coe.
11:45 < hebutterworth> code.
11:46 -!- tim [~tim@cpe-66-67-139-238.rochester.res.rr.com] has quit [Ping timeout: 480 seconds]
11:46 < hebutterworth> I'll have to do the xend bits again when I switch to the new xend.
11:47 < hebutterworth> But I'm putting that off until I've got the USB bits working.
11:57 -!- cfreak [cfreak@dsl-084-056-106-011.arcor-ip.net] has quit [Quit: .]
12:01 -!- aliguori [~anthony@cpe-70-112-81-91.austin.res.rr.com] has quit [Quit: Leaving]
12:03 -!- stekloff [~stekloff@bi01p1.co.us.ibm.com] has joined #xen
12:14 -!- tim [~tim@cpe-66-67-139-238.rochester.res.rr.com] has joined #xen
12:16 -!- muli [~muli@pat.zurich.ibm.com] has quit [Quit: BitchX Official FTP Site -- ftp://ftp.bitchx.com]
12:16 -!- aliguori [~anthony@pixpat.austin.ibm.com] has joined #xen
12:53 -!- mccabemt [~mike@ny-lackawannacadent4-1c-a-144.buf.adelphia.net] has joined #xen
13:14 -!- sleon [sleon@e180000006.adsl.alicedsl.de] has joined #xen
13:14 < sleon> is it possible from childdomains to get access to xen?
13:15 < riel> dom0 is a child domain ;)
13:15 < riel> I assume it should be possible to have multiple such domains, if you try hard enough
13:15 < sleon> i mean
13:16 < sleon> i have 3 domains
13:16 < sleon> one is dom0
13:16 < sleon> is it possible from childdomains to give commands to xen to spawn new domains?
13:16 < sleon> or to kill domains?
13:16 < sleon> or for example i have one domain, that is router
13:16 < sleon> accessable from evryone
13:17 < sleon> and then second is fileserver
13:17 < sleon> that should be very secure
13:17 < sleon> and accessable only from internal network
13:17 < demon> no, not presently
13:17 < demon> afaik
13:17 < sleon> can someone hack my router and then get access to the fileserver?
13:17 < riel> indeed, you'll probably have to ask the shype people about that
13:17 < sleon> shype`??
13:17 < demon> dom0 is, at least currently, the only domain that's blessed to tell the hypervisor what to do
13:18 < riel> oh, you want to ensure the child domains do NOT get access to xen?  that works already by default ;)
13:18 < sleon> but do other domains have possibility of direct access to other domains?
13:18 < riel> no, unprivileged domains have no such access
13:18 < sleon> yes that is what i wnat
13:18 < demon> if they can, it's a bug
13:18 < demon> but they shouldn't be able to
13:19  * riel prepares for ... pain
13:19 < riel> time to try upgrading to the current -unstable snapshot
13:20 -!- athomas [~athomas@ppp-0-39.lond-b-2.access.uk.tiscali.com] has quit [Quit: Leaving]
13:20 < riel> just in time for the FC4 freeze
13:21 -!- cfreak [cfreak@dsl-084-056-106-011.arcor-ip.net] has joined #xen
13:26 < MarkWilliamson> Tv: A backend / frontend for plain RS232 serial ports wouldn't be too hard
13:26 < MarkWilliamson> But I doubt anyone will want to implement it ;-)
13:30 < sleon> is it possible to eport a file on a filesystem as a harddrive for a domain?
13:30 < sleon> ioctl 00005331 not supported by Xen blkdev
13:30 < sleon> i get this when i try to do it
13:35 < Tv> MarkWilliamson: *nod*
13:36 < Tv> I could hack it myself, but I think I'd rather help with the USB thing.
13:36  * Tv misses the concept of free time.
13:36 < MarkWilliamson> You could probably write the backend for an RS232 split driver to run as a userspace daemon, rather than hacking dom0's kernel.
13:37 < MarkWilliamson> But the USB stuff will be more useful for most people (and you could always plug in a USB-RS232 adaptor ;-)
13:39 < tim> tessier, first quarter of 2006 for AMD, and supposedly in a couple months for Intel
13:39 < tessier> tim: Wow. Awesome. Can't wait to be able to run a Windows domain next to my Linux domains.
13:40 < tim> you said it :)
13:40  * tessier wonders if MS will find a way to break it
13:40 < tim> don't think thats possible...its hardware
13:40 < tim> but if anyone can do it....its M$
13:41 < tessier> My thoughts exactly. I don't see how but...
13:41 < tim> this is probably a stupid question, idk anything about virtualization, why would software like xen want USB support?
13:42 < MarkWilliamson> tim: same reason vmware supports it
13:42 < MarkWilliamson> it's just useful to be able to plug in a device and give it to a virtual machine
13:43 -!- soffi [~soffi@Tolvudeild-SC-gw.vv.simnet.is] has quit [Quit: Leaving]
13:43 < tessier> FC4 is gonna have xen build in...looking forward to that.
13:43 < MarkWilliamson> sometimes because you want to transfer stuff from (e.g.) a usb hard disk to the guest domain
13:43 < tim> oh, gotcha
13:43 < MarkWilliamson> or (when windows support appears) because the guest actually supports more devices than the host :-)
13:43 < tessier> I'm not in xen at the moment because I need support for encrypted filesystems on loopback which the xen binaries didn't come with and I haven't gotten around to recompiling yet.
13:43 < tim> i was under the impression that if it worked in the host domain it'd work in the guest domain....like i said, i know nothing about virtualization
13:45 < MarkWilliamson> tim: sure.  but what if you're using a random ill-supported device (such as a USB Feather Duster) that only comes with Windows drivers
13:45 < tim> hrmmm
13:45 < MarkWilliamson> The host can't support it if it's runnintg Linux.  But you can fire up a Windows XP guest and give it the device
13:45 < tim> ...i want a USB feather duster
13:46 < MarkWilliamson> And the Guest will no what to do with it, even though the host doesn't have drivers
13:46 < tim> yes, that makes sense now, i was just not thinking
13:46 < MarkWilliamson> So you can still use it :-)  (doesn't everyone want a Usb feather duster!)
13:46 < tim> lol :)
13:48 < MarkWilliamson> hmmmmm.  /me imagines Xen running on a palmtop
13:48 < Tv> tim: my use case: allow domU to use a device connected to serial port
13:49 < riel> 86 files changed, 7950 insertions(+), 999 deletions(-)
13:49 < riel> ok, not too bad
13:49  * riel reads
13:49 < tim> Tv, domU?
13:50 < MarkWilliamson> tim: domU == guest
13:51 < Tv> "domain, unpriviledged"
13:51 < Tv> as opposed to "dom0" == "domain, first one"
13:51 < tim> ah gotcha
13:54 < tim> ok here comes stupid question number 2 from me....well 3 actually
13:54 < mccabemt> Is there a procedure you're supposed to follow for submitting patches other than sending them to the mailing list and possibly bugzilla?
13:54 < hollis> mccabemt: nope, just the mailing list
13:55 < hollis> mccabemt: along with Signed-off-by line, which I always forget
13:55 < MarkWilliamson> mccabemt: send them to the mailing list.  We use the Linux kernel "Signed-off-by: <email>"
13:55 < MarkWilliamson> which is a certification of various legal stuff (it's your code, or code you're allowed to contribute, you're not doing anything naughty, etc :-))
13:56 < mccabemt> thanks, I'll resubmit that basic memory one then
13:56 < tim> I read an article (how i found out about xen) saying you could have several virtual partitions on ur HD that do several different things. The one that attracted me was that you could have like a TV partition that would be a small amount of code and therefore start up almost instantainously after you boot ur computer......with the new virtualization chips from Intel and AMD will things like this be possible or are they still a couple years of
13:56 < tim> f?
13:56 < tim> wow....2 characters past the limit apparently :P
13:56 < tessier> tim: I asked that question myself just a while ago...
13:56 < tessier> tim tessier, first quarter of 2006 for AMD, and supposedly in a couple months for Intel
13:57 < Tv> tim: That concept doesn't really seem to have anything to do with xen, really.
13:57 < tim> oops, sry
13:57 < Tv> tim: many of my computers have two installs of linux; one is for normal use and one is a minimal 300MB install for disaster recovery
13:57 < MarkWilliamson> Tv: tim: no, that article was about Xen but the concept would work with any VMM if it got popular enough 
13:58 < MarkWilliamson> I think it was XenSource's VP of marketing talking about how great the world will be because of Xen, no?
13:58 < Tv> I mean, if you are _booting_ the machine, and want it to _just_ display television, where's the V in that?
13:59 < tim> yea i believe it was XenSources VP
13:59 < Tv> Or do you mean applications-as-operating-systems in separate guests?
13:59 < tim> Tv, that was more a proof of concept type thing I believe, it basically said that the OS would lose significance and become more or less just a platform to run applications
14:00 < tim> yes applications-as-operating-systems in seperate guests...exactly
14:00 < MarkWilliamson> Tv: that's the idea.  basically he was saying you could have an "appliance VM" that did TV.  That'd boot up quick whilst your general purpose OS could boot in the background
14:00 < tim> so is that "possible" now, its just a matter of making these "application OS's?"
14:00 < Tv> tim: yes
14:00 < tim> thats so freakin cool
14:00 < Tv> also their cooperation is still sucky
14:01 < tim> whose cooperation?
14:01 < Tv> main OS & the rest
14:01 < Tv> e.g. showing stuff on screen
14:01 < tim> ah
14:02 < tim> this is some awesome stuff you guys are working on....keep it up!
14:03 -!- DEac- [~deac@xdsl-213-196-201-68.netcologne.de] has quit [Read error: Operation timed out]
14:06 -!- Rai [~blah@pcp742261pcs.reston01.va.comcast.net] has joined #xen
14:10 < Rai> Greets, all.  I'll cut to the chase as best I can: I want to build a stable/testing Xen rpm for RHEL4 using the FC4 .src.rpm as a template (which is unbuildable today for Xen), but I'm not sure how to go from Xen-release .tar.gz to monolithic patchfile to be applied during RH's rpmbuild source-patch stage.
14:10 < Rai> Sure I watched Xen patch the pristine-kernel and merge the sparse stuff in, but when I try to make a patch directly from pristine -> ref and try using that with some .spec file tweaking, many, many other patches fail and lots of messiness ensues (ie, failed build).
14:10 < Rai> If someone can say how the FC4 xen patch was done so it can be reverted to a 'more stable' Xen release, I'd love a hint.
14:12 < aliguori> Rai: reil would be the guy to ask on that one since he made the rpms
14:12 < aliguori> er, riel
14:12 < Rai> aliguori: Thanks, I'll wait around.  :)
14:12 < aliguori> the ie thing always kills me :-)
14:12 < MarkWilliamson> aliguori: perhaps we should change his name to r.*l
14:13 < Rai> :D
14:13 < aliguori> MarkWilliamson: I think we should at least have riel and keir agree on a common spelling :-)
14:13 < aliguori> that would make things much eaiser
14:13 < MarkWilliamson> aliguori: Yes, I think that's only fair!
14:13 < tim> lol
14:13 < aliguori> absolutely :-)
14:13 < rharper> haha
14:14 < MarkWilliamson> we could prepare patches for their home pages.  don't forget the signed-off-by
14:14 < MarkWilliamson> *shrugs* or just file a bugzilla and hope they sort it out themselves!
14:15 < aliguori> bugzilla's starting to get a healthy number of open bugs in it..
14:15 < aliguori> they might not notice for a while :_0
14:16 < MarkWilliamson> Yeah, it's been very handy having the bugzilla, I think
14:17 < aliguori> MarkWilliamson: are you still working on XenFS?
14:17 -!- DEac- [~deac@xdsl-213-196-206-5.netcologne.de] has joined #xen
14:17 < MarkWilliamson> aliguori: yes but right now I'm not actually hacking on it, having gone off on a number of tangents!
14:17 < aliguori> MarkWilliamson: and do you when 3.0-testing is going to split?
14:17 < tim> XenFS = Xen file system?
14:17 < aliguori> mmm, tangents
14:18 < MarkWilliamson> tim: yup
14:18 < MarkWilliamson> aliguori: the most significant of which is an implementation of kexec
14:18 < aliguori> MarkWilliamson: kexec what to what?  linux to xen? xen to xen?
14:18 < aliguori> or either :-)
14:18 -!- mccabemt [~mike@ny-lackawannacadent4-1c-a-144.buf.adelphia.net] has quit [Read error: Operation timed out]
14:19 < MarkWilliamson> aliguori: Xen guest to another Xen guest
14:19 < MarkWilliamson> I think one day we'll want a kexec implementation in Xen itself...  But I don't have time to do that right now.
14:20 < aliguori> MarkWilliamson: oh.. how does that work?  is it just domU linux kexec()'ing another domU linux?  or is this a full reboot into a different guest image?
14:20 < aliguori> MarkWilliamson: I imagine this is for a domU bootloader right?
14:20 < MarkWilliamson> aliguori: I thought about doing in all within the guest
14:21 < MarkWilliamson> But it's a waste of time because it'd duplicate a load of code that's already in the domain builder.  It's sufficent to develop a sensible means of the guest passing out a new kernel to start
14:22 < MarkWilliamson> To start with, Xend will destroy the old guest and build a new one with the new kernel.  Later one, I'd like to eliminate the need to destroy the domain, so that people can use it for guest KDump.
14:22 < MarkWilliamson> And yes, it's for domain bootloaders for now :-)
14:23 < aliguori> MarkWilliamson: ah, so is this all occuring over the control channel?
14:24 < MarkWilliamson> aliguori: not exactly.  the guest builds a structure i call a "kexeclist", which specifies the machine pages where the new kernel is to be found
14:24 < MarkWilliamson> Xend can then grab these directly from the domain's memory.  It maps nicely onto the way the generic kexec code works.
14:25 < aliguori> MarkWilliamson: so then did you add a new SHUTDOWN_KEXEC reason or something?  How does Xend know when to look for this kexeclist?
14:25 < MarkWilliamson> aliguori: yup.  that message just has cmdline length, kernel length and initrdlen, plus the machine address of the kexeclist
14:26 < aliguori> ah
14:26 < aliguori> MarkWilliamson: reconnecting the devices is going to be a little odd.. especially with a network device like iSCSI
14:26 < riel> Rai: feel free to ask me any questions about the FC4 xen kernels
14:27 < tim> is Xen going to be installed standard with FC4?
14:27 < MarkWilliamson> aliguori: to start with, the new kernel will be in a new domain image, so devices will just reconnect
14:27 -!- sleon [sleon@e180000006.adsl.alicedsl.de] has quit [Ping timeout: 480 seconds]
14:27 < MarkWilliamson> aliguori: to boot in the same domain image, for kdump, i'll need to disconnect the existing devices first
14:28 < riel> tim: not in the default install, but the RPMs are available
14:28 < riel> tim: just "yum install xen kernel-xen0" and you're set
14:29 < aliguori> MarkWilliamson: I imagine it may be possible to have the original kernel simply not issue DRIVER_STATUS messages which means that you would only have to recreate the backends
14:29 < aliguori> MarkWilliamson: oh wait, nm, you need to access the devices to read the kernel from :-)
14:30 < MarkWilliamson> aliguori: yeah :-) and in the more general case, users might want to kexec at any time
14:31 < aliguori> MarkWilliamson: sure.  it may prove interesting to reuse the kexec code to kexec into another domain (so domU's can launch other domU's)
14:32 < MarkWilliamson> aliguori: e.g. have a partition on the virtual disk with a different distro installed and be able to jump into that?
14:32 < aliguori> MarkWilliamson: yup
14:33 < aliguori> MarkWilliamson: it would be interesting to have a hierarchical domain model (as opposed to the linear one we have now) especially for resource allocation
14:33 < MarkWilliamson> aliguori: yes, i think that's planned eventually
14:33 -!- mccabemt [~mike@ny-lackawannacadent1a-lac-b-200.buf.adelphia.net] has joined #xen
14:34 < MarkWilliamson> it's just time consuming to implement, so nobody has done it yet
14:34 < aliguori> yeah, I think some of the fundamentals would have to be rethought..  there's always 4.0 or 5.0 though :-)
14:34 < riel> aliguori,MarkW: I'm not even sure it needs to be implemented, vs. emulated using XenSE security rules
14:35 < MarkWilliamson> riel: yeah, that could be quite a neat way of doing it
14:35 < aliguori> riel: i hope XenSE doesn't become too much like SELinux.. SELinux policies are scary
14:36 < riel> aliguori: the number of things xen can do is much smaller, so the rules should be simpler
14:36 < MarkWilliamson> heh, the original draft called it SEXen instead of XenSE
14:36 < hollis> heh
14:36 < aliguori> is there a paper? about XenSE?
14:36 < hollis> who could vote against a name like that??
14:36 < riel> the security enhanced X people have similar naming issues
14:36 < MarkWilliamson> they realised it was a bad idea when it got dropped by a research council's spam filter :-)
14:37 < riel> especially since they're an NSA sponsored/run project
14:37 < MarkWilliamson> aliguori: it was a funding application, not publically available
14:37 < riel> SE-X
14:37 < rharper> hollis: =)
14:37 < rharper> stupid filters
14:38 < aliguori> nice
14:38 < hollis> what is security-enhanced X?
14:39 < MarkWilliamson> I think it was the mandatory access control for window interactions
14:39 < riel> hollis: security extensions that would allow you to show windows from multiple security levels simultaneously, have a trusted path, etc...
14:39 < MarkWilliamson> Security labels on window contents, clipboard, etc
14:39 < riel> it needs to do things like prevent the user from cut'n'pasting from a top secret document into an unclassified document
14:39 < hollis> huh
14:39 < aliguori> huh
14:39 < rharper> where does Xen and Window contents intersect ?
14:40 < hollis> rharper: only the name
14:40 < riel> and prevent an unclassified application from showing a "password:" window and snoop the user's top secret clearance password, etc...
14:40 < aliguori> yeah, that makes sense.. b/c we used to have to separate machines for the different networks to specifically prevent that
14:40 < riel> rharper: SEX vs. SEXen ;)
14:40 < rharper> riel: haha
14:40 < riel> obviously the Xen project is cooler
14:41 < riel> oh, and Xen could be used as part of a MILS system
14:41 < riel> (multiple independant levels of security)
14:41 < rharper> sorry, I missed the the part about X-windows ... was still thinking SE Linux stuff 
14:41 < riel> by running separate virtual machines at different security levels, like vmware's nettop project
14:50 < MarkWilliamson> riel: that was one of the original motivators for XenSE
15:19 -!- aliguori [~anthony@pixpat.austin.ibm.com] has quit [Quit: Leaving]
15:27 -!- aliguori [~anthony@pixpat.austin.ibm.com] has joined #xen
15:28 -!- tierra [~tierra@dsl093-225-126.slc1.dsl.speakeasy.net] has joined #xen
15:43 < jonmason> is there a simple way to determine what protocol (TCP/UDP) is encapsulated in IPv6?
15:45 < grifferz> tcpdump?
15:46 < jonmason> I wish
15:46 < jonmason> I mean from the packet
15:47 < hollis> I think tcpdump can operate on binary files you've saved off
15:47 < jonmason> the ofset for the tcp/udp checksum is different
15:47 < jonmason> hollis: I am talking about in the TCP stack
15:47 < hollis> oh :)
15:47 -!- tierra [~tierra@dsl093-225-126.slc1.dsl.speakeasy.net] has quit [Ping timeout: 480 seconds]
15:47 < jonmason> hollis: but you are correct, tcpdump will do that
15:49 -!- tim [~tim@cpe-66-67-139-238.rochester.res.rr.com] has quit [Ping timeout: 480 seconds]
15:50 < jonmason> ipv4 has the protocol field, which specifies TCP, UDP, etc.  
15:50 < jonmason> there is no such field in the ipv6 header
15:54  * murble finds potnetial lvm/dm breakage in domain0 :(
16:14  * riel decides to not enable HOTPLUG_CPU after seeing that it doesn't cleanly build ;)
16:17 < rharper> riel: you have the output of that? I'll clean that up if I can
16:21 < riel> rharper: the output has scrolled away, basically the cpu_state per-cpu variable isn't declared in one of the files using it
16:21 < riel> not declared in arch/xen/i386/kernel/process.c, should probably be an extern in some include file
16:21 < riel> <flood/>
16:21 < riel> arch/xen/i386/kernel/built-in.o(.init.text+0x44e1): In function `acpi_parse_fadt':
16:21 < riel> arch/xen/i386/kernel/acpi/boot.c:617: undefined reference to `pmtmr_ioport'
16:21 < riel> arch/xen/i386/kernel/built-in.o(.init.text+0x44e6):arch/xen/i386/kernel/acpi/boot.c:619: undefined reference to `pmtmr_ioport'
16:21 < riel> arch/xen/i386/kernel/built-in.o(.init.text+0x451a):arch/xen/i386/kernel/acpi/boot.c:614: undefined reference to `pmtmr_ioport'
16:21 < riel> arch/xen/i386/kernel/built-in.o(.init.text+0x6470): In function `mp_config_acpi_legacy_irqs':
16:21 < riel> arch/xen/i386/kernel/mpparse.c:1008: undefined reference to `es7000_plat'
16:22 < riel> drivers/built-in.o(.text+0x8002): In function `get_new_vector':
16:22 < riel> drivers/pci/msi.c:364: undefined reference to `interrupt'
16:22 < riel> drivers/built-in.o(.text+0x800e):drivers/pci/msi.c:364: undefined reference to `set_intr_gate'
16:22 < riel> make: *** [.tmp_vmlinux1] Error 1
16:22 < riel> </flood>
16:22 < riel> awesome, nearly got it ;)
16:22 < rharper> riel: ok, I'll give it a compile in a bit and see if I can see that warning
16:37 < riel> awesome, down to 1 linking erorr now!
16:41  * riel unsets CONFIG_PCI_MSI ;)
16:43 -!- tim [~tim@cpe-66-67-139-238.rochester.res.rr.com] has joined #xen
16:45 < jonmason> riel: won't that break PCIe?
16:46 < riel> config PCI_MSI
16:46 < riel>         bool "Message Signaled Interrupts (MSI and MSI-X)"
16:46 < riel> ...
16:47 < riel>            If you don't know what to do here, say N.
16:47  * riel guesses not
16:49 < jonmason> MSi is required for PCI express
16:49 < jonmason> it is how it does interrupts
16:49 < jonmason> so, I would think that would cause all of your I/O to not work
16:50 < jonmason> unless they all work via polling
16:50 < riel> hummm ok
16:50 < riel> that's too bad then ;)
16:50 < jonmason> if I had a PCIe system, I would try to confirm this
16:51 < riel> dunno if I have one, but I do know I have no PCIe cards
16:51 < jonmason> if you don't have PCIe, then diable it ;-)
16:51 < riel> it doesn't compile
16:51 < riel> so Idisable it
16:52 < jonmason> I would think lspci would tell you 
16:52 < riel> too bad if an FC4 user does have PCIe and tries to use xen ;)
16:52 < riel> ok good, now vmlinuz compiled
16:52 < jonmason> perhaps someone should open a bug ;-)
16:55 < riel> good point, will do
16:56 < jonmason> actually, from your post it looks like someone got sloppy and broke the definitions in MSI
16:56 < riel> another nice activity to do while waiting on a compile
16:56 < riel> nope, drivers/pci/msi.c just depends on something arch/xen doesn't do (and quite possibly shouldn't do)
16:56 < jonmason> I'd have to know the xen stuff better to argue with you
16:58  * riel files #49
17:38 -!- riel is now known as unriel
17:51 -!- aliguori [~anthony@pixpat.austin.ibm.com] has quit [Quit: Leaving]
17:52 -!- enum [~Administr@ip68-7-54-228.sd.sd.cox.net] has joined #xen
17:52 < enum> yo, I have a couple of questions.. 
17:52 < enum> 1) Arent't there supposed to be example kernel configs in the xen package?
17:52 < enum> 2) Is there a way to do networking for guests without the tun module being loaded?
17:56 < rharper> enum: you will find the default configs in linux-<version>-xen-sparse/arch/xen/configs 
17:56 < rharper> enum: guest networking works via bridging (by default) but can support routing as well, though I;ve not messed with that 
17:59 < enum> rharper, my experience with bridging I always had to have tun enabled in the kernel;
17:59 < enum> thank you for your replies :)
18:00 < hollis> er, aren't tun/tap modules that allow userspace networking?
18:00 < rharper> enum: sure, lemme look at my configs, I dont change them from the defaults so tun/tap might already be enabled and I dont know it
18:01 < rharper> dom0 config has CONFIG_TUN=Y 
18:01 < enum> aha, that's why I couldn't modprobe
18:02 < rharper> yeah, that'll do it
18:02 < enum> do you recall what package contains tunctl?  I forget this one
18:02 < rharper> lemme check
18:03 < rharper> uml-utilities
18:03 < rharper> on debain
18:03 < rharper> debian
18:04 < enum> awesome.. I'm on gentoo so it was usermode-utilities, but you gave me the general idea, thanks!
18:05 < rharper> sure
18:12 < jonmason> is debug on by default in the latest unstable release?
18:15 -!- debugger [debugger@217.129.148.164] has joined #xen
18:15 -!- aliguori [~anthony@cpe-70-112-81-91.austin.res.rr.com] has joined #xen
18:16 -!- mccabemt [~mike@ny-lackawannacadent1a-lac-b-200.buf.adelphia.net] has quit [Read error: Operation timed out]
18:22 < rharper> jonmason: I dont think so
18:22 < rharper> but I always compile with debug=y in any case 
18:22 < jonmason> its printing out all this extra crap that I never saw before
18:23 < rharper> from xend ?
18:23 < rharper> yeah, not sure where that came from
18:23 < jonmason> yup
18:27 < jonmason> [xend] DEBUG (XendDomain:565) domain_restart_schedule> 1 poweroff 1
18:27 < jonmason> that crap
18:32 -!- tierra [~tierra@dsl093-225-126.slc1.dsl.speakeasy.net] has joined #xen
18:43 -!- enum [~Administr@ip68-7-54-228.sd.sd.cox.net] has quit [Read error: Connection reset by peer]
18:52 -!- rharper [~rharper@pixpat.austin.ibm.com] has quit [Quit: Leaving]
19:01 -!- hollis [~hollis@pixpat.austin.ibm.com] has quit [Quit: leaving]
19:15 -!- debugger [debugger@217.129.148.164] has quit [Quit: ]
19:31 -!- stekloff [~stekloff@bi01p1.co.us.ibm.com] has quit [Quit: Leaving]
20:16 -!- tim [~tim@cpe-66-67-139-238.rochester.res.rr.com] has quit [Ping timeout: 480 seconds]
20:18 -!- soffi [~soffi@proxy.du.vdsl.is] has joined #xen
20:29 -!- tim [~tim@cpe-66-67-139-238.rochester.res.rr.com] has joined #xen
20:29 -!- aliguori [~anthony@cpe-70-112-81-91.austin.res.rr.com] has quit [Quit: Leaving]
20:37 -!- rusty [~rusty@bh02i525f01.au.ibm.com] has joined #xen
20:43 -!- DEac- [~deac@xdsl-213-196-206-5.netcologne.de] has quit [Read error: Operation timed out]
20:54 -!- DEac- [~deac@xdsl-213-168-123-193.netcologne.de] has joined #xen
20:55 -!- rusty [~rusty@bh02i525f01.au.ibm.com] has quit [Quit: Client exiting]
20:59 -!- jimix [~jimix@ip13.194.susc.suscom.net] has joined #xen
21:02 -!- cfreak [cfreak@dsl-084-056-106-011.arcor-ip.net] has quit [Quit: .]
21:16 -!- Pete [~Pete@pcp01685957pcs.wchstr01.pa.comcast.net] has quit [Remote host closed the connection]
21:31 -!- jimix [~jimix@ip13.194.susc.suscom.net] has quit [Quit: jimix]
21:35 -!- rusty [~rusty@bh02i525f01.au.ibm.com] has joined #xen
21:41 -!- tierra [~tierra@dsl093-225-126.slc1.dsl.speakeasy.net] has quit [Quit: bug, n: A son of a glitch.]
21:48 -!- tierra [~tierra@dsl093-225-126.slc1.dsl.speakeasy.net] has joined #xen
21:48 -!- soffi [~soffi@proxy.du.vdsl.is] has quit [Quit: Leaving]
21:56 -!- lilo [~lilo@lilo.usercloak.oftc.net] has quit [Remote host closed the connection]
22:01 -!- lilo [~lilo@lilo.usercloak.oftc.net] has joined #xen
22:19 -!- lilo_ [~lilo@lilo.usercloak.oftc.net] has joined #xen
22:20 -!- lilo [~lilo@lilo.usercloak.oftc.net] has quit [Ping timeout: 480 seconds]
23:34 -!- MarkWilliamson [~MarkWilli@maw48.kings.cam.ac.uk] has left #xen [Kopete 0.10 : http://kopete.kde.org]
23:36 -!- tierra [~tierra@dsl093-225-126.slc1.dsl.speakeasy.net] has quit [Quit: bug, n: A son of a glitch.]
--- Log closed Wed May 18 23:59:00 2005