From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Jan Beulich <JBeulich@suse.com>,
xen-devel <xen-devel@lists.xenproject.org>
Cc: Paul Durrant <paul.durrant@citrix.com>
Subject: Re: [PATCH 4/4] x86emul: correct FPU code/data pointers and opcode handling
Date: Tue, 14 Mar 2017 10:56:47 +0000 [thread overview]
Message-ID: <5df81f70-4328-cd33-e28c-4cd0a1f458ed@citrix.com> (raw)
In-Reply-To: <58C68B25020000780014269F@prv-mh.provo.novell.com>
On 13/03/17 11:05, Jan Beulich wrote:
> @@ -1027,13 +1076,48 @@ do {
> static void put_fpu(
> struct fpu_insn_ctxt *fic,
> bool failed_late,
> + const struct x86_emulate_state *state,
> struct x86_emulate_ctxt *ctxt,
> const struct x86_emulate_ops *ops)
> {
> if ( unlikely(failed_late) && fic->type == X86EMUL_FPU_fpu )
> - ops->put_fpu(ctxt, X86EMUL_FPU_fpu);
> + ops->put_fpu(ctxt, X86EMUL_FPU_fpu, NULL);
> + else if ( unlikely(fic->type == X86EMUL_FPU_fpu) && !state->fpu_ctrl )
> + {
> + struct x86_emul_fpu_aux aux = {
> + .ip = ctxt->regs->r(ip),
> + .cs = ctxt->regs->cs,
> + .op = ((ctxt->opcode & 7) << 8) | state->modrm,
> + };
> + struct segment_register sreg;
> +
> + if ( ops->read_segment &&
> + ops->read_segment(x86_seg_cs, &sreg, ctxt) == X86EMUL_OKAY )
Why are the read_segment hooks optional here?
In the case that we are hitting FPU instructions for emulation, we can
reasonably require read/write_segment hooks.
In particular, regs->%sreg are only valid for PV guests.
> + aux.cs = sreg.sel;
> + if ( state->ea.type == OP_MEM )
> + {
> + aux.dp = state->ea.mem.off;
> + if ( ops->read_segment &&
> + ops->read_segment(state->ea.mem.seg, &sreg,
> + ctxt) == X86EMUL_OKAY )
> + aux.ds = sreg.sel;
> + else
> + switch ( state->ea.mem.seg )
> + {
> + case x86_seg_cs: aux.ds = ctxt->regs->cs; break;
> + case x86_seg_ds: aux.ds = ctxt->regs->ds; break;
> + case x86_seg_es: aux.ds = ctxt->regs->es; break;
> + case x86_seg_fs: aux.ds = ctxt->regs->fs; break;
> + case x86_seg_gs: aux.ds = ctxt->regs->gs; break;
> + case x86_seg_ss: aux.ds = ctxt->regs->ss; break;
> + default: ASSERT_UNREACHABLE(); break;
> + }
> + aux.dval = true;
> + }
> + ops->put_fpu(ctxt, X86EMUL_FPU_none, &aux);
> + }
> else if ( fic->type != X86EMUL_FPU_none && ops->put_fpu )
> - ops->put_fpu(ctxt, X86EMUL_FPU_none);
> + ops->put_fpu(ctxt, X86EMUL_FPU_none, NULL);
> }
>
> static inline bool fpu_check_write(void)
> @@ -4231,8 +4268,10 @@ x86_emulate(
> dst.bytes = 4;
> break;
> case 4: /* fldenv - TODO */
> + state->fpu_ctrl = true;
Arguably, state->fpu_ctrl is a decode property rather than an emulation
property. It is the kind of information which we might plausibly want
an x86_insn_*() accessor for.
~Andrew
> goto cannot_emulate;
> case 5: /* fldcw m2byte */
> + state->fpu_ctrl = true;
> if ( (rc = ops->read(ea.mem.seg, ea.mem.off, &src.val,
> 2, ctxt)) != X86EMUL_OKAY )
> goto done;
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
next prev parent reply other threads:[~2017-03-14 10:56 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-13 10:56 [PATCH 0/4] x86emul: FPU handling corrections Jan Beulich
2017-03-13 11:03 ` [PATCH 1/4] x86emul: fold exit paths Jan Beulich
2017-03-13 11:26 ` Andrew Cooper
2017-03-13 11:03 ` [PATCH 2/4] x86emul: centralize put_fpu() invocations Jan Beulich
2017-03-13 11:55 ` Andrew Cooper
2017-03-13 12:31 ` Jan Beulich
2017-03-13 11:05 ` [PATCH 3/4] x86emul: correct handling of FPU insns faulting on memory write Jan Beulich
2017-03-13 14:03 ` Andrew Cooper
2017-03-14 9:15 ` Tian, Kevin
2017-03-13 11:05 ` [PATCH 4/4] x86emul: correct FPU code/data pointers and opcode handling Jan Beulich
2017-03-14 9:21 ` Paul Durrant
2017-03-14 10:56 ` Andrew Cooper [this message]
2017-03-14 11:04 ` Jan Beulich
2017-03-13 11:07 ` [PATCH][XTF] add FPU/SIMD register state test Jan Beulich
2017-03-14 11:36 ` Andrew Cooper
2017-03-14 11:54 ` Jan Beulich
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=5df81f70-4328-cd33-e28c-4cd0a1f458ed@citrix.com \
--to=andrew.cooper3@citrix.com \
--cc=JBeulich@suse.com \
--cc=paul.durrant@citrix.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 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).