|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] Is it possible that Xen starts without Domain0
I have a question which may sound stupid. Is the dom0 mainly responsible for administration of other VMs? If a PC only needs running HVM and doesn't need any administration, is it possible that Xen doesn't start dom0 but setup VM environment and start-up HVM image? What modification do I need, such as drivers, memory management, file systems? Best regards, Hu Jia Yi Ext: 20430 Tel: 65-67510430 -----Original Message----- From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx [mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of xen-devel-request@xxxxxxxxxxxxxxxxxxx Sent: Friday, September 07, 2007 8:02 AM To: xen-devel@xxxxxxxxxxxxxxxxxxx Subject: Xen-devel Digest, Vol 31, Issue 26 Send Xen-devel mailing list submissions to xen-devel@xxxxxxxxxxxxxxxxxxx To subscribe or unsubscribe via the World Wide Web, visit http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel or, via email, send a message with subject or body 'help' to xen-devel-request@xxxxxxxxxxxxxxxxxxx You can reach the person managing the list at xen-devel-owner@xxxxxxxxxxxxxxxxxxx When replying, please edit your Subject line so it is more specific than "Re: Contents of Xen-devel digest..." Today's Topics: 1. Likely VMX Assist Issue from Ubuntu bug report (Zulauf, John) 2. Re: Likely VMX Assist Issue from Ubuntu bug report (Mats Petersson) 3. Re: [VTD-NEO][patch 0/6] Intel VT-d/Neocleus 1:1 mreged code for PCI passthrough (John Byrne) 4. RE: [VTD-NEO][patch 0/6] Intel VT-d/Neocleus 1:1 mreged code for PCI passthrough (Kay, Allen M) ---------------------------------------------------------------------- Message: 1 Date: Thu, 6 Sep 2007 15:02:46 -0700 From: "Zulauf, John" <john.zulauf@xxxxxxxxx> Subject: [Xen-devel] Likely VMX Assist Issue from Ubuntu bug report To: <xen-devel@xxxxxxxxxxxxxxxxxxx> Message-ID: <BD262A443AD428499D90AF8368C4528DA20404@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> Content-Type: text/plain; charset="us-ascii" "fancy isolinux screen on install isos hang xen/kvm HVM guests" https://bugs.launchpad.net/ubuntu/+bug/83642 Bug is in state "confirmed" and while the concensus on the bug thread is "we probably shouldn't be doing fancy things in protected mode", this seems like a fairly important distro to be borked for 3.2 (or 3.1.1 whatever). I've verified this using the i386 Ubuntu tip: http://cdimage.ubuntu.com/releases/gutsy/tribe-5/gutsy-desktop-i386.iso FYI John Zulauf Quoting the Ubuntu bug: I'm working with ubuntu on Xen right now, and this is a very bad problem. Both the server and desktop install CD's, for both dapper and edgy, use fancy full screen (vbe based?) isolinux install screens. Could we please do away with these screens on the server or alternate install CD? These fancy screens are causing fully virtualized guests that try to boot from these CD's to crash before the boot screen is even drawn. This is true for both Xen and KVM. To clarify, this does not cause the -host- to crash, just the guest, but you get a blank screen and wonder what happened. Background (mostly speculation, but I think it's right): Intel designed VT in a strange way, such that only protected mode instructions are allowed o be virtualized. Anything done in real mode must be emulated...every instruction. The Xen and KVM folks have emulated enough to get things working, but have not handled every instruction, including apparently some of the fancy (VBE?) graphics isolinux on the ubuntu boot cd's is using. (FreeBSD's btx loader also has problems) For reference, AMD's SVM analogue does, in fact, virtualize real mode instructions on the processor, and I'm able to boot all install CD's just fine on an AMD machine. This is an Intel VT .... 'quirk'. The mini.iso network install CD loads just fine and works, and I can install over an emulated network. And that CD includes a splash screen w/ isolinux, so it's not all VBE operations that cause problems. You should still be able to have a splash screen, but more then that might cause the problems. I've filed a bug against Xen about this, and I just tried KVM and ran into the same issue, so I'm assuming it's th same problem. But until the Xen folks figure out what instructions need to be emulated, and take enough time to care, or Intel comes out with an updated VT implementation that does what AMD's does, we can't just boot up a ubuntu install CD on virtual machines and have it work. My requested solution is that isolinux use just the standard (preferably text) menu and options on the server and/or alternate install CD. Having one full, officially supported install CD that doesn't crash Xen/KVM when trying to install a ubuntu would go a long way towards helping those of us trying to use ubuntu in a virtual environment out. Besides, while I really appreciate all the fancy boot options for a desktop machine, but I would prefer a plain text option for servers anyway. I do, however, see why some would like the opposite. Would it be possible to get the feisty 'server' install CD to forgo the fancy bootup options? NOTE: I think I understand what's going on, but if I'm missing something obvious, please tell me. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.xensource.com/archives/html/xen-devel/attachments/20070906/ c7a1a927/attachment.htm ------------------------------ Message: 2 Date: Thu, 06 Sep 2007 23:13:37 +0100 From: Mats Petersson <mats@xxxxxxxxxxxxxxxxx> Subject: Re: [Xen-devel] Likely VMX Assist Issue from Ubuntu bug report To: "Zulauf, John" <john.zulauf@xxxxxxxxx>,<xen-devel@xxxxxxxxxxxxxxxxxxx> Message-ID: <46e07b6e.1185300a.4139.05c4@xxxxxxxxxxxxx> Content-Type: text/plain; charset="us-ascii"; format=flowed At 23:02 06/09/2007, Zulauf, John wrote: >Content-class: urn:content-classes:message >Content-Type: multipart/alternative; > boundary="----_=_NextPart_001_01C7F0D1.A664E607" > >"fancy isolinux screen on install isos hang xen/kvm HVM guests" > ><https://bugs.launchpad.net/ubuntu/+bug/83642>https://bugs.launchpad.ne t/ubuntu/+bug/83642 > >Bug is in state "confirmed" and while the concensus on the bug >thread is "we probably shouldn't be doing fancy things in protected >mode", this seems like a fairly important distro to be borked for >3.2 (or 3.1.1 whatever). > >I've verified this using the i386 Ubuntu tip: ><http://cdimage.ubuntu.com/releases/gutsy/tribe-5/gutsy-desktop-i386.is o>http://cdimage.ubuntu.com/releases/gutsy/tribe-5/gutsy-desktop-i386.is o As far as I know, this is still the case. And the reason is, as stated in the bug-report, that the Intel people decided to not allow real-mode code to be virtualized. This is not a problem in itself, because VM8086 mode can cover most of the code, with a bit of "VMXAssist" to fix up privileged instructions not allows in VM8086 mode. However, there is a problem, and that is that the state of segment registers isn't maintained when switching from protected mode back to real-mode. This is often used by boot-loading code to load data into memory that is normally not reachable from real-mode (that is, memory above 1M). -- Mats > >FYI > >John Zulauf > >Quoting the Ubuntu bug: > >I'm working with ubuntu on Xen right now, and this is a very bad >problem. Both the server and desktop install CD's, for both dapper >and edgy, use fancy full screen (vbe based?) isolinux install >screens. Could we please do away with these screens on the server or >alternate install CD? These fancy screens are causing fully >virtualized guests that try to boot from these CD's to crash before >the boot screen is even drawn. This is true for both Xen and KVM. > >To clarify, this does not cause the -host- to crash, just the guest, >but you get a blank screen and wonder what happened. > >Background (mostly speculation, but I think it's right): >Intel designed VT in a strange way, such that only protected mode >instructions are allowed o be virtualized. Anything done in real >mode must be emulated...every instruction. The Xen and KVM folks >have emulated enough to get things working, but have not handled >every instruction, including apparently some of the fancy (VBE?) >graphics isolinux on the ubuntu boot cd's is using. (FreeBSD's btx >loader also has problems) > >For reference, AMD's SVM analogue does, in fact, virtualize real >mode instructions on the processor, and I'm able to boot all install >CD's just fine on an AMD machine. This is an Intel VT .... 'quirk'. > >The mini.iso network install CD loads just fine and works, and I can >install over an emulated network. And that CD includes a splash >screen w/ isolinux, so it's not all VBE operations that cause >problems. You should still be able to have a splash screen, but more >then that might cause the problems. > >I've filed a bug against Xen about this, and I just tried KVM and >ran into the same issue, so I'm assuming it's th same problem. But >until the Xen folks figure out what instructions need to be >emulated, and take enough time to care, or Intel comes out with an >updated VT implementation that does what AMD's does, we can't just >boot up a ubuntu install CD on virtual machines and have it work. > >My requested solution is that isolinux use just the standard >(preferably text) menu and options on the server and/or alternate >install CD. Having one full, officially supported install CD that >doesn't crash Xen/KVM when trying to install a ubuntu would go a >long way towards helping those of us trying to use ubuntu in a >virtual environment out. Besides, while I really appreciate all the >fancy boot options for a desktop machine, but I would prefer a plain >text option for servers anyway. I do, however, see why some would >like the opposite. > >Would it be possible to get the feisty 'server' install CD to forgo >the fancy bootup options? > >NOTE: I think I understand what's going on, but if I'm missing >something obvious, please tell me. > >_______________________________________________ >Xen-devel mailing list >Xen-devel@xxxxxxxxxxxxxxxxxxx >http://lists.xensource.com/xen-devel ------------------------------ Message: 3 Date: Thu, 06 Sep 2007 16:16:29 -0700 From: John Byrne <john.l.byrne@xxxxxx> Subject: Re: [Xen-devel] [VTD-NEO][patch 0/6] Intel VT-d/Neocleus 1:1 mreged code for PCI passthrough To: "Kay, Allen M" <allen.m.kay@xxxxxxxxx> Cc: Guy Zana <guy@xxxxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx, Keir Fraser <keir@xxxxxxxxxxxxx> Message-ID: <46E08A4D.8050706@xxxxxx> Content-Type: text/plain; charset=ISO-8859-1; format=flowed When I use these patches and start a nativedom with a directly-assigned NIC and no IOMMU, I get a lock up. Running the same domain/configuration/machine with the direct-io.hg tree worked fine. The crash output is below. If you'd like more information, let me know. John Byrne (XEN) pt_irq.c:81:d1 invalid assert_option value (XEN) pt_irq.c:81:d1 invalid assert_option value (XEN) pt_irq.c:81:d1 invalid assert_option value (XEN) pt_irq.c:81:d1 invalid assert_option value (XEN) pt_irq.c:81:d1 invalid assert_option value (XEN) pt_irq.c:81:d1 invalid assert_option value (XEN) pt_irq.c:81:d1 invalid assert_option value (XEN) pt_irq.c:81:d1 invalid assert_option value (XEN) pt_irq.c:81:d1 invalid assert_option value (XEN) pt_irq.c:81:d1 invalid assert_option value (XEN) WARNING: send pio with something already pending (9)? (XEN) domain_crash_sync called from hvm.c:485 (XEN) Domain 1 (vcpu#0) crashed on cpu#7: (XEN) ----[ Xen-3.0-unstable x86_32 debug=n Not tainted ]---- (XEN) CPU: 7 (XEN) EIP: 0000:[<00100fcb>] (XEN) EFLAGS: 00000002 CONTEXT: hvm (XEN) eax: 00000064 ebx: 001390c4 ecx: 001390c4 edx: 000000e9 (XEN) esi: 00103762 edi: 00101bf0 ebp: 00139038 esp: 00139038 (XEN) cr0: 00000011 cr4: 00000000 cr3: 00000000 cr2: 00000000 (XEN) ds: 0000 es: 0000 fs: 0000 gs: 0000 ss: 0000 cs: 0000 (XEN) domain_crash_sync called from hvm.c:132 (XEN) domain_crash_sync called from hvm.c:132 (XEN) domain_crash_sync called from hvm.c:132 (XEN) domain_crash_sync called from hvm.c:132 .... (XEN) *** [ Xen-3.0-unstable x86_32 debug=n Not tainted ]----(XEN) ----[ Xen-3.0-unstable x86_32 debug=n Not tainted ]----(XEN) e x86_32 debug=n Not tainted ]---- (XEN) ----[ Xen-3.0-unstable x86_32 debug=n Not tainted ]---- (XEN) CPU: 6 (XEN) CPU: 6(XEN) idle_loop+0x1b/0x90+010246 CONTEXT: hypervisor (XEN) EFLAGS: 00010246 CONTEXT: hypervisor (XEN) eax: 00000300 ebx: ffbe7fb4 ecx: 00000000 edx: 00000006 (XEN) esi: ff1a8430 edi: 91d91b27 ebp: 0000001c esp: ffbe7fa8 (XEN) cr0: 8005003b cr4: 000026d0 cr3: 3c6ee000 cr2: b7bf7000 (XEN) ds: e010 es: e010 fs: 0000 gs: 0000 ss: e010 cs: e008 (XEN) do_page_fault+0x45/0x3b0 (XEN) (XEN) Xen stac00010246Xen stac00010246 CR3: 00000000(XEN) ffbea080 ax: 6563696c ebx: 0000e010 ecx: 00010246 edx: ff1b7fb4(XEN) ffbea080 00000001 si: 0000e010 edi: 00000000 ebp: ff1b40ec esp: ff1b40a8(XEN) 00000000 s: e010 es: e010 fs: 0000 gs: 0000 ss: e010(XEN) c1351f90 00000006 00000006 00000006 (XEN) c03d7180 00000000 000e0007 c01013a7 00000061 00000246 c1351f8c 00000069 (XEN) 0000007b 0000007b 00000000 00000000 00000006 ffbea080 (XEN) Xen call trace: (XEN) [<ff1209fb>] idle_loop+0x1b/0x90 (XEN) Kay, Allen M wrote: > The following 6 patches contains merge of Intel VT-d and Neocleus' 1:1 > mapping patches for enabling HVM guest direct device access that were > last submitted around end of May. These patches applied cleanly to > changeset 15730. > > To enabled xen vt-d code, add "ioapic_ack=old" to xen boot parameter in > grub.conf on systems with VT-d hardware. > > To enabled xen 1:1 mapping code, add "enabled_nativedom=1" to xen boot > parameter in grub.conf. > > Signed-off-by: Allen Kay <allen.m.kay@xxxxxxxxx> > Signed-off-by: Guy Zana <guy@xxxxxxxxxxxx> > > _______________________________________________ > Xen-devel mailing list > Xen-devel@xxxxxxxxxxxxxxxxxxx > http://lists.xensource.com/xen-devel > ------------------------------ Message: 4 Date: Thu, 6 Sep 2007 17:00:31 -0700 From: "Kay, Allen M" <allen.m.kay@xxxxxxxxx> Subject: RE: [Xen-devel] [VTD-NEO][patch 0/6] Intel VT-d/Neocleus 1:1 mreged code for PCI passthrough To: "John Byrne" <john.l.byrne@xxxxxx> Cc: Guy Zana <guy@xxxxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx, Keir Fraser <keir@xxxxxxxxxxxxx> Message-ID: <13A2F7DE1BAEA345A61DD40F303ED7A66C5CF9@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> Content-Type: text/plain; charset="us-ascii" Other than minor changes while rebasing from 15521 to 15730. The following files have been modified that might affect functionality: Tools/hvmloader/32bitbios_support.c: removed a hack to increase highbiosarea size. Tools/ioemu/hw/pass-throught.c/pt_pci_write_config(): for is_native=1 case, pass-through pci config writes. Otherwise, pass-through only access to command register (for vt-d case). Note that we will use a different switch variable once it is added. These are minor changes, you might want to replace these file from the ones from direct-io tree to see if it fixes your problem. Allen >-----Original Message----- >From: John Byrne [mailto:john.l.byrne@xxxxxx] >Sent: Thursday, September 06, 2007 4:16 PM >To: Kay, Allen M >Cc: xen-devel@xxxxxxxxxxxxxxxxxxx; Guy Zana; Keir Fraser >Subject: Re: [Xen-devel] [VTD-NEO][patch 0/6] Intel >VT-d/Neocleus 1:1 mreged code for PCI passthrough > >When I use these patches and start a nativedom with a >directly-assigned >NIC and no IOMMU, I get a lock up. Running the same >domain/configuration/machine with the direct-io.hg tree worked >fine. The >crash output is below. If you'd like more information, let me know. > >John Byrne > >(XEN) pt_irq.c:81:d1 invalid assert_option value >(XEN) pt_irq.c:81:d1 invalid assert_option value >(XEN) pt_irq.c:81:d1 invalid assert_option value >(XEN) pt_irq.c:81:d1 invalid assert_option value >(XEN) pt_irq.c:81:d1 invalid assert_option value >(XEN) pt_irq.c:81:d1 invalid assert_option value >(XEN) pt_irq.c:81:d1 invalid assert_option value >(XEN) pt_irq.c:81:d1 invalid assert_option value >(XEN) pt_irq.c:81:d1 invalid assert_option value >(XEN) pt_irq.c:81:d1 invalid assert_option value >(XEN) WARNING: send pio with something already pending (9)? >(XEN) domain_crash_sync called from hvm.c:485 >(XEN) Domain 1 (vcpu#0) crashed on cpu#7: >(XEN) ----[ Xen-3.0-unstable x86_32 debug=n Not tainted ]---- >(XEN) CPU: 7 >(XEN) EIP: 0000:[<00100fcb>] >(XEN) EFLAGS: 00000002 CONTEXT: hvm >(XEN) eax: 00000064 ebx: 001390c4 ecx: 001390c4 edx: 000000e9 >(XEN) esi: 00103762 edi: 00101bf0 ebp: 00139038 esp: 00139038 >(XEN) cr0: 00000011 cr4: 00000000 cr3: 00000000 cr2: 00000000 >(XEN) ds: 0000 es: 0000 fs: 0000 gs: 0000 ss: 0000 cs: 0000 >(XEN) domain_crash_sync called from hvm.c:132 >(XEN) domain_crash_sync called from hvm.c:132 >(XEN) domain_crash_sync called from hvm.c:132 >(XEN) domain_crash_sync called from hvm.c:132 >.... >(XEN) *** [ Xen-3.0-unstable x86_32 debug=n Not tainted ]----(XEN) >----[ Xen-3.0-unstable x86_32 debug=n Not tainted ]----(XEN) e >x86_32 debug=n Not tainted ]---- >(XEN) ----[ Xen-3.0-unstable x86_32 debug=n Not tainted ]---- >(XEN) CPU: 6 >(XEN) CPU: 6(XEN) idle_loop+0x1b/0x90+010246 CONTEXT: hypervisor > >(XEN) EFLAGS: 00010246 CONTEXT: hypervisor >(XEN) eax: 00000300 ebx: ffbe7fb4 ecx: 00000000 edx: 00000006 >(XEN) esi: ff1a8430 edi: 91d91b27 ebp: 0000001c esp: ffbe7fa8 >(XEN) cr0: 8005003b cr4: 000026d0 cr3: 3c6ee000 cr2: b7bf7000 >(XEN) ds: e010 es: e010 fs: 0000 gs: 0000 ss: e010 cs: e008 >(XEN) do_page_fault+0x45/0x3b0 >(XEN) (XEN) Xen stac00010246Xen stac00010246 >CR3: 00000000(XEN) ffbea080 > ax: 6563696c ebx: 0000e010 ecx: 00010246 edx: ff1b7fb4(XEN) >ffbea080 00000001 > si: 0000e010 edi: 00000000 ebp: ff1b40ec esp: ff1b40a8(XEN) >00000000 > s: e010 es: e010 fs: 0000 gs: 0000 ss: e010(XEN) c1351f90 >00000006 00000006 > 00000006 >(XEN) c03d7180 00000000 000e0007 c01013a7 00000061 00000246 >c1351f8c >00000069 >(XEN) 0000007b 0000007b 00000000 00000000 00000006 ffbea080 >(XEN) Xen call trace: >(XEN) [<ff1209fb>] idle_loop+0x1b/0x90 >(XEN) > > >Kay, Allen M wrote: >> The following 6 patches contains merge of Intel VT-d and >Neocleus' 1:1 >> mapping patches for enabling HVM guest direct device access that were >> last submitted around end of May. These patches applied cleanly to >> changeset 15730. >> >> To enabled xen vt-d code, add "ioapic_ack=old" to xen boot >parameter in >> grub.conf on systems with VT-d hardware. >> >> To enabled xen 1:1 mapping code, add "enabled_nativedom=1" >to xen boot >> parameter in grub.conf. >> >> Signed-off-by: Allen Kay <allen.m.kay@xxxxxxxxx> >> Signed-off-by: Guy Zana <guy@xxxxxxxxxxxx> >> >> _______________________________________________ >> Xen-devel mailing list >> Xen-devel@xxxxxxxxxxxxxxxxxxx >> http://lists.xensource.com/xen-devel >> > ------------------------------ _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel End of Xen-devel Digest, Vol 31, Issue 26 ***************************************** _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |