Re: port kvm to arm

[Avi Kivity]

(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 linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/