From: Matthew Rosato <mjrosato@linux.ibm.com>
To: Cornelia Huck <cohuck@redhat.com>
Cc: thuth@redhat.com, pmorel@linux.ibm.com, david@redhat.com,
schnelle@linux.ibm.com, richard.henderson@linaro.org,
qemu-s390x@nongnu.org, qemu-devel@nongnu.org,
pasic@linux.ibm.com, borntraeger@de.ibm.com,
alex.williamson@redhat.com, mst@redhat.com, pbonzini@redhat.com
Subject: Re: [RFC 2/8] s390x/pci: MSI-X isn't strictly required for passthrough
Date: Thu, 10 Dec 2020 10:13:29 -0500 [thread overview]
Message-ID: <9fc712d1-2350-f16f-7073-87162def13eb@linux.ibm.com> (raw)
In-Reply-To: <20201210112806.61b0c854.cohuck@redhat.com>
On 12/10/20 5:28 AM, Cornelia Huck wrote:
> On Wed, 9 Dec 2020 15:34:20 -0500
> Matthew Rosato <mjrosato@linux.ibm.com> wrote:
>
>> s390 PCI currently disallows PCI devices without the MSI-X capability.
>> However, this fence doesn't make sense for passthrough devices. Move
>> the check to only fence emulated devices (e.g., virtio).
>>
>> Signed-off-by: Matthew Rosato <mjrosato@linux.ibm.com>
>> Reviewed-by: Pierre Morel <pmorel@linux.ibm.com>
>> ---
>> hw/s390x/s390-pci-bus.c | 14 ++++++++------
>> 1 file changed, 8 insertions(+), 6 deletions(-)
>>
>> diff --git a/hw/s390x/s390-pci-bus.c b/hw/s390x/s390-pci-bus.c
>> index 05f7460..afad048 100644
>> --- a/hw/s390x/s390-pci-bus.c
>> +++ b/hw/s390x/s390-pci-bus.c
>> @@ -1028,12 +1028,12 @@ static void s390_pcihost_plug(HotplugHandler *hotplug_dev, DeviceState *dev,
>> s390_pci_get_clp_info(pbdev);
>> } else {
>> pbdev->fh |= FH_SHM_EMUL;
>> - }
>>
>> - if (s390_pci_msix_init(pbdev)) {
>> - error_setg(errp, "MSI-X support is mandatory "
>> - "in the S390 architecture");
>> - return;
>> + if (s390_pci_msix_init(pbdev)) {
>> + error_setg(errp, "MSI-X support is mandatory "
>> + "in the S390 architecture");
>> + return;
>> + }
>> }
>>
>> if (dev->hotplugged) {
>> @@ -1073,7 +1073,9 @@ static void s390_pcihost_unplug(HotplugHandler *hotplug_dev, DeviceState *dev,
>> devfn = pci_dev->devfn;
>> qdev_unrealize(dev);
>>
>> - s390_pci_msix_free(pbdev);
>> + if (pbdev->fh & FH_SHM_EMUL) {
>> + s390_pci_msix_free(pbdev);
>> + }
>> s390_pci_iommu_free(s, bus, devfn);
>> pbdev->pdev = NULL;
>> pbdev->state = ZPCI_FS_RESERVED;
>
> Remind me: Wasn't it only msi that was strictly required (i.e., not msi-x?)
>
> Can we generally relax this requirement, possibly with some changes in
> the adapter interrupt mapping? I might misremember, though.
>
Yes, but even so our current emulation support only sets up for MSI-X,
it does not have an msi_init() equivalent. I do believe that this
requirement can be relaxed at some point for the emulation support as
well, but the focus on this set was to at least stop fencing passthrough
for no reason.
next prev parent reply other threads:[~2020-12-10 15:16 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-09 20:34 [RFC 0/8] s390x/pci: Fixing s390 vfio-pci ISM support Matthew Rosato
2020-12-09 20:34 ` [RFC 1/8] linux-headers: update against 5.10-rc7 Matthew Rosato
2020-12-09 20:34 ` [RFC 2/8] s390x/pci: MSI-X isn't strictly required for passthrough Matthew Rosato
2020-12-10 10:28 ` Cornelia Huck
2020-12-10 15:13 ` Matthew Rosato [this message]
2020-12-17 13:08 ` Cornelia Huck
2020-12-17 15:12 ` Matthew Rosato
2020-12-09 20:34 ` [RFC 3/8] s390x/pci: fix pcistb length Matthew Rosato
2020-12-10 10:30 ` Cornelia Huck
2020-12-10 15:15 ` Matthew Rosato
2020-12-17 13:09 ` Cornelia Huck
2020-12-09 20:34 ` [RFC 4/8] s390x/pci: Introduce the ZpciOps structure Matthew Rosato
2020-12-09 20:34 ` [RFC 5/8] s390x/pci: Fix memory_region_access_valid call Matthew Rosato
2020-12-10 12:15 ` Cornelia Huck
2020-12-09 20:34 ` [RFC 6/8] s390x/pci: Handle devices that support relaxed alignment Matthew Rosato
2020-12-09 20:34 ` [RFC 7/8] s390x/pci: PCISTB via the vfio zPCI I/O region Matthew Rosato
2020-12-09 20:34 ` [RFC 8/8] s390x/pci: PCILG " Matthew Rosato
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=9fc712d1-2350-f16f-7073-87162def13eb@linux.ibm.com \
--to=mjrosato@linux.ibm.com \
--cc=alex.williamson@redhat.com \
--cc=borntraeger@de.ibm.com \
--cc=cohuck@redhat.com \
--cc=david@redhat.com \
--cc=mst@redhat.com \
--cc=pasic@linux.ibm.com \
--cc=pbonzini@redhat.com \
--cc=pmorel@linux.ibm.com \
--cc=qemu-devel@nongnu.org \
--cc=qemu-s390x@nongnu.org \
--cc=richard.henderson@linaro.org \
--cc=schnelle@linux.ibm.com \
--cc=thuth@redhat.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).