Hi, gurus,
I want to have a clear picture of how xen/dom0 works with qemu and the
physical hardware so I searched qemu website, but only found limited
documents. Xen doesn''t include detailed docs either. It only says qemu
is modified to integrate in xen. What''s the modification and why they
are modified remains only in the souce code files.
I found it is quite complicated looking for clues in the source code
files to draw a big picture. Could anybody tell me where I should start?
Best regards,
Hu Jia Yi
Ext: 20430
Tel: 65-67510430
-----Original Message-----
From: xen-devel-bounces@lists.xensource.com
[mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of
xen-devel-request@lists.xensource.com
Sent: Wednesday, September 26, 2007 5:35 AM
To: xen-devel@lists.xensource.com
Subject: Xen-devel Digest, Vol 31, Issue 106
Send Xen-devel mailing list submissions to
xen-devel@lists.xensource.com
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@lists.xensource.com
You can reach the person managing the list at
xen-devel-owner@lists.xensource.com
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Xen-devel digest..."
Today''s Topics:
1. auto-translated-physmap resume (Andres Lagar-Cavilla)
2. Xen Kernel Debug Tools (John Anderson)
3. Re: Report Xen-3.1.1-rc1 make install does not install
/etc/hotplug (Keir Fraser)
4. RE: auto-translated-physmap resume (Ian Pratt)
5. How do I debug the hypervisor? (Roger Cruz)
6. RE: Xen Kernel Debug Tools (Ian Pratt)
----------------------------------------------------------------------
Message: 1
Date: Tue, 25 Sep 2007 16:25:16 -0400
From: Andres Lagar-Cavilla <andreslc@cs.toronto.edu>
Subject: [Xen-devel] auto-translated-physmap resume
To: xen-devel@lists.xensource.com
Message-ID: <46F96EAC.8040101@cs.toronto.edu>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Hi,
I was wondering, perhaps in my ignorance, what prevents an
auto-translated-physmap linux guest from being suspended/resumed.
As far as I understand, there would be no need for pagetable
canonicalization code in xc_linux_save, as well as no need for those
mfn_to_pfn translations in pre_suspend (and viceversa in post_suspend)
Anything I am missing?
Thanks!
Andres
------------------------------
Message: 2
Date: Tue, 25 Sep 2007 13:31:51 -0700
From: "John Anderson" <johnha@ccbill.com>
Subject: [Xen-devel] Xen Kernel Debug Tools
To: <xen-devel@lists.xensource.com>
Message-ID:
<A7F39817EC2477418A3AA053E69F835A99BD0D@Exchange.ccbill-hq.local>
Content-Type: text/plain; charset="us-ascii"
Greetings,
I''m attempting to mash grsecurity-2.1.9 into Xen 3.1.1-rc1. Last time
I
did this, for Xen 3.02, things went off without much of a hitch.
However, this time I''m running into a snag in the Dom0 kernel when a
para-virtualized DomU starts up. The page fault I''m seeing in the
Xen''s dmesg (xm dmesg) is below, but as it is, its not very helpful.
I''m looking for a Xen tutorial that lists the tools and techniques I
need to debug kernel code, and hopefully associate this stack trace with
a source file and line number. Does anyone know if such a tutorial
exists? If so, can you please point me in the right direction? I''ve
found some dated documents about kdb patches being necessary or some
sort of thing. I was hoping it would be as easy as turning on debug
support, getting a crash dump, and running it through gdb, but it
doesn''t look like that is the case.
Here is the page fault exception I''m getting in xm dmesg. The Dom0
Linux kernel''s dmesg gets no messages. This happens when I attempt to
start a grsecurity enabled DomU on a grsecurity enabled Dom0. Starting
a grsecurity enabled DomU on a non-grsecurity Dom0 works just fine.
(XEN) Unhandled page fault in domain 14 on VCPU 0 (ec=0010)
(XEN) Pagetable walk from ffffffff80200000:
(XEN) L4[0x1ff] = 0000000000000000 ffffffffffffffff
(XEN) domain_crash_sync called from entry.S
(XEN) Domain 14 (vcpu#0) crashed on cpu#0:
(XEN) ----[ Xen-3.1.0 x86_64 debug=n Not tainted ]----
(XEN) CPU: 0
(XEN) RIP: e033:[<ffffffff80200000>]
(XEN) RFLAGS: 0000000000010202 CONTEXT: guest
(XEN) rax: 0000000000000000 rbx: 0000000000000000 rcx:
0000000000000000
(XEN) rdx: 0000000000000000 rsi: ffffffff80569000 rdi:
0000000000000000
(XEN) rbp: 0000000000000000 rsp: ffffffff80574000 r8:
0000000000000000
(XEN) r9: 0000000000000000 r10: 0000000000000000 r11:
0000000000000000
(XEN) r12: 0000000000000000 r13: 0000000000000000 r14:
0000000000000000
(XEN) r15: 0000000000000000 cr0: 000000008005003b cr4:
00000000000006f0
(XEN) cr3: 000000041c62a000 cr2: ffffffff80200000
(XEN) ds: 0000 es: 0000 fs: 0000 gs: 0000 ss: e02b cs: e033
(XEN) Guest stack trace from rsp=ffffffff80574000:
(XEN) Stack empty.
Thanks,
John Anderson
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.xensource.com/archives/html/xen-devel/attachments/20070925/
ab01e8fb/attachment.htm
------------------------------
Message: 3
Date: Tue, 25 Sep 2007 22:16:15 +0100
From: Keir Fraser <Keir.Fraser@cl.cam.ac.uk>
Subject: Re: [Xen-devel] Report Xen-3.1.1-rc1 make install does not
install /etc/hotplug
To: Teck Choon Giam <giamteckchoon@gmail.com>
Cc: xen-devel@lists.xensource.com
Message-ID: <C31F392F.E070%Keir.Fraser@cl.cam.ac.uk>
Content-Type: text/plain; charset="US-ASCII"
On 25/9/07 19:27, "Teck Choon Giam" <giamteckchoon@gmail.com>
wrote:
> Thanks for your information about udevinfo. Yes, you are right as
> this is the output shown in my test CentOS 5.0:
> # udevinfo -V
> udevinfo, version 095
>
> and in CentOS 4.5 it is:
> # udevinfo -V
> udevinfo, version 039
>
> So would this means that for any udevinfo version greater than 059, I
> have to manually create /etc/hotplug folder and copy xen-backend.agent
> into it manually for future releases for Xen i.e. version 3.1.1?
The question is really why your system doesn''t pick up the udev config
files
we install, and work properly with those. I wouldn''t really expect it
to
need the hotplug config file.
-- Keir
------------------------------
Message: 4
Date: Tue, 25 Sep 2007 22:14:59 +0100
From: "Ian Pratt" <Ian.Pratt@cl.cam.ac.uk>
Subject: RE: [Xen-devel] auto-translated-physmap resume
To: "Andres Lagar-Cavilla" <andreslc@cs.toronto.edu>,
<xen-devel@lists.xensource.com>
Message-ID:
<8A87A9A84C201449A0C56B728ACF491E26083B@liverpoolst.ad.cl.cam.ac.uk>
Content-Type: text/plain; charset="us-ascii"
> I was wondering, perhaps in my ignorance, what prevents an
> auto-translated-physmap linux guest from being suspended/resumed.
> As far as I understand, there would be no need for pagetable
> canonicalization code in xc_linux_save, as well as no need for those
> mfn_to_pfn translations in pre_suspend (and viceversa in post_suspend)
> Anything I am missing?
That''s about it -- there''s less to do if you''re using
shadow pagetables.
Since auto-translated-physmap is typically only used by various research
projects its not particularly well maintained, but its usually easy to
fix up.
Ian
------------------------------
Message: 5
Date: Tue, 25 Sep 2007 17:31:01 -0400
From: "Roger Cruz" <rcruz@marathontechnologies.com>
Subject: [Xen-devel] How do I debug the hypervisor?
To: "xen-devel" <xen-devel@lists.xensource.com>
Message-ID:
<40B551BEDC7945419A5897958AB3947C099207@mtexch.marathontechnologies.com>
Content-Type: text/plain; charset="us-ascii"
Just posted this in XenSource''s Misc. forums, but I figure this may be
a
more appropriate channel to ask the following question.
I''m using XenEnterprise 4.0 (hypervisor is based off 3.1.0) and would
like to make changes to the hypervisor. I need to find out how to hook
up a debugger to it so I can step through the code and examine its
state.
I would appreciate a detail response on how to configure the hypervisor,
hook up GDB and have access to symbol information.
Thank you.
Roger Cruz
------------------------------
Message: 6
Date: Tue, 25 Sep 2007 22:33:11 +0100
From: "Ian Pratt" <Ian.Pratt@cl.cam.ac.uk>
Subject: RE: [Xen-devel] Xen Kernel Debug Tools
To: "John Anderson" <johnha@ccbill.com>,
<xen-devel@lists.xensource.com>
Message-ID:
<8A87A9A84C201449A0C56B728ACF491E26083F@liverpoolst.ad.cl.cam.ac.uk>
Content-Type: text/plain; charset="us-ascii"
> Here is the page fault exception I''m getting in xm dmesg. The
Dom0
> Linux kernel''s dmesg gets no messages. This happens when I
attempt to
> start a grsecurity enabled DomU on a grsecurity enabled Dom0.
> Starting a grsecurity enabled DomU on a non-grsecurity Dom0 works just
> fine.
This is pretty surprising. When a domU is actually running, dom0 isn''t
really involved (other than for IO), so its surprising grsec makes a
difference.
Do you get any console output from the guest before it crashes? I''m
wandering if its actually been built incorrectly by the domain builder
running in dom0.
It''s looks like its dieing trying to do an instruction fetch from
ffffffff80200000 which is presumably the page fault handler.
Are you using a debug build of Xen? You may get some more helpful
output.
Ian
>
>
> (XEN) Unhandled page fault in domain 14 on VCPU 0 (ec=0010)
>
> (XEN) Pagetable walk from ffffffff80200000:
>
> (XEN) L4[0x1ff] = 0000000000000000 ffffffffffffffff
>
> (XEN) domain_crash_sync called from entry.S
>
> (XEN) Domain 14 (vcpu#0) crashed on cpu#0:
>
> (XEN) ----[ Xen-3.1.0 x86_64 debug=n Not tainted ]----
>
> (XEN) CPU: 0
>
> (XEN) RIP: e033:[<ffffffff80200000>]
>
> (XEN) RFLAGS: 0000000000010202 CONTEXT: guest
>
> (XEN) rax: 0000000000000000 rbx: 0000000000000000 rcx:
> 0000000000000000
>
> (XEN) rdx: 0000000000000000 rsi: ffffffff80569000 rdi:
> 0000000000000000
>
> (XEN) rbp: 0000000000000000 rsp: ffffffff80574000 r8:
> 0000000000000000
>
> (XEN) r9: 0000000000000000 r10: 0000000000000000 r11:
> 0000000000000000
>
> (XEN) r12: 0000000000000000 r13: 0000000000000000 r14:
> 0000000000000000
>
> (XEN) r15: 0000000000000000 cr0: 000000008005003b cr4:
> 00000000000006f0
>
> (XEN) cr3: 000000041c62a000 cr2: ffffffff80200000
>
> (XEN) ds: 0000 es: 0000 fs: 0000 gs: 0000 ss: e02b cs: e033
>
> (XEN) Guest stack trace from rsp=ffffffff80574000:
>
> (XEN) Stack empty.
>
>
>
>
>
> Thanks,
>
>
>
> John Anderson
------------------------------
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
End of Xen-devel Digest, Vol 31, Issue 106
******************************************
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Peter Teoh
2007-Sep-30 10:54 UTC
Re: [Xen-devel] Want to Learn how Qemu works in Xen and dom0
I am not an expert on Xen-QEMU either, but just want to share what I have found and know so far: First, reading the wiki: http://wiki.xensource.com/xenwiki/XenRoadMap QEMU QEMU has proved to be very helpful for providing Xen HVM guests with emulated IO devices. However, Xen''s current "qemu-dm" code has diverged quite heavily from mainline qemu, which means that we can''t as easily capitalise on enhancements made to mainline qemu, and also makes it harder for us to contribute enhancements back to Fabrice. Fixing this is a priority. We are developing a re-implementation of qemu-dm that is maintained as a patch queue against an unmodified snapshot of mainline qemu, and hope to have this ready for testing soon. Like the shadow pagetable code, this is going to require extensive testing even prior to inclusion in -unstable. Catching up with the latest version of qemu has a number of nice side effects. It gets us Anthony Liguori''s improved VNC server code for the framebuffer, removing our dependency on the rather obtuse libvncserver library. Further, it gets us support for emulated USB devices, most interesting of which is a USB mouse. The USB mouse protocol supports a mode of operation whereby it provides absolute x,y co-ordinates rather relative motion events (which the OS usually turns into absolute co-ordinates using some unknown `black box'' algorithm that has mouse speed and acceleration parameters). Being able to inject absolute co-ordinates means that it is easy to arrange for our the HVM guest cursor to perfectly track the local cursor in the VNC viewer, regardless of the user''s mouse settings. Although not immediately on the horizon, there are plans to give qemu a slightly extended role in Xen. The `V2E'' research work in Cambridge has shown that it is possible to move the execution state of a guest from a Xen virtual machine into qemu and back out again. In the context of the research work the aim was to enable high-performance taint tracking to be implemented, where the guest ran at full speed as a xen guest until it accessed a tainted value at which point execution was moved on to the qemu emulator which was able to monitor execution closely. At some point later execution would be moved back to Xen. As pointed out by Leendert, a similar approach can be used for transitioning into IO emulation, cleaning up the current interface and possibly providing performance optimizations when many IO operations are performed in close proximity. This technique also solves a thorny issue with Intel VT systems, which unlike AMD-V do not provide h/w assistance for virtualizing the legacy x86 `real mode''. Today, we have the `vmxassist'' code containing a crude emulator to try and handle this case, but the code fails in the presence of certain complex 16b applications, such as MSDOS or the SuSE graphical boot loader. Having the ability to throw execution onto QEMU which has a complete real mode emulation would solve this problem. And the binaries described: qemu-dm, is found in /usr/lib/xen/bin: /usr/lib/xen/bin>ls -1xpt qemu-dm xenconsole readnotes xc_restore xc_save xenctx qemu-dm.debug xen-sdlfb xen-sdlfbo xen-vncfb xen-vncfbo And as for the implementation, I found it under tools/ioemu. And under tools/ioemu/patches, I found all the diff files to be applied against the QEMU source. From the tools/ioemu/Changelog file, I deduced that the qemu version downloaded is 0.8.2. And as for the binary - qemu-dm, it is compiled into the subdirectory: tools/ioemu/i386-dm, based on original files located in tools/ioemu/ and its various subdirectory (as seen from Makefile, Makefile.target, it is depending on a complex criteria involving platform environment etc). _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel