qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Yi Min Zhao <zyimin@linux.vnet.ibm.com>
To: Cornelia Huck <cohuck@redhat.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 4/4] s390x/pci: add iommu replay callback
Date: Tue, 29 Aug 2017 16:26:10 +0800	[thread overview]
Message-ID: <0d7cc071-cebe-82d5-90da-9737a5f0733e@linux.vnet.ibm.com> (raw)
In-Reply-To: <20170829100746.66c47fd8.cohuck@redhat.com>



在 2017/8/29 下午4:07, Cornelia Huck 写道:
> [Restored cc:s. Please remember to do reply-all.]
>
> On Tue, 29 Aug 2017 12:46:51 +0800
> Yi Min Zhao <zyimin@linux.vnet.ibm.com> wrote:
>
>> 在 2017/8/28 下午11:57, Cornelia Huck 写道:
>>> On Mon, 28 Aug 2017 10:04:47 +0200
>>> Yi Min Zhao <zyimin@linux.vnet.ibm.com> wrote:
>>>
>>>> Let's introduce iommu replay callback for s390 pci iommu memory region.
>>>> Currently we don't need any dma mapping replay. So let it return
>>>> directly. This implementation will avoid meaningless loops calling
>>>> translation callback.
>>>>
>>>> Reviewed-by: Pierre Morel <pmorel@linux.vnet.ibm.com>
>>>> Reviewed-by: Halil Pasic <pasic@linux.vnet.ibm.com>
>>>> Signed-off-by: Yi Min Zhao <zyimin@linux.vnet.ibm.com>
>>>> ---
>>>>    hw/s390x/s390-pci-bus.c | 8 ++++++++
>>>>    1 file changed, 8 insertions(+)
>>>>
>>>> diff --git a/hw/s390x/s390-pci-bus.c b/hw/s390x/s390-pci-bus.c
>>>> index 9e1f7ff5c5..359509ccea 100644
>>>> --- a/hw/s390x/s390-pci-bus.c
>>>> +++ b/hw/s390x/s390-pci-bus.c
>>>> @@ -407,6 +407,13 @@ static IOMMUTLBEntry s390_translate_iommu(IOMMUMemoryRegion *mr, hwaddr addr,
>>>>        return ret;
>>>>    }
>>>>    
>>>> +static void s390_pci_iommu_replay(IOMMUMemoryRegion *iommu,
>>>> +                                  IOMMUNotifier *notifier)
>>>> +{
>>>> +    /* we don't need iommu replay currently */
>>> This really needs to be heavier on the _why_. My guess is that anything
>>> which would require replay goes through the rpcit instruction?
>> My understanding is:
>> Our arch is different from others. Each pci device has its own iommu, not
>> like other archs' implementation. So currently there must be no existing
>> mappings belonging to any newly plugged pci device whose iommu doesn't
>> have any mapping at the time.
> So please put that explanation into the function. (Also, "currently"?
> Are we expecting it to change?)
The iommu replay function is originally introduced for vfio. I think 
they want to re-build
the existing mappings because vfio has a copy of mappings in kernel. For 
our case,
the mappings would be cleanup when a pci device unplugged, and new mappings
would be created when a pci device plugged. I think replay only can 
happen during
vfio-pci device migration.
>
>> In addition, it's also due to vfio blocking migration. If vfio-pci supports
>> migration in future, we could implement iommu replay by that time.
> That's not an argument: This is the base zpci support, it should not
> depend on the supported devices and what they do. (What's the status of
> virtio-pci, btw? Does it work with your patches applied, or is there
> still more to be done?)
>
>
My understanding is virtio-pci doesn't need replay. All mappings of any 
pci device are existing in
guest memory. Once the mappings is built, all of them could be migrated 
along with the guest
system. But I might misunderstand it. Please correct me.

  reply	other threads:[~2017-08-29  8:26 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-28  8:04 [Qemu-devel] [PATCH 0/4] four zpci patches Yi Min Zhao
2017-08-28  8:04 ` [Qemu-devel] [PATCH 1/4] s390x/pci: fixup trap_msix() Yi Min Zhao
2017-08-28 14:51   ` Cornelia Huck
2017-08-29  4:32     ` Yi Min Zhao
2017-08-29  8:00       ` Cornelia Huck
2017-08-29  8:05         ` Yi Min Zhao
2017-08-29  8:12         ` Yi Min Zhao
2017-08-29  8:22           ` Cornelia Huck
2017-08-29  8:33             ` Yi Min Zhao
2017-08-29  8:58               ` Cornelia Huck
2017-08-30  9:47   ` Cornelia Huck
2017-08-28  8:04 ` [Qemu-devel] [PATCH 2/4] s390x/pci: remove idx from msix msg data Yi Min Zhao
2017-08-28 15:04   ` Cornelia Huck
2017-08-29  4:33     ` Yi Min Zhao
2017-08-28  8:04 ` [Qemu-devel] [PATCH 3/4] s390x/pci: fixup ind_offset of msix routing entry Yi Min Zhao
2017-08-28 15:33   ` Cornelia Huck
2017-08-29  4:39     ` Yi Min Zhao
2017-08-28  8:04 ` [Qemu-devel] [PATCH 4/4] s390x/pci: add iommu replay callback Yi Min Zhao
2017-08-28 15:57   ` Cornelia Huck
2017-08-29  4:46     ` Yi Min Zhao
2017-08-29  8:07       ` Cornelia Huck
2017-08-29  8:26         ` Yi Min Zhao [this message]
2017-08-29  9:33           ` Cornelia Huck
2017-08-29  9:49             ` Cornelia Huck
2017-08-29  9:53               ` Yi Min Zhao
2017-08-29  9:51             ` Yi Min Zhao
2017-08-29  9:57               ` Cornelia Huck
2017-08-29 10:00                 ` 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=0d7cc071-cebe-82d5-90da-9737a5f0733e@linux.vnet.ibm.com \
    --to=zyimin@linux.vnet.ibm.com \
    --cc=agraf@suse.de \
    --cc=borntraeger@de.ibm.com \
    --cc=cohuck@redhat.com \
    --cc=pasic@linux.vnet.ibm.com \
    --cc=pmorel@linux.vnet.ibm.com \
    --cc=qemu-devel@nongnu.org \
    --cc=richard.henderson@linaro.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).