[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 15:00:07 +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=zpululCJFR0WMrB7SSWewhlM0I1YhTEn6oaEJM61yEA=; b=n2H2YGD/JQx2LLgZ9JtW7LwfmyRmJt7IuT7yg5EySsQlVH4lsPpOrXsRM8vjbGOIpwhy/tvDj+ym3TdAxBdugvqAioryMZLRut40fOM/kOkldlGn+4zzNFeykAfHGcRP3Uz7dy6lHs+ZvM/E2PU7BSZbv0yqvynyLL4kjZJCLmk+6oKF+qRQsEcDHhDxqTcZ/etq2moeSnrQ4UjfqRKiD2RCvxGN04OakZrxLmB/y3k4tllQcyXo16dRFvOH9g88fUC6azJfthB8vy8XRBKAvq9zKpLDv6LM8fqh5NRjC6YU2QD8mtkvlBsfjTnlhYR1CYea+21YR4Acr9K4Q6SF/w==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=SLQj9T2CCDAGP3YVEvDu1WXexCov2HUAtkm2xaNoSVdPME/f35Aw5a5z/OfjXPvUzbyFurBut90p1PQMKNl33IF+yC09OOBzWjDYwUP48nNDl7EHTFwSKQisd4mnwQ1ESDg7Iz684sAGBoMxUgxI8cfS7TiCAUGSxxAUC5eD2a7secCG96bPkzZNfw89anuz4c212Wh3Ehcih2vuzyjaS83swmf/MsT/0LvdAPX1LSwL2QddWlG/QGqvtt1tw/OcAajPHVkdtMMZScNQMwwo8V1ISGW+PYzBk4OSAtPf/Z0NjDdudCVT6GYwhcOWETTVhZXBCmbMc3uh7bKw/m0IIQ==
  • 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 15:00:12 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Thread-index: AQHVbGY5LYraxeTPu06yM6Qe3Haip6cudlQAgAEKjgCAAATfAIAAl0IA///TxQCAAAeXAA==
  • Thread-topic: [Xen-devel] [PATCH v10] x86/emulate: Send vm_event from emulate


On 17.09.2019 17:32, Jan Beulich wrote:
> On 17.09.2019 16:11, Alexandru Stefan ISAILA wrote:
>>
>>
>> On 17.09.2019 11:09, Jan Beulich wrote:
>>> On 17.09.2019 09:52, Alexandru Stefan ISAILA wrote:
>>>> 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
>>>>      */"
>>>
>>> First of all - why "was sent"? The event is yet to be sent, isn't it?
>>
>> Yes it should state "if the event is sent".
> 
> "is sent" is still not indicating this is something yet to happen.
> "is to be sent" would be to me (caveat - I'm not a native speaker).
> 
>>> And then I'm afraid this still isn't enough. __hvm_copy() gets used
>>> for many purposes. For example, while looking into this again when
>>> preparing the reply here, I've noticed that above you may wrongly
>>> call hvm_monitor_check_p2m() with npfec_kind_with_gla - there's no
>>> linear address when HVMCOPY_linear is not set. If, while putting
>>
>> You are right, a check for HVMCOPY_linear should go in the if so we are
>> sure that it is called with a linear address only.
>>
>>> together what the comment needs to explain (i.e. everything that
>>> can't be implied from the code you add), you considered all cases
>>> you should have noticed this yourself.
>>
>> With this new check in place (HVMCOPY_linear) __hvm_copy() will be
>> called from linear_read() linear_write() where it will pass down
>> X86EMUL_RETRY.
>>
>> The comment can change to:
>> "If a event is sent return paged_out. The emulation will have no side
>> effect and will return X86EMUL_RETRY"
> 
> I'm sorry to be a pain in your neck, but no, this still is not
> sufficient imo. The comment, whatever wording you choose,
> should make clear that you have understood the possible effects
> of using a suspicious return value, and it should also make
> clear to readers that this is in fact not going to cause a
> problem _for any caller_.
> 

There is no problem, I understand the risk of having suspicious return 
values. I am not hanged on having this return. I used this to skip 
adding a new return value. I can do this if we agree on a suitable name 
for a new return value in enum hvm_translation_result. I can propose 
HVMTRANS_bad_gfn_access.

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®.