From: Jeremy Fitzhardinge <jeremy@goop.org>
To: Andi Kleen <ak@muc.de>
Cc: Andrew Morton <akpm@osdl.org>,
virtualization@lists.osdl.org,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Chris Wright <chrisw@sous-sol.org>
Subject: Re: [PATCH 3/4] x86 paravirt_ops: implementation of paravirt_ops
Date: Sun, 06 Aug 2006 22:56:30 -0700 [thread overview]
Message-ID: <44D6D60E.5080507@goop.org> (raw)
In-Reply-To: <200608070739.33428.ak@muc.de>
Andi Kleen wrote:
> On Monday 07 August 2006 06:47, Rusty Russell wrote:
>
>> This patch does the dumbest possible replacement of paravirtualized
>> instructions: calls through a "paravirt_ops" structure. Currently
>> these are function implementations of native hardware: hypervisors
>> will override the ops structure with their own variants.
>>
>
> You should call it HAL - that would make it clearer what it is.
>
I've always found the term "HAL" to be vague to the point of
meaningless. What would it mean in this case: "hypervisor abstraction
layer"? It certainly doesn't attempt abstract all hardware.
> I think I would prefer to patch always. Is there a particular
> reason you can't do that?
>
Some calls just don't need patching; an indirect call is fast enough,
and simple. But I can't think of a good reason to not patch patchable
calls, other than for debugging perhaps (easier to place one breakpoint
than one per inline site).
J
WARNING: multiple messages have this Message-ID (diff)
From: Jeremy Fitzhardinge <jeremy@goop.org>
To: Andi Kleen <ak@muc.de>
Cc: 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 3/4] x86 paravirt_ops: implementation of paravirt_ops
Date: Sun, 06 Aug 2006 22:56:30 -0700 [thread overview]
Message-ID: <44D6D60E.5080507@goop.org> (raw)
In-Reply-To: <200608070739.33428.ak@muc.de>
Andi Kleen wrote:
> On Monday 07 August 2006 06:47, Rusty Russell wrote:
>
>> This patch does the dumbest possible replacement of paravirtualized
>> instructions: calls through a "paravirt_ops" structure. Currently
>> these are function implementations of native hardware: hypervisors
>> will override the ops structure with their own variants.
>>
>
> You should call it HAL - that would make it clearer what it is.
>
I've always found the term "HAL" to be vague to the point of
meaningless. What would it mean in this case: "hypervisor abstraction
layer"? It certainly doesn't attempt abstract all hardware.
> I think I would prefer to patch always. Is there a particular
> reason you can't do that?
>
Some calls just don't need patching; an indirect call is fast enough,
and simple. But I can't think of a good reason to not patch patchable
calls, other than for debugging perhaps (easier to place one breakpoint
than one per inline site).
J
next prev parent reply other threads:[~2006-08-07 5:56 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 [this message]
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
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=44D6D60E.5080507@goop.org \
--to=jeremy@goop.org \
--cc=ak@muc.de \
--cc=akpm@osdl.org \
--cc=chrisw@sous-sol.org \
--cc=linux-kernel@vger.kernel.org \
--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.