qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Christian Borntraeger <borntraeger@de.ibm.com>
To: Alexander Graf <agraf@suse.de>
Cc: Cornelia Huck <cornelia.huck@de.ibm.com>,
	Jens Freimann <jfrei@linux.vnet.ibm.com>,
	Heinz Graalfs <graalfs@linux.vnet.ibm.com>,
	qemu-devel <qemu-devel@nongnu.org>,
	Einar Lueck <elelueck@linux.vnet.ibm.com>
Subject: Re: [Qemu-devel] [PATCH] s390: use sync regs for register transfer
Date: Thu, 20 Sep 2012 17:21:50 +0200	[thread overview]
Message-ID: <505B348E.7010808@de.ibm.com> (raw)
In-Reply-To: <2101761A-84C3-4B1A-9C85-9176F5774196@suse.de>

On 20/09/12 16:13, Alexander Graf wrote:
> 
> 
> On 20.09.2012, at 14:49, Christian Borntraeger <borntraeger@de.ibm.com> wrote:
> 
>> [...]
>>>> --- a/target-s390x/kvm.c
>>>> +++ b/target-s390x/kvm.c
>>>> @@ -88,50 +88,77 @@ void kvm_arch_reset_vcpu(CPUS390XState *env)
>>>>    /* FIXME: add code to reset vcpu. */
>>>> }
>>>>
>>>> +/* we want to have the prefix, the GPRS, the ACRS and the CRS up to date */
>>>> +#define QEMU_NEEDED_REGS  (KVM_SYNC_PREFIX | KVM_SYNC_GPRS | \
>>>> +                         KVM_SYNC_ACRS   | KVM_SYNC_CRS)
>>>> +
>>>> +/* But qemu only changes the GPRS */
>>>> +#define QEMU_DIRTY_REGS  (KVM_SYNC_GPRS)
>>>> +
>>>> int kvm_arch_put_registers(CPUS390XState *env, int level)
>>>> {
>>>>    struct kvm_regs regs;
>>>>    int ret;
>>>>    int i;
>>>>
>>>> -    ret = kvm_vcpu_ioctl(env, KVM_GET_REGS, &regs);
>>>> -    if (ret < 0) {
>>>> -        return ret;
>>>> -    }
>>>> -
>>>> -    for (i = 0; i < 16; i++) {
>>>> -        regs.gprs[i] = env->regs[i];
>>>> -    }
>>>> -
>>>> -    ret = kvm_vcpu_ioctl(env, KVM_SET_REGS, &regs);
>>>> -    if (ret < 0) {
>>>> -        return ret;
>>>> -    }
>>>> -
>>>>    env->kvm_run->psw_addr = env->psw.addr;
>>>>    env->kvm_run->psw_mask = env->psw.mask;
>>>>
>>>> -    return ret;
>>>> +    if ((env->kvm_run->kvm_valid_regs & QEMU_NEEDED_REGS) == QEMU_NEEDED_REGS) {
>>>
>>> Isn't this also missing a check for KVM_CAP_SYNC_REGS?
>>
>> I ommitted the check for two reasons: 
>> - since kvm_check_extension is an ioctl by itself, this would counter the original idea of sync regs
>> - the kvm_run structure contains zeroes at the sync reg location in kernels that dont support that,
>>  (the area was unused and the page was allocated with GFP_ZERO) 
>>  So by having any of the kvm_valid_regs != 0 we know that SYNC REGS must be supported
> 
> But the spec explicitly says that the fields are only valid when the CAP is present. So if you think that is unnecessary, please patch the spec.

Maybe I should do both. Update the spec that the CAP defines if this is any
useful, if not it will start out with zeroes,but also having a single CAP check
during startup to have the code cleaner.

> The way we get around constant ioctls for cap checks is that we usually check only once and remember the result in a global variable. Please check other arch's kvm.c files for reference.

I looked for that in i386, but seems that only ppc does it. So I will look more
into ppc....

> 
>>
>>
>>> Also, on reset we probably also want to write the other registers back, right?
>>
>> Well, on reset we call the initial cpu reset ioctl, which does reset the other registers mandated
>> by a cpu reset. Furthermore, it is not different to the current implementation....
> 
> The difference is that get_registers fetches more registers, so not putting them looks awkward.

Yep, obviously the commenting was not enough to explain the why.
> 
>>
>> What we might want to do is to also consider a clear reset (which also zeroes the FPRs and ARs as
>> well as memory etc) as an additional option. But this should not be the default, e.g. to make
>> kdump or standalone dump possible.
>> I think this would then be an addon-patch by itself.
> 
> What does reset on normal systems look like? Does it clear register state?

A reset does not, a reset clear does.

But you just got me convinced, that we should really follow the level statement
for the put function and simply write everything for KVM_PUT_FULL_STATE and
KVM_PUT_RESET_STATE. The KVM_EXIT_S390_RESET handler must then do the right
thing (e.g. making sure that the general purpose register content for a
non-clear reset is not changed). Will look if that works out.

Christian

  reply	other threads:[~2012-09-20 15:22 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-08-22 11:54 [Qemu-devel] [PATCH] s390: use sync regs for register transfer Jens Freimann
2012-09-20 12:19 ` Alexander Graf
2012-09-20 12:49   ` Christian Borntraeger
2012-09-20 14:13     ` Alexander Graf
2012-09-20 15:21       ` Christian Borntraeger [this message]
  -- strict thread matches above, loose matches on Subject: below --
2012-10-03 20:08 [Qemu-devel] [PATCH 1/5] " Blue Swirl
2012-10-04  7:56 ` [Qemu-devel] [PATCH] " Jens Freimann

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=505B348E.7010808@de.ibm.com \
    --to=borntraeger@de.ibm.com \
    --cc=agraf@suse.de \
    --cc=cornelia.huck@de.ibm.com \
    --cc=elelueck@linux.vnet.ibm.com \
    --cc=graalfs@linux.vnet.ibm.com \
    --cc=jfrei@linux.vnet.ibm.com \
    --cc=qemu-devel@nongnu.org \
    /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).