All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Jan Beulich" <JBeulich@suse.com>
To: Razvan Cojocaru <rcojocaru@bitdefender.com>
Cc: andrew.cooper3@citrix.com, paul.durrant@citrix.com,
	Tim Deegan <tim@xen.org>,
	xen-devel@lists.xen.org
Subject: Re: [PATCH RFC] x86/emulate: implement hvmemul_cmpxchg() with an actual CMPXCHG
Date: Thu, 30 Mar 2017 08:21:21 -0600	[thread overview]
Message-ID: <58DD3081020000780014AB39@prv-mh.provo.novell.com> (raw)
In-Reply-To: <cf8f6b85-324d-73b1-4533-941ed9072e2c@bitdefender.com>

>>> On 30.03.17 at 16:08, <rcojocaru@bitdefender.com> wrote:
> On 03/30/2017 03:56 PM, Razvan Cojocaru wrote:
>> On 03/30/2017 03:05 PM, Jan Beulich wrote:
>>> What I do note though is that you don't copy back the value
>>> __cmpxchg() returns, yet that's what is needed. *map may
>>> have changed again already.
>> 
>> Changing the code to:
>> 
>> 1162     ret = __cmpxchg(map, old, new, bytes);
>> 1163
>> 1164     if ( ret != old )
>> 1165     {
>> 1166         memcpy(p_old, &ret, bytes);
>> 1167         rc = X86EMUL_CMPXCHG_FAILED;
>> 1168     }
>> 
>> where ret is an unsigned long still triggers BSODs when I add my patch
>> to yours. I'll need to dig deeper.
> 
> Nevermind, I've found the culprit: hvm_emulate_one_vm_event()'s code
> needs to be wrapped in a loop that checks for X86EMUL_RETRY again, since
> hvmemul_cmpxchg() may return RETRY even for some mapping problems, in
> which case we again end up with the guest trying to re-execute an
> emulable CMPXCHG.

This seems wrong to me - note how my patch changes behavior
regarding the return value from paging_cmpxchg_guest_entry()
in ptwr_emulated_update().

> However, this gets me back to my original problem when I "solved" it in
> the same manner (looping until emulation succeeds) back when
> hvmemul_cmpxchg() failures were reported with RETRY: eventually the
> guest BSODs with code 101. RETRY failures are still possible coming from
> the hvmemul_vaddr_to_mfn() code in my patch.
> 
> I wonder if I should just return X86EMUL_CMPXCHG_FAILED for all those as
> well and just never end up returning RETRY from hvmemul_cmpxchg().

That would seem similarly wrong to me - it ought to be
UNHANDLEABLE, I would think. In any event, never returning
RETRY would also be wrong in case you hit emulated MMIO, but
that's really the only case where RETRY should be passed back.

Jan


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

  reply	other threads:[~2017-03-30 14:21 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-24 13:24 [PATCH RFC] x86/emulate: implement hvmemul_cmpxchg() with an actual CMPXCHG Razvan Cojocaru
2017-03-28  9:14 ` Razvan Cojocaru
2017-03-28 10:03   ` Jan Beulich
2017-03-28 10:25     ` Andrew Cooper
2017-03-28 10:44       ` Jan Beulich
2017-03-29  5:59       ` Jan Beulich
2017-03-29  8:14         ` Razvan Cojocaru
2017-03-28 10:27     ` Razvan Cojocaru
2017-03-28 10:47       ` Jan Beulich
2017-03-28 10:50         ` Razvan Cojocaru
2017-03-28 11:32           ` Jan Beulich
2017-03-29 13:55           ` Jan Beulich
2017-03-29 14:00             ` Razvan Cojocaru
2017-03-29 15:04               ` Razvan Cojocaru
2017-03-29 15:49                 ` Razvan Cojocaru
2017-03-30 12:05                   ` Jan Beulich
2017-03-30 12:25                     ` Razvan Cojocaru
2017-03-30 12:56                     ` Razvan Cojocaru
2017-03-30 14:08                       ` Razvan Cojocaru
2017-03-30 14:21                         ` Jan Beulich [this message]
2017-03-30 15:05                           ` Razvan Cojocaru
2017-03-30 15:47                             ` Jan Beulich
2017-03-31  6:17                               ` Razvan Cojocaru
2017-03-31  7:34                                 ` Jan Beulich
2017-03-31  9:56                                   ` Razvan Cojocaru
2017-03-31 14:46                                     ` Jan Beulich
2017-03-31 15:01                                       ` Razvan Cojocaru
2017-03-31 15:04                                         ` Jan Beulich
2017-04-01 16:56                                           ` Razvan Cojocaru
2017-04-03 10:23                                             ` Jan Beulich
2017-04-03 18:20                                             ` Razvan Cojocaru
2017-04-03 18:36                                               ` Razvan Cojocaru
2017-04-04  9:07                                                 ` Jan Beulich
2017-04-04 12:01                                                   ` Razvan Cojocaru
2017-04-08 22:15                                                 ` Razvan Cojocaru
2017-04-09 11:03                                                   ` Razvan Cojocaru
2017-04-10 10:18                                                   ` Jan Beulich
2017-03-29 14:12             ` Razvan Cojocaru

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=58DD3081020000780014AB39@prv-mh.provo.novell.com \
    --to=jbeulich@suse.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=paul.durrant@citrix.com \
    --cc=rcojocaru@bitdefender.com \
    --cc=tim@xen.org \
    --cc=xen-devel@lists.xen.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.