On Mon, Apr 18, 2022 at 11:24:31PM +0300, Kirill A. Shutemov wrote:
> <linux/bitmap> doesn't include <linux/kernel.h> or similar things.
> Is it okay for now?
No, it is not ok because those linux/ includes are moving targets. They
keep changing and then that indirectly influences the decompressor.
How much functionality from linux/bitmap.h do you actually need?
> But the goal of the function is not to accept the memory, but mark it
> as unaccepted in the bitmap.
Really?
+ * Accept small regions that might not be able to be represented
+ * in the bitmap:
+ */
+ if (end - start < 2 * PMD_SIZE) {
+ __accept_memory(start, end);
That looks like it is accepting to me.
> Conceptionally, it is just memory that requires additional action before
> it can be accessed. Yes, at the moment TDX and SEV are the only users.
> It is implementation detail that TDX and SEV use memory encryption.
So there *might* be some potential future use. Nothing concrete at the
moment.
> Because I don't think it is a good fit. Frankly, even <asm/coco.h> fits
> better, although I'm no a fan either.
>
> Do we have file shortage? I would rather keep it separate.
So I have not read a single argument for why the unaccepted memory gunk
should be separate.
We have perfectly fine mem_encrypt.[ch] files everywhere which already
contain code which deals with the kernel running as encrypted guest. The
unaccepted memory stuff is part of that - not something separate.
If it gets to get used for something different, sure, then it can be
carved out because it might need to be built separately, without the
rest of the encryption code. But as it is now, it doesn't have to. So
please put it in those files.
> Both allocate_e820() and handling unaccepted memory requires access to the
> efi memory map. We only need the size of memory map for e820, while
> unaccepted memory requires walking the map. We can serve both by
> requesting the map from the firmware once. It requires allocation and
> freeing memory for the map.
>
> Makes sense?
Ok, thanks.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
