linux-kernel - Re: [PATCH 00/11] x86: disable virt on kdump and emergency

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]

Date:	Mon, 17 Nov 2008 13:04:27 -0200
From:	Eduardo Habkost <ehabkost@...hat.com>
To:	Avi Kivity <avi@...hat.com>
Cc:	Ingo Molnar <mingo@...e.hu>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Simon Horman <horms@...ge.net.au>,
	Andrew Morton <akpm@...l.org>, Vivek Goyal <vgoyal@...hat.com>,
	Haren Myneni <hbabu@...ibm.com>,
	Andrey Borzenkov <arvidjaar@...l.ru>, mingo@...hat.com,
	"Rafael J. Wysocki" <rjw@...k.pl>,
	Zachary Amsden <zach@...are.com>, kexec@...ts.infradead.org,
	kvm@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 00/11] x86: disable virt on kdump and emergency_restart
	(v3)

On Sun, Nov 16, 2008 at 09:57:55AM +0200, Avi Kivity wrote:
> Eduardo Habkost wrote:
>> Hi,
>>
>> This is a new spin of the series to disable vmx on kdump and on
>> emergency_restart. Now we avoid doing the function pointer stuff by
>> moving 4 small KVM functions to a header, as inline functions. The code
>> looks much simpler now, but we have to be more careful because some
>> additional code will run on kdump and reboot even when KVM is never
>> loaded.
>>
>> I haven't tested the SVM changes on AMD CPUs. The changes are really
>> simple, but some testing is welcome.
>>
>> This series is against tip.git#master, that already contains the
>> nmi_shootdown_cpus() changes I've submitted previously.
>>
>>
>>   
>
> Looks good.  I am slightly uneasy about moving things away from vmx.h  
> and svm.h; can we keep them there and #include those headers directly?

I see them as bits of code that are being moved from KVM to the kernel
core. I think moving those bits outside arch/x86/kvm/ makes this more
clear: people can expect that code living in arch/x86/kvm/ is never
used if CONFIG_KVM was not set.

Because of their location, I thought svm.h and vmx.h had KVM-specific
code. Now I've noticed they are independent from KVM. May I move svm.h
and vmx.h to arch/x86/include/asm, then?

-- 
Eduardo
--
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/