On a real machine a cpu disabled via hlt with interrupts disabled can be reactivated via a nmi ipi. Enable the hypervisor to do this for hvm, too. Signed-off-by: juergen.gross@ts.fujitsu.com 1 file changed, 4 insertions(+), 1 deletion(-) xen/arch/x86/hvm/vlapic.c | 5 ++++- _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 01/18/2012 09:48 AM, Juergen Gross wrote:> On a real machine a cpu disabled via hlt with interrupts disabled can be > reactivated via a nmi ipi. Enable the hypervisor to do this for hvm, too. > > Signed-off-by: juergen.gross@ts.fujitsu.com > > > 1 file changed, 4 insertions(+), 1 deletion(-) > xen/arch/x86/hvm/vlapic.c | 5 ++++-BTW: I was not able to reactivate a vcpu via INIT/SIPI/SIPI sequence. It works on initial system boot when the target vcpu is activated the first time. If I deactivate a vcpu and try to activate it again it will start to run, but it is not starting at the specified entry point (at least it isn''t performing the first instruction there). Is there some special initialization needed to make this work? Do I have to reset something on the vcpu before deactivating it? Juergen -- Juergen Gross Principal Developer Operating Systems PDG ES&S SWE OS6 Telephone: +49 (0) 89 3222 2967 Fujitsu Technology Solutions e-mail: juergen.gross@ts.fujitsu.com Domagkstr. 28 Internet: ts.fujitsu.com D-80807 Muenchen Company details: ts.fujitsu.com/imprint.html
On 18/01/2012 08:48, "Juergen Gross" <juergen.gross@ts.fujitsu.com> wrote:> On a real machine a cpu disabled via hlt with interrupts disabled can be > reactivated via a nmi ipi. Enable the hypervisor to do this for hvm, too.I think the vcpu_kick() path is still needed where the vcpu is HLTed with interrupts enabled. I''ll have to give this a bit of thought... Probably clear_bit(_VPF_down) vcpu_wake() vcpu_kick() Would work just fine. -- Keir> Signed-off-by: juergen.gross@ts.fujitsu.com > > > 1 file changed, 4 insertions(+), 1 deletion(-) > xen/arch/x86/hvm/vlapic.c | 5 ++++- > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel
On 18/01/2012 09:07, "Juergen Gross" <juergen.gross@ts.fujitsu.com> wrote:> On 01/18/2012 09:48 AM, Juergen Gross wrote: >> On a real machine a cpu disabled via hlt with interrupts disabled can be >> reactivated via a nmi ipi. Enable the hypervisor to do this for hvm, too. >> >> Signed-off-by: juergen.gross@ts.fujitsu.com >> >> >> 1 file changed, 4 insertions(+), 1 deletion(-) >> xen/arch/x86/hvm/vlapic.c | 5 ++++- > > BTW: I was not able to reactivate a vcpu via INIT/SIPI/SIPI sequence. It works > on initial system boot when the target vcpu is activated the first time. If I > deactivate a vcpu and try to activate it again it will start to run, but it is > not starting at the specified entry point (at least it isn''t performing the > first instruction there). > Is there some special initialization needed to make this work? Do I have to > reset > something on the vcpu before deactivating it?No it should just work. Hvmloader wakes and then sleeps every AP, in hvmloader/smp.c. So even the first INIT-SIPI wakeup of an AP in the guest OS is not the first, as hvmloader already did it once! So this path should be working and indeed tested on every HVM guest boot. -- Keir> > Juergen
On 18/01/2012 09:31, "Keir Fraser" <keir.xen@gmail.com> wrote:> On 18/01/2012 09:07, "Juergen Gross" <juergen.gross@ts.fujitsu.com> wrote: > >> On 01/18/2012 09:48 AM, Juergen Gross wrote: >>> On a real machine a cpu disabled via hlt with interrupts disabled can be >>> reactivated via a nmi ipi. Enable the hypervisor to do this for hvm, too. >>> >>> Signed-off-by: juergen.gross@ts.fujitsu.com >>> >>> >>> 1 file changed, 4 insertions(+), 1 deletion(-) >>> xen/arch/x86/hvm/vlapic.c | 5 ++++- >> >> BTW: I was not able to reactivate a vcpu via INIT/SIPI/SIPI sequence. It >> works >> on initial system boot when the target vcpu is activated the first time. If I >> deactivate a vcpu and try to activate it again it will start to run, but it >> is >> not starting at the specified entry point (at least it isn''t performing the >> first instruction there). >> Is there some special initialization needed to make this work? Do I have to >> reset >> something on the vcpu before deactivating it? > > No it should just work. Hvmloader wakes and then sleeps every AP, in > hvmloader/smp.c. So even the first INIT-SIPI wakeup of an AP in the guest OS > is not the first, as hvmloader already did it once! So this path should be > working and indeed tested on every HVM guest boot.Bit more info: INIT-SIPI logic is complicated by needing to avoid deadlocks between two VCPUs attempting to pause and reset each other. But the core dispatch logic is in vlapic_init_sipi_action(). You will see that on INIT, we should call vcpu_reset() which will de-initialise and VCPU_down the vcpu. And then on SIPI we call hvm_vcpu_reset_state(), which should reinitialise and wake the vcpu to start running at the specified CS:IP. So the above will be good places for you to add tracing and work out what''s going on. :-) -- Keir> -- Keir > >> >> Juergen > >
On 01/18/2012 10:36 AM, Keir Fraser wrote:> On 18/01/2012 09:31, "Keir Fraser"<keir.xen@gmail.com> wrote: > >> On 18/01/2012 09:07, "Juergen Gross"<juergen.gross@ts.fujitsu.com> wrote: >> >>> On 01/18/2012 09:48 AM, Juergen Gross wrote: >>>> On a real machine a cpu disabled via hlt with interrupts disabled can be >>>> reactivated via a nmi ipi. Enable the hypervisor to do this for hvm, too. >>>> >>>> Signed-off-by: juergen.gross@ts.fujitsu.com >>>> >>>> >>>> 1 file changed, 4 insertions(+), 1 deletion(-) >>>> xen/arch/x86/hvm/vlapic.c | 5 ++++- >>> BTW: I was not able to reactivate a vcpu via INIT/SIPI/SIPI sequence. It >>> works >>> on initial system boot when the target vcpu is activated the first time. If I >>> deactivate a vcpu and try to activate it again it will start to run, but it >>> is >>> not starting at the specified entry point (at least it isn''t performing the >>> first instruction there). >>> Is there some special initialization needed to make this work? Do I have to >>> reset >>> something on the vcpu before deactivating it? >> No it should just work. Hvmloader wakes and then sleeps every AP, in >> hvmloader/smp.c. So even the first INIT-SIPI wakeup of an AP in the guest OS >> is not the first, as hvmloader already did it once! So this path should be >> working and indeed tested on every HVM guest boot. > Bit more info: INIT-SIPI logic is complicated by needing to avoid deadlocks > between two VCPUs attempting to pause and reset each other. But the core > dispatch logic is in vlapic_init_sipi_action(). You will see that on INIT, > we should call vcpu_reset() which will de-initialise and VCPU_down the vcpu. > And then on SIPI we call hvm_vcpu_reset_state(), which should reinitialise > and wake the vcpu to start running at the specified CS:IP. > > So the above will be good places for you to add tracing and work out what''s > going on. :-)Yeah, thanks for the confirmation this should work. Printing some diagnostics helped me to spot the error in my code. Juergen -- Juergen Gross Principal Developer Operating Systems PDG ES&S SWE OS6 Telephone: +49 (0) 89 3222 2967 Fujitsu Technology Solutions e-mail: juergen.gross@ts.fujitsu.com Domagkstr. 28 Internet: ts.fujitsu.com D-80807 Muenchen Company details: ts.fujitsu.com/imprint.html