On 07.10.2012, at 15:34, Avi Kivity wrote: > 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).
Yeah, and we have a patch pending that emulates the MPIC in kernel space. But I want to keep 100% compatibility with user space emulated MPICs anyway, least of all to make sure that we have an easier time to narrow down bugs. > >> >> 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. Why not reverse the logic? Just have a list of MSRs you require user space to emulate. Put all the others that arrive at user space into the "unknown MSR" bucket and leave it to user space to decide what it wants to do with them. Alex -- 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