Re: [PATCH v5 05/15] KVM: s390: unify pending_irqs() and pending_irqs_no_gisa()

[pierre morel]

Le 12/20/18 Ã 13:33, Michael Mueller a ÃcritÂ:
> On 20.12.18 13:21, Cornelia Huck wrote:
> > On Thu, 20 Dec 2018 12:49:56 +0100
> > Michael Mueller <mimu@xxxxxxxxxxxxx> wrote:
> >
> > > On 20.12.18 12:06, Cornelia Huck wrote:
> > > > On Wed, 19 Dec 2018 20:17:46 +0100
> > > > Michael Mueller <mimu@xxxxxxxxxxxxx> wrote:
> > > > > Use a single function with parameter irq_flags to differentiate
> > > > > between cases.
...snip
> > > > > ÂÂ }
> > > > > -static inline unsigned long pending_irqs_no_gisa(struct kvm_vcpu 
> > > > > *vcpu)
> > > > > +static inline unsigned long pending_irqs(struct kvm_vcpu *vcpu, 
> > > > > u16 irq_flags)
> > > >
> > > > Any deeper reason why this is a u16? 16 bits should be enough for
> > > > everyone? :)
> > >
> > > I want to use the 8 bits for the IRQ type and the other 8 for additional
> > > controls, see: "KVM: s390: restore IAM in get_ipm() when IPM is clean"
> >
> > Still need to look at that patch, but my question mainly was "why only
> > 16 bits"? I would think making this local variable larger is cheap.

+1

> I will enlarge the flag mask to u32 with 16 bits for the IRQ types then.

AFAIK CPU generally work better with int (or long)
Is there any hardware reason to restrict the size?

> > > > > ÂÂ {
> > > > > -ÂÂÂ return vcpu->kvm->arch.float_int.pending_irqs |
> > > > > -ÂÂÂÂÂÂÂ vcpu->arch.local_int.pending_irqs;
> > > > > -}