From: Dong Jia Shi <bjsdjshi@linux.vnet.ibm.com>
To: Cornelia Huck <cornelia.huck@de.ibm.com>
Cc: Dong Jia Shi <bjsdjshi@linux.vnet.ibm.com>,
kvm@vger.kernel.org, linux-s390@vger.kernel.org,
qemu-devel@nongnu.org, borntraeger@de.ibm.com, agraf@suse.com,
alex.williamson@redhat.com, eric.auger@redhat.com
Subject: Re: [Qemu-devel] [PATCH v7 05/13] s390x/css: realize css_create_sch
Date: Tue, 9 May 2017 09:38:31 +0800 [thread overview]
Message-ID: <20170509013831.GF15974@bjsdjshi@linux.vnet.ibm.com> (raw)
In-Reply-To: <20170508125040.7dc4e1e2.cornelia.huck@de.ibm.com>
* Cornelia Huck <cornelia.huck@de.ibm.com> [2017-05-08 12:50:40 +0200]:
> On Mon, 8 May 2017 13:18:22 +0800
> Dong Jia Shi <bjsdjshi@linux.vnet.ibm.com> wrote:
>
> > * Cornelia Huck <cornelia.huck@de.ibm.com> [2017-05-05 14:11:53 +0200]:
> >
> > > On Fri, 5 May 2017 04:03:44 +0200
> > > Dong Jia Shi <bjsdjshi@linux.vnet.ibm.com> wrote:
>
> > > > -SubchDev *css_create_virtual_sch(CssDevId bus_id, Error **errp)
> > > > +SubchDev *css_create_sch(CssDevId bus_id, bool is_virtio, bool squash_mcss,
> > > > + Error **errp)
> > > > {
> > > > uint16_t schid = 0;
> > > > SubchDev *sch;
> > > >
> > > > if (bus_id.valid) {
> > > > - /* Enforce use of virtual cssid. */
> > > > - if (bus_id.cssid != VIRTUAL_CSSID) {
> > > > - error_setg(errp, "cssid %hhx not valid for virtual devices",
> > > > - bus_id.cssid);
> > > > + if (is_virtio != (bus_id.cssid == VIRTUAL_CSSID)) {
> > > > + error_setg(errp, "cssid %hhx not valid for %s devices",
> > > > + bus_id.cssid,
> > > > + (is_virtio ? "virtio" : "non-virtio"));
> > >
> > > This reminds me of something else: virtual 3270 devices will use the
> > > virtual channel subsystem by default. I think this is fine: Even though
> > > they are not virtio devices, they are fully virtual constructs, and it
> > > does not make sense to artificially shove them into another css.
> > VIRTUAL CSS (0xFE) is reserved for virtio devices only, no? This is what
> > I understood... So we should not put any non-virtio devices into CSS
> > 0xFE.
> >
> > If my understanding is not right before, I agree that we put non-virtio
> > (e.g. 3270) devices into CSS 0xFE, and ...
> >
> > >
> > > But this means the distinction should be virtual vs. non-virtual and
> > > not virtio vs. non-virtio, and the squashing is only applicable to
> > > non-virtual devices. Mainly a naming thing.
> > ... do the following modifications here:
> > s/virtio/virtual
> > s/non-virtio/non-virtual
> > s/is_virtio/is_virtual
>
> I realize that I wanted to treat css 0xfe as virtio-only initially;
Aha, here is the origination of my former understanding.
> but I think the virtual/non-virtual distinction actually makes more
> sense.
Agreed. And since we do not have legacy problem that stops us from doing
this, I will fix according to your comments.
>
> - For devices that don't have a hardware equivalent at all (like
> virtio-ccw), it's clear that they should be in the virtual css.
Nod.
>
> - For devices that are always fully emulated (because there's no device
> that could be passthroughed), I'd argue that they should be treated as
> fully virtual as well. This means 3270, and would include things like a
> card punch should anyone feel an urge to emulate that one :)
Nod.
>
> - An emulation of a device that could also be passthroughed is a bit of
> a grey area. One could argue to put it either with the virtual devices
> or with the non-virtual ones. But I think we can ignore that for now
> (until someone decides that a dasd emulation is a thing qemu urgently
> needs...)
Ok.
--
Dong Jia Shi
next prev parent reply other threads:[~2017-05-09 1:38 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-05 2:03 [Qemu-devel] [PATCH v7 00/13] basic channel IO passthrough infrastructure based on vfio Dong Jia Shi
2017-05-05 2:03 ` [Qemu-devel] [PATCH v7 01/13] update-linux-headers: update for vfio-ccw Dong Jia Shi
2017-05-05 2:03 ` [Qemu-devel] [PATCH v7 02/13] vfio: linux-headers " Dong Jia Shi
2017-05-05 2:03 ` [Qemu-devel] [PATCH v7 03/13] s390x/css: add s390-squash-mcss machine option Dong Jia Shi
2017-05-05 2:03 ` [Qemu-devel] [PATCH v7 04/13] s390x/css: realize css_sch_build_schib Dong Jia Shi
2017-05-05 12:04 ` Cornelia Huck
2017-05-08 3:07 ` Dong Jia Shi
2017-05-05 2:03 ` [Qemu-devel] [PATCH v7 05/13] s390x/css: realize css_create_sch Dong Jia Shi
2017-05-05 12:11 ` Cornelia Huck
2017-05-08 5:18 ` Dong Jia Shi
2017-05-08 10:50 ` Cornelia Huck
2017-05-09 1:38 ` Dong Jia Shi [this message]
2017-05-05 2:03 ` [Qemu-devel] [PATCH v7 06/13] s390x/css: device support for s390-ccw passthrough Dong Jia Shi
2017-05-09 8:18 ` Auger Eric
2017-05-11 21:13 ` Alex Williamson
2017-05-15 2:22 ` Dong Jia Shi
2017-05-05 2:03 ` [Qemu-devel] [PATCH v7 07/13] vfio/ccw: vfio based subchannel passthrough driver Dong Jia Shi
2017-05-09 8:19 ` Auger Eric
2017-05-11 21:48 ` Alex Williamson
2017-05-05 2:03 ` [Qemu-devel] [PATCH v7 08/13] vfio/ccw: get io region info Dong Jia Shi
2017-05-09 8:20 ` Auger Eric
2017-05-11 21:48 ` Alex Williamson
2017-05-05 2:03 ` [Qemu-devel] [PATCH v7 09/13] vfio/ccw: get irqs info and set the eventfd fd Dong Jia Shi
2017-05-09 8:21 ` Auger Eric
2017-05-09 8:35 ` Dong Jia Shi
2017-05-11 21:49 ` Alex Williamson
2017-05-15 2:31 ` Dong Jia Shi
2017-05-15 2:35 ` Dong Jia Shi
2017-05-05 2:03 ` [Qemu-devel] [PATCH v7 10/13] s390x/css: introduce and realize ccw-request callback Dong Jia Shi
2017-05-11 21:49 ` Alex Williamson
2017-05-05 2:03 ` [Qemu-devel] [PATCH v7 11/13] s390x/css: ccw translation infrastructure Dong Jia Shi
2017-05-05 2:03 ` [Qemu-devel] [PATCH v7 12/13] vfio/ccw: update sense data if a unit check is pending Dong Jia Shi
2017-05-11 21:49 ` Alex Williamson
2017-05-05 2:03 ` [Qemu-devel] [PATCH v7 13/13] MAINTAINERS: Add vfio-ccw maintainer Dong Jia Shi
2017-05-05 12:20 ` Cornelia Huck
2017-05-08 5:29 ` Dong Jia Shi
2017-05-08 9:09 ` Cornelia Huck
2017-05-09 1:41 ` Dong Jia Shi
2017-05-09 7:33 ` Cornelia Huck
2017-05-11 21:49 ` Alex Williamson
2017-05-05 12:22 ` [Qemu-devel] [PATCH v7 00/13] basic channel IO passthrough infrastructure based on vfio Cornelia Huck
2017-05-08 5:31 ` Dong Jia Shi
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=20170509013831.GF15974@bjsdjshi@linux.vnet.ibm.com \
--to=bjsdjshi@linux.vnet.ibm.com \
--cc=agraf@suse.com \
--cc=alex.williamson@redhat.com \
--cc=borntraeger@de.ibm.com \
--cc=cornelia.huck@de.ibm.com \
--cc=eric.auger@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=qemu-devel@nongnu.org \
/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).