On Thu, 10 Jan 2019 11:12:47 -0500
"Jason J. Herne" <jjhe...@linux.ibm.com> wrote:
> On 12/14/18 8:04 AM, Cornelia Huck wrote:
> > On Wed, 12 Dec 2018 09:11:15 -0500
> > "Jason J. Herne" <jjhe...@linux.ibm.com> wrote:
> >
> >> Now that we have a Channel I/O library let's modify virtio boot code to
> >> make use of it for running channel programs.
> >>
> >> Signed-off-by: Jason J. Herne <jjhe...@linux.ibm.com>
> >> ---
> >> pc-bios/s390-ccw/virtio.c | 21 ++-------------------
> >> 1 file changed, 2 insertions(+), 19 deletions(-)
> >>
> >> diff --git a/pc-bios/s390-ccw/virtio.c b/pc-bios/s390-ccw/virtio.c
> >> index aa9da72..5fb49e2 100644
> >> --- a/pc-bios/s390-ccw/virtio.c
> >> +++ b/pc-bios/s390-ccw/virtio.c
> >> @@ -92,30 +92,13 @@ int drain_irqs(SubChannelId schid)
> >> static int run_ccw(VDev *vdev, int cmd, void *ptr, int len)
> >> {
> >> Ccw1 ccw = {};
> >> - CmdOrb orb = {};
> >> - int r;
> >> -
> >> - enable_subchannel(vdev->schid);
> >> -
> >> - /* start subchannel command */
> >> - orb.fmt = 1;
> >> - orb.cpa = (u32)(long)&ccw;
> >> - orb.lpm = 0x80;
> >>
> >> ccw.cmd_code = cmd;
> >> ccw.cda = (long)ptr;
> >> ccw.count = len;
> >>
> >> - r = ssch(vdev->schid, &orb);
> >> - /*
> >> - * XXX Wait until device is done processing the CCW. For now we can
> >> - * assume that a simple tsch will have finished the CCW
> >> processing,
> >> - * but the architecture allows for asynchronous operation
> >> - */
> >> - if (!r) {
> >> - r = drain_irqs(vdev->schid);
> >> - }
> >> - return r;
> >> + enable_subchannel(vdev->schid);
> >
> > Preexisting, but I'm wondering why we enable the subchannel here and
> > not just once?
> >
> >> + return do_cio(vdev->schid, ptr2u32(&ccw), CCW_FMT1);
> >> }
> >>
> >> static void vring_init(VRing *vr, VqInfo *info)
> >
> >
>
> Good question. It seems to be needed for the net-boot path. Here is the chain:
>
> netmain.c : main()
> netmain,c : net_init()
> virtio-net.c : virtio_net_init()
> virtio.c : virtio_setup_ccw()
> virtio.c : run_ccw()
>
> In this case the subchannel would not already be enabled. I suppose I *could*
> change it,
> but at this point I'm trying to limit how much more code I'm touching :).
> This patch set
> already touches a bit more code than I anticipated. Let me know what your
> thoughts are.
As it doesn't really hurt, I think we can defer this to later. Let's
not make this patch set bigger than needed :)
