xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Jan Beulich <JBeulich@suse.com>,
	Mukesh Rathor <mukesh.rathor@oracle.com>
Cc: xen-devel <xen-devel@lists.xenproject.org>,
	boris.ostrovsky@oracle.com, Aravind.Gopalakrishnan@amd.com,
	suravee.suthikulpanit@amd.com
Subject: Re: [RFH]: AMD CR intercept for lmsw/clts
Date: Tue, 05 Aug 2014 12:16:16 +0100	[thread overview]
Message-ID: <53E0BD00.8010602@citrix.com> (raw)
In-Reply-To: <53E0A7EC02000078000294FF@mail.emea.novell.com>

On 05/08/2014 08:46, Jan Beulich wrote:
>>>> On 05.08.14 at 03:33, <mukesh.rathor@oracle.com> wrote:
>> Hi,
>>
>> On AMD, clts/lmsw will cause "mov cr" vmexit, but unlike intel, they
>> can't be handled via svm_vmexit_do_cr_access and are emulated thru
>> handle_mmio() which is a problem for pvh because of:
>>
>> handle_mmio():
>> ..
>>     ASSERT(!is_pvh_vcpu(curr));
>>
>> AMD CR intercepts in svm.c:
>>     case VMEXIT_CR0_READ ... VMEXIT_CR15_READ:
>>     case VMEXIT_CR0_WRITE ... VMEXIT_CR15_WRITE:
>>         if ( cpu_has_svm_decode && (vmcb->exitinfo1 & (1ULL << 63)) )
>>             svm_vmexit_do_cr_access(vmcb, regs);
>>         else if ( !handle_mmio() )     <==========
>>             hvm_inject_hw_exception(TRAP_gp_fault, 0);
>>     break;
>>
>> Soooo, this leaves no choice but to make the ASSERT conditional
>> for intel only, and let handle_mmio go thru x86_emulate and let
>> x86_emulate fail for anything other than lmsw/clts? I was thinking
>> something like:
>>
>> x86_emulate()
>>   int fail_pvh_emul = 1;
>>   ...
>>   case lmsw/clts:
>>      .....
>>      fail_pvh_emul = 0;
>>
>> then
>>  done:
>>      if (fail_pvh_emul)
>>          rc = X86EMUL_UNHANDLEABLE;
>>      return rc;
> I'd strongly recommend against adding any such to x86_emulate():
> There's nothing precluding the emulator to be used for PVH guests.
>
>> Or, should I just create a new function for clts/lmsw and call it
>> directly from vmexit switch itself?
> I'd prefer this - it seems pretty ugly to me that handle_mmio()/
> x86_emulate() gets used for this purpose - but am not certain this
> will actually work out nicely for other than CLTS: All the
> instructions currently handled specially are ones with fixed
> operands, and only CLTS fits that.
>
> You'll btw have the same problem with SMSW and DRx accesses,
> string I/O instructions, as well as (on older CPUs) with moves to/from
> CRx and INVLPG.

SMSW certainly, but what is wrong with the others?  For those, the exit
info appears to give fully decoded information.

> In the case this doesn't turn out reasonable, rather than
> manipulating handle_mmio() any further, I'd suggest to investigate
> bypassing that function in favor of a more direct access to the x86
> emulator. After all you're not after any MMIO emulation here, just
> bare instructions (many of which without memory operands at all).

In the AMD System manual (vol 2), there are special cases listed for
lmsw, clts and smsw in section 15.8.1.  In each case, bit 63 of
exitinfo1 will be clear (which is checked using magic numbers in the
code).  It would appear that under these circumstances, the only
information provided is "it wasn't a mov instruction".  As a result, I
think x86_emulate() is the best way go to, rather than hacking something
up locally, although I would agree that handle_mmio() is not really
appropriate.

~Andrew

  reply	other threads:[~2014-08-05 11:16 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-05  1:33 [RFH]: AMD CR intercept for lmsw/clts Mukesh Rathor
2014-08-05  7:46 ` Jan Beulich
2014-08-05 11:16   ` Andrew Cooper [this message]
2014-08-05 12:11     ` Jan Beulich
2014-08-05 13:00       ` Andrew Cooper
2014-08-05 13:15         ` Jan Beulich
2014-08-05 22:30         ` Mukesh Rathor
2014-08-06  9:34           ` Andrew Cooper
2014-08-15 21:04             ` Konrad Rzeszutek Wilk
2014-08-15 21:48               ` Andrew Cooper
2014-08-05 22:22   ` Mukesh Rathor

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=53E0BD00.8010602@citrix.com \
    --to=andrew.cooper3@citrix.com \
    --cc=Aravind.Gopalakrishnan@amd.com \
    --cc=JBeulich@suse.com \
    --cc=boris.ostrovsky@oracle.com \
    --cc=mukesh.rathor@oracle.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 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).