linux-kernel - Re: [PATCH 1/4] x86 paravirt_ops: create no

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: <44D7A7E6.2060401@vmware.com>
Date:	Mon, 07 Aug 2006 13:51:50 -0700
From:	Zachary Amsden <zach@...are.com>
To:	Rusty Russell <rusty@...tcorp.com.au>
Cc:	Andi Kleen <ak@....de>, virtualization@...ts.osdl.org,
	Andrew Morton <akpm@...l.org>,
	Chris Wright <chrisw@...s-sol.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/4] x86 paravirt_ops: create no_paravirt.h for native
 ops

Rusty Russell wrote:
>>> +
>>> +/*
>>> + * Set IOPL bits in EFLAGS from given mask
>>> + */
>>> +static inline void set_iopl_mask(unsigned mask)
>>>       
>> This function can be completely written in C using local_save_flags()/local_restore_flags()
>> Please do that. I guess it's still a good idea to keep it separated
>> though because it might allow other optimizations.
>>
>> e.g. i've been thinking about special casing IF changes in save/restore flags 
>> to optimize CPUs which have slow pushf/popf. If you already make sure
>> all non IF manipulations of flags are separated that would help.
>>     

Actually, that is not quite true.  Local_save_flags / 
raw_local_irq_restore today is used only for operating on IF flag, and 
raw_local_restore_flags does not exist.  Our implementation of these in 
VMI assumes that only the IF flag is being changed, and this is the 
default assumption under which Xen runs as well.  Using local_restore to 
switch IOPL as well causes the extremely performance critical common 
case of pure IRQ restore to do potentially a lot more work in a hypervisor.

So if you do want us to go with the C approach, I would propose using 
raw_local_iopl_restore, which can make a different hypercall (actually, 
in our case, this is not even a hypercall, merely a VMI call).

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