qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Halil Pasic <pasic@linux.ibm.com>
To: Pierre Morel <pmorel@linux.ibm.com>
Cc: Collin Walling <walling@linux.ibm.com>,
	thuth@redhat.com, david@redhat.com, cohuck@redhat.com,
	qemu-devel@nongnu.org, borntraeger@de.ibm.com,
	qemu-s390x@nongnu.org, rth@twiddle.net
Subject: Re: [Qemu-devel] [PATCH v2] s390x/pci: Set the iommu region size mpcifc request
Date: Wed, 16 Jan 2019 15:50:11 +0100	[thread overview]
Message-ID: <20190116155011.478db4da@oc2783563651> (raw)
In-Reply-To: <1188d21d-3603-c291-e69b-38d341ae90f4@linux.ibm.com>

On Wed, 16 Jan 2019 15:16:44 +0100
Pierre Morel <pmorel@linux.ibm.com> wrote:

> On 16/01/2019 13:40, Halil Pasic wrote:
> > On Tue, 15 Jan 2019 10:35:42 -0500
> > Collin Walling <walling@linux.ibm.com> wrote:
> > 
> >> On 1/10/19 8:00 AM, Pierre Morel wrote:
> >>> The size of the accessible iommu memory region in the guest
> >>> is given to the IOMMU by the guest through the mpcifc request
> >>> specifying the PCI Base Address and the PCI Address Limit.
> >>>
> >>> Let set the size of the IOMMU region to:
> >>>       (PCI Address Limit) - (PCI Base Address) + 1.
> >>>
> >>> Signed-off-by: Pierre Morel <pmorel@linux.ibm.com>
> >>> ---
> >>>    hw/s390x/s390-pci-bus.c | 2 +-
> >>>    1 file changed, 1 insertion(+), 1 deletion(-)
> >>>
> >>> diff --git a/hw/s390x/s390-pci-bus.c b/hw/s390x/s390-pci-bus.c
> >>> index 69e0671..e97696a 100644
> >>> --- a/hw/s390x/s390-pci-bus.c
> >>> +++ b/hw/s390x/s390-pci-bus.c
> >>> @@ -660,7 +660,7 @@ void s390_pci_iommu_enable(S390PCIIOMMU *iommu)
> >>>        char *name = g_strdup_printf("iommu-s390-%04x", iommu->pbdev->uid);
> >>>        memory_region_init_iommu(&iommu->iommu_mr, sizeof(iommu->iommu_mr),
> >>>                                 TYPE_S390_IOMMU_MEMORY_REGION, OBJECT(&iommu->mr),
> >>> -                             name, iommu->pal + 1);
> >>> +                             name, iommu->pal - iommu->pba + 1);
> > 
> >  From the the look of this, I would say we basically used the address
> > denoting the end of the region as the size of the region. This smells
> > like a bug to me, but the commit message and the title ain't clear about
> > this, and there is no fixes tag. Because of the latter I did some digging
> > and came to commit f7c40aa "s390x/pci: fix failures of dma
> > map/unmap" (Yi Min Zhao, 2016-06-19) which basically did the inverse of
> > this commit!
> > 
> > My initial motivation was to check if this is stable material. But now
> > I'm very confused. I'm admittedly zPCI incompetent. Could some of the
> > people that understand what is going on help me feel better about this
> > patch?
> > 
> > Regards,
> > Halil
> 
> 
> The patch you speak about corrected the problem described in its comment 
> by setting the offset address of the subregion to 0, making sure 
> VFIO_PCI works for Z but introduced a bug we did not see at that time by 
> making the subregion too large.
> 
> This patch correct the bug, I can add a reference to this with:
> fixing: commit f7c40aa1e7feb50bc4d4bc171fa811bdd9a93e51
> 

@Connie, will you add the Fixes tag? Do we need a cc stable (since
broken since 2016-06-19)?

@Pierre: So you say it's a bug. What can go wrong because of this?
For example if we interpret pal as a size, I guess we could end up with
the memory region not fitting the guest memory, or? I'm still pretty
much in the dark about the implications of this bug.

Regards,
Halil

  parent reply	other threads:[~2019-01-16 14:50 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-10 13:00 [Qemu-devel] [PATCH v2] s390x/pci: Set the iommu region size as guest wants Pierre Morel
2019-01-10 13:00 ` [Qemu-devel] [PATCH v2] s390x/pci: Set the iommu region size mpcifc request Pierre Morel
2019-01-15 13:59   ` Cornelia Huck
2019-01-15 15:35   ` Collin Walling
2019-01-16 12:40     ` Halil Pasic
2019-01-16 14:16       ` Pierre Morel
2019-01-16 14:34         ` Cornelia Huck
2019-01-16 14:50         ` Halil Pasic [this message]
2019-01-16 15:44           ` Pierre Morel
2019-01-16 16:41             ` Cornelia Huck
2019-01-17 15:13               ` Halil Pasic
2019-01-15 15:47   ` Cornelia Huck
2019-01-15 17:35     ` Pierre Morel

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=20190116155011.478db4da@oc2783563651 \
    --to=pasic@linux.ibm.com \
    --cc=borntraeger@de.ibm.com \
    --cc=cohuck@redhat.com \
    --cc=david@redhat.com \
    --cc=pmorel@linux.ibm.com \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-s390x@nongnu.org \
    --cc=rth@twiddle.net \
    --cc=thuth@redhat.com \
    --cc=walling@linux.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 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).