[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH 03/15] x86/emul: Rename hvm_trap to x86_event and move it into the emulation infrastructure



On 24/11/16 13:56, Jan Beulich wrote:
>>>> On 23.11.16 at 16:38, <andrew.cooper3@xxxxxxxxxx> 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?

I am open to idea of swapping things around, but wonder whether this
would be better done in a separate patch to avoid interfering with this
mechanical movement.

>
>> --- 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...

The first version also had an int => unsigned int change for error_code.

Now, the only difference is trap => vector, but I would like to keep it
for consistency with the other changes.

~Andrew

>
> Anyway, with or without the comments addressed,
> Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>
>
> Jan
>


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.