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. -- 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
