(copying kvm@xxxxxxxxxxxxxxx, where most kvm development happens)
sen wang wrote:
I have some idea about the ARM KVM.
I have register a project ,named"arm-kvm", to port KVM to arm.
I'll kick off the ARM KVM porting next week.
This is my plan:
step 1 Make a guest linux run on the Hypervisor-linux.
From the Hypervisor-linux's viewpoint, The guest is a thread of him.
which is like the X86 KVM.But,In this step,the guest-linux has no IO.
It is based on roofs. The physical memroy is allocated to the guest os
at creating time. The guest-linux still run in the privileged
mode,which handle the user mode memory exeception ,SWI system call ...
But the guest-linux will not touch the hardware devices.The physical
interrupt should be controlled by Hypervisor-linux. So the
Hypervisor-linux can switch it off when interrupt happens. And the
Hypervisor-linux will provide some vitual system devices like system
timer and interrupt controller for guest.
Because lack of hardware support,The guest linux should know when to
exit,for exemple the idle time,the kernel panic, the guest should
voluntarily exit VM --which is like a thread switch.
so there is another job: modification of Hypervisor-linux to support
arm,and modification of qemu for arm KVM
You'll can hook read[bwl]() and similar functions to use hypercalls,
which will allow you to use emulated devices in qemu, even without full
mmu virtualization.
step 2 Make guest IO work
The guest should have IO functions.Of course, IT is the virtIO. we
should make the virtIO work on the arm kvm.The arm has no hardware
virtualization extension like intel VT. But,In the guest virtIO
driver, when need start IO,the guest should voluntarily exit VM--so it
like IO-exit of the intel VT.
If you make emulated devices work, then you can defer this to the last
step. virtio is only an optimization.
step 3 add memory virtualization for guest
just make the guest run in the user mode，porting the x86 kvm memory
virtualization function for arm kvm,and so on. But I think we should
keep the work mode of step 1 as a option for user. sometime, I think
the guest handle the physical memory directly is not a bad thing.
step 4 use the trustzone
from arm V6, there is a hardware extension of trustzone. We can make
use of it. let the Hypervisor-linux run int the monitor state,the
guest run in the non-security state. But,the guest os run as
normal--linux kernel in the privileged mode,the user program in the
user mode.So architecture is more elegant.
Does the monitor state have its own userspace? If not, how are you
going to run qemu?
step5 more guest os
the work mode of step 1 has the advantage: we don't need modify the
guest much,which make port wince,symbain possible. for, you know,we
don't have so much source codes for those os.
welcome join the "arm-kvm" team. thanks
Good luck :)
--
Do not meddle in the internals of kernels, for they are subtle and quick to panic.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
