Hi, On 9/21/23 05:35, Duan, Zhenzhong wrote: > Hi Eric, > >> -----Original Message----- >> From: Eric Auger <eric.au...@redhat.com> >> Sent: Thursday, September 21, 2023 1:31 AM >> Subject: Re: [PATCH v1 13/22] vfio: Add base container >> >> Hi Zhenzhong, >> >> On 9/19/23 19:23, Cédric Le Goater wrote: >>> On 8/30/23 12:37, Zhenzhong Duan wrote: >>>> From: Yi Liu <yi.l....@intel.com> >>>> >>>> Abstract the VFIOContainer to be a base object. It is supposed to be >>>> embedded by legacy VFIO container and later on, into the new iommufd >>>> based container. >>>> >>>> The base container implements generic code such as code related to >>>> memory_listener and address space management. The VFIOContainerOps >>>> implements callbacks that depend on the kernel user space being used. >>>> >>>> 'common.c' and vfio device code only manipulates the base container with >>>> wrapper functions that calls the functions defined in >>>> VFIOContainerOpsClass. >>>> Existing 'container.c' code is converted to implement the legacy >>>> container >>>> ops functions. >>>> >>>> Below is the base container. It's named as VFIOContainer, old >>>> VFIOContainer >>>> is replaced with VFIOLegacyContainer. >>> Usualy, we introduce the new interface solely, port the current models >>> on top of the new interface, wire the new models in the current >>> implementation and remove the old implementation. Then, we can start >>> adding extensions to support other implementations. >>> >>> spapr should be taken care of separatly following the principle above. >>> With my PPC hat, I would not even read such a massive change, too risky >>> for the subsystem. This path will need (much) further splitting to be >>> understandable and acceptable. >> We might split this patch by >> 1) introducing VFIOLegacyContainer encapsulating the base VFIOContainer, >> without using the ops in a first place: >> common.c would call vfio_container_* with harcoded legacy >> implementation, ie. retrieving the legacy container with container_of. >> 2) we would introduce the BE interface without using it. >> 3) we would use the new BE interface >> >> Obviously this needs to be further tried out. If you wish I can try to >> split it that way ... Please let me know > Sure, thanks for your help, glad that I can cooperate with you to move > this series forward. > I just updated the branch which rebased to newest upstream for you to pick at > https://github.com/yiliu1765/qemu/tree/zhenzhong/iommufd_cdev_v1_rebased
OK thanks. Let me do the exercise. Eric > > Thanks > Zhenzhong
