WorldCIST'24 - 12nd World Conference on Information Systems and Technologies | Lodz, Poland

[WorldCIST-24]

* CORE Conference
** Google Scholar H5-Index = 25

*** Indexed in Scopus, WoS, DBLP, etc.




----
---
WorldCIST'24 - The 12th World Conference on Information Systems and Technologies

Lodz University of Technology, Lodz, Poland, March 26-28, 2024

http://worldcist.org/ 


 ---
---



Scope

The WorldCist'24 - 12nd World Conference on Information Systems and 
Technologies,  to be held in Lodz, at Lodz University of Technology, Poland, 26 
- 28 March 2024, is a global forum for researchers and practitioners to present 
and discuss the most recent innovations, trends, results, experiences and 
concerns in the several perspectives of Information Systems and Technologies.

We are pleased to invite you to submit your original papers to WorldCist'24. 
All submissions will be reviewed on the basis of relevance, originality, 
importance and clarity.



Themes

Submitted papers should be related with one or more of the main themes proposed 
for the Conference:

A) Information and Knowledge Management (IKM);

B) Organizational Models and Information Systems (OMIS);

C) Software and Systems Modeling (SSM);

D) Software Systems, Architectures, Applications and Tools (SSAAT);

E) Multimedia Systems and Applications (MSA);

F) Computer Networks, Mobility and Pervasive Systems (CNMPS);

G) Intelligent and Decision Support Systems (IDSS);

H) Big Data Analytics and Applications (BDAA);

I) Human-Computer Interaction (HCI);

J) Ethics, Computers and Security (ECS)

K) Health Informatics (HIS);

L) Information Technologies in Education (ITE);

M) Technologies for Biomedical Applications (TBA)

N) Information Technologies in Radiocommunications (ITR);



Types of Submissions and Decisions

Four types of original papers can be submitted:

Full paper: Finished or consolidated R works, to be included in one of the 
Conference themes. These papers are assigned a 10-page limit.

Short paper: Ongoing works with relevant preliminary results, open to 
discussion. These papers are assigned a 7-page limit.

Poster paper: Initial work with relevant ideas, open to discussion. These 
papers are assigned to a 4-page limit.

Company paper: Companies' papers that show practical experience, R & D, tools, 
etc., focused on some topics of the conference. These papers are assigned to a 
4-page limit.

Submitted papers must comply with the format of Lecture Notes in Networks and 
Systems series (see Instructions for Authors at Springer Website) 
,
 be written in English, must not have been published before, not be under 
review for any other conference or publication and not include any information 
leading to the authors’ identification. Therefore, the authors’ names, 
affiliations and bibliographic references should not be included in the version 
for evaluation by the Program Committee. This information should only be 
included in the camera-ready version, saved in Word or Latex format and also in 
PDF format. These files must be accompanied by the Consent to Publish form 
filled out, in a ZIP file, and uploaded at the conference management system.


All papers will be subjected to a “double-blind review” by at least two members 
of the Program Committee.

Based on Program Committee evaluation, a paper can be rejected or accepted by 
the Conference Chairs. In the later case, it can be accepted as the type 
originally submitted or as another type. Thus, full papers can be accepted as 
short papers or poster papers only. Similarly, short papers can be accepted as 
poster papers only.

Poster papers and Company papers are not published in the Conference 
Proceedings, being only presented and discussed. The authors of accepted poster 
papers should build and print a poster to be exhibited during the Conference. 
This poster must follow an A1 or A2 vertical format. The Conference includes 
Work Sessions where these posters are presented and orally discussed, with a 7 
minute limit per poster.

The authors of accepted Full papers will have 15 minutes to present their work 
in a Conference Work Session; approximately 5 minutes of discussion will follow 
each presentation. The authors of accepted Short papers and Company papers will 
have 11 minutes to present their work in a Conference Work Session; 
approximately 4 minutes of discussion will follow each presentation.



Publication and Indexing

To ensure that a full paper or short paper is published and presented, poster 
paper or company paper is presented, at least one of the authors must be fully 
registered by the 5th of January 2024, and the paper must 

Re: [-next 1/5] PCI: Add the pci_is_vga() helper

[Bjorn Helgaas]

On Wed, Aug 30, 2023 at 07:15:28PM +0800, Sui Jingfeng wrote:
> From: Sui Jingfeng 
> 
> The PCI code and ID assignment specification defined four types of
> display controllers for the display base class(03h), and the devices
> with 0x00h sub-class code are VGA devices. VGA devices with programming

I can update this with the spec details (PCI Code and Assignment spec
r1.15, secs 1.1 and 1.4).

> interface 0x00 is VGA-compatible, VGA devices with programming interface
> 0x01 are 8514-compatible controllers. Besides, PCI_CLASS_NOT_DEFINED_VGA
> is defined to provide backward compatibility for devices that were built
> before the class code field was defined. Hence, introduce the pci_is_vga()
> helper, let it handle the details for us. It returns true if the PCI(e)
> device being tested belongs to the VGA devices category.
>
> Cc: "Maciej W. Rozycki" 
> Signed-off-by: Sui Jingfeng 
> ---
>  include/linux/pci.h | 27 +++
>  1 file changed, 27 insertions(+)
> 
> diff --git a/include/linux/pci.h b/include/linux/pci.h
> index cf6e0b057752..ace727001911 100644
> --- a/include/linux/pci.h
> +++ b/include/linux/pci.h
> @@ -713,6 +713,33 @@ static inline bool pci_is_bridge(struct pci_dev *dev)
>   dev->hdr_type == PCI_HEADER_TYPE_CARDBUS;
>  }
>  
> +/**
> + * The PCI code and ID assignment specification defined four types of
> + * display controllers for the display base class(03h), and the devices
> + * with 0x00h sub-class code are VGA devices. VGA devices with programming
> + * interface 0x00 is VGA-compatible, VGA devices with programming interface
> + * 0x01 are 8514-compatible controllers. Besides, PCI_CLASS_NOT_DEFINED_VGA
> + * is defined to provide backward compatibility for devices that were built
> + * before the class code field was defined. This means that it belong to the
> + * VGA devices category also.
> + *
> + * Returns:
> + * true if the PCI device is a VGA device, false otherwise.
> + */
> +static inline bool pci_is_vga(struct pci_dev *pdev)
> +{
> + if (!pdev)
> + return false;
> +
> + if ((pdev->class >> 8) == PCI_CLASS_DISPLAY_VGA)
> + return true;
> +
> + if ((pdev->class >> 8) == PCI_CLASS_NOT_DEFINED_VGA)
> + return true;

Are you seeing a problem that will be fixed by this series, i.e., a
PCI_CLASS_NOT_DEFINED_VGA device that we currently don't handle
correctly?

I think this makes sense per the spec, but there's always a risk of
breaking something, so it's nice if the change actually *fixes*
something to make that risk worthwhile.

> + return false;
> +}
> +
>  #define for_each_pci_bridge(dev, bus)\
>   list_for_each_entry(dev, >devices, bus_list)   \
>   if (!pci_is_bridge(dev)) {} else
> -- 
> 2.34.1
> 
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [-next 4/5] drm/virgpu: Switch to pci_is_vga()

[Bjorn Helgaas]

On Thu, Oct 05, 2023 at 04:57:14PM -0500, Bjorn Helgaas wrote:
> In subject: "drm/virtio" to match previous history.
> 
> On Wed, Aug 30, 2023 at 07:15:31PM +0800, Sui Jingfeng wrote:
> > From: Sui Jingfeng 
> > 
> > Should be no functional change, just for cleanup purpose.
> > 
> > Cc: David Airlie 
> > Cc: Gerd Hoffmann 
> > Cc: Gurchetan Singh 
> > Cc: Chia-I Wu 
> > Cc: Daniel Vetter 
> > Signed-off-by: Sui Jingfeng 
> > ---
> >  drivers/gpu/drm/virtio/virtgpu_drv.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.c 
> > b/drivers/gpu/drm/virtio/virtgpu_drv.c
> > index add075681e18..3a368304475a 100644
> > --- a/drivers/gpu/drm/virtio/virtgpu_drv.c
> > +++ b/drivers/gpu/drm/virtio/virtgpu_drv.c
> > @@ -51,7 +51,7 @@ static int virtio_gpu_pci_quirk(struct drm_device *dev)
> >  {
> > struct pci_dev *pdev = to_pci_dev(dev->dev);
> > const char *pname = dev_name(>dev);
> > -   bool vga = (pdev->class >> 8) == PCI_CLASS_DISPLAY_VGA;
> > +   bool vga = pci_is_vga(pdev);
> 
> This *is* a functional change: Previously "vga" was only true for
> PCI_CLASS_DISPLAY_VGA (0x0300).  Now it will be true for both
> PCI_CLASS_DISPLAY_VGA (0x0300) and PCI_CLASS_DISPLAY_OTHER (0x0380).

Oops, sorry, my mistake here.  I meant PCI_CLASS_NOT_DEFINED_VGA, not
PCI_CLASS_DISPLAY_OTHER.  pci_is_vga() is true for either of:

  PCI_CLASS_DISPLAY_VGA   0x0300
  PCI_CLASS_NOT_DEFINED_VGA   0x0001

(PCI_CLASS_NOT_DEFINED_VGA is defined in the PCI Code and Assignment
spec r1.15, sec 1.1; PCI_CLASS_DISPLAY_VGA is sec 1.4.)

> Is that desirable?  I can't tell.  Maybe the GPU folks will chime in.
> 
> > int ret;
> >  
> > DRM_INFO("pci: %s detected at %s\n",
> > -- 
> > 2.34.1
> > 
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [-next 4/5] drm/virgpu: Switch to pci_is_vga()

[Bjorn Helgaas]

In subject: "drm/virtio" to match previous history.

On Wed, Aug 30, 2023 at 07:15:31PM +0800, Sui Jingfeng wrote:
> From: Sui Jingfeng 
> 
> Should be no functional change, just for cleanup purpose.
> 
> Cc: David Airlie 
> Cc: Gerd Hoffmann 
> Cc: Gurchetan Singh 
> Cc: Chia-I Wu 
> Cc: Daniel Vetter 
> Signed-off-by: Sui Jingfeng 
> ---
>  drivers/gpu/drm/virtio/virtgpu_drv.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.c 
> b/drivers/gpu/drm/virtio/virtgpu_drv.c
> index add075681e18..3a368304475a 100644
> --- a/drivers/gpu/drm/virtio/virtgpu_drv.c
> +++ b/drivers/gpu/drm/virtio/virtgpu_drv.c
> @@ -51,7 +51,7 @@ static int virtio_gpu_pci_quirk(struct drm_device *dev)
>  {
>   struct pci_dev *pdev = to_pci_dev(dev->dev);
>   const char *pname = dev_name(>dev);
> - bool vga = (pdev->class >> 8) == PCI_CLASS_DISPLAY_VGA;
> + bool vga = pci_is_vga(pdev);

This *is* a functional change: Previously "vga" was only true for
PCI_CLASS_DISPLAY_VGA (0x0300).  Now it will be true for both
PCI_CLASS_DISPLAY_VGA (0x0300) and PCI_CLASS_DISPLAY_OTHER (0x0380).

Is that desirable?  I can't tell.  Maybe the GPU folks will chime in.

>   int ret;
>  
>   DRM_INFO("pci: %s detected at %s\n",
> -- 
> 2.34.1
> 
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH net-next v4 2/2] virtio-net: add cond_resched() to the command waiting loop

[Feng Liu via Virtualization]

On 2023-07-24 a.m.2:46, Michael S. Tsirkin wrote:

External email: Use caution opening links or attachments


On Fri, Jul 21, 2023 at 10:18:03PM +0200, Maxime Coquelin wrote:



On 7/21/23 17:10, Michael S. Tsirkin wrote:

On Fri, Jul 21, 2023 at 04:58:04PM +0200, Maxime Coquelin wrote:



On 7/21/23 16:45, Michael S. Tsirkin wrote:

On Fri, Jul 21, 2023 at 04:37:00PM +0200, Maxime Coquelin wrote:



On 7/20/23 23:02, Michael S. Tsirkin wrote:

On Thu, Jul 20, 2023 at 01:26:20PM -0700, Shannon Nelson wrote:

On 7/20/23 1:38 AM, Jason Wang wrote:


Adding cond_resched() to the command waiting loop for a better
co-operation with the scheduler. This allows to give CPU a breath to
run other task(workqueue) instead of busy looping when preemption is
not allowed on a device whose CVQ might be slow.

Signed-off-by: Jason Wang 


This still leaves hung processes, but at least it doesn't pin the CPU any
more.  Thanks.
Reviewed-by: Shannon Nelson 



I'd like to see a full solution
1- block until interrupt


Would it make sense to also have a timeout?
And when timeout expires, set FAILED bit in device status?


virtio spec does not set any limits on the timing of vq
processing.


Indeed, but I thought the driver could decide it is too long for it.

The issue is we keep waiting with rtnl locked, it can quickly make the
system unusable.


if this is a problem we should find a way not to keep rtnl
locked indefinitely.


 From the tests I have done, I think it is. With OVS, a reconfiguration is
performed when the VDUSE device is added, and when a MLX5 device is
in the same bridge, it ends up doing an ioctl() that tries to take the
rtnl lock. In this configuration, it is not possible to kill OVS because
it is stuck trying to acquire rtnl lock for mlx5 that is held by virtio-
net.


So for sure, we can queue up the work and process it later.
The somewhat tricky part is limiting the memory consumption.





Hi Jason

Excuse me, is there any plan for when will v5 patch series be sent out? 
Will the v5 patches solve the problem of ctrlvq's infinite poll for 
buggy devices?


Thanks
Feng




2- still handle surprise removal correctly by waking in that case




---
  drivers/net/virtio_net.c | 4 +++-
  1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index 9f3b1d6ac33d..e7533f29b219 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -2314,8 +2314,10 @@ static bool virtnet_send_command(struct virtnet_info 
*vi, u8 class, u8 cmd,
  * into the hypervisor, so the request should be handled 
immediately.
  */
 while (!virtqueue_get_buf(vi->cvq, ) &&
-  !virtqueue_is_broken(vi->cvq))
+  !virtqueue_is_broken(vi->cvq)) {
+   cond_resched();
 cpu_relax();
+   }

 return vi->ctrl->status == VIRTIO_NET_OK;
  }
--
2.39.3

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization








___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH vhost v2 00/16] vdpa: Add support for vq descriptor mappings

[Michael S. Tsirkin]

On Thu, Oct 05, 2023 at 05:44:01PM +, Dragos Tatulea wrote:
> On Thu, 2023-10-05 at 13:31 -0400, Michael S. Tsirkin wrote:
> > On Thu, Sep 28, 2023 at 07:45:11PM +0300, Dragos Tatulea wrote:
> > > This patch series adds support for vq descriptor table mappings which
> > > are used to improve vdpa live migration downtime. The improvement comes
> > > from using smaller mappings which take less time to create and destroy
> > > in hw.
> > > 
> > > The first part adds the vdpa core changes from Si-Wei [0].
> > > 
> > > The second part adds support in mlx5_vdpa:
> > > - Refactor the mr code to be able to cleanly add descriptor mappings.
> > > - Add hardware descriptor mr support.
> > > - Properly update iotlb for cvq during ASID switch.
> > > 
> > > Changes in v2:
> > > 
> > > - The "vdpa/mlx5: Enable hw support for vq descriptor mapping" change
> > >   was split off into two patches to avoid merge conflicts into the tree
> > >   of Linus.
> > > 
> > >   The first patch contains only changes for mlx5_ifc.h. This must be
> > >   applied into the mlx5-next tree [1] first. Once this patch is applied
> > >   on mlx5-next, the change has to be pulled fom mlx5-next into the vhost
> > >   tree and only then the remaining patches can be applied.
> > 
> > 
> > I get it you plan v3?
> There are some very small improvements (commit message in 13/16 and fix in
> 16/16) that could make a v3. The latter can be addressed as a separate patch
> when moving dup_iotlb to vhost/iotlb. What do you think?


if there's a fix by all means post v3.

> > 
> > > [0]
> > > https://lore.kernel.org/virtualization/1694248959-13369-1-git-send-email-si-wei@oracle.com
> > > [1]
> > > https://git.kernel.org/pub/scm/linux/kernel/git/mellanox/linux.git/log/?h=mlx5-next
> > > 
> > > Dragos Tatulea (13):
> > >   vdpa/mlx5: Expose descriptor group mkey hw capability
> > >   vdpa/mlx5: Create helper function for dma mappings
> > >   vdpa/mlx5: Decouple cvq iotlb handling from hw mapping code
> > >   vdpa/mlx5: Take cvq iotlb lock during refresh
> > >   vdpa/mlx5: Collapse "dvq" mr add/delete functions
> > >   vdpa/mlx5: Rename mr destroy functions
> > >   vdpa/mlx5: Allow creation/deletion of any given mr struct
> > >   vdpa/mlx5: Move mr mutex out of mr struct
> > >   vdpa/mlx5: Improve mr update flow
> > >   vdpa/mlx5: Introduce mr for vq descriptor
> > >   vdpa/mlx5: Enable hw support for vq descriptor mapping
> > >   vdpa/mlx5: Make iotlb helper functions more generic
> > >   vdpa/mlx5: Update cvq iotlb mapping on ASID change
> > > 
> > > Si-Wei Liu (3):
> > >   vdpa: introduce dedicated descriptor group for virtqueue
> > >   vhost-vdpa: introduce descriptor group backend feature
> > >   vhost-vdpa: uAPI to get dedicated descriptor group id
> > > 
> > >  drivers/vdpa/mlx5/core/mlx5_vdpa.h |  31 +++--
> > >  drivers/vdpa/mlx5/core/mr.c    | 191 -
> > >  drivers/vdpa/mlx5/core/resources.c |   6 +-
> > >  drivers/vdpa/mlx5/net/mlx5_vnet.c  | 100 ++-
> > >  drivers/vhost/vdpa.c   |  27 
> > >  include/linux/mlx5/mlx5_ifc.h  |   8 +-
> > >  include/linux/mlx5/mlx5_ifc_vdpa.h |   7 +-
> > >  include/linux/vdpa.h   |  11 ++
> > >  include/uapi/linux/vhost.h |   8 ++
> > >  include/uapi/linux/vhost_types.h   |   5 +
> > >  10 files changed, 264 insertions(+), 130 deletions(-)
> > > 
> > > -- 
> > > 2.41.0
> > 
> 

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH vhost v2 00/16] vdpa: Add support for vq descriptor mappings

[Dragos Tatulea via Virtualization]

On Thu, 2023-10-05 at 13:31 -0400, Michael S. Tsirkin wrote:
> On Thu, Sep 28, 2023 at 07:45:11PM +0300, Dragos Tatulea wrote:
> > This patch series adds support for vq descriptor table mappings which
> > are used to improve vdpa live migration downtime. The improvement comes
> > from using smaller mappings which take less time to create and destroy
> > in hw.
> > 
> > The first part adds the vdpa core changes from Si-Wei [0].
> > 
> > The second part adds support in mlx5_vdpa:
> > - Refactor the mr code to be able to cleanly add descriptor mappings.
> > - Add hardware descriptor mr support.
> > - Properly update iotlb for cvq during ASID switch.
> > 
> > Changes in v2:
> > 
> > - The "vdpa/mlx5: Enable hw support for vq descriptor mapping" change
> >   was split off into two patches to avoid merge conflicts into the tree
> >   of Linus.
> > 
> >   The first patch contains only changes for mlx5_ifc.h. This must be
> >   applied into the mlx5-next tree [1] first. Once this patch is applied
> >   on mlx5-next, the change has to be pulled fom mlx5-next into the vhost
> >   tree and only then the remaining patches can be applied.
> 
> 
> I get it you plan v3?
There are some very small improvements (commit message in 13/16 and fix in
16/16) that could make a v3. The latter can be addressed as a separate patch
when moving dup_iotlb to vhost/iotlb. What do you think?

> 
> > [0]
> > https://lore.kernel.org/virtualization/1694248959-13369-1-git-send-email-si-wei@oracle.com
> > [1]
> > https://git.kernel.org/pub/scm/linux/kernel/git/mellanox/linux.git/log/?h=mlx5-next
> > 
> > Dragos Tatulea (13):
> >   vdpa/mlx5: Expose descriptor group mkey hw capability
> >   vdpa/mlx5: Create helper function for dma mappings
> >   vdpa/mlx5: Decouple cvq iotlb handling from hw mapping code
> >   vdpa/mlx5: Take cvq iotlb lock during refresh
> >   vdpa/mlx5: Collapse "dvq" mr add/delete functions
> >   vdpa/mlx5: Rename mr destroy functions
> >   vdpa/mlx5: Allow creation/deletion of any given mr struct
> >   vdpa/mlx5: Move mr mutex out of mr struct
> >   vdpa/mlx5: Improve mr update flow
> >   vdpa/mlx5: Introduce mr for vq descriptor
> >   vdpa/mlx5: Enable hw support for vq descriptor mapping
> >   vdpa/mlx5: Make iotlb helper functions more generic
> >   vdpa/mlx5: Update cvq iotlb mapping on ASID change
> > 
> > Si-Wei Liu (3):
> >   vdpa: introduce dedicated descriptor group for virtqueue
> >   vhost-vdpa: introduce descriptor group backend feature
> >   vhost-vdpa: uAPI to get dedicated descriptor group id
> > 
> >  drivers/vdpa/mlx5/core/mlx5_vdpa.h |  31 +++--
> >  drivers/vdpa/mlx5/core/mr.c    | 191 -
> >  drivers/vdpa/mlx5/core/resources.c |   6 +-
> >  drivers/vdpa/mlx5/net/mlx5_vnet.c  | 100 ++-
> >  drivers/vhost/vdpa.c   |  27 
> >  include/linux/mlx5/mlx5_ifc.h  |   8 +-
> >  include/linux/mlx5/mlx5_ifc_vdpa.h |   7 +-
> >  include/linux/vdpa.h   |  11 ++
> >  include/uapi/linux/vhost.h |   8 ++
> >  include/uapi/linux/vhost_types.h   |   5 +
> >  10 files changed, 264 insertions(+), 130 deletions(-)
> > 
> > -- 
> > 2.41.0
> 

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH vhost v2 00/16] vdpa: Add support for vq descriptor mappings

[Michael S. Tsirkin]

On Thu, Sep 28, 2023 at 07:45:11PM +0300, Dragos Tatulea wrote:
> This patch series adds support for vq descriptor table mappings which
> are used to improve vdpa live migration downtime. The improvement comes
> from using smaller mappings which take less time to create and destroy
> in hw.
> 
> The first part adds the vdpa core changes from Si-Wei [0].
> 
> The second part adds support in mlx5_vdpa:
> - Refactor the mr code to be able to cleanly add descriptor mappings.
> - Add hardware descriptor mr support.
> - Properly update iotlb for cvq during ASID switch.
> 
> Changes in v2:
> 
> - The "vdpa/mlx5: Enable hw support for vq descriptor mapping" change
>   was split off into two patches to avoid merge conflicts into the tree
>   of Linus.
> 
>   The first patch contains only changes for mlx5_ifc.h. This must be
>   applied into the mlx5-next tree [1] first. Once this patch is applied
>   on mlx5-next, the change has to be pulled fom mlx5-next into the vhost
>   tree and only then the remaining patches can be applied.


I get it you plan v3?

> [0] 
> https://lore.kernel.org/virtualization/1694248959-13369-1-git-send-email-si-wei@oracle.com
> [1] 
> https://git.kernel.org/pub/scm/linux/kernel/git/mellanox/linux.git/log/?h=mlx5-next
> 
> Dragos Tatulea (13):
>   vdpa/mlx5: Expose descriptor group mkey hw capability
>   vdpa/mlx5: Create helper function for dma mappings
>   vdpa/mlx5: Decouple cvq iotlb handling from hw mapping code
>   vdpa/mlx5: Take cvq iotlb lock during refresh
>   vdpa/mlx5: Collapse "dvq" mr add/delete functions
>   vdpa/mlx5: Rename mr destroy functions
>   vdpa/mlx5: Allow creation/deletion of any given mr struct
>   vdpa/mlx5: Move mr mutex out of mr struct
>   vdpa/mlx5: Improve mr update flow
>   vdpa/mlx5: Introduce mr for vq descriptor
>   vdpa/mlx5: Enable hw support for vq descriptor mapping
>   vdpa/mlx5: Make iotlb helper functions more generic
>   vdpa/mlx5: Update cvq iotlb mapping on ASID change
> 
> Si-Wei Liu (3):
>   vdpa: introduce dedicated descriptor group for virtqueue
>   vhost-vdpa: introduce descriptor group backend feature
>   vhost-vdpa: uAPI to get dedicated descriptor group id
> 
>  drivers/vdpa/mlx5/core/mlx5_vdpa.h |  31 +++--
>  drivers/vdpa/mlx5/core/mr.c| 191 -
>  drivers/vdpa/mlx5/core/resources.c |   6 +-
>  drivers/vdpa/mlx5/net/mlx5_vnet.c  | 100 ++-
>  drivers/vhost/vdpa.c   |  27 
>  include/linux/mlx5/mlx5_ifc.h  |   8 +-
>  include/linux/mlx5/mlx5_ifc_vdpa.h |   7 +-
>  include/linux/vdpa.h   |  11 ++
>  include/uapi/linux/vhost.h |   8 ++
>  include/uapi/linux/vhost_types.h   |   5 +
>  10 files changed, 264 insertions(+), 130 deletions(-)
> 
> -- 
> 2.41.0

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH 0/9] drm: Annotate structs with __counted_by

[Kees Cook]

On Thu, Oct 05, 2023 at 11:42:38AM +0200, Christian König wrote:
> Am 02.10.23 um 20:22 schrieb Kees Cook:
> > On Mon, Oct 02, 2023 at 08:11:41PM +0200, Christian König wrote:
> > > Am 02.10.23 um 20:08 schrieb Kees Cook:
> > > > On Mon, Oct 02, 2023 at 08:01:57PM +0200, Christian König wrote:
> > > > > Am 02.10.23 um 18:53 schrieb Kees Cook:
> > > > > > On Mon, Oct 02, 2023 at 11:06:19AM -0400, Alex Deucher wrote:
> > > > > > > On Mon, Oct 2, 2023 at 5:20 AM Christian König
> > > > > > >  wrote:
> > > > > > > > Am 29.09.23 um 21:33 schrieb Kees Cook:
> > > > > > > > > On Fri, 22 Sep 2023 10:32:05 -0700, Kees Cook wrote:
> > > > > > > > > > This is a batch of patches touching drm for preparing for 
> > > > > > > > > > the coming
> > > > > > > > > > implementation by GCC and Clang of the __counted_by 
> > > > > > > > > > attribute. Flexible
> > > > > > > > > > array members annotated with __counted_by can have their 
> > > > > > > > > > accesses
> > > > > > > > > > bounds-checked at run-time checking via CONFIG_UBSAN_BOUNDS 
> > > > > > > > > > (for array
> > > > > > > > > > indexing) and CONFIG_FORTIFY_SOURCE (for 
> > > > > > > > > > strcpy/memcpy-family functions).
> > > > > > > > > > 
> > > > > > > > > > As found with Coccinelle[1], add __counted_by to structs 
> > > > > > > > > > that would
> > > > > > > > > > benefit from the annotation.
> > > > > > > > > > 
> > > > > > > > > > [...]
> > > > > > > > > Since this got Acks, I figure I should carry it in my tree. 
> > > > > > > > > Let me know
> > > > > > > > > if this should go via drm instead.
> > > > > > > > > 
> > > > > > > > > Applied to for-next/hardening, thanks!
> > > > > > > > > 
> > > > > > > > > [1/9] drm/amd/pm: Annotate struct 
> > > > > > > > > smu10_voltage_dependency_table with __counted_by
> > > > > > > > >   https://git.kernel.org/kees/c/a6046ac659d6
> > > > > > > > STOP! In a follow up discussion Alex and I figured out that 
> > > > > > > > this won't work.
> > > > > > I'm so confused; from the discussion I saw that Alex said both 
> > > > > > instances
> > > > > > were false positives?
> > > > > > 
> > > > > > > > The value in the structure is byte swapped based on some 
> > > > > > > > firmware
> > > > > > > > endianness which not necessary matches the CPU endianness.
> > > > > > > SMU10 is APU only so the endianess of the SMU firmware and the CPU
> > > > > > > will always match.
> > > > > > Which I think is what is being said here?
> > > > > > 
> > > > > > > > Please revert that one from going upstream if it's already on 
> > > > > > > > it's way.
> > > > > > > > 
> > > > > > > > And because of those reasons I strongly think that patches like 
> > > > > > > > this
> > > > > > > > should go through the DRM tree :)
> > > > > > Sure, that's fine -- please let me know. It was others Acked/etc. 
> > > > > > Who
> > > > > > should carry these patches?
> > > > > Probably best if the relevant maintainer pick them up individually.
> > > > > 
> > > > > Some of those structures are filled in by firmware/hardware and only 
> > > > > the
> > > > > maintainers can judge if that value actually matches what the compiler
> > > > > needs.
> > > > > 
> > > > > We have cases where individual bits are used as flags or when the 
> > > > > size is
> > > > > byte swapped etc...
> > > > > 
> > > > > Even Alex and I didn't immediately say how and where that field is 
> > > > > actually
> > > > > used and had to dig that up. That's where the confusion came from.
> > > > Okay, I've dropped them all from my tree. Several had Acks/Reviews, so
> > > > hopefully those can get picked up for the DRM tree?
> > > I will pick those up to go through drm-misc-next.
> > > 
> > > Going to ping maintainers once more when I'm not sure if stuff is correct 
> > > or
> > > not.
> > Sounds great; thanks!
> 
> I wasn't 100% sure for the VC4 patch, but pushed the whole set to
> drm-misc-next anyway.
> 
> This also means that the patches are now auto merged into the drm-tip
> integration branch and should any build or unit test go boom we should
> notice immediately and can revert it pretty easily.

Thanks very much; I'll keep an eye out for any reports.

-- 
Kees Cook
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH vhost 16/16] vdpa/mlx5: Update cvq iotlb mapping on ASID change

[Dragos Tatulea via Virtualization]

On Thu, 2023-10-05 at 12:41 +0200, Eugenio Perez Martin wrote:
> On Thu, Sep 28, 2023 at 6:50 PM Dragos Tatulea  wrote:
> > 
> > For the following sequence:
> > - cvq group is in ASID 0
> > - .set_map(1, cvq_iotlb)
> > - .set_group_asid(cvq_group, 1)
> > 
> > ... the cvq mapping from ASID 0 will be used. This is not always correct
> > behaviour.
> > 
> > This patch adds support for the above mentioned flow by saving the iotlb
> > on each .set_map and updating the cvq iotlb with it on a cvq group change.
> > 
> > Signed-off-by: Dragos Tatulea 
> > ---
> >  drivers/vdpa/mlx5/core/mlx5_vdpa.h |  2 ++
> >  drivers/vdpa/mlx5/core/mr.c    | 26 ++
> >  drivers/vdpa/mlx5/net/mlx5_vnet.c  |  9 -
> >  3 files changed, 36 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/vdpa/mlx5/core/mlx5_vdpa.h
> > b/drivers/vdpa/mlx5/core/mlx5_vdpa.h
> > index ae09296f4270..db988ced5a5d 100644
> > --- a/drivers/vdpa/mlx5/core/mlx5_vdpa.h
> > +++ b/drivers/vdpa/mlx5/core/mlx5_vdpa.h
> > @@ -32,6 +32,8 @@ struct mlx5_vdpa_mr {
> >     unsigned long num_directs;
> >     unsigned long num_klms;
> > 
> > +   struct vhost_iotlb *iotlb;
> > +
> >     bool user_mr;
> >  };
> > 
> > diff --git a/drivers/vdpa/mlx5/core/mr.c b/drivers/vdpa/mlx5/core/mr.c
> > index a4135c16b5bf..403c08271489 100644
> > --- a/drivers/vdpa/mlx5/core/mr.c
> > +++ b/drivers/vdpa/mlx5/core/mr.c
> > @@ -499,6 +499,8 @@ static void _mlx5_vdpa_destroy_mr(struct mlx5_vdpa_dev
> > *mvdev, struct mlx5_vdpa_
> >     destroy_user_mr(mvdev, mr);
> >     else
> >     destroy_dma_mr(mvdev, mr);
> > +
> > +   vhost_iotlb_free(mr->iotlb);
> >  }
> > 
> >  void mlx5_vdpa_destroy_mr(struct mlx5_vdpa_dev *mvdev,
> > @@ -558,6 +560,30 @@ static int _mlx5_vdpa_create_mr(struct mlx5_vdpa_dev
> > *mvdev,
> >     else
> >     err = create_dma_mr(mvdev, mr);
> > 
> > +   if (err)
> > +   return err;
> > +
> > +   mr->iotlb = vhost_iotlb_alloc(0, 0);
> > +   if (!mr->iotlb) {
> > +   err = -ENOMEM;
> > +   goto err_mr;
> > +   }
> > +
> > +   err = dup_iotlb(mr->iotlb, iotlb);
> > +   if (err)
> > +   goto err_iotlb;
> > +
> > +   return 0;
> > +
> > +err_iotlb:
> > +   vhost_iotlb_free(mr->iotlb);
> > +
> > +err_mr:
> > +   if (iotlb)
> > +   destroy_user_mr(mvdev, mr);
> > +   else
> > +   destroy_dma_mr(mvdev, mr);
> > +
> >     return err;
> >  }
> > 
> > diff --git a/drivers/vdpa/mlx5/net/mlx5_vnet.c
> > b/drivers/vdpa/mlx5/net/mlx5_vnet.c
> > index 46441e41892c..fc5d6b989a5a 100644
> > --- a/drivers/vdpa/mlx5/net/mlx5_vnet.c
> > +++ b/drivers/vdpa/mlx5/net/mlx5_vnet.c
> > @@ -3154,12 +3154,19 @@ static int mlx5_set_group_asid(struct vdpa_device
> > *vdev, u32 group,
> >    unsigned int asid)
> >  {
> >     struct mlx5_vdpa_dev *mvdev = to_mvdev(vdev);
> > +   int err = 0;
> > 
> >     if (group >= MLX5_VDPA_NUMVQ_GROUPS || asid >= MLX5_VDPA_NUM_AS)
> >     return -EINVAL;
> > 
> >     mvdev->group2asid[group] = asid;
> > -   return 0;
> > +
> > +   mutex_lock(>mr_mtx);
> > +   if (group == MLX5_VDPA_CVQ_GROUP && mvdev->mr[asid])
> > +   err = mlx5_vdpa_update_cvq_iotlb(mvdev, mvdev->mr[asid]-
> > >iotlb, asid);
> 
> Do we need to protect here in case userspace sets the same ASID twice?
> mlx5_vdpa_update_cvq_iotlb shouldn't call dup_iotlb with the same src
> and dst.

Why would src and dst be identical? Doesn't dup_iotlb create a copy of src?

That being said, there should be a check in dup_iotlb for dst == src. Not sure
if this is an error or success though...

Thanks,
Dragos
- 
> Apart from that:
> 
> Acked-by: Eugenio Pérez 
> 
> > +   mutex_unlock(>mr_mtx);
> > +
> > +   return err;
> >  }
> > 
> >  static const struct vdpa_config_ops mlx5_vdpa_ops = {
> > --
> > 2.41.0
> > 
> 

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH vhost 15/16] vdpa/mlx5: Make iotlb helper functions more generic

[Dragos Tatulea via Virtualization]

On Thu, 2023-10-05 at 12:14 +0200, Eugenio Perez Martin wrote:
> On Thu, Sep 28, 2023 at 6:50 PM Dragos Tatulea  wrote:
> > 
> > They will be used in a followup patch.
> > 
> > Signed-off-by: Dragos Tatulea 
> > ---
> >  drivers/vdpa/mlx5/core/mr.c | 16 
> >  1 file changed, 8 insertions(+), 8 deletions(-)
> > 
> > diff --git a/drivers/vdpa/mlx5/core/mr.c b/drivers/vdpa/mlx5/core/mr.c
> > index 3dee6d9bed6b..a4135c16b5bf 100644
> > --- a/drivers/vdpa/mlx5/core/mr.c
> > +++ b/drivers/vdpa/mlx5/core/mr.c
> > @@ -454,20 +454,20 @@ static void destroy_dma_mr(struct mlx5_vdpa_dev
> > *mvdev, struct mlx5_vdpa_mr *mr)
> >     mlx5_vdpa_destroy_mkey(mvdev, mr->mkey);
> >  }
> > 
> > -static int dup_iotlb(struct mlx5_vdpa_dev *mvdev, struct vhost_iotlb *src)
> > +static int dup_iotlb(struct vhost_iotlb *iotlb, struct vhost_iotlb *src)
> 
> It would be great to move this patch to vhost/iotlb, especially
> because it can be reused by vdpa_sim. But it can be done on top for
> sure,
> 
Ack. Will create a separate patch for this after the series.

Thanks,
Dragos

> Acked-by: Eugenio Pérez 
> 
> >  {
> >     struct vhost_iotlb_map *map;
> >     u64 start = 0, last = ULLONG_MAX;
> >     int err;
> > 
> >     if (!src) {
> > -   err = vhost_iotlb_add_range(mvdev->cvq.iotlb, start, last,
> > start, VHOST_ACCESS_RW);
> > +   err = vhost_iotlb_add_range(iotlb, start, last, start,
> > VHOST_ACCESS_RW);
> >     return err;
> >     }
> > 
> >     for (map = vhost_iotlb_itree_first(src, start, last); map;
> >     map = vhost_iotlb_itree_next(map, start, last)) {
> > -   err = vhost_iotlb_add_range(mvdev->cvq.iotlb, map->start,
> > map->last,
> > +   err = vhost_iotlb_add_range(iotlb, map->start, map->last,
> >     map->addr, map->perm);
> >     if (err)
> >     return err;
> > @@ -475,9 +475,9 @@ static int dup_iotlb(struct mlx5_vdpa_dev *mvdev, struct
> > vhost_iotlb *src)
> >     return 0;
> >  }
> > 
> > -static void prune_iotlb(struct mlx5_vdpa_dev *mvdev)
> > +static void prune_iotlb(struct vhost_iotlb *iotlb)
> >  {
> > -   vhost_iotlb_del_range(mvdev->cvq.iotlb, 0, ULLONG_MAX);
> > +   vhost_iotlb_del_range(iotlb, 0, ULLONG_MAX);
> >  }
> > 
> >  static void destroy_user_mr(struct mlx5_vdpa_dev *mvdev, struct
> > mlx5_vdpa_mr *mr)
> > @@ -544,7 +544,7 @@ void mlx5_vdpa_destroy_mr_resources(struct mlx5_vdpa_dev
> > *mvdev)
> >     for (int i = 0; i < MLX5_VDPA_NUM_AS; i++)
> >     mlx5_vdpa_destroy_mr(mvdev, mvdev->mr[i]);
> > 
> > -   prune_iotlb(mvdev);
> > +   prune_iotlb(mvdev->cvq.iotlb);
> >  }
> > 
> >  static int _mlx5_vdpa_create_mr(struct mlx5_vdpa_dev *mvdev,
> > @@ -596,8 +596,8 @@ int mlx5_vdpa_update_cvq_iotlb(struct mlx5_vdpa_dev
> > *mvdev,
> > 
> >     spin_lock(>cvq.iommu_lock);
> > 
> > -   prune_iotlb(mvdev);
> > -   err = dup_iotlb(mvdev, iotlb);
> > +   prune_iotlb(mvdev->cvq.iotlb);
> > +   err = dup_iotlb(mvdev->cvq.iotlb, iotlb);
> > 
> >     spin_unlock(>cvq.iommu_lock);
> > 
> > --
> > 2.41.0
> > 
> 

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH vhost 14/16] vdpa/mlx5: Enable hw support for vq descriptor mapping

[Dragos Tatulea via Virtualization]

On Thu, 2023-10-05 at 11:42 +0200, Eugenio Perez Martin wrote:
> On Thu, Sep 28, 2023 at 6:50 PM Dragos Tatulea  wrote:
> > 
> > Vq descriptor mappings are supported in hardware by filling in an
> > additional mkey which contains the descriptor mappings to the hw vq.
> > 
> > A previous patch in this series added support for hw mkey (mr) creation
> > for ASID 1.
> > 
> > This patch fills in both the vq data and vq descriptor mkeys based on
> > group ASID mapping.
> > 
> > The feature is signaled to the vdpa core through the presence of the
> > .get_vq_desc_group op.
> > 
> > Signed-off-by: Dragos Tatulea 
> > ---
> >  drivers/vdpa/mlx5/net/mlx5_vnet.c  | 26 --
> >  include/linux/mlx5/mlx5_ifc_vdpa.h |  7 ++-
> >  2 files changed, 30 insertions(+), 3 deletions(-)
> > 
> > diff --git a/drivers/vdpa/mlx5/net/mlx5_vnet.c
> > b/drivers/vdpa/mlx5/net/mlx5_vnet.c
> > index 25bd2c324f5b..46441e41892c 100644
> > --- a/drivers/vdpa/mlx5/net/mlx5_vnet.c
> > +++ b/drivers/vdpa/mlx5/net/mlx5_vnet.c
> > @@ -823,6 +823,7 @@ static int create_virtqueue(struct mlx5_vdpa_net *ndev,
> > struct mlx5_vdpa_virtque
> >     u32 out[MLX5_ST_SZ_DW(create_virtio_net_q_out)] = {};
> >     struct mlx5_vdpa_dev *mvdev = >mvdev;
> >     struct mlx5_vdpa_mr *vq_mr;
> > +   struct mlx5_vdpa_mr *vq_desc_mr;
> >     void *obj_context;
> >     u16 mlx_features;
> >     void *cmd_hdr;
> > @@ -878,6 +879,11 @@ static int create_virtqueue(struct mlx5_vdpa_net *ndev,
> > struct mlx5_vdpa_virtque
> >     vq_mr = mvdev->mr[mvdev->group2asid[MLX5_VDPA_DATAVQ_GROUP]];
> >     if (vq_mr)
> >     MLX5_SET(virtio_q, vq_ctx, virtio_q_mkey, vq_mr->mkey);
> > +
> > +   vq_desc_mr = mvdev->mr[mvdev-
> > >group2asid[MLX5_VDPA_DATAVQ_DESC_GROUP]];
> > +   if (vq_desc_mr)
> > +   MLX5_SET(virtio_q, vq_ctx, desc_group_mkey, vq_desc_mr-
> > >mkey);
> > +
> >     MLX5_SET(virtio_q, vq_ctx, umem_1_id, mvq->umem1.id);
> >     MLX5_SET(virtio_q, vq_ctx, umem_1_size, mvq->umem1.size);
> >     MLX5_SET(virtio_q, vq_ctx, umem_2_id, mvq->umem2.id);
> > @@ -2265,6 +2271,16 @@ static u32 mlx5_vdpa_get_vq_group(struct vdpa_device
> > *vdev, u16 idx)
> >     return MLX5_VDPA_DATAVQ_GROUP;
> >  }
> > 
> > +static u32 mlx5_vdpa_get_vq_desc_group(struct vdpa_device *vdev, u16 idx)
> > +{
> > +   struct mlx5_vdpa_dev *mvdev = to_mvdev(vdev);
> > +
> > +   if (is_ctrl_vq_idx(mvdev, idx))
> > +   return MLX5_VDPA_CVQ_GROUP;
> > +
> > +   return MLX5_VDPA_DATAVQ_DESC_GROUP;
> > +}
> > +
> >  static u64 mlx_to_vritio_features(u16 dev_features)
> >  {
> >     u64 result = 0;
> > @@ -3139,7 +3155,7 @@ static int mlx5_set_group_asid(struct vdpa_device
> > *vdev, u32 group,
> >  {
> >     struct mlx5_vdpa_dev *mvdev = to_mvdev(vdev);
> > 
> > -   if (group >= MLX5_VDPA_NUMVQ_GROUPS)
> > +   if (group >= MLX5_VDPA_NUMVQ_GROUPS || asid >= MLX5_VDPA_NUM_AS)
> 
> Nit: the check for asid >= MLX5_VDPA_NUM_AS is redundant, as it will
> be already checked by VHOST_VDPA_SET_GROUP_ASID handler in
> drivers/vhost/vdpa.c:vhost_vdpa_vring_ioctl. Not a big deal.
Ack.

> 
> >     return -EINVAL;
> > 
> >     mvdev->group2asid[group] = asid;
> > @@ -3160,6 +3176,7 @@ static const struct vdpa_config_ops mlx5_vdpa_ops = {
> >     .get_vq_irq = mlx5_get_vq_irq,
> >     .get_vq_align = mlx5_vdpa_get_vq_align,
> >     .get_vq_group = mlx5_vdpa_get_vq_group,
> > +   .get_vq_desc_group = mlx5_vdpa_get_vq_desc_group, /* Op disabled if
> > not supported. */
> >     .get_device_features = mlx5_vdpa_get_device_features,
> >     .set_driver_features = mlx5_vdpa_set_driver_features,
> >     .get_driver_features = mlx5_vdpa_get_driver_features,
> > @@ -3258,6 +3275,7 @@ struct mlx5_vdpa_mgmtdev {
> >     struct vdpa_mgmt_dev mgtdev;
> >     struct mlx5_adev *madev;
> >     struct mlx5_vdpa_net *ndev;
> > +   struct vdpa_config_ops vdpa_ops;
> >  };
> > 
> >  static int config_func_mtu(struct mlx5_core_dev *mdev, u16 mtu)
> > @@ -3371,7 +3389,7 @@ static int mlx5_vdpa_dev_add(struct vdpa_mgmt_dev
> > *v_mdev, const char *name,
> >     max_vqs = 2;
> >     }
> > 
> > -   ndev = vdpa_alloc_device(struct mlx5_vdpa_net, mvdev.vdev, mdev-
> > >device, _vdpa_ops,
> > +   ndev = vdpa_alloc_device(struct mlx5_vdpa_net, mvdev.vdev, mdev-
> > >device, >vdpa_ops,
> >  MLX5_VDPA_NUMVQ_GROUPS, MLX5_VDPA_NUM_AS,
> > name, false);
> >     if (IS_ERR(ndev))
> >     return PTR_ERR(ndev);
> > @@ -3546,6 +3564,10 @@ static int mlx5v_probe(struct auxiliary_device *adev,
> >     MLX5_CAP_DEV_VDPA_EMULATION(mdev, max_num_virtio_queues) +
> > 1;
> >     mgtdev->mgtdev.supported_features = get_supported_features(mdev);
> >     mgtdev->madev = madev;
> > +   mgtdev->vdpa_ops = mlx5_vdpa_ops;
> > +
> > +   if 

Re: [PATCH vhost 13/16] vdpa/mlx5: Introduce mr for vq descriptor

[Dragos Tatulea via Virtualization]

On Wed, 2023-10-04 at 20:53 +0200, Eugenio Perez Martin wrote:
> On Thu, Sep 28, 2023 at 6:50 PM Dragos Tatulea  wrote:
> > 
> > Introduce the vq descriptor group and ASID 1. Until now .set_map on ASID
> 
> s/ASID/vq group/?
> 
Oh, indeed.

> > 1 was only updating the cvq iotlb. From now on it also creates a mkey
> > for it. The current patch doesn't use it but follow-up patches will
> > add hardware support for mapping the vq descriptors.
> > 
> > Signed-off-by: Dragos Tatulea 
> > ---
> >  drivers/vdpa/mlx5/core/mlx5_vdpa.h |  5 +++--
> >  drivers/vdpa/mlx5/core/mr.c    | 14 +-
> >  drivers/vdpa/mlx5/net/mlx5_vnet.c  | 20 +---
> >  3 files changed, 25 insertions(+), 14 deletions(-)
> > 
> > diff --git a/drivers/vdpa/mlx5/core/mlx5_vdpa.h
> > b/drivers/vdpa/mlx5/core/mlx5_vdpa.h
> > index bbe4335106bd..ae09296f4270 100644
> > --- a/drivers/vdpa/mlx5/core/mlx5_vdpa.h
> > +++ b/drivers/vdpa/mlx5/core/mlx5_vdpa.h
> > @@ -70,11 +70,12 @@ struct mlx5_vdpa_wq_ent {
> >  enum {
> >     MLX5_VDPA_DATAVQ_GROUP,
> >     MLX5_VDPA_CVQ_GROUP,
> > +   MLX5_VDPA_DATAVQ_DESC_GROUP,
> >     MLX5_VDPA_NUMVQ_GROUPS
> >  };
> > 
> >  enum {
> > -   MLX5_VDPA_NUM_AS = MLX5_VDPA_NUMVQ_GROUPS
> > +   MLX5_VDPA_NUM_AS = 2
> >  };
> > 
> >  struct mlx5_vdpa_dev {
> > @@ -89,7 +90,7 @@ struct mlx5_vdpa_dev {
> >     u16 max_idx;
> >     u32 generation;
> > 
> > -   struct mlx5_vdpa_mr *mr;
> > +   struct mlx5_vdpa_mr *mr[MLX5_VDPA_NUM_AS];
> 
> I'm wondering if it makes sense to squash all of this patch with the
> previous one, as I think *mr[MLX5_VDPA_NUM_AS] makes way more sense
> than just *mr.
> 
I've been on the fence about this one. It seemed cleaner to have two patches.

> Whatever you choose, for both patches:
> 
> Acked-by: Eugenio Pérez 
> 
> >     /* serialize mr access */
> >     struct mutex mr_mtx;
> >     struct mlx5_control_vq cvq;
> > diff --git a/drivers/vdpa/mlx5/core/mr.c b/drivers/vdpa/mlx5/core/mr.c
> > index 00eff5a07152..3dee6d9bed6b 100644
> > --- a/drivers/vdpa/mlx5/core/mr.c
> > +++ b/drivers/vdpa/mlx5/core/mr.c
> > @@ -511,8 +511,10 @@ void mlx5_vdpa_destroy_mr(struct mlx5_vdpa_dev *mvdev,
> > 
> >     _mlx5_vdpa_destroy_mr(mvdev, mr);
> > 
> > -   if (mvdev->mr == mr)
> > -   mvdev->mr = NULL;
> > +   for (int i = 0; i < MLX5_VDPA_NUM_AS; i++) {
> > +   if (mvdev->mr[i] == mr)
> > +   mvdev->mr[i] = NULL;
> > +   }
> > 
> >     mutex_unlock(>mr_mtx);
> > 
> > @@ -523,11 +525,11 @@ void mlx5_vdpa_update_mr(struct mlx5_vdpa_dev *mvdev,
> >  struct mlx5_vdpa_mr *new_mr,
> >  unsigned int asid)
> >  {
> > -   struct mlx5_vdpa_mr *old_mr = mvdev->mr;
> > +   struct mlx5_vdpa_mr *old_mr = mvdev->mr[asid];
> > 
> >     mutex_lock(>mr_mtx);
> > 
> > -   mvdev->mr = new_mr;
> > +   mvdev->mr[asid] = new_mr;
> >     if (old_mr) {
> >     _mlx5_vdpa_destroy_mr(mvdev, old_mr);
> >     kfree(old_mr);
> > @@ -539,7 +541,9 @@ void mlx5_vdpa_update_mr(struct mlx5_vdpa_dev *mvdev,
> > 
> >  void mlx5_vdpa_destroy_mr_resources(struct mlx5_vdpa_dev *mvdev)
> >  {
> > -   mlx5_vdpa_destroy_mr(mvdev, mvdev->mr);
> > +   for (int i = 0; i < MLX5_VDPA_NUM_AS; i++)
> > +   mlx5_vdpa_destroy_mr(mvdev, mvdev->mr[i]);
> > +
> >     prune_iotlb(mvdev);
> >  }
> > 
> > diff --git a/drivers/vdpa/mlx5/net/mlx5_vnet.c
> > b/drivers/vdpa/mlx5/net/mlx5_vnet.c
> > index 4a87f9119fca..25bd2c324f5b 100644
> > --- a/drivers/vdpa/mlx5/net/mlx5_vnet.c
> > +++ b/drivers/vdpa/mlx5/net/mlx5_vnet.c
> > @@ -821,6 +821,8 @@ static int create_virtqueue(struct mlx5_vdpa_net *ndev,
> > struct mlx5_vdpa_virtque
> >  {
> >     int inlen = MLX5_ST_SZ_BYTES(create_virtio_net_q_in);
> >     u32 out[MLX5_ST_SZ_DW(create_virtio_net_q_out)] = {};
> > +   struct mlx5_vdpa_dev *mvdev = >mvdev;
> > +   struct mlx5_vdpa_mr *vq_mr;
> >     void *obj_context;
> >     u16 mlx_features;
> >     void *cmd_hdr;
> > @@ -873,7 +875,9 @@ static int create_virtqueue(struct mlx5_vdpa_net *ndev,
> > struct mlx5_vdpa_virtque
> >     MLX5_SET64(virtio_q, vq_ctx, desc_addr, mvq->desc_addr);
> >     MLX5_SET64(virtio_q, vq_ctx, used_addr, mvq->device_addr);
> >     MLX5_SET64(virtio_q, vq_ctx, available_addr, mvq->driver_addr);
> > -   MLX5_SET(virtio_q, vq_ctx, virtio_q_mkey, ndev->mvdev.mr->mkey);
> > +   vq_mr = mvdev->mr[mvdev->group2asid[MLX5_VDPA_DATAVQ_GROUP]];
> > +   if (vq_mr)
> > +   MLX5_SET(virtio_q, vq_ctx, virtio_q_mkey, vq_mr->mkey);
> >     MLX5_SET(virtio_q, vq_ctx, umem_1_id, mvq->umem1.id);
> >     MLX5_SET(virtio_q, vq_ctx, umem_1_size, mvq->umem1.size);
> >     MLX5_SET(virtio_q, vq_ctx, umem_2_id, mvq->umem2.id);
> > @@ -2633,7 +2637,8 @@ static void restore_channels_info(struct mlx5_vdpa_net
> > *ndev)
> >  }
> > 

Re: [PATCH 0/9] drm: Annotate structs with __counted_by

[Christian König]

Am 02.10.23 um 20:22 schrieb Kees Cook:

On Mon, Oct 02, 2023 at 08:11:41PM +0200, Christian König wrote:

Am 02.10.23 um 20:08 schrieb Kees Cook:

On Mon, Oct 02, 2023 at 08:01:57PM +0200, Christian König wrote:

Am 02.10.23 um 18:53 schrieb Kees Cook:

On Mon, Oct 02, 2023 at 11:06:19AM -0400, Alex Deucher wrote:

On Mon, Oct 2, 2023 at 5:20 AM Christian König
 wrote:

Am 29.09.23 um 21:33 schrieb Kees Cook:

On Fri, 22 Sep 2023 10:32:05 -0700, Kees Cook wrote:

This is a batch of patches touching drm for preparing for the coming
implementation by GCC and Clang of the __counted_by attribute. Flexible
array members annotated with __counted_by can have their accesses
bounds-checked at run-time checking via CONFIG_UBSAN_BOUNDS (for array
indexing) and CONFIG_FORTIFY_SOURCE (for strcpy/memcpy-family functions).

As found with Coccinelle[1], add __counted_by to structs that would
benefit from the annotation.

[...]

Since this got Acks, I figure I should carry it in my tree. Let me know
if this should go via drm instead.

Applied to for-next/hardening, thanks!

[1/9] drm/amd/pm: Annotate struct smu10_voltage_dependency_table with 
__counted_by
  https://git.kernel.org/kees/c/a6046ac659d6

STOP! In a follow up discussion Alex and I figured out that this won't work.

I'm so confused; from the discussion I saw that Alex said both instances
were false positives?


The value in the structure is byte swapped based on some firmware
endianness which not necessary matches the CPU endianness.

SMU10 is APU only so the endianess of the SMU firmware and the CPU
will always match.

Which I think is what is being said here?


Please revert that one from going upstream if it's already on it's way.

And because of those reasons I strongly think that patches like this
should go through the DRM tree :)

Sure, that's fine -- please let me know. It was others Acked/etc. Who
should carry these patches?

Probably best if the relevant maintainer pick them up individually.

Some of those structures are filled in by firmware/hardware and only the
maintainers can judge if that value actually matches what the compiler
needs.

We have cases where individual bits are used as flags or when the size is
byte swapped etc...

Even Alex and I didn't immediately say how and where that field is actually
used and had to dig that up. That's where the confusion came from.

Okay, I've dropped them all from my tree. Several had Acks/Reviews, so
hopefully those can get picked up for the DRM tree?

I will pick those up to go through drm-misc-next.

Going to ping maintainers once more when I'm not sure if stuff is correct or
not.

Sounds great; thanks!


I wasn't 100% sure for the VC4 patch, but pushed the whole set to 
drm-misc-next anyway.


This also means that the patches are now auto merged into the drm-tip 
integration branch and should any build or unit test go boom we should 
notice immediately and can revert it pretty easily.


Thanks,
Christian.



-Kees



___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH vfio 10/11] vfio/virtio: Expose admin commands over virtio device

[Christoph Hellwig]

On Mon, Oct 02, 2023 at 12:13:20PM -0300, Jason Gunthorpe wrote:
> ??? This patch series is an implementation of changes that OASIS
> approved.

I think you are fundamentally missing my point.  This is not about
who publish a spec, but how we struture Linux code.

And the problem is that we trea vfio as a separate thing, and not an
integral part of the driver.  vfio being separate totally makes sense
for the original purpose of vfio, that is a a no-op passthrough of
a device to userspace.

But for all the augmented vfio use cases it doesn't, for them the
augmented vfio functionality is an integral part of the core driver.
That is true for nvme, virtio and I'd argue mlx5 as well.

So we need to stop registering separate pci_drivers for this kind
of functionality, and instead have an interface to the driver to
switch to certain functionalities.

E.g. for this case there should be no new vfio-virtio device, but
instead you should be able to switch the virtio device to an
fake-legacy vfio mode.

Assuming the whole thing actually makes sense, as the use case seems
a bit fishy to start with, but I'll leave that argument to the virtio
maintainers.

Similarly for nvme.  We'll never accept a separate nvme-live migration
vfio driver.  This functionality needs to be part of the nvme driver,
probed there and fully controlled there.
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization