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

Date:	Tue, 8 Aug 2006 03:59:12 +0200
From:	Andi Kleen <ak@....de>
To:	virtualization@...ts.osdl.org
Cc:	Zachary Amsden <zach@...are.com>,
	Rusty Russell <rusty@...tcorp.com.au>,
	Andrew Morton <akpm@...l.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Chris Wright <chrisw@...s-sol.org>
Subject: Re: [PATCH 1/4] x86 paravirt_ops: create no_paravirt.h for native ops

On Monday 07 August 2006 22:51, Zachary Amsden wrote:
> 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.  

Yes, sorry for the typo.

> 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).

I meant Rusty can use local restore in his native implementation.
The higher level interface can be different.

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