RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 2143160 - nodedev-create fails to set mdev attributes
Summary: nodedev-create fails to set mdev attributes
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: libvirt
Version: 8.8
Hardware: s390x
OS: Unspecified
medium
medium
Target Milestone: rc
: ---
Assignee: Jonathon Jongsma
QA Contact: smitterl
Jiri Herrmann
URL:
Whiteboard:
Depends On: 2143158
Blocks:
TreeView+ depends on / blocked
 
Reported: 2022-11-16 08:46 UTC by smitterl
Modified: 2024-01-25 04:25 UTC (History)
9 users (show)

Fixed In Version: libvirt-8.0.0-21.el8
Doc Type: Known Issue
Doc Text:
.`nodedev-dumpxml` does not list attributes correctly for certain mediated devices Currently, the `nodedev-dumpxml` does not list attributes correctly for mediated devices that were created using the `nodedev-create` command. To work around this problem, use the `nodedev-define` and `nodedev-start` commands instead.
Clone Of: 2143158
Environment:
Last Closed: 2023-07-12 10:17:03 UTC
Type: Bug
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker RHELPLAN-139538 0 None None None 2022-11-16 08:50:02 UTC

Description smitterl 2022-11-16 08:46:10 UTC 
+++ This bug was initially created as a clone of Bug #2143158 +++

Description of problem:
We can't use mediated device for crypto domains when they are created with the `nodedev-create` command. It would not set the necessary device attributes. The workaround currently would be to first `nodedev-define` and then `nodedev-start` the device.


Version-Release number of selected component (if applicable):
libvirt-8.9.0-2.el9.s390x

How reproducible:
100%

Steps to Reproduce:

With attached vfio_ap_nodedev.xml on appropriate host

1. virsh nodedev-create vfio_ap_nodedev.xml
==> returns name of the mediated device, let it be mdev_XXX
2. virsh nodedev-dumpxml mdev_XXX

Actual results:

<device>
  <name>mdev_d36d7d0f_cf3d_4fef_bb9c_ed393954996b_matrix</name>
  <path>/sys/devices/vfio_ap/matrix/d36d7d0f-cf3d-4fef-bb9c-ed393954996b</path>
  <parent>ap_matrix</parent>
  <driver>
    <name>vfio_ap_mdev</name>
  </driver>
  <capability type='mdev'>
    <type id='vfio_ap-passthrough'/>
    <uuid>d36d7d0f-cf3d-4fef-bb9c-ed393954996b</uuid>
    <parent_addr>matrix</parent_addr>
    <iommuGroup number='1'/>
  </capability>
</device>


Expected results:

<device>
  <name>mdev_d36d7d0f_cf3d_4fef_bb9c_ed393954996b_matrix</name>
  <path>/sys/devices/vfio_ap/matrix/d36d7d0f-cf3d-4fef-bb9c-ed393954996b</path>
  <parent>ap_matrix</parent>
  <driver>
    <name>vfio_ap_mdev</name>
  </driver>
  <capability type='mdev'>
    <type id='vfio_ap-passthrough'/>
    <uuid>d36d7d0f-cf3d-4fef-bb9c-ed393954996b</uuid>
    <parent_addr>matrix</parent_addr>
    <iommuGroup number='1'/>
    <attr name='assign_adapter' value='0x01'/>
    <attr name='assign_domain' value='0x002c'/>
  </capability>
</device>


Additional info:

A)
The expected result is obtained with steps

1. virsh nodedev-define vfio_ap_nodedev.xml
2. virsh nodedev-start mdev_XXX
3. virsh nodedev-dumpxml mdev_XXX

B)
I don't think this is a regression, but need to double check.

--- Additional comment from  on 2022-11-16 08:45:22 UTC ---

This can be reproduced with libvirt-8.0.0-10.module+el8.8.0+16781+9f4724c2.s390x
Comment 2 John Ferlan 2023-05-24 15:21:48 UTC 
Considering bug 2143158 was moved to POST for 9.3.0, can a backport be done here for 8.9.0?

Assigned to Jonathon directly since he noted the upstream commit in the cloned from bug.
Comment 8 liang cong 2023-06-27 07:20:30 UTC 
Tested with below steps:
1. make sure s390utils related packages, mdevctl and libvirt are installed:
# rpm -qa s390utils*
s390utils-cpuplugd-2.25.0-2.el8.s390x
s390utils-hmcdrvfs-2.25.0-2.el8.s390x
s390utils-2.25.0-2.el8.s390x
s390utils-chreipl-fcp-mpath-2.25.0-2.el8.s390x
s390utils-base-2.25.0-2.el8.s390x
s390utils-ziomon-2.25.0-2.el8.s390x
s390utils-iucvterm-2.25.0-2.el8.s390x
s390utils-cmsfs-2.25.0-2.el8.s390x
s390utils-osasnmpd-2.25.0-2.el8.s390x
s390utils-cmsfs-fuse-2.25.0-2.el8.s390x
s390utils-zdsfs-2.25.0-2.el8.s390x
s390utils-cpacfstatsd-2.25.0-2.el8.s390x
s390utils-core-2.25.0-2.el8.s390x
s390utils-mon_statd-2.25.0-2.el8.s390x
s390utils-devel-2.25.0-2.el8.s390x

# rpm -q mdevctl
mdevctl-1.1.0-2.el8.s390x


# rpm -q libvirt qemu-kvm
libvirt-8.0.0-21.module+el8.9.0+19166+e262ca96.s390x
qemu-kvm-6.2.0-35.module+el8.9.0+19166+e262ca96.s390x

2. Found mdevctl callout script at places:
# ls /etc/mdevctl.d/scripts.d/callouts/ap-check.sh
/etc/mdevctl.d/scripts.d/callouts/ap-check.sh

# cat /etc/mdevctl.d/scripts.d/callouts/ap-check.sh
[ -e /usr/lib/mdevctl/scripts.d/callouts/ap-check ] && /usr/lib/mdevctl/scripts.d/callouts/ap-check "$@"

# ls /usr/lib/mdevctl/scripts.d/callouts/ap-check
/usr/lib/mdevctl/scripts.d/callouts/ap-check

3. Restart virtnodedevd service
# systemctl restart virtnodedevd

4. virsh nodedev-create vfio_ap_nodedev.xml
# cat vfio_ap_nodedev.xml 
<device>
	<!-- same parent device for all -->
	<parent>ap_matrix</parent>
	<capability type="mdev">
		<type id="vfio_ap-passthrough"/>
		<uuid>d36d7d0f-cf3d-4fef-bb9c-ed393954996b</uuid>
		<attr name="assign_adapter" value="0x02"/>
		<attr name="assign_domain" value="0x002b"/>
	</capability>
</device>

# virsh nodedev-create vfio_ap_nodedev.xml
Node device mdev_d36d7d0f_cf3d_4fef_bb9c_ed393954996b_matrix created from vfio_ap_nodedev.xml

5. virsh nodedev-dumpxml mdev_d36d7d0f_cf3d_4fef_bb9c_ed393954996b_matrix, and could not see attribute "assign_adapter" and "assign_domain"
# virsh nodedev-dumpxml mdev_d36d7d0f_cf3d_4fef_bb9c_ed393954996b_matrix
<device>
  <name>mdev_d36d7d0f_cf3d_4fef_bb9c_ed393954996b_matrix</name>
  <path>/sys/devices/vfio_ap/matrix/d36d7d0f-cf3d-4fef-bb9c-ed393954996b</path>
  <parent>ap_matrix</parent>
  <driver>
    <name>vfio_mdev</name>
  </driver>
  <capability type='mdev'>
    <type id='vfio_ap-passthrough'/>
    <uuid>d36d7d0f-cf3d-4fef-bb9c-ed393954996b</uuid>
    <iommuGroup number='4'/>
  </capability>
</device>


6. Check the mdevctl output:
# mdevctl list -vu d36d7d0f-cf3d-4fef-bb9c-ed393954996b --dumpjson
{
  "mdev_type": "vfio_ap-passthrough",
  "start": "manual",
  "attrs": [
    {
      "assign_adapter": "2"
    },
    {
      "assign_domain": "43"
    }
  ]
}

# mdevctl list -vu d36d7d0f-cf3d-4fef-bb9c-ed393954996b
d36d7d0f-cf3d-4fef-bb9c-ed393954996b matrix vfio_ap-passthrough manual
  Attrs:
    @{0}: {"assign_adapter":"2"}
    @{1}: {"assign_domain":"43"}


7. virsh nodedev-dumpxml mdev_d36d7d0f_cf3d_4fef_bb9c_ed393954996b_matrix again. And still could not see attribute "assign_adapter" and "assign_domain"
# virsh nodedev-dumpxml mdev_d36d7d0f_cf3d_4fef_bb9c_ed393954996b_matrix
<device>
  <name>mdev_d36d7d0f_cf3d_4fef_bb9c_ed393954996b_matrix</name>
  <path>/sys/devices/vfio_ap/matrix/d36d7d0f-cf3d-4fef-bb9c-ed393954996b</path>
  <parent>ap_matrix</parent>
  <driver>
    <name>vfio_mdev</name>
  </driver>
  <capability type='mdev'>
    <type id='vfio_ap-passthrough'/>
    <uuid>d36d7d0f-cf3d-4fef-bb9c-ed393954996b</uuid>
    <iommuGroup number='4'/>
  </capability>
</device>


8. Then I restart virtnodedevd service again
# # systemctl restart virtnodedevd

9. Check virsh nodedev-dumpxml output, then found attribute "assign_adapter" and "assign_domain".
# virsh nodedev-dumpxml mdev_d36d7d0f_cf3d_4fef_bb9c_ed393954996b_matrix
<device>
  <name>mdev_d36d7d0f_cf3d_4fef_bb9c_ed393954996b_matrix</name>
  <path>/sys/devices/vfio_ap/matrix/d36d7d0f-cf3d-4fef-bb9c-ed393954996b</path>
  <parent>ap_matrix</parent>
  <driver>
    <name>vfio_mdev</name>
  </driver>
  <capability type='mdev'>
    <type id='vfio_ap-passthrough'/>
    <uuid>d36d7d0f-cf3d-4fef-bb9c-ed393954996b</uuid>
    <iommuGroup number='4'/>
    <attr name='assign_adapter' value='2'/>
    <attr name='assign_domain' value='43'/>
  </capability>
</device>

Hi Jonathon, I think this issue is same with https://bugzilla.redhat.com/show_bug.cgi?id=2143158#c19, and the fix is posted as comments https://bugzilla.redhat.com/show_bug.cgi?id=2143158#c22, so I think the new fix code also need to be a part of the backport.
Comment 9 Jonathon Jongsma 2023-06-27 13:44:48 UTC 
Aha, it seems that somehow I had missed that patch. Let me look into it.
Comment 10 John Ferlan 2023-07-05 15:23:22 UTC 
It would seem to me that we should use the FailedQA process in order to move this bug back to assigned, allow Jonathon to apply the updated change downstream, and then go through the re-verification.  Leaving a needinfo on qa for that decision...

NB: FailedQA always fails to "reset" the DTM/ITM and invariably that leads to missed deadline bot messaging. So we should update the values as we update this bug...
Comment 15 Red Hat Bugzilla 2024-01-25 04:25:37 UTC 
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 120 days
Note You need to log in before you can comment on or make changes to this bug.