On Thu, May 04, 2023 at 09:00:51PM +0000, Luck, Tony wrote: > > +An error injection example:: > > + > > + # cd /sys/kernel/debug/apei/einj > > + # cat available_error_type # See which errors can be injected > > + 0x00000001 EINJV2 Processor Error > > + 0x00000002 EINJV2 Memory Error > > + 0x00000004 EINJV2 PCI Express Error > > + # echo 0x2 > error_type > > + # echo 0x5 > flags > > + # echo 0x12345000 > param1 > > + # echo 0x2 > param5 > > + # echo 1 > error_inject > > > > Is the expectation that platforms that implement EINJV2 will not include legacy > > EINJ support? > > I spoke to some BIOS folks here. They said that the ACPI 6.5 change is an > extension to the action table with new opcodes for GET/SET when EINJV2 > is supported. The legacy actions are not deprecated. So platform firmware could > support both old and new injection formats. > > So I'm going to double down on this: > > > Maybe it would be better to change the top-level directory to: > > > > /sys/kernel/debug/apei/einjv2 I also think this is the best way to go to have EINJ and EINJv2 supported. Is anyone working on implementing this? or should I give it a shot and try to send a patch that separates the parent directory for EINJv2? > > and say this isn't a "maybe". The EINJV2 interface files should go > in a new directory. The old files should continue to work (assuming > firmware still enumerates the old available types). > > Simplifying the interface for EINJV2 in the new directory is an option. > I think we should take it ... the "paramN" files that mean different > things for different injection types were an evolution rather than a design. > > -Tony > > > >
