Porting VBox to Xen domU (paravirt)
Posted: 21. Nov 2008, 19:14
Hi,
I've been looking into porting Virtual Box to be able to run on Xen domU. Xen domU runs in ring 1, and in paravirt mode the domU kernel is modified to cooperate with the Xen hypervisor. In porting Virtual Box to run, I have to modify the vboxdrv kernel mdule to use the modified memory functions, which worked out fine. Of greater difficulty is modifying VMMR0.r0 to run in ring 1 and to collaborate with the underlying Xen hypervisor.
In my approach, I would like to allow the guest to stay in ring 1 "alongside" the domU kernel. I'm a newbie to x86 architecture, and am wondering if there is some fundamental flaw to this design.
I've recently been thinking about the memory mapping issues, and am having some lack of clarity as to how Virtual Box keeps VMMR0.r0 and VMMGC.gc mapped when executing the guest OS without allowing the guest kernel to stomp on them. My understanding is that VMMR0.r0 is protected because the guest kernel is in ring 1 and VMMR0.r0 is in ring0. However, from what I understand, VMMGC.gc is in ring 1 and is mapped during guest execution. Is this a fundamental problem for my approach because VMMR0.r0 will now be in ring 1 and able to be accessed from the guest directly?
Thanks!
I've been looking into porting Virtual Box to be able to run on Xen domU. Xen domU runs in ring 1, and in paravirt mode the domU kernel is modified to cooperate with the Xen hypervisor. In porting Virtual Box to run, I have to modify the vboxdrv kernel mdule to use the modified memory functions, which worked out fine. Of greater difficulty is modifying VMMR0.r0 to run in ring 1 and to collaborate with the underlying Xen hypervisor.
In my approach, I would like to allow the guest to stay in ring 1 "alongside" the domU kernel. I'm a newbie to x86 architecture, and am wondering if there is some fundamental flaw to this design.
I've recently been thinking about the memory mapping issues, and am having some lack of clarity as to how Virtual Box keeps VMMR0.r0 and VMMGC.gc mapped when executing the guest OS without allowing the guest kernel to stomp on them. My understanding is that VMMR0.r0 is protected because the guest kernel is in ring 1 and VMMR0.r0 is in ring0. However, from what I understand, VMMGC.gc is in ring 1 and is mapped during guest execution. Is this a fundamental problem for my approach because VMMR0.r0 will now be in ring 1 and able to be accessed from the guest directly?
Thanks!