Re: [Qemu-devel] [RFC PATCH v3 3/3] VFIO Type1 IOMMU change: to support with iommu and without iommu

[Tian, Kevin]

> From: Dong Jia [mailto:address@hidden
> Sent: Thursday, May 19, 2016 3:28 PM
> 
> On Fri, 13 May 2016 02:05:01 -0700
> Neo Jia <address@hidden> 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