Received: by 2002:a05:6358:3188:b0:123:57c1:9b43 with SMTP id q8csp1734462rwd; Sun, 21 May 2023 05:20:38 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ7DoNngCrjlloGX/XKyk7sn3ylTsQDl2MZnUCucnxXXjW+3tTFlbtlOqS9lKZH08CrmxoPx X-Received: by 2002:a17:903:481:b0:1af:9b8a:9c7b with SMTP id jj1-20020a170903048100b001af9b8a9c7bmr3372019plb.47.1684671638105; Sun, 21 May 2023 05:20:38 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1684671638; cv=none; d=google.com; s=arc-20160816; b=boztskrz8vhgA4ZlhhQ4AWFHJLK5QQxQWvyEMdhTlsqaQAfQye2ewh61+810IFq96a C29xSLnVrhWc7eNpkdnobFyYgaqcog+wY5z3Yt40d51UzBB1ykY7yteJBWJAI4jq/OCX ONUbV/B4N/c04BaJ9tIYL7J7pGBJiFAJNO3UbIcY4zwI7aSnsHAZyyMGByeANdgtYXP6 S11FX7GK4LV9iio+W4m+VN1CSEPPyldFUi99eOwSUs9xj1l8kiPjWWRRPRPYYZaMwLau xYXQ+MppyOoFHmy5+f2DKcoqcPnFoN1dTq5kwbmTTbDb6Z2gVmL5GfZtwMjf062BEPU0 VNGQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:user-agent :content-transfer-encoding:references:in-reply-to:date:cc:to:from :subject:message-id:dkim-signature; bh=CRmypL8OSRunVkjNtin0m5vFHRjGVTpDaAIsHcd6j0k=; b=FB7IZjwUL7fbIKpzGDU6egYfe2bw1U4OBm5IN4zcIOo4v5d2jI/WijmyTc6V0pGb6A PXM9eB1xcJIs3R47JDt2B0V89oBDm5AlcfD225Ip36MbbJWwJoZ9bD8eFGgx/+9ZAMyn aELMuVFwA3TlFUQ5YUUj8iDWdUWd1M3VOG4LwOktQOFHaO2jyMhRIUuAAv7PNI4MH2Jg YmD7wxFVXk3kl7GffbbPKAF2928nWg0wbUTKKr2FDmIAChZK8KGPckluDuSfn+F7QSLs pFEzMgQet2ftm+cogA/fEY+9iIR1lAQO7PZtbzRZFkttxgXnDOAedRnu+W/iOl4Td4Tu /EmA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@xry111.site header.s=default header.b=cjPlRo3S; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=xry111.site Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id jc18-20020a17090325d200b001a197aa18fesi2903985plb.121.2023.05.21.05.20.25; Sun, 21 May 2023 05:20:38 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@xry111.site header.s=default header.b=cjPlRo3S; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=xry111.site Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230108AbjEULpx (ORCPT + 99 others); Sun, 21 May 2023 07:45:53 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41940 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232129AbjEUL2i (ORCPT ); Sun, 21 May 2023 07:28:38 -0400 Received: from xry111.site (xry111.site [89.208.246.23]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 605DD19B; Sun, 21 May 2023 04:17:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=xry111.site; s=default; t=1684667871; bh=Q26CYmvUlS+fBTmmnY0bWV8ZvrwzVZeSJzFo8/ADxRA=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=cjPlRo3SnYcMX+/nzK6H1iJmrb6mzETgC1X6eqv7JRPssiRUIG6tseoXXED9IvDcx Gzy21SjMmc39YBDXEDucNGM4yB8HMqyMKDzA9x+leMkBQjtrpV8nZXFut5uPzySYAk taQOMV+xU7K8xC5qkI/GluXEZiUnMnuCgINgr8gU= Received: from localhost.localdomain (xry111.site [IPv6:2001:470:683e::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature ECDSA (P-384) server-digest SHA384) (Client did not present a certificate) (Authenticated sender: xry111@xry111.site) by xry111.site (Postfix) with ESMTPSA id 1A72565AEB; Sun, 21 May 2023 07:17:48 -0400 (EDT) Message-ID: Subject: Re: [PATCH v10 00/30] Add KVM LoongArch support From: Xi Ruoyao To: WANG Xuerui , maobibo , Paolo Bonzini , Huacai Chen Cc: Greg Kroah-Hartman , loongarch@lists.linux.dev, linux-kernel@vger.kernel.org, kvm@vger.kernel.org, Jens Axboe , Mark Brown , Alex Deucher , Oliver Upton , Tianrui Zhao Date: Sun, 21 May 2023 19:17:47 +0800 In-Reply-To: <4529ee5b-364a-7819-c727-71cf94057b8b@xen0n.name> References: <20230515021522.2445551-1-zhaotianrui@loongson.cn> <02f07d8e-e1c2-2ec0-59c3-f5b4ef0463dc@loongson.cn> <4529ee5b-364a-7819-c727-71cf94057b8b@xen0n.name> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.48.1 MIME-Version: 1.0 X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_PASS,SPF_PASS, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, 2023-05-21 at 18:22 +0800, WANG Xuerui wrote: /* snip */ > (BTW, how do people usually deal with pre-release hardware wit=20 > documentation not out yet? I suppose similar situations like this should= =20 > turn up fairly often.) Intel normally releases the doc much earlier than shipping the hardware to customers. For example, the x86 Linear Address Masking doc has been released in 2020 (allowing Linus himself to hack the LAM code in kernel :), but AFAIK there is no Intel CPU models released with LAM support yet (at least my Raptor Lake does not indicate LAM in cpuid, or maybe I'm missing the latest server models?) For other vendors I'm not sure. > Aside from this, there's another point: use of undocumented instructions= =20 > in raw form with ".word". This currently doesn't work in LLVM/Clang,=20 Hmm, is it an inherent limitation of Clang or it's simply not implemented for LoongArch yet? On x86_64 I tried ".byte 0x90" in the inline assembly and Clang correctly emits a nop instruction. > thus will slightly set back the ongoing ClangBuiltLinux enablement=20 > effort (currently all such usages in arch/loongarch are related to=20 > "invtlb" which has perfect support, and can be removed). AFAIK, such=20 > practice dates back to the LoongISA times, when the Loongson extended=20 > opcodes weren't supported by the upstream MIPS toolchains for some=20 > reason; but LoongArch is independent and not bounded by anyone else now,= =20 > so it's better in terms of maintainability to just add the instructions= =20 > to the toolchains. People will not be inconvenienced by having to use=20 > bleeding-edge LoongArch toolchains because upstream LoongArch devs have= =20 > always been doing this. Or it may be resolved by some fancy #ifdef directives. --=20 Xi Ruoyao School of Aerospace Science and Technology, Xidian University