On Fri, Jan 11, 2019 at 06:25:21PM +0000, James Morse wrote:
> We ack it in the corrupt-record case too, because we are done with the
> memory.
Ok, so the only thing that we need to do unconditionally is ACK in order
to free the memory. Or is there an exception to that set of steps in
error handling?
> I think it is. 18.3.2.8 of ACPI v6.2 (search for Generic Hardware Error Source
> version 2", then below the table):
> * OSPM detects error (via interrupt/exception or polling the block status)
> * OSPM copies the error status block
> * OSPM clears the block status field of the error status block
> * OSPM acknowledges the error via Read Ack register
>
> The ENOENT case is excluded by 'polling the block status'.
Ok, so we signal the absence of an error record with ENOENT.
if (!buf_paddr)
return -ENOENT;
Can that even happen?
Also, in that case, what would happen if we ACK the error anyway? We'd
confuse the firmware?
I sure hope firmware is prepared for spurious ACKs :)
> Unsurprisingly the spec doesn't consider the case that firmware generates
> corrupt records!
You mean the EIO case?
Not surprised at all. But we do not report that record so all good.
Thx.
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
_______________________________________________
kvmarm mailing list
kvmarm@xxxxxxxxxxxxxxxxxxxxx
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
