From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 239E8CCA473 for ; Fri, 22 Jul 2022 15:07:27 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2E0486B0072; Fri, 22 Jul 2022 11:07:27 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 290326B0073; Fri, 22 Jul 2022 11:07:27 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 157C66B0074; Fri, 22 Jul 2022 11:07:27 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 06F876B0072 for ; Fri, 22 Jul 2022 11:07:27 -0400 (EDT) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id D0A17120CCC for ; Fri, 22 Jul 2022 15:07:26 +0000 (UTC) X-FDA: 79715064492.19.2F39CE4 Received: from mail.skyhub.de (mail.skyhub.de [5.9.137.197]) by imf29.hostedemail.com (Postfix) with ESMTP id A8BC4120086 for ; Fri, 22 Jul 2022 15:07:23 +0000 (UTC) Received: from zn.tnic (p200300ea97297665329c23fffea6a903.dip0.t-ipconnect.de [IPv6:2003:ea:9729:7665:329c:23ff:fea6:a903]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.skyhub.de (SuperMail on ZX Spectrum 128k) with ESMTPSA id DCB0B1EC04E4; Fri, 22 Jul 2022 17:07:17 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=dkim; t=1658502438; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:in-reply-to:in-reply-to: references:references; bh=3Hc0Vuv3k27qn5hRTK62cKaY/chLQcEx0JaH2giHRug=; b=fFn7fCbE9fzF8IoOrgQ/x1EoTFvBSRPNJLjiw+qpNnOmbOf65mkhNsyc0cETIHlUak1sm/ qOkO8NF/s4BDSD8YxmO71pol1top4QIOpBgu/2bqpyTZC67PPk7hajToBOT++7Gm1GT4fO nwOhQ/PnGxR+T4CmEfYCAQnMLgFMbSM= Date: Fri, 22 Jul 2022 17:07:13 +0200 From: Borislav Petkov To: Marc Orr Cc: Dave Hansen , Ard Biesheuvel , Dionna Amalie Glaze , "Kirill A. Shutemov" , Peter Gonda , Andy Lutomirski , Sean Christopherson , Andrew Morton , Joerg Roedel , Andi Kleen , Kuppuswamy Sathyanarayanan , David Rientjes , Vlastimil Babka , Tom Lendacky , Thomas Gleixner , Peter Zijlstra , Paolo Bonzini , Ingo Molnar , Varad Gautam , Dario Faggioli , Mike Rapoport , David Hildenbrand , Marcelo Cerri , tim.gardner@canonical.com, Khalid ElMously , philip.cox@canonical.com, the arch/x86 maintainers , Linux Memory Management List , linux-coco@lists.linux.dev, linux-efi , LKML , "Yao, Jiewen" Subject: Re: [PATCHv7 00/14] mm, x86/cc: Implement support for unaccepted memory Message-ID: References: <22d54786-bc12-ecc5-2b37-cbaa56090aa8@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1658502445; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=3Hc0Vuv3k27qn5hRTK62cKaY/chLQcEx0JaH2giHRug=; b=O/ZcRqqmNHyuDSPX5MrDFCh6KH7fH5IWor9ys1yYJ5zwIChxyJ6tk51m1uHVGmyVPutZaw MLiLX8RphKbGPrq3VLQ6I2tsWO8DAftc+BnGuf7OlRYMmiG70LawvVS7sFayrvy5jGq5Oc 25pBoJxf9z9hBJcSYVaR5JqPoT1IlVI= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1658502445; a=rsa-sha256; cv=none; b=2AsLZG9ei0UmCjbO3UgRVgNAyR4RTecyQhsl8GgdbKn2o2c+Yeq0cjMy8UNnEx2dmI0inN daTE8tLDDAah7QM9IjAgzA4d9s3cwjjrW+Q5f/Oj8Dp+5Yn5oZMqRwrUAIJ5mZuaYAjAw3 dsvgk8YeCj6+/LN0Wrde0+sBFVfnXIA= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=pass header.d=alien8.de header.s=dkim header.b=fFn7fCbE; dmarc=pass (policy=none) header.from=alien8.de; spf=pass (imf29.hostedemail.com: domain of bp@alien8.de designates 5.9.137.197 as permitted sender) smtp.mailfrom=bp@alien8.de X-Stat-Signature: qsu5hd3haiheboutxbqbt378upe44pdt X-Rspamd-Queue-Id: A8BC4120086 Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=alien8.de header.s=dkim header.b=fFn7fCbE; dmarc=pass (policy=none) header.from=alien8.de; spf=pass (imf29.hostedemail.com: domain of bp@alien8.de designates 5.9.137.197 as permitted sender) smtp.mailfrom=bp@alien8.de X-Rspam-User: X-Rspamd-Server: rspam11 X-HE-Tag: 1658502443-350302 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Wed, Jul 20, 2022 at 10:03:40AM -0700, Marc Orr wrote: > Generally, no. But the problem with tags is that distros tag their > images wrong sometimes. And that leads to problems. For example, I > just got a bug assigned to me yesterday about some ARM image tagged as > SEV_CAPABLE. Oops. Lol :-). (Though, I'm pretty sure we won't try to > boot an ARM image on a non-ARM host anyway; but it's still wrong...) Yeah, even if, let it crash'n'burn - people will notice pretty quickly. > That being said, this lazy accept problem is sort of a special case, > since it requires deploying code to the guest FW and the guest kernel. > I'm still relatively new at all of this, but other than the > SNP/TDX-enlightenment patches themselves, I haven't really seen any > other examples of this. So that goes back to my previous question. Is > this going to happen a lot more? Good question. Unfortunately, not even the architects of coco could give you an answer because, as you see yourself, those additional features like memory acceptance, live migration, etc keep changing - the whole coco thing is pretty much a moving target. For example, if someone comes along and says, err, see, I have this live migration helper and that thing runs as an EFI executable and it is so much better... Not saying it'll happen but it could. I hope you're catching my drift. > If not, I can definitely see value in the argument to skip the > complexity of the FW/kernel feature negotiation. > > Another thing I thought of since my last reply, that's mostly an > internal solution to this problem on our side: Going back to Dave's > 10k-foot view of the different angles of how to solve this. For "1. > Deal with that at the host level configuration", I'm thinking we could > tag the images with their internal guest kernel version. For example, > if an image has a 5.15 kernel, then we could have a `KERNEL_5_15` tag. > This would then allow us to have logic in the guest FW like: > > if (guest_kernel_is_at_least(/*major=*/5, /*minor=*/15) > enable_lazy_accept = true; Well, I don't want to spoil your idea but imagine distros like SLE or others backport features into old kernels. All of a sudden 5.14 or older can do memory acceptance too. And then that version-based scheme falls apart. So I'm guessing it would probably be better to explicitly tag distro images. Thing is, once all needed support gets in, you can drop the tags and simply say, you don't support those old images anymore and assume all required support is there and implicit... > Also, tagging images with their underlying kernel versions still seems > susceptible to mis-labeling. But this seems like it can be mostly > "fixed" via automation (e.g., write a tool to boot the guest and ask > it what it's kernel version is and use the result to attach the tag). I'll do you one better: boot the image and check for all required features and produce tags. Or do not accept the image as a possible coco image. And so on. Thx. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette