Re: [Xen-devel] [PATCH v7] x86/emulate: Send vm_event from emulate

[Alexandru Stefan ISAILA <aisaila@xxxxxxxxxxxxxxx>]

>>>>> @@ -629,6 +697,14 @@ static void *hvmemul_map_linear_addr(
>>>>>       
>>>>>                   ASSERT(p2mt == p2m_ram_logdirty || 
>>>>> !p2m_is_readonly(p2mt));
>>>>>               }
>>>>> +
>>>>> +        if ( curr->arch.vm_event &&
>>>>> +            curr->arch.vm_event->send_event &&
>>>>> +            hvm_emulate_send_vm_event(addr, gfn, pfec) )
>>>>> +        {
>>>>> +            err = ERR_PTR(~X86EMUL_RETRY);
>>>>> +            goto out;
>>>>> +        }
>>>>
>>>> Did you notice that there's an immediate exit from the loop only
>>>> in case the linear -> physical translation fails? This is
>>>> relevant for page fault delivery correctness for accesses
>>>> crossing page boundaries. I think you want to use
>>>> update_map_err() and drop the "goto out". I can't really make up
>>>
>>> By update_map_err() are you saying to have the err var assigned and then
>>> drop "goto out"? If so how do I keep the err from my access violation
>>> without exiting from the loop?
>>
>> Counter question: Why do you _need_ to keep "your" value of err?
>> If, just as an example, there's going to be a #PF on the other
>> half of the access, then "your" access violation is of no interest
>> at all.
> 
> You are right, there is no need to keep the "goto out" here. It was just
> for optimization in the idea that there is no need to do further steps
> but I can drop the "goto out" and the code will work the same.
> 

There is a problem with dropping the "goto out". If everything goes fine 
then it will return the mapping and I don't want that. This can be 
stopped by checking if ( err ) after the loop and it is not null then 
goto out. And going with this idea I can init *err = NULL and drop the 
err = NULL from hvmemul_map_linear_addr(). Is this ok for the next version?

Regards,
Alex
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel