Re: [PATCH -v3 0/8] kvm/svm: implement new DecodeAssist features
On Tue, Dec 21, 2010 at 11:11:59AM +0100, Andre Przywara wrote: Hi, this is version 3 of the DecodeAssist patches. I added 3 clean up patches which are not SVM specific. Changes between v2 and v3: - now includes the (unchanged) CR8 handling fix - move complete_insn_gp() helper function into x86.c - remove unnecessary comment - fix handling of illegal CR accesses (inject #UD, should actually not occur) - completely rework the instruction bytes copy patch Now this propagates the addr/len pair from the interception handling into the emulator. For this I cleaned up this code path a bit (patch 3), so it does not blow up all current users of emulate_instruction. Changes between v1 and v2: - goes on top of the CR8 handling fix I sent out earlier this week (required for proper handling of CR8 exceptions) - handles exception cases properly (for mov cr and mov dr) - uses X86_FEATURE_ names instead of SVM_FEATURE names (for boot_cpu_has) (thanks to Joerg for spotting this) - use static_cpu_has where appropriate - some minor code cleanups (for instance cr register calculation) - move prefetch callback into x86_decode_insn and out of every fetch I refrained from ditching the callback at all, as I dont like extending every emulate_instruction call with NULL, 0. But if this is desperately needed, I can still change it. - rename vendor specific prefetch function names Upcoming AMD CPUs will have a SVM enhancement called DecodeAssist which will provide more information when intercepting certain events. These information allows to skip the instruction fetching and decoding and handle the intercept immediately. This patch set implements all the features which are documented in the recent AMD manual (APM vol. 2). For details see the patches. Please review and apply. Regards, Andre. Applied, thanks (fixed DR patch to not inject exceptions since its already done by get_dr/set_dr). -- 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
Re: [PATCH -v3 0/8] kvm/svm: implement new DecodeAssist features
On 12/21/2010 12:11 PM, Andre Przywara wrote: Hi, this is version 3 of the DecodeAssist patches. I added 3 clean up patches which are not SVM specific. Changes between v2 and v3: - now includes the (unchanged) CR8 handling fix - move complete_insn_gp() helper function into x86.c - remove unnecessary comment - fix handling of illegal CR accesses (inject #UD, should actually not occur) - completely rework the instruction bytes copy patch Now this propagates the addr/len pair from the interception handling into the emulator. For this I cleaned up this code path a bit (patch 3), so it does not blow up all current users of emulate_instruction. Changes between v1 and v2: - goes on top of the CR8 handling fix I sent out earlier this week (required for proper handling of CR8 exceptions) - handles exception cases properly (for mov cr and mov dr) - uses X86_FEATURE_ names instead of SVM_FEATURE names (for boot_cpu_has) (thanks to Joerg for spotting this) - use static_cpu_has where appropriate - some minor code cleanups (for instance cr register calculation) - move prefetch callback into x86_decode_insn and out of every fetch I refrained from ditching the callback at all, as I dont like extending every emulate_instruction call with NULL, 0. But if this is desperately needed, I can still change it. - rename vendor specific prefetch function names Upcoming AMD CPUs will have a SVM enhancement called DecodeAssist which will provide more information when intercepting certain events. These information allows to skip the instruction fetching and decoding and handle the intercept immediately. This patch set implements all the features which are documented in the recent AMD manual (APM vol. 2). For details see the patches. Looks good. -- 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
