On Wed, May 25, 2011, Tian, Kevin wrote about "RE: [PATCH 23/31] nVMX: Correct handling of interrupt injection":
> > If L1 turns on VM_EXIT_ACK_INTR_ON_EXIT (again, no hypervisor that I know
> > does), things look very different from the description above: L1 expects
>
> Type-1 bare metal hypervisor may enable this bit, such as Xen. This bit is
> really prepared for L2 hypervisor since normally L2 hypervisor is tricky to
> touch generic interrupt logic, and thus better to not ack it until interrupt
> is enabled and then hardware will gear to the kernel interrupt handler
> automatically.
I have to be honest (and I was, in the patch set's introduction), this version
of nested VMX was only tested with a KVM L1. We've had VMWARE Server running
as a guest using a two-year-old branch of this code (as reported in our paper),
but this code has changed considerably since and it probably will not work
today. We've never tested Xen as L1.
I'll remove the emphasis on "no hypervisor that I know does", but the important
point remains: VM_EXIT_ACK_INTR_ON_EXIT is an optional feature, which we
report is *not* supported, so L1 should not attempt to use it.
As you said, it's not that difficult to support it, so we should, eventually,
but it's not a priority right now. It's on my Bugzilla.
> > +/*
> > + * In nested virtualization, check if L1 asked to exit on external interrupts.
> > + * For most existing hypervisors, this will always return true.
> > + */
> > +static bool nested_exit_on_intr(struct kvm_vcpu *vcpu)
> > +{
> > + return get_vmcs12(vcpu)->pin_based_vm_exec_control &
> > + PIN_BASED_EXT_INTR_MASK;
> > +}
> > +
>
> could be a similar common wrapper like nested_cpu_has...
I thought this made the callers easier to read, and didn't result in too much
code duplication, so I prefer it this way.
--
Nadav Har'El | Wednesday, May 25 2011, 21 Iyyar 5771
nyh@xxxxxxxxxxxxxxxxxxx |-----------------------------------------
Phone +972-523-790466, ICQ 13349191 |Windows detected you moved your mouse.
http://nadav.harel.org.il |Reboot for this change to take effect.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
