From: "Roger Pau Monné" <roger.pau@citrix.com>
To: Sander Eikelenboom <linux@eikelenboom.it>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] Xen-unstable: pci-passthrough regression bisected to: x86/smp: use APIC ALLBUT destination shorthand when possible
Date: Wed, 5 Feb 2020 11:23:56 +0100 [thread overview]
Message-ID: <20200205102356.GQ4679@Air-de-Roger> (raw)
In-Reply-To: <20200203132108.GW4679@Air-de-Roger>
Ping?
On Mon, Feb 03, 2020 at 02:21:08PM +0100, Roger Pau Monné wrote:
> On Mon, Feb 03, 2020 at 01:44:06PM +0100, Sander Eikelenboom wrote:
> > On 03/02/2020 13:41, Roger Pau Monné wrote:
> > > On Mon, Feb 03, 2020 at 01:30:55PM +0100, Sander Eikelenboom wrote:
> > >> On 03/02/2020 13:23, Roger Pau Monné wrote:
> > >>> On Mon, Feb 03, 2020 at 09:33:51AM +0100, Sander Eikelenboom wrote:
> > >>>> Hi Roger,
> > >>>>
> > >>>> Last week I encountered an issue with the PCI-passthrough of a USB controller.
> > >>>> In the guest I get:
> > >>>> [ 1143.313756] xhci_hcd 0000:00:05.0: xHCI host not responding to stop endpoint command.
> > >>>> [ 1143.334825] xhci_hcd 0000:00:05.0: xHCI host controller not responding, assume dead
> > >>>> [ 1143.347364] xhci_hcd 0000:00:05.0: HC died; cleaning up
> > >>>> [ 1143.356407] usb 1-2: USB disconnect, device number 2
> > >>>>
> > >>>> Bisection turned up as the culprit:
> > >>>> commit 5500d265a2a8fa63d60c08beb549de8ec82ff7a5
> > >>>> x86/smp: use APIC ALLBUT destination shorthand when possible
> > >>>
> > >>> Sorry to hear that, let see if we can figure out what's wrong.
> > >>
> > >> No problem, that is why I test stuff :)
> > >>
> > >>>> I verified by reverting that commit and now it works fine again.
> > >>>
> > >>> Does the same controller work fine when used in dom0?
> > >>
> > >> Will test that, but as all other pci devices in dom0 work fine,
> > >> I assume this controller would also work fine in dom0 (as it has also
> > >> worked fine for ages with PCI-passthrough to that guest and still works
> > >> fine when reverting the referenced commit).
> > >
> > > Is this the only device that fails to work when doing pci-passthrough,
> > > or other devices also don't work with the mentioned change applied?
> > >
> > > Have you tested on other boxes?
> > >
> > >> I don't know if your change can somehow have a side effect
> > >> on latency around the processing of pci-passthrough ?
> > >
> > > Hm, the mentioned commit should speed up broadcast IPIs, but I don't
> > > see how it could slow down other interrupts. Also I would think the
> > > domain is not receiving interrupts from the device, rather than
> > > interrupts being slow.
> > >
> > > Can you also paste the output of lspci -v for that xHCI device from
> > > dom0?
> > >
> > > Thanks, Roger.
> >
> > Will do this evening including the testing in dom0 etc.
> > Will also see if there is any pattern when observing /proc/interrupts in
> > the guest.
>
> Thanks! I also have some trivial patch that I would like you to try,
> just to discard send_IPI_mask clearing the scratch_cpumask under
> another function feet.
>
> Roger.
> ---
> diff --git a/xen/arch/x86/smp.c b/xen/arch/x86/smp.c
> index 65eb7cbda8..aeeb506155 100644
> --- a/xen/arch/x86/smp.c
> +++ b/xen/arch/x86/smp.c
> @@ -66,7 +66,8 @@ static void send_IPI_shortcut(unsigned int shortcut, int vector,
> void send_IPI_mask(const cpumask_t *mask, int vector)
> {
> bool cpus_locked = false;
> - cpumask_t *scratch = this_cpu(scratch_cpumask);
> + static DEFINE_PER_CPU(cpumask_t, send_ipi_cpumask);
> + cpumask_t *scratch = &this_cpu(send_ipi_cpumask);
>
> /*
> * This can only be safely used when no CPU hotplug or unplug operations
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xenproject.org
> https://lists.xenproject.org/mailman/listinfo/xen-devel
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
next prev parent reply other threads:[~2020-02-05 10:24 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-03 8:33 [Xen-devel] Xen-unstable: pci-passthrough regression bisected to: x86/smp: use APIC ALLBUT destination shorthand when possible Sander Eikelenboom
2020-02-03 12:23 ` Roger Pau Monné
2020-02-03 12:30 ` Sander Eikelenboom
2020-02-03 12:41 ` Roger Pau Monné
2020-02-03 12:44 ` Sander Eikelenboom
2020-02-03 13:21 ` Roger Pau Monné
2020-02-05 10:23 ` Roger Pau Monné [this message]
2020-02-05 11:03 ` Sander Eikelenboom
2020-02-05 11:18 ` Roger Pau Monné
2020-02-10 20:49 ` Sander Eikelenboom
2020-02-11 14:00 ` Roger Pau Monné
2020-02-12 8:46 ` Sander Eikelenboom
2020-02-12 9:10 ` Roger Pau Monné
2020-02-03 12:49 ` Jan Beulich
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=20200205102356.GQ4679@Air-de-Roger \
--to=roger.pau@citrix.com \
--cc=linux@eikelenboom.it \
--cc=xen-devel@lists.xenproject.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).