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... -- PMM _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm
