Re: [Xen-devel] [RFC v2 08/15] Update IRTE according to guest interrupt config changes

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 16.06.15 at 10:08, <feng.wu@xxxxxxxxx> wrote:
>> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
>> Sent: Tuesday, June 09, 2015 11:06 PM
>> >>> On 08.05.15 at 11:07, <feng.wu@xxxxxxxxx> wrote:
>> > +    dest_vcpu_array = xzalloc_array(struct vcpu *, d->max_vcpus);
>> 
>> You realize that this can be quite big an allocation? (You could at
>> least halve it by storing vCPU IDs instead of pointers, but if I'm
>> not mistaken this could even be a simple bitmap.)
> 
> I think maybe storing the vCPU IDs is better than using bitmap, because
> If using vCPU IDs, we can easily to find the destination vCPU id by 
> dest_vcpu_id_array [gvec % dest_vcpu_num],
> then we can get the vcpu form d->vcpu[]. However if we use bitmap here, we 
> set 
> the bits for those vCPUs which
> is present in the destination field, then we need to use find_next_bit() to 
> find the right vCPU ID, this may need
> a while loop, see the following scenario:
> 
> - Guest has 8 vCPUs, in the interrupt destination fields, it only configures 
> vcpu 0, 1, 3, 4, 5, 7 for the lowest-priority interrupt.
>  So we get the vCPU destination bitmap like this: 10111011b
> - Suppose guest vector is 44, so we choose 44%6=2, we need to use 
> find_next_bit() to find the second set bit (counting from 0, which is vCPU ID 
> 3), this may need a while loop.
> 
> What is your opinion about this? Space vs Speed?

Since the array can get rather large (in particular, larger than a page),
space would seem the more important factor here.

Also - please trim your replies.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel