[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH V6 2/4] x86/altp2m: Add hypercall to set a range of sve bits


  • To: George Dunlap <george.dunlap@xxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • From: Alexandru Stefan ISAILA <aisaila@xxxxxxxxxxxxxxx>
  • Date: Tue, 24 Dec 2019 08:48:33 +0000
  • Accept-language: en-US
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=bitdefender.com; dmarc=pass action=none header.from=bitdefender.com; dkim=pass header.d=bitdefender.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=1M66exX9UGCz+p0FSp+eW8UJUbwC/P1yCIKnin4gEDY=; b=UnEc8mtXSZF4QqrvNBuLIkK3gZinVC7DOfNf4NfXEerfATz4suCHr+73jsRu3YITG0ZvgyFwHDFrKbBQuXcbDoayq6VtPShVUGLjqJlh8zogB0oDaw0IJfoGrf2i2ToSK3Uih2T5TxYakk3Ywc/Su2QwstL8ozysi27R/7EIYPBueJEo+7+rrluNSAeeC43Ve8dotc9l6czBYzkAL5/vx12ekQJDeZkxBvsxVdnllTgI4iHAM+pDr6Ncy+kY7+A+/cHyl919/aue2E5mrkmsVERnkoqGfY8j7BBAfjdRBqWa7vVbxA7gDSaJXVyDLvQHar/Iyq8E+2B2ComPgh1AbA==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=dCHO4beVg4U8bo5aYXe+fUBFC3m/6t5QmiD2FfhivZMa3f6VgbTcUCsGxL5VGsu6Lo4MeHrbA1d7AVAxmRGl5/X5XYRHhCTeDnmGl2mTb/aB77o2o88m/wglsVKFyBf6lKx/H7QA3/PNTlMBkpqSq9jAlSVwMv/Ix/L3nZBGHXRq3nxWN08i16kBsacQaCC1wGoCovHDnV3I1jqZEjzcsIZIlZp3cMKWnrwRQhgAjMYvjuTkTkI5zp2D4uf3wryTOdjJYmF+q068q1m3wZbCJyOCw2Yykb+Sdt2qD6UZZbZ9N2Ud6MSc87zAwVs7tPOI0dXkuWpRhE29HVoGG315DQ==
  • Authentication-results: spf=none (sender IP is ) smtp.mailfrom=aisaila@xxxxxxxxxxxxxxx;
  • Cc: Petre Ovidiu PIRCALABU <ppircalabu@xxxxxxxxxxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Razvan COJOCARU <rcojocaru@xxxxxxxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>, George Dunlap <George.Dunlap@xxxxxxxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Ian Jackson <ian.jackson@xxxxxxxxxxxxx>, Tamas K Lengyel <tamas@xxxxxxxxxxxxx>, Jan Beulich <jbeulich@xxxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • Delivery-date: Tue, 24 Dec 2019 08:48:54 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Thread-index: AQHVuZnoQDql7d7Su0+P124sSAtk36fI9bKAgAAE8IA=
  • Thread-topic: [PATCH V6 2/4] x86/altp2m: Add hypercall to set a range of sve bits


On 24.12.2019 10:30, George Dunlap wrote:
> On 12/23/19 2:04 PM, Alexandru Stefan ISAILA wrote:
>> By default the sve bits are not set.
>> This patch adds a new hypercall, xc_altp2m_set_supress_ve_multi(),
>> to set a range of sve bits.
>> The core function, p2m_set_suppress_ve_multi(), does not brake in case
> 
> *break

Sorry for the typo.

> 
>> of a error and it is doing a best effort for setting the bits in the
>> given range. A check for continuation is made in order to have
>> preemption on big ranges.
> 
> Weird English quirk: this should be "large".  ("Big" and "large" are
> both adjectives, and "ranges" is a noun, so theoretically it should be
> OK; but if you ask almost any native English speaker they'll say that
> "big" sounds wrong in this case.  No real idea why.)
> 
> Both of these could be fixed on check-in.
> 
>> diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
>> index 4fc919a9c5..de832dcc6d 100644
>> --- a/xen/arch/x86/mm/p2m.c
>> +++ b/xen/arch/x86/mm/p2m.c
>> @@ -3070,6 +3070,70 @@ out:
>>       return rc;
>>   }
>>   
>> +/*
>> + * Set/clear the #VE suppress bit for multiple pages.  Only available on 
>> VMX.
>> + */
>> +int p2m_set_suppress_ve_multi(struct domain *d,
>> +                              struct xen_hvm_altp2m_suppress_ve_multi *sve)
>> +{
>> +    struct p2m_domain *host_p2m = p2m_get_hostp2m(d);
>> +    struct p2m_domain *ap2m = NULL;
>> +    struct p2m_domain *p2m = host_p2m;
>> +    uint64_t start = sve->first_gfn;
>> +    int rc = 0;
>> +
>> +    if ( sve->view > 0 )
>> +    {
>> +        if ( sve->view >= MAX_ALTP2M ||
>> +             d->arch.altp2m_eptp[array_index_nospec(sve->view, MAX_ALTP2M)] 
>> ==
>> +             mfn_x(INVALID_MFN) )
>> +            return -EINVAL;
>> +
>> +        p2m = ap2m = d->arch.altp2m_p2m[array_index_nospec(sve->view,
>> +                                                           MAX_ALTP2M)];
>> +    }
>> +
>> +    p2m_lock(host_p2m);
>> +
>> +    if ( ap2m )
>> +        p2m_lock(ap2m);
>> +
>> +    while ( sve->last_gfn >= start )
>> +    {
>> +        p2m_access_t a;
>> +        p2m_type_t t;
>> +        mfn_t mfn;
>> +        int err = 0;
>> +
>> +        if ( altp2m_get_effective_entry(p2m, _gfn(start), &mfn, &t, &a, 
>> AP2MGET_query) )
>> +            a = p2m->default_access;
> 
> So in the single-entry version, if altp2m_get_effective_entry() returns
> an error, you pass that error up the stack; but in the multiple-entry
> version, you ignore the error and simply set the access to
> default_access?  I don't think that can be right.  If it is right, then
> it definitely needs a comment.
> 

The idea behind this was to have a best effort try and signal the first 
error. If the get_entry fails then the best way to go is with 
default_access but this is open for debate.

Another way to solve this is to update the first_error_gfn/first_error 
and then continue. I think this ca be used to make p2m_set_suppress_ve() 
call p2m_set_suppress_ve_multi.

> This points out another issue: implementing this functionality twice
> risks having this sort of drift between the single-entry version and the
> multiple-entry version.  Would it make sense instead to implement the
> single-entry version hypercall using p2m_set_suppress_ve_multi?
> 

In the single version there is no best-effort idea because the user can 
make use of every single error.

Alex
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.