All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rusty Russell <rusty@rustcorp.com.au>
To: Jeremy Fitzhardinge <jeremy@goop.org>
Cc: Chris Wright <chrisw@sous-sol.org>,
	Virtualization Mailing List <virtualization@lists.osdl.org>
Subject: Re: rough sketch of revised patching infrastructure
Date: Thu, 22 Feb 2007 21:55:57 +1100	[thread overview]
Message-ID: <1172141757.13378.76.camel@localhost.localdomain> (raw)
In-Reply-To: <45DD6EF7.9060808@goop.org>

On Thu, 2007-02-22 at 02:22 -0800, Jeremy Fitzhardinge wrote:
> Rusty Russell wrote:
> > On Wed, 2007-02-21 at 18:09 -0800, Jeremy Fitzhardinge wrote:
> >   
> >> Here's the new patching patch.  It compiles, but it doesn't, you know,
> >> boot, as such.
> >>     
> >
> > OK, there are several separate things here.
> > (1) Get rid of the PARAVIRT_IRQ_DISABLE etc constants in favour of
> > offsetof within the structure.
> > (2) Change (almost) all the paravirt hooks to be patchable.
> > (3) Genericise the infrastructure to table-driven.
> >
> > These should probably become separate patches, in fact.
> >   
> 
> OK, here's something which is more presentable, and it even boots (at
> least under Xen; haven't tried native).
> 
> paravirt-patch-rename-paravirt_patch.patch

Great.

> paravirt-use-offset-site-ids.patch

Cool.

> paravirt-fix-clobbers.patch
>  - misc cleanups

Cool.

> paravirt-patchable-call-wrappers.patch
>  - wrap a large number of the paravirt calls with the magic to make the
> callsites patchable.  More are possible; this is just a good first step.

Ugly, but I originally played with alternatives for a long time and mine
were no prettier.

> paravirt-patch-machinery.patch
>  - the actual patching machinery, which is function-pointer driven
> rather than table driven now.

Not quite so sure on this one.  We loop through calling
paravirt_ops.patch() for each patch.  In the native case, this calls
paravirt_patcher with a fn pointer, which is simply called by
paravirt_patcher.

I would think you want to replace paravirt_patcher's patch == NULL case
with a special "paravity_patch_default", and then have to paravirt_ops
patch function call that specifically when it wants a default.

Also, I think you can leave the native table almost as-is, eg:

static const struct native_insns
{
       const char *start, *end;
} native_insns[] = {
       [PARAVIRT_PATCH(irq_disable)] = { start_cli, end_cli },
       [PARAVIRT_PATCH(irq_enable)] = { start_sti, end_sti },
...
};
static unsigned native_patch(u8 type, u16 clobbers, void *insns, unsigned len)
{
       unsigned int insn_len;

       /* Don't touch it if we don't have a replacement */
       if (type >= ARRAY_SIZE(native_insns) || !native_insns[type].start)
               return paravirt_patch_default(type, clobbers, insns, len);
       insn_len = native_insns[type].end - native_insns[type].start;

       /* Similarly if we can't fit replacement. */
       if (len < insn_len)
               return paravirt_patch_default(type, clobbers, insns, len);

       return paravirt_patch_insns(insns, len, native_insns[type].start, native_insns[type].end);
}

Actually, your paravirt_patch_insns has similar logic anyway, so this
code could collapse (it should fall back to paravirt_patch_default tho
IMHO).

Thanks for doing this work!
Rusty.

  reply	other threads:[~2007-02-22 10:55 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-02-22  2:09 rough sketch of revised patching infrastructure Jeremy Fitzhardinge
2007-02-22  3:43 ` Rusty Russell
2007-02-22 10:22   ` Jeremy Fitzhardinge
2007-02-22 10:55     ` Rusty Russell [this message]
2007-02-22 18:13       ` Jeremy Fitzhardinge
2007-02-22 22:14         ` Zachary Amsden
2007-02-22 22:49           ` Jeremy Fitzhardinge
2007-02-22 22:51         ` Ian Campbell
2007-02-22 22:54           ` Jeremy Fitzhardinge

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=1172141757.13378.76.camel@localhost.localdomain \
    --to=rusty@rustcorp.com.au \
    --cc=chrisw@sous-sol.org \
    --cc=jeremy@goop.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.