do not need to confuse users with noiommu
> devices that are safe and assignable and devices where noiommu should
> warn them to stay away. Thanks,
Understand. But like explained above, even if we introduce a new vfio
iommu backend, what it does would probably look quite like what the
no-iommu backend does. Any idea about this?
>
> Alex
>
Dong Jia
On Wed, 4 May 2016 13:26:53 -0600
Alex Williamson wrote:
> On Wed, 4 May 2016 17:26:29 +0800
> Dong Jia wrote:
>
> > On Fri, 29 Apr 2016 11:17:35 -0600
> > Alex Williamson wrote:
> >
> > Dear Alex:
> >
> > Thanks for the comments.
> >
>
On Thu, 5 May 2016 13:19:45 -0600
Alex Williamson wrote:
> [cc +Intel,NVIDIA]
>
> On Thu, 5 May 2016 18:29:08 +0800
> Dong Jia wrote:
>
> > On Wed, 4 May 2016 13:26:53 -0600
> > Alex Williamson wrote:
> >
> > > On Wed, 4 May 2016 17:26:29 +0800
>
So which one is the right way to go?
> >
> > As above, I think we have a need to support both approaches in this new
> > iommu backend, it will be up to you to determine which is appropriate
> > for your devices and guest drivers. A fully pinned guest has a latency
> > advantage, but obviously there are numerous disadvantages for the
> > pinning itself. Pinning on-demand has overhead to setup each DMA
> > operations by the device but has a much smaller pinning footprint.
Dong Jia
va = iova;
> + lpfn->pfn = pfn[i];
> + lpfn->npage = 1;
> + lpfn->prot = prot;
> + atomic_inc(&lpfn->ref_count);
> + vfio_link_pfn(domain, lpfn);
> + }
> +
> + ret = i;
> +
> +pin_done:
> + mutex_unlock(&iommu->lock);
> + return ret;
> +}
> +EXPORT_SYMBOL(vfio_pin_pages);
Dong Jia
On Thu, 2 Jun 2016 00:56:47 -0700
Neo Jia wrote:
> On Wed, Jun 01, 2016 at 04:40:19PM +0800, Dong Jia wrote:
> > On Wed, 25 May 2016 01:28:17 +0530
> > Kirti Wankhede wrote:
> >
> > > +
> > > +/*
> > > + * Pin a set of guest PF
vice. I found the
existing callbacks could not meet my requirements.
Something like the following would be fine for my case:
int (*ioctl)(struct mdev_device *vdev,
unsigned int cmd,
unsigned long arg);
What do you think about this?
Dong Jia
On Fri, 3 Jun 2016 09:40:16 +
"Tian, Kevin" wrote:
> > From: Dong Jia [mailto:bjsdj...@linux.vnet.ibm.com]
> > Sent: Friday, June 03, 2016 4:58 PM
> >
> >
> > ...snip...
> >
> > > +struct phy_device_ops {
> > >
On Mon, 6 Jun 2016 10:57:49 +0530
Kirti Wankhede wrote:
>
>
> On 6/3/2016 2:27 PM, Dong Jia wrote:
> > On Wed, 25 May 2016 01:28:15 +0530
> > Kirti Wankhede wrote:
> >
> >
> > ...snip...
> >
> >> +struct phy_device_ops {
> >>
On Fri, 20 May 2016 03:21:31 +
"Tian, Kevin" wrote:
> > From: Dong Jia [mailto:bjsdj...@linux.vnet.ibm.com]
> > Sent: Thursday, May 19, 2016 3:28 PM
> >
> > On Fri, 13 May 2016 02:05:01 -0700
> > Neo Jia wrote:
> >
> > ...snip...
> &
On Sun, 5 Jun 2016 23:27:42 -0700
Neo Jia wrote:
> On Mon, Jun 06, 2016 at 02:01:48PM +0800, Dong Jia wrote:
> > On Mon, 6 Jun 2016 10:57:49 +0530
> > Kirti Wankhede wrote:
> >
> > >
> > >
> > > On 6/3/2016 2:27 PM, Dong Jia wrote:
> >
On Tue, 7 Jun 2016 02:47:10 +
"Tian, Kevin" wrote:
> > From: Dong Jia
> > Sent: Monday, June 06, 2016 2:59 PM
> >
>
> [...]
>
> > Channel I/O is quite different to PCI, so I copied some more details
> > here. Hope these could help.
>
t; On Tue, 7 Jun 2016 03:03:32 +
> > > "Tian, Kevin" wrote:
> > >
> > > > > From: Alex Williamson [mailto:alex.william...@redhat.com]
> > > > > Sent: Tuesday, June 07, 2016 3:31 AM
> > > > >
> > > > &g
On Tue, 7 Jun 2016 20:48:42 -0700
Neo Jia wrote:
> On Wed, Jun 08, 2016 at 11:18:42AM +0800, Dong Jia wrote:
> > On Tue, 7 Jun 2016 19:39:21 -0600
> > Alex Williamson wrote:
> >
> > > On Wed, 8 Jun 2016 01:18:42 +
> > > "Tian, Kevin&quo
On Tue, 7 Jun 2016 22:29:30 -0600
Alex Williamson wrote:
> On Wed, 8 Jun 2016 11:18:42 +0800
> Dong Jia wrote:
>
> > On Tue, 7 Jun 2016 19:39:21 -0600
> > Alex Williamson wrote:
> >
> > > On Wed, 8 Jun 2016 01:18:42 +
> > > "Tian, Kevin
don't see any way around tracking the
> iova. The iommu can't tell us this like it can with the normal type1
> model because the pfn is the result of the translation, not the key for
> the translation. So we're always going to have between 1 and
> (size/PAGE_SIZE) iova entries per vgpu_dma entry. You might be able to
> manage the vgpu_dma with an rb-tree, but each vgpu_dma entry needs some
> data structure tracking every iova.
>
> Sparse mapping has the same issue but of course the tree of iovas is
> potentially incomplete and we need a way to determine where it's
> incomplete. A page table rooted in the vgpu_dma and indexed by the
> offset from the start vaddr seems like the way to go here. It's also
> possible that some mediated device models might store the iova in the
> command sent to the device and therefore be able to parse those entries
> back out to unmap them without storing them separately. This might be
> how the s390 channel-io model would prefer to work.
Dear Alex:
For the s390 channel-io model, when an I/O instruction was intercepted
and issued to the device driver for further translation, the operand of
the instruction contents iovas only. Since iova is the key to locate an
entry in the database (r-b tree or whatever), we do can parse the
entries back out one by one when doing the unmap operation.
^^
BTW, if the mediated-iommu backend can potentially offer a transaction
level support for the unmap operation, I believe it will benefit the
performance for this case.
e.g.:
handler = vfio_trasaction_begin();
foreach(iova in the command) {
pfn = vfio_trasaction_map(handler, iova);
do_io(pfn);
}
/*
* Expect to unmap all of the pfns mapped in this trasaction with the
* next statement. The mediated-iommu backend could use handler as the
* key to track the list of the entries.
*/
vfio_trasaction_unmap(handler);
vfio_trasaction_end(handler);
Not sure if this could benefit the vgpu sparse mapping use case though.
> That seems like
> further validation that such tracking is going to be dependent on the
> mediated driver itself and probably not something to centralize in a
> mediated iommu driver. Thanks,
>
> Alex
>
Dong Jia
On Fri, 13 May 2016 00:24:34 -0700
Neo Jia wrote:
> On Fri, May 13, 2016 at 03:10:22PM +0800, Dong Jia wrote:
> > On Thu, 12 May 2016 13:05:52 -0600
> > Alex Williamson wrote:
> >
> > > On Thu, 12 May 2016 08:00:36 +
> > > "Tian, Kevin&quo
o typical guest RAM for the I/O instructions
issued by the passed-through ccw-device drivers. They can use any
memory chunk allocated by a kmalloc.
The working set depends on how much memory used by the device drivers,
and of course the number of the available memory. Since there is no
restrictions of the memory usage for this case, it varies...
[...]
Dong Jia
ward on their
feedback.
Thanks!
>
> - UUID was removed from the interface between mdev and vendor driver;
>
>
> TODO
>
> remove mdev stuff from vfio.h
> update doc
>
Dong Jia
On Wed, 17 Aug 2016 03:09:10 -0700
Neo Jia wrote:
> On Wed, Aug 17, 2016 at 04:58:14PM +0800, Dong Jia wrote:
> > On Tue, 16 Aug 2016 16:14:12 +0800
> > Jike Song wrote:
> >
> > >
> > > This patchset is based on NVidia's "Add
kfree(domain);
> + mutex_unlock(&iommu->lock);
> + return 0;
> + }
> +
Dong Jia
ret = parent->ops->read(mdev, &val, sizeof(val), *ppos);
> + if (ret <= 0)
> + goto read_err;
> +
> + if (copy_to_user(buf, &val, sizeof(val)))
> + goto read_err;
> +
> + filled = 1;
> + }
> +
> + count -= filled;
> + done += filled;
> + *ppos += filled;
> + buf += filled;
> + }
> +
> + return done;
> +
> +read_err:
> + return -EFAULT;
> +}
[...]
Dong Jia
Introduce device information about vfio-ccw: VFIO_DEVICE_FLAGS_CCW.
Realize VFIO_DEVICE_GET_INFO ioctl for vfio-ccw.
Signed-off-by: Dong Jia Shi
Reviewed-by: Pierre Morel
---
drivers/vfio/ccw/vfio_ccw.c | 20
include/uapi/linux/vfio.h | 1 +
2 files changed, 21
(idaw) as the data of
the cda entry.
6. For tic ccw:
- Find the target ccw, and find its offset to the address of the
ccw buffer.
- Store the offset as the CDA value in the ccw.
Signed-off-by: Dong Jia Shi
Reviewed-by: Pierre Morel
---
drivers/vfio/ccw/ccwchain.c | 441
Let's make orb-related definitions available outside
of the common I/O layer for future use (e.g. for
passing channel devices to a guest).
Signed-off-by: Dong Jia Shi
Reviewed-by: Pierre Morel
---
{drivers/s390/cio => arch/s390/include/asm}/orb.h | 0
drivers/s390/cio/ea
This enables IOMMU API if CONFIG_CCW is configured.
Signed-off-by: Dong Jia Shi
Reviewed-by: Pierre Morel
---
drivers/iommu/Kconfig | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
index dd1dc39..63bbc3d 100644
--- a
iples of Operation manual (IBM Form. No. SA22-7832)
2. ESA/390 Common I/O Device Commands manual (IBM Form. No. SA22-7204)
3. https://en.wikipedia.org/wiki/Channel_I/O
4. https://www.kernel.org/doc/Documentation/s390/cds.txt
Dong Jia Shi (8):
iommu: s390: enable iommu api for s390 ccw devices
-by: Dong Jia Shi
Reviewed-by: Pierre Morel
---
drivers/vfio/ccw/vfio_ccw.c | 190 +++-
include/uapi/linux/vfio.h | 23 ++
2 files changed, 212 insertions(+), 1 deletion(-)
diff --git a/drivers/vfio/ccw/vfio_ccw.c b/drivers/vfio/ccw/vfio_ccw.c
index
Add a basic vfio_ccw driver, which depends on the VFIO No-IOMMU
support.
Add a new config option:
Device Drivers
--> VFIO Non-Privileged userspace driver framework
--> VFIO No-IOMMU support
--> VFIO support for ccw devices
Signed-off-by: Dong Jia Shi
Reviewed-by: Pie
CCW translation requires to pin/unpin sets of mem pages frequently.
Currently we have a lack of support to do this in an efficient way.
So we introduce page_array data structure and helper functions to
handle pin/unpin operations here.
Signed-off-by: Dong Jia Shi
---
drivers/vfio/ccw/Makefile
Introduce VFIO_DEVICE_CCW_HOT_RESET ioctl for vfio-ccw to make it
possible to hot-reset the device.
We try to achieve a hot reset by first offlining the device and then
onlining it again: this should clear all state at the subchannel.
Signed-off-by: Dong Jia Shi
Reviewed-by: Pierre Morel
populating 100 pages of IOVA space all backed by the same
> > > malloc'd page. This is valid, I have unit tests that do essentially
> > > this. Those will all have the same pfn. The user then does an
> > > UNMAP_DMA to a single one of those IOVA pages. Did the user unmap
> > > everything matching that pfn? Of course not, they only unmapped that
> > > one IOVA page. There is no guarantee of a 1:1 mapping of pfn to IOVA.
> > > UNMAP_DMA works based on IOVA. Invalidation broadcasts to the vendor
> > > driver MUST therefore also work based on IOVA. This is not an academic
> > > problem, address space aliases exist in real VMs, imagine a virtual
> > > IOMMU. Thanks,
> > >
> >
> >
> > So struct vfio_iommu_type1_dma_unmap should be passed as argument to
> > notifier callback:
> >
> > if (unmapped && iommu->external_domain)
> > - vfio_notifier_call_chain(iommu, unmap);
> > + blocking_notifier_call_chain(&iommu->notifier,
> > + VFIO_IOMMU_NOTIFY_DMA_UNMAP,
> > +unmap);
> >
> > Then vendor driver should find pfns he has pinned from this range of
> > iovas, then invalidate and unpin pfns. Right?
>
> That seems like a valid choice. It's probably better than calling the
> notifier for each page of iova. Thanks,
>
> Alex
>
Hi Kirti,
This version requires the *vendor driver* call vfio_register_notifier
for an mdev device before any pinning operations. I guess all of the
vendor drivers may have some alike code for notifier
registration/unregistration.
My question is, how about letting the mdev framework managing the
notifier registration/unregistration process?
We could add a notifier_fn_t callback to "struct parent_ops", then the
mdev framework should make sure that the vendor driver assigned a value
to this callback. The mdev core could initiate a notifier_block for each
parent driver with its callback, and register/unregister it to vfio in
the right time.
--
Dong Jia
* Kirti Wankhede [2016-11-01 13:17:19 +0530]:
>
>
> On 11/1/2016 9:15 AM, Dong Jia Shi wrote:
> > * Alex Williamson [2016-10-29 08:03:01 -0600]:
> >
> >> On Sat, 29 Oct 2016 16:07:05 +0530
> >> Kirti Wankhede wrote:
> >>
> >>> On
* Jike Song [2016-09-13 10:35:11 +0800]:
> On 09/08/2016 10:45 AM, Jike Song wrote:
> > On 08/25/2016 05:22 PM, Dong Jia wrote:
> >> On Thu, 25 Aug 2016 09:23:53 +0530
> >> Kirti Wankhede wrote:
> >>
> >> [...]
> >>
> >> Dear Kir
Mediated device */
> +struct mdev_device {
> + struct device dev;
> + struct parent_device*parent;
> + uuid_le uuid;
> + void*driver_data;
> +
> + /* internal */
> + struct kref ref;
> + struct list_headnext;
> + struct kobject *type_kobj;
> +};
> +
> +
Empty line.
> +/**
> + * struct parent_ops - Structure to be registered for each parent device to
> + * register the device to mdev module.
> + *
[...]
> + * @mmap:mmap callback
No need a piece of description for arguments of the mmap callback?
> + * Parent device that support mediated device should be registered with mdev
> + * module with parent_ops structure.
> + **/
> +
> +struct parent_ops {
> + struct module *owner;
> + const struct attribute_group **dev_attr_groups;
> + const struct attribute_group **mdev_attr_groups;
> + struct attribute_group **supported_type_groups;
> +
> + int (*create)(struct kobject *kobj, struct mdev_device *mdev);
> + int (*remove)(struct mdev_device *mdev);
> + int (*open)(struct mdev_device *mdev);
> + void(*release)(struct mdev_device *mdev);
> + ssize_t (*read)(struct mdev_device *mdev, char __user *buf,
> + size_t count, loff_t *ppos);
> + ssize_t (*write)(struct mdev_device *mdev, const char __user *buf,
> + size_t count, loff_t *ppos);
> + ssize_t (*ioctl)(struct mdev_device *mdev, unsigned int cmd,
> + unsigned long arg);
> + int (*mmap)(struct mdev_device *mdev, struct vm_area_struct *vma);
> +};
> +
[...]
--
Dong Jia
add_dev_err:
> >> + mutex_unlock(&parent_list_lock);
> >> + if (parent)
> >> + mdev_put_parent(parent);
> > Why do this? I don't find the place that you call mdev_get_parent above.
> >
>
> kref_init(&parent->ref);
> Above increments the ref_count, so mdev_put_parent() should be called if
> anything fails.
>
> >> + else
> >> + put_device(dev);
> > Shouldn't we always do this?
> >
>
> When mdev_put_parent() is called, its release function do this. So if
> mdev_put_parent() is called, we don't need this.
Sorry for missing that. Thanks for the explanation!
>
> >> + return ret;
> >> +}
> >> +EXPORT_SYMBOL(mdev_register_device);
> >> +
[...]
--
Dong Jia
mdev-y := mdev_core.o mdev_sysfs.o mdev_driver.o
>
> obj-$(CONFIG_VFIO_MDEV) += mdev.o
> +obj-$(CONFIG_VFIO_MDEV_DEVICE) += vfio_mdev.o
> diff --git a/drivers/vfio/mdev/vfio_mdev.c b/drivers/vfio/mdev/vfio_mdev.c
[...]
> +
> +MODULE_VERSION(DRIVER_VERSION);
> +MODULE_LICENSE("GPL");
?
GPL V2
> +MODULE_AUTHOR(DRIVER_AUTHOR);
> +MODULE_DESCRIPTION(DRIVER_DESC);
> --
> 2.7.0
>
--
Dong Jia
list, next) {
> - list_for_each_entry(group, &domain->group_list, next) {
> - if (group->iommu_group != iommu_group)
> - continue;
> + group = find_iommu_group(domain, iommu_group);
> + if (!group)
> + continue;
[...]
Looks good to me!
--
Dong Jia
> - /* Map it! */
> - ret = vfio_iommu_map(iommu, iova + dma->size, pfn, npage, prot);
> - if (ret) {
> - __vfio_unpin_pages_remote(pfn, npage, prot, true);
> - break;
> - }
> -
> - size -= npage << PAGE_SHIFT;
> - dma->size += npage << PAGE_SHIFT;
> - }
> -
> - if (ret)
> - vfio_remove_dma(iommu, dma);
> -
> + ret = vfio_pin_map_dma(iommu, dma, size);
> +do_map_err:
> mutex_unlock(&iommu->lock);
> return ret;
> }
> --
> 2.7.0
>
--
Dong Jia
fn);
> + if (p)
> + ret = 0;
> + mutex_unlock(&addr_space->pfn_list_lock);
> + return ret;
> +}
We could save a local variables(@ret) here by:
return (p ? 0 : 1);
> +
> struct vwork {
> struct mm_struct*mm;
> longnpage;
[...]
--
Dong Jia
edistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#ifndef MDEV_H
> +#define MDEV_H
> +
> +/* Parent Device */
This is really a nit pick:
s/Device/device/
> +struct parent_device {
> + struct device *dev;
> + const struct parent_ops *ops;
> +
> + /* internal */
> + struct kref ref;
> + struct mutexlock;
> + struct list_headnext;
> + struct kset *mdev_types_kset;
> + struct list_headtype_list;
> +};
> +
> +/* Mediated device */
[...]
All findings from me are nitpickings. If you like you can have my r-b:
Reviewed-by: Dong Jia Shi
--
Dong Jia
ev bus\n");
If you want to report an error message here, you should do it in a
previous patch where you introduce the call for mdev_bus_register.
> + return ret;
> + }
> +
> + /*
> + * Attempt to load known vfio_mdev. This gives us a working environmen
vfio_iommu_driver_ops
> *ops);
> @@ -127,6 +131,14 @@ static inline long vfio_spapr_iommu_eeh_ioctl(struct
> iommu_group *group,
> }
> #endif /* CONFIG_EEH */
>
> +#define VFIO_PIN_PAGES_MAX_ENTRIES (PAGE_SIZE/sizeof(unsigned long))
> +
> +extern int vfio_pin_pages(struct device *dev, unsigned long *user_pfn,
> + int npage, int prot, unsigned long *phys_pfn);
> +
> +extern int vfio_unpin_pages(struct device *dev, unsigned long *user_pfn,
> + int npage);
> +
Move this hunk up to the "External user API" section?
> /*
> * IRQfd - generic
> */
> --
> 2.7.0
>
The code looks good to me.
--
Dong Jia
break;
> - }
> -
> - /* Map it! */
> - ret = vfio_iommu_map(iommu, iova + dma->size, pfn, npage, prot);
> - if (ret) {
> - vfio_unpin_pages_remote(pfn, npage, prot, true);
> - break;
> - }
> -
> - size -= npage << PAGE_SHIFT;
> - dma->size += npage << PAGE_SHIFT;
> - }
> -
> - if (ret)
> - vfio_remove_dma(iommu, dma);
> -
> + ret = vfio_pin_map_dma(iommu, dma, size);
> +do_map_err:
Rename to out_unlock?
> mutex_unlock(&iommu->lock);
> return ret;
> }
> --
> 2.7.0
>
Otherwise, LGTM!
--
Dong Jia
s->open(mdev);
> - if (ret)
> + if (ret) {
> + if (likely(parent->ops->notifier))
> + vfio_unregister_notifier(&mdev->dev, &mdev->nb);
> module_put(THIS_MODULE);
> + }
>
> return ret;
> }
[...]
--
Dong Jia
* Kirti Wankhede [2016-11-16 20:47:18 +0530]:
>
>
> On 11/16/2016 12:07 PM, Dong Jia Shi wrote:
> > * Kirti Wankhede [2016-11-15 20:59:55 +0530]:
> >
> > Hi Kirti,
> >
> > [...]
> >
> >> diff --git a/drivers/vfio/mdev/vfio_mdev.c b
ot fail here either.
> + }
> +
> module_put(THIS_MODULE);
> }
>
[...]
--
Dong Jia
> >
> > > As discussed, I dropped patch 12, updated the documentation, and added
> > > 'retries' initialization. This is now applied to my next branch for
> > > v4.10. Thanks to the reviewers and Kirti and Neo for your hard work!
> > > Thanks,
> > >
> >
> > That's a great news! Alex, do you have an idea when this series may
> > hit linux-next? :-)
>
> Whenever there's a new build, hopefully within the next 24hrs, but I
> don't really know the schedule. Thanks,
Great news! Can't wait to try the upstream version. :->
Thanks everybody that makes this happen!!
>
> Alex
>
--
Dong Jia
* Alex Williamson [2017-02-24 16:27:24 -0700]:
> On Fri, 17 Feb 2017 09:29:35 +0100
> Dong Jia Shi wrote:
>
> > Realize VFIO_DEVICE_GET_IRQ_INFO ioctl to retrieve
> > VFIO_CCW_IO_IRQ information.
> >
> > Realize VFIO_DEVICE_SET_IRQS ioctl to set an eventfd f
> +
> + ret = count;
> +
> +
> +accessfailed:
> + mutex_unlock(&mdev_state->ops_lock);
> +
> + return ret;
> +}
> +
...snip...
> +ssize_t mtty_read(struct mdev_device *mdev, char __user *buf,
> + size_t count, loff_t *ppos)
> +{
> + return mdev_access(mdev, buf, count, *ppos, false);
> +}
> +
> +ssize_t mtty_write(struct mdev_device *mdev, const char __user *buf,
> + size_t count, loff_t *ppos)
> +{
> + return mdev_access(mdev, (char *)buf, count, *ppos, true);
> +}
> +
...snip...
--
Dong Jia
* Cornelia Huck [2017-04-11 11:06:58 +0200]:
> On Fri, 17 Mar 2017 04:19:17 +0100
> Dong Jia Shi wrote:
>
> > The patch series introduce a basic channel I/O passthrough
> > infrastructure based on vfio.
>
> I think this is basically ready for 2.10, once the kernel
Add vfio_ccw.h.
Signed-off-by: Dong Jia Shi
---
scripts/update-linux-headers.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/scripts/update-linux-headers.sh b/scripts/update-linux-headers.sh
index 6a370a8..2f906c4 100755
--- a/scripts/update-linux-headers.sh
+++ b/scripts
css_create_virtual_sch to a new
css_create_sch function to handl all these cases and do allocation
and initialization of the subchannel according to the device type
and machine configuration.
Reviewed-by: Pierre Morel
Signed-off-by: Dong Jia Shi
---
hw/s390x/css-bridge.c | 2 ++
hw/s390x/css.c
/O interrupt to notify guest the I/O result.
Signed-off-by: Xiao Feng Ren
Signed-off-by: Dong Jia Shi
---
hw/s390x/css.c | 4 +--
hw/s390x/s390-ccw.h| 1 +
hw/vfio/ccw.c | 73 ++
include/hw/s390x/css.h | 2 ++
4 files
ff-by: Xiao Feng Ren
Signed-off-by: Dong Jia Shi
---
default-configs/s390x-softmmu.mak | 1 +
hw/vfio/Makefile.objs | 1 +
hw/vfio/ccw.c | 207 ++
include/hw/vfio/vfio-common.h | 1 +
4 files changed, 210 insertions(+)
tch 8: correct the validation of num_irqs.
v1 -> v2:
1. Rebase the implementation to the mdev framework approach.
2. Use pread and pwrite on an I/O region to issue I/O requests and
receive results.
Dong Jia Shi (8):
update-linux-headers: update for vfio-ccw
vfio: linux-headers updat
vfio-ccw provides an MMIO region for I/O operations. We fetch its
information via ioctls here, then we can use it performing I/O
instructions and retrieving I/O results later on.
Signed-off-by: Dong Jia Shi
---
hw/vfio/ccw.c | 52
1 file
translation and perform an I/O operation.
3. Assign different condition code based on the I/O result, or
trigger a program check.
Signed-off-by: Xiao Feng Ren
Signed-off-by: Dong Jia Shi
---
hw/s390x/css.c | 88 ++
hw/s390x/s390-ccw.c| 12
This is a placeholder for a linux-headers update.
Signed-off-by: Dong Jia Shi
---
linux-headers/linux/vfio.h | 17 +
linux-headers/linux/vfio_ccw.h | 28
2 files changed, 45 insertions(+)
create mode 100644 linux-headers/linux/vfio_ccw.h
diff
Concurrent-sense data is currently not delivered. This patch stores
the concurrent-sense data to the subchannel if a unit check is pending
and the concurrent-sense bit is enabled. Then a TSCH can retreive the
right IRB data back to the guest.
Signed-off-by: Dong Jia Shi
---
hw/vfio/ccw.c | 7
Add Cornelia Huck as the vfio-ccw maintainer.
Signed-off-by: Dong Jia Shi
---
MAINTAINERS | 5 +
1 file changed, 5 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index c60235e..5bac5f1 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -999,6 +999,11 @@ S: Supported
F: hw/vfio/*
F
MCSS-E), we need an option to
squash both the virtio subchannels and e.g. passed-through
subchannels from their real css (0-3, or 0 for hosts not
activating MCSS-E) into the default css. This will be
exploited in a later patch.
Signed-off-by: Xiao Feng Ren
Signed-off-by: Dong Jia Shi
---
hw
device information. Thus we realize a new css_sch_build_schib function
to extract the path_masks, chpids, chpid type from sysfs. To reuse
the existing code, we refactor css_add_virtual_chpid to css_add_chpid.
Reviewed-by: Pierre Morel
Signed-off-by: Xiao Feng Ren
Signed-off-by: Dong Jia Shi
---
hw
In order to support subchannels pass-through, we introduce a s390
subchannel device called "s390-ccw" to hold the real subchannel info.
The s390-ccw devices inherit from the abstract CcwDevice which connect
to the existing virtual-css-bus.
Signed-off-by: Dong Jia Shi
---
hw/s390x/Mak
the signal.
Signed-off-by: Dong Jia Shi
---
hw/vfio/ccw.c | 102 ++
1 file changed, 102 insertions(+)
diff --git a/hw/vfio/ccw.c b/hw/vfio/ccw.c
index 20a4d1a..5127c87 100644
--- a/hw/vfio/ccw.c
+++ b/hw/vfio/ccw.c
@@ -22,6 +22,7
apter_routes, \
^^
Nit:-++
> + AdapterRoutes),
> +VMSTATE_UINT8(thinint_isc, VirtioCcwDevice),
> +VMSTATE_INT32(revision, VirtioCcwDevice),
> +VMSTATE_END_OF_LIST()
> +}
> +};
> +
> static void virtio_ccw_bus_new(VirtioBusState *bus, size_t bus_size,
> VirtioCcwDevice *dev);
>
[...]
--
Dong Jia Shi
* Eric Blake [2017-06-05 07:19:14 -0500]:
Hi Eric,
> On 06/04/2017 10:09 PM, Dong Jia Shi wrote:
> > * Halil Pasic [2017-06-02 16:05:31 +0200]:
> >
> > Hi Halil,
> >
> > Sorry for the late show up. I just found some nits, which could be
> > ig
This is a placeholder for a linux-headers update.
Signed-off-by: Dong Jia Shi
---
linux-headers/linux/vfio.h | 17 +
linux-headers/linux/vfio_ccw.h | 28
2 files changed, 45 insertions(+)
create mode 100644 linux-headers/linux/vfio_ccw.h
diff
validation of num_regions.
5. Patch 8: correct the validation of num_irqs.
v1 -> v2:
1. Rebase the implementation to the mdev framework approach.
2. Use pread and pwrite on an I/O region to issue I/O requests and
receive results.
Dong Jia Shi (8):
update-linux-headers: update for vfio-ccw
Add vfio_ccw.h.
Signed-off-by: Dong Jia Shi
---
scripts/update-linux-headers.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/scripts/update-linux-headers.sh b/scripts/update-linux-headers.sh
index 6a370a8..2f906c4 100755
--- a/scripts/update-linux-headers.sh
+++ b/scripts
css_create_virtual_sch to a new
css_create_sch function to handl all these cases and do allocation
and initialization of the subchannel according to the device type
and machine configuration.
Reviewed-by: Pierre Morel
Signed-off-by: Dong Jia Shi
---
hw/s390x/css-bridge.c | 2 ++
hw/s390x/css.c
/O interrupt to notify guest the I/O result.
Signed-off-by: Xiao Feng Ren
Signed-off-by: Dong Jia Shi
---
hw/s390x/css.c | 4 +--
hw/s390x/s390-ccw.h| 1 +
hw/vfio/ccw.c | 85 ++
include/hw/s390x/css.h | 2 ++
4 files
In order to support subchannels pass-through, we introduce a s390
subchannel device called "s390-ccw" to hold the real subchannel info.
The s390-ccw devices inherit from the abstract CcwDevice which connect
to the existing virtual-css-bus.
Signed-off-by: Dong Jia Shi
---
hw/s390x/Mak
MCSS-E), we need an option to
squash both the virtio subchannels and e.g. passed-through
subchannels from their real css (0-3, or 0 for hosts not
activating MCSS-E) into the default css. This will be
exploited in a later patch.
Signed-off-by: Xiao Feng Ren
Signed-off-by: Dong Jia Shi
---
hw
device information. Thus we realize a new css_sch_build_schib function
to extract the path_masks, chpids, chpid type from sysfs. To reuse
the existing code, we refactor css_add_virtual_chpid to css_add_chpid.
Reviewed-by: Pierre Morel
Signed-off-by: Xiao Feng Ren
Signed-off-by: Dong Jia Shi
---
hw
Concurrent-sense data is currently not delivered. This patch stores
the concurrent-sense data to the subchannel if a unit check is pending
and the concurrent-sense bit is enabled. Then a TSCH can retreive the
right IRB data back to the guest.
Signed-off-by: Dong Jia Shi
---
hw/vfio/ccw.c | 7
ff-by: Xiao Feng Ren
Signed-off-by: Dong Jia Shi
---
default-configs/s390x-softmmu.mak | 1 +
hw/vfio/Makefile.objs | 1 +
hw/vfio/ccw.c | 187 ++
include/hw/vfio/vfio-common.h | 1 +
4 files changed, 190 insertions(+)
the signal.
Signed-off-by: Dong Jia Shi
---
hw/vfio/ccw.c | 103 ++
1 file changed, 103 insertions(+)
diff --git a/hw/vfio/ccw.c b/hw/vfio/ccw.c
index 7ddcfd7..6760cee 100644
--- a/hw/vfio/ccw.c
+++ b/hw/vfio/ccw.c
@@ -22,6 +22,7
translation and perform an I/O operation.
3. Assign different condition code based on the I/O result, or
trigger a program check.
Signed-off-by: Xiao Feng Ren
Signed-off-by: Dong Jia Shi
---
hw/s390x/css.c | 89 ++
hw/s390x/s390-ccw.c| 12
Add Cornelia Huck as the vfio-ccw maintainer.
Signed-off-by: Dong Jia Shi
---
MAINTAINERS | 5 +
1 file changed, 5 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index cae3b09..c1f9917 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -999,6 +999,11 @@ S: Supported
F: hw/vfio/*
F
vfio-ccw provides an MMIO region for I/O operations. We fetch its
information via ioctls here, then we can use it performing I/O
instructions and retrieving I/O results later on.
Signed-off-by: Dong Jia Shi
---
hw/vfio/ccw.c | 54 ++
1 file
* Cornelia Huck [2017-05-05 14:04:20 +0200]:
> On Fri, 5 May 2017 04:03:43 +0200
> Dong Jia Shi wrote:
>
> > From: Xiao Feng Ren
> >
> > The S390 virtual css support already has a mechanism to build virtual
> > Sub-Channel Information Block and provide vi
* Cornelia Huck [2017-05-05 14:11:53 +0200]:
> On Fri, 5 May 2017 04:03:44 +0200
> Dong Jia Shi wrote:
>
> > The S390 virtual css support already has a mechanism to create a
> > virtual subchannel and provide it to the guest. However, to
> > pass-through subchan
* Cornelia Huck [2017-05-05 14:20:14 +0200]:
> On Fri, 5 May 2017 04:03:52 +0200
> Dong Jia Shi wrote:
>
> > Add Cornelia Huck as the vfio-ccw maintainer.
> >
> > Signed-off-by: Dong Jia Shi
> > ---
> > MAINTAINERS | 5 +
> > 1 file c
* Cornelia Huck [2017-05-05 14:22:34 +0200]:
> On Fri, 5 May 2017 04:03:39 +0200
> Dong Jia Shi wrote:
>
> > The patch series introduce a basic channel I/O passthrough
> > infrastructure based on vfio.
> > - Focus on supporting dasd-eckd(cu_type/dev_type = 0x3990/
* Cornelia Huck [2017-05-08 12:50:40 +0200]:
> On Mon, 8 May 2017 13:18:22 +0800
> Dong Jia Shi wrote:
>
> > * Cornelia Huck [2017-05-05 14:11:53 +0200]:
> >
> > > On Fri, 5 May 2017 04:03:44 +0200
> > > Dong Jia Shi wrote:
>
> > >
* Cornelia Huck [2017-05-08 11:09:27 +0200]:
> On Mon, 8 May 2017 13:29:27 +0800
> Dong Jia Shi wrote:
>
> > * Cornelia Huck [2017-05-05 14:20:14 +0200]:
> >
> > > On Fri, 5 May 2017 04:03:52 +0200
> > > Dong Jia Shi wrote:
> > >
>
* Auger Eric [2017-05-09 10:21:15 +0200]:
Hi Eric,
> Hi,
>
> On 05/05/2017 04:03, Dong Jia Shi wrote:
> > vfio-ccw resorts to the eventfd mechanism to communicate with userspace.
> > We fetch the irqs info via the ioctl VFIO_DEVICE_GET_IRQ_INFO,
> > register a event
t; +/*
> > + * s390 CCW Assignment Support
> > + *
> > + * Copyright 2017 IBM Corp
> > + * Author(s): Dong Jia Shi
> > + *Xiao Feng Ren
> > + *Pierre Morel
> > + *
> > + * This work is licensed under the terms of the GNU GPL, version 2
&g
handler(*pfd, NULL, NULL, vcdev);
> > +event_notifier_cleanup(&vcdev->io_notifier);
> > +goto set_error;
>
>
> nit, unnecessary goto here. set_error label is unused if removed.
Ok, I will remove both this goto line and the set_error label line!
>
> Otherwise,
>
> Acked-by: Alex Williamson
>
>
Thanks for all of your A-Bs! I will add them in next version.
> > +}
> > +
> > +set_error:
> > +g_free(irq_set);
> > +
> > +get_error:
> > +g_free(irq_info);
> > +}
> > +
[...]
--
Dong Jia Shi
* Dong Jia Shi [2017-05-15 10:31:48 +0800]:
> * Alex Williamson [2017-05-11 15:49:04 -0600]:
>
> Hi Alex,
>
> [...]
>
> > > diff --git a/hw/vfio/ccw.c b/hw/vfio/ccw.c
> > > index 7ddcfd7..6760cee 100644
> > > --- a/hw/vfio/ccw.c
> > >
This is a placeholder for a linux-headers update.
Signed-off-by: Dong Jia Shi
---
linux-headers/linux/vfio.h | 17 +
linux-headers/linux/vfio_ccw.h | 28
2 files changed, 45 insertions(+)
create mode 100644 linux-headers/linux/vfio_ccw.h
diff
ccw.h to uapi.
2. Adopt the vfio-ccw cmdline interface as vfio-pci with mdev devices.
3. Rename s390-map-css to s390-squash-mcss (patch 2), and update devno
generation method (patch 5).
4. Patch 7: correct the validation of num_regions.
5. Patch 8: correct the validation of num_irqs.
v1 -> v2:
1. Re
MCSS-E), we need an option to
squash both the virtio subchannels and e.g. passed-through
subchannels from their real css (0-3, or 0 for hosts not
activating MCSS-E) into the default css. This will be
exploited in a later patch.
Signed-off-by: Xiao Feng Ren
Signed-off-by: Dong Jia Shi
---
hw
translation and perform an I/O operation.
3. Assign different condition code based on the I/O result, or
trigger a program check.
Signed-off-by: Xiao Feng Ren
Signed-off-by: Dong Jia Shi
---
hw/s390x/css.c | 89 ++
hw/s390x/s390-ccw.c| 12
Add vfio_ccw.h.
Signed-off-by: Dong Jia Shi
---
scripts/update-linux-headers.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/scripts/update-linux-headers.sh b/scripts/update-linux-headers.sh
index 6a370a8669..2f906c4d16 100755
--- a/scripts/update-linux-headers.sh
+++ b
vfio-ccw provides an MMIO region for I/O operations. We fetch its
information via ioctls here, then we can use it performing I/O
instructions and retrieving I/O results later on.
Reviewed-by: Eric Auger
Acked-by: Alex Williamson
Signed-off-by: Dong Jia Shi
---
hw/vfio/ccw.c | 54
real device information. Thus we realize a new css
sch_build_schib function to extract the path_masks, chpids, chpid
type from sysfs. To reuse the existing code, we refactor
css_add_virtual_chpid to css_add_chpid.
Reviewed-by: Pierre Morel
Signed-off-by: Xiao Feng Ren
Signed-off-by: Dong Jia Shi
/O interrupt to notify guest the I/O result.
Acked-by: Alex Williamson
Signed-off-by: Xiao Feng Ren
Signed-off-by: Dong Jia Shi
---
hw/s390x/css.c | 4 +--
hw/vfio/ccw.c | 85 +
include/hw/s390x/css.h | 2 ++
include
iewed-by: Eric Auger
Acked-by: Alex Williamson
Signed-off-by: Xiao Feng Ren
Signed-off-by: Dong Jia Shi
---
default-configs/s390x-softmmu.mak | 1 +
hw/vfio/Makefile.objs | 1 +
hw/vfio/ccw.c | 187 ++
include/hw/vfio/vfio-com
1 - 100 of 374 matches
Mail list logo
