From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-yw1-f201.google.com (mail-yw1-f201.google.com [209.85.128.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 53E8B5399 for ; Thu, 31 Aug 2023 21:18:21 +0000 (UTC) Received: by mail-yw1-f201.google.com with SMTP id 00721157ae682-594e1154756so15210037b3.2 for ; Thu, 31 Aug 2023 14:18:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1693516700; x=1694121500; darn=lists.linux.dev; h=content-transfer-encoding:cc:to:from:subject:message-id:references :mime-version:in-reply-to:date:from:to:cc:subject:date:message-id :reply-to; bh=YO6r55IA8eElX5w/+X8zOZmT73jh5i8DqE52ZxJWYQc=; b=guXnkcDNIx1XMysszhmhJL6plHIPzL6SW7QHZxEbAQGuDfgO5T4dxQzggbuRVn3rYg ODxtVEaMS5SG5XuAF0I+wETnGGpKpEZVuzu2kcrCXQvcjUge/cuE2Yn431SHOmzHdt1Y f7EhgQf5dKTU2UbS5j3tROjjLrBvwVzePpyn6Xx5d7hPgN0bojtmhNWGrXeDXDITF78V U0b/609DkUAxEdUMkY9Zl6JsSqw2/hbSmE5fghb5Ly2eWuuqDLy+8Rs6QS+wARKiRcRR LjkmlrIED9h1F+a9ztB+CJoilu44iHWDoa5d8FCI8aET+kr8+aHipghudlkK+lXZASDX i67A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1693516700; x=1694121500; h=content-transfer-encoding:cc:to:from:subject:message-id:references :mime-version:in-reply-to:date:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to; bh=YO6r55IA8eElX5w/+X8zOZmT73jh5i8DqE52ZxJWYQc=; b=LJyKQHnNymMsAwrD31FW9r7Oq0gwOCrdJo+ZWa0sjvVxfGmZn61jHw2fKUJybYSK4b RDgJQ7qVx/mu4XFzeyiZYdW+dAOn+luwhlD9+yOCK/r5+pDBDzDsL2rYsqSYF/tBoHfn QaUHTku9KhiF7irs3UYeCEX5nFtd5RR8Tl0OH+rHc+E5gmb8ShbSsT65DEKUQEbUxGiI Dj6IekvSKLFRpzRjkt51OlsYc0aYa+tFVUn0bbuegd8I4UHxOhmyiLpwWEaPKKjVfj4/ 3zSzDryq1YYwfHayBOopYMXvi7xVg4SkaWHAbUMXruTUu66CN1ltK7wRErN9u54jL3dT WooQ== X-Gm-Message-State: AOJu0Yy9A/31plTTuvchdMNJZT9WcuMCuNuF8Z/CrbHwnzwrmznTvgSP qG3fMqHFXKmTcvYJPXzYb4q8472ohnY= X-Google-Smtp-Source: AGHT+IEZwzQUuTI7C6FFX7BSq8V52BjhaRfu7MbpFPM/CoSsWVx5jFl7L8T8aMfs6TbWHc+jUHpp1k/u52U= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a05:690c:721:b0:586:5d03:67c8 with SMTP id bt1-20020a05690c072100b005865d0367c8mr16211ywb.3.1693516700041; Thu, 31 Aug 2023 14:18:20 -0700 (PDT) Date: Thu, 31 Aug 2023 14:18:18 -0700 In-Reply-To: Precedence: bulk X-Mailing-List: kvmarm@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20230704075054.3344915-1-stevensd@google.com> <20230704075054.3344915-6-stevensd@google.com> <20230705102547.hr2zxkdkecdxp5tf@linux.intel.com> Message-ID: Subject: Re: [PATCH v7 5/8] KVM: x86/mmu: Don't pass FOLL_GET to __kvm_follow_pfn From: Sean Christopherson To: David Stevens Cc: Yu Zhang , Marc Zyngier , Michael Ellerman , Peter Xu , linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, kvm@vger.kernel.org Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Fri, Aug 25, 2023, David Stevens wrote: > On Fri, Aug 25, 2023 at 12:15=E2=80=AFAM Sean Christopherson wrote: > > > > On Thu, Aug 24, 2023, David Stevens wrote: > > > On Wed, Jul 5, 2023 at 7:25=E2=80=AFPM Yu Zhang wrote: > > > > > > > > On Tue, Jul 04, 2023 at 04:50:50PM +0900, David Stevens wrote: > > > > > @@ -4529,7 +4540,8 @@ static int kvm_tdp_mmu_page_fault(struct kv= m_vcpu *vcpu, > > > > > > > > > > out_unlock: > > > > > read_unlock(&vcpu->kvm->mmu_lock); > > > > > - kvm_release_pfn_clean(fault->pfn); > > > > > > > > Yet kvm_release_pfn() can still be triggered for the kvm_vcpu_maped= gfns. > > > > What if guest uses a non-referenced page(e.g., as a vmcs12)? Althou= gh I > > > > believe this is not gonna happen in real world... > > > > > > kvm_vcpu_map still uses gfn_to_pfn, which eventually passes FOLL_GET > > > to __kvm_follow_pfn. So if a guest tries to use a non-refcounted page > > > like that, then kvm_vcpu_map will fail and the guest will probably > > > crash. It won't trigger any bugs in the host, though. > > > > > > It is unfortunate that the guest will be able to use certain types of > > > memory for some purposes but not for others. However, while it is > > > theoretically fixable, it's an unreasonable amount of work for > > > something that, as you say, nobody really cares about in practice [1]= . > > > > > > [1] https://lore.kernel.org/all/ZBEEQtmtNPaEqU1i@google.com/ > > > > There are use cases that care, which is why I suggested allow_unsafe_km= ap. > > Specifically, AWS manages their pool of guest memory in userspace and m= aps it all > > via /dev/mem. Without that module param to let userspace opt-in, this = series will > > break such setups. It still arguably is a breaking change since it req= uires > > userspace to opt-in, but allowing such behavior by default is simply no= t a viable > > option, and I don't have much sympathy since so much of this mess has i= ts origins > > in commit e45adf665a53 ("KVM: Introduce a new guest mapping API"). > > > > The use cases that no one cares about (AFAIK) is allowing _untrusted_ u= serspace > > to back guest RAM with arbitrary memory. In other words, I want KVM to= allow > > (by default) mapping device memory into the guest for things like vGPUs= , without > > having to do the massive and invasive overhaul needed to safely allow b= acking guest > > RAM with completely arbitrary memory. >=20 > Do you specifically want the allow_unsafe_kmap breaking change? v7 of > this series should have supported everything that is currently > supported by KVM, but you're right that the v8 version of > hva_to_pfn_remapped doesn't support mapping > !kvm_pfn_to_refcounted_page() pages. That could be supported > explicitly with allow_unsafe_kmap as you suggested, I think it needs to be explicit, i.e. needs the admin to opt-in to the unsa= fe behavior. 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 lists.ozlabs.org (lists.ozlabs.org [112.213.38.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 6BD1FC83F37 for ; Thu, 31 Aug 2023 21:19:15 +0000 (UTC) Authentication-Results: lists.ozlabs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=google.com header.i=@google.com header.a=rsa-sha256 header.s=20221208 header.b=JzGqkXud; dkim-atps=neutral Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4RcDYs6Zwmz3c7C for ; Fri, 1 Sep 2023 07:19:13 +1000 (AEST) Authentication-Results: lists.ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=google.com header.i=@google.com header.a=rsa-sha256 header.s=20221208 header.b=JzGqkXud; dkim-atps=neutral Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=flex--seanjc.bounces.google.com (client-ip=2607:f8b0:4864:20::114a; helo=mail-yw1-x114a.google.com; envelope-from=3napxzaykdjuh3zc815dd5a3.1dba7cjmee1-23ka7hih.doaz0h.dg5@flex--seanjc.bounces.google.com; receiver=lists.ozlabs.org) Received: from mail-yw1-x114a.google.com (mail-yw1-x114a.google.com [IPv6:2607:f8b0:4864:20::114a]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4RcDXw4qt3z2yN3 for ; Fri, 1 Sep 2023 07:18:23 +1000 (AEST) Received: by mail-yw1-x114a.google.com with SMTP id 00721157ae682-59224c40275so15177027b3.3 for ; Thu, 31 Aug 2023 14:18:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1693516700; x=1694121500; darn=lists.ozlabs.org; h=content-transfer-encoding:cc:to:from:subject:message-id:references :mime-version:in-reply-to:date:from:to:cc:subject:date:message-id :reply-to; bh=YO6r55IA8eElX5w/+X8zOZmT73jh5i8DqE52ZxJWYQc=; b=JzGqkXud6vvFFXyzF6NaJI5WoTcqJ3+2JtjtqAp4HFfxtcI+aQPeHvu2OT3WnkOHTj LlsLVuOuFLMvyVL1tAFOw6ata93DlvFoRQSRdew6MowjprfalJcLi1bqW8zu9gDAOz5N +PTo1tfAZVzluKO9rI8yN0MEKH/ZRzOq4dSGycSDDJbCjAYDs0pPYHrxMbi9fEYCbtbg T8Vz6/7GUPb3nXfNUjEArlavTx+6EtVPDfjqvfBxJoCA1vf4NLWhlwtUPAuXqdgs3Hmo niib22MWvsvZICfrk0KH+uZyuyY0cAkmmRKVOGen2gKYyzinw7DgexpAiT+CqhdSMEkZ 5b0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1693516700; x=1694121500; h=content-transfer-encoding:cc:to:from:subject:message-id:references :mime-version:in-reply-to:date:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to; bh=YO6r55IA8eElX5w/+X8zOZmT73jh5i8DqE52ZxJWYQc=; b=EF7Mfq1NpAeMW5jCX7pl7BPYEZSBzcwf8oY/nqM8c2PpL7G7cSnKnp0ZenlKXpG4j0 Ycq3Vzjn+8w0xZw4FUWdlc0fmiY8CwufXgjvXcoUIT8wxdWjnHALueyup3xLIHESNeax BKCmPBWya8BnFB7FdoSR38q2hW9NcQpXH7h+eF6e6m5uISzKyWVfyvAO6MpHCCkR2uG5 OcfkE3c9Y5G5St3KwWV58XpeYbshOQuKoF+zUpU/sp5OyoQ7bpQH8Op7H8qbvlqdLkH5 pEw5vLpsRxWBcWgcUZ68Jo8sQn5f0lRIUaxNpwPSQbkIW0LgwzIjBfadJSjcFZrQVc0I SGsQ== X-Gm-Message-State: AOJu0Yy7rEvQYNvhCDrkMmlV4757MR56Uoeo8GowU8q+8Dh4c22/AuKx zVk8lHLTaRd3Bzk1FMM82+prk7+K0eo= X-Google-Smtp-Source: AGHT+IEZwzQUuTI7C6FFX7BSq8V52BjhaRfu7MbpFPM/CoSsWVx5jFl7L8T8aMfs6TbWHc+jUHpp1k/u52U= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a05:690c:721:b0:586:5d03:67c8 with SMTP id bt1-20020a05690c072100b005865d0367c8mr16211ywb.3.1693516700041; Thu, 31 Aug 2023 14:18:20 -0700 (PDT) Date: Thu, 31 Aug 2023 14:18:18 -0700 In-Reply-To: Mime-Version: 1.0 References: <20230704075054.3344915-1-stevensd@google.com> <20230704075054.3344915-6-stevensd@google.com> <20230705102547.hr2zxkdkecdxp5tf@linux.intel.com> Message-ID: Subject: Re: [PATCH v7 5/8] KVM: x86/mmu: Don't pass FOLL_GET to __kvm_follow_pfn From: Sean Christopherson To: David Stevens Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: kvm@vger.kernel.org, Marc Zyngier , linux-kernel@vger.kernel.org, Peter Xu , Yu Zhang , kvmarm@lists.linux.dev, linuxppc-dev@lists.ozlabs.org, linux-arm-kernel@lists.infradead.org Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" On Fri, Aug 25, 2023, David Stevens wrote: > On Fri, Aug 25, 2023 at 12:15=E2=80=AFAM Sean Christopherson wrote: > > > > On Thu, Aug 24, 2023, David Stevens wrote: > > > On Wed, Jul 5, 2023 at 7:25=E2=80=AFPM Yu Zhang wrote: > > > > > > > > On Tue, Jul 04, 2023 at 04:50:50PM +0900, David Stevens wrote: > > > > > @@ -4529,7 +4540,8 @@ static int kvm_tdp_mmu_page_fault(struct kv= m_vcpu *vcpu, > > > > > > > > > > out_unlock: > > > > > read_unlock(&vcpu->kvm->mmu_lock); > > > > > - kvm_release_pfn_clean(fault->pfn); > > > > > > > > Yet kvm_release_pfn() can still be triggered for the kvm_vcpu_maped= gfns. > > > > What if guest uses a non-referenced page(e.g., as a vmcs12)? Althou= gh I > > > > believe this is not gonna happen in real world... > > > > > > kvm_vcpu_map still uses gfn_to_pfn, which eventually passes FOLL_GET > > > to __kvm_follow_pfn. So if a guest tries to use a non-refcounted page > > > like that, then kvm_vcpu_map will fail and the guest will probably > > > crash. It won't trigger any bugs in the host, though. > > > > > > It is unfortunate that the guest will be able to use certain types of > > > memory for some purposes but not for others. However, while it is > > > theoretically fixable, it's an unreasonable amount of work for > > > something that, as you say, nobody really cares about in practice [1]= . > > > > > > [1] https://lore.kernel.org/all/ZBEEQtmtNPaEqU1i@google.com/ > > > > There are use cases that care, which is why I suggested allow_unsafe_km= ap. > > Specifically, AWS manages their pool of guest memory in userspace and m= aps it all > > via /dev/mem. Without that module param to let userspace opt-in, this = series will > > break such setups. It still arguably is a breaking change since it req= uires > > userspace to opt-in, but allowing such behavior by default is simply no= t a viable > > option, and I don't have much sympathy since so much of this mess has i= ts origins > > in commit e45adf665a53 ("KVM: Introduce a new guest mapping API"). > > > > The use cases that no one cares about (AFAIK) is allowing _untrusted_ u= serspace > > to back guest RAM with arbitrary memory. In other words, I want KVM to= allow > > (by default) mapping device memory into the guest for things like vGPUs= , without > > having to do the massive and invasive overhaul needed to safely allow b= acking guest > > RAM with completely arbitrary memory. >=20 > Do you specifically want the allow_unsafe_kmap breaking change? v7 of > this series should have supported everything that is currently > supported by KVM, but you're right that the v8 version of > hva_to_pfn_remapped doesn't support mapping > !kvm_pfn_to_refcounted_page() pages. That could be supported > explicitly with allow_unsafe_kmap as you suggested, I think it needs to be explicit, i.e. needs the admin to opt-in to the unsa= fe behavior. 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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id D325FC83F2F for ; Thu, 31 Aug 2023 21:18:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:Cc:To:From:Subject:Message-ID: References:Mime-Version:In-Reply-To:Date:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Owner; bh=svrz3opBU/DzEab/FsmyCt4go0wJHhOC6jgXB/j3PBY=; b=UtXqI0goJMDhoYwiK/d/mSF81G lrU5IujVkY1eX4sxITJaBd3AT6AtWcaI6q1Zllk4uFm8BoBBNC1TOzVXqSeqHix+npcFdXp3yOLvP v8RZ2viTnSHNvrYBml2F9xY4E5ZgS2Mcwt/a0qQdwAwhe6MeSkdvqYdjMQN4QZAi5jAM5FMMgfDrx mXGPZLuDOJYVLkTHa0KeTAHaweu5YP4bxfQwMS6vOJmVuY1HPaS6Zlp0p2u6rNojUJhaRE8yMozOy kS+38zUYyRguCos85y3efESmTNrseOwIdC/OrYhfSjNspuNgv+B/Jd0h4jPRUKiq1PXpXuojQUHEF hy+QTVwQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1qbp3c-00Fpmj-3B; Thu, 31 Aug 2023 21:18:28 +0000 Received: from mail-yw1-x1149.google.com ([2607:f8b0:4864:20::1149]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1qbp3Z-00FplS-1o for linux-arm-kernel@lists.infradead.org; Thu, 31 Aug 2023 21:18:27 +0000 Received: by mail-yw1-x1149.google.com with SMTP id 00721157ae682-58d428d4956so15444427b3.0 for ; Thu, 31 Aug 2023 14:18:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1693516700; x=1694121500; darn=lists.infradead.org; h=content-transfer-encoding:cc:to:from:subject:message-id:references :mime-version:in-reply-to:date:from:to:cc:subject:date:message-id :reply-to; bh=YO6r55IA8eElX5w/+X8zOZmT73jh5i8DqE52ZxJWYQc=; b=UHTz2icOprTiJq8UVGJysChL4C4EB+Q6WEkXKA7YI61IGdjTEw8gT5ZBx3akUOoAdH h9qpau1Zqik0+yuEPnZm+QYRzx75AaBQBAryvv4VWL/zckJ8TLuEARq/OlhZSVWWi4ba 6cgE3XGTMAzFnyzscloNATKRnm1lAhtSSJX6fB0zoK/atN/hchYKtz7n8KWS0QwexZEr hsAO/kSNlX5lF9Xl775N9abcSuC0rg/C1kayNWb2fV64oX3F6eg22852jx/PHZtMyi88 fl+ok3chzsDp++1dpIYNh7vh87fF2ANKHa9Qq5H88c5bpxeCO4WGioOmMLyU32wpQfdQ 7MDg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1693516700; x=1694121500; h=content-transfer-encoding:cc:to:from:subject:message-id:references :mime-version:in-reply-to:date:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to; bh=YO6r55IA8eElX5w/+X8zOZmT73jh5i8DqE52ZxJWYQc=; b=AhrNotGzFXLIOomkssmVZi/rz1smLu4s1qVhH9ZyzPUiKrJNcjyYFqrJofZvm1hwkA zNe22zhBDOPWyqhu/o0pUaDGavvbeNdZyKs10ygiBKHpWLdBlBulNhnZoRsGrWchgmNX qj6sR/JnYLyQIsPtjZesnf6doSZ7sCrunj/lrrnhlkRXMEraoXSEQsHTNe+vvCi5SdyG AJZA3Xa1xhyTqxDd6KNCdGXDnSyIDQrgA71sYc2C77Df7lxWV0aMTK3sJ893OXaPBKyg jmClASV9iDkRlgi/5Ooybizvl0K3OmrcfGaxWf5lmrNhQLjtm+Pc5mpBRCzRhPAUDN7A l7JQ== X-Gm-Message-State: AOJu0YyeYJuAHpNloJJGMU1CX58ZUCH+ttOnVXUJTDKfdetvid0hpC8o AK7PZCuH0RHqXaefq5KcOjdR25Oc+pM= X-Google-Smtp-Source: AGHT+IEZwzQUuTI7C6FFX7BSq8V52BjhaRfu7MbpFPM/CoSsWVx5jFl7L8T8aMfs6TbWHc+jUHpp1k/u52U= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a05:690c:721:b0:586:5d03:67c8 with SMTP id bt1-20020a05690c072100b005865d0367c8mr16211ywb.3.1693516700041; Thu, 31 Aug 2023 14:18:20 -0700 (PDT) Date: Thu, 31 Aug 2023 14:18:18 -0700 In-Reply-To: Mime-Version: 1.0 References: <20230704075054.3344915-1-stevensd@google.com> <20230704075054.3344915-6-stevensd@google.com> <20230705102547.hr2zxkdkecdxp5tf@linux.intel.com> Message-ID: Subject: Re: [PATCH v7 5/8] KVM: x86/mmu: Don't pass FOLL_GET to __kvm_follow_pfn From: Sean Christopherson To: David Stevens Cc: Yu Zhang , Marc Zyngier , Michael Ellerman , Peter Xu , linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, kvm@vger.kernel.org X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230831_141825_603112_9E38D976 X-CRM114-Status: GOOD ( 30.86 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org T24gRnJpLCBBdWcgMjUsIDIwMjMsIERhdmlkIFN0ZXZlbnMgd3JvdGU6Cj4gT24gRnJpLCBBdWcg MjUsIDIwMjMgYXQgMTI6MTXigK9BTSBTZWFuIENocmlzdG9waGVyc29uIDxzZWFuamNAZ29vZ2xl LmNvbT4gd3JvdGU6Cj4gPgo+ID4gT24gVGh1LCBBdWcgMjQsIDIwMjMsIERhdmlkIFN0ZXZlbnMg d3JvdGU6Cj4gPiA+IE9uIFdlZCwgSnVsIDUsIDIwMjMgYXQgNzoyNeKAr1BNIFl1IFpoYW5nIDx5 dS5jLnpoYW5nQGxpbnV4LmludGVsLmNvbT4gd3JvdGU6Cj4gPiA+ID4KPiA+ID4gPiBPbiBUdWUs IEp1bCAwNCwgMjAyMyBhdCAwNDo1MDo1MFBNICswOTAwLCBEYXZpZCBTdGV2ZW5zIHdyb3RlOgo+ ID4gPiA+ID4gQEAgLTQ1MjksNyArNDU0MCw4IEBAIHN0YXRpYyBpbnQga3ZtX3RkcF9tbXVfcGFn ZV9mYXVsdChzdHJ1Y3Qga3ZtX3ZjcHUgKnZjcHUsCj4gPiA+ID4gPgo+ID4gPiA+ID4gIG91dF91 bmxvY2s6Cj4gPiA+ID4gPiAgICAgICByZWFkX3VubG9jaygmdmNwdS0+a3ZtLT5tbXVfbG9jayk7 Cj4gPiA+ID4gPiAtICAgICBrdm1fcmVsZWFzZV9wZm5fY2xlYW4oZmF1bHQtPnBmbik7Cj4gPiA+ ID4KPiA+ID4gPiBZZXQga3ZtX3JlbGVhc2VfcGZuKCkgY2FuIHN0aWxsIGJlIHRyaWdnZXJlZCBm b3IgdGhlIGt2bV92Y3B1X21hcGVkIGdmbnMuCj4gPiA+ID4gV2hhdCBpZiBndWVzdCB1c2VzIGEg bm9uLXJlZmVyZW5jZWQgcGFnZShlLmcuLCBhcyBhIHZtY3MxMik/IEFsdGhvdWdoIEkKPiA+ID4g PiBiZWxpZXZlIHRoaXMgaXMgbm90IGdvbm5hIGhhcHBlbiBpbiByZWFsIHdvcmxkLi4uCj4gPiA+ Cj4gPiA+IGt2bV92Y3B1X21hcCBzdGlsbCB1c2VzIGdmbl90b19wZm4sIHdoaWNoIGV2ZW50dWFs bHkgcGFzc2VzIEZPTExfR0VUCj4gPiA+IHRvIF9fa3ZtX2ZvbGxvd19wZm4uIFNvIGlmIGEgZ3Vl c3QgdHJpZXMgdG8gdXNlIGEgbm9uLXJlZmNvdW50ZWQgcGFnZQo+ID4gPiBsaWtlIHRoYXQsIHRo ZW4ga3ZtX3ZjcHVfbWFwIHdpbGwgZmFpbCBhbmQgdGhlIGd1ZXN0IHdpbGwgcHJvYmFibHkKPiA+ ID4gY3Jhc2guIEl0IHdvbid0IHRyaWdnZXIgYW55IGJ1Z3MgaW4gdGhlIGhvc3QsIHRob3VnaC4K PiA+ID4KPiA+ID4gSXQgaXMgdW5mb3J0dW5hdGUgdGhhdCB0aGUgZ3Vlc3Qgd2lsbCBiZSBhYmxl IHRvIHVzZSBjZXJ0YWluIHR5cGVzIG9mCj4gPiA+IG1lbW9yeSBmb3Igc29tZSBwdXJwb3NlcyBi dXQgbm90IGZvciBvdGhlcnMuIEhvd2V2ZXIsIHdoaWxlIGl0IGlzCj4gPiA+IHRoZW9yZXRpY2Fs bHkgZml4YWJsZSwgaXQncyBhbiB1bnJlYXNvbmFibGUgYW1vdW50IG9mIHdvcmsgZm9yCj4gPiA+ IHNvbWV0aGluZyB0aGF0LCBhcyB5b3Ugc2F5LCBub2JvZHkgcmVhbGx5IGNhcmVzIGFib3V0IGlu IHByYWN0aWNlIFsxXS4KPiA+ID4KPiA+ID4gWzFdIGh0dHBzOi8vbG9yZS5rZXJuZWwub3JnL2Fs bC9aQkVFUXRtdE5QYUVxVTFpQGdvb2dsZS5jb20vCj4gPgo+ID4gVGhlcmUgYXJlIHVzZSBjYXNl cyB0aGF0IGNhcmUsIHdoaWNoIGlzIHdoeSBJIHN1Z2dlc3RlZCBhbGxvd191bnNhZmVfa21hcC4K PiA+IFNwZWNpZmljYWxseSwgQVdTIG1hbmFnZXMgdGhlaXIgcG9vbCBvZiBndWVzdCBtZW1vcnkg aW4gdXNlcnNwYWNlIGFuZCBtYXBzIGl0IGFsbAo+ID4gdmlhIC9kZXYvbWVtLiAgV2l0aG91dCB0 aGF0IG1vZHVsZSBwYXJhbSB0byBsZXQgdXNlcnNwYWNlIG9wdC1pbiwgdGhpcyBzZXJpZXMgd2ls bAo+ID4gYnJlYWsgc3VjaCBzZXR1cHMuICBJdCBzdGlsbCBhcmd1YWJseSBpcyBhIGJyZWFraW5n IGNoYW5nZSBzaW5jZSBpdCByZXF1aXJlcwo+ID4gdXNlcnNwYWNlIHRvIG9wdC1pbiwgYnV0IGFs bG93aW5nIHN1Y2ggYmVoYXZpb3IgYnkgZGVmYXVsdCBpcyBzaW1wbHkgbm90IGEgdmlhYmxlCj4g PiBvcHRpb24sIGFuZCBJIGRvbid0IGhhdmUgbXVjaCBzeW1wYXRoeSBzaW5jZSBzbyBtdWNoIG9m IHRoaXMgbWVzcyBoYXMgaXRzIG9yaWdpbnMKPiA+IGluIGNvbW1pdCBlNDVhZGY2NjVhNTMgKCJL Vk06IEludHJvZHVjZSBhIG5ldyBndWVzdCBtYXBwaW5nIEFQSSIpLgo+ID4KPiA+IFRoZSB1c2Ug Y2FzZXMgdGhhdCBubyBvbmUgY2FyZXMgYWJvdXQgKEFGQUlLKSBpcyBhbGxvd2luZyBfdW50cnVz dGVkXyB1c2Vyc3BhY2UKPiA+IHRvIGJhY2sgZ3Vlc3QgUkFNIHdpdGggYXJiaXRyYXJ5IG1lbW9y eS4gIEluIG90aGVyIHdvcmRzLCBJIHdhbnQgS1ZNIHRvIGFsbG93Cj4gPiAoYnkgZGVmYXVsdCkg bWFwcGluZyBkZXZpY2UgbWVtb3J5IGludG8gdGhlIGd1ZXN0IGZvciB0aGluZ3MgbGlrZSB2R1BV cywgd2l0aG91dAo+ID4gaGF2aW5nIHRvIGRvIHRoZSBtYXNzaXZlIGFuZCBpbnZhc2l2ZSBvdmVy aGF1bCBuZWVkZWQgdG8gc2FmZWx5IGFsbG93IGJhY2tpbmcgZ3Vlc3QKPiA+IFJBTSB3aXRoIGNv bXBsZXRlbHkgYXJiaXRyYXJ5IG1lbW9yeS4KPiAKPiBEbyB5b3Ugc3BlY2lmaWNhbGx5IHdhbnQg dGhlIGFsbG93X3Vuc2FmZV9rbWFwIGJyZWFraW5nIGNoYW5nZT8gdjcgb2YKPiB0aGlzIHNlcmll cyBzaG91bGQgaGF2ZSBzdXBwb3J0ZWQgZXZlcnl0aGluZyB0aGF0IGlzIGN1cnJlbnRseQo+IHN1 cHBvcnRlZCBieSBLVk0sIGJ1dCB5b3UncmUgcmlnaHQgdGhhdCB0aGUgdjggdmVyc2lvbiBvZgo+ IGh2YV90b19wZm5fcmVtYXBwZWQgZG9lc24ndCBzdXBwb3J0IG1hcHBpbmcKPiAha3ZtX3Bmbl90 b19yZWZjb3VudGVkX3BhZ2UoKSBwYWdlcy4gVGhhdCBjb3VsZCBiZSBzdXBwb3J0ZWQKPiBleHBs aWNpdGx5IHdpdGggYWxsb3dfdW5zYWZlX2ttYXAgYXMgeW91IHN1Z2dlc3RlZCwKCkkgdGhpbmsg aXQgbmVlZHMgdG8gYmUgZXhwbGljaXQsIGkuZS4gbmVlZHMgdGhlIGFkbWluIHRvIG9wdC1pbiB0 byB0aGUgdW5zYWZlCmJlaGF2aW9yLgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18KbGludXgtYXJtLWtlcm5lbCBtYWlsaW5nIGxpc3QKbGludXgtYXJtLWtl cm5lbEBsaXN0cy5pbmZyYWRlYWQub3JnCmh0dHA6Ly9saXN0cy5pbmZyYWRlYWQub3JnL21haWxt YW4vbGlzdGluZm8vbGludXgtYXJtLWtlcm5lbAo=