On 12/22/2011 03:17 PM, Christian Borntraeger wrote: > On 22/12/11 13:54, Avi Kivity wrote: > >> My main concern was the prefix register (this is a per cpu register that > >> defines the address of two pages that are swapped with the pages at 0 for this cpu). > >> SMP on s390 is done that way (e.g. interrupt things are stored in page 0 for this cpu) > >> The storage that qemu sees is storage without prefix. For architecture compliance > >> we actually must check _every_ memory access if it hits the prefix/swpa area and > >> the add/subtract the prefix value. > > > > Those are only memory accesses coming from the cpu, yes? Why does > > userspace have to access them at all? I imagine DMA ignores it > > completely since it doesn't come from the cpu. > > Not sure if I got you question...(just ask again if that doesnt aswer it) > > The prefix page contains HW-defined content (like the PSWs for the different > interrupt types) as well as some OS-defined values (for CPU local data structures > as well as a place to store information in critical sections) > The prefix page (and the swap area) must not be used for device I/O (since it will > be broken as you pointed out), but some I/O instructions can and will write status > information to the prefix page. For example the channel subsystem driver in Linux > will use an area in the prefix page as a store address for some instructions. > > So let me phrase the above sentence differently: > For architecture compliance we actually must check every memory access that is done > on behalf of a guest cpu and was not already handled by the host kernel. "on behalf of the guest cpu" is the key phrase. This never happens in userspace for x86, but I guess that s390 is different here. Thanks for the clarification. -- error compiling committee.c: too many arguments to function -- 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
