On Tue, Sep 1, 2009 at 3:29 PM, Marcelo Tosatti<[email protected]> wrote: > On Tue, Sep 01, 2009 at 03:08:55PM +0200, Mohammed Gamal wrote: >> On Tue, Sep 1, 2009 at 2:18 PM, Marcelo Tosatti<[email protected]> wrote: >> > On Tue, Sep 01, 2009 at 02:14:17PM +0200, Mohammed Gamal wrote: >> >> On Tue, Sep 1, 2009 at 1:48 PM, Marcelo Tosatti<[email protected]> >> >> wrote: >> >> > On Tue, Sep 01, 2009 at 12:48:18PM +0200, Mohammed Gamal wrote: >> >> >> - Change returned handle_invalid_guest_state() to return relevant exit >> >> >> codes >> >> >> - Move triggering the emulation from vmx_vcpu_run() to >> >> >> vmx_handle_exit() >> >> >> - Return to userspace instead of repeatedly trying to emulate >> >> >> instructions that have already failed >> >> >> >> >> >> Signed-off-by: Mohammed Gamal <[email protected]> >> >> > >> >> > Mohammed, >> >> > >> >> > The handle_invalid_guest_state loop is potentially problematic. It would >> >> > be more appropriate to use the __vcpu_run loop. >> >> > >> >> > Can't you set vmx->emulation_required depending on the result >> >> > of one call to emulate_instruction and get rid of the while >> >> > (!guest_state_valid(vcpu)) loop? >> >> > >> >> >> >> Invalid state emulation is VMX-specfic, while the __vcpu_run loop is >> >> independent of the virtualization extension (defined in x86.c), no? >> >> AMD SVM can comforably run hosts in big-real mode and thus it doesn't >> >> have the notion of a guest going to an invalid state because of mode >> >> switching, so I don't think it'd be a good idea to move emulation into >> >> a generic layer. Please correct me if I am wrong >> > >> > Right. But all i am asking is to emulate one instruction at a >> > time in handle_invalid_guest_state, instead of looping until >> > guest_state_valid(vcpu). >> > >> > So you get rid of schedule(), the check for signal_pending, etc. >> >> But we'll still need to enter the guest when it's in a valid state, so >> we need to move that loop somewhere, > > Sure, just set vmx->emulation_required = guest_state_valid(vcpu). When > the state is good, the entry handler will vmentry. > >> and now that we still have a loop >> we'll also still need to do the pending signals and scheduling checks, >> no? > > Point is you can use the __vcpu_run loop. > > In the latest patch you do: > > + /* Don't enter VMX if guest state is invalid, let the exit handler > + start emulation until we arrive back to a valid state */ > + if (vmx->emulation_required && emulate_invalid_guest_state) > return; > > And then emulate in the exit handler. > >> I'd appreciate any suggestions you have to alleviate this. > > I fail to see why you need an internal loop if you can use the external > (__vcpu_run) one.
Because it's not just used by VMX. So I don't think it'd be wise to use it for something that's VMX-specific. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
