>-----Original Message-----
>From: Cédric Le Goater <c...@redhat.com>
>Sent: Wednesday, October 18, 2023 4:04 PM
>Subject: Re: [PATCH v2 02/27] vfio: Introduce base object for VFIOContainer and
>targetted interface
>
>On 10/18/23 04:41, Duan, Zhenzhong wrote:
>> Hi Cédric,
>>
>>> -----Original Message-----
>>> From: Cédric Le Goater <c...@redhat.com>
>>> Sent: Tuesday, October 17, 2023 11:51 PM
>>> Subject: Re: [PATCH v2 02/27] vfio: Introduce base object for VFIOContainer
>and
>>> targetted interface
>>>
>>> On 10/16/23 10:31, Zhenzhong Duan wrote:
>>>> From: Eric Auger <eric.au...@redhat.com>
>>>>
>>>> Introduce a dumb VFIOContainer base object and its targetted interface.
>>>> This is willingly not a QOM object because we don't want it to be
>>>> visible from the user interface. The VFIOContainer will be smoothly
>>>> populated in subsequent patches as well as interfaces.
>>>>
>>>> No fucntional change intended.
>>>>
>>>> Signed-off-by: Eric Auger <eric.au...@redhat.com>
>>>> Signed-off-by: Yi Liu <yi.l....@intel.com>
>>>> Signed-off-by: Yi Sun <yi.y....@linux.intel.com>
>>>> Signed-off-by: Zhenzhong Duan <zhenzhong.d...@intel.com>
>>>> ---
>>>> include/hw/vfio/vfio-common.h | 8 +--
>>>> include/hw/vfio/vfio-container-base.h | 82
>+++++++++++++++++++++++++++
>>>> 2 files changed, 84 insertions(+), 6 deletions(-)
>>>> create mode 100644 include/hw/vfio/vfio-container-base.h
>>>>
>>>> diff --git a/include/hw/vfio/vfio-common.h b/include/hw/vfio/vfio-
>common.h
>>>> index 34648e518e..9651cf921c 100644
>>>> --- a/include/hw/vfio/vfio-common.h
>>>> +++ b/include/hw/vfio/vfio-common.h
>>>> @@ -30,6 +30,7 @@
>>>> #include <linux/vfio.h>
>>>> #endif
>>>> #include "sysemu/sysemu.h"
>>>> +#include "hw/vfio/vfio-container-base.h"
>>>>
>>>> #define VFIO_MSG_PREFIX "vfio %s: "
>>>>
>>>> @@ -81,6 +82,7 @@ typedef struct VFIOAddressSpace {
>>>> struct VFIOGroup;
>>>>
>>>> typedef struct VFIOLegacyContainer {
>>>> + VFIOContainer bcontainer;
>>>
>>> That's the parent class, right ?
>>
>> Right.
>>
>>>
>>>> VFIOAddressSpace *space;
>>>> int fd; /* /dev/vfio/vfio, empowered by the attached groups */
>>>> MemoryListener listener;
>>>> @@ -200,12 +202,6 @@ typedef struct VFIODisplay {
>>>> } dmabuf;
>>>> } VFIODisplay;
>>>>
>>>> -typedef struct {
>>>> - unsigned long *bitmap;
>>>> - hwaddr size;
>>>> - hwaddr pages;
>>>> -} VFIOBitmap;
>>>> -
>>>> void vfio_host_win_add(VFIOLegacyContainer *container,
>>>> hwaddr min_iova, hwaddr max_iova,
>>>> uint64_t iova_pgsizes);
>>>> diff --git a/include/hw/vfio/vfio-container-base.h b/include/hw/vfio/vfio-
>>> container-base.h
>>>> new file mode 100644
>>>> index 0000000000..afc8543d22
>>>> --- /dev/null
>>>> +++ b/include/hw/vfio/vfio-container-base.h
>>>> @@ -0,0 +1,82 @@
>>>> +/*
>>>> + * VFIO BASE CONTAINER
>>>> + *
>>>> + * Copyright (C) 2023 Intel Corporation.
>>>> + * Copyright Red Hat, Inc. 2023
>>>> + *
>>>> + * Authors: Yi Liu <yi.l....@intel.com>
>>>> + * Eric Auger <eric.au...@redhat.com>
>>>> + *
>>>> + * This program is free software; you can redistribute it and/or modify
>>>> + * it under the terms of the GNU General Public License as published by
>>>> + * the Free Software Foundation; either version 2 of the License, or
>>>> + * (at your option) any later version.
>>>> +
>>>> + * This program is distributed in the hope that it will be useful,
>>>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>>>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>>>> + * GNU General Public License for more details.
>>>> +
>>>> + * You should have received a copy of the GNU General Public License along
>>>> + * with this program; if not, see <http://www.gnu.org/licenses/>.
>>>> + */
>>>> +
>>>> +#ifndef HW_VFIO_VFIO_BASE_CONTAINER_H
>>>> +#define HW_VFIO_VFIO_BASE_CONTAINER_H
>>>> +
>>>> +#include "exec/memory.h"
>>>> +#ifndef CONFIG_USER_ONLY
>>>> +#include "exec/hwaddr.h"
>>>> +#endif
>>>> +
>>>> +typedef struct VFIOContainer VFIOContainer;
>>>> +typedef struct VFIODevice VFIODevice;
>>>> +typedef struct VFIOIOMMUBackendOpsClass VFIOIOMMUBackendOpsClass;
>>>> +
>>>> +typedef struct {
>>>> + unsigned long *bitmap;
>>>> + hwaddr size;
>>>> + hwaddr pages;
>>>> +} VFIOBitmap;
>>>> +
>>>> +/*
>>>> + * This is the base object for vfio container backends
>>>> + */
>>>> +struct VFIOContainer {
>>>> + VFIOIOMMUBackendOpsClass *ops;
>>>
>>> This is unexpected.
>>>
>>> I thought that an abstract QOM model for VFIOContainer was going
>>> to be introduced with a VFIOContainerClass with the ops below
>>> (VFIOIOMMUBackendOpsClass).
>>>
>>> Then, we would call :
>>>
>>> VFIOContainerClass *vcc = VFIO_CONTAINER_GET_CLASS(container);
>>>
>>> to get the specific implementation for the current container.
>>>
>>> I don't understand the VFIOIOMMUBackendOpsClass pointer and
>>> TYPE_VFIO_IOMMU_BACKEND_OPS. It seems redundant.
>>
>> The original implementation was abstract QOM model. But it wasn't accepted,
>> see https://lore.kernel.org/all/YmuFv2s5TPuw7K%2Fu@yekko/ for details.
>
>I see the idea was challenged, not rejected. I need to dig in further and this
>will take time.
Thanks for help looking into it.
+David, Hi David, I'm digging into your concern of using QOM to abstract base
container and legacy VFIOContainer:
"The QOM class of things is visible to the user/config layer via QMP (and
sometimes command line).
It doesn't necessarily correspond to guest visible differences, but it often
does."
AIUI, while it's true when the QOM type includes TYPE_USER_CREATABLE interface,
otherwise, user can't create an object of this type. Only difference is user
will see
"object type '%s' isn't supported by object-add" instead of "invalid object
type: %s".
Is your expectation to not permit user to create this object or only want user
to see "invalid object type: %s".
If you mean the first, then I think QOM could be suitable if we don't include
TYPE_USER_CREATABLE interface?
Thanks
Zhenzhong
