lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <m11vp18xmp.fsf@fess.ebiederm.org>
Date:	Tue, 30 Jun 2009 10:00:46 -0700
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Gleb Natapov <gleb@...hat.com>
Cc:	Yinghai Lu <yhlu.kernel@...il.com>, linux-kernel@...r.kernel.org,
	Suresh Siddha <suresh.b.siddha@...el.com>,
	Sheng Yang <sheng@...ux.intel.com>,
	"kvm\@vger.kernel.org" <kvm@...r.kernel.org>,
	"avi\@redhat.com" <avi@...hat.com>
Subject: Re: [PATCH v4] enable x2APIC without interrupt remapping under KVM

Gleb Natapov <gleb@...hat.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.

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.

Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ