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)
--
Thanks,
David / dhildenb
