On 10/07/2012 03:30 PM, Alexander Graf wrote: >>> >>> Yup. The new APIC MSR registers would also have the same problem, right? >> >> Which new APIC MSR registers? > > I thought x2apic can be accessed through MSRs? If you want to emulate that in > user space, you need something similar.
It's emulated in the kernel. But yes, for -no-kvm-irqchip -cpu +x2apic we have to do this kind of forwarding. >> >> An SPR becomes heavily used by a guest, and there is therefore pressure >> to emulate it in the kernel in order to improve performance. > > Then you enable a CAP to have it enabled in kernel space and thus user and > kernel space know about it. Ok. > >> The downside of this generic approach is that it prepares suprises down >> the road. The alternative approach, of adding a new KVM_EXIT_RESET, >> avoids this minefield, but requires ABI changes every time we want to >> emulate something in userspace. Can you provide a critique of this >> alternate approach? > > Yeah, it doesn't scale as well. The SPR read/write give us all information we > need to emulate other registers too, like the magical "read this SPR and > automatically get the interrupt vector from the MPIC and ack the interrupt > along the way" register we have on e500. We'd have to add a new exit for that > one as well. And for the next, and the next. Unless we emulate the MPIC in the kernel (of course that shouldn't be the trigger). > > Plus, today we don't get good error messages when we fail an SPR read/write. > With this approach, you do. And you can potentially configure whether you > want to ignore unknown SPRs on a per-VM basis. Ok, it makes sense. Maybe we should do the same for x86, though I'm worried about fragmenting the implementation - the cpu is now implemented in both userspace and the kernel, and we need to document precisely which MSRs are emulated in the kernel. -- 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
