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. Will userspace be able to rely on everything exposed via the cp15 interface being simple save-and-restoreable state? (ie for odd cases like the CCSIDRs we provide access only via the demux, and not also as an entry in the main cp15 index space which accesses the current CCSIDR). What I'm getting at is, should it be in theory possible to do VM migration via a userspace implementation that looks like: * get the list of all supported registers * get the value of all those registers * stream the (index,value) tuples over the wire * on the receiving side, write all the values to the kernel where we don't have any knowledge in userspace at all about the meaning/semantics of the registers we are save/loading. (assuming for the moment that there is no mismatch between the two kernels about which registers are implemented...that is a different can of worms which I may open tomorrow.) ...or do we say that there might be special cases where userspace needs to handle certain registers in a specific way? (for example if the "acts like hardware" CCSIDR is exposed to userspace we need to know not to write to it because we don't know which particular cache ID register will get written by that access). -- PMM _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm
