From: sonny <sonny@burdell.org>
To: Hollis Blanchard <hollisb@us.ibm.com>
Cc: linuxppc-dev <linuxppc-dev@ozlabs.org>,
kvm-ppc <kvm-ppc@vger.kernel.org>
Subject: Re: [RFC] a little disassembly infrastructure
Date: Fri, 24 Oct 2008 22:13:53 +0000 [thread overview]
Message-ID: <490248A1.6080004@burdell.org> (raw)
In-Reply-To: <1224867546.9634.42.camel@localhost.localdomain>
Hollis Blanchard wrote:
> Hi, I wrote this patch for KVM [1], but now that I look closer it seems
> like there might be some overlapping functionality.
>
> First there's emulate_instruction(), but since that only handles a few
> instructions it's just an ordered list of if ((instruction & MASK_A) =
> INST_A) tests, so it doesn't actually parse out opcodes or anything.
>
> I've also found xmon's ppc-opc.c. That parses the opcode and operands,
> so could use some shared macros. Of course, the actual lookup isn't
> time-sensitive, so that doesn't make sense to share. On the other hand,
> if we do come up with something fast *and* robust for KVM, maybe xmon
> could use that.
>
> Of course, these macros alone is pretty small, so maybe it's not a big
> deal to make a kvm-specific copy of them, leaving the other uses alone.
>
> Comments?
>
> [1] KVM on PowerPC traps when privileged instructions are executed in
> the guest context. We must then (quickly!) disassemble them and emulate
> their behavior. Right now we do this with a giant switch statement or
> two, but are considering more sophisticated techniques in the future.
>
Yeah, personally I like this change. I was looking at emulating some
PPC instructions in a driver and based on inspection I was going to use
the code you had in for KVM. Having these macros in a generic header is
a "Good Thing" IMHO. I think we should have a generic disassembly
infrastructure and use that everywhere.
WARNING: multiple messages have this Message-ID (diff)
From: sonny <sonny@burdell.org>
To: Hollis Blanchard <hollisb@us.ibm.com>
Cc: linuxppc-dev <linuxppc-dev@ozlabs.org>,
kvm-ppc <kvm-ppc@vger.kernel.org>
Subject: Re: [RFC] a little disassembly infrastructure
Date: Fri, 24 Oct 2008 17:13:53 -0500 [thread overview]
Message-ID: <490248A1.6080004@burdell.org> (raw)
In-Reply-To: <1224867546.9634.42.camel@localhost.localdomain>
Hollis Blanchard wrote:
> Hi, I wrote this patch for KVM [1], but now that I look closer it seems
> like there might be some overlapping functionality.
>
> First there's emulate_instruction(), but since that only handles a few
> instructions it's just an ordered list of if ((instruction & MASK_A) ==
> INST_A) tests, so it doesn't actually parse out opcodes or anything.
>
> I've also found xmon's ppc-opc.c. That parses the opcode and operands,
> so could use some shared macros. Of course, the actual lookup isn't
> time-sensitive, so that doesn't make sense to share. On the other hand,
> if we do come up with something fast *and* robust for KVM, maybe xmon
> could use that.
>
> Of course, these macros alone is pretty small, so maybe it's not a big
> deal to make a kvm-specific copy of them, leaving the other uses alone.
>
> Comments?
>
> [1] KVM on PowerPC traps when privileged instructions are executed in
> the guest context. We must then (quickly!) disassemble them and emulate
> their behavior. Right now we do this with a giant switch statement or
> two, but are considering more sophisticated techniques in the future.
>
Yeah, personally I like this change. I was looking at emulating some
PPC instructions in a driver and based on inspection I was going to use
the code you had in for KVM. Having these macros in a generic header is
a "Good Thing" IMHO. I think we should have a generic disassembly
infrastructure and use that everywhere.
next prev parent reply other threads:[~2008-10-24 22:13 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-10-24 16:59 [RFC] a little disassembly infrastructure Hollis Blanchard
2008-10-24 16:59 ` Hollis Blanchard
2008-10-24 22:13 ` sonny [this message]
2008-10-24 22:13 ` sonny
2008-10-25 2:55 ` Paul Mackerras
2008-10-25 2:55 ` Paul Mackerras
2008-10-31 17:20 ` Hollis Blanchard
2008-10-31 17:20 ` Hollis Blanchard
2008-11-03 20:12 ` Hollis Blanchard
2008-11-03 20:12 ` Hollis Blanchard
2008-11-03 20:44 ` Paul Mackerras
2008-11-03 20:44 ` Paul Mackerras
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=490248A1.6080004@burdell.org \
--to=sonny@burdell.org \
--cc=hollisb@us.ibm.com \
--cc=kvm-ppc@vger.kernel.org \
--cc=linuxppc-dev@ozlabs.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.