Re: [Xen-devel] [PATCH] x86/monitor: add support for descriptor access events

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 14.03.17 at 13:15, <itopan@xxxxxxxxxxxxxxx> wrote:
>> > @@ -2642,6 +2660,38 @@ void svm_vmexit_handler(struct cpu_user_regs *regs)
>> >      case VMEXIT_PAUSE:
>> >          svm_vmexit_do_pause(regs);
>> >          break;
>> > +    
>> > +    case VMEXIT_IDTR_READ:
>> > +        hvm_descriptor_access_intercept(vmcb->exitintinfo.bytes, 0, 
> VM_EVENT_DESC_IDTR, 0);
>> > +        break;
>> > +
>> > +    case VMEXIT_GDTR_READ:
>> > +        hvm_descriptor_access_intercept(vmcb->exitintinfo.bytes, 0, 
> VM_EVENT_DESC_GDTR, 0);
>> > +        break;
>> > +
>> > +    case VMEXIT_LDTR_READ:
>> > +        hvm_descriptor_access_intercept(vmcb->exitintinfo.bytes, 0, 
> VM_EVENT_DESC_LDTR, 0);
>> > +        break;
>> > +
>> > +    case VMEXIT_TR_READ:
>> > +        hvm_descriptor_access_intercept(vmcb->exitintinfo.bytes, 0, 
> VM_EVENT_DESC_TR, 0);
>> > +        break;
>> > +
>> > +    case VMEXIT_IDTR_WRITE:
>> > +        hvm_descriptor_access_intercept(vmcb->exitintinfo.bytes, 0, 
> VM_EVENT_DESC_IDTR, 1);
>> > +        break;
>> > +
>> > +    case VMEXIT_GDTR_WRITE:
>> > +        hvm_descriptor_access_intercept(vmcb->exitintinfo.bytes, 0, 
> VM_EVENT_DESC_GDTR, 1);
>> > +        break;
>> > +
>> > +    case VMEXIT_LDTR_WRITE:
>> > +        hvm_descriptor_access_intercept(vmcb->exitintinfo.bytes, 0, 
> VM_EVENT_DESC_LDTR, 1);
>> > +        break;
>> > +
>> > +    case VMEXIT_TR_WRITE:
>> > +        hvm_descriptor_access_intercept(vmcb->exitintinfo.bytes, 0, 
> VM_EVENT_DESC_TR, 1);
>> > +        break;
>> 
>> I think this can be halved in size by having
>> 'hvm_descriptor_access_intercept(..., exit_reason_write?1:0)'
>> 
>> And maybe even collapse completely by having a lookup table mapping exit
>> reason to event.
> 
> The problem with both ideas is that they depend on assumptions about the
> values of the VMEXIT_* constants to make the code shorter and still
> keep it readable, which in my opinion would be bad.

I see nothing bad here, we make similar assumptions elsewhere.

> Although they will
> most likely stay sequential and keep their current numeric values,

They're sure to stay the same forever, or else everyone's code
will break.

Jan


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