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

Re: [Xen-devel] Mem_event API and MEM_EVENT_REASON_SINGLESTEP


  • To: xen-devel@xxxxxxxxxxxxx
  • From: Razvan Cojocaru <rzvncj@xxxxxxxxx>
  • Date: Thu, 29 Nov 2012 18:20:27 +0200
  • Delivery-date: Thu, 29 Nov 2012 16:20:17 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xen.org>

Hello, thank you for the quick reply!
That might work for single-vcpu guests.  On multi-vcpu, you'd have to
pause the whole VM, unprotect the page, single-step the one vcpu that
trapped, re-protect the page, and unpause the VM.  That might be
unacceptably slow.

Ah, the simple fact that the words "unacceptably slow" could be employed to describe the situation makes this approach very unlikely to fit my purposes.

I'm still interested in how the debugger API works, though. Maybe, just maybe, it'll just be acceptably slow. :)

You could try:
  - pause the domain
  - copy out the contents of the page
  - use XENMEM_decrease_reservation to remove the page from the guest
  - unpause the domain

Then all accesses to that page will get emulated by Xen and forwarded to
qemu, just like happens for emulated MMIO devices.  In qemu, you can
emulate the read or write access, and do anything else you like at the
same time.

That won't work for memory that's accessed in non-trivial ways
(e.g. used for pagetables or descriptor tables) or using instructions
that are unsupported/buggy in Xen's instruction emulator.

Well, I need it to be able to work on _all_ memory, however accessed. Also, with this approach I might have to copy out the contents of all of the domain's pages in the worst case scenario - isn't that something to avoid?

Thanks,
Razvan Cojocaru

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

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