Christoffer, Just to be clear, the guest storage at 0xFFFF0000 will not be guest's storage, so we would have to take care to make sure they can't read that storage. Otherwise they could have problems. For everything else, what you said is along the same lines I was thinking, thanks for your input! Brian Christoffer Dall wrote: > see my answers below > > (Oren, there's a question hidden in there for you if you have > time/energy...) > > On Mon, Apr 20, 2009 at 8:28 PM, Brian Smith <bls2129 at columbia.edu > <mailto:bls2129 at columbia.edu>> wrote: > > Hey, > Sorry, I don't 100% understand, let's take for example the > address 0xFFFF0000 (the reset interrupt vector), what will be > there when the guest is running? > > > a custom interrupt handler placed above 0xFFFF0000 and mapped by both > shadow and host page table, which does: > - replace page table to host page table > - call host kernel interrupt handler (possibly the KVM handler, which > you are writing!!!) > > > Will it be the guest's reset interrupt vector, or will it be the > host's reset interrupt vector. It seems to me it must be the > latter, but in this case how do we prevent the guest from > reading/writing to that storage when trying to setup his own > interrupt handlers? With the guest switch your talking about > writing interrupt handlers, I want to make sure you don't > duplicate any work I've done, have you looked at my stuff? You > said disable interrupts, is that until the jump to the guest, or > are you suggesting the guest should run disabled? If that is the > case then there is no point in intercepting IRQ interrupts right? > I'm going to assume the guest does run enabled so I can build on > what you said below to my question. > > > - Of course IRQ's are enabled when running the guest. > - might not be necessary to disable interrupts, could instead be done > by checking which page table is in effect when handling interrupt - > probably better. This does not interfere with your work, and we will > think more about the specifics during the week. We can revisit this > subject next week if you wish. > > > > Like I said, obviously we want the host kernel to handle hardware > interrupts, that isn't what I was asking. I agree 100% that QEMU > generates the interrupt, and I am guessing it does that through > some interface to KVM. If this is the case, we can't do anything > with the interrupt until the guest looses control and the host > (kvm module) gains control. That is my question, what do we need > to do to regain control. > > > I think I understand your question. You have a good point. The thing > we have to think about is where to return to from the interrupt. > > I suggest (Oren, it would be great if you have input here): > - Instead of letting the host return to the guest, let it return to > our kvm interrupt handler. > - In here, if an interrupt has been raised by QEMU since the last > time the guest was issued, issue the guest interrupt handler instead > of the originating code and emulate where to return to in the guest etc. > - The interrupt would be set asynchronously in QEMU by the signals > registered on file descripters and a SIG_ALRM for timers. > - The above can be done by replacing r14 and modifying SPSR before > calling the host handler. > > In this way we let the host kernel deal with nested interrupts and all > that stuff and the only thing we do is impose a _very_ thin layer > around the interrupts and only if we are running a guest. Nice and > minimally intrusive I think. > > > > Let me try and ask the question a different way. When any > asynchronous interrupt occurs the interrupt handler is responsible > for saving state so when the interrupted task is redispatched it's > like the interrupt never happened. In the case of an asynchronous > interrupt while the guest was running, if the only step we took > was pass the interrupt to the real handler, at next redispatch the > guest will be the one getting control not the host (because the > interrupt occurred while running the guest). We don't want that > because then we don't have control to issue any interrupts of our > own to the guest. > Here's the question. Is it sufficient for us to just reenable for > interrupts in our interrupt handler (host code) and let ourselves > get interrupted for the same IRQ, but this time the state saved > will be the host state and we have successfully broken from the > guest. Or do we have to give control to the real IRQ handler > ourselves in such a way that when it saves state it will give us > (host) control and not the state of the CPU when the interrupt > actually occurred (in the guest). "reenable" is easiest to code > since nothing needs to be done, and this is how ppc works (I > believe ppc will keep issuing a hardware event until the handler > says "I've seen you, stop"). I am wondering if anyone knows if > that is how ARM works. I think we have to do it the hard way, but > I wanted to get your opinions on it before attempting it. > > UNDEFINED interrupts can legitimately occur if a user program > issues a coprocessor and the coprocessor doesn't exist (say the > floating point coprocessor). A good operating system would > emulate the user program's intentions if it can. UNDEFINED > interrupts can also occur if you tried to execute data too. In > either case, we would want to pass the interrupt to the guest. > > > if from host, pass it to host, if from guest, pass it to guest. I > don't see any subtleties here. > > > > Regards, > Brian > > Christoffer Dall wrote: > > 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 > <mailto:bls2129 at columbia.edu> <mailto:bls2129 at columbia.edu > <mailto: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 > <mailto:Android-virt at lists.cs.columbia.edu> > <mailto:Android-virt at lists.cs.columbia.edu > <mailto:Android-virt at lists.cs.columbia.edu>> > > https://lists.cs.columbia.edu/cucslists/listinfo/android-virt > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > Android-virt mailing list > Android-virt at lists.cs.columbia.edu > <mailto:Android-virt at lists.cs.columbia.edu> > https://lists.cs.columbia.edu/cucslists/listinfo/android-virt > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Android-virt mailing list > Android-virt at lists.cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/android-virt >
