linux-kernel - Re: [PATCH] paravirt.h

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:	Wed, 23 Aug 2006 10:18:12 +0200
From:	Andi Kleen <ak@...e.de>
To:	Zachary Amsden <zach@...are.com>
Cc:	Arjan van de Ven <arjan@...radead.org>,
	virtualization@...ts.osdl.org,
	Jeremy Fitzhardinge <jeremy@...p.org>,
	Andrew Morton <akpm@...l.org>,
	Chris Wright <chrisw@...s-sol.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] paravirt.h

 
> Well, I don't think anything is sufficient for a preemptible kernel.  I 
> think that's just plain not going to work.  You could have a kernel 
> thread that got preempted in a paravirt-op patch point, and making all 
> the patch points non-preempt is probably a non-starter (either +12 bytes 
> each or no native inlining). 

stop machine deals with preemption.  If it didn't it would be unusable
for the purposes the kernel uses it right now (cpu hotplug, module unloading etc.)

> stop_machine_run() is almost what I want, but even that is not 
> sufficient.  You also need to disable NMIs and debug traps

and machine checks. debug traps -- i assume you mean kernel debuggers -- 
sounds like something that cannot be really controlled though.

How do you control a debugger from the debugee?

I don't think NMI/MCEs are a problem though because NMIs (at least oprofile/nmi watchdog) 
and MCEs all just have global state that can be changed on a single CPU.

> , which is  
> pretty hairy, but doable.  The problem with stop_machine_run() is that I 
> don't just want the kernel to halt running on remote CPUs, I want the 
> kernel on all CPUs to actually do something simultaneously - the entry 
> into paravirt mode requires a hypervisor call on each CPU, and 
> stop_machine() doesn't provide a facility to fire a callback on each CPU 
> from the stopmachine state.

Ok.

-Andi

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