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

Re: [Xen-devel] [PATCH v10] x86/emulate: Send vm_event from emulate


  • To: Jan Beulich <jbeulich@xxxxxxxx>
  • From: Alexandru Stefan ISAILA <aisaila@xxxxxxxxxxxxxxx>
  • Date: Tue, 17 Sep 2019 07:52:26 +0000
  • Accept-language: en-US
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=bitdefender.com; dmarc=pass action=none header.from=bitdefender.com; dkim=pass header.d=bitdefender.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=iRAoFVeBKN++g8Jlc17Dy90Kj1cTAJ9rw1JZHXt/OOQ=; b=guiSiR49Q8OhuK76+uH4svGCQxWWrHtk7ahq1smhEWrvX4GkkdeLKV3fdNBQ2aSgPWBvJwrSMGdXBjHDwPqAspQs5SqTN6ikeCxv+22QC47rUMafAsAgqXhyvC6M8bDS34KGPwUbctrtRgbIW6z4OdAs5lyqPIqxES0MKSwCfv8mrH/Hs2hobPW+HEn4CfM1QbCdc6BO99KeHWjD9JoygBZYkM3KQBv/BemAliOxtXbI0BpckFgq4kyalKkyczp5xlB/wHO0rjFW7T4+x2dpejNbDasUDCL3/rDciY0R0demCvPGTCEuKwaAuzd/pDsjMuz7txi9g2vDyQ4AGuiO6w==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=PilODW9ULJn9gOlle8LQJOExsoAfTf1NHv2PwuJascPafSBi3WpgqGOJGJtUFl+1ybWpYz9hvZmLDh0j21NuXj7ZcjaA3ccBBtbBggAWWcPfA6HVR8An4ot0GIRCHjyDUWoHSatYcbor5/phFTGY/dbjAev/phVk3QxCM2pDlMLsDQGg0gdVvIYn5ByZT9fE4H7L+IcBpHZ8ZWq8weunQB5hxTb+MxGbQojmjTzAu66DqwHNhZ6ru+RFSMPVzHgm4fw29GivZKWH6Lng9kvOfpTRdm4gK9QGuQI0U7wA5JmJyTDh5nBtVM/hlObtZVd3b+muEn4EI2XD+AJt29N2Yw==
  • Authentication-results: spf=none (sender IP is ) smtp.mailfrom=aisaila@xxxxxxxxxxxxxxx;
  • Cc: Petre Ovidiu PIRCALABU <ppircalabu@xxxxxxxxxxxxxxx>, "tamas@xxxxxxxxxxxxx" <tamas@xxxxxxxxxxxxx>, "wl@xxxxxxx" <wl@xxxxxxx>, Razvan COJOCARU <rcojocaru@xxxxxxxxxxxxxxx>, "george.dunlap@xxxxxxxxxxxxx" <george.dunlap@xxxxxxxxxxxxx>, "andrew.cooper3@xxxxxxxxxx" <andrew.cooper3@xxxxxxxxxx>, "paul.durrant@xxxxxxxxxx" <paul.durrant@xxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, "roger.pau@xxxxxxxxxx" <roger.pau@xxxxxxxxxx>
  • Delivery-date: Tue, 17 Sep 2019 07:52:39 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Thread-index: AQHVbGY5LYraxeTPu06yM6Qe3Haip6cudlQAgAEKjgA=
  • Thread-topic: [PATCH v10] x86/emulate: Send vm_event from emulate


On 16.09.2019 18:58, Jan Beulich wrote:
> On 16.09.2019 10:10, Alexandru Stefan ISAILA wrote:
>> --- a/xen/arch/x86/hvm/hvm.c
>> +++ b/xen/arch/x86/hvm/hvm.c
>> @@ -3224,6 +3224,14 @@ static enum hvm_translation_result __hvm_copy(
>>               return HVMTRANS_bad_gfn_to_mfn;
>>           }
>>   
>> +        if ( unlikely(v->arch.vm_event) &&
>> +             v->arch.vm_event->send_event &&
>> +             hvm_monitor_check_p2m(addr, gfn, pfec, npfec_kind_with_gla) )
>> +        {
>> +            put_page(page);
>> +            return HVMTRANS_gfn_paged_out;
> 
> I'm sorry, but there is _still_ no comment next to this apparent
> mis-use of HVMTRANS_gfn_paged_out.

I will add this comment here:

"/*
   * In case a vm event was sent return paged_out so the emulation will
   * stop with no side effect
   */"


> 
>> @@ -215,6 +217,79 @@ void hvm_monitor_interrupt(unsigned int vector, 
>> unsigned int type,
>>       monitor_traps(current, 1, &req);
>>   }
>>   
>> +/*
>> + * Send memory access vm_events based on pfec. Returns true if the event was
>> + * sent and false for p2m_get_mem_access() error, no violation and event 
>> send
>> + * error. Assumes the caller will check arch.vm_event->send_event.
>> + *
>> + * NOTE: p2m_get_mem_access() can fail if the entry was not found in the EPT
>> + * (in which case access to it is unrestricted, so no violations can occur).
>> + * In this cases it is fine to continue the emulation.
>> + */
> 
> I think this part of the comment would better go ...
> 
>> +bool hvm_monitor_check_p2m(unsigned long gla, gfn_t gfn, uint32_t pfec,
>> +                           uint16_t kind)
>> +{
>> +    xenmem_access_t access;
>> +    vm_event_request_t req = {};
>> +    paddr_t gpa = (gfn_to_gaddr(gfn) | (gla & ~PAGE_MASK));
>> +
>> +    ASSERT(current->arch.vm_event->send_event);
>> +
>> +    current->arch.vm_event->send_event = false;
>> +
>> +    if ( p2m_get_mem_access(current->domain, gfn, &access,
>> +                            altp2m_vcpu_idx(current)) != 0 )
>> +        return false;
> 
> ... next to the call here (but the maintainers of the file would
> have to judge in the end). That said, I continue to not understand
> why a not found entry means unrestricted access. Isn't it
> ->default_access which controls what such a "virtual" entry would
> permit?

I'm sorry for this misleading comment. The code states that if entry was 
not found the access will be default_access and return 0. So in this 
case the default_access will be checked.

/* If request to get default access. */
if ( gfn_eq(gfn, INVALID_GFN) )
{
     *access = memaccess[p2m->default_access];
     return 0;
}

If this clears thing up I can remove the "NOTE" part if the comment.


> 
>> +    switch ( access )
>> +    {
>> +    case XENMEM_access_x:
>> +    case XENMEM_access_rx:
>> +        if ( pfec & PFEC_write_access )
>> +            req.u.mem_access.flags = MEM_ACCESS_R | MEM_ACCESS_W;
>> +        break;
>> +
>> +    case XENMEM_access_w:
>> +    case XENMEM_access_rw:
>> +        if ( pfec & PFEC_insn_fetch )
>> +            req.u.mem_access.flags = MEM_ACCESS_X;
>> +        break;
>> +
>> +    case XENMEM_access_r:
>> +    case XENMEM_access_n:
>> +        if ( pfec & PFEC_write_access )
>> +            req.u.mem_access.flags |= MEM_ACCESS_R | MEM_ACCESS_W;
>> +        if ( pfec & PFEC_insn_fetch )
>> +            req.u.mem_access.flags |= MEM_ACCESS_X;
>> +        break;
>> +
>> +    case XENMEM_access_wx:
>> +    case XENMEM_access_rwx:
>> +    case XENMEM_access_rx2rw:
>> +    case XENMEM_access_n2rwx:
>> +    case XENMEM_access_default:
>> +        break;
>> +    }
>> +
>> +    if ( !req.u.mem_access.flags )
>> +        return false; /* no violation */
>> +
>> +    if ( kind == npfec_kind_with_gla )
>> +        req.u.mem_access.flags |= MEM_ACCESS_FAULT_WITH_GLA |
>> +                                  MEM_ACCESS_GLA_VALID;
>> +    else if ( kind == npfec_kind_in_gpt )
>> +        req.u.mem_access.flags |= MEM_ACCESS_FAULT_IN_GPT |
>> +                                  MEM_ACCESS_GLA_VALID;
>> +
>> +
>> +    req.reason = VM_EVENT_REASON_MEM_ACCESS;
>> +    req.u.mem_access.gfn = gfn_x(gfn);
>> +    req.u.mem_access.gla = gla;
>> +    req.u.mem_access.offset = gpa & ~PAGE_MASK;
>> +
>> +    return monitor_traps(current, true, &req) >= 0;
>> +}
> 
> There are quite a few uses of "current" in here - please consider
> latching into a local variable named "curr".

I will add a local variable here.

Thanks,
Alex
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel

 


Rackspace

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