From mboxrd@z Thu Jan  1 00:00:00 1970
From: George Dunlap <george.dunlap@eu.citrix.com>
Subject: Re: [PATCH v4 08/15] x86/altp2m: add control of
	suppress_ve.
Date: Fri, 10 Jul 2015 12:11:32 +0100
Message-ID: <559FA864.4000502@eu.citrix.com>
References: <1436489553-6300-1-git-send-email-edmund.h.white@intel.com>
	<1436489553-6300-9-git-send-email-edmund.h.white@intel.com>
	<559FAEF3020000780008F576@mail.emea.novell.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
In-Reply-To: <559FAEF3020000780008F576@mail.emea.novell.com>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: Jan Beulich <JBeulich@suse.com>, Ed White <edmund.h.white@intel.com>
Cc: Tim Deegan <tim@xen.org>, Ravi Sahita <ravi.sahita@intel.com>, Wei Liu <wei.liu2@citrix.com>, Andrew Cooper <andrew.cooper3@citrix.com>, Ian Jackson <ian.jackson@eu.citrix.com>, xen-devel@lists.xen.org, tlengyel@novetta.com, Daniel De Graaf <dgdegra@tycho.nsa.gov>
List-Id: xen-devel@lists.xenproject.org

On 07/10/2015 10:39 AM, Jan Beulich wrote:
>>>> On 10.07.15 at 02:52, <edmund.h.white@intel.com> wrote:
>> @@ -1528,16 +1528,17 @@ bool_t p2m_mem_access_check(paddr_t gpa, unsigned long gla,
>>      vm_event_request_t *req;
>>      int rc;
>>      unsigned long eip = guest_cpu_user_regs()->eip;
>> +    bool_t sve;
>>  
>>      /* First, handle rx2rw conversion automatically.
>>       * These calls to p2m->set_entry() must succeed: we have the gfn
>>       * locked and just did a successful get_entry(). */
>>      gfn_lock(p2m, gfn, 0);
>> -    mfn = p2m->get_entry(p2m, gfn, &p2mt, &p2ma, 0, NULL);
>> +    mfn = p2m->get_entry(p2m, gfn, &p2mt, &p2ma, 0, NULL, &sve);
>>  
>>      if ( npfec.write_access && p2ma == p2m_access_rx2rw ) 
>>      {
>> -        rc = p2m->set_entry(p2m, gfn, mfn, PAGE_ORDER_4K, p2mt, p2m_access_rw);
>> +        rc = p2m->set_entry(p2m, gfn, mfn, PAGE_ORDER_4K, p2mt, p2m_access_rw, sve);
>>          ASSERT(rc == 0);
>>          gfn_unlock(p2m, gfn, 0);
>>          return 1;
>> @@ -1546,7 +1547,7 @@ bool_t p2m_mem_access_check(paddr_t gpa, unsigned long gla,
>>      {
>>          ASSERT(npfec.write_access || npfec.read_access || npfec.insn_fetch);
>>          rc = p2m->set_entry(p2m, gfn, mfn, PAGE_ORDER_4K,
>> -                            p2mt, p2m_access_rwx);
>> +                            p2mt, p2m_access_rwx, -1);
> 
> So why -1 here ...
> 
>> @@ -1566,14 +1567,14 @@ bool_t p2m_mem_access_check(paddr_t gpa, unsigned long gla,
>>          else
>>          {
>>              gfn_lock(p2m, gfn, 0);
>> -            mfn = p2m->get_entry(p2m, gfn, &p2mt, &p2ma, 0, NULL);
>> +            mfn = p2m->get_entry(p2m, gfn, &p2mt, &p2ma, 0, NULL, &sve);
>>              if ( p2ma != p2m_access_n2rwx )
>>              {
>>                  /* A listener is not required, so clear the access
>>                   * restrictions.  This set must succeed: we have the
>>                   * gfn locked and just did a successful get_entry(). */
>>                  rc = p2m->set_entry(p2m, gfn, mfn, PAGE_ORDER_4K,
>> -                                    p2mt, p2m_access_rwx);
>> +                                    p2mt, p2m_access_rwx, sve);
> 
> ... but sve here, when -1 means "retain current setting" anyway?
> (Same question applies elsewhere.)

This is my code. I considered whether to use -1 here, but since we're
reading and retaining gfn, mfn, and p2mt, it seemed more consistent
stylistically to just read and re-write it along with the others.

In any case I don't have strong opinions.

 -G