Gregory Haskins wrote:
>> I don't understand. Isn't the tpr read- only from the point of view of >> the lapic? >> >> > > Not quite. Its true that the APIC proper views the TPR as read-only. > However, TPR can be set by the CPU using both MOV to CR8 as well as an MMIO > operation to the TPR register, and MMIOs are handled by the APIC code (on > behalf of the vCPU) > Right, I forgot. > >> A simple set_cr8 helper should do the trick. >> > > That would certainly solve the simple MOV to CR8 problem, yes. I gets a > little goofier when we start looking at the MMIO access path, but even that > isn't insurmountable. Where I really hit the wall was when I was thinking > about TPR shadowing, which really wants direct access to the contiguous > register file of the LAPIC. I suppose we could give the CPU a real shadow of > the registers and simply sync the TPR value on exit. But it just seemed to > be getting hacky for the sake of having vcpu->cr8. Whats wrong with simply > looking at the LAPIC registers when you want to know? ;) > It's weird that you look at the kernel lapic even when you're using the userint code. I'd also like to be consistent with the other registers which have shadows in the vcpu struct. -- error compiling committee.c: too many arguments to function ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
