On Oct 7 18:24, Lukasz Maniak wrote: > From: Łukasz Gieryk > > The Nvme device defines two properties: max_ioqpairs, msix_qsize. Having > them as constants is problematic for SR-IOV support. > > The SR-IOV feature introduces virtual resources (queues, interrupts) > that can be assigned to PF and its dependent VFs. Each device, following > a reset, should work with the configured number of queues. A single > constant is no longer sufficient to hold the whole state. > > This patch tries to solve the problem by introducing additional > variables in NvmeCtrl’s state. The variables for, e.g., managing queues > are therefore organized as: > > - n->params.max_ioqpairs – no changes, constant set by the user. > > - n->max_ioqpairs - (new) value derived from n->params.* in realize(); > constant through device’s lifetime. > > - n->(mutable_state) – (not a part of this patch) user-configurable, > specifies number of queues available _after_ > reset. > > - n->conf_ioqpairs - (new) used in all the places instead of the ‘old’ > n->params.max_ioqpairs; initialized in realize() > and updated during reset() to reflect user’s > changes to the mutable state. > > Since the number of available i/o queues and interrupts can change in > runtime, buffers for sq/cqs and the MSIX-related structures are > allocated big enough to handle the limits, to completely avoid the > complicated reallocation. A helper function (nvme_update_msixcap_ts) > updates the corresponding capability register, to signal configuration > changes. > > Signed-off-by: Łukasz Gieryk Instead of this, how about adding new parameters, say, sriov_vi_private and sriov_vq_private. Then, max_ioqpairs and msix_qsize are still the "physical" limits and the new parameters just reserve some for the primary controller, the rest being available for flexsible resources.