[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Xen-devel] [RFC] x86/vm_event: Allow returning i-cache for emulation
- To: George Dunlap <george.dunlap@xxxxxxxxxx>
- From: Tamas Lengyel <tamas.lengyel@xxxxxxxxxxxx>
- Date: Mon, 12 Sep 2016 08:31:43 -0600
- Cc: Kevin Tian <kevin.tian@xxxxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Jan Beulich <jbeulich@xxxxxxxx>, Razvan Cojocaru <rcojocaru@xxxxxxxxxxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Julien Grall <julien.grall@xxxxxxx>, Paul Durrant <paul.durrant@xxxxxxxxxx>, Jun Nakajima <jun.nakajima@xxxxxxxxx>, Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>
- Delivery-date: Mon, 12 Sep 2016 14:31:49 +0000
- List-id: Xen developer discussion <xen-devel.lists.xen.org>
On Sep 12, 2016 08:17, "George Dunlap" <george.dunlap@xxxxxxxxxx> wrote:
>
> On 09/09/16 16:41, Tamas K Lengyel wrote:
> > When emulating instructions the emulator maintains a small i-cache fetched
> > from the guest memory. Under certain scenarios this memory region may contain
> > instructions that a monitor subscriber would prefer to hide, namely INT3, and
> > instead would prefer to emulate a different instruction in-place.
> >
> > This patch extends the vm_event interface to allow returning this i-cache via
> > the vm_event response.
>
> So do you have a problem right now with stale caches (i.e., you modify
> an INT3 back to something else in guest RAM but the emulator still
> emulates the INT3)? Or is the idea here that instead of doing the
> replace-singlestep-replace loop, you just tell the emulator, "Here,
> emulate this instead" (without removing the INT3 from guest memory at all)?
>
> (Or am I completely missing the point here?)
>
Hi George,
it's the latter! This would make tracing with int3s a bit more flexible on multi-vcpu guests as there would be no racecondition. I use altp2m right now to get around this problem but it's always good to have a backup in case altp2m is disabled.
Tamas
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel
|
