qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Roger Pau Monné" <roger.pau@citrix.com>
To: Zhao Yan <yan.y.zhao@intel.com>
Cc: sstabellini@kernel.org, anthony.perard@citrix.com,
	xen-devel@lists.xenproject.org, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH] Xen PCI passthrough: fix passthrough failure when irq map failure
Date: Thu, 22 Nov 2018 15:18:05 +0100	[thread overview]
Message-ID: <20181122141805.vyqywi4ep65loye3@mac> (raw)
In-Reply-To: <20181122131110.GA31906@joy-OptiPlex-7040>

On Thu, Nov 22, 2018 at 08:11:20AM -0500, Zhao Yan wrote:
> On Thu, Oct 18, 2018 at 03:56:36PM +0100, Roger Pau Monné wrote:
> > On Thu, Oct 18, 2018 at 08:22:41AM +0000, Zhao, Yan Y wrote:
> > > Hi
> > > The background for this patch is that: for some pci device, even it's PCI_INTERRUPT_PIN is not 0, it actually does not support INTx mode, so we should just report error, disable INTx mode and continue the passthrough.
> > > However, the commit 5a11d0f7 regards this as error condition and let qemu quit passthrough, which is too rigorous.
> > > 
> > > Error message is below:
> > > libxl: error: libxl_qmp.c:287:qmp_handle_error_response: Domain 2:received an error message from QMP server: Mapping machine irq 0 to pirq -1 failed: Operation not permitted
> > 
> > I'm having issues figuring out what's happening here.
> > s->real_device.irq is 0, yet the PCI config space read of
> > PCI_INTERRUPT_PIN returns something different than 0.
> > 
> > AFAICT this is due to some kind of error in Linux, so that even when
> > the device is supposed to have a valid IRQ the sysfs node it is set to
> > 0, do you know the actual underlying cause of this?
> > 
> > Thanks, Roger.
> Hi Roger
> Sorry for the later reply, I just missed this mail...
> On my side, it's because the hardware actually does not support INTx mode,
> but its configuration space does not report PCI_INTERRUPT_PIN to 0. It's a
> hardware bug, but previous version of qemu can tolerate it, switch to MSI
> and make passthrough work.

Then I think it would be better to check both PCI_INTERRUPT_PIN and
s->real_device.irq before attempting to map the IRQ.

Making the error non-fatal would mean that a device with a valid IRQ
could fail to be setup correctly but the guest will still be created,
and things won't go as expected when the guest attempts to use it.

Thanks, Roger.

  reply	other threads:[~2018-11-22 14:18 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-16  2:14 [Qemu-devel] [PATCH] Xen PCI passthrough: fix passthrough failure when irq map failure Zhao Yan
2018-10-18  8:22 ` Zhao, Yan Y
2018-10-18 14:56   ` Roger Pau Monné
2018-11-22 13:11     ` Zhao Yan
2018-11-22 14:18       ` Roger Pau Monné [this message]
2018-11-23  5:04         ` Zhao Yan
2018-11-23 10:19           ` Roger Pau Monné
2018-11-23 10:26             ` Jan Beulich
2018-11-26  1:58               ` Zhao Yan

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=20181122141805.vyqywi4ep65loye3@mac \
    --to=roger.pau@citrix.com \
    --cc=anthony.perard@citrix.com \
    --cc=qemu-devel@nongnu.org \
    --cc=sstabellini@kernel.org \
    --cc=xen-devel@lists.xenproject.org \
    --cc=yan.y.zhao@intel.com \
    /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).