From: Gleb Natapov <gleb@redhat.com>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Yinghai Lu <yhlu.kernel@gmail.com>,
linux-kernel@vger.kernel.org,
Suresh Siddha <suresh.b.siddha@intel.com>,
Sheng Yang <sheng@linux.intel.com>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
"avi@redhat.com" <avi@redhat.com>
Subject: Re: [PATCH v4] enable x2APIC without interrupt remapping under KVM
Date: Tue, 30 Jun 2009 22:15:45 +0300 [thread overview]
Message-ID: <20090630191545.GF8122@redhat.com> (raw)
In-Reply-To: <m11vp18xmp.fsf@fess.ebiederm.org>
On Tue, Jun 30, 2009 at 10:00:46AM -0700, Eric W. Biederman wrote:
> Gleb Natapov <gleb@redhat.com> writes:
>
> > On Tue, Jun 30, 2009 at 12:18:19AM -0700, Yinghai Lu wrote:
> >> how about kexec second kernel in KVM ?
> >>
> >> x2apic_preenabled will be set in second kernel.
> >>
> > By the way anybody knows why kexec does not use BIOS reset code
> > (cmos 0xf offset) to jump into new kernel after hard reset?
>
> After a hard reset. That simply isn't possible. A hard
> reset clears everything even memory.
>
I mean "soft reset". At least on 286 in order to move from protected
mode to real mode "soft reset" was issued via kbd controller or via
triple fault. BIOS reset code was used to avoid POST. Obviously back
than this kind of reset haven't cleared memory. I'll try to check what
happens on a modern HW.
BTW Linux sets BIOS reset code to "return by long jump" in
smpboot_setup_warm_reset() for some reason.
> You might be able to get a full cpu reset but not a reset of the I/O
> devices.
>
> The premise of kexec is that we are doing things on our own, and don't
> get a 3rd piece of software involved that has not been heavily tested
> on the path we want to use. Occassionally it is a pain to do everything
> ourselves but at least when we do and we test it we know it is going
> to work.
>
> Cpu designers lately seem fond of adding features that require all
> kind of coordination to turn on and off. We handle the hardware
> virtualization mode features now, and if x2apic has similar problems
> being turned on and off I am certain we can handle that case in a
> similar fashion.
>
> When we can my preference is to keep code like that out of the
> kexec on panic path if we can figure out how to write the software
> to do something reasonable.
>
> Once we figure out how to work without putting the interrupt controllers
> in legacy mode to handle the timer interrupts I expect all kinds of
> things will become simpler.
>
If the "soft reset" method can work it worth to implemented. I am not
suggesting we should make it default (just line --real-mode is not default).
--
Gleb.
next prev parent reply other threads:[~2009-06-30 19:15 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-06-30 6:45 [PATCH v4] enable x2APIC without interrupt remapping under KVM Gleb Natapov
2009-06-30 7:18 ` Yinghai Lu
2009-06-30 7:54 ` Gleb Natapov
2009-06-30 18:43 ` Yinghai Lu
2009-06-30 18:53 ` Gleb Natapov
2009-06-30 15:58 ` Gleb Natapov
2009-06-30 17:00 ` Eric W. Biederman
2009-06-30 17:14 ` Avi Kivity
2009-06-30 19:24 ` Eric W. Biederman
2009-06-30 19:15 ` Gleb Natapov [this message]
2009-06-30 17:15 ` Eric W. Biederman
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=20090630191545.GF8122@redhat.com \
--to=gleb@redhat.com \
--cc=avi@redhat.com \
--cc=ebiederm@xmission.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=sheng@linux.intel.com \
--cc=suresh.b.siddha@intel.com \
--cc=yhlu.kernel@gmail.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