From: Keir Fraser <keir.xen@gmail.com>
To: "Dong, Eddie" <eddie.dong@intel.com>, Jan Beulich <JBeulich@suse.com>
Cc: Aravindh Puthiyaparambil <aravindh@virtuata.com>,
"Nakajima, Jun" <jun.nakajima@intel.com>,
xen-devel <xen-devel@lists.xen.org>
Subject: Re: [PATCH] vmx: Allow software (user defined) interrupts to be injected in to the guest
Date: Thu, 03 May 2012 15:35:36 +0100 [thread overview]
Message-ID: <CBC85648.323C3%keir.xen@gmail.com> (raw)
In-Reply-To: <A12AC9D104E08D47BAF23C492F83C53B23B4A6A2@SHSMSX102.ccr.corp.intel.com>
On 03/05/2012 14:42, "Dong, Eddie" <eddie.dong@intel.com> wrote:
>>> The TRAP_debug should not use SW_EXCEPTION, it should use
>> HW_EXCEPTION
>>> Per SDM and confirmation from our HW guys. We will send fixes soon.
>>
>> Please also have the opcode 0xF1 generated #DB addressed in
>> whatever is the appropriate way.
>
> Opcode 0xf1 should use " privileged software exception".
>
> What we can do probably include:
> 1: A patch to fix the mistake of #BP & #OF, plus additional comments to state
> the usage of the API.
> 2: Another patch to provide a new API for 0xf1 & CD nn? But we don't have real
> usage case to test so far.
Yes, this sounds great.
-- Keir
> We will provide #1 quickly, but for #2, can Aravindh provide test if we get
> the patch ready?
>
>>
>>>>
>>>> Anyone except perhaps LOCK - none of them should have any effect
>>>> other than making the instruction longer.
>>>>
>>> LOCK can never be used as prefix of INT nn instruction, nor can REPx
>> prefix.
>>> Can you provide more details as for this concern?
>>
>> The only prefix that is documented to cause #UD here is LOCK. All
>
> In #UD case (fault), the guest RIP is not advanced per SDM, and therefore
> guest will either
> spin in the previous LOCK instruction, or advance the IP to next instruction
> by guest #UD handler.
> I didn't see emulator could advance IP to the next instruction (INT nn) for
> LOCK prefix.
> Do I miss something?
>
>> other prefixes should consequently be considered ignored, and so
>> should the emulation do (and properly handle resulting instruction
>> lengths).
>>
> The behavior is un-defined per SDM in this case, so either solution should be
> fine :)
>
> Thx, Eddie
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
next prev parent reply other threads:[~2012-05-03 14:35 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-04-20 5:04 [PATCH] vmx: Allow software (user defined) interrupts to be injected in to the guest Aravindh Puthiyaparambil
2012-04-20 8:54 ` Jan Beulich
2012-04-20 10:12 ` Keir Fraser
2012-05-02 8:53 ` Dong, Eddie
2012-05-02 9:23 ` Jan Beulich
2012-05-03 0:25 ` Dong, Eddie
2012-05-03 1:55 ` Aravindh Puthiyaparambil
2012-05-03 5:02 ` Dong, Eddie
2012-05-03 9:26 ` Jan Beulich
2012-05-03 13:42 ` Dong, Eddie
2012-05-03 14:17 ` Jan Beulich
2012-05-03 14:35 ` Keir Fraser [this message]
2012-05-03 18:15 ` Aravindh Puthiyaparambil
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=CBC85648.323C3%keir.xen@gmail.com \
--to=keir.xen@gmail.com \
--cc=JBeulich@suse.com \
--cc=aravindh@virtuata.com \
--cc=eddie.dong@intel.com \
--cc=jun.nakajima@intel.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).