> -----Original Message-----
> From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
> [mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of
> Steven Y. Ko
> Sent: 17 April 2007 17:46
> To: xen-devel@xxxxxxxxxxxxxxxxxxx
> Subject: [Xen-devel] Trying to understand HVM booting
>
> Hello,
>
> I'm trying to understand how HVM booting works. By my limited
> understanding of the Xen code, it seems that a new domain is scheduled
> but paused (or is it paused?) by domain_create() in
> xen/common/domain.c. Then xc_hvm_build() in tools/libxc/xc_hvm_build.c
> loads hvmloader and calls a hypercall with XEN_DOMCTL_setvcpucontext.
> It looks like, when executing this hypercall, domain_unpause() is
> called (in xen/common/domctl.c) and it starts the execution of
> hvmloader. Is this correct? My understanding is very limited, and it
> would be great if someone can point out some important pieces of code
> so I can look into it.
I'm not an expert, but what you say seems about right from what I've
understood.
>
> Also, I'm looking at hvmloader, and wondering where it actually starts
> loading the new HVM DomU kernel. Specifically, I wonder where in the
> code it reads the disk to load the kernel. Can anyone give me some
> pointers? Thanks!
Ok, let's explain how hvmloader works: it loads the BIOS, VGA-bios, and
if relevant VMXassist into memory, then jumps to the reset-address in
the BIOS-code.
It's the BIOS that loads your OS-kernel (or whatever else it may be that
the boot-sector that your DISK-line in the config file contains). For
example, you can boot DOS, real-time OS or whatever else may available
on the disk (boot-sector virus's included, I would think!). And when it
comes to the BIOS loading the image, it's actually no different from on
the bare-metal BIOS loading the OS. It just does some IO to the
disk-controller (normally IDE, meaning IO-addresses as 1F0-1F7 for the
first controller, 1E0-1E7 for the second controller). These IO
instructions are intercepted by the hypervisor and sent to QEMU for
"execution". Once the boot-sector is loaded and checked for the correct
"this is a real boot-sector", the BIOS jumps to the start of the
boot-sector and from there on, you're in the boot-loader of the OS,
whether that's the Windows boot, GRUB/LILO for Linux or some other
proprietary boot-manager (an OS/2 term, I think).
With a modified hvmloader, you could also load for example ROM-images,
directly into guest-memory, of a RTOS that you may want to executed. [I
have some "simple guests" that completely bypass the hvmloader, I just
replace "hvmloader" with my binary image, and it just starts executing
"my code" immediately, without having to create a disk-image and rely on
a bunch of other things. Very good for testing basic stuff in HVM path
of the hypervisor].
I hope this lets you move on further in your understanding of hvmloader.
--
Mats
>
> - Steve
>
> _______________________________________________
> 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
|
Home