From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>,
Xen-devel <xen-devel@lists.xen.org>
Cc: Kevin Tian <kevin.tian@intel.com>, Keir Fraser <keir@xen.org>,
Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>,
Eddie Dong <eddie.dong@intel.com>,
Jan Beulich <JBeulich@suse.com>,
Aravind Gopalakrishnan <Aravind.Gopalakrishnan@amd.com>,
Jun Nakajima <jun.nakajima@intel.com>
Subject: Re: [PATCH v2 5/6] x86/hvm: Forced Emulation Prefix for debug builds of Xen
Date: Tue, 23 Sep 2014 16:17:07 -0400 [thread overview]
Message-ID: <5421D543.8020600@oracle.com> (raw)
In-Reply-To: <5421BAA0.4050209@citrix.com>
On 09/23/2014 02:23 PM, Andrew Cooper wrote:
> On 23/09/14 19:20, Boris Ostrovsky wrote:
>> On 09/23/2014 12:09 PM, Andrew Cooper wrote:
>>> Analysis of XSAs 105 and 106 show that is possible to force a race
>>> condition
>>> which causes any arbitrary instruction to be emulated.
>>>
>>> To aid testing, explicitly introduce the Forced Emulation Prefix for
>>> debug
>>> builds alone.
>>>
>>> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
>>> CC: Keir Fraser <keir@xen.org>
>>> CC: Jan Beulich <JBeulich@suse.com>
>>> CC: Boris Ostrovsky <boris.ostrovsky@oracle.com>
>>> CC: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
>>> CC: Aravind Gopalakrishnan <Aravind.Gopalakrishnan@amd.com>
>>> CC: Jun Nakajima <jun.nakajima@intel.com>
>>> CC: Eddie Dong <eddie.dong@intel.com>
>>> CC: Kevin Tian <kevin.tian@intel.com>
>>>
>>> ---
>>> v2: (all suggested by Jan)
>>> * Use hvm_fetch_from_guest_virt_nofault() in preference to
>>> copy_from_guest()
>>> * Vastly reduce use of #ifndef NDEBUG
>>> ---
>>> docs/misc/xen-command-line.markdown | 11 +++++++++++
>>> xen/arch/x86/hvm/hvm.c | 5 +++++
>>> xen/arch/x86/hvm/svm/svm.c | 13 +++++++++++++
>>> xen/arch/x86/hvm/vmx/vmx.c | 13 +++++++++++++
>>> xen/include/asm-x86/hvm/hvm.h | 7 +++++++
>>> 5 files changed, 49 insertions(+)
>>>
>>> diff --git a/docs/misc/xen-command-line.markdown
>>> b/docs/misc/xen-command-line.markdown
>>> index af93e17..389701a 100644
>>> --- a/docs/misc/xen-command-line.markdown
>>> +++ b/docs/misc/xen-command-line.markdown
>>> @@ -682,6 +682,17 @@ Bit 11 - MSR operation logging
>>> Recognized in debug builds of the hypervisor only.
>>> +### hvm\_fep
>>> +> `= <boolean>`
>>> +
>>> +> Default: `false`
>>> +
>>> +Allow use of the Forced Emulation Prefix in HVM guests, to allow
>>> emulation of
>>> +arbitrary instructions.
>>> +
>>> +This option is intended for development purposes, and is only
>>> available in
>>> +debug builds of the hypervisor.
>>> +
>>> ### hvm\_port80
>>> > `= <boolean>`
>>> diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
>>> index 5c7e0a4..34f28d0 100644
>>> --- a/xen/arch/x86/hvm/hvm.c
>>> +++ b/xen/arch/x86/hvm/hvm.c
>>> @@ -86,6 +86,11 @@ unsigned long __attribute__ ((__section__
>>> (".bss.page_aligned")))
>>> static bool_t __initdata opt_hap_enabled = 1;
>>> boolean_param("hap", opt_hap_enabled);
>>> +#ifndef opt_hvm_fep
>>> +bool_t opt_hvm_fep;
>>> +boolean_param("hvm_fep", opt_hvm_fep);
>>> +#endif
>>> +
>>> static int cpu_callback(
>>> struct notifier_block *nfb, unsigned long action, void *hcpu)
>>> {
>>> diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
>>> index b6beefc..cda968b 100644
>>> --- a/xen/arch/x86/hvm/svm/svm.c
>>> +++ b/xen/arch/x86/hvm/svm/svm.c
>>> @@ -2118,6 +2118,19 @@ static void svm_vmexit_ud_intercept(struct
>>> cpu_user_regs *regs)
>>> struct hvm_emulate_ctxt ctxt;
>>> int rc;
>>> + if ( opt_hvm_fep )
>>> + {
>>> + char sig[5]; /* ud2; .ascii "xen" */
>>> +
>>> + if ( (hvm_fetch_from_guest_virt_nofault(
>>> + sig, regs->eip, sizeof(sig), 0) == HVMCOPY_okay) &&
>>> + (memcmp(sig, "\xf\xbxen", sizeof(sig)) == 0) )
>>> + {
>>> + regs->eip += sizeof(sig);
>>> + regs->eflags &= ~X86_EFLAGS_RF;
>>> + }
>>> + }
>> This code is exactly the same for SVM and VMX. Can it be factored out?
>>
>> -boris
> It can, and I considered that, but it would prevent optimising to
> nothing for non-debug builds. Given that it was a single simple if()
> statement, I chose not to.
What about an inline (or a macro)? It won't help with code size but is a
good thing from code maintainability point of vew.
-boris
next prev parent reply other threads:[~2014-09-23 20:17 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-23 15:03 [PATCH 0/6] HVM Emulation and trap injection fixes Andrew Cooper
2014-09-23 15:03 ` [PATCH 1/6] x86emul: fix SYSCALL/SYSENTER/SYSEXIT emulation Andrew Cooper
2014-09-23 15:03 ` [PATCH 2/6] x86/emulate: Provide further information about software events Andrew Cooper
2014-09-23 15:03 ` [PATCH 3/6] x86/hvm: Don't discard the SW/HW event distinction from the emulator Andrew Cooper
2014-09-25 20:57 ` Tian, Kevin
2014-09-26 20:12 ` Boris Ostrovsky
2014-09-23 15:03 ` [PATCH 4/6] x86/emulate: Support for emulating software event injection Andrew Cooper
2014-09-23 22:24 ` Aravind Gopalakrishnan
2014-09-24 9:22 ` Andrew Cooper
2014-09-24 13:01 ` Boris Ostrovsky
2014-09-24 13:04 ` Andrew Cooper
2014-09-24 13:24 ` Boris Ostrovsky
2014-09-24 14:20 ` Andrew Cooper
2014-09-26 20:13 ` Boris Ostrovsky
2014-09-26 21:09 ` Aravind Gopalakrishnan
2014-09-23 15:03 ` [PATCH 5/6] x86/hvm: Forced Emulation Prefix for debug builds of Xen Andrew Cooper
2014-09-23 15:27 ` Jan Beulich
2014-09-23 16:09 ` [PATCH v2 " Andrew Cooper
2014-09-23 16:21 ` Jan Beulich
2014-09-25 21:04 ` Tian, Kevin
2014-09-23 18:20 ` Boris Ostrovsky
2014-09-23 18:23 ` Andrew Cooper
2014-09-23 20:17 ` Boris Ostrovsky [this message]
2014-09-24 12:56 ` Andrew Cooper
2014-09-26 20:14 ` Boris Ostrovsky
2014-09-23 15:03 ` [PATCH 6/6] x86/svm: Misc cleanup Andrew Cooper
2014-09-26 20:15 ` Boris Ostrovsky
2014-09-23 15:19 ` [PATCH 0/6] HVM Emulation and trap injection fixes 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=5421D543.8020600@oracle.com \
--to=boris.ostrovsky@oracle.com \
--cc=Aravind.Gopalakrishnan@amd.com \
--cc=JBeulich@suse.com \
--cc=andrew.cooper3@citrix.com \
--cc=eddie.dong@intel.com \
--cc=jun.nakajima@intel.com \
--cc=keir@xen.org \
--cc=kevin.tian@intel.com \
--cc=suravee.suthikulpanit@amd.com \
--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 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).