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

Re: [PATCH v2 6/9] x86/shadow: re-work 4-level SHADOW_FOREACH_L2E()


  • To: Andrew Cooper <Andrew.Cooper3@xxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Wed, 18 Jan 2023 08:25:17 +0100
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=d1BXN+EBezKFEDEV7kCekm2JH8EqTVC7vguBfgcsXcc=; b=fmTsQRrzQjBhzQ4JqQTEDUQdHbQfBt+isc3Bf8Qp5n/BviFXPOSX611TYr9ZaBowzPLREv1M5QdrPnkuVzIQTsG82AKjtTl8CLam9W7n/Rw7cLFA8AyEaFP7X2hF7qjBKoY+G1U7HMkpBt63FJs2hsuB90c9yeE+KQ/GW/3nSuHDG+O/IPOinsR2ZP8Ffcx+2iwGOirkIGcWa7/Y+OchdZoiSozDirVSFfMYOCO1vCggOXQQT72o8hI7a4t5rgCtZJJu8cB2kkhH/zmv7mI4PkF6IvKX/cIpjciwFgjbUSGHR/qd32Li/LxyVd9jvxw9lfMyLrDisuXYYDlADVVWRQ==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=QfPzzu/guOIakYquH+gtGzubRhN01vJiYO49gH0z73apqJD/Cg/eNBipP0ZWf5GFWLGqfE1pqjQ/mP6jaf8S3wLK127lKbPv6wr+/YPejCsAFxIzwYIxeDVceKDXuIVmMFSiVeyfIo3q6cUDqXWafz00nVgHu7PSY2N81Hg8q7bClTpywM9T2FhTpTj1Q0MQn7utZnue1go/BCpY1kB3JQRzxrNbBMxmSrjm4pZapBOvAPlYjHODmuaY/tp9ix9+QXl2j7bb2sF7ERvEEXV1cn/zhEIkGTuvC+geMDhgXpQvdaRIyGwGvVrqUyOxalwJ0huSu4yWvIGwx8UcO2WNWg==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
  • Cc: Wei Liu <wl@xxxxxxx>, Roger Pau Monne <roger.pau@xxxxxxxxxx>, "Tim (Xen.org)" <tim@xxxxxxx>, George Dunlap <George.Dunlap@xxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Wed, 18 Jan 2023 07:25:32 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 17.01.2023 19:48, Andrew Cooper wrote:
> On 11/01/2023 1:54 pm, Jan Beulich wrote:
>> First of all move the almost loop-invariant condition out of the loop;
>> transform it into an altered loop boundary. Since the new local variable
>> wants to be "unsigned int" and named without violating name space rules,
>> convert the loop induction variable accordingly.
> 
> I'm firmly -1 against using trailing underscores.

Well, I can undo that aspect, but just to get done with the change. I do
consider ...

> Mainly, I object to the attempt to justify doing so based on a rule we
> explicitly choose to violate for code consistency and legibility reasons.

... your view here at least questionable: I'm unaware of us doing so
explicitly, and I've pointed out numerous times that the C standard
specifies very clearly what underscore-prefixed names may be used for. 

> But in this case, you're taking a block of logic which was cleanly in
> one style, and making it mixed, even amongst only the local variables.

That's simply the result of wanting to limit how much of a change I
make to the macro, such that the actual changes are easier to spot.

>> --- a/xen/arch/x86/mm/shadow/multi.c
>> +++ b/xen/arch/x86/mm/shadow/multi.c
>> @@ -863,23 +863,20 @@ do {
>>  /* 64-bit l2: touch all entries except for PAE compat guests. */
>>  #define SHADOW_FOREACH_L2E(_sl2mfn, _sl2e, _gl2p, _done, _dom, _code)       
>> \
>>  do {                                                                        
>> \
>> -    int _i;                                                                 
>> \
>> -    int _xen = !shadow_mode_external(_dom);                                 
>> \
>> +    unsigned int i_, end_ = SHADOW_L2_PAGETABLE_ENTRIES;                    
>> \
>>      shadow_l2e_t *_sp = map_domain_page((_sl2mfn));                         
>> \
>>      ASSERT_VALID_L2(mfn_to_page(_sl2mfn)->u.sh.type);                       
>> \
>> -    for ( _i = 0; _i < SHADOW_L2_PAGETABLE_ENTRIES; _i++ )                  
>> \
>> +    if ( !shadow_mode_external(_dom) &&                                     
>> \
>> +         is_pv_32bit_domain(_dom) &&                                        
>> \
> 
> The second clause here implies the first.  Given that all we're trying
> to say here is "are there Xen entries to skip", I think we'd be fine
> dropping the external() check entirely.

Will do. I may retain this in some form of comment.

>> +         mfn_to_page(_sl2mfn)->u.sh.type != SH_type_l2_64_shadow )          
>> \
>> +        end_ = COMPAT_L2_PAGETABLE_FIRST_XEN_SLOT(_dom);                    
>> \
>> +    for ( i_ = 0; i_ < end_; ++i_ )                                         
>> \
>>      {                                                                       
>> \
>> -        if ( (!(_xen))                                                      
>> \
>> -             || !is_pv_32bit_domain(_dom)                                   
>> \
>> -             || mfn_to_page(_sl2mfn)->u.sh.type == SH_type_l2_64_shadow     
>> \
>> -             || (_i < COMPAT_L2_PAGETABLE_FIRST_XEN_SLOT(_dom)) )           
>> \
>> -        {                                                                   
>> \
>> -            (_sl2e) = _sp + _i;                                             
>> \
>> -            if ( shadow_l2e_get_flags(*(_sl2e)) & _PAGE_PRESENT )           
>> \
>> -                {_code}                                                     
>> \
>> -            if ( _done ) break;                                             
>> \
>> -            increment_ptr_to_guest_entry(_gl2p);                            
>> \
>> -        }                                                                   
>> \
>> +        (_sl2e) = _sp + i_;                                                 
>> \
>> +        if ( shadow_l2e_get_flags(*(_sl2e)) & _PAGE_PRESENT )               
>> \
>> +            { _code }                                                       
>> \
> 
> This doesn't match either of our two styles. 

Indeed, and I was unable to come up with good criteria whether to leave
it (for consistency with the other macros) or  change it. Since you're
...

> if ( ... )
> { _code }
> 
> would be closer to Xen's normal style, but  ...
> 
>> +        if ( _done ) break;                                                 
>> \
> 
> ... with this too, I think it would still be better to write it out
> fully, so:
> 
> if ( ... )
> {
>     _code
> }
> if ( _done )
>     break;
> 
> These macros are already big enough that trying to save 3 lines seems
> futile.

... explicitly asking for it, I'll change then. Would you mind if I then
also added a semicolon after _code, to make things look more sensible?

Jan



 


Rackspace

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