[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] xen bug hunting
> > some of the problems i remember encountering: > in dom0: creating a new domain, destroying it, and creating a new domain > reboots my machine. same happens if dom1 is unable to boot, and the > domains gets destroyed this way. This isn't good. I haven't seen Xen crash due to another domain failing in a very long time. It's possible that this bug has been introduced recently -- I'll try and reproduce. > the default .config works fine, but as soon as i enable > CONFIG_EXPERIMENTAL and CONFIG_FS_DEVFS(sp?), dom0 isn't able to boot > anymore (immediate reboot). i'll try examining this one in a ring 1 domain, > as soon as i have my first virtual harddrive install boot. Odd. I've never used devfs, but I'd have thought it would have worked. Its configuration will probably need teaching about virtual block devices. > things that don't work: > mouse (logitech ps/2 optical wheelmouse) neither in X nor gpm PS2 mice seem to work for us. Can you say a bit more about the setup. > questions: > how do i assign a partition as root partition to the new domain? > i suspect vbds are what i want. are they documented anywhere? You can either give the new domain a real, physical partition as its root, or give it a virtual disk. If the former, you'll need to grant the domain access e.g. to give domain 1 r/w access to /dev/hda4 : xenctl physical grant -phda4 -w -n1 You'll need to set "root=/dev/hda4" on the command line for the new domain. Alternatively, create and populate a virtual disk, and then use 'xenctl vbd create' to attach it to another domain. [see the other thread on xen-devel for more info] > any discussions about a 2.6 port yet? are you aiming for > inclusion in 2.7? We'll probably do a 2.6 port once its stable. Inclusion it 2.7 would be great, but we'll need to demonstrate a vibrant user community. That's where you come in ;-) > i know that the multiboot approach is more flexible, but would it be > possible to implement xen's functionality into a linux kernel? could > this possibly increase dom0*'s performance and range of available > drivers? Trying to implement Xen within Linux is actually likely to slow things down. In the long term, we see Xen's future more as a 'next generation BIOS'. We want to create a standard OS-independent environment for running device drivers in a protected ring-1 environment. In the shorter term, we may add support to allow drivers for 'low performance' devices like USB, PCMCIA etc to run in domain0, and be virtualized via domain0. This should give us the same hardware support as Linux, until we convince the world that Xen should be shipped on every machine ;-) Cheers, Ian ------------------------------------------------------- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |