Re: [PATCH] x86/dpci: remove the dpci EOI timer

[Jason Andryuk <jandryuk@xxxxxxxxx>]

On Thu, Jan 14, 2021 at 5:22 AM Roger Pau Monné <roger.pau@xxxxxxxxxx> wrote:
>
> On Wed, Jan 13, 2021 at 04:31:33PM -0500, Jason Andryuk wrote:
> > On Wed, Jan 13, 2021 at 1:34 PM Jason Andryuk <jandryuk@xxxxxxxxx> wrote:
> > >
> > > On Wed, Jan 13, 2021 at 1:06 PM Roger Pau Monné <roger.pau@xxxxxxxxxx> 
> > > wrote:
> > > >
> > > > On Wed, Jan 13, 2021 at 10:48:52AM -0500, Jason Andryuk wrote:
> >
> > <snip>
> >
> > > > > I have some laptops running OpenXT where the USB controller and NIC
> > > > > share an interrupt, and I assign them to different domains.  Qubes
> > > > > would hit this as well.
> > > >
> > > > Is there any chance you could try the patch and see if you can hit the
> > > > issue it was trying to fix?
> > >
> > > Would testing a backport to 4.12 be useful?  There were some file
> > > renames, but it looks to apply.  The only difference is the 4.12
> > > hvm_pirq_eoi hunk still has `(ent && ent->fields.mask) || `.  Maybe
> > > backport commit eb298f32fac5ac "x86/dpci: EOI interrupt regardless of
> > > its masking status" as well?
>
> Yes, backporting that one should be harmless.
>
> > Ok, I added these two patches to OpenXT with Xen 4.12.
>
> Thanks!
>
> > > Testing staging would take a little longer to make a machine available.
> > >
> > > I guess I'd also need to disable MSI for the two devices to ensure
> > > they are both using the GSI?
> >
> > lspci in dom0 shows the USB xhci controller, iwlwifi, and e1000e
> > devices all with IRQ 16 and all with MSI disabled ("MSI: Enabled-").
> > The two linux HVMs run with (PV) linux stubdoms, and the HVM kernels
> > were started with pci=nosmi.  Networking through the iwlwifi device

Jan, the VM kernel command lines had pci=nomsi and the typo was only
in the email.

> > works for that VM while a mouse attached to the xhci controller is
> > also working in the second VM.  Is there something else I should test?
>
> Not really, I think that test should be good enough, the issue is that
> we don't know which OS was seeing the issues noted by Kevin.
>
> To make sure you trigger the right scenario, could you start the
> iwlwifi HVM guest first, and then stress test the network device
> (using iperf for example) while you bring up the second VM that uses
> the xhci device?

I ran `cat /dev/zero | ssh server 'cat > /dev/null'` which generates
~1000 interrupts per second.

The second VM starts up ok.  Both are Linux 5.4.x, so not a version
Kevin would have tested :)

Regards,
Jason