On 05/21/2012 04:06 PM, Michael S. Tsirkin wrote: > > I think the reason is __apic_read which now simply copies the registers > out to guest, this code will become less straight-forward if it's not > 1:1. > It can still be 1:1, just drop the 12 bytes of completely useless padding after each 32-bit datum. >> And if you look deeper, then you'll notice that _ALL_ APIC registers >> are on a 16 byte boundary (thanks Peter for pointing that out). >> >> So it's even more silly to have a 1:1 representation instead of >> implementing the default emulated apic_read/write functions to access >> (offset >> 2). >> >> And of course, that design decision causes lookups to be slow. > > Yes, it might be one of the reasons why my patch helps so > much: it adds a cache in front of this data structure. > Well, *fix the fscking data structure first*. > > So what you propose is in fact to rework apic registers at least for > ISR,IRR,TMR to use a bitmap. > I am fine with this suggestion but would like some feedback from kvm > maintainers on where they want to go before I spend time on that. > This should be a 20-minute hack. -hpa -- 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
