Avi Kivity wrote: > On 07/24/2009 10:00 AM, Jan Kiszka wrote: >> Marcelo Tosatti wrote: >> >>> On Wed, Jul 22, 2009 at 11:53:26PM +0200, Jan Kiszka wrote: >>> >>>> Release and re-acquire preemption and IRQ lock in the same order as >>>> vcpu_enter_guest does. >>>> >>> This should happen in vcpu_enter_guest, before it decides to disable >>> preemption/irqs (so you consolidate the control there). >>> >> >> Maybe, maybe not. handle_invalid_guest_state is an alternative way of >> "executing" guest code, and it currently shares the setup and tear-down >> with vmx_vcpu_run. If it has to share parts that actually require >> preemption and IRQ lock, then moving makes not much sense. Can anyone >> comment on what the requirements for handle_invalid_guest_state are? >> > > Like you said, it's an alternative to vmx entry/exit, so it shares the > same requirements. It must run with interrupts and preemption enabled, > but any code that normally runs in the entry critical section (like > interrupt injection) must continue to run in a critical section. > > >> I would suggest to merge this fix first and then decide about and >> potentially merge a refactoring patch. >> > > btw, what does it fix? a debug warning? >
I haven't seen anything in the wild, and I don't think it would raise a warning. All it should cause is a potential delay of some pending reschedule as preempt_enable will not fire under local_irq_disable. Jan
signature.asc
Description: OpenPGP digital signature