On Wed, Mar 20, 2013 at 01:46:22PM -0600, Alex Williamson wrote: >On Wed, 2013-03-20 at 20:31 +0100, Benjamin Herrenschmidt wrote: >> On Wed, 2013-03-20 at 12:48 -0600, Alex Williamson wrote:
.../... >> As for EEH, I will let Gavin describe in more details what he is doing, >> though I wouldn't be surprised if so far he doesn't have a >> non-accelerated path :-) Which indeed makes things oddball, granted ... >> at least for now. I *think* what Gavin's doing right now is a >> pass-through to the host EEH directly in the kernel, so without a slow >> path... >> Yes, I don't have non-accelerated path. I'm trying to describe what I'm doing: On the host side, the interrupt will be triggered while detecting frozen PE, which has been passed to guest. We won't send EEH event to EEH core on host side and we're waiting for guest to be involved to handle the EEH error. In guest, any access to config or MMIO of the frozen PE will trigger EEH event and in turn, the guest utilizes existing (exactly same to pSeries on phyp case) RTAS calls to recover the error. The RTAS calls is being emulated in host kernel. Part of the RTAS call arguments is PCI domain/bus/slot/function viewed from guest perspective. That's different from that for same physical PCI device in host side. So I used VFIO-PCI to do the mapping and maintain the information in host kernel. >> Gavin, it really boils down to that. In-kernel EEH for guests is a >> KVMism that ends up not involving VFIO in any other way than >> establishing the mapping, then arguably it could be done via a VM ioctl. >> >> If there's more going through VFIO and shared state, then it should >> probably go through VFIO-PCI. > Ben, you're right. I use VFIO for nothing other than doing address mapping. So I will do the address mapping in VM IOCTL instead of in VFIO-PCI. Thanks, Gavin _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
