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. M. -- Jazz is not dead. It just smells funny... _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm
