All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andi Kleen <ak@muc.de>
To: virtualization@lists.osdl.org
Cc: Rusty Russell <rusty@rustcorp.com.au>,
	Andrew Morton <akpm@osdl.org>, Chris Wright <chrisw@sous-sol.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 1/4] x86 paravirt_ops: create no_paravirt.h for native ops
Date: Mon, 7 Aug 2006 07:30:17 +0200	[thread overview]
Message-ID: <200608070730.17813.ak@muc.de> (raw)
In-Reply-To: <1154925835.21647.29.camel@localhost.localdomain>


> ===================================================================
> --- /dev/null
> +++ b/include/asm-i386/no_paravirt.h

I can't say I like the name. After all that should be the normal
case for a long time now ... native? normal? bareiron?

Also I would prefer if you split this file up a bit - the old
processor/system/irqflags split wasn't too bad.



> +
> +/*
> + * 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.



> +/* Stop speculative execution */
> +static inline void sync_core(void)
> +{
> +	unsigned int eax = 1, ebx, ecx, edx;
> +	__cpuid(&eax, &ebx, &ecx, &edx);
> +}

Actually I don't think this one should be para virtualized at all.
I don't see any reason at all why a hypervisor should trap it and it
is very time critical. I would recommend you move it back into the 
normal files without hooks.

> +
> +/*
> + * Clear and set 'TS' bit respectively
> + */

The comment seems out of date (no set TS)


> +#define clts() __asm__ __volatile__ ("clts")
> +#define read_cr0() ({ \
> +	unsigned int __dummy; \
> +	__asm__ __volatile__( \

Maybe it's just me, but can't you just drop all these __s around
asm and volatile? They are completely useless as far I know. 

Also the assembly will be easier readable if you just keep it on a single 
line for the simple ones.

-Andi

  parent reply	other threads:[~2006-08-07  5:30 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-08-07  4:43 [PATCH 1/4] x86 paravirt_ops: create no_paravirt.h for native ops Rusty Russell
2006-08-07  4:45 ` [PATCH 2/4] x86 paravirt_ops: paravirt_desc.h for native descriptor ops Rusty Russell
2006-08-07  4:45   ` Rusty Russell
2006-08-07  4:47   ` [PATCH 3/4] x86 paravirt_ops: implementation of paravirt_ops Rusty Russell
2006-08-07  4:47     ` Rusty Russell
2006-08-07  4:48     ` [PATCH 4/4] x86 paravirt_ops: binary patching infrastructure Rusty Russell
2006-08-07  4:48       ` Rusty Russell
2006-08-07  5:14       ` Rusty Russell
2006-08-07  5:38       ` Andi Kleen
2006-08-07  5:56         ` Jeremy Fitzhardinge
2006-08-07  5:56           ` Jeremy Fitzhardinge
2006-08-07  5:39     ` [PATCH 3/4] x86 paravirt_ops: implementation of paravirt_ops Andi Kleen
2006-08-07  5:56       ` Jeremy Fitzhardinge
2006-08-07  5:56         ` Jeremy Fitzhardinge
2006-08-07  6:13       ` Rusty Russell
2006-08-07  6:20         ` Andi Kleen
2006-08-07  6:20           ` Andi Kleen
2006-08-07  7:27           ` Rusty Russell
2006-08-07  5:40   ` [PATCH 2/4] x86 paravirt_ops: paravirt_desc.h for native descriptor ops Andi Kleen
2006-08-07  5:40     ` Andi Kleen
2006-08-07  7:50     ` Rusty Russell
2006-08-07  7:50       ` Rusty Russell
2006-08-07  8:53       ` Andi Kleen
2006-08-07 17:19         ` Dave Jones
2006-08-07 17:19           ` Dave Jones
2006-08-07  5:22 ` [PATCH 1/4] x86 paravirt_ops: create no_paravirt.h for native ops Jeremy Fitzhardinge
2006-08-07  5:30 ` Andi Kleen [this message]
2006-08-07  5:43   ` Jeremy Fitzhardinge
2006-08-07  6:02     ` Andi Kleen
2006-08-07  6:23       ` Jeremy Fitzhardinge
2006-08-07  6:03     ` Rusty Russell
2006-08-07  6:16       ` Andi Kleen
2006-08-07  6:04   ` Rusty Russell
2006-08-07  6:04     ` Rusty Russell
2006-08-07  6:17     ` Andi Kleen
2006-08-07  6:17       ` Andi Kleen
2006-08-07  6:27       ` Muli Ben-Yehuda
2006-08-07  6:27         ` Muli Ben-Yehuda
2006-08-07  7:34         ` Jan Engelhardt
2006-08-07  8:40           ` Muli Ben-Yehuda
2006-08-07  8:40             ` Muli Ben-Yehuda
2006-08-07 17:54             ` Jan Engelhardt
2006-08-07 17:54               ` Jan Engelhardt
2006-08-07 20:51     ` Zachary Amsden
2006-08-07 20:51       ` Zachary Amsden
2006-08-08  1:59       ` Andi Kleen
2006-08-08  1:59         ` Andi Kleen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200608070730.17813.ak@muc.de \
    --to=ak@muc.de \
    --cc=akpm@osdl.org \
    --cc=chrisw@sous-sol.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rusty@rustcorp.com.au \
    --cc=virtualization@lists.osdl.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.