On Tue, 2018-08-07 at 17:10 +0800, Yi Min Zhao wrote:
This patch provides a caching mechanism for the device address
extensions uid and fid on S390. For efficient sparse address allocation,
we introduce two hash tables for uid/fid which hold the address set
information per domain. Also in order to improve performance of
searching available value, we introduce our own callbacks for the two
hashtables. In this way, uid/fid is saved in hash key and hash value
could be any non-NULL pointer due to no operation on hash value. That is
also the reason why we don't introduce hash value free callback.
Signed-off-by: Yi Min Zhao <zyimin(a)linux.ibm.com>
Reviewed-by: Boris Fiuczynski <fiuczy(a)linux.vnet.ibm.com>
Reviewed-by: Bjoern Walk <bwalk(a)linux.vnet.ibm.com>
Reviewed-by: Ján Tomko <jtomko(a)redhat.com>
---
src/conf/domain_addr.c | 85 ++++++++++++++++++++++++++++++++++++++++++
src/conf/domain_addr.h | 9 +++++
src/libvirt_private.syms | 1 +
src/qemu/qemu_domain_address.c | 7 ++++
4 files changed, 102 insertions(+)
I haven't looked into the hash table handling in detail but I
wonder if it's really necessary? IIUC you're using it just to
mark which uids and fids have been already used by a device,
which the PCI address allocation code does by setting bits
inside integer variables - having a custom hash table for the
same seems like overkill, and from the maintenance point of
view it would be great to have the logic for PCI address and
zPCI address allocation be similar unless diverging is strictly
necessary.
--
Andrea Bolognani / Red Hat / Virtualization