On 06/25/2014 08:03 AM, Gavin Shan wrote:
On Tue, Jun 24, 2014 at 05:00:52PM +1000, Benjamin Herrenschmidt wrote:
On Tue, 2014-06-24 at 14:57 +0800, Mike Qiu wrote:
Is that mean *host* side error injection should base on
"CONFIG_IOMMU_API" ? If it is just host side(no guest, no pass through),
can't we do error inject?
Maybe I misunderstand :)
Ah no, make different patches, we don't want to use IOMMU group ID, just
PE numbers. Maybe we should expose in sysfs the PEs from the platform
code with the error injection files underneath ...
Yeah, "errinjct" needs grab PCI_domain_nr+PE number from sysfs. We
already had PE number sysfs file:
[root@ltcfbl8eb 0000:01:00.1]# pwd
/sys/bus/pci/devices/0000:01:00.1
[root@ltcfbl8eb 0000:01:00.1]# cat eeh_pe_config_addr
0x1
For guest support, we will rely on VFIO group ioctl command, which
naturally depends on pass-through.
---
We probably implement it like this. If there're anything wrong, please
correct me:
- Introduce EEH callback struct eeh_ops::err_inject(), which will be
implemented for PowerNV (NULL for pSeries) by calling the PCI error
injection dedicated OPAL API (opal_pci_err_inject()).
- Introduce global function eeh.c::eeh_err_inject(), which calls to
eeh_ops::err_inject() and newly introduced VFIO EEH operation
will be implemented based on this function.
- Introduce debugfs /sys/kernel/debug/powerpc/PCIxxxx/errinjct, which
Here maybe "/sys/kernel/debug/powerpc/errinjct" is better, because it
will supply "PCI_domain_nr" in parameters, so no need supply errinjct
for each PCI domain.
Another reason is error inject not only for PCI(in future), so better
not in PCI domain entry.
Also it simple for userland tools to has a fixed path.
Thanks
Mike
receives PCI error injection parameters from "errinjct". It could
have format: "ei_token:addr:mask:PCI_domain_nr:PE_num:function".
Eventually, eeh_err_inject() is invoked to call the corresponding
OPAL API.
Thanks,
Gavin
--
To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
