On 21.12.2011, at 07:52, Christian Borntraeger wrote: > 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? They're in my queue. I'll have to go through a full set of tests and a few more applies before I'm sending it out again though. > >> >>> - 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. But you only need to read it from user space, right? So you can put a R/O version of it in the shared kvm_run struct or create your own MMIO mapping for shared values (which should be possible thanks to Carsten's patch set). That way you get almost 0 overhead from fetching the prefix register, but can use an extensible interface for registers that don't change that often and actually get an event (ioctl) in the kernel for prefix writes from user space, which should almost never occur. Alex -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
