2 +-
> drivers/iommu/s390-iommu.c | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
Reviewed-by: Matthew Rosato
nged, 29 insertions(+), 22 deletions(-)
>
Reviewed-by: Matthew Rosato
sts on s390 in LPAR and within a QEMU guest -- all tests pass
(used 1M hugepages)
Did light regression testing of vfio-ap and vfio-ccw on s390x with
CONFIG_VFIO_CONTAINER=y and =n.
Didn't see it in your branch yet, but also verified the proposed change to
iommufd_fill_cap_dma_avail (.avail = U32_MAX) would work as expected.
Tested-by: Matthew Rosato
On 11/14/22 9:59 AM, Jason Gunthorpe wrote:
> On Mon, Nov 14, 2022 at 09:55:21AM -0500, Matthew Rosato wrote:
>>>> AFAICT there is no equivalent means to specify
>>>> vfio_iommu_type1.dma_entry_limit when using iommufd; looks like
>>>> we'll just always
On 11/14/22 9:23 AM, Jason Gunthorpe wrote:
> On Thu, Nov 10, 2022 at 10:01:13PM -0500, Matthew Rosato wrote:
>> On 11/7/22 7:52 PM, Jason Gunthorpe wrote:
>>> This series provides an alternative container layer for VFIO implemented
>>> using iommufd. This is optional, i
On 11/7/22 7:52 PM, Jason Gunthorpe wrote:
> This series provides an alternative container layer for VFIO implemented
> using iommufd. This is optional, if CONFIG_IOMMUFD is not set then it will
> not be compiled in.
>
> At this point iommufd can be injected by passing in a iommfd FD to
> VFIO_GRO
On 11/3/22 5:56 PM, Alex Williamson wrote:
> On Wed, 2 Nov 2022 16:01:45 +0100
> Eric Farman wrote:
>
>> Hi all,
>>
>> Here is an update to the vfio-ccw lifecycle changes that have been discussed
>> in various forms over the past year [1][2] or so, and which I dusted off
>> recently.
>>
>> Patch
lbacks.
>
> Signed-off-by: Eric Farman
> Reviewed-by: Jason Gunthorpe
> Reviewed-by: Kevin Tian
Reviewed-by: Matthew Rosato
gt; - }
> + private = vfio_alloc_device(vfio_ccw_private, vdev, &mdev->dev,
> + &vfio_ccw_dev_ops);
> + if (IS_ERR(private))
> + return PTR_ERR(private);
OK, and now it makes sense to switch to IS_ERR since _vfio_alloc_device uses
ERR_PTR.
Reviewed-by: Matthew Rosato
On 11/2/22 11:01 AM, Eric Farman wrote:
> There's enough separation between the parent and private structs now,
> that it is fine to remove the release completion hack.
>
> Signed-off-by: Eric Farman
> Reviewed-by: Kevin Tian
Reviewed-by: Matthew Rosato
>
ook my advice :)
In fact it looks like some of my other comments from patch 1 get cleaned up
here too -- but would still be good to make those changes in patch 1 for
completeness/bisect.
Reviewed-by: Matthew Rosato
_private.
> + put_device(&parent->dev);
As you said in your other reply, this goes away
> return ret;
> }
>
> static void vfio_ccw_sch_remove(struct subchannel *sch)
> {
> - struct vfio_ccw_private *private = dev_get_drvdata(&sch->dev);
> + struct vfio_ccw_parent *parent = dev_get_drvdata(&sch->dev);
> + struct vfio_ccw_private *private = dev_get_drvdata(&parent->dev);
>
> - mdev_unregister_parent(&private->parent);
> + mdev_unregister_parent(&parent->parent);
>
> + device_unregister(&parent->dev);
> dev_set_drvdata(&sch->dev, NULL);
>
> vfio_ccw_free_private(private);
> + put_device(&parent->dev);
As you said in your other reply, this goes away
The rest looks fine, with these changes you can have:
Reviewed-by: Matthew Rosato
On 11/2/22 3:29 PM, Eric Farman wrote:
> On Wed, 2022-11-02 at 16:01 +0100, Eric Farman wrote:
>> Move the stuff associated with the mdev parent (and thus the
>> subchannel struct) into its own struct, and leave the rest in
>> the existing private structure.
>>
>> The subchannel will point to the p
ct work_struct *work)
> +void vfio_ccw_crw_todo(struct work_struct *work)
> {
> struct vfio_ccw_private *private;
>
> @@ -154,52 +154,7 @@ static struct vfio_ccw_private
> *vfio_ccw_alloc_private(struct subchannel *sch)
> if (!private)
> return ERR_PT
= to_subchannel(private->vdev.dev->parent);
I'm not a big fan of the amount of indirection there, but I prefer this over
back-pocketing the subchannel in vfio_ccw_private anyway
Reviewed-by: Matthew Rosato
On 10/19/22 12:21 PM, Eric Farman wrote:
> Move the stuff associated with the mdev parent (and thus the
> subchannel struct) into its own struct, and leave the rest in
> the existing private structure.
>
> The subchannel will point to the parent, and the parent will point
> to the private, for the
On 4/12/22 11:53 AM, Jason Gunthorpe wrote:
When the open_device() op is called the container_users is incremented and
held incremented until close_device(). Thus, so long as drivers call
functions within their open_device()/close_device() region they do not
need to worry about the container_user
On 10/1/21 1:52 PM, Jason Gunthorpe wrote:
Makes the code easier to understand what is memory lifecycle and what is
other stuff.
Reviewed-by: Eric Farman
Signed-off-by: Jason Gunthorpe
Reviewed-by: Matthew Rosato
eviewed-by: Matthew Rosato
---
drivers/s390/cio/vfio_ccw_drv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/s390/cio/vfio_ccw_drv.c b/drivers/s390/cio/vfio_ccw_drv.c
index 76099bcb765b45..371558ec92045d 100644
--- a/drivers/s390/cio/vfio_ccw_drv.c
+++ b/driver
19 matches
Mail list logo
