On Thu, Oct 18, 2012 at 1:26 PM, Marc Zyngier <marc.zyngier@xxxxxxx> wrote: > On 18/10/12 18:14, Christoffer Dall wrote: >> On Thu, Oct 18, 2012 at 11:08 AM, Marc Zyngier <marc.zyngier@xxxxxxx> wrote: >>> On 18/10/12 15:41, Christoffer Dall wrote: >>>> On Thu, Oct 18, 2012 at 10:25 AM, Peter Maydell >>>> <peter.maydell@xxxxxxxxxx> wrote: >>>>> On 18 October 2012 15:12, Christoffer Dall >>>>> <c.dall@xxxxxxxxxxxxxxxxxxxxxx> wrote: >>>>>> On Thu, Oct 18, 2012 at 10:09 AM, Alexander Graf <agraf@xxxxxxx> wrote: >>>>>>> On 18.10.2012, at 16:05, Marc Zyngier wrote: >>>>>>>> On 18/10/12 14:51, Christoffer Dall wrote: >>>>>>>>> I actually assumed that a reboot would generate a virtual reset to the >>>>>>>>> cpu, but I haven't looked into this at all. What exactly happens in >>>>>>>>> the guest kernel side when you call reboot? >>>>>>>> >>>>>>>> You hit some special VE device that causes the VCPUs to be reset (Peter, >>>>>>>> can you be more specific than I am?), >>>>> >>>>> It's in the VExpress system config registers: >>>>> http://arminfo.emea.arm.com/help/topic/com.arm.doc.dui0447f/CACDEFGH.html >>>>> >>>>> basically you use SYS_CFGCTRL to write to the relevant register on >>>>> the motherboard configuration controller to say "reboot!". (In QEMU >>>>> we emulate this by calling qemu_system_reset_request(), which will >>>>> do a simulation level reset: all device models get their reset function >>>>> called, resetting registers to reset values. Before we next run KVM >>>>> we will do a sync of state to the kernel.) >>>>> >>>>> We probably do want to tell the kernel when we've had a reset, though, >>>>> because part of the plan for cp15 registers is that QEMU should be able >>>>> to cope with the kernel knowing more cp15 registers than it does. So >>>>> QEMU wouldn't be able to reset cp15 regs it didn't know about. >>>>> [Well, I could make qemu suck out and save the reset values for >>>>> everything on startup so it could feed them back on reset. But it might >>>>> be easier to just tell the kernel to reset?] >>>>> >>>>> If you want us to make an ioctl on reset there's a convenient hook >>>>> for that on the qemu side. >>>>> >>>>>>>> but we don't signal anything to >>>>>>>> the VM itself - hence the guest restarting with timers ticking and GIC >>>>>>>> in some arbitrary state (interrupts being queued into the list >>>>>>>> registers, for example...). >>>>>>> >>>>>>> If you ever want to do live migration, you need to be able to get/set the >>>>>>> state of your GIC from user space anyways. So what would usually happen >>>>>>> is that on reset, QEMU would just set the state to a known good reset state. >>>>>>> >>>>>> hmm, Marc, how would we expose the GIC state? That's more than just >>>>>> the list registers because we can have things queued on the kernel >>>>>> side as well right? oh no... >>>>> >>>>> You don't want to expose the list registers anyway, they're an >>>>> implementation detail. Ideally you expose the architectural >>>>> state, so we can do migration between the in-kernel GIC and >>>>> the TCG fully-emulated GIC. Dong Aisheng is planning to look at >>>>> VGIC save/restore but I think he's still getting up to speed on the >>>>> GIC architecture... >>>>> >>>> ok, so let's see if we can hold off on this until anyone has enough >>>> time to devote to make this complete, under the assumption that we can >>>> fix the reset issue in another way before that. >>>> >>>> Marc, do you know if the problem is that we take interrupts when we're >>>> not ready to or is the problem that once we're ready to take >>>> interrupts we get interrupts from somewhere we didn't expect? >>> >>> I think I just got to the bottom of this: once an interrupt is queued in >>> an LR, we never look back. It will get delivered, no matter what, as >>> soon as the CPU interface is enabled, and regardless of the state of the >>> distributor. We should be able to retire an interrupt from there if it >>> is disabled. >>> >>> I have a patch for this, coming up after a few more test runs. >>> >> I may be missing some larger picture here, but shouldn't qemu set the >> cpsr to mask irqs and fiqs on the cpu and then the guest kernel should >> only unmask these when it's actually ready to handle interrupts and >> then a "spurious" irq shouldn't cause a kernel bug? I'm confused. > > I think you're confusing what appends at the CPU and GIC levels. > slightly less confused than that... > - As you just said, the CPU starts with interrupt masked. > - Soon enough, the GIC gets initialized (all interrupt lines disabled, > CPU interface enabled). > - Then, interrupts are unmasked at the CPU level. > > Normally, nothing should happen, as all interrupts are disabled (at the > distributor level). But if the host has already inserted an IRQ in a LR, > then this interrupt will fire as soon as the CPU clears its I bit, > irrespective of the distributor state. > > The fix is to honor the enable bits even for interrupts that are already > inserted in the CPU virtual control interface, by retiring them from the > LRs. > This I understand. What I think I confuse is that while you can take an irq exception on the cpu that comes from nowhere and everybody should be happy, if you actually ask the gic where it came from and you see it's from some device you assume is not enabled on the gic, then it's bad. You being the kernel. Correct? _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm
