|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v2] mem_access: sanitize code around sending vm_event request
On Wed, Aug 3, 2016 at 8:41 AM, George Dunlap <george.dunlap@xxxxxxxxxx> wrote:
> On 01/08/16 17:52, Tamas K Lengyel wrote:
>> The two functions monitor_traps and mem_access_send_req duplicate some of the
>> same functionality. The mem_access_send_req however leaves a lot of the
>> standard vm_event fields to be filled by other functions.
>>
>> Remove mem_access_send_req() completely, making use of monitor_traps() to put
>> requests into the monitor ring. This in turn causes some cleanup around the
>> old callsites of mem_access_send_req(), and on ARM, the introduction of the
>> __p2m_mem_access_send_req() helper to fill in common mem_access information.
>> We also update monitor_traps to now include setting the common vcpu_id field
>> so that all other call-sites can ommit this step.
>>
>> Finally, this change identifies that errors from mem_access_send_req() were
>> never checked. As errors constitute a problem with the monitor ring,
>> crashing the domain is the most appropriate action to take.
>>
>> Signed-off-by: Tamas K Lengyel <tamas.lengyel@xxxxxxxxxxxx>
>> Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
>
> This appears to be v3, not v2?
No, it's still just v2.
>
>> diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
>> index 812dbf6..27f9d26 100644
>> --- a/xen/arch/x86/mm/p2m.c
>> +++ b/xen/arch/x86/mm/p2m.c
>> @@ -1728,13 +1728,8 @@ bool_t p2m_mem_access_check(paddr_t gpa, unsigned
>> long gla,
>> if ( req )
>> {
>> *req_ptr = req;
>> - req->reason = VM_EVENT_REASON_MEM_ACCESS;
>> -
>> - /* Pause the current VCPU */
>> - if ( p2ma != p2m_access_n2rwx )
>> - req->flags |= VM_EVENT_FLAG_VCPU_PAUSED;
>>
>> - /* Send request to mem event */
>> + req->reason = VM_EVENT_REASON_MEM_ACCESS;
>> req->u.mem_access.gfn = gfn;
>> req->u.mem_access.offset = gpa & ((1 << PAGE_SHIFT) - 1);
>> if ( npfec.gla_valid )
>> @@ -1750,23 +1745,10 @@ bool_t p2m_mem_access_check(paddr_t gpa, unsigned
>> long gla,
>> req->u.mem_access.flags |= npfec.read_access ? MEM_ACCESS_R : 0;
>> req->u.mem_access.flags |= npfec.write_access ? MEM_ACCESS_W : 0;
>> req->u.mem_access.flags |= npfec.insn_fetch ? MEM_ACCESS_X : 0;
>> - req->vcpu_id = v->vcpu_id;
>> -
>> - vm_event_fill_regs(req);
>> -
>> - if ( altp2m_active(v->domain) )
>> - {
>> - req->flags |= VM_EVENT_FLAG_ALTERNATE_P2M;
>> - req->altp2m_idx = vcpu_altp2m(v).p2midx;
>> - }
>> }
>>
>> - /* Pause the current VCPU */
>> - if ( p2ma != p2m_access_n2rwx )
>> - vm_event_vcpu_pause(v);
>> -
>> - /* VCPU may be paused, return whether we promoted automatically */
>> - return (p2ma == p2m_access_n2rwx);
>> + /* Return whether vCPU pause is required (aka. sync event) */
>> + return (p2ma != p2m_access_n2rwx);
>> }
>>
>> static inline
>
> p2m-bits:
>
> Acked-by: George Dunlap <george.dunlap@xxxxxxxxxx>
>
> But I agree with Julien -- this patch has several independent changes
> which makes it quite difficult to tell what's going on. I'm sure it's
> taken the two of us a lot more time together to figure out what is and
> is not happening than it would have for you to break it down into
> several little chunks.
>
> If you're not already familiar with it, I would recommend looking into
> stackgit. My modus operandi for things like this is to get things
> working in one big patch, then pop it off the stack and apply bits of it
> at a time to make a series.
>
> It's not only more considerate of your reviewers, but it's also a
> helpful exercise for yourself.
>
The extra work doesn't just come from splitting the code itself
(although I don't know which bits would really make sense to split
here that would worth the effort) but testing a series on various
platforms. As you are in the same boat that this should be multiple
patches (so it's 3v2) I have no problem just postponing the ARM
sanitization beside what's absolutely required at the moment. I'm
already looking at how to move the mem_accss code out of p2m on both
platforms so we don't have to end up in this loop in the future.
Thanks,
Tamas
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |