>>> On 23.11.16 at 16:38, <andrew.coop...@citrix.com> wrote:
> --- a/xen/arch/x86/x86_emulate/x86_emulate.h
> +++ b/xen/arch/x86/x86_emulate/x86_emulate.h
> @@ -67,6 +67,28 @@ enum x86_swint_emulation {
> x86_swint_emulate_all, /* Help needed with all software events */
> };
>
> +/*
> + * x86 event types. This enumeration is valid for:
> + * Intel VMX: {VM_ENTRY,VM_EXIT,IDT_VECTORING}_INTR_INFO[10:8]
> + * AMD SVM: eventinj[10:8] and exitintinfo[10:8] (types 0-4 only)
> + */
> +enum x86_event_type {
> + X86_EVENTTYPE_EXT_INTR, /* External interrupt */
> + X86_EVENTTYPE_NMI = 2, /* NMI */
> + X86_EVENTTYPE_HW_EXCEPTION, /* Hardware exception */
> + X86_EVENTTYPE_SW_INTERRUPT, /* Software interrupt (CD nn) */
> + X86_EVENTTYPE_PRI_SW_EXCEPTION, /* ICEBP (F1) */
> + X86_EVENTTYPE_SW_EXCEPTION, /* INT3 (CC), INTO (CE) */
> +};
> +
> +struct x86_event {
> + int16_t vector;
> + uint8_t type; /* X86_EVENTTYPE_* */
Do we perhaps want to make the compiler warn about possibly
incomplete switch statements, but making this an 8-bit field of
type enum x86_event_type? (That would perhaps imply making
vector and insn_len bitfields too; see also below.)
> + uint8_t insn_len; /* Instruction length */
> + uint32_t error_code; /* HVM_DELIVER_NO_ERROR_CODE if n/a */
> + unsigned long cr2; /* Only for TRAP_page_fault h/w exception */
> +};
Also I have to admit I'm not really happy about the mixing of fixed
width and fundamental types. Can I talk you into using only the
latter?
> --- a/xen/include/asm-x86/hvm/vmx/vvmx.h
> +++ b/xen/include/asm-x86/hvm/vmx/vvmx.h
> @@ -112,8 +112,8 @@ void nvmx_vcpu_destroy(struct vcpu *v);
> int nvmx_vcpu_reset(struct vcpu *v);
> uint64_t nvmx_vcpu_eptp_base(struct vcpu *v);
> enum hvm_intblk nvmx_intr_blocked(struct vcpu *v);
> -bool_t nvmx_intercepts_exception(struct vcpu *v, unsigned int trap,
> - int error_code);
> +bool_t nvmx_intercepts_exception(
> + struct vcpu *v, unsigned int vector, int error_code);
This reformatting doesn't appear to be in line with other nearby
code. But iirc you've got an ack from the VMX side already...
Anyway, with or without the comments addressed,
Reviewed-by: Jan Beulich <jbeul...@suse.com>
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
