Re: port kvm to arm

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



(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

[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux