-------- Forwarded Message --------
Subject: S390 testing for IOMMUFD
Date: Mon, 7 Nov 2022 21:09:02 -0400
From: Jason Gunthorpe <jgg(a)nvidia.com>
To: Cornelia Huck <cohuck(a)redhat.com>, Eric Farman
<farman(a)linux.ibm.com>, Matthew Rosato <mjrosato(a)linux.ibm.com>, Niklas
Schnelle <schnelle(a)linux.ibm.com>, Tony Krowiak
<akrowiak(a)linux.ibm.com>, Halil Pasic <pasic(a)linux.ibm.com>, Jason Herne
<jjherne(a)linux.ibm.com>, linux-s390(a)vger.kernel.org
CC: iommu(a)lists.linux.dev, Kevin Tian <kevin.tian(a)intel.com>, Alex
Williamson <alex.williamson(a)redhat.com>, kvm(a)vger.kernel.org, Lu Baolu
<baolu.lu(a)linux.intel.com>, Nicolin Chen <nicolinc(a)nvidia.com>
On Mon, Nov 07, 2022 at 08:48:53PM -0400, Jason Gunthorpe wrote:
> [
> This has been in linux-next for a little while now, and we've completed
> the syzkaller run. 1300 hours of CPU time have been invested since the
> last report with no improvement in coverage or new detections. syzkaller
> coverage reached 69%(75%), and review of the misses show substantial
> amounts are WARN_ON's and other debugging which are not expected to be
> covered.
> ]
>
> iommufd is the user API to control the IOMMU subsystem as it relates to
> managing IO page tables that point at user space memory.
[chop cc list]
s390 mdev maintainers,
Can I ask your help to test this with the two S390 mdev drivers? Now
that gvt is passing and we've covered alot of the QA ground it is a
good time to run it.
Take the branch from here:
https://git.kernel.org/pub/scm/linux/kernel/git/jgg/iommufd.git/log/?h=for-…
And build the kernel with
CONFIG_VFIO_CONTAINER=n
CONFIG_IOMMUFD=y
CONFIG_IOMMUFD_VFIO_CONTAINER=y
And your existing stuff should work with iommufd providing the iommu
support to vfio. There will be a dmesg confirming this.
Let me know if there are any problems!
If I recall there was some desire from the S390 platform team to start
building on iommufd to create some vIOMMU acceleration for S390
guests, this is a necessary first step.
Thanks,
Jason
Update the current driver adaptation and usage method, from fixed
use of Hisilicon device driver to automatic registration of the
driver according to the algorithm.
When the algorithm API layer uses the driver, it is no longer
bound to the fixed device driver, but dynamically obtained
and stored according to the algorithm query to use.
Update the driver and API layer of the zip module, keep the
function of the init interface unchanged, update the implementation
of the init2 interface and match the dynamic loading function.
liulongfang (4):
uadk: Add driver dynamic loading function
uadk: added ability to query supported algorithms
uadk: improve the dynamic loading public framework
uadk/zip: Adapt the zip module to the dynamic loading framework
Makefile.am | 4 +-
drv/hisi_comp.c | 101 ++++++++-
include/drv/wd_comp_drv.h | 27 ---
include/wd.h | 12 +
include/wd_alg.h | 85 ++++++++
include/wd_alg_common.h | 10 +
include/wd_sched.h | 6 +-
include/wd_util.h | 18 +-
libwd.map | 8 +
wd.c | 56 ++++-
wd_alg.c | 265 ++++++++++++++++++++++
wd_comp.c | 160 +++++++-------
wd_util.c | 447 +++++++++++++++++++++++++++++++++++++-
13 files changed, 1068 insertions(+), 131 deletions(-)
create mode 100644 include/wd_alg.h
create mode 100644 wd_alg.c
--
2.33.0
On 2022/11/10 下午4:15, fanghao (A) wrote:
>
>
> 在 2022/11/10 10:54, Zhangfei Gao 写道:
>> Here is discussion about uadk branch & tag policy
>>
>> By now, I saw the best example
>> https://github.com/intel/intel-ipsec-mb
>>
>> 1. no lts branch, only use tag + ReleaseNotes.txt
>>
>> Lts branch will cost too much resources, it is hard for a small team
>> like us.
>> For example it is difficult to git am current patch to any tag half
>> year ago.
>>
>> Unlike OS, it is little meaning for UADK to keep a stable version.
>> We can not attract customer only by maintaining a stable version,
> mainly for LTS OS easy to catch the bugfix update for which version
> that have been intergrated.
Yes,
but it maybe another story if we promise like two years' maintain.
>
>> but only the performance and new feautre, like support both
>> accelerators and cpu instructions.
>>
>>
>> 2. Tag policy
>>
>> Refer
>> https://github.com/intel/intel-ipsec-mb/blob/main/ReleaseNotes.txt
>>
>> Basically two releases each year,
> looks good to me.
>
>>
>> v1.3 September 2022
>> v1.2 February 2022
>> v1.1 October 2021
>> v1.0 April 2021
>>
> The time node is not fixed. Do we need fixed time?
Sure,
How about one month before Euler release?
>
>> No small tag, since uadk is stable enough. is it too simple, suitable?
>> What's the minor tag used for?
>> Other component (openssl-uadk) need refer these tag accordingly.
>>
>> We may consider minor tag for bug fix? like 1.3.1 for a big bug fix?
> looks good to me.
>
>> intel-ipsec-mb$
>> $ git tag
>> v1.0
>> v1.1
>> v1.2
>> v1.3
>>
>> 3. ReleaseNotes Contents:
>>
>> General:
>> Working combination, uadk xxx & openssl-uadk xxx & dpdk xxx
>>
>> Main change:
>> Like support cpu instructions
>> api change?
>>
>> Library
>> New algoirthm:
>>
>> Test Applications:
>>
>> Fixes:
>>
> Can be simplified like this?
>
> Features：
> ...
>
> Fixes:
> ...
We can use this for UADK.
For openssl-uadk, the testing combination maybe required.
I am not sure whether openssl-uadk can work with any version of UADK
from now on.
ie. the UADK interface keeps stable.
We found openssl-uadk can not work with some old version UADK before.
openssl-uadk depend on UADK, we can add testing combination in
openssl-uadk ReleaseNotes.
UADK releasenotes may have no such issue.
>
>
> But how to kown the bugfix for which tag?
> For example: new tag 2.3.1 for bugfix,how to kown this fix for which
> version.maybe fix
> for 2.1 just not for 2.3.
Since no lts branch, only description in ReleaseNotes can be check.
Since one release half year, suppose there is no such issue, like a bug
fix happens half year later.
Thanks
>
>> Release status: Unreleased & tag (like v1.3 September 2022)
>> -Unreleased
>> +v1.3 September 2022
>>
>> _______________________________________________
>> Acc mailing list -- acc(a)openeuler.org
>> To unsubscribe send an email to acc-leave(a)openeuler.org
> _______________________________________________
> Acc mailing list -- acc(a)openeuler.org
> To unsubscribe send an email to acc-leave(a)openeuler.org
-------- Forwarded Message --------
Subject: DPDK 22.11 released
Date: Sun, 27 Nov 2022 23:22:17 +0100
From: Thomas Monjalon <thomas(a)monjalon.net>
To: announce(a)dpdk.org
A new major release is available:
https://fast.dpdk.org/rel/dpdk-22.11.tar.xz
It was a comfortable release cycle:
1387 commits from 193 authors
1902 files changed, 137224 insertions(+), 61256 deletions(-)
The branch 22.11 should be supported for at least two years, maybe more,
making it recommended for system integration and deployment.
The new major ABI version is 23.
The next releases 23.03 and 23.07 will be ABI-compatible with 22.11.
Below are some new features:
- LoongArch build
- Intel uncore frequency control
- mempool optimizations
- new mbuf layout for IOVA-as-VA build
- multiple mbuf pools per Rx queue
- Rx buffer split based on protocol
- hardware congestion management
- hairpin memory configuration
- proactive NIC error handling
- Rx/Tx descriptor dump
- flow API extensions
- GVE (Google Virtual Ethernet)
- IDPF (Intel Infrastructure DataPath Function)
- UADK supporting HiSilicon crypto
- MACsec processing offload
- ShangMi crypto algorithms
- baseband FFT operations
- eventdev Tx queue start/stop
- eventdev crypto vectorization
- NitroSketch membership
- DTS introduction in DPDK repository
More details in the release notes:
https://doc.dpdk.org/guides/rel_notes/release_22_11.html
There are 74 new contributors (including authors, reviewers and testers).
Welcome to Abdullah Sevincer, Abhishek Maheshwari, Alan Liu,
Aleksandr Miloshenko, Alex Vesker, Alexander Chernavin, Allen Hubbe,
Amit Prakash Shukla, Anatolii Gerasymenko, Arkadiusz Kubalewski,
Arshdeep Kaur, Benjamin Le Berre, Bhagyada Modali, David MacDougal,
Dawid Zielinski, Dexia Li, Dukai Yuan, Erez Shitrit, Fei Qin, Frank Du,
Gal Shalom, Grzegorz Siwik, Hamdan Igbaria, Hamza Khan, Henning Schild,
Huang Wei, Huzaifa Rahman, James Hershaw, Jeremy Spewock, Jin Ling,
Joey Xing, Jun Qiu, Kaiwen Deng, Karen Sornek, Ke Xu, Kevin O'Sullivan,
Lei Cai, Lei Ji, Leszek Zygo, Long Wu, Lukasz Czapnik, Lukasz Kupczak,
Mah Yock Gen, Mandal Purna Chandra, Mao YingMing, Marcin Szycik,
Michael Savisko, Min Zhou, Mingjin Ye, Mingshan Zhang, Mário Kuka,
Piotr Gardocki, Qingmin Liu, R Mohamed Shah, Roman Storozhenko,
Sathesh Edara, Sergey Temerkhanov, Shiqi Liu, Stephen Coleman,
Steven Zou, Sunil Uttarwar, Sunyang Wu, Sylvia Grundwürmer,
Tadhg Kearney, Taekyung Kim, Taripin Samuel, Tomasz Jonak,
Tomasz Zawadzki, Tsotne Chakhvadze, Usman Tanveer, Wiktor Pilarczyk,
Yaqi Tang, Yi Li and Zhangfei Gao.
Below is the number of commits per employer (with authors count):
456 Intel (65)
227 Marvell (29)
179 NVIDIA (28)
83 Corigine (6)
81 Red Hat (5)
60 Huawei (6)
58 AMD (5)
55 Microsoft (4)
53 OKTET Labs (2)
19 NXP (5)
14 Ericsson (1)
13 6WIND (2)
...
A big thank to all courageous people who took on the non rewarding task
of reviewing other's job.
Based on Reviewed-by and Acked-by tags, the top non-PMD reviewers are:
53 Akhil Goyal <gakhil(a)marvell.com>
45 Andrew Rybchenko <andrew.rybchenko(a)oktetlabs.ru>
36 Morten Brørup <mb(a)smartsharesystems.com>
34 Niklas Söderlund <niklas.soderlund(a)corigine.com>
34 Bruce Richardson <bruce.richardson(a)intel.com>
33 David Marchand <david.marchand(a)redhat.com>
31 Ori Kam <orika(a)nvidia.com>
25 Maxime Coquelin <maxime.coquelin(a)redhat.com>
21 Jerin Jacob <jerinj(a)marvell.com>
20 Chengwen Feng <fengchengwen(a)huawei.com>
The next version will be 23.03 in March.
The new features for 23.03 can be submitted during the next 4 weeks:
http://core.dpdk.org/roadmap#dates
Please share your roadmap.
Thanks everyone
Good day,
Did you get my last email? I have sent email 3 times and no reply
from you.
Hope this email acc(a)lists.linaro.org is correct
I await your prompt response.
Yours sincerely,
Best regards,
