[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Dynamic Disassembling domU Instructions



Hi Jan,

Thank you for the insight. That explains a lot of the repeated cached instruction fetching.
This might belong to another thread, I was exploring xentrace, ran it with "sudo xentrace output", but it returns the message of "ERROR: Failed to map cpu buffer! (13 = Permission denied)", even running as root. Googled around but nothing insightful showed up, any suggestion would be appreciated.

Best,


On Thu, Jan 4, 2018 at 11:38 PM, Jan Beulich <JBeulich@xxxxxxxx> wrote:
>>> On 05.01.18 at 04:17, <manchonkuok@xxxxxxxxx> wrote:
> I am trying to modify Xen 4.8 to have it print out the opcode as well as
> some registers of an HVM domU as it runs. I tried to modify
> xen/arch/x86/hvm/emulate.c 's hvmemul_insn_fetch to output the content in
> hvmemul_ctxt->insn_buf with printk. In hvmemul_insn_fetch, it seems that a
> lot of the requested bytes are cached, does the domU's OS repeatedly calls
> the same instruction region over and over again?

No, but certain operations require going through the emulator
twice (e.g. once to formulate a request to qemu, and a second
time to process its response). It would be wrong to read guest
memory a second time in such a case.

You will also notice that after a completed emulation that cache
is being invalidated.

> Lastly, I am using printk to log the opcodes. Ideally I would want the
> opcode to be written to a separate file, but I read that it is not good to
> do any file access in kernel programming. Are there other alternatives or
> util functions that I should consider using?

xentrace would come to mind.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.