[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Xen-devel] [PATCH v4] x86/vm_event: Allow overwriting Xen's i-cache used for emulation
- To: Razvan Cojocaru <rcojocaru@xxxxxxxxxxxxxxx>
- From: Tamas K Lengyel <tamas.lengyel@xxxxxxxxxxxx>
- Date: Mon, 26 Sep 2016 08:55:48 -0600
- Cc: "Tian, Kevin" <kevin.tian@xxxxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Jun Nakajima <jun.nakajima@xxxxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Julien Grall <julien.grall@xxxxxxx>, Paul Durrant <paul.durrant@xxxxxxxxxx>, Jan Beulich <JBeulich@xxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx
- Delivery-date: Mon, 26 Sep 2016 14:56:02 +0000
- List-id: Xen developer discussion <xen-devel.lists.xen.org>
On Sep 26, 2016 08:29, "Razvan Cojocaru" <rcojocaru@xxxxxxxxxxxxxxx> wrote:
>
> On 09/26/2016 01:33 PM, Jan Beulich wrote:
> >>>> On 22.09.16 at 20:54, <tamas.lengyel@xxxxxxxxxxxx> wrote:
> >> When emulating instructions Xen's emulator maintains a small i-cache fetched
> >> from the guest memory. This patch extends the vm_event interface to allow
> >> overwriting this i-cache via a buffer returned in the vm_event response.
> >>
> >> When responding to a SOFTWARE_BREAKPOINT event (INT3) the monitor subscriber
> >> normally has to remove the INT3 from memory - singlestep - place back INT3
> >> to allow the guest to continue execution. This routine however is
> >> susceptible
> >> to a race-condition on multi-vCPU guests. By allowing the subscriber to return
> >> the i-cache to be used for emulation it can side-step the problem by returning
> >> a clean buffer without the INT3 present.
> >>
> >> As part of this patch we rename hvm_mem_access_emulate_one to
> >> hvm_emulate_one_vm_event to better reflect that it is used in various
> >> vm_event
> >> scenarios now, not just in response to mem_access events.
> >>
> >> Signed-off-by: Tamas K Lengyel <tamas.lengyel@xxxxxxxxxxxx>
> >> Acked-by: Razvan Cojocaru <rcojocaru@xxxxxxxxxxxxxxx>
> >
> > Non-VM-event specific code:
> > Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>
> >
> > One question though:
> >
> >> --- a/xen/arch/x86/vm_event.c
> >> +++ b/xen/arch/x86/vm_event.c
> >> @@ -209,11 +209,20 @@ void vm_event_emulate_check(struct vcpu *v, vm_event_response_t *rsp)
> >> if ( p2m_mem_access_emulate_check(v, rsp) )
> >> {
> >> if ( rsp->flags & VM_EVENT_FLAG_SET_EMUL_READ_DATA )
> >> - v->arch.vm_event->emul_read_data = rsp->data.emul_read_data;
> >> + v->arch.vm_event->emul.read = rsp->data.emul.read;
> >>
> >> v->arch.vm_event->emulate_flags = rsp->flags;
> >> }
> >> break;
> >> +
> >> + case VM_EVENT_REASON_SOFTWARE_BREAKPOINT:
> >> + if ( rsp->flags & VM_EVENT_FLAG_SET_EMUL_INSN_DATA )
> >> + {
> >> + v->arch.vm_event->emul.insn = rsp->data.emul.insn;
> >> + v->arch.vm_event->emulate_flags = rsp->flags;
> >> + }
> >> + break;
> >
> > Is this intentionally different from the case above (where the setting
> > of ->emulate_flags is outside the inner if()?
Yes, it's intentional.
> Good point. The case below should follow suit of the one above unless
> there's a corner case Tamas is aware of that I'm missing. Otherwise, a
> comment would be nice to explain the difference (perhaps for
> VM_EVENT_REASON_SOFTWARE_BREAKPOINT only
> VM_EVENT_FLAG_SET_EMUL_INSN_DATA ever makes sense - never a simple
> emulation).
>
That's exactly the case here as the commit text explains. Emulating in response to an int3 event only makes sense if you return the insn buffer. I can add a comment to that effect if that helps, though I think it's pretty straight forward.
Tamas
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel
|