[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: Jan Beulich <jbeulich@xxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
- From: Andrew Cooper <Andrew.Cooper3@xxxxxxxxxx>
- Date: Tue, 17 Jan 2023 18:48:36 +0000
- Accept-language: en-GB, en-US
- Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.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=i6nnM96Wcje001If7Kq8Ot3jIAsr9a3RJkD8G3Wj0uM=; b=BDPU9/byCc+ci43NiqEf3FJc4Y4kWRgFJteZZ2ufGJk9DTOLyhn9I4zFn9kOMprc0Dckrw2hBWkwJVlV3ztzTjElZ2AqqAU5yoR5YYutNascBjswsmNcRtYq+ymRdL2bjmt0lnihcQBstoMhXHqdtcouoUEY130IsE7FVEuG6/yeOPDCCzbWThFpoATEChR3nePG9KBwt/R+PyZDKnTqjwcY17F8eVi75XvfITk4AVDV4njpfCNrQcGukL6NljR6yZ0jmp0fvTI2uGCjwFjXKH8mlDoQRBWLo1R35yVE0TPEitSe+f0+2MB5BWMZn4mnVJvSxarMk8LBawUsS0yIOA==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Ssit10oVSFIGqXVojDuHcDpQjRWZUa8k0+V4nTo9iOn3R2ZjMaot83/ano4cgGblxbIocPewrjceupdfTxRzoaaKUmg7mr/7l5RFeuBikeqIoSofSD5Oyfo+u4TvsKxZ8LxKssBqJy3b0sHFSMVseR21q6F2EApjYO/Upr1csPjlYzrf9EZb9OWivdqujgQ39sErQuBFt+xS6zuuHG6uQyub434VyEYfAfqBav1aJ7ZdGteHCDIH458KHpLlJU+la4jZhnHhkW2BsOfOBQywR6n/SAXtIeolvdPQM5iVhpQvd7d9Edxht0/gXDy8w12bGkfGMkhbN3nePgSWiElY/A==
- Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com;
- Cc: Wei Liu <wl@xxxxxxx>, Roger Pau Monne <roger.pau@xxxxxxxxxx>, "Tim (Xen.org)" <tim@xxxxxxx>, George Dunlap <George.Dunlap@xxxxxxxxxx>
- Delivery-date: Tue, 17 Jan 2023 18:49:09 +0000
- Ironport-data: A9a23:t6pI+6tkYA6vNJHrzHyy5UUH++fnVGdfMUV32f8akzHdYApBsoF/q tZmKWmOPveJa2b1ed9zYI++80oCsZfcyddnTgFt/39nQSNG+JbJXdiXEBz9bniYRiHhoOCLz O1FM4Wdc5pkJpP4jk3wWlQ0hSAkjclkfpKlVKiffHg0HVU/IMsYoUoLs/YjhYJ1isSODQqIu Nfjy+XSI1bg0DNvWo4uw/vrRChH4bKj51v0gnRkPaoQ5AaHyCFPZH4iDfrZw0XQE9E88tGSH 44v/JnhlkvF8hEkDM+Sk7qTWiXmlZaLYGBiIlIPM0STqkAqSh4ai87XB9JFAatjsB2bnsgZ9 Tl4ncfYpTHFnEH7sL91vxFwS0mSNEDdkVPNCSDXXce7lyUqf5ZwqhnH4Y5f0YAwo45K7W9yG fMwNAIHUiLT2aWMx7egRPhF28t7Fdn5M9ZK0p1g5Wmx4fcOZ7nmGvyPz/kImTA6i4ZJAOrUY NcfZXx3dhPcbhZTO1ARTpUjgOOvgXq5eDpdwL6XjfNvvy6Pk0osgP60bou9lt+iHK25mm6xo G7c8nu/KRYdLNGFkhKO8262h/+JliT+MG4XPOzjrqc13QPCroAVICEbZ36WurqAsXf9V9lRI Ewz8wp/p6dnoSRHSfG4BXVUukWsvBQRRt5RGO0S8xyWx+zf5APxLngJSHtNZcIrsOcyRCc2z RmZktXxHzttvbaJD3WH+d+8sjeaKSUTa2gYakcsUQoAy8nupsc0lB2nczp4OKu8j9mwEzegx TmP9XE6n+9K059N0Lin91fahT7qvoLOUgM++gTQWCSi8x99Y4mmIYev7DA38Mp9EWpQdXHZ1 FBspiRUxLpm4U2l/MBVfNgwIQ==
- Ironport-hdrordr: A9a23:XPv9CaucWk8Vq2bdIYNcZ90t7skC+IMji2hC6mlwRA09TyXGra 2TdaUgvyMc1gx7ZJh5o6HnBEDyewKkyXcV2/hmAV7GZmXbUQSTXeVfBOfZogEIeBeOv9K1t5 0QFJSWYeeYZTcVsS+Q2njaLz9U+qjjzEnev5a9854Cd2FXQpAlyz08JheQE0VwSgUDL4E+Do Cg6s1OoCflUWgLb+ygb0N1FNTrlpnurtbLcBQGDxko5E2lljWz8oP3FBCew1M3Ty5P+7E/6m LI+jaJrJlL8svLhyM05VWjoKi+q+GRhOerw/b8y/T9Hw+cxjpAor4RG4Fq8gpF491Ho2xa6O Uk6y1QRPibrUmhNl1d6CGdoTXIwXIg7WTvxkSfhmamqcvlRCgiA84Eno5BdADFgnBQye1Uwe ZKxnzcuYFQEQrFkCD368OgbWAVqqOYmwtQrQcotQ0sbaIOLLtK6YAP9kJcF5kNWCr89YA8Ce FrSMXR/uxff1+WZ23Q+jAH+q3aYl0jWhOdBkQSsM2c1DZb2Hh/0ksD3cQa2nMN7og0RZVI7/ nNdq5oiLZNRMkLar8VPpZ0feKnTmjWBR7cOmObJlrqUKkBJnLWspbypK444em7EaZ4vKfaWK 6xIW+wmVRCBH4GU/f+oaGj2iq9PFmAYQ==
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
- Thread-index: AQHZJcRNSLEE6oa1r0qKWqqRMiTKGK6i/RMA
- Thread-topic: [PATCH v2 6/9] x86/shadow: re-work 4-level SHADOW_FOREACH_L2E()
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.
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.
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.
> --- 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.
> + 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.
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.
~Andrew
> + increment_ptr_to_guest_entry(_gl2p); \
P.S. I'm pretty sure I had encountered this before, but I'm re-reminded
of how much this function seems like a bad idea, even in the context of
this macroset taking arbitrary _done and _code blobs...
|