From: Zachary Amsden <zach@vmware.com>
To: Rusty Russell <rusty@rustcorp.com.au>
Cc: Andrew Morton <akpm@osdl.org>, Andi Kleen <ak@muc.de>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Chris Wright <chrisw@sous-sol.org>,
virtualization@lists.osdl.org
Subject: Re: [PATCH 1/4] x86 paravirt_ops: create no_paravirt.h for native ops
Date: Mon, 07 Aug 2006 13:51:50 -0700 [thread overview]
Message-ID: <44D7A7E6.2060401@vmware.com> (raw)
In-Reply-To: <1154930669.7642.12.camel@localhost.localdomain>
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
WARNING: multiple messages have this Message-ID (diff)
From: Zachary Amsden <zach@vmware.com>
To: Rusty Russell <rusty@rustcorp.com.au>
Cc: Andi Kleen <ak@muc.de>,
virtualization@lists.osdl.org, 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, 07 Aug 2006 13:51:50 -0700 [thread overview]
Message-ID: <44D7A7E6.2060401@vmware.com> (raw)
In-Reply-To: <1154930669.7642.12.camel@localhost.localdomain>
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
next prev parent reply other threads:[~2006-08-07 20:51 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
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 [this message]
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=44D7A7E6.2060401@vmware.com \
--to=zach@vmware.com \
--cc=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.