mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Paolo Bonzini <pbonzini@redhat.com>
To: Roman Penyaev <roman.penyaev@profitbricks.com>,
	Mikhail Sennikovskii <mikhail.sennikovskii@profitbricks.com>,
	Gleb Natapov <gleb@kernel.org>,
	kvm@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC] KVM: SVM: do not drop VMCB CPL to 0 if SS is not present
Date: Tue, 30 May 2017 16:47:04 +0200	[thread overview]
Message-ID: <0155f13f-f65b-27a6-e646-44fffccbbf40@redhat.com> (raw)
In-Reply-To: <CAJrWOzD6Xq==b-zYCDdFLgSRMPM-NkNuTSDFEtX=7MreT45i7Q@mail.gmail.com>



On 19/05/2017 18:14, Roman Penyaev wrote:
> 2. A bit complicated, which makes sure the CPL field is preserved across
>    KVM_GET/SET_SREGS calls and makes svm_set_segment() and svm_get_segment()
>    functionality symmethric:

I think I prefer this solution.

>    KVM SVM side:
>    -------------
> 
>    --- a/arch/x86/kvm/svm.c
>    +++ b/arch/x86/kvm/svm.c
>    @@ -1999,7 +1999,7 @@ static void svm_set_segment(struct kvm_vcpu *vcpu,
>             * would entail passing the CPL to userspace and back.
>             */
>            if (seg == VCPU_SREG_SS)
>    -               svm->vmcb->save.cpl = (s->attrib >>
> SVM_SELECTOR_DPL_SHIFT) & 3;
>    +               svm->vmcb->save.cpl = (var->dpl & 3);
> 
>            mark_dirty(svm->vmcb, VMCB_SEG);
>    }

I wonder why svm_set_segment is setting s->attrib = 0 at all.  The 
manual only mentions checking P=0.  What about something like:

	s->base = var->base;
	s->limit = var->limit;
	s->selector = var->selector;
	s->attrib = (var->type & SVM_SELECTOR_TYPE_MASK);
	s->attrib |= (var->s & 1) << SVM_SELECTOR_S_SHIFT;
	s->attrib |= (var->dpl & 3) << SVM_SELECTOR_DPL_SHIFT;
	s->attrib |= (var->present && !var->unusable) << SVM_SELECTOR_P_SHIFT;
	s->attrib |= (var->avl & 1) << SVM_SELECTOR_AVL_SHIFT;
	s->attrib |= (var->l & 1) << SVM_SELECTOR_L_SHIFT;
	s->attrib |= (var->db & 1) << SVM_SELECTOR_DB_SHIFT;
	s->attrib |= (var->g & 1) << SVM_SELECTOR_G_SHIFT;

>    QEMU side:
>    ----------
> 
>    --- a/target/i386/kvm.c
>    +++ b/target/i386/kvm.c
>    @@ -1979,6 +1979,8 @@ static int kvm_get_sregs(X86CPU *cpu)
>         get_seg(&env->segs[R_FS], &sregs.fs);
>         get_seg(&env->segs[R_GS], &sregs.gs);
>         get_seg(&env->segs[R_SS], &sregs.ss);
>    +    if (sregs.ss.unusable)
>    +        env->segs[R_SS].flags |= sregs.ss.dpl << DESC_DPL_SHIFT;
> 
>         get_seg(&env->tr, &sregs.tr);
>         get_seg(&env->ldt, &sregs.ldt);

I think what QEMU should do is, in get_seg

	if (rhs->unusable) {
	    lhs->flags &= ~DESC_P_MASK;
	} else {
	    ...
	}

This would preserve the SS.DPL field.  This should still work fine with
QEMU commit 4cae9c9 (the loading side would set lhs->unusable).

Thanks,

Paolo

> 
> Current email is an RFC since for us is not fully clear is it really
> needed to preserve DPL across KVM_SET/GET_SREGS calls when segment
> is unusable.  E.g. there was a commit:
> 
> 4cae9c97967a ("target-i386: kvm: clear unusable segments' flags in migration")
> 
> which in purpose drops all segment flags to zero on QEMU side in order
> to fix guests migration.

  parent reply	other threads:[~2017-05-30 14:47 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-19 16:14 Roman Penyaev
2017-05-21  3:31 ` Andy Lutomirski
2017-05-21  7:53   ` Roman Penyaev
2017-05-21 20:19     ` Andy Lutomirski
2017-05-24 19:19       ` Roman Penyaev
2017-05-30 14:47 ` Paolo Bonzini [this message]
2017-05-30 17:35   ` Roman Penyaev
2017-05-30 21:09     ` Paolo Bonzini
2017-05-31 10:17       ` Roman Penyaev
2017-05-31 10:50         ` Paolo Bonzini
2017-05-30 15:13 ` Paolo Bonzini
2017-05-30 15:58   ` Roman Penyaev
2017-05-30 16:05     ` Paolo Bonzini
2017-05-30 16:31       ` Gi-Oh Kim
2017-06-15 21:44       ` Andy Lutomirski
2017-06-16  8:44         ` Roman Penyaev
2017-06-16 16:40         ` Paolo Bonzini

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=0155f13f-f65b-27a6-e646-44fffccbbf40@redhat.com \
    --to=pbonzini@redhat.com \
    --cc=gleb@kernel.org \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mikhail.sennikovskii@profitbricks.com \
    --cc=roman.penyaev@profitbricks.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

all inboxes | Powered by JetHome®