All of lore.kernel.org
 help / color / mirror / Atom feed
From: Wander Lairson Costa <wander@redhat.com>
To: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
Cc: Borislav Petkov <bp@alien8.de>, Andy Lutomirski <luto@kernel.org>,
	Sean Christopherson <seanjc@google.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Joerg Roedel <jroedel@suse.de>, Ard Biesheuvel <ardb@kernel.org>,
	Andi Kleen <ak@linux.intel.com>,
	Kuppuswamy Sathyanarayanan
	<sathyanarayanan.kuppuswamy@linux.intel.com>,
	David Rientjes <rientjes@google.com>,
	Vlastimil Babka <vbabka@suse.cz>,
	Tom Lendacky <thomas.lendacky@amd.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Peter Zijlstra <peterz@infradead.org>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Ingo Molnar <mingo@redhat.com>,
	Varad Gautam <varad.gautam@suse.com>,
	Dario Faggioli <dfaggioli@suse.com>,
	Dave Hansen <dave.hansen@intel.com>,
	Brijesh Singh <brijesh.singh@amd.com>,
	Mike Rapoport <rppt@kernel.org>,
	David Hildenbrand <david@redhat.com>,
	x86@kernel.org, linux-mm@kvack.org, linux-coco@lists.linux.dev,
	linux-efi@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCHv5 04/12] x86/boot: Add infrastructure required for unaccepted memory support
Date: Fri, 29 Apr 2022 07:58:14 -0300	[thread overview]
Message-ID: <YmvExncBpvDdfTjd@fedora> (raw)
In-Reply-To: <20220425033934.68551-5-kirill.shutemov@linux.intel.com>

On Mon, Apr 25, 2022 at 06:39:26AM +0300, Kirill A. Shutemov wrote:

[snip]

>  
> +static __always_inline void __set_bit(long nr, volatile unsigned long *addr)

Can't we update the existing set_bit function?

> +{
> +	asm volatile(__ASM_SIZE(bts) " %1,%0" : : "m" (*(volatile long *) addr),

Why do we need the cast here?

> +		     "Ir" (nr) : "memory");

Shouldn't we add "cc" to the clobber list?

> +}
> +
> +static __always_inline void __clear_bit(long nr, volatile unsigned long *addr)
> +{
> +	asm volatile(__ASM_SIZE(btr) " %1,%0" : : "m" (*(volatile long *) addr),
> +		     "Ir" (nr) : "memory");
> +}

Same comments of __set_bit apply here (except there is no clear_bit function)

[snip]

> +
> +static __always_inline unsigned long swab(const unsigned long y)
> +{
> +#if __BITS_PER_LONG == 64
> +	return __builtin_bswap32(y);
> +#else /* __BITS_PER_LONG == 32 */
> +	return __builtin_bswap64(y);

Suppose y = 0x11223344UL, then, the compiler to cast it to a 64 bits
value yielding 0x0000000011223344ULL, __builtin_bswap64 will then
return 0x4433221100000000, and the return value will be casted back
to 32 bits, so swapb will always return 0, won't it?

> +#endif
> +}
> +
> +unsigned long _find_next_bit(const unsigned long *addr1,
> +		const unsigned long *addr2, unsigned long nbits,

The addr2 name seems a bit misleading, it seems to act as some kind of mask,
is that right?

> +		unsigned long start, unsigned long invert, unsigned long le)
> +{
> +	unsigned long tmp, mask;
> +
> +	if (unlikely(start >= nbits))
> +		return nbits;
> +
> +	tmp = addr1[start / BITS_PER_LONG];
> +	if (addr2)
> +		tmp &= addr2[start / BITS_PER_LONG];
> +	tmp ^= invert;
> +
> +	/* Handle 1st word. */
> +	mask = BITMAP_FIRST_WORD_MASK(start);
> +	if (le)
> +		mask = swab(mask);
> +
> +	tmp &= mask;
> +
> +	start = round_down(start, BITS_PER_LONG);
> +
> +	while (!tmp) {
> +		start += BITS_PER_LONG;
> +		if (start >= nbits)
> +			return nbits;
> +
> +		tmp = addr1[start / BITS_PER_LONG];
> +		if (addr2)
> +			tmp &= addr2[start / BITS_PER_LONG];
> +		tmp ^= invert;
> +	}

Isn't better to divide start by BITS_PER_LONG in the beginning of the fuction,
and then multiply it by BITS_PER_LONG when necessary, saving the division operations
in the while loop?

[snip]


  reply	other threads:[~2022-04-29 10:58 UTC|newest]

Thread overview: 58+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-25  3:39 [PATCHv5 00/12] mm, x86/cc: Implement support for unaccepted memory Kirill A. Shutemov
2022-04-25  3:39 ` [PATCHv5 01/12] x86/boot/: Centralize __pa()/__va() definitions Kirill A. Shutemov
2022-04-25  7:37   ` David Hildenbrand
2022-04-25  7:52   ` Mike Rapoport
2022-04-25  3:39 ` [PATCHv5 02/12] mm: Add support for unaccepted memory Kirill A. Shutemov
2022-04-28 10:05   ` Borislav Petkov
2022-05-03 20:21   ` David Hildenbrand
2022-05-06  0:54     ` Kirill A. Shutemov
2022-04-25  3:39 ` [PATCHv5 03/12] efi/x86: Get full memory map in allocate_e820() Kirill A. Shutemov
2022-04-27 20:25   ` Borislav Petkov
2022-04-27 23:48     ` Kirill A. Shutemov
2022-04-28 10:02       ` Borislav Petkov
2022-04-25  3:39 ` [PATCHv5 04/12] x86/boot: Add infrastructure required for unaccepted memory support Kirill A. Shutemov
2022-04-29 10:58   ` Wander Lairson Costa [this message]
2022-05-02 13:38     ` Kirill A. Shutemov
2022-04-25  3:39 ` [PATCHv5 05/12] efi/x86: Implement support for unaccepted memory Kirill A. Shutemov
2022-04-29 10:53   ` Borislav Petkov
2022-05-02 13:40     ` Kirill A. Shutemov
2022-04-25  3:39 ` [PATCHv5 06/12] x86/boot/compressed: Handle " Kirill A. Shutemov
2022-04-27  0:17   ` Michael Roth
2022-04-27 14:19     ` Kirill A. Shutemov
2022-05-03 14:15       ` Borislav Petkov
2022-04-29 13:10   ` Wander Lairson Costa
2022-05-03 14:12   ` Borislav Petkov
2022-05-06 15:30     ` Kirill A. Shutemov
2022-05-10 11:03       ` Borislav Petkov
2022-05-13  5:31         ` Dionna Amalie Glaze
2022-05-13  5:34         ` Dionna Amalie Glaze
2022-05-13  9:01           ` Borislav Petkov
2022-05-13 14:45             ` Kirill A. Shutemov
2022-05-16  6:46               ` Xu, Min M
2022-05-31 22:37                 ` Dionna Amalie Glaze
2022-05-31 22:40                 ` Dionna Amalie Glaze
2022-06-01 15:49                   ` Gupta, Pankaj
2022-06-01 16:20                     ` Dionna Amalie Glaze
2022-06-01 19:34                       ` Randy Dunlap
2022-06-01 21:19                         ` Gupta, Pankaj
2022-06-02 12:51                       ` Gupta, Pankaj
2022-06-02 15:31                         ` Dionna Amalie Glaze
2022-06-07 17:28                           ` Dionna Amalie Glaze
2022-06-07 18:15                             ` Gupta, Pankaj
2022-04-25  3:39 ` [PATCHv5 07/12] x86/mm: Reserve unaccepted memory bitmap Kirill A. Shutemov
2022-04-29 13:19   ` Wander Lairson Costa
2022-05-04 11:04   ` Borislav Petkov
2022-04-25  3:39 ` [PATCHv5 08/12] x86/mm: Provide helpers for unaccepted memory Kirill A. Shutemov
2022-05-04 11:12   ` Borislav Petkov
2022-05-06 16:13     ` Kirill A. Shutemov
2022-05-10 18:32       ` Borislav Petkov
2022-05-11  1:15         ` Kirill A. Shutemov
2022-05-11  9:07           ` Borislav Petkov
2022-04-25  3:39 ` [PATCHv5 09/12] x86/tdx: Make _tdx_hypercall() and __tdx_module_call() available in boot stub Kirill A. Shutemov
2022-04-25  3:39 ` [PATCHv5 10/12] x86/tdx: Unaccepted memory support Kirill A. Shutemov
2022-05-05 10:12   ` Borislav Petkov
2022-05-06 20:44     ` Kirill A. Shutemov
2022-05-11  1:19       ` Kirill A. Shutemov
2022-05-11  9:13         ` Borislav Petkov
2022-04-25  3:39 ` [PATCHv5 11/12] mm/vmstat: Add counter for memory accepting Kirill A. Shutemov
2022-04-25  3:39 ` [PATCHv5 12/12] x86/mm: Report unaccepted memory in /proc/meminfo Kirill A. Shutemov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YmvExncBpvDdfTjd@fedora \
    --to=wander@redhat.com \
    --cc=ak@linux.intel.com \
    --cc=akpm@linux-foundation.org \
    --cc=ardb@kernel.org \
    --cc=bp@alien8.de \
    --cc=brijesh.singh@amd.com \
    --cc=dave.hansen@intel.com \
    --cc=david@redhat.com \
    --cc=dfaggioli@suse.com \
    --cc=jroedel@suse.de \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=linux-coco@lists.linux.dev \
    --cc=linux-efi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=luto@kernel.org \
    --cc=mingo@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=peterz@infradead.org \
    --cc=rientjes@google.com \
    --cc=rppt@kernel.org \
    --cc=sathyanarayanan.kuppuswamy@linux.intel.com \
    --cc=seanjc@google.com \
    --cc=tglx@linutronix.de \
    --cc=thomas.lendacky@amd.com \
    --cc=varad.gautam@suse.com \
    --cc=vbabka@suse.cz \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.