From: "Jan Beulich" <JBeulich@suse.com>
To: Ravi Sahita <ravi.sahita@intel.com>
Cc: Tim Deegan <tim@xen.org>, Wei Liu <wei.liu2@citrix.com>,
George Dunlap <george.dunlap@eu.citrix.com>,
Andrew Cooper <andrew.cooper3@citrix.com>,
Ian Jackson <ian.jackson@eu.citrix.com>,
Edmund H White <edmund.h.white@intel.com>,
"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
Jun Nakajima <jun.nakajima@intel.com>,
"tlengyel@novetta.com" <tlengyel@novetta.com>,
Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: Re: [PATCH v7 11/15] x86/altp2m: define and implement alternate p2m HVMOP types.
Date: Thu, 23 Jul 2015 09:08:39 -0600 [thread overview]
Message-ID: <55B11F970200007800094B83@prv-mh.provo.novell.com> (raw)
In-Reply-To: <DBC12B0F5509554280826E40BCDEE8BE54FE8383@ORSMSX104.amr.corp.intel.com>
>>> On 23.07.15 at 16:56, <ravi.sahita@intel.com> wrote:
>> From: Jan Beulich [mailto:JBeulich@suse.com]
>>Sent: Thursday, July 23, 2015 3:22 AM
>>
>>>>> On 23.07.15 at 01:01, <edmund.h.white@intel.com> wrote:
>>> Signed-off-by: Ed White <edmund.h.white@intel.com>
>>>
>>> Acked-by: Jan Beulich <jbeulich@suse.com>
>>
>>And I have to withdraw this ack pending clarification of (and perhaps
>>adjustment to) the #VE info address interface.
>>
>
> Could we have the ack back :-) I clarified the #VE info address interface in
> the other email - repeating here:
>
> " If the "EPT-violation #VE" VM-execution control is 1, the
> virtualization-exception information address must
> satisfy the following checks:
> - Bits 11:0 of the address must be 0.
> - The address must not set any bits beyond the processor's physical-address
> width."
Yes, for this aspect.
>>> --- a/xen/arch/x86/hvm/hvm.c
>>> +++ b/xen/arch/x86/hvm/hvm.c
>>> @@ -6138,6 +6138,140 @@ static int hvmop_get_param(
>>> return rc;
>>> }
>>>
>>> +static int do_altp2m_op(
>>> + XEN_GUEST_HANDLE_PARAM(void) arg) {
>>> + struct xen_hvm_altp2m_op a;
>>> + struct domain *d = NULL;
>>> + int rc = 0;
>>> +
>>> + if ( !hvm_altp2m_supported() )
>>> + return -EOPNOTSUPP;
>>> +
>>> + if ( copy_from_guest(&a, arg, 1) )
>>> + return -EFAULT;
>>> +
>>> + if ( a.pad1 || a.pad2 ||
>>> + (a.version != HVMOP_ALTP2M_INTERFACE_VERSION) ||
>>> + (a.cmd < HVMOP_altp2m_get_domain_state) ||
>>> + (a.cmd > HVMOP_altp2m_change_gfn) )
>>
>>I'm afraid such a change invalidates any earlier ack, even if ti is correct.
> Instead
>>of this, why don't you start numbering of the sub-ops at zero? Or if you
> really
>>have a reason to start at 1, why not simply check a.cmd against zero (without
>>using any particular sub-op value)? And then it escapes me why this can't be
>>handled in a default case in the switch statement below anyway.
>
> Hmm - is that a requirement per se? we are consistently checking per the
> sub-op definition we have.
Well, in a way. But doing range checks like this means future
additions of sub-ops would always need to touch this code. Quite
different from doing it in the default case of a switch statement.
Plus, can you see how the expression is going to look like if in
interface version 2 you need to remove one or two of the current
entries, replacing them with new, higher numbers?
> Would like this to be considered as is.
>
> As I said in the cover letter we have constraints on how much more we can do
> this week now -
> so requesting the maintainers to accept v7 with the review comments you have
> on those recorded as pending to be addressed by us.
Yes, on that basis, albeit extremely hesitantly to be honest. If any
other maintainer would be as hesitant as I am about this, I would
likely put the two together to yield a NAK.
Jan
next prev parent reply other threads:[~2015-07-23 15:08 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-22 23:01 [PATCH v7 00/15] Alternate p2m: support multiple copies of host p2m Ed White
2015-07-22 23:01 ` [PATCH v7 01/15] common/domain: Helpers to pause a domain while in context Ed White
2015-07-22 23:01 ` [PATCH v7 02/15] VMX: VMFUNC and #VE definitions and detection Ed White
2015-07-22 23:01 ` [PATCH v7 03/15] VMX: implement suppress #VE Ed White
2015-07-22 23:01 ` [PATCH v7 04/15] x86/HVM: Hardware alternate p2m support detection Ed White
2015-07-22 23:01 ` [PATCH v7 05/15] x86/altp2m: basic data structures and support routines Ed White
2015-07-23 9:22 ` Jan Beulich
2015-07-23 14:36 ` Sahita, Ravi
2015-07-23 14:53 ` Jan Beulich
2015-07-23 15:00 ` Sahita, Ravi
2015-07-22 23:01 ` [PATCH v7 06/15] VMX/altp2m: add code to support EPTP switching and #VE Ed White
2015-07-23 9:43 ` Jan Beulich
2015-07-23 14:40 ` Sahita, Ravi
2015-07-23 15:00 ` Jan Beulich
2015-07-23 15:02 ` Sahita, Ravi
2015-07-22 23:01 ` [PATCH v7 07/15] VMX: add VMFUNC leaf 0 (EPTP switching) to emulator Ed White
2015-07-22 23:01 ` [PATCH v7 08/15] x86/altp2m: add control of suppress_ve Ed White
2015-07-22 23:01 ` [PATCH v7 09/15] x86/altp2m: alternate p2m memory events Ed White
2015-07-22 23:01 ` [PATCH v7 10/15] x86/altp2m: add remaining support routines Ed White
2015-07-23 10:05 ` Jan Beulich
2015-07-23 14:51 ` Sahita, Ravi
2015-07-23 15:02 ` Jan Beulich
2015-07-23 16:08 ` George Dunlap
2015-07-23 16:15 ` Jan Beulich
2015-07-23 16:50 ` Sahita, Ravi
2015-07-23 19:10 ` George Dunlap
2015-07-22 23:01 ` [PATCH v7 11/15] x86/altp2m: define and implement alternate p2m HVMOP types Ed White
2015-07-23 10:22 ` Jan Beulich
2015-07-23 14:56 ` Sahita, Ravi
2015-07-23 15:08 ` Jan Beulich [this message]
2015-07-23 15:16 ` Sahita, Ravi
2015-07-22 23:01 ` [PATCH v7 12/15] x86/altp2m: Add altp2mhvm HVM domain parameter Ed White
2015-07-22 23:01 ` [PATCH v7 13/15] x86/altp2m: XSM hooks for altp2m HVM ops Ed White
2015-07-23 16:08 ` Jan Beulich
2015-07-23 16:56 ` Sahita, Ravi
2015-07-24 7:49 ` Jan Beulich
2015-07-22 23:01 ` [PATCH v7 14/15] tools/libxc: add support to altp2m hvmops Ed White
2015-07-22 23:01 ` [PATCH v7 15/15] tools/xen-access: altp2m testcases Ed White
2015-07-23 17:12 ` [PATCH v7 00/15] Alternate p2m: support multiple copies of host p2m Wei Liu
2015-07-23 19:11 ` George Dunlap
2015-07-24 9:56 ` Wei Liu
2015-07-24 16:06 ` Sahita, Ravi
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=55B11F970200007800094B83@prv-mh.provo.novell.com \
--to=jbeulich@suse.com \
--cc=andrew.cooper3@citrix.com \
--cc=dgdegra@tycho.nsa.gov \
--cc=edmund.h.white@intel.com \
--cc=george.dunlap@eu.citrix.com \
--cc=ian.jackson@eu.citrix.com \
--cc=jun.nakajima@intel.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;
as well as URLs for NNTP newsgroup(s).