On 05/22/2012 12:04 AM, Thomas Gleixner wrote:
> >
> > +static u8 count_vectors(void *bitmap)
> > +{
> > + u32 *word = bitmap;
> > + int word_offset;
> > + u8 count = 0;
> > + for (word_offset = 0; word_offset < MAX_APIC_VECTOR >> 5; ++word_offset)
> > + count += hweight32(word[word_offset << 2]);
> > + return count;
> > +}
>
> Why do you need to reimplement bitmap_weight()?
>
> Because your bitmap is not a bitmap, but a set of 32bit registers
> which have an offset of 4 words each. I really had to twist my brain
> around this function and the test_and_clr/set ones above just because
> the name bitmap is so horribly misleading. Add an extra bonus for
> using void pointers.
>
> Yes, I know, the existing code is full of this, but that's not an
> excuse to add more of it.
>
> This emulation is just silly. Nothing in an emulation where the access
> to the emulated hardware is implemented with vmexits is requiring a
> 1:1 memory layout. It's completely irrelevant whether the hardware has
> an ISR regs offset of 0x10 or not. Nothing prevents the emulation to
> use a consecutive bitmap for the vector bits instead of reimplementing
> a boatload of bitmap operations.
>
> The only justification for having the same layout as the actual
> hardware is when you are going to map the memory into the guest space,
> which is not the case here.
>
>
The APIC page is in fact mapped to the hardware (not the guest, but vmx
microcode does access it). Only one register, the TPR, is ever used.
It's possible to re-layout the data structure so that the TPR stays in
the same place while everything else becomes contiguous, but we'll have
to do it again if the hardware starts mapping more registers.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
