From patchwork Mon Nov 7 14:34:08 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Razvan Cojocaru X-Patchwork-Id: 9415325 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 99F2160512 for ; Mon, 7 Nov 2016 14:36:17 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 826B628BB7 for ; Mon, 7 Nov 2016 14:36:17 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 7658B28BBF; Mon, 7 Nov 2016 14:36:17 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.2 required=2.0 tests=BAYES_00, RCVD_IN_DNSWL_MED autolearn=ham version=3.3.1 Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id 0BAE328BB7 for ; Mon, 7 Nov 2016 14:36:16 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1c3kzi-00079T-7b; Mon, 07 Nov 2016 14:33:54 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1c3kzh-00079N-AQ for xen-devel@lists.xenproject.org; Mon, 07 Nov 2016 14:33:53 +0000 Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id CC/7B-26755-0D090285; Mon, 07 Nov 2016 14:33:52 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrCIsWRWlGSWpSXmKPExsUSfTxjoe75CQo RBp8+GFl83zKZyYHR4/CHKywBjFGsmXlJ+RUJrBkzjp1lLZijVHFuTzdTA+NU6S5GTg4hAXeJ 06euM3UxcgHZaxglNh6aywbh3GGUuHihjbWLkQPIcZPY/kgaIr6QUeJEy3t2kG5hAWOJBVdfs YDYIgLKEr2/frNAFN1nl+j8M4MVxGEWOMMoseTZZzaQKjYBQ4nVG1vAbF4BJ4lzMx6C2SwCKh LdX88zgtiiAuES72cthKoRlDg58wnYBk4Be4kVJ66BxZkF9CR2XP/FCmHLS2x/O4cZxJYQyJF oX/qFEeRqCQEpif+tSiA3SAhsY5Fom/SfCaJGRuLRxJtsExhFZyFZMQvJ2FlIxi5gZF7FqF6c WlSWWqRrqJdUlJmeUZKbmJmja2hgrJebWlycmJ6ak5hUrJecn7uJERgbDECwg3H5R6dDjJIcT EqivFdjFSKE+JLyUyozEosz4otKc1KLDzHKcHAoSfAe6gfKCRalpqdWpGXmAKMUJi3BwaMkwn sUJM1bXJCYW5yZDpE6xagoJc4bAJIQAElklObBtcESwyVGWSlhXkagQ4R4ClKLcjNLUOVfMYp zMCoJ89qATOHJzCuBm/4KaDET0OKqGLDFJYkIKakGxp5E9kDers351ffX2QbcetT+LPTUROWN PCfW9Jxanb1m1RuVK6VGzHL1FrU7Fj107S1y7LrzaO3CpTHRL82fv7meeeJIpsbn93/P9RzbV 7BsZcq+QtNCd+dFR9wYH2wUd/ngE890nvO4h8zDngKL8ENev9/yPZ36gevZDEGedAaR3CN35/ 5UqFZiKc5INNRiLipOBAAbHlHIBwMAAA== X-Env-Sender: rcojocaru@bitdefender.com X-Msg-Ref: server-7.tower-31.messagelabs.com!1478529231!62060461!1 X-Originating-IP: [91.199.104.161] X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG X-StarScan-Received: X-StarScan-Version: 9.0.13; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21703 invoked from network); 7 Nov 2016 14:33:51 -0000 Received: from mx01.bbu.dsd.mx.bitdefender.com (HELO mx01.bbu.dsd.mx.bitdefender.com) (91.199.104.161) by server-7.tower-31.messagelabs.com with DHE-RSA-AES128-GCM-SHA256 encrypted SMTP; 7 Nov 2016 14:33:51 -0000 Received: (qmail 15516 invoked from network); 7 Nov 2016 16:33:50 +0200 Received: from unknown (HELO mx-sr.buh.bitdefender.com) (10.17.80.103) by mx01.bbu.dsd.mx.bitdefender.com with AES256-GCM-SHA384 encrypted SMTP; 7 Nov 2016 16:33:50 +0200 Received: from smtp02.buh.bitdefender.net (smtp.bitdefender.biz [10.17.80.76]) by mx-sr.buh.bitdefender.com (Postfix) with ESMTP id C47BC7FC05 for ; Mon, 7 Nov 2016 16:33:49 +0200 (EET) Received: (qmail 1678 invoked from network); 7 Nov 2016 16:33:49 +0200 Received: from rcojocaru.dsd.ro (HELO ?10.10.14.59?) (rcojocaru@bitdefender.com@10.10.14.59) by smtp02.buh.bitdefender.net with SMTP; 7 Nov 2016 16:33:49 +0200 To: Jan Beulich References: <56bd0939-976b-ef45-4182-60e65c2f3ddc@bitdefender.com> <58186EB702000078000F25A0@prv-mh.provo.novell.com> <0837744b-5fc6-0f8e-1c68-592ab8f1369f@bitdefender.com> <5818BA8502000078000F25E7@prv-mh.provo.novell.com> <5818C56E02000078000F263B@prv-mh.provo.novell.com> <14c80cc5-8338-bb29-7981-5851db27cd69@bitdefender.com> <58204D50020000780011C945@prv-mh.provo.novell.com> <58205E37020000780011C9A1@prv-mh.provo.novell.com> <3d1c2cac-5a73-4397-a1dd-286ed8b34fc3@bitdefender.com> <5820805B020000780011CA75@prv-mh.provo.novell.com> <58208DA2020000780011CB2A@prv-mh.provo.novell.com> <5820956A020000780011CB5B@prv-mh.provo.novell.com> From: Razvan Cojocaru Message-ID: <6430868f-6eb8-5c07-3a79-6f94101ca600@bitdefender.com> Date: Mon, 7 Nov 2016 16:34:08 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <5820956A020000780011CB5B@prv-mh.provo.novell.com> X-BitDefender-Scanner: Clean, Agent: BitDefender qmail 3.1.6 on smtp02.buh.bitdefender.net, sigver: 7.67921 X-BitDefender-Spam: No (0) X-BitDefender-SpamStamp: Build: [Engines: 2.15.6.911, Dats: 434673, Stamp: 3], Multi: [Enabled, t: (0.000011, 0.004188)], BW: [Enabled, t: (0.000007,0.000001)], RBL DNSBL: [Disabled], APM: [Enabled, Score: 500, t: (0.004196), Flags: 85D2ED72; NN_FORGED_THUNDERBIRD_2; NN_BEST_SOL_ADN; NN_LEGIT_VALID_REPLY; NN_LEGIT_SUMM_400_WORDS; NN_NO_LINK_NMD; NN_LEGIT_BITDEFENDER; NN_LEGIT_S_SQARE_BRACKETS], SGN: [Enabled, t: (0.007289)], URL: [Enabled, t: (0.000005)], RTDA: [Enabled, t: (0.019798), Hit: No, Details: v2.4.0; Id: 2m1gheo.1b0r0aub6.vin7], total: 0(775) X-BitDefender-CF-Stamp: none Cc: Andrew Cooper , Andrei Vlad LUTAS , "tamas@tklengyel.com" , "xen-devel@lists.xenproject.org" Subject: Re: [Xen-devel] xc_hvm_inject_trap() races X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xen.org Sender: "Xen-devel" X-Virus-Scanned: ClamAV using ClamSMTP On 11/07/2016 03:53 PM, Jan Beulich wrote: >>>> On 07.11.16 at 14:44, wrote: >> On 11/07/2016 03:20 PM, Jan Beulich wrote: >>>>>> On 07.11.16 at 13:27, wrote: >>>> On 11/07/2016 02:23 PM, Jan Beulich wrote: >>>>>> At this point it looks like the best solution is to simply discard the >>>>>>> non-architectural event if there's a pending architectural one, and add >>>>>>> a new vm_event, as suggested by Tamas, that notifies the application >>>>>>> that a trap has failed, or succeeded, and let it do the best it can with >>>>>>> that information. >>>>> Well, if the two of you think this is something which fits into the VM >>>>> event model, then I guess that's an option. I, for one, am not >>>>> convinced: It simply seems too special purpose. If this was a more >>>>> generic event ("interruption delivered", perhaps with a type or >>>>> vector qualifier) that can be subscribed to, and the app did that >>>>> only for such transient periods of time, this would look more >>>>> reasonable to me. >>>> >>>> Indeed, that's the way I think of it: the user is free to subscribe to >>>> the event or not, and the event is: >>>> >>>> struct vm_event_injection_result { >>>> uint32_t vector; >>>> uint32_t type; >>>> uint32_t error_code; >>>> uint64_t cr2; >>>> uint32_t injected; >>>> }; >>>> >>>> with injected 0 for failure and 1 for success. It's as generic as possible. >>> >>> Wait, no, that's not what I did describe. I'm not talking about the >>> "result" of an injection (through hypercall), but about delivering of >>> events (of any origin). Hence there can't be any "failure" here. >>> IOW what I'm proposing is a "VM is about to see this interruption" >>> event. >> >> But a a success-only event is hard to interpret with regards to failure, >> which is what we're really interested in (specifically, failure to >> inject via hypercall). Do we count it as a failure if we don't receive a >> "VM is about to see this interruption" event immediately after the >> vm_event that caused the injection, on the same processor, with the same >> trap vector? That's a tricky commitment to make. > > If you subscribed to all interruptions, you'd simply see one next > which is different from the one you've tried to inject. > >> That would also decrease performance, likely noticeably, for a >> vm_event-based application, as we'd get many such events (most of which >> we're not interested in at all) which would require treatment while the >> respective VCPU is paused. > > You should limit the periods of time when you enable the > subscription (e.g. only from when you inject an event until > you did see it arrive). Perhaps such a subscription should then > be per-vCPU ... I think there might be a design argument against this model: using a generic event implies that there are (or there might be) users interested in long-term following interrupt events. However, that's clearly impractical, since this would effectively render the guest unusable. So the real use case would be to just use it, as you say, sparingly, for just a few events - but in this case the event was never meant to be followed more than figuring out if, for example, outside injection failed, which can more readily be accomplished with a single, dedicated event. My proposal was simply something along the lines of: Thanks, Razvan diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c index 704fd64..58f5ae4 100644 --- a/xen/arch/x86/hvm/hvm.c +++ b/xen/arch/x86/hvm/hvm.c @@ -535,8 +535,22 @@ void hvm_do_resume(struct vcpu *v) /* Inject pending hw/sw trap */ if ( v->arch.hvm_vcpu.inject_trap.vector != -1 ) { - hvm_inject_trap(&v->arch.hvm_vcpu.inject_trap); + unsigned int success = 0; + + /* Check for already pending interrupts (races). */ + if ( !hvm_event_pending(v) ) + { + hvm_inject_trap(&v->arch.hvm_vcpu.inject_trap); + success = 1; + } + v->arch.hvm_vcpu.inject_trap.vector = -1; + + hvm_monitor_injection_result(v->arch.hvm_vcpu.inject_trap.vector, + v->arch.hvm_vcpu.inject_trap.type, + v->arch.hvm_vcpu.inject_trap.error_code, + v->arch.hvm_vcpu.inject_trap.cr2, + success); } }