Peter Maydell <peter.maydell@xxxxxxxxxx> writes: > 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). Yes. > > 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. Absolutely. This is why I dislike Avi's original API suggestion which contained the concept of read-only registers: we don't have those, only registers which you can *currently* only write one possible value to. If you think of some case where this isn't possible, please share! Cheers, Rusty. _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm
