Hi Julien,
>>> [...]
>>>
>>>> switch ( fsc )
>>>> {
>>>> + case FSC_FLT_TRANS:
>>>> + {
>>>> + if ( altp2m_active(d) )
>>>> + {
>>>> + const struct npfec npfec = {
>>>> + .insn_fetch = 1,
>>>> + .gla_valid = 1,
>>>> + .kind = hsr.iabt.s1ptw ? npfec_kind_in_gpt :
>>>> npfec_kind_with_gla
>>>> + };
>>>> +
>>>> + /*
>>>> + * Copy the entire page of the failing instruction
>>>> into the
>>>> + * currently active altp2m view.
>>>> + */
>>>> + if ( altp2m_lazy_copy(v, gpa, gva, npfec, &p2m) )
>>>> + return;
>>>
>>> I forgot to mention that I think there is a race condition here. If
>>> multiple vCPU (let say A and B) use the same altp2m, they may fault
>>> here.
>>>
>>> If vCPU A already fixed the fault, this function will return false and
>>> continue. So this will lead to inject an instruction abort to the
>>> guest.
>>>
I have solved this issue as well:
In altp2m_lazy_copy, we check whether the faulting address is already
mapped in the current altp2m view. The only reason why the current
altp2m should have a valid entry for the apparently faulting address is
that it was previously (almost simultaneously) mapped by another vcpu.
That is, if the mapping for the faulting address is valid in the altp2m,
we return true and hence let the guest retry (without injecting an
instruction/data abort exception) to access the address in question.
Best regards,
~Sergej
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
