Re: [Xen-devel] [PATCH] vm_event: Rename MEM_ACCESS_EMULATE and MEM_ACCESS_EMULATE_NOWRITE

["Lengyel, Tamas" <tlengyel@xxxxxxxxxxx>]

> Now looking at this more closely - VM_EVENT_FLAG_EMULATE_NOWRITE doesn't
> get set on rsp->flags. As such, it would make sense to keep it as a
> separate define (simply VM_EVENT_EMULATE_NOWRITE?). IMHO VM_EVENT_FLAG_*
> defines should correspond to things set on the req/rsp->flags field.

It does get set, it's just not very obvious, but please see line 1468 below:

1417 void p2m_mem_access_emulate_check(struct vcpu *v,
1418                                   const vm_event_response_t *rsp)
1419 {
1420     /* Mark vcpu for skipping one instruction upon rescheduling. */
1421     if ( rsp->flags & MEM_ACCESS_EMULATE )
1422     {
1423         xenmem_access_t access;
1424         bool_t violation = 1;
1425         const struct vm_event_mem_access *data = ""> 1426
1427         if ( p2m_get_mem_access(v->domain, data->gfn, &access) == 0 )
1428         {
1429             switch ( access )
1430             {
1431             case XENMEM_access_n:
1432             case XENMEM_access_n2rwx:
1433             default:
1434                 violation = data->flags & MEM_ACCESS_RWX;
1435                 break;

[...]

1462             case XENMEM_access_rwx:
1463                 violation = 0;
1464                 break;
1465             }
1466         }
1467
1468         v->arch.vm_event.emulate_flags = violation ? rsp->flags : 0;
1469     }
1470 }

With the right conditions, v->arch.vm_event.emulate_flags is assigned
rsp->flags, which does have VM_EVENT_EMULATE_NOWRITE set quite a lot for
us. :)

Ah OK. Maybe we don't need to copy the entire rsp->flags, only the emulate related bits? But that's beyond the scope of this patch so:

Acked-by: Tamas K Lengyel <tlengyel@xxxxxxxxxxx>

 

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