On 27.10.20 20:24, 'Nikhil Devshatwar' via Jailhouse wrote:
> On 18:33-20201027, Jan Kiszka wrote:
>> On 26.10.20 20:52, 'Nikhil Devshatwar' via Jailhouse wrote:
>>> @@ -356,20 +362,15 @@ static int pvu_iommu_program_entries(struct cell
>>> *cell, u8 virtid)
>>> if (idx == 0 && i >= dev->num_entries) {
>>> /* Find next available TLB and chain to it */
>>> tlb_next = pvu_tlb_alloc(dev, virtid);
>>> - if (tlb_next < 0)
>>> - return -ENOMEM;
>>> pvu_tlb_chain(dev, tlbnum, tlb_next);
>>> pvu_tlb_enable(dev, tlbnum);
>>> tlbnum = tlb_next;
>>> }
>>>
>>> - ret = pvu_entry_write(dev, tlbnum, idx, ent);
>>> - if (ret)
>>> - return ret;
>>> + pvu_entry_write(dev, tlbnum, idx, ent);
>>
>> But what if pvu_entry_write finds an issue? Are we fine with reporting
>> only and then simply continueing?
>>
> The failures in pvu_entry_write are defensive programming.
> To ensure that the hardware constraints are met.
> Here, the caller has ensured the constraints, so this won't fail.
>
> I can either get rid of the checks or explain why it is okay to
> ignore the return value
Are the check run against an unlikely hardware state or against a
possibly invalid cell configuration?
Jan
--
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux
--
You received this message because you are subscribed to the Google Groups
"Jailhouse" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/jailhouse-dev/aa9db23e-5e3b-5656-367b-a387e04ba0a2%40siemens.com.
