kvm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Christian Borntraeger <borntraeger@de.ibm.com>
To: Alexander Graf <agraf@suse.de>
Cc: Avi Kivity <avi@redhat.com>,
	Marcelo Tosatti <mtosatti@redhat.com>,
	KVM list <kvm@vger.kernel.org>,
	Cornelia Huck <cornelia.huck@de.ibm.com>,
	Jens Freimann <jfrei@linux.vnet.ibm.com>,
	Martin Schwidefsky <schwidefsky@de.ibm.com>,
	Heiko Carstens <heiko.carstens@de.ibm.com>,
	Carsten Otte <cotte@de.ibm.com>
Subject: Re: [PATCH 2/2]: kvm-s390: add KVM_S390_GET/SET_SREGS2 call for additional hw regs
Date: Wed, 21 Dec 2011 07:52:17 +0100	[thread overview]
Message-ID: <4EF18221.4090602@de.ibm.com> (raw)
In-Reply-To: <2AE8A2B7-06BB-4091-ACFE-1D42A7851F61@suse.de>

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


  reply	other threads:[~2011-12-21  6:52 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-12-20  9:38 [PATCH]: kvm-s390: add KVM_S390_GET/SET_SREGS2 call for additional hw regs Christian Borntraeger
2011-12-20  9:52 ` Avi Kivity
2011-12-20  9:59   ` Christian Borntraeger
2011-12-20 10:09     ` Avi Kivity
2011-12-20 11:40       ` [PATCH 1/2]: kvm-s390: use guest flush inline function Christian Borntraeger
2011-12-20 11:41       ` [PATCH 2/2]: kvm-s390: add KVM_S390_GET/SET_SREGS2 call for additional hw regs Christian Borntraeger
2011-12-20 14:20         ` Alexander Graf
2011-12-20 16:16           ` Christian Borntraeger
2011-12-20 16:28             ` Alexander Graf
2011-12-21  6:52               ` Christian Borntraeger [this message]
2011-12-21  7:10                 ` Alexander Graf

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4EF18221.4090602@de.ibm.com \
    --to=borntraeger@de.ibm.com \
    --cc=agraf@suse.de \
    --cc=avi@redhat.com \
    --cc=cornelia.huck@de.ibm.com \
    --cc=cotte@de.ibm.com \
    --cc=heiko.carstens@de.ibm.com \
    --cc=jfrei@linux.vnet.ibm.com \
    --cc=kvm@vger.kernel.org \
    --cc=mtosatti@redhat.com \
    --cc=schwidefsky@de.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).