Re: [patch 0/3] RFC: provide synchronous registers in kvm_run

[Avi Kivity <avi@redhat.com>]

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