On Wed, Dec 13, 2017 at 12:57:11PM +0100, David Hildenbrand wrote:
> 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?
The intercept messages are sent to the parent partition (whose role is
played by the hypervisor in our case) and that one is supposed to decide
what to do with it.
Triggering a pagefault in the guest doesn't look correct because the
checks you mention are related to the GPA and not to the guest virtual
address.
So I think the only option we have is to return an error code, and we
need to decide which one. We also can fall through to the userspace,
but I can't see why the userspace would have better chances to read that
GPA.
Roman.
