Hi there.
Andreas and I are continuing the incremental approach to make something
running.
The status is this:
- We can run the bootl oader now, but fast we run into problems, since:
* the kernel expects to be at low address 0x00000008
* next step for kernel is to load itself in the upper 1G of the virtual
memory space
The way forward, which Andreas and I are working on:
- Create shadow page table
* have special mapping in upper 64 mb, which Linux doesn't touch
* relocate code to this mapping
- Write guest-switch and interrupt handlers:
* guest switch will disable interrupts, switch page table, switch
handlers, jump to guest
* interrup handler will switch back page table and jump to kernel
handlers
Regarding the questions below, see my answers inline:
On Mon, Apr 20, 2009 at 12:19 PM, <bls2129 at columbia.edu> wrote:
> Hi all,
> Here is hopefully a better explanation of what I poorly described
> at the meeting today. We have come to agreement that we need to
> intercept IRQ exceptions, what I am unsure is how to handle them. For
> synchronous interrupts we do not pass them to the host kernel handler:
> SWI's that aren't due to translation should be passed along to the
> guest, UNDEFINED interrupts that isn't because of a system control
> processor operation is handled the same. I am less certain about
> synchronous abort interrupts, and whether the host kernel should see
> these, but that can be a later discussion.
I don't understand the above. Can you explain what is the case with
"UNDEFINED interrupts that isn't because of a system control processor
operation"?
I am also not certain about how to deal with data aborts. We definitely have
to wrap logic around it, but the answer will come when the guest table is in
place the the guest enables MMU and starts managing its own page tables and
so on. For sure data aborts should not be injected "raw" into the guest and
I don't think we need to worry about this right now, but probably next week
we have to.
>
> For asynchronous interrupts, we obviously want the host kernel to
> handle the interrupt. I was looking at the architecture and what I am
> unsure about is what happens if we are in our IRQ interrupt handler
> and enable for interrupts, would the IRQ be reissued by the hardware
> or is it lost? If it is reissued that would be great, because when
> the host code enables for interrupts, our host state is saved and on
> redispatch we regain control as the host. This is similar to how the
> PPC code works.
Hardware interrupts should not be forwarded to guest kernel. All devices are
emulated and these interrupts are generated by QEMU. The only thing we have
to do is switch the page tables and invoke the host handler. (A timer
interrupt would send a SIGALRM to qemu, which would eventually cause KVM to
emulate a timer interrupt and execute the guest handler in this case).
See kvm_arch_pre_run() in target-ppc/kvm.c:121 in the QEMU source and
kvmppc_check_and_deliver_interrupts() in arch/powerpc/kvm/booke_guest.c:209
in the linux kernel.
>
>
> If the interrupt would be lost, that means we have to pass the
> interrupt to the kernel ourselves, but we have to mess around with the
> registers the real IRQ will save to ensure the host regains control,
> not the guest (what the registers really were at interrupt).
>
> Comments/Suggestions?
>
> Brian
>
> _______________________________________________
> Android-virt mailing list
> Android-virt at lists.cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/android-virt
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.cs.columbia.edu/pipermail/android-virt/attachments/20090420/2f9795b3/attachment.html
