linux-kernel - Re: [PATCH v4] enable x2APIC without interrupt remapping under KVM

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] [day] [month] [year] [list]

Message-ID: <m1iqid34os.fsf@fess.ebiederm.org>
Date:	Tue, 30 Jun 2009 12:24:51 -0700
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Avi Kivity <avi@...hat.com>
Cc:	Gleb Natapov <gleb@...hat.com>, 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>
Subject: Re: [PATCH v4] enable x2APIC without interrupt remapping under KVM

Avi Kivity <avi@...hat.com> writes:

> So the jump-to-vector reset code cannot work on real hardware?  It works in
> qemu, but of course that's easy.

In general yes.  Nothing regularly uses that path so there is little
point adding a new users if we can avoid it.

Heck there are machines with unreliable cmos.

>> 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.
>>    
>
> I think it makes sense to add full reset support as a non-default option.
> Leaving hardware running and dmaing left and right has its risks.

It is easy enough to do that in user space in /sbin/kexec if that proves
useful for some reason.

As for the leaving hardware running and dmaing left and right.  You
are talking about the kexec on panic code path.  On a normal reboot
we do our darndest to cleanly shut everything down properly.

We avoid the dmaing left and right problem by reserving a chunk of
memory at boot time and we probably should be reserving a chunk
of the iommus as well for that purpose.

Hardware resets in general don't preserve the contents of memory.

In general the kexec on panic path is about teaching drivers to
initialize in the worst possible scenario and using those drivers
that can to get information out of the system.

At the same time 99% of the code that runs is in user space so
it should be easy to jump through whatever hoops make sense in
the user space component.  While keeping the kexec on panic code
path as slim as possible.

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/