From: Dong Jia <bjsdjshi@linux.vnet.ibm.com>
To: "Tian, Kevin" <kevin.tian@intel.com>
Cc: Neo Jia <cjia@nvidia.com>,
Alex Williamson <alex.williamson@redhat.com>,
"Ruan, Shuai" <shuai.ruan@intel.com>,
"Song, Jike" <jike.song@intel.com>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
Kirti Wankhede <kwankhede@nvidia.com>,
"kraxel@redhat.com" <kraxel@redhat.com>,
"pbonzini@redhat.com" <pbonzini@redhat.com>,
"Lv, Zhiyuan" <zhiyuan.lv@intel.com>,
Dong Jia <bjsdjshi@linux.vnet.ibm.com>
Subject: Re: [Qemu-devel] [RFC PATCH v3 3/3] VFIO Type1 IOMMU change: to support with iommu and without iommu
Date: Tue, 7 Jun 2016 15:04:41 +0800 [thread overview]
Message-ID: <20160607150441.3287a587@oc7835276234> (raw)
In-Reply-To: <AADFC41AFE54684AB9EE6CBC0274A5D15F8911F8@SHSMSX101.ccr.corp.intel.com>
On Tue, 7 Jun 2016 02:47:10 +0000
"Tian, Kevin" <kevin.tian@intel.com> wrote:
> > From: Dong Jia
> > Sent: Monday, June 06, 2016 2:59 PM
> >
>
> [...]
>
> > Channel I/O is quite different to PCI, so I copied some more details
> > here. Hope these could help.
> >
> > Channel subsystem:
> > The channel subsystem directs the flow of information between I/O devices
> > and main storage. It relieves CPUs of the task of communicating directly
> > with I/O devices and permits data processing to proceed concurrently with
> > I/O processing.
> >
> > Channel path:
> > The channel subsystem uses one or more channel paths as the communication
> > link in managing the flow of information to or from I/O devices.
> >
> > Subchannel:
> > Within the channel subsystem are subchannels. One subchannel of type I/O
> > is provided for and dedicated to each I/O device accessible to the channel
> > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > subsystem.
> >
> > Control unit:
> > A control unit implements a standardized interface which translates between
> > the Channel Subsystem and the actual device. It does this by adapting the
> > characteristics of each device so that it can respond to the standard form
> > of control provided by the channel subsystem.
> >
> > Channel Path:
> > The channel subsystem communicates with the I/O devices by means of
> > channel paths between the channel subsystem and control units.
> >
> > +-------------------+
> > | channel subsystem |
> > +-------------------+
> > | |
> > | +----------+ | +--------------+ +------------+
> > | |subchannel| | channel path | control unit | | I/O device |
> > | +---------------------------------------------------------------+
> > | | subchno | | | | | devno |
> > | +----------+ | +--------------+ +------------+
> > | |
> > +-------------------+
> >
> > There is no concept of ccw-device registers by the subchannel. Control
> > unit will interact with the device, collect the I/O result, and inform
> > the result to the subchannel.
> > So it seems to me, there is no needs to provide region info for
> > isolation. As mentioned above, the isolation is quite natural.
> >
> > Please correct me in case I misunderstood some of the concepts in your
> > questions and gave irrelevant answers. :>
> >
>
> Thanks for above background which is very useful. Several follow-up Qs:
>
> 1) Does it mean that VFIO is managing resource in subchannel level, so Qemu
> can only operate subchannels assigned to itself
Dear Kevin,
This understanding is basically right, but not that exactly.
Linux creates a 'struct ccw_device' for each device it has detected, and
a 'struct subchannel' for the corresponding subchannel. When we issue
a command to a device instance, the device can find the subchannel and
pass the command to it.
The current vfio-ccw implementation targets a device passthru. So I'd say
that VFIO is managing resource in both the device and the
subchannel level.
However, there is a discussion inside our team that tries to figure out
if a subchannel passthru would be better. So, in the future, it's
possible to do the management in a subchannel level only.
> (then emulate as the complete channel io sub-system to guest)?
This is right.
>
> 2) How are ccw commands associated with a subchannel?
The I/O instruction requires a subchannel id and an ORB
(Operation-Request Block, which contains the execution parameters,
including the address of the ccws). So when an I/O instruction was
intercepted, we know which is the target subchannel. And using this
target information, we can find the real physical device and the
subchannel to perform the instruction.
> Are they submitted
> through a dedicated subchannel interface (so VFIO can easily map that interface)
We can understand it this way.
> or that subchannel is specified by a special ccw cmd (means VFIO-ccw needs
> to scan cmds to avoid malicious attempts on non-assigned subchannels)?
No. CCWs themselves don't contain subchannel information.
>
> Thanks
> Kevin
>
--------
Dong Jia
next prev parent reply other threads:[~2016-06-07 7:05 UTC|newest]
Thread overview: 78+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-02 18:40 [Qemu-devel] [RFC PATCH v3 0/3] Add vGPU support Kirti Wankhede
2016-05-02 18:40 ` [Qemu-devel] [RFC PATCH v3 1/3] vGPU Core driver Kirti Wankhede
2016-05-03 22:43 ` Alex Williamson
2016-05-04 2:45 ` Tian, Kevin
2016-05-04 16:57 ` Alex Williamson
2016-05-05 8:58 ` Tian, Kevin
2016-05-04 2:58 ` Tian, Kevin
2016-05-12 8:22 ` Tian, Kevin
2016-05-04 13:31 ` Kirti Wankhede
2016-05-05 9:06 ` Tian, Kevin
2016-05-05 10:44 ` Kirti Wankhede
2016-05-05 12:07 ` Tian, Kevin
2016-05-05 12:57 ` Kirti Wankhede
2016-05-11 6:37 ` Tian, Kevin
2016-05-06 12:14 ` Jike Song
2016-05-06 16:16 ` Kirti Wankhede
2016-05-09 12:12 ` Jike Song
2016-05-02 18:40 ` [Qemu-devel] [RFC PATCH v3 2/3] VFIO driver for vGPU device Kirti Wankhede
2016-05-03 22:43 ` Alex Williamson
2016-05-04 3:23 ` Tian, Kevin
2016-05-04 17:06 ` Alex Williamson
2016-05-04 21:14 ` Neo Jia
2016-05-05 4:42 ` Kirti Wankhede
2016-05-05 9:24 ` Tian, Kevin
2016-05-05 20:27 ` Neo Jia
2016-05-11 6:45 ` Tian, Kevin
2016-05-11 20:10 ` Alex Williamson
2016-05-12 0:59 ` Tian, Kevin
2016-05-04 16:25 ` Kirti Wankhede
2016-05-02 18:40 ` [Qemu-devel] [RFC PATCH v3 3/3] VFIO Type1 IOMMU change: to support with iommu and without iommu Kirti Wankhede
2016-05-03 10:40 ` Jike Song
2016-05-03 22:43 ` Alex Williamson
2016-05-04 3:39 ` Tian, Kevin
2016-05-05 6:55 ` Jike Song
2016-05-05 9:27 ` Tian, Kevin
2016-05-10 7:52 ` Jike Song
2016-05-10 16:02 ` Neo Jia
2016-05-11 9:15 ` Jike Song
2016-05-11 22:06 ` Alex Williamson
2016-05-12 4:11 ` Jike Song
2016-05-12 19:49 ` Neo Jia
2016-05-13 2:41 ` Tian, Kevin
2016-05-13 6:22 ` Jike Song
2016-05-13 6:43 ` Neo Jia
2016-05-13 7:30 ` Jike Song
2016-05-13 7:42 ` Neo Jia
2016-05-13 7:45 ` Tian, Kevin
2016-05-13 8:31 ` Neo Jia
2016-05-13 9:23 ` Jike Song
2016-05-13 15:50 ` Neo Jia
2016-05-16 6:57 ` Jike Song
2016-05-13 6:08 ` Jike Song
2016-05-13 6:41 ` Neo Jia
2016-05-13 7:13 ` Tian, Kevin
2016-05-13 7:38 ` Neo Jia
2016-05-13 8:02 ` Tian, Kevin
2016-05-13 8:41 ` Neo Jia
2016-05-12 8:00 ` Tian, Kevin
2016-05-12 19:05 ` Alex Williamson
2016-05-12 20:12 ` Neo Jia
2016-05-13 9:46 ` Jike Song
2016-05-13 15:48 ` Neo Jia
2016-05-16 2:27 ` Jike Song
2016-05-13 3:55 ` Tian, Kevin
2016-05-13 16:16 ` Alex Williamson
2016-05-13 7:10 ` Dong Jia
2016-05-13 7:24 ` Neo Jia
2016-05-13 8:39 ` Dong Jia
2016-05-13 9:05 ` Neo Jia
2016-05-19 7:28 ` Dong Jia
2016-05-20 3:21 ` Tian, Kevin
2016-06-06 6:59 ` Dong Jia
2016-06-07 2:47 ` Tian, Kevin
2016-06-07 7:04 ` Dong Jia [this message]
2016-05-05 7:51 ` Kirti Wankhede
2016-05-04 1:05 ` [Qemu-devel] [RFC PATCH v3 0/3] Add vGPU support Tian, Kevin
2016-05-04 6:17 ` Neo Jia
2016-05-04 17:07 ` Alex Williamson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160607150441.3287a587@oc7835276234 \
--to=bjsdjshi@linux.vnet.ibm.com \
--cc=alex.williamson@redhat.com \
--cc=cjia@nvidia.com \
--cc=jike.song@intel.com \
--cc=kevin.tian@intel.com \
--cc=kraxel@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=kwankhede@nvidia.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=shuai.ruan@intel.com \
--cc=zhiyuan.lv@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).