Hi,
On 13/02/18 14:31, Julien Grall wrote:
> Hi Andre,
>
> On 09/02/18 14:39, Andre Przywara wrote:
>> +/* Requires the VCPU's ap_list_lock to be held. */
>> +static void vgic_flush_lr_state(struct vcpu *vcpu)
>> +{
>> + struct vgic_cpu *vgic_cpu = &vcpu->arch.vgic_cpu;
>> + struct vgic_irq *irq;
>> + int count = 0;
>> +
>> + ASSERT(spin_is_locked(&vgic_cpu->ap_list_lock));
>> +
>> + if ( compute_ap_list_depth(vcpu) > gic_get_nr_lrs() )
>> + vgic_sort_ap_list(vcpu);
>> +
>> + list_for_each_entry( irq, &vgic_cpu->ap_list_head, ap_list )
>> + {
>> + spin_lock(&irq->irq_lock);
>> +
>> + if ( unlikely(vgic_target_oracle(irq) != vcpu) )
>> + goto next;
>> +
>> + /*
>> + * If we get an SGI with multiple sources, try to get
>> + * them in all at once.
>> + */
>> + do
>> + {
>> + vgic_populate_lr(vcpu, irq, count++);
>> + } while ( irq->source && count < gic_get_nr_lrs() );
>> +
>> +next:
>> + spin_unlock(&irq->irq_lock);
>> +
>> + if ( count == gic_get_nr_lrs() )
>> + {
>> + if ( !list_is_last(&irq->ap_list, &vgic_cpu->ap_list_head) )
>> + vgic_set_underflow(vcpu);
>> + break;
>> + }
>> + }
>> +
>> + vcpu->arch.vgic_cpu.used_lrs = count;
>> +
>> + /* Nuke remaining LRs */
>> + for ( ; count < gic_get_nr_lrs(); count++)
>> + vgic_clear_lr(vcpu, count);
>
> Why do you need to nuke the LRs here, don't you always zero them when
> clearing it?
We nuke our internal LR copies in here.
It might be interesting to see if we can get rid of those in Xen,
because we can always write to the LRs directly. But this is an
optimization I am not too keen on addressing too early, because this
deviates from the KVM VGIC architecture.
Cheers,
Andre.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
