Christoffer Dall wrote: > it has to be able to read from 0xFFFF0000 and up when in everything else > than user mode otherwise the interrupt vectors won't work. But yes, in > user mode neither host or guest should be able to read/modify these > addresses - I think it's already like this - no? I would think that the guest runs in lower privilege level than the host. so memory at 0xFFFF0000 (and up ?) is going to be accessible by the privileged runlevel but not by regular runlevel. therefore, the guest kernel won't be able to access it directly. when an interrupt occurs the runlevel automatically changes and the handler runs in privileged mode. (just like usermode processes can't access 0xC0000000 and up in linux, while the kernel can). Oren. > > On Mon, Apr 20, 2009 at 9:34 PM, Brian Smith <bls2129 at columbia.edu > <mailto:bls2129 at columbia.edu>> wrote: > > 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> > <mailto: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>> <mailto: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>> > <mailto: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> > <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
