From: Chao Gao <chao.gao@intel.com>
To: Maxim Levitsky <mlevitsk@redhat.com>
Cc: Wanpeng Li <wanpengli@tencent.com>,
kvm@vger.kernel.org, David Airlie <airlied@linux.ie>,
Dave Hansen <dave.hansen@linux.intel.com>,
dri-devel@lists.freedesktop.org, "H. Peter Anvin" <hpa@zytor.com>,
Brijesh Singh <brijesh.singh@amd.com>,
Joerg Roedel <joro@8bytes.org>,
x86@kernel.org, Ingo Molnar <mingo@redhat.com>,
Tom Lendacky <thomas.lendacky@amd.com>,
intel-gfx@lists.freedesktop.org, Borislav Petkov <bp@alien8.de>,
Rodrigo Vivi <rodrigo.vivi@intel.com>,
Thomas Gleixner <tglx@linutronix.de>,
intel-gvt-dev@lists.freedesktop.org,
Jim Mattson <jmattson@google.com>,
Sean Christopherson <seanjc@google.com>,
linux-kernel@vger.kernel.org, Paolo Bonzini <pbonzini@redhat.com>,
Vitaly Kuznetsov <vkuznets@redhat.com>
Subject: Re: [Intel-gfx] [RFC PATCH v3 02/19] KVM: x86: inhibit APICv/AVIC when the guest and/or host changes apic id/base from the defaults.
Date: Wed, 18 May 2022 19:51:01 +0800 [thread overview]
Message-ID: <20220518115056.GA18087@gao-cwp> (raw)
In-Reply-To: <8c78939bf01a98554696add10e17b07631d97a28.camel@redhat.com>
On Wed, May 18, 2022 at 12:50:27PM +0300, Maxim Levitsky wrote:
>> > struct kvm_arch {
>> > @@ -1258,6 +1260,7 @@ struct kvm_arch {
>> > hpa_t hv_root_tdp;
>> > spinlock_t hv_root_tdp_lock;
>> > #endif
>> > + bool apic_id_changed;
>>
>> What's the value of this boolean? No one reads it.
>
>I use it in later patches to kill the guest during nested VM entry
>if it attempts to use nested AVIC after any vCPU changed APIC ID.
>
>I mentioned this boolean in the commit description.
>
>This boolean avoids the need to go over all vCPUs and checking
>if they still have the initial apic id.
Do you want to kill the guest if APIC base got changed? If yes,
you can check if APICV_INHIBIT_REASON_RO_SETTINGS is set and save
the boolean.
>
>In the future maybe we can introduce a more generic 'taint'
>bitmap with various flags like that, indicating that the guest
>did something unexpected.
>
>BTW, the other option in regard to the nested AVIC is just to ignore this issue completely.
>The code itself always uses vcpu_id's, thus regardless of when/how often the guest changes
>its apic ids, my code would just use the initial APIC ID values consistently.
>
>In this case I won't need this boolean.
>
>>
>> > };
>> >
>> > struct kvm_vm_stat {
>> > diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
>> > index 66b0eb0bda94e..8996675b3ef4c 100644
>> > --- a/arch/x86/kvm/lapic.c
>> > +++ b/arch/x86/kvm/lapic.c
>> > @@ -2038,6 +2038,19 @@ static void apic_manage_nmi_watchdog(struct kvm_lapic *apic, u32 lvt0_val)
>> > }
>> > }
>> >
>> > +static void kvm_lapic_check_initial_apic_id(struct kvm_lapic *apic)
>> > +{
>> > + if (kvm_apic_has_initial_apic_id(apic))
>> > + return;
>> > +
>> > + pr_warn_once("APIC ID change is unsupported by KVM");
>>
>> It is misleading because changing xAPIC ID is supported by KVM; it just
>> isn't compatible with APICv. Probably this pr_warn_once() should be
>> removed.
>
>Honestly since nobody uses this feature, I am not sure if to call this supported,
>I am sure that KVM has more bugs in regard of using non standard APIC ID.
>This warning might hopefuly make someone complain about it if this
>feature is actually used somewhere.
Now I got you. It is fine to me.
WARNING: multiple messages have this Message-ID (diff)
From: Chao Gao <chao.gao@intel.com>
To: Maxim Levitsky <mlevitsk@redhat.com>
Cc: Wanpeng Li <wanpengli@tencent.com>,
kvm@vger.kernel.org, David Airlie <airlied@linux.ie>,
Dave Hansen <dave.hansen@linux.intel.com>,
dri-devel@lists.freedesktop.org, "H. Peter Anvin" <hpa@zytor.com>,
Brijesh Singh <brijesh.singh@amd.com>,
Joerg Roedel <joro@8bytes.org>,
x86@kernel.org, Ingo Molnar <mingo@redhat.com>,
Zhi Wang <zhi.a.wang@intel.com>,
Tom Lendacky <thomas.lendacky@amd.com>,
intel-gfx@lists.freedesktop.org, Borislav Petkov <bp@alien8.de>,
Rodrigo Vivi <rodrigo.vivi@intel.com>,
Thomas Gleixner <tglx@linutronix.de>,
intel-gvt-dev@lists.freedesktop.org,
Jim Mattson <jmattson@google.com>,
Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>,
Sean Christopherson <seanjc@google.com>,
linux-kernel@vger.kernel.org, Paolo Bonzini <pbonzini@redhat.com>,
Vitaly Kuznetsov <vkuznets@redhat.com>
Subject: Re: [RFC PATCH v3 02/19] KVM: x86: inhibit APICv/AVIC when the guest and/or host changes apic id/base from the defaults.
Date: Wed, 18 May 2022 19:51:01 +0800 [thread overview]
Message-ID: <20220518115056.GA18087@gao-cwp> (raw)
In-Reply-To: <8c78939bf01a98554696add10e17b07631d97a28.camel@redhat.com>
On Wed, May 18, 2022 at 12:50:27PM +0300, Maxim Levitsky wrote:
>> > struct kvm_arch {
>> > @@ -1258,6 +1260,7 @@ struct kvm_arch {
>> > hpa_t hv_root_tdp;
>> > spinlock_t hv_root_tdp_lock;
>> > #endif
>> > + bool apic_id_changed;
>>
>> What's the value of this boolean? No one reads it.
>
>I use it in later patches to kill the guest during nested VM entry
>if it attempts to use nested AVIC after any vCPU changed APIC ID.
>
>I mentioned this boolean in the commit description.
>
>This boolean avoids the need to go over all vCPUs and checking
>if they still have the initial apic id.
Do you want to kill the guest if APIC base got changed? If yes,
you can check if APICV_INHIBIT_REASON_RO_SETTINGS is set and save
the boolean.
>
>In the future maybe we can introduce a more generic 'taint'
>bitmap with various flags like that, indicating that the guest
>did something unexpected.
>
>BTW, the other option in regard to the nested AVIC is just to ignore this issue completely.
>The code itself always uses vcpu_id's, thus regardless of when/how often the guest changes
>its apic ids, my code would just use the initial APIC ID values consistently.
>
>In this case I won't need this boolean.
>
>>
>> > };
>> >
>> > struct kvm_vm_stat {
>> > diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
>> > index 66b0eb0bda94e..8996675b3ef4c 100644
>> > --- a/arch/x86/kvm/lapic.c
>> > +++ b/arch/x86/kvm/lapic.c
>> > @@ -2038,6 +2038,19 @@ static void apic_manage_nmi_watchdog(struct kvm_lapic *apic, u32 lvt0_val)
>> > }
>> > }
>> >
>> > +static void kvm_lapic_check_initial_apic_id(struct kvm_lapic *apic)
>> > +{
>> > + if (kvm_apic_has_initial_apic_id(apic))
>> > + return;
>> > +
>> > + pr_warn_once("APIC ID change is unsupported by KVM");
>>
>> It is misleading because changing xAPIC ID is supported by KVM; it just
>> isn't compatible with APICv. Probably this pr_warn_once() should be
>> removed.
>
>Honestly since nobody uses this feature, I am not sure if to call this supported,
>I am sure that KVM has more bugs in regard of using non standard APIC ID.
>This warning might hopefuly make someone complain about it if this
>feature is actually used somewhere.
Now I got you. It is fine to me.
WARNING: multiple messages have this Message-ID (diff)
From: Chao Gao <chao.gao@intel.com>
To: Maxim Levitsky <mlevitsk@redhat.com>
Cc: kvm@vger.kernel.org, Wanpeng Li <wanpengli@tencent.com>,
Vitaly Kuznetsov <vkuznets@redhat.com>,
Jani Nikula <jani.nikula@linux.intel.com>,
Paolo Bonzini <pbonzini@redhat.com>,
Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>,
Rodrigo Vivi <rodrigo.vivi@intel.com>,
Zhenyu Wang <zhenyuw@linux.intel.com>,
Joonas Lahtinen <joonas.lahtinen@linux.intel.com>,
Tom Lendacky <thomas.lendacky@amd.com>,
Ingo Molnar <mingo@redhat.com>, David Airlie <airlied@linux.ie>,
Thomas Gleixner <tglx@linutronix.de>,
Dave Hansen <dave.hansen@linux.intel.com>,
x86@kernel.org, intel-gfx@lists.freedesktop.org,
Sean Christopherson <seanjc@google.com>,
Daniel Vetter <daniel@ffwll.ch>, Borislav Petkov <bp@alien8.de>,
Joerg Roedel <joro@8bytes.org>,
linux-kernel@vger.kernel.org, Jim Mattson <jmattson@google.com>,
Zhi Wang <zhi.a.wang@intel.com>,
Brijesh Singh <brijesh.singh@amd.com>,
"H. Peter Anvin" <hpa@zytor.com>,
intel-gvt-dev@lists.freedesktop.org,
dri-devel@lists.freedesktop.org
Subject: Re: [RFC PATCH v3 02/19] KVM: x86: inhibit APICv/AVIC when the guest and/or host changes apic id/base from the defaults.
Date: Wed, 18 May 2022 19:51:01 +0800 [thread overview]
Message-ID: <20220518115056.GA18087@gao-cwp> (raw)
In-Reply-To: <8c78939bf01a98554696add10e17b07631d97a28.camel@redhat.com>
On Wed, May 18, 2022 at 12:50:27PM +0300, Maxim Levitsky wrote:
>> > struct kvm_arch {
>> > @@ -1258,6 +1260,7 @@ struct kvm_arch {
>> > hpa_t hv_root_tdp;
>> > spinlock_t hv_root_tdp_lock;
>> > #endif
>> > + bool apic_id_changed;
>>
>> What's the value of this boolean? No one reads it.
>
>I use it in later patches to kill the guest during nested VM entry
>if it attempts to use nested AVIC after any vCPU changed APIC ID.
>
>I mentioned this boolean in the commit description.
>
>This boolean avoids the need to go over all vCPUs and checking
>if they still have the initial apic id.
Do you want to kill the guest if APIC base got changed? If yes,
you can check if APICV_INHIBIT_REASON_RO_SETTINGS is set and save
the boolean.
>
>In the future maybe we can introduce a more generic 'taint'
>bitmap with various flags like that, indicating that the guest
>did something unexpected.
>
>BTW, the other option in regard to the nested AVIC is just to ignore this issue completely.
>The code itself always uses vcpu_id's, thus regardless of when/how often the guest changes
>its apic ids, my code would just use the initial APIC ID values consistently.
>
>In this case I won't need this boolean.
>
>>
>> > };
>> >
>> > struct kvm_vm_stat {
>> > diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
>> > index 66b0eb0bda94e..8996675b3ef4c 100644
>> > --- a/arch/x86/kvm/lapic.c
>> > +++ b/arch/x86/kvm/lapic.c
>> > @@ -2038,6 +2038,19 @@ static void apic_manage_nmi_watchdog(struct kvm_lapic *apic, u32 lvt0_val)
>> > }
>> > }
>> >
>> > +static void kvm_lapic_check_initial_apic_id(struct kvm_lapic *apic)
>> > +{
>> > + if (kvm_apic_has_initial_apic_id(apic))
>> > + return;
>> > +
>> > + pr_warn_once("APIC ID change is unsupported by KVM");
>>
>> It is misleading because changing xAPIC ID is supported by KVM; it just
>> isn't compatible with APICv. Probably this pr_warn_once() should be
>> removed.
>
>Honestly since nobody uses this feature, I am not sure if to call this supported,
>I am sure that KVM has more bugs in regard of using non standard APIC ID.
>This warning might hopefuly make someone complain about it if this
>feature is actually used somewhere.
Now I got you. It is fine to me.
next prev parent reply other threads:[~2022-05-18 11:51 UTC|newest]
Thread overview: 159+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-27 20:02 [Intel-gfx] [RFC PATCH v3 00/19] RFC: nested AVIC Maxim Levitsky
2022-04-27 20:02 ` Maxim Levitsky
2022-04-27 20:02 ` Maxim Levitsky
2022-04-27 20:02 ` [Intel-gfx] [RFC PATCH v3 01/19] KVM: x86: document AVIC/APICv inhibit reasons Maxim Levitsky
2022-04-27 20:02 ` Maxim Levitsky
2022-04-27 20:02 ` Maxim Levitsky
2022-05-18 15:56 ` Sean Christopherson
2022-05-18 15:56 ` Sean Christopherson
2022-05-18 17:13 ` [Intel-gfx] " Maxim Levitsky
2022-05-18 17:13 ` Maxim Levitsky
2022-05-18 17:13 ` Maxim Levitsky
2022-04-27 20:02 ` [Intel-gfx] [RFC PATCH v3 02/19] KVM: x86: inhibit APICv/AVIC when the guest and/or host changes apic id/base from the defaults Maxim Levitsky
2022-04-27 20:02 ` Maxim Levitsky
2022-04-27 20:02 ` Maxim Levitsky
2022-05-18 8:28 ` [Intel-gfx] " Chao Gao
2022-05-18 8:28 ` Chao Gao
2022-05-18 8:28 ` Chao Gao
2022-05-18 9:50 ` [Intel-gfx] " Maxim Levitsky
2022-05-18 9:50 ` Maxim Levitsky
2022-05-18 9:50 ` Maxim Levitsky
2022-05-18 11:51 ` Chao Gao [this message]
2022-05-18 11:51 ` Chao Gao
2022-05-18 11:51 ` Chao Gao
2022-05-18 12:36 ` [Intel-gfx] " Maxim Levitsky
2022-05-18 12:36 ` Maxim Levitsky
2022-05-18 12:36 ` Maxim Levitsky
2022-05-18 15:39 ` Sean Christopherson
2022-05-18 15:39 ` Sean Christopherson
2022-05-18 17:15 ` [Intel-gfx] " Maxim Levitsky
2022-05-18 17:15 ` Maxim Levitsky
2022-05-18 17:15 ` Maxim Levitsky
2022-05-19 16:06 ` Sean Christopherson
2022-05-19 16:06 ` Sean Christopherson
2022-05-22 9:03 ` [Intel-gfx] " Maxim Levitsky
2022-05-22 9:03 ` Maxim Levitsky
2022-05-22 9:03 ` Maxim Levitsky
2022-05-22 14:47 ` Jim Mattson
2022-05-22 14:47 ` Jim Mattson
2022-05-23 6:50 ` [Intel-gfx] " Maxim Levitsky
2022-05-23 6:50 ` Maxim Levitsky
2022-05-23 6:50 ` Maxim Levitsky
2022-05-23 17:22 ` Jim Mattson
2022-05-23 17:22 ` Jim Mattson
2022-05-23 17:31 ` Sean Christopherson
2022-05-23 17:31 ` Sean Christopherson
2022-06-23 9:44 ` [Intel-gfx] " Maxim Levitsky
2022-06-23 9:44 ` Maxim Levitsky
2022-06-23 9:44 ` Maxim Levitsky
2022-04-27 20:02 ` [Intel-gfx] [RFC PATCH v3 03/19] KVM: x86: SVM: remove avic's broken code that updated APIC ID Maxim Levitsky
2022-04-27 20:02 ` Maxim Levitsky
2022-04-27 20:02 ` Maxim Levitsky
2022-05-19 16:10 ` Sean Christopherson
2022-05-19 16:10 ` Sean Christopherson
2022-05-22 9:01 ` [Intel-gfx] " Maxim Levitsky
2022-05-22 9:01 ` Maxim Levitsky
2022-05-22 9:01 ` Maxim Levitsky
2022-05-23 17:19 ` Sean Christopherson
2022-05-23 17:19 ` Sean Christopherson
2022-04-27 20:02 ` [Intel-gfx] [RFC PATCH v3 04/19] KVM: x86: mmu: allow to enable write tracking externally Maxim Levitsky
2022-04-27 20:02 ` Maxim Levitsky
2022-04-27 20:02 ` Maxim Levitsky
2022-05-19 16:27 ` Sean Christopherson
2022-05-19 16:27 ` Sean Christopherson
2022-05-22 10:21 ` [Intel-gfx] " Maxim Levitsky
2022-05-22 10:21 ` Maxim Levitsky
2022-05-22 10:21 ` Maxim Levitsky
2022-05-19 16:37 ` Sean Christopherson
2022-05-19 16:37 ` Sean Christopherson
2022-05-22 10:22 ` [Intel-gfx] " Maxim Levitsky
2022-05-22 10:22 ` Maxim Levitsky
2022-05-22 10:22 ` Maxim Levitsky
2022-07-20 14:42 ` [Intel-gfx] " Maxim Levitsky
2022-07-20 14:42 ` Maxim Levitsky
2022-07-20 14:42 ` Maxim Levitsky
2022-07-25 16:08 ` [Intel-gfx] " Sean Christopherson
2022-07-25 16:08 ` Sean Christopherson
2022-07-25 16:08 ` Sean Christopherson
2022-07-28 7:46 ` [Intel-gfx] " Maxim Levitsky
2022-07-28 7:46 ` Maxim Levitsky
2022-07-28 7:46 ` Maxim Levitsky
2022-08-01 15:53 ` [Intel-gfx] " Maxim Levitsky
2022-08-01 15:53 ` Maxim Levitsky
2022-08-01 15:53 ` Maxim Levitsky
2022-08-01 17:20 ` [Intel-gfx] " Sean Christopherson
2022-08-01 17:20 ` Sean Christopherson
2022-08-01 17:20 ` Sean Christopherson
2022-08-08 13:13 ` [Intel-gfx] Nested AVIC design (was:Re: [RFC PATCH v3 04/19] KVM: x86: mmu: allow to enable write tracking externally) Maxim Levitsky
2022-08-08 13:13 ` Maxim Levitsky
2022-08-08 13:13 ` Maxim Levitsky
2022-09-29 22:38 ` [Intel-gfx] " Sean Christopherson
2022-09-29 22:38 ` Sean Christopherson
2022-09-29 22:38 ` Sean Christopherson
2022-10-03 7:27 ` [Intel-gfx] " Maxim Levitsky
2022-10-03 7:27 ` Maxim Levitsky
2022-10-03 7:27 ` Maxim Levitsky
2022-11-10 0:47 ` [Intel-gfx] " Sean Christopherson
2022-11-10 0:47 ` Sean Christopherson
2022-11-10 0:47 ` Sean Christopherson
2022-04-27 20:03 ` [Intel-gfx] [RFC PATCH v3 05/19] x86: KVMGT: use kvm_page_track_write_tracking_enable Maxim Levitsky
2022-04-27 20:03 ` Maxim Levitsky
2022-04-27 20:03 ` Maxim Levitsky
2022-05-19 16:38 ` Sean Christopherson
2022-05-19 16:38 ` Sean Christopherson
2022-04-27 20:03 ` [Intel-gfx] [RFC PATCH v3 06/19] KVM: x86: mmu: add gfn_in_memslot helper Maxim Levitsky
2022-04-27 20:03 ` Maxim Levitsky
2022-04-27 20:03 ` Maxim Levitsky
2022-05-19 16:43 ` Sean Christopherson
2022-05-19 16:43 ` Sean Christopherson
2022-05-22 10:22 ` [Intel-gfx] " Maxim Levitsky
2022-05-22 10:22 ` Maxim Levitsky
2022-05-22 10:22 ` Maxim Levitsky
2022-05-22 12:12 ` [Intel-gfx] " Maxim Levitsky
2022-05-22 12:12 ` Maxim Levitsky
2022-05-22 12:12 ` Maxim Levitsky
2022-04-27 20:03 ` [Intel-gfx] [RFC PATCH v3 07/19] KVM: x86: mmu: tweak fast path for emulation of access to nested NPT pages Maxim Levitsky
2022-04-27 20:03 ` Maxim Levitsky
2022-04-27 20:03 ` Maxim Levitsky
2022-04-27 20:03 ` [Intel-gfx] [RFC PATCH v3 08/19] KVM: x86: SVM: move avic state to separate struct Maxim Levitsky
2022-04-27 20:03 ` Maxim Levitsky
2022-04-27 20:03 ` Maxim Levitsky
2022-04-27 20:03 ` [Intel-gfx] [RFC PATCH v3 09/19] KVM: x86: nSVM: add nested AVIC tracepoints Maxim Levitsky
2022-04-27 20:03 ` Maxim Levitsky
2022-04-27 20:03 ` Maxim Levitsky
2022-04-27 20:03 ` [Intel-gfx] [RFC PATCH v3 10/19] KVM: x86: nSVM: implement AVIC's physid/logid table access helpers Maxim Levitsky
2022-04-27 20:03 ` Maxim Levitsky
2022-04-27 20:03 ` Maxim Levitsky
2022-04-27 20:03 ` [Intel-gfx] [RFC PATCH v3 11/19] KVM: x86: nSVM: implement shadowing of AVIC's physical id table Maxim Levitsky
2022-04-27 20:03 ` Maxim Levitsky
2022-04-27 20:03 ` Maxim Levitsky
2022-04-27 20:03 ` [Intel-gfx] [RFC PATCH v3 12/19] KVM: x86: nSVM: make nested AVIC physid write tracking be aware of the host scheduling Maxim Levitsky
2022-04-27 20:03 ` Maxim Levitsky
2022-04-27 20:03 ` Maxim Levitsky
2022-04-27 20:03 ` [Intel-gfx] [RFC PATCH v3 13/19] KVM: x86: nSVM: wire nested AVIC to nested guest entry/exit Maxim Levitsky
2022-04-27 20:03 ` Maxim Levitsky
2022-04-27 20:03 ` Maxim Levitsky
2022-04-27 20:03 ` [Intel-gfx] [RFC PATCH v3 14/19] KVM: x86: rename .set_apic_access_page_addr to reload_apic_access_page Maxim Levitsky
2022-04-27 20:03 ` Maxim Levitsky
2022-04-27 20:03 ` Maxim Levitsky
2022-05-19 16:55 ` Sean Christopherson
2022-05-19 16:55 ` Sean Christopherson
2022-05-22 10:22 ` [Intel-gfx] " Maxim Levitsky
2022-05-22 10:22 ` Maxim Levitsky
2022-05-22 10:22 ` Maxim Levitsky
2022-04-27 20:03 ` [Intel-gfx] [RFC PATCH v3 15/19] KVM: x86: nSVM: add code to reload AVIC physid table when it is invalidated Maxim Levitsky
2022-04-27 20:03 ` Maxim Levitsky
2022-04-27 20:03 ` Maxim Levitsky
2022-04-27 20:03 ` [Intel-gfx] [RFC PATCH v3 16/19] KVM: x86: nSVM: implement support for nested AVIC vmexits Maxim Levitsky
2022-04-27 20:03 ` Maxim Levitsky
2022-04-27 20:03 ` Maxim Levitsky
2022-04-27 20:03 ` [Intel-gfx] [RFC PATCH v3 17/19] KVM: x86: nSVM: implement nested AVIC doorbell emulation Maxim Levitsky
2022-04-27 20:03 ` Maxim Levitsky
2022-04-27 20:03 ` Maxim Levitsky
2022-04-27 20:03 ` [Intel-gfx] [RFC PATCH v3 18/19] KVM: x86: SVM/nSVM: add optional non strict AVIC doorbell mode Maxim Levitsky
2022-04-27 20:03 ` Maxim Levitsky
2022-04-27 20:03 ` Maxim Levitsky
2022-04-27 20:03 ` [Intel-gfx] [RFC PATCH v3 19/19] KVM: x86: nSVM: expose the nested AVIC to the guest Maxim Levitsky
2022-04-27 20:03 ` Maxim Levitsky
2022-04-27 20:03 ` Maxim Levitsky
2022-04-27 20:11 ` [Intel-gfx] ✗ Fi.CI.BUILD: failure for RFC: nested AVIC (rev2) Patchwork
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=20220518115056.GA18087@gao-cwp \
--to=chao.gao@intel.com \
--cc=airlied@linux.ie \
--cc=bp@alien8.de \
--cc=brijesh.singh@amd.com \
--cc=dave.hansen@linux.intel.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=hpa@zytor.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=intel-gvt-dev@lists.freedesktop.org \
--cc=jmattson@google.com \
--cc=joro@8bytes.org \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=mlevitsk@redhat.com \
--cc=pbonzini@redhat.com \
--cc=rodrigo.vivi@intel.com \
--cc=seanjc@google.com \
--cc=tglx@linutronix.de \
--cc=thomas.lendacky@amd.com \
--cc=vkuznets@redhat.com \
--cc=wanpengli@tencent.com \
--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.