On 28.05.14 23:58, Benjamin Herrenschmidt wrote:
On Wed, 2014-05-28 at 22:49 +1000, Gavin Shan wrote:
I will remove those "address" related macros in next revision because it's
user-level bussiness, not related to host kernel any more.
If the user is QEMU + guest, we need the address to identify the PE though PHB
BUID could be used as same purpose to get PHB, which is one-to-one mapping with
IOMMU group on sPAPR platform. However, once the PE address is built and returned
to guest, guest will use the PE address as input parameter in subsequent RTAS
calls.
If the user is some kind of application who just uses the ioctl() without supporting
RTAS calls. We don't need care about PE address.
I am a bit reluctant with that PE==PHB equation we seem to be introducing.
This isn't the case in HW. It's possible that this is how we handle VFIO *today*
in qemu but it doesn't have to be does it ?
Right, but that's pure QEMU internals. From the VFIO kernel interface's
point of view, a VFIO group is a PE context, as that's what gets IOMMU
controlled together too.
It also paints us into a corner if we want to start implementing some kind of
emulated EEH for selected emulated devices and/or virtio.
I don't think so :). In QEMU the PHB emulation would have to notify the
"container" (IOMMU emulation layer -> PE) that a PE operation happened.
It's that emulation code's responsibility to broadcast operations across
its own emulated operations (recover config space access, reconfigure
BARs, etc) and the VFIO PE operations.
So from a kernel interface point of view, I think leaving out any
address information is the right way to go. Whether we managed to get
all QEMU internal interfaces modeled correctly yet has to be seen on the
next patch set revision :).
Alex
--
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
