Xen-Devel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Ed White <edmund.h.white@intel.com>, xen-devel@lists.xen.org
Cc: Ravi Sahita <ravi.sahita@intel.com>,
	Wei Liu <wei.liu2@citrix.com>, Tim Deegan <tim@xen.org>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	Jan Beulich <jbeulich@suse.com>,
	tlengyel@novetta.com, Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: Re: [PATCH v2 05/12] VMX/altp2m: add code to support EPTP switching and #VE.
Date: Wed, 24 Jun 2015 18:40:55 +0100	[thread overview]
Message-ID: <558AEBA7.1090600@citrix.com> (raw)
In-Reply-To: <558AE985.3000500@intel.com>

On 24/06/15 18:31, Ed White wrote:
> On 06/24/2015 04:59 AM, Andrew Cooper wrote:
>>> +
>>> +    if ( !veinfo )
>>> +        return 0;
>>> +
>>> +    if ( veinfo->semaphore != 0 )
>>> +        goto out;
>> The semantics of this semaphore are not clearly spelled out in the
>> manual.  The only information I can locate concerning this field is in
>> note in 25.5.6.1 which says:
>>
>> "Delivery of virtualization exceptions writes the value FFFFFFFFH to
>> offset 4 in the virtualization-exception informa-
>> tion area (see Section 25.5.6.2). Thus, once a virtualization exception
>> occurs, another can occur only if software
>> clears this field."
>>
>> I presume this should be taken to mean "software writes 0 to this
>> field", but some clarification would be nice.
>>
> Immediately above that, where the conditions required to deliver #VE
> are discussed, it says "the 32 bits at offset 4 in the
> virtualization-exception information area are all 0". Hardware never
> writes anything other than FFFFFFFFH there, so only software can make
> that be so.

So it does.  Sorry for missing that.

>
>>> +
>>> +            if ( !p2m_find_altp2m_by_eptp(v->domain, eptp, &idx) )
>>> +            {
>>> +                gdprintk(XENLOG_ERR, "EPTP not found in alternate p2m list\n");
>>> +                domain_crash(v->domain);
>>> +            }
>>> +        }
>>> +
>> Is it worth checking that idx is plausible at this point, before blindly
>> writing it back into the vcpu structure?
> I'm not sure I follow your logic. In the case where the hardware supports
> EPTP_INDEX, the hardware itself is asserting that the index is valid. In the
> case quoted above, if the index isn't valid p2m_find_altp2m_by_eptp() will
> fail.

I tend to be somewhat more pessimistic when coding.

It is possible for __vmread(EPTP_INDEX, &idx); to return any index
between 0 and 511 (including some other software bug which has gone and
accidentally set of altp2m 11).

I would put a BUG_ON(idx >= MAX_ALTP2M) here just for safety.  Nothing
good can come of attempting to continue in such a state, but it is
certainly not an impossible situation to get into.

~Andrew

  reply	other threads:[~2015-06-24 17:40 UTC|newest]

Thread overview: 116+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-22 18:56 [PATCH v2 00/12] Alternate p2m: support multiple copies of host p2m Ed White
2015-06-22 18:56 ` [PATCH v2 01/12] VMX: VMFUNC and #VE definitions and detection Ed White
2015-06-24  8:45   ` Andrew Cooper
2015-06-22 18:56 ` [PATCH v2 02/12] VMX: implement suppress #VE Ed White
2015-06-24  9:35   ` Andrew Cooper
2015-06-29 14:20   ` George Dunlap
2015-06-29 14:31     ` Andrew Cooper
2015-06-29 15:03       ` George Dunlap
2015-06-29 16:21         ` Sahita, Ravi
2015-06-29 16:21         ` Ed White
2015-06-22 18:56 ` [PATCH v2 03/12] x86/HVM: Hardware alternate p2m support detection Ed White
2015-06-24  9:44   ` Andrew Cooper
2015-06-24 10:07     ` Jan Beulich
2015-06-22 18:56 ` [PATCH v2 04/12] x86/altp2m: basic data structures and support routines Ed White
2015-06-24 10:06   ` Andrew Cooper
2015-06-24 10:23     ` Jan Beulich
2015-06-24 17:20     ` Ed White
2015-06-24 10:29   ` Andrew Cooper
2015-06-24 11:14     ` Andrew Cooper
2015-06-26 21:17     ` Ed White
2015-06-27 19:25       ` Ed White
2015-06-29 13:00       ` Andrew Cooper
2015-06-29 16:23         ` Ed White
2015-06-24 14:44   ` Jan Beulich
2015-06-22 18:56 ` [PATCH v2 05/12] VMX/altp2m: add code to support EPTP switching and #VE Ed White
2015-06-24 11:59   ` Andrew Cooper
2015-06-24 17:31     ` Ed White
2015-06-24 17:40       ` Andrew Cooper [this message]
2015-06-22 18:56 ` [PATCH v2 06/12] VMX: add VMFUNC leaf 0 (EPTP switching) to emulator Ed White
2015-06-24 12:47   ` Andrew Cooper
2015-06-24 20:29     ` Ed White
2015-06-25  8:26       ` Jan Beulich
2015-06-24 14:26   ` Jan Beulich
2015-06-22 18:56 ` [PATCH v2 07/12] x86/altp2m: add control of suppress_ve Ed White
2015-06-24 13:05   ` Andrew Cooper
2015-06-24 14:38   ` Jan Beulich
2015-06-24 17:53     ` Ed White
2015-06-25  8:12       ` Jan Beulich
2015-06-25 16:36         ` Ed White
2015-06-26  6:04           ` Jan Beulich
2015-06-26 16:27             ` Ed White
2015-07-06 17:12               ` George Dunlap
2015-07-06 17:35                 ` Ed White
2015-07-06 18:29                   ` George Dunlap
2015-07-06 18:43                     ` Ed White
2015-07-07 10:10                       ` George Dunlap
2015-07-07 16:24                         ` Ed White
2015-07-07 17:33                           ` George Dunlap
2015-07-07 17:38                             ` Sahita, Ravi
2015-07-08  7:24                               ` Jan Beulich
2015-07-08 10:12                               ` Tim Deegan
2015-07-08 12:51                                 ` George Dunlap
2015-07-08  7:23                           ` Jan Beulich
2015-07-07  8:04                     ` Jan Beulich
2015-06-22 18:56 ` [PATCH v2 08/12] x86/altp2m: alternate p2m memory events Ed White
2015-06-24 13:09   ` Andrew Cooper
2015-06-24 16:01   ` Lengyel, Tamas
2015-06-24 18:02     ` Ed White
2015-06-22 18:56 ` [PATCH v2 09/12] x86/altp2m: add remaining support routines Ed White
2015-06-23 18:15   ` Lengyel, Tamas
2015-06-23 18:52     ` Ed White
2015-06-23 19:35       ` Lengyel, Tamas
2015-06-24 13:46   ` Andrew Cooper
2015-06-24 17:47     ` Ed White
2015-06-24 18:19       ` Andrew Cooper
2015-06-26 16:30         ` Ed White
2015-06-29 13:03           ` Andrew Cooper
2015-06-29 16:24             ` Ed White
2015-06-24 16:15   ` Lengyel, Tamas
2015-06-24 18:06     ` Ed White
2015-06-25  8:52       ` Ian Campbell
2015-06-25 16:27         ` Ed White
2015-06-25 12:44       ` Lengyel, Tamas
2015-06-25 13:40         ` Razvan Cojocaru
2015-06-25 16:48           ` Ed White
2015-06-25 17:39             ` Sahita, Ravi
2015-06-25 18:22             ` Razvan Cojocaru
2015-06-25 18:23             ` Lengyel, Tamas
2015-06-25 20:46               ` Ed White
2015-06-25 22:45                 ` Lengyel, Tamas
2015-06-25 23:10                   ` Ed White
2015-06-25  2:44   ` Lengyel, Tamas
2015-06-25 16:31     ` Ed White
2015-06-25 17:42       ` Lengyel, Tamas
2015-06-25 20:27         ` Ed White
2015-06-25 21:33           ` Lengyel, Tamas
2015-06-22 18:56 ` [PATCH v2 10/12] x86/altp2m: define and implement alternate p2m HVMOP types Ed White
2015-06-24 13:58   ` Andrew Cooper
2015-06-24 14:53   ` Jan Beulich
2015-06-22 18:56 ` [PATCH v2 11/12] x86/altp2m: Add altp2mhvm HVM domain parameter Ed White
2015-06-24 14:06   ` Andrew Cooper
2015-06-24 14:59   ` Jan Beulich
2015-06-24 17:57     ` Ed White
2015-06-24 18:08       ` Andrew Cooper
2015-06-25  8:34         ` Jan Beulich
2015-06-25  8:33       ` Jan Beulich
2015-06-22 18:56 ` [PATCH v2 12/12] x86/altp2m: XSM hooks for altp2m HVM ops Ed White
2015-06-26 19:24   ` Daniel De Graaf
2015-06-26 19:35     ` Ed White
2015-06-29 17:52       ` Daniel De Graaf
2015-06-29 17:55         ` Sahita, Ravi
2015-06-23 21:27 ` [PATCH v2 00/12] Alternate p2m: support multiple copies of host p2m Lengyel, Tamas
2015-06-23 22:25   ` Ed White
2015-06-24  5:39   ` Razvan Cojocaru
2015-06-24 13:32     ` Lengyel, Tamas
2015-06-24 13:37       ` Razvan Cojocaru
2015-06-24 16:43         ` Ed White
2015-06-24 21:34           ` Lengyel, Tamas
2015-06-24 22:02             ` Ed White
2015-06-24 22:45               ` Lengyel, Tamas
2015-06-24 22:55                 ` Ed White
2015-06-25  9:00                   ` Andrew Cooper
2015-06-25 16:38                     ` Ed White
2015-06-25 17:29                       ` Lengyel, Tamas
2015-06-25 20:34                         ` Ed White
2015-06-24 14:10 ` Andrew Cooper

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=558AEBA7.1090600@citrix.com \
    --to=andrew.cooper3@citrix.com \
    --cc=dgdegra@tycho.nsa.gov \
    --cc=edmund.h.white@intel.com \
    --cc=ian.jackson@eu.citrix.com \
    --cc=jbeulich@suse.com \
    --cc=ravi.sahita@intel.com \
    --cc=tim@xen.org \
    --cc=tlengyel@novetta.com \
    --cc=wei.liu2@citrix.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