All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Jan Beulich" <JBeulich@suse.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>
Cc: Juergen Gross <jgross@suse.com>,
	xen-devel <xen-devel@lists.xenproject.org>,
	Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
Subject: Re: [PATCH v2 1/2] SVM: re-work VMCB sync-ing
Date: Wed, 02 May 2018 01:11:39 -0600	[thread overview]
Message-ID: <5AE964AB02000078001BFEF1@prv1-mh.provo.novell.com> (raw)
In-Reply-To: <858c4aeb-4aa0-a7bd-19f3-e4922dbbd5ba@oracle.com>

>>> On 30.04.18 at 19:50, <boris.ostrovsky@oracle.com> wrote:
> On 04/30/2018 01:07 PM, Andrew Cooper wrote:
>> On 30/04/18 12:37, Jan Beulich wrote:
>>> While the main problem to be addressed here is the issue of what so far
>>> was named "vmcb_in_sync" starting out with the wrong value (should have
>>> been true instead of false, to prevent performing a VMSAVE without ever
>>> having VMLOADed the vCPU's state), go a step further and make the
>>> sync-ed state a tristate: CPU and memory may be in sync or an update
>>> may be required in either direction. Rename the field and introduce an
>>> enum. Callers of svm_sync_vmcb() now indicate the intended new state
>>> (with a slight "anomaly" when requesting VMLOAD: we could store
>>> vmcb_needs_vmsave in those cases as the callers request, but the VMCB
>>> really is in sync at that point, and hence there's no need to VMSAVE in
>>> case we don't make it out to guest context), and all syncing goes
>>> through that function.
>>>
>>> With that, there's no need to VMLOAD the state perhaps multiple times;
>>> all that's needed is loading it once before VM entry.
>>>
>>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>>> ---
>>> v2: Also handle VMLOAD in svm_sync_vmcb(). Add comment to enum
>>>     vmcb_sync_state.
>> -1 from me.  This is even more confusing to use than v1.
>>
>> It is not obvious at all that using svm_sync_vmcb(v, vmcb_needs_vmsave);
>> means "vmload", and its actively wrong that the state doesn't remain
>> in-sync.
> 
> It does become in-sync:
> 
> 
> +    if ( new_state == vmcb_needs_vmsave )
> +    {
> +        ASSERT(arch_svm->vmcb_sync_state == vmcb_needs_vmload);
> +        svm_vmload(arch_svm->vmcb);
> +        arch_svm->vmcb_sync_state = vmcb_in_sync;
> +    }
> +    else
> 
> (although Jan is questioning whether to drop that change in the comments to 
> patch 2, if I understood him correctly)

Indeed - in patch 2 this could be made go away. Hence the posting of patch 2
at this point in time in the first place (otherwise I would have waited until 4.12
has opened).

In any event - I need some sort of indication of a way forward here.

Jan



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

  reply	other threads:[~2018-05-02  7:11 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-30 10:17 [PATCH v2 0/2] SVM: guest state handling adjustments Jan Beulich
2018-04-30 11:37 ` [PATCH v2 1/2] SVM: re-work VMCB sync-ing Jan Beulich
2018-04-30 15:30   ` Boris Ostrovsky
2018-04-30 15:50     ` Jan Beulich
2018-04-30 15:56       ` Boris Ostrovsky
2018-04-30 16:01         ` Jan Beulich
2018-04-30 17:07   ` Andrew Cooper
2018-04-30 17:50     ` Boris Ostrovsky
2018-05-02  7:11       ` Jan Beulich [this message]
2018-05-02 14:45         ` Boris Ostrovsky
2018-05-03 14:43           ` Jan Beulich
2018-05-03 18:34             ` Boris Ostrovsky
2018-04-30 11:37 ` [PATCH v2 2/2] SVM: introduce a VM entry helper Jan Beulich
2018-04-30 11:51   ` Andrew Cooper

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=5AE964AB02000078001BFEF1@prv1-mh.provo.novell.com \
    --to=jbeulich@suse.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=boris.ostrovsky@oracle.com \
    --cc=jgross@suse.com \
    --cc=suravee.suthikulpanit@amd.com \
    --cc=xen-devel@lists.xenproject.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.