On 21 June 2012 23:25, Christoffer Dall <c.dall at virtualopensystems.com> wrote: > On Thu, Jun 21, 2012 at 5:29 PM, Peter Maydell <peter.maydell at linaro.org> wrote: >> On 21 June 2012 21:58, Christoffer Dall <c.dall at virtualopensystems.com> wrote: >>> I think we would want to support migration as a general concept, but >>> probably not between non-kvm accelerated qemu environments and >>> accelerated ones. >> >> I think conceptually it is supposed to work to migrate between >> KVM and TCG (emulated) QEMU. Basically the kernel should provide >> the ABI[*] for reading/writing the GIC state, and QEMU then marshalls >> that into a state struct that is shared between its in-kernel-GIC >> and emulated-GIC models. > > does anybody use this? are anyone going to? is it even tested? Well, the QEMU code shares a state structure already (it was the obvious way to implement it, matching x86), and you need to provide a load/save state function in the kernel anyhow. My point is really "don't design things to rule it out". >> [*] some variation on the read-write-many-regs stuff that I think >> Rusty said he was going to look into, I would suggest. >> > > how would that work? represent the GIC registers as pseudo registers > as part of the CP15 registers, or...? The idea is that the API includes a (subsystem,register-number) tuple, so the copro registers live in one subsystem, and the GIC registers would all be in another. This means we have one consistent API for "does the kernel know about these registers?", "read them", "write them", and we don't have to export lots of structures and manage adding new fields to them. >> The out-of-kernel GIC model does implement interrupt priorities, >> and the priority registers are part of the state. But I think that >> the way we'd handle that is that save/restore would determine that >> the kernel didn't provide the priority registers and would just >> accept that it couldn't set them. Or if the kernel provided >> registers that read-as-written but don't have any effect, we could >> just save and restore the state into those. > > I just don't think we should keep this state around if we don't use > it, but then it all of the sudden may have an effect if migrated to > QEMU. > > If I understand correctly, the reason we don't have to deal with it is > the fact that the guests we run (so far) sets all the priorities to > the same value, so we can just ignore the fields, and return that same > value to user space. > > On the other hand, if we were to return real values as written, I > think we should actually respect these values when deciding whether or > ?wnot to forward the interrupts to the vcpu interface through the list > registers. reads-as-written is just as valid a dummy implementation as writes-ignored. As soon as you get into not behaving the same way the hardware does, you're in the world of "does it happen to work OK for the guests I happen to care about running, is it convenient to implement". > (What I really want to avoid is that some things seem to work > correctly, but then happens to work differently on QEMU all of the > sudden, because the guest kernel was updated to use interrupt > priorities, but KVM never complains...) If you want to avoid that you need to actually implement priorities. Or throw an undef into the guest if it tries to write the priority registers to something other than the defaults. Choosing to only partially implement the functionality of a device is inherently choosing that things might explode if a guest attempts to use the things you left out. -- PMM
