From: "Raj, Ashok" <ashok.raj@intel.com>
To: Alan Cox <gnomes@lxorguk.ukuu.org.uk>
Cc: Alex Williamson <alex.williamson@redhat.com>,
kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
iommu@lists.linux-foundation.org, Joerg Roedel <joro@8bytes.org>,
Bjorn Helgaas <helgaas@kernel.org>,
Gage Eads <gage.eads@intel.com>, Ashok Raj <ashok.raj@intel.com>
Subject: Re: [PATCH] vfio/pci: Some buggy virtual functions incorrectly report 1 for intx.
Date: Fri, 10 Aug 2018 09:54:05 -0700 [thread overview]
Message-ID: <20180810165405.GA82669@otc-nc-03> (raw)
In-Reply-To: <20180810174836.66d9791b@alans-desktop>
On Fri, Aug 10, 2018 at 05:48:36PM +0100, Alan Cox wrote:
> > The hardware isn't public yet, so can't talk about it :-(. Once this patch gets
> > merged, will let the OSV engagement folks drive it for inclusions. We
> > could mark this for stable, but i would rather wait until we know the
> > timeline when they are expecting it to be in. It shouldn't break anything
> > since we are just enforcing the spec.
>
> Until a new better spec appears...
Well, here we are talking about PIN interrupts and VF's. IMO it would be
weird to allow Virtual functions and physical interrupts other than MSIx.
There are other things in the PCIe spec which could be enforced in SW
or expect devices to implement them.
What might be ok is probably doing the right thing in SW as done in this
patch, additionaly maybe we can flag them and say "Your device is busted"
message.
>
> I know there is always fun when it comes to the people involved in
> such a screwup having to admit it in public but this should IMHO be
> tied to a PCI identifier table so that we know what the afflicted
> hardware is. Otherwise some day in the future SRIOV will grow new features
> and we'll have no idea what particular devices we need to narrow the
> workaround too and indeed not necessarily even know this device is the
> only one, as we'll silently fix other stuff then have it break on us
> later.
>
> Alan
next prev parent reply other threads:[~2018-08-10 16:54 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-08-09 19:37 [PATCH] vfio/pci: Some buggy virtual functions incorrectly report 1 for intx Ashok Raj
2018-08-09 19:44 ` Alex Williamson
2018-08-09 23:03 ` Raj, Ashok
2018-08-10 16:48 ` Alan Cox
2018-08-10 16:54 ` Raj, Ashok [this message]
2018-09-12 17:46 ` Raj, Ashok
2018-09-19 3:59 ` Alex Williamson
[not found] ` <20180919194617.GA14924@otc-nc-03>
2018-09-19 22:25 ` Eads, Gage
2018-09-19 22:47 ` Alex Williamson
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=20180810165405.GA82669@otc-nc-03 \
--to=ashok.raj@intel.com \
--cc=alex.williamson@redhat.com \
--cc=gage.eads@intel.com \
--cc=gnomes@lxorguk.ukuu.org.uk \
--cc=helgaas@kernel.org \
--cc=iommu@lists.linux-foundation.org \
--cc=joro@8bytes.org \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.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 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).