Description of problem:
Failed to start second guest which use a shared nvdimm device

Version-Release number of selected component (if applicable):
libvirt-5.6.0-4.module+el8.1.0+4160+b50057dc.x86_64

How reproducible:
100%

Steps to Reproduce:
1. prepare 2 guest with 1 shared nvdimm device:

1. virsh dumpxml vm1

<memory model='nvdimm' access='shared'>
<source>
<path>/tmp/nvdimm</path>
<alignsize unit='KiB'>2048</alignsize>
</source>
<target>
<size unit='KiB'>524288</size>
<node>1</node>
<label>
<size unit='KiB'>128</size>
</label>
</target>
<alias name='nvdimm0'/>
<address type='dimm' slot='0'/>
</memory>

1. virsh dumpxml vm2

<memory model='nvdimm' access='shared'>
<source>
<path>/tmp/nvdimm</path>
<alignsize unit='KiB'>2048</alignsize>
</source>
<target>
<size unit='KiB'>524288</size>
<node>1</node>
<label>
<size unit='KiB'>128</size>
</label>
<readonly/>
</target>
<address type='dimm' slot='0'/>
</memory>

2. start 2 guest

1. virsh start vm1
   Domain vm1 started

1. virsh start vm2
   error: Failed to start domain vm2
   error: internal error: child reported (status=125): Requested operation is not valid: Setting different SELinux label on /tmp/nvdimm which is already in use

3. check nvdimm label:

1. ll -Z /tmp/nvdimm
   rw-rr-. 1 qemu qemu system_u:object_r:svirt_image_t:s0:c486,c699 536870912 Sep 5 04:37 /tmp/nvdimm

1. getfattr -m trusted.libvirt.security -d /tmp/nvdimm
   getfattr: Removing leading '/' from absolute path names
2. file: tmp/nvdimm
   trusted.libvirt.security.dac="+0:+0"
   trusted.libvirt.security.ref_dac="3"
   trusted.libvirt.security.ref_selinux="1"
   trusted.libvirt.security.selinux="unconfined_u:object_r:user_tmp_t:s0"
   trusted.libvirt.security.timestamp_dac="1567565944"
   trusted.libvirt.security.timestamp_selinux="1567565944"

Actual results:

Fail to start 2nd guest

Expected results:

Start success

Additional info:

from the qemu doc, when set share=on, the same nvdimm backend file could be shared with other guest:

"share=on/off" controls the visibility of guest writes. If
"share=on", then guest writes will be applied to the backend
file. If another guest uses the same backend file with option
"share=on", then above writes will be visible to it as well. If
"share=off", then guest writes won't be applied to the backend
file and thus will be invisible to other guests.