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

Re: [Xen-devel] [PATCH V5] x86/altp2m: Hypercall to set altp2m view visibility


  • To: Jan Beulich <jbeulich@xxxxxxxx>
  • From: Alexandru Stefan ISAILA <aisaila@xxxxxxxxxxxxxxx>
  • Date: Tue, 3 Mar 2020 09:43:23 +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=Zjl6cGXWaxlmoKt9/R0sIOpYLy0sssGep3kRKlgD/H0=; b=LhaslsjzfdyCJh44/h3KLQfLYQlcfxrzaA2XbeJpGEWD6nCcSIaBR/znVzse3oda1tz9nuNevuGDJAEdR9uORyNMFqL/SCANNxJ/zzWOYlSG+eXSKSylGvleqqL5T1lQdb2PWY+8XNU1So9ZDNu8mpjWh7xK82VuRQ/cYj5hLdYIzFAMCeJDzY1apVcWVoLzhZL//YrVZV9ZwnQR+9gwR6ptOjbAANZAfJ+PVsEzw00vbZFgX4+S1VI188xa61QESXFOvsIiMGZN5c4QL9lnjypK9k51FEurpRk8ZdMd/6vLLesYhoGuAn+4O304fjpQ/gN0LFH4XrSv4q52ym5Hpw==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ieYDrks4c/VwutuZC8Zz+p7LJMcVPNnusfs+761yntDguWPUP7CJbdx5BCY1Owxg3b+6AN5szqdQlA/+n5AOgCjDU7kWW8H0tAm5eltNFXdpmF1Q3oXllGqRY1sUfeijbrdtKy+aGRnlMahFmqv65vD6QwDH5g1mzhyOMuA9TXs+Je5NvflGXHabF4uE4wIGy0HcYEMMamqPhTblj5AH+9cV46Vy2haryzxsCwBkRpFdnU1n5BFZlgBoot48skD93bq/YnZq1qXUt8PJJaYyD0VqKd6cAfWB2uzhqZ1T8BP7Cc0uaWJxfUd8Ukz9CGZlvLeWhEOlPojWAFZDwz3zyA==
  • Authentication-results: spf=none (sender IP is ) smtp.mailfrom=aisaila@xxxxxxxxxxxxxxx;
  • Cc: Kevin Tian <kevin.tian@xxxxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, 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>, Jun Nakajima <jun.nakajima@xxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • Delivery-date: Tue, 03 Mar 2020 09:43:28 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Thread-index: AQHV7Kc8f1s5+kS3/0OKIQZfqMdQDqg2o5AAgAADe4A=
  • Thread-topic: [PATCH V5] x86/altp2m: Hypercall to set altp2m view visibility


On 03.03.2020 11:30, Jan Beulich wrote:
> On 26.02.2020 14:18, Alexandru Stefan ISAILA wrote:
>> @@ -4840,6 +4841,19 @@ static int do_altp2m_op(
>>           break;
>>       }
>>   
>> +    case HVMOP_altp2m_set_visibility:
>> +    {
>> +        uint16_t idx = a.u.set_visibility.altp2m_idx;
> 
> Why a fixed width type (and even one inefficient to deal with)?
> (One might even ask - why a local variable in the first place,
> when it's used ...
> 
>> +        if ( a.u.set_visibility.pad )
>> +            rc = -EINVAL;
>> +        else if ( !altp2m_active(d) )
>> +            rc = -EOPNOTSUPP;
>> +        else
>> +            rc = p2m_set_altp2m_view_visibility(d, idx,
>> +                                                a.u.set_visibility.visible);
> 
> ... just once here.) The function takes "unsigned int" in any
> event.

Sure, I can have this idx dropped and use the value in the structure.
I had that in place to have line size smaller and the code easy to read.

> 
>> @@ -3145,6 +3148,35 @@ int p2m_get_suppress_ve(struct domain *d, gfn_t gfn, 
>> bool *suppress_ve,
>>   
>>       return rc;
>>   }
>> +
>> +int p2m_set_altp2m_view_visibility(struct domain *d, unsigned int 
>> altp2m_idx,
>> +                                   uint8_t visible)
>> +{
>> +    altp2m_list_lock(d);
>> +
>> +    /*
>> +     * Eptp index is correlated with altp2m index and should not exceed
>> +     * min(MAX_ALTP2M, MAX_EPTP).
>> +     */
>> +    if ( altp2m_idx >= min(ARRAY_SIZE(d->arch.altp2m_p2m), MAX_EPTP) ||
>> +         d->arch.altp2m_eptp[array_index_nospec(altp2m_idx, MAX_EPTP)] ==
>> +         mfn_x(INVALID_MFN) )
>> +    {
>> +        altp2m_list_unlock(d);
> 
> I think it would be nice if this went the normal function exit path.
> Would be pretty simple to arrange for by introducing a local variable
> holding the function return value.
> 

I had the return here so as not to have boundary issues if the 
altp2m_idx is wrong  and then I have to manipulate  altp2m_eptp[].


But sure, it can have a local rc var that is returned at the end of the 
function and drop this unlock just to use a single one before the return.

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®.