On Wed, 23 May 2012, Avi Kivity wrote: > On 05/22/2012 08:26 PM, Thomas Gleixner wrote: > > On Tue, 22 May 2012, Avi Kivity wrote: > >> On 05/22/2012 12:04 AM, Thomas Gleixner wrote: > >> > 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. > > > > I would avoid that by having a compressed version which reflects the > > SW state and the mapped one which allows the vmx microcode to fiddle > > with the TPR. If you need more registers in the HW page then you don't > > have to worry about the layout and just have a proper accessor for > > that. > > That works, but replaces one problem with another: now we have two > sources for the same data, and need to juggle between them depending on > register number (either synchronizing in both directions, or special > casing); so you're simplifying one thing at the expense of the other. > If the microcode starts accessing more registers, then having two > layouts becomes even uglier.
Fair enough :) -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
