> From: Dong Jia [mailto:bjsdjshi@xxxxxxxxxxxxxxxxxx] > Sent: Thursday, May 19, 2016 3:28 PM > > On Fri, 13 May 2016 02:05:01 -0700 > Neo Jia <cjia@xxxxxxxxxx> wrote: > > ...snip... > > > > > Hi Dong, > > > > We should definitely be mindful about the data structure performance especially > > dealing with kernel. But for now, we haven't done any performance analysis yet > > for the current rbtree implementation, later we will definitely run it through > > large guest RAM configuration and multiple virtual devices cases, etc. to > > collect data. > > > > Regarding your use case, may I ask if there will be concurrent command streams > > running for the same VM? > Hi Neo: > > Sorry for the late response. Spent some time to make the confirmation. > > For our case, one iommu group will add one (and only one) ccw-device. > For one ccw-device, there will be no concurrent command streams from it. > Hi, Dong, Looks there can be multiple devices behind one channel, according to: https://en.wikipedia.org/wiki/Channel_I/O Do they need to be assigned together as one iommu group? If not, how is the isolation being done in your implementation? Based on cmd scanning in Qemu-side? Another curious question about channel io itself. I'm unclear whether the channel here only fulfills the role of DMA controller (i.e. controlling how device access memory), or also offloads CPU accesses to the registers on the ccw-device. Are ccw-device registers directly addressable by CPU on s390, similar to MMIO concept on x86? If yes, I guess you also need provide region info in vfio-ccw to control which I/O resource can be accessed by user space (looks not there in your vfio-ccw patch series). If not, how do you control the isolation in that aspect? :-) Thanks Kevin -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
