On 06/16/2010 02:14 PM, Nadav Har'El wrote:
Hi,

On Mon, Jun 14, 2010, Avi Kivity wrote about "Re: [PATCH 3/24] Implement VMXON and 
VMXOFF":
On 06/13/2010 03:24 PM, Nadav Har'El wrote:
This patch allows a guest to use the VMXON and VMXOFF instructions, and
emulates them accordingly. Basically this amounts to checking some
prerequisites, and then remembering whether the guest has enabled or
disabled
VMX operation.
Should probably reorder with next patch.
I can't do this if I want the code to compile after each patch, because the
next patch (controlling when setting cr4.VMXE can be set) needs to check
whether VMXON was done.

You can have this patch add the vmxon check. But it doesn't matter too much, you can keep the current order.

Need to block INIT signals in the local apic as well (fine for a
separate patch).
I've been looking into how I might best go about achieving this.

The APIC_DM_INIT handler is in lapic.c, which is not aware of VMX or
(obviously) nested VMX. So I need to add some sort of generic "block INIT"
flag which that code will check. Is this the sort of fix you had in mind?

It's not enough to block INIT, there is also exit reason 3, INIT signal. So you need to call x86.c code from the lapic, which needs to call a kvm_x86_op hook which lets vmx.c decide whether the INIT needs to be intercepted or not, and what to do with it (ignore in root mode, exit in non-root mode)

Note the check needs to be done in vcpu context, not during delivery as it is done now. So we probably need a KVM_REQ_INIT bit in vcpu->requests, which we can check during guest entry where we know if we're in root or non-root mode.

Pretty complicated and esoteric. We can defer this now while we work out more immediate issues, but it needs to be addressed.

--
error compiling committee.c: too many arguments to function

--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to