public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Vivek Goyal <vgoyal@redhat.com>
To: "Huang, Ying" <ying.huang@intel.com>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>,
	Pavel Machek <pavel@ucw.cz>,
	nigel@nigel.suspend2.net, "Rafael J. Wysocki" <rjw@sisk.pl>,
	Andrew Morton <akpm@linux-foundation.org>,
	linux-kernel@vger.kernel.org,
	linux-pm@lists.linux-foundation.org,
	Kexec Mailing List <kexec@lists.infradead.org>
Subject: Re: [PATCH -mm] kexec jump -v9
Date: Tue, 27 May 2008 18:15:14 -0400	[thread overview]
Message-ID: <20080527221514.GA20037@redhat.com> (raw)
In-Reply-To: <1211873263.12819.103.camel@caritas-dev.intel.com>

On Tue, May 27, 2008 at 03:27:43PM +0800, Huang, Ying wrote:
> On Thu, 2008-05-15 at 20:51 -0400, Vivek Goyal wrote:
> > On Thu, May 15, 2008 at 01:41:50PM +0800, Huang, Ying wrote:
> > > Hi, Vivek,
> > > 
> > > On Wed, 2008-05-14 at 16:52 -0400, Vivek Goyal wrote:
> > > [...]
> > > > Ok, I have done some testing on this patch. Currently I have just
> > > > tested switching back and forth between two kernels and it is working for
> > > > me.
> > > > 
> > > > Just that I had to put LAPIC and IOAPIC in legacy mode for it to work. Few
> > > > comments/questions are inline.
> > > 
> > > It seems that for LAPIC and IOAPIC, there is
> > > lapic_suspend()/lapic_resume() and ioapic_suspend()/ioapic_resume(),
> > > which will be called before/after kexec jump through
> > > device_power_down()/device_power_up(). So, the mechanism for
> > > LAPIC/IOAPIC is there, we may need to check the corresponding
> > > implementation.
> > > 
> > 
> > ioapic_suspend() is not putting APICs in Legacy mode and that's why
> > we are seeing the issue. It only saves the IOAPIC routing table entries
> > and these entries are restored during ioapic_resume().
> > 
> > But I think somebody has to put APICs in legacy mode for normal 
> > hibernation also. Not sure who does it. May be BIOS, so that during
> > resume, second kernel can get the timer interrupts.
> 
> As for IOAPIC legacy mode, is it related to the following code which set
> the routing table entry for i8259?
> 
> 

Yes.

> void disable_IO_APIC(void)
> {
>         /*
>          * Clear the IO-APIC before rebooting:
>          */
>         clear_IO_APIC();
> 
>         /*
>          * If the i8259 is routed through an IOAPIC
>          * Put that IOAPIC in virtual wire mode
>          * so legacy interrupts can be delivered.
>          */
>         if (ioapic_i8259.pin != -1) {
>                 struct IO_APIC_route_entry entry;
> 
>                 memset(&entry, 0, sizeof(entry));
>                 entry.mask            = 0; /* Enabled */
>                 entry.trigger         = 0; /* Edge */
>                 entry.irr             = 0;
>                 entry.polarity        = 0; /* High */
>                 entry.delivery_status = 0;
>                 entry.dest_mode       = 0; /* Physical */
>                 entry.delivery_mode   = dest_ExtINT; /* ExtInt */
>                 entry.vector          = 0;
>                 entry.dest.physical.physical_dest =
>                                         GET_APIC_ID(apic_read(APIC_ID));
> 
>                 /*
>                  * Add it to the IO-APIC irq-routing table:
>                  */
>                 ioapic_write_entry(ioapic_i8259.apic, ioapic_i8259.pin,
> entry);
>         }
>         disconnect_bsp_APIC(ioapic_i8259.pin != -1);
> }
> 
> 
> But, because IOAPIC may need to be in original state during
> suspend/resume, so it is not appropriate to call disable_IO_APIC() in
> ioapic_suspend(). So I think we can call disable_IO_APIC() in new
> hibernation/restore callback.

My hunch is suspend/resume will still work if we put this call in
ioapic_suspend() but I would not recommend that. suspend/resume does
not need to put IOAPIC in legacy mode.
  
I am not sure what is "new hibernation/restore callback"? Are you
referring to new patches from Rafel?

I think this issue is specifc to kexec and kjump so probably we should
not tweaking any suspend/resume related bit.

How about calling disable_IO_APIC() in kexec_jump()? We can probably even
optimize it by calling it only when we are transitioning into new image
for the first time and not for subsquent transitions (by keeping some kind of
count in kimage). This is little hackish but, should work...

Thanks
Vivek

  reply	other threads:[~2008-05-27 22:17 UTC|newest]

Thread overview: 83+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-03-06  3:13 [PATCH -mm] kexec jump -v9 Huang, Ying
2008-03-11 21:10 ` Vivek Goyal
2008-03-11 21:59   ` Nigel Cunningham
2008-03-11 23:55     ` Eric W. Biederman
2008-03-12  0:09     ` david
2008-03-12  2:14     ` Huang, Ying
2008-03-12 18:53       ` Vivek Goyal
2008-03-13  0:01         ` Eric W. Biederman
2008-03-11 22:18   ` Rafael J. Wysocki
2008-03-12  2:02     ` Eric W. Biederman
2008-03-12  2:26     ` Huang, Ying
2008-03-11 23:24   ` Pavel Machek
2008-03-11 23:49     ` Rafael J. Wysocki
2008-03-12  1:55       ` Huang, Ying
2008-03-12 15:01         ` [linux-pm] " Alan Stern
2008-03-12 21:53           ` Rafael J. Wysocki
2008-03-13  0:33             ` Eric W. Biederman
2008-03-13 17:03               ` Rafael J. Wysocki
2008-03-13 23:07                 ` Eric W. Biederman
2008-03-14  1:31                   ` Rafael J. Wysocki
     [not found]                     ` <m1prtsug2e.fsf@ebiederm.dsl.xmission.com>
2008-03-18 23:52                       ` Pavel Machek
2008-03-19  0:08                       ` Rafael J. Wysocki
2008-03-19  2:33                         ` Alan Stern
     [not found]                           ` <m1ve3jtmxk.fsf@ebiederm.dsl.xmission.com>
2008-03-19 15:01                             ` Alan Stern
2008-03-19 19:28                               ` Rafael J. Wysocki
2008-03-20 10:40                             ` Pavel Machek
2008-03-20 22:45                               ` Rafael J. Wysocki
2008-03-20 23:01                                 ` Alan Stern
2008-03-20 23:22                                   ` Pavel Machek
2008-03-20 23:40                                     ` Rafael J. Wysocki
2008-03-21  0:36                                       ` Rafael J. Wysocki
2008-03-21  0:52                                       ` Alan Stern
2008-03-21 22:05                                         ` Nigel Cunningham
2008-03-22 16:21                                         ` Pavel Machek
2008-03-22 17:45                                           ` Rafael J. Wysocki
2008-03-22 20:49                                             ` Alan Stern
2008-03-22 21:29                                               ` Rafael J. Wysocki
2008-05-14 22:38                                                 ` Eric W. Biederman
2008-05-14 23:47                                                   ` Rafael J. Wysocki
2008-05-15 20:55                                                     ` Eric W. Biederman
2008-05-15 21:20                                                       ` Rafael J. Wysocki
2008-05-14 20:41                       ` Maxim Levitsky
2008-05-14 23:34                         ` Eric W. Biederman
2008-03-12  8:57       ` Pavel Machek
2008-03-12  0:00     ` Nigel Cunningham
2008-03-12  1:45   ` Huang, Ying
2008-03-12  2:17     ` Eric W. Biederman
2008-03-12  6:54       ` Huang, Ying
2008-03-12 19:37       ` Vivek Goyal
2008-03-14  8:03         ` Huang, Ying
2008-03-21 19:12           ` Vivek Goyal
2008-03-25  7:25             ` Huang, Ying
2008-03-12 19:47     ` Vivek Goyal
2008-04-09  9:34 ` Pavel Machek
2008-04-09 12:30   ` Vivek Goyal
2008-05-14 16:03 ` Vivek Goyal
2008-05-14 17:49   ` Vivek Goyal
2008-05-14 20:52 ` Vivek Goyal
2008-05-15  2:32   ` Huang, Ying
2008-05-15 20:09     ` Vivek Goyal
2008-05-16  1:48       ` Huang, Ying
2008-05-16  1:51         ` Vivek Goyal
2008-05-16  2:08           ` Huang, Ying
2008-05-16 12:13         ` Pavel Machek
2008-05-15  5:41   ` Huang, Ying
2008-05-15 18:42     ` Eric W. Biederman
2008-05-16  0:51     ` Vivek Goyal
2008-05-16  1:35       ` Eric W. Biederman
2008-05-16  1:55         ` Huang, Ying
2008-05-27  7:27       ` Huang, Ying
2008-05-27 22:15         ` Vivek Goyal [this message]
2008-05-28  1:35           ` Huang, Ying
2008-05-14 22:30 ` Eric W. Biederman
2008-05-14 23:55   ` Rafael J. Wysocki
2008-05-15 22:03     ` Eric W. Biederman
2008-05-15 23:20       ` Rafael J. Wysocki
2008-05-16 12:18       ` Pavel Machek
2008-05-16 14:20       ` [linux-pm] " Alan Stern
2008-05-15  1:42   ` Huang, Ying
2008-05-15 19:05     ` Rafael J. Wysocki
2008-05-15 14:14   ` [linux-pm] " Alan Stern
2008-05-15 20:48     ` Eric W. Biederman
2008-05-15 21:07       ` Alan Stern

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20080527221514.GA20037@redhat.com \
    --to=vgoyal@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=ebiederm@xmission.com \
    --cc=kexec@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@lists.linux-foundation.org \
    --cc=nigel@nigel.suspend2.net \
    --cc=pavel@ucw.cz \
    --cc=rjw@sisk.pl \
    --cc=ying.huang@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox