Re: [Xen-devel] [PATCH 10/17] vmx: nest: VMExit handler in L2

[Qing He <qing.he@xxxxxxxxx>]

On Thu, 2010-05-20 at 19:44 +0800, Tim Deegan wrote:
> At 10:41 +0100 on 22 Apr (1271932882), Qing He wrote:
> > +
> > +    case VMX_EXIT_REASONS_FAILED_VMENTRY:
> > +    case EXIT_REASON_TRIPLE_FAULT:
> > +    case EXIT_REASON_TASK_SWITCH:
> > +    case EXIT_REASON_IO_INSTRUCTION:
> > +    case EXIT_REASON_CPUID:
> > +    case EXIT_REASON_MSR_READ:
> > +    case EXIT_REASON_MSR_WRITE:
> 
> Aren't these gated on a control bitmap in the L1 VMCS?
> 

cpuid is unconditional
io and msr are controlled through bitmaps, but they are turned
off in the capability reporting

> > +    case EXIT_REASON_HLT:
> > +    case EXIT_REASON_RDTSC:
> > +    case EXIT_REASON_RDPMC:
> > +    case EXIT_REASON_MWAIT_INSTRUCTION:
> > +    case EXIT_REASON_PAUSE_INSTRUCTION:
> > +    case EXIT_REASON_MONITOR_INSTRUCTION:
> > +    case EXIT_REASON_DR_ACCESS:
> > +    case EXIT_REASON_INVLPG:
> > +    {
> > +        int i;
> > +
> > +        /* exit according to guest exec_control */
> > +        ctrl = __get_vvmcs(nest->vvmcs, CPU_BASED_VM_EXEC_CONTROL);
> > +
> > +        for ( i = 0; i < ARRAY_SIZE(control_bit_for_reason); i++ )
> > +            if ( control_bit_for_reason[i].reason == exit_reason )
> > +                break;
> 
> You've already got a switch statement - why not gate these individually
> rather than bundling them together and scanning an array?
> 

Well, they are the `regular' part of exit handling, a bit in the control
bitmap corresponds to their behavior

> > +    if ( nest->vmexit_pending )
> > +        bypass_l0 = 1;
> 
> This variable doesn't seem to do anything useful. 

This is a preparation for those doesn't generate virtual
vmexit but need to bypass normal L0 exit handler
> 
> > +    return bypass_l0;
> > +}
> 
> Cheers,
> 
> Tim.
> 
> -- 
> Tim Deegan <Tim.Deegan@xxxxxxxxxx>
> Principal Software Engineer, XenServer Engineering
> Citrix Systems UK Ltd.  (Company #02937203, SL9 0BG)

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel