All of lore.kernel.org
 help / color / mirror / Atom feed
From: Cornelia Huck <cohuck@redhat.com>
To: Yi Min Zhao <zyimin@linux.vnet.ibm.com>
Cc: qemu-devel@nongnu.org, borntraeger@de.ibm.com,
	pasic@linux.vnet.ibm.com, pmorel@linux.vnet.ibm.com,
	agraf@suse.de, richard.henderson@linaro.org
Subject: Re: [Qemu-devel] [PATCH v2 1/3] s390x/pci: remove idx from msix msg data
Date: Tue, 5 Sep 2017 11:15:40 +0200	[thread overview]
Message-ID: <20170905111540.027058d1.cohuck@redhat.com> (raw)
In-Reply-To: <07ef5826-6b09-5ac8-7d51-d00db7170437@linux.vnet.ibm.com>

On Tue, 5 Sep 2017 17:08:14 +0800
Yi Min Zhao <zyimin@linux.vnet.ibm.com> wrote:

> 在 2017/9/5 下午4:50, Cornelia Huck 写道:
> > On Tue, 5 Sep 2017 16:44:37 +0800
> > Yi Min Zhao <zyimin@linux.vnet.ibm.com> wrote:
> >  
> >> 在 2017/9/5 下午4:29, Cornelia Huck 写道:  
> >>> On Fri,  1 Sep 2017 06:22:56 +0200
> >>> Yi Min Zhao <zyimin@linux.vnet.ibm.com> wrote:
> >>>     
> >>>> PCIDevice pointer has been a parameter of kvm_arch_fixup_msi_route().
> >>>> So we don't need to store zpci idx in msix message data to find out the
> >>>> specific zpci device. Instead, we could use pci device id to find its
> >>>> corresponding zpci device.
> >>>>
> >>>> Signed-off-by: Yi Min Zhao <zyimin@linux.vnet.ibm.com>
> >>>> ---
> >>>>    hw/s390x/s390-pci-bus.c  | 16 +++++-----------
> >>>>    hw/s390x/s390-pci-bus.h  |  2 ++
> >>>>    hw/s390x/s390-pci-inst.c | 24 ------------------------
> >>>>    hw/s390x/s390-pci-stub.c |  6 ++++++
> >>>>    target/s390x/kvm.c       |  7 +++++--
> >>>>    5 files changed, 18 insertions(+), 37 deletions(-)
> >>>>

> >>>> diff --git a/target/s390x/kvm.c b/target/s390x/kvm.c
> >>>> index 1338c29528..3d490c5e4b 100644
> >>>> --- a/target/s390x/kvm.c
> >>>> +++ b/target/s390x/kvm.c
> >>>> @@ -2533,10 +2533,13 @@ int kvm_arch_fixup_msi_route(struct kvm_irq_routing_entry *route,
> >>>>                                 uint64_t address, uint32_t data, PCIDevice *dev)
> >>>>    {
> >>>>        S390PCIBusDevice *pbdev;
> >>>> -    uint32_t idx = data >> ZPCI_MSI_VEC_BITS;
> >>>>        uint32_t vec = data & ZPCI_MSI_VEC_MASK;
> >>>>    
> >>>> -    pbdev = s390_pci_find_dev_by_idx(s390_get_phb(), idx);
> >>>> +    if (!dev) {
> >>>> +        return -ENODEV;  
> >>> Can this actually happen?  
> >> I think this cannot happen. But I'm afraid that I miss something.
> >> So I added this to avoid NULL pointer. But from the code and
> >> my test, there has not been NULL pointer happened.  
> > I'm wondering if that is in the same category as the instance I
> > commented on above. Do you want to log something?
> >  
> For the case above, I ensure that zpci device must exist. But here, I'm 
> not sure.
> Because it's called from outside. I'm not sure if the caller might call
> kvm_irqchip_add_msi_route() with NULL as pci device argument.
> 
> Although msix ctrl mr is accessed from outside. But its initialization
> is controled by our code and the pointer to zpci device is saved as
> mr's opaque.

OK. Maybe add a DPRINTF as for the condition below?

> >>>     
> >>>> +    }
> >>>> +
> >>>> +    pbdev = s390_pci_find_dev_by_target(s390_get_phb(), DEVICE(dev)->id);
> >>>>        if (!pbdev) {
> >>>>            DPRINTF("add_msi_route no dev\n");
> >>>>            return -ENODEV;  
> >>>     
> >  
> 

  reply	other threads:[~2017-09-05  9:15 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-09-01  4:22 [Qemu-devel] [PATCH v2 0/3] three zpci patches Yi Min Zhao
2017-09-01  4:22 ` [Qemu-devel] [PATCH v2 1/3] s390x/pci: remove idx from msix msg data Yi Min Zhao
2017-09-05  8:29   ` Cornelia Huck
2017-09-05  8:44     ` Yi Min Zhao
2017-09-05  8:50       ` Cornelia Huck
2017-09-05  9:08         ` Yi Min Zhao
2017-09-05  9:15           ` Cornelia Huck [this message]
2017-09-05  9:21             ` Yi Min Zhao
2017-09-05  9:25               ` Cornelia Huck
2017-09-01  4:22 ` [Qemu-devel] [PATCH v2 2/3] s390x/pci: fixup ind_offset of msix routing entry Yi Min Zhao
2017-09-05  9:29   ` Cornelia Huck
2017-09-01  4:22 ` [Qemu-devel] [PATCH v2 3/3] s390x/pci: add iommu replay callback Yi Min Zhao
2017-09-05  9:28   ` Cornelia Huck
2017-09-05  9:51     ` Yi Min Zhao

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=20170905111540.027058d1.cohuck@redhat.com \
    --to=cohuck@redhat.com \
    --cc=agraf@suse.de \
    --cc=borntraeger@de.ibm.com \
    --cc=pasic@linux.vnet.ibm.com \
    --cc=pmorel@linux.vnet.ibm.com \
    --cc=qemu-devel@nongnu.org \
    --cc=richard.henderson@linaro.org \
    --cc=zyimin@linux.vnet.ibm.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.