Re: [PATCH v2 03/14] KVM: selftests: Add vfio_pci_irq_test

[Sean Christopherson <seanjc@google.com>]

On Thu, Apr 02, 2026, Josh Hilke wrote:
> On Wed, Apr 01, 2026 at 12:58:08PM -0700, Sean Christopherson wrote:
> > On Tue, Mar 31, 2026, Josh Hilke wrote:
> > > +int main(int argc, char **argv)
> > > +{
> > > +	/*
> > > +	 * Pick a random vector and a random GSI to use for device IRQ.
> > > +	 *
> > > +	 * Pick an IRQ vector in range [32, UINT8_MAX]. Min value is 32 because
> > > +	 * Linux/x86 reserves vectors 0-31 for exceptions and architecture
> > > +	 * defined NMIs and interrupts.
> > > +	 *
> > > +	 * Pick a GSI in range [24, KVM_MAX_IRQ_ROUTES - 1]. The min value is 24
> > > +	 * because KVM reserves GSIs 0-15 for legacy ISA IRQs and 16-23 only go
> > > +	 * to the IOAPIC. The max is KVM_MAX_IRQ_ROUTES - 1, because
> > > +	 * KVM_MAX_IRQ_ROUTES is exclusive.
> > > +	*/
> > > +	u32 gsi = 24 + rand() % (KVM_MAX_IRQ_ROUTES - 1 - 24);
> > > +	u8 vector = 32 + rand() % (UINT8_MAX - 32);
> > 
> > Ahh, now I see why you included "Reproduce tests that rely on randomization" in
> > this series.
> > 
> > I think I'd prefer to tweak guest_random_state() to drop the "guest" in favor of
> > "kvm", and then use that framework in host code as well.  Then you wouldn't need
> > to open code the % fun.
> > 
> 
> How would using the guest_random_state() library remove the need to calculate the appropriate ranges using %? 
> The library (tools/testing/selftests/kvm/include/test_util.h) only provides:
> 
> uint64_t guest_random_u64(struct guest_random_state *state);
> uint32_t guest_random_u32(struct guest_random_state *state);
> 
> I could avoid using % by adding a new library function that picks a
> random number within a range:
> 
> uint64_t kvm_random_u64_in_range(struct kvm_random_state *state, uint64_t min, uint64_t max);

Yes, please.  I was thinking that in my head, but never typed it out.  The original
plan with the pRNG code was to build out the set of APIs for doing random number
things, it just never picked up steam due to lack of need.

> > As for the get_irq_number() and get_irq_count(), those need to be much more clearly
> > scoped to /proc/interrupts.  E.g. "irq" in KVM context most often refers to the
> > guest IRQ vector, not the host Linux make-believe IRQ number.
> > 
> 
> How about I rename these to get_proc_irq_num() and get_proc_irq_count()?
> And then rename the library irq_util.h/c to proc_util.h/c?

Works for me.

> > > +	/* Set a consistent seed so that test are repeatable. */
> > > +	srand(0);
> > 
> > And using a pRNG instead of rand() should make this unnecessary.
> > 
> 
> We shouldn't even need a pRNG if we follow your suggestion above and use
> the guest_random_state() framework for the host, as it would provide the
> guest_random_u64() function.

Heh, by pRNG I meant guest_random_state itself: "struct guest_random_state" is
itself a pseudo-RNG implementation.