From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Hildenbrand Subject: Re: [PATCH v5 2/2] kvm: x86: hyperv: guest->host event signaling via eventfd Date: Wed, 13 Dec 2017 12:57:11 +0100 Message-ID: References: <20171212160742.793-1-rkagan@virtuozzo.com> <20171212160742.793-3-rkagan@virtuozzo.com> <20171213114450.GD18723@rkaganb.sw.ru> <752b8f33-805f-002a-6ae5-a37b3c8b012a@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit To: Roman Kagan , kvm@vger.kernel.org, Paolo Bonzini , =?UTF-8?B?UmFkaW0gS3LEjW3DocWZ?= , "Denis V. Lunev" , Konrad Rzeszutek Wilk , Vitaly Kuznetsov Return-path: Received: from mx1.redhat.com ([209.132.183.28]:55606 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752175AbdLML5N (ORCPT ); Wed, 13 Dec 2017 06:57:13 -0500 In-Reply-To: <752b8f33-805f-002a-6ae5-a37b3c8b012a@redhat.com> Content-Language: en-US Sender: kvm-owner@vger.kernel.org List-ID: On 13.12.2017 12:51, David Hildenbrand wrote: > On 13.12.2017 12:46, David Hildenbrand wrote: >> On 13.12.2017 12:44, Roman Kagan wrote: >>> On Wed, Dec 13, 2017 at 10:55:02AM +0100, David Hildenbrand wrote: >>>> >>>>> +static u16 kvm_hvcall_signal_event(struct kvm_vcpu *vcpu, bool fast, u64 param) >>>>> +{ >>>>> + u16 ret; >>>>> + u32 conn_id, flag_no; >>>>> + int idx; >>>>> + struct eventfd_ctx *eventfd; >>>>> + >>>>> + if (unlikely(!fast)) { >>>>> + gpa_t gpa = param; >>>>> + >>>>> + if ((gpa & (__alignof__(param) - 1)) || >>>>> + offset_in_page(gpa) + sizeof(param) > PAGE_SIZE) >>>>> + return HV_STATUS_INVALID_ALIGNMENT; >>>>> + >>>>> + idx = srcu_read_lock(&vcpu->kvm->srcu); >>>>> + ret = kvm_vcpu_read_guest(vcpu, gpa, ¶m, sizeof(param)); >>>>> + srcu_read_unlock(&vcpu->kvm->srcu, idx); >>>>> + >>>>> + if (ret < 0) >>>>> + return HV_STATUS_INSUFFICIENT_MEMORY; >>>> >>>> "... event flags do not require any buffer allocation or queuing within >>>> the hypervisor, so HvSignalEvent will never fail due to insufficient >>>> resources." >>> >>> Ouch. I wonder what else to map -EFAULT to then... Looks like >>> HV_STATUS_INVALID_ALIGNMENT is the most appropriate (as in "The input or >>> output GPA pointer is not within the bounds of the GPA space.") >>> >>> Thanks, >>> Roman. >>> >> >> It is likely happen rearelyn, but usually if we are out of memory we >> should report to user space. (chances that we won't be able to continue >> for longer either way are very high) >> > (I implied -ENOMEM is translated to -EFAULT) it can of course happen if > the address is wrong. > > Also wonder how to deal with that. Could it be that we even have to > trigger a page fault in the guest? > The hypervisor will validate that the calling partition can read from the input page before executing the requested hypercall. This validation consists of two checks: the specified GPA is mapped and the GPA is marked readable. If either of these tests fails, the hypervisor generates a memory intercept message. So memory intercept message is the right thing to do I guess? -- Thanks, David / dhildenb