On 20/12/11 17:28, Alexander Graf wrote: >>> Would it make sense to instead use the GET_ONE_REG and SET_ONE_REG >>> interfaces? >>> >>> http://permalink.gmane.org/gmane.comp.emulators.kvm.devel/80854
What is the status of these patches? > >> - Is the interface limited to 56 registers? (see the ID) > > Uh. It's limited to 0x0fffffffffffffff registers per architecture :). Yes, I see. > Do you expect the prefix register to be synced often? If so, then you should > maybe put it into kvm_struct > and always have it shared between kernel and user space, always updating it > on every user space exit > and entry (you can optimize by checking if it changed). > > I don't think user space should worry about prefix too often though. Unless > you expect anyone to DMA > into the CPU prefix area :). In theory: To be architecture compliant we actually must check for _every_ memory access to the guest if it is 0 < address < 8192 or prefix < address < prefix+8192 and swap that. Usually this should not not happen very often, but you dont know until you check. As of today: Only a small part of the guest OS actually touches the lowcore and current KVM guests never cause exits to qemu that have to deal with such an case - it was handled by SIE or by the host kernel - so not a problem. Future: Additional components and non-para-virtualized I/O will pass addresses in the prefix pages to some instructions that qemu might have to handle, so we might need that more often. To play safe, we might want to do the prefix translation for all handled intercepts. Then we would need the prefix value almost always. Christian -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
