On 21 August 2012 03:07, Rusty Russell <rusty.russell@xxxxxxxxxx> wrote: > We still want to implement it to save the state. That's been the theory > so far: save everything, even if it's not fungible today. > > To be concrete, for CSSELR/CSSIDR, we define a new coproc index: > > #define KVM_ARM_MSR_CSSIDR_DEMUX 0x20 > > Then we use the bottom 4 bits of the CSSELR to index into this, > eg. 0x0020 0x0000 gives the CCSIDR when CSSELR == 0. If you agree, I'll > patch it. Yes, I think that makes sense. (We might want to make 0x0020 0xXXXX be more than just the CCSIDRs, it seems quite a large chunk of the space to give to just 16 registers. I don't think that would affect anything except what name you give the #define <something> 0x20.) > For performance monitors, yes, they are turned off and on in weird ways > (PMCNTENSET/PMCNTENCLR). I can't quite see why it is this way? Is it > to avoid having to do a read/write cycle to flip a single counter? > > I think here we'd not expose the PMCNTENCLR reg, as it's implied by the > PMCNTENSET reg, *and* we'd write absolute ON/OFF values rather than the > 0-is-ignored stuff. Also makes sense. Note that this means that you might end up with one access function for the guest doing a read/write and another one for qemu userspace doing a read/write. The other case I've run into where the guest and qemu access functions might need to be different is the TEEHBR, which has an access restriction on it that it isn't accessible by PL0 if the TEECR bit 0 is set. Obviously you don't want to apply access restrictions to qemu's save/load accesses. Whether that actually requires a second access function in the kernel depends on whether we're implementing the register as 'set value on guest entry/exit' rather than trapping guest accesses, though. I haven't looked at what we're doing with this register at the moment. (The perf counter registers also have similar access-permission checks that you wouldn't want to do for the qemu accesses.) I also haven't yet thought much about how to save/load the cp15 timer state (generic timer). I guess we would want to have userspace save/load the current value of the CNTVCT virtual count register, and actually implement that by having the kernel change the value of the underlying CNTVOFF virtual offset register (so when you restore on a host where the physical timer count is obviously going to be different from when you saved, the guest sees the same resulting virtual count.) My other headache is what to do with constant registers, where at the moment QEMU assumes they're constant and generally doesn't include them in the migration state, but on the other hand if we want to do migration to a heterogenous cpu we need to save/load them. But I think that's more my headache than a kernel one. (Can you remember if we ever discussed what we were going to do with constant regs?) -- PMM _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm
