linux-kernel - RE: [PATCH v2 1/5] hisi_acc_vfio

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <8225389dd537497c9753cf0a321964e4@huawei.com>
Date: Tue, 14 Jan 2025 08:07:43 +0000
From: Shameerali Kolothum Thodi <shameerali.kolothum.thodi@...wei.com>
To: liulongfang <liulongfang@...wei.com>, Alex Williamson
	<alex.williamson@...hat.com>
CC: "jgg@...dia.com" <jgg@...dia.com>, Jonathan Cameron
	<jonathan.cameron@...wei.com>, "kvm@...r.kernel.org" <kvm@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linuxarm@...neuler.org" <linuxarm@...neuler.org>
Subject: RE: [PATCH v2 1/5] hisi_acc_vfio_pci: fix XQE dma address error



> -----Original Message-----
> From: liulongfang <liulongfang@...wei.com>
> Sent: Tuesday, January 14, 2025 3:18 AM
> To: Alex Williamson <alex.williamson@...hat.com>
> Cc: Shameerali Kolothum Thodi
> <shameerali.kolothum.thodi@...wei.com>; jgg@...dia.com; Jonathan
> Cameron <jonathan.cameron@...wei.com>; kvm@...r.kernel.org; linux-
> kernel@...r.kernel.org; linuxarm@...neuler.org
> Subject: Re: [PATCH v2 1/5] hisi_acc_vfio_pci: fix XQE dma address error
> 

[...]

> > @@ -418,7 +440,7 @@ static int vf_qm_get_match_data(struct
> hisi_acc_vf_core_device *hisi_acc_vdev,
> >  	int vf_id = hisi_acc_vdev->vf_id;
> >  	int ret;
> >
> > -	vf_data->acc_magic = ACC_DEV_MAGIC;
> > +	vf_data->acc_magic = ACC_DEV_MAGIC_V2;
> >  	/* Save device id */
> >  	vf_data->dev_id = hisi_acc_vdev->vf_dev->device;
> >
> > Thanks,
> > Alex
> >
> >>>
> >>> As for the compatibility issues between old and new versions in the
> >>> future, we do not need to reserve version numbers to deal with them
> >>> now. Because before encountering specific problems, our design may
> be redundant.
> >>
> >> A magic value + version number would prevent the need to replace the
> >> magic value every time an issue is encountered, which I think was
> >> also Shameer's commit, which is not addressed by forcing the
> >> formatting of a portion of the magic value.  None of what you're
> >> trying to do here precludes a new data structure for the new magic
> >> value or defining the padding fields for different use cases.
> >> Thanks,
> >>
> >> Alex
> >
> 
> If we want to use the original magic number, we also need to add the major
> and minor version numbers. It does not cause compatibility issues and can
> only reuse the original u64 memory space.
> 
> This is also Shameerali's previous plan. Do you accept this plan?

The suggestion here is to improve my previous plan.. ie, instead of overloading
the V2 MAGIC with version info, introduce version(major:minor) separately.

Something like,

Rename old MAGIC as MAGIC_V1

Introduce new MAGIC as MAGIC_V2

Repurpose any padding or reserved fields in struct vf_data for major:minor
version  fields. The idea of introducing these major:minor is for future use
where instead of coming up with a  new MAGIC data every time we can
increment the version for bug fixes and features if required. 

Hope this is clear now.

Thanks,
Shameer