On Thu, 2010-05-20 at 19:21 +0800, Tim Deegan wrote:
> At 10:41 +0100 on 22 Apr (1271932881), Qing He wrote:
> > +/*
> > + * Nested virtualization interrupt handling:
> > + *
> > + * When vcpu runs in nested context (L2), the event delivery from
> > + * L0 to L1 may be blocked by several reasons:
> > + * - virtual VMExit
> > + * - virtual VMEntry
>
> I'm not sure I understand what the plan is here. It looks like you
> queue up a virtual vmentry or vmexit so that it happens just before the
> real vmentry and then have to hold off interrupt injection because of
> it. I'm a little worried that we'll end up taking a virtual vmexit for
> an interrupt, and then not injecting the interrupt.
>
Interrupt handling was one of the most error prone parts when I
was implementingg nested virtualization. I'll write a more detailed
outline here in next several days, but I'll list some points here,
hope it can help.
Let's say, there are three kinds of interrupt: physical intr (physical),
l0 intr (to be injected to l1), l1 intr (to be injected to l2), then:
- simple rule: when running in L2, l0 intr causes a virtual vmexit
- what about there is a pending l0 intr when l1 intr is to be
injected? and what if there is a pending softirq in the window
between loading L2 vmcs and physical vmentry?
- failed l1 intr may be injected by l0 or l1, depending on who solves
the fault
- when running in L2, if a l0 intr is to be injected, but blocked
(vmentry in progress, idtv injection), it is not exactly correct to
simply open intr window. Intr window will cause L2 to exit till L2's
IF is cleared, but that should not be a blocking reason for l0 intr
- there is the option of ack-intr-on-exit, which needs to be handled
carefully in original vmx_intr_assist
Thanks,
Qing
> Maybe you could outline the overall design of how interrupt delivery and
> virtual vmenter/vmexit should work in nested VMX. I suspect that I've
> just misunderstood the code.
>
> 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
|
Home