From: Greg Kurz <groug@kaod.org> To: "Cédric Le Goater" <clg@kaod.org> Cc: Paul Mackerras <paulus@samba.org>, Alexey Kardashevskiy <aik@ozlabs.ru>, David Gibson <david@gibson.dropbear.id.au>, kvm@vger.kernel.org, kvm-ppc@vger.kernel.org Subject: Re: [PATCH] KVM: PPC: Book3S HV: XIVE: fix page offset when clearing ESB pages Date: Wed, 29 May 2019 11:06:57 +0200 [thread overview] Message-ID: <20190529110657.2dbd1d72@bahia.lab.toulouse-stg.fr.ibm.com> (raw) In-Reply-To: <20190528211324.18656-1-clg@kaod.org> On Tue, 28 May 2019 23:13:24 +0200 Cédric Le Goater <clg@kaod.org> wrote: > Under XIVE, the ESB pages of an interrupt are used for interrupt > management (EOI) and triggering. They are made available to guests > through a mapping of the XIVE KVM device. > > When a device is passed-through, the passthru_irq helpers, > kvmppc_xive_set_mapped() and kvmppc_xive_clr_mapped(), clear the ESB > pages of the guest IRQ number being mapped and let the VM fault > handler repopulate with the correct page. > > The ESB pages are mapped at offset 4 (KVM_XIVE_ESB_PAGE_OFFSET) in the > KVM device mapping. Unfortunately, this offset was not taken into > account when clearing the pages. This lead to issues with the Good catch ! :) Reviwed-by: Greg Kurz <groug@kaod.org> > passthrough devices for which the interrupts were not functional under > some guest configuration (tg3 and single CPU) or in any configuration And this patch fixes my tg3 use case. Tested-by: Greg Kurz <groug@kaod.org> > (e1000e adapter). > > Signed-off-by: Cédric Le Goater <clg@kaod.org> > --- > > if unmap_mapping_pages() could be called from a module, we would > simplify a bit this code. > > arch/powerpc/kvm/book3s_xive_native.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/arch/powerpc/kvm/book3s_xive_native.c b/arch/powerpc/kvm/book3s_xive_native.c > index 8b762e3ebbc5..5596c8ec221a 100644 > --- a/arch/powerpc/kvm/book3s_xive_native.c > +++ b/arch/powerpc/kvm/book3s_xive_native.c > @@ -172,6 +172,7 @@ int kvmppc_xive_native_connect_vcpu(struct kvm_device *dev, > static int kvmppc_xive_native_reset_mapped(struct kvm *kvm, unsigned long irq) > { > struct kvmppc_xive *xive = kvm->arch.xive; > + pgoff_t esb_pgoff = KVM_XIVE_ESB_PAGE_OFFSET + irq * 2; > > if (irq >= KVMPPC_XIVE_NR_IRQS) > return -EINVAL; > @@ -185,7 +186,7 @@ static int kvmppc_xive_native_reset_mapped(struct kvm *kvm, unsigned long irq) > mutex_lock(&xive->mapping_lock); > if (xive->mapping) > unmap_mapping_range(xive->mapping, > - irq * (2ull << PAGE_SHIFT), > + esb_pgoff << PAGE_SHIFT, > 2ull << PAGE_SHIFT, 1); > mutex_unlock(&xive->mapping_lock); > return 0;
WARNING: multiple messages have this Message-ID (diff)
From: Greg Kurz <groug@kaod.org> To: "Cédric Le Goater" <clg@kaod.org> Cc: Paul Mackerras <paulus@samba.org>, Alexey Kardashevskiy <aik@ozlabs.ru>, David Gibson <david@gibson.dropbear.id.au>, kvm@vger.kernel.org, kvm-ppc@vger.kernel.org Subject: Re: [PATCH] KVM: PPC: Book3S HV: XIVE: fix page offset when clearing ESB pages Date: Wed, 29 May 2019 09:06:57 +0000 [thread overview] Message-ID: <20190529110657.2dbd1d72@bahia.lab.toulouse-stg.fr.ibm.com> (raw) In-Reply-To: <20190528211324.18656-1-clg@kaod.org> On Tue, 28 May 2019 23:13:24 +0200 Cédric Le Goater <clg@kaod.org> wrote: > Under XIVE, the ESB pages of an interrupt are used for interrupt > management (EOI) and triggering. They are made available to guests > through a mapping of the XIVE KVM device. > > When a device is passed-through, the passthru_irq helpers, > kvmppc_xive_set_mapped() and kvmppc_xive_clr_mapped(), clear the ESB > pages of the guest IRQ number being mapped and let the VM fault > handler repopulate with the correct page. > > The ESB pages are mapped at offset 4 (KVM_XIVE_ESB_PAGE_OFFSET) in the > KVM device mapping. Unfortunately, this offset was not taken into > account when clearing the pages. This lead to issues with the Good catch ! :) Reviwed-by: Greg Kurz <groug@kaod.org> > passthrough devices for which the interrupts were not functional under > some guest configuration (tg3 and single CPU) or in any configuration And this patch fixes my tg3 use case. Tested-by: Greg Kurz <groug@kaod.org> > (e1000e adapter). > > Signed-off-by: Cédric Le Goater <clg@kaod.org> > --- > > if unmap_mapping_pages() could be called from a module, we would > simplify a bit this code. > > arch/powerpc/kvm/book3s_xive_native.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/arch/powerpc/kvm/book3s_xive_native.c b/arch/powerpc/kvm/book3s_xive_native.c > index 8b762e3ebbc5..5596c8ec221a 100644 > --- a/arch/powerpc/kvm/book3s_xive_native.c > +++ b/arch/powerpc/kvm/book3s_xive_native.c > @@ -172,6 +172,7 @@ int kvmppc_xive_native_connect_vcpu(struct kvm_device *dev, > static int kvmppc_xive_native_reset_mapped(struct kvm *kvm, unsigned long irq) > { > struct kvmppc_xive *xive = kvm->arch.xive; > + pgoff_t esb_pgoff = KVM_XIVE_ESB_PAGE_OFFSET + irq * 2; > > if (irq >= KVMPPC_XIVE_NR_IRQS) > return -EINVAL; > @@ -185,7 +186,7 @@ static int kvmppc_xive_native_reset_mapped(struct kvm *kvm, unsigned long irq) > mutex_lock(&xive->mapping_lock); > if (xive->mapping) > unmap_mapping_range(xive->mapping, > - irq * (2ull << PAGE_SHIFT), > + esb_pgoff << PAGE_SHIFT, > 2ull << PAGE_SHIFT, 1); > mutex_unlock(&xive->mapping_lock); > return 0;
next prev parent reply other threads:[~2019-05-29 16:12 UTC|newest] Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-05-28 21:13 [PATCH] KVM: PPC: Book3S HV: XIVE: fix page offset when clearing ESB pages Cédric Le Goater 2019-05-28 21:13 ` Cédric Le Goater 2019-05-29 9:06 ` Greg Kurz [this message] 2019-05-29 9:06 ` Greg Kurz 2019-05-31 6:36 ` Paul Mackerras 2019-05-31 6:36 ` Paul Mackerras 2020-11-05 13:47 [PATCH] KVM: PPC: Book3S HV: XIVE: Fix possible oops when accessing ESB page Cédric Le Goater 2020-11-05 13:47 ` Cédric Le Goater 2020-11-05 13:47 ` Cédric Le Goater 2020-11-05 17:41 ` Greg Kurz 2020-11-05 17:41 ` Greg Kurz 2020-11-05 17:41 ` Greg Kurz 2020-11-06 3:19 ` Michael Ellerman 2020-11-06 3:19 ` Michael Ellerman 2020-11-06 3:19 ` Michael Ellerman 2020-11-10 22:04 ` Cédric Le Goater 2020-11-10 22:04 ` Cédric Le Goater 2020-11-10 22:04 ` Cédric Le Goater 2020-11-16 12:29 ` Michael Ellerman 2020-11-16 12:29 ` Michael Ellerman 2020-11-16 12:29 ` Michael Ellerman 2020-11-17 10:52 ` Michael Ellerman
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=20190529110657.2dbd1d72@bahia.lab.toulouse-stg.fr.ibm.com \ --to=groug@kaod.org \ --cc=aik@ozlabs.ru \ --cc=clg@kaod.org \ --cc=david@gibson.dropbear.id.au \ --cc=kvm-ppc@vger.kernel.org \ --cc=kvm@vger.kernel.org \ --cc=paulus@samba.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: linkBe 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.