1. 15 Jun, 2019 8 commits
  2. 11 Jun, 2019 5 commits
    • Heiko Carstens's avatar
      s390/kdump: get rid of compile warning · 2980ba6a
      Heiko Carstens authored
      Move the CONFIG_CRASH_DUMP ifdef to get rid of this:
      
      arch/s390/kernel/machine_kexec.c:146:22: warning: 'do_start_kdump' defined but not used [-Wunused-function]
      Signed-off-by: default avatarHeiko Carstens <heiko.carstens@de.ibm.com>
      2980ba6a
    • Vasily Gorbik's avatar
      RAID/s390: remove invalid 'r' inline asm operand modifier · eec0a43d
      Vasily Gorbik authored
      gcc silently ignores unsupported inline asm operand modifiers, effectively
      turning '%r0' into '%0', but upcoming clang 9 complains about them:
      lib/raid6/s390vx8.c:63:16: error: invalid operand in inline asm: 'VLM $2,$3,0,${1:r}'
              asm volatile ("VLM %2,%3,0,%r1"
                            ^
      
      Clean up what look like a typo 'r' inline asm operand modifier usage.
      Signed-off-by: default avatarVasily Gorbik <gor@linux.ibm.com>
      Signed-off-by: default avatarHeiko Carstens <heiko.carstens@de.ibm.com>
      eec0a43d
    • Mauro Carvalho Chehab's avatar
      s390: include/asm/debug.h add kerneldoc markups · a20aa857
      Mauro Carvalho Chehab authored
      Instead of keeping the documentation inside s390dbf.rst,
      move them to arch/s390/include/asm/debug.h, using standard
      kernel-doc markups.
      
      Keeping the documentation close to the code helps to keep it
      updated. It also makes easier to document other stuff inside
      debug.h, as all it needs is to add kernel-doc markups inside
      it, as the file will be already be included at the produced
      documentation.
      
      -
      
      Those were converted to kerneldoc using this script specially
      designed to parse ths file, and manually editted:
      
      <script>
      use strict;
      
      my $mode = "";
      my $parameter = "";
      my $ret = "";
      my $descr = "";
      
      sub add_var($)
      {
      	my $ln = shift;
      
      	$ln =~ s/^\s+//;
      	$ln =~ s/\s+$//;
      
      	return if ($ln eq "");
      
      	$ln =~ s/^(\S+)\s+/$1\t/;
      
      	print " * \@$ln\n";
      }
      
      sub add_return($)
      {
      	my $ln = shift;
      
      	print " *\n * Return:\n" if ($mode ne "Return Value:");
      
      	$ln =~ s/^\s+//;
      	$ln =~ s/\s+$//;
      
      	return if ($ln eq "");
      
      	print " * -   $ln\n";
      }
      
      sub add_description($)
      {
      	my $ln = shift;
      
      	print " *\n * \n" if ($mode ne "Description:");
      
      	$ln =~ s/^\s+//;
      	$ln =~ s/\s+$//;
      
      	return if ($ln eq "");
      
      	print " * $ln\n";
      }
      
      sub flush_results()
      {
      	print " */\n\n";
      }
      
      while (<>) {
      	if (m/^[\-]+$/) {
      		flush_results();
      		$mode = "";
      		$parameter = "";
      		$ret = "";
      		$descr = "";
      		next;
      	}
      	if (m/(Parameter:)(.*)/) {
      		print " *\n" if ($mode eq "func");
      		add_var($2);
      		$mode = $1;
      		next;
      	}
      	if (m/(Return Value:)(.*)/) {
      		add_return($2);
      		$mode = $1;
      		next;
      	}
      	if (m/(Description:)(.*)/) {
      		add_description($2);
      		$mode = $1;
      		next;
      	}
      	if ($mode eq "Parameter:") {
      		add_var($_);
      		next;
      	}
      	if ($mode eq "Return Value:") {
      		add_return($_);
      		next;
      	}
      	if ($mode eq "Description:") {
      		add_description($_);
      		next;
      	}
      	next if (m/^\s*$/);
      
      	if (m/^\S+.*\s\*?(\S+)\s*\(/) {
      		if ($mode eq "") {
      			print "/**\n * $1()\n";
      		} else {
      			print " * $1()\n";
      		}
      		$mode="func";
      	}
      }
      flush_results();
      </script>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab+samsung@kernel.org>
      Signed-off-by: default avatarHeiko Carstens <heiko.carstens@de.ibm.com>
      a20aa857
    • Mauro Carvalho Chehab's avatar
      docs: s390: convert docs to ReST and rename to *.rst · 8b4a503d
      Mauro Carvalho Chehab authored
      Convert all text files with s390 documentation to ReST format.
      
      Tried to preserve as much as possible the original document
      format. Still, some of the files required some work in order
      for it to be visible on both plain text and after converted
      to html.
      
      The conversion is actually:
        - add blank lines and identation in order to identify paragraphs;
        - fix tables markups;
        - add some lists markups;
        - mark literal blocks;
        - adjust title markups.
      
      At its new index.rst, let's add a :orphan: while this is not linked to
      the main index.rst file, in order to avoid build warnings.
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab+samsung@kernel.org>
      Signed-off-by: default avatarHeiko Carstens <heiko.carstens@de.ibm.com>
      8b4a503d
    • Mauro Carvalho Chehab's avatar
      docs: Debugging390.txt: convert table to ascii artwork · dc3988f4
      Mauro Carvalho Chehab authored
      The first bit/value table inside the document is very
      hard to read and won't fit ReST format. Also, some columns aren't
      properly aligned.
      
      Convert it to a nice ascii artwork table with makes it easier to
      read as plain text and is compatible with ReST format parser
      on Sphinx.
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab+samsung@kernel.org>
      Signed-off-by: default avatarHeiko Carstens <heiko.carstens@de.ibm.com>
      dc3988f4
  3. 07 Jun, 2019 9 commits
  4. 04 Jun, 2019 11 commits
  5. 03 Jun, 2019 7 commits
    • Eric Farman's avatar
      s390/cio: Remove vfio-ccw checks of command codes · 9b6e57e5
      Eric Farman authored
      If the CCW being processed is a No-Operation, then by definition no
      data is being transferred.  Let's fold those checks into the normal
      CCW processors, rather than skipping out early.
      
      Likewise, if the CCW being processed is a "test" (a category defined
      here as an opcode that contains zero in the lowest four bits) then no
      special processing is necessary as far as vfio-ccw is concerned.
      These command codes have not been valid since the S/370 days, meaning
      they are invalid in the same way as one that ends in an eight [1] or
      an otherwise valid command code that is undefined for the device type
      in question.  Considering that, let's just process "test" CCWs like
      any other CCW, and send everything to the hardware.
      
      [1] POPS states that a x08 is a TIC CCW, and that having any high-order
      bits enabled is invalid for format-1 CCWs.  For format-0 CCWs, the
      high-order bits are ignored.
      Signed-off-by: default avatarEric Farman <farman@linux.ibm.com>
      Message-Id: <20190516161403.79053-4-farman@linux.ibm.com>
      Acked-by: default avatarFarhan Ali <alifm@linux.ibm.com>
      Signed-off-by: default avatarCornelia Huck <cohuck@redhat.com>
      9b6e57e5
    • Eric Farman's avatar
      s390/cio: Allow zero-length CCWs in vfio-ccw · 453eac31
      Eric Farman authored
      It is possible that a guest might issue a CCW with a length of zero,
      and will expect a particular response.  Consider this chain:
      
         Address   Format-1 CCW
         --------  -----------------
       0 33110EC0  346022CC 33177468
       1 33110EC8  CF200000 3318300C
      
      CCW[0] moves a little more than two pages, but also has the
      Suppress Length Indication (SLI) bit set to handle the expectation
      that considerably less data will be moved.  CCW[1] also has the SLI
      bit set, and has a length of zero.  Once vfio-ccw does its magic,
      the kernel issues a start subchannel on behalf of the guest with this:
      
         Address   Format-1 CCW
         --------  -----------------
       0 021EDED0  346422CC 021F0000
       1 021EDED8  CF240000 3318300C
      
      Both CCWs were converted to an IDAL and have the corresponding flags
      set (which is by design), but only the address of the first data
      address is converted to something the host is aware of.  The second
      CCW still has the address used by the guest, which happens to be (A)
      (probably) an invalid address for the host, and (B) an invalid IDAW
      address (doubleword boundary, etc.).
      
      While the I/O fails, it doesn't fail correctly.  In this example, we
      would receive a program check for an invalid IDAW address, instead of
      a unit check for an invalid command.
      
      To fix this, revert commit 4cebc5d6 ("vfio: ccw: validate the
      count field of a ccw before pinning") and allow the individual fetch
      routines to process them like anything else.  We'll make a slight
      adjustment to our allocation of the pfn_array (for direct CCWs) or
      IDAL (for IDAL CCWs) memory, so that we have room for at least one
      address even though no guest memory will be pinned and thus the
      IDAW will not be populated with a host address.
      Signed-off-by: default avatarEric Farman <farman@linux.ibm.com>
      Message-Id: <20190516161403.79053-3-farman@linux.ibm.com>
      Acked-by: default avatarFarhan Ali <alifm@linux.ibm.com>
      Signed-off-by: default avatarCornelia Huck <cohuck@redhat.com>
      453eac31
    • Eric Farman's avatar
      s390/cio: Don't pin vfio pages for empty transfers · 5d87fbf7
      Eric Farman authored
      The skip flag of a CCW offers the possibility of data not being
      transferred, but is only meaningful for certain commands.
      Specifically, it is only applicable for a read, read backward, sense,
      or sense ID CCW and will be ignored for any other command code
      (SA22-7832-11 page 15-64, and figure 15-30 on page 15-75).
      
      (A sense ID is xE4, while a sense is x04 with possible modifiers in the
      upper four bits.  So we will cover the whole "family" of sense CCWs.)
      
      For those scenarios, since there is no requirement for the target
      address to be valid, we should skip the call to vfio_pin_pages() and
      rely on the IDAL address we have allocated/built for the channel
      program.  The fact that the individual IDAWs within the IDAL are
      invalid is fine, since they aren't actually checked in these cases.
      
      Set pa_nr to zero when skipping the pfn_array_pin() call, since it is
      defined as the number of pages pinned and is used to determine
      whether to call vfio_unpin_pages() upon cleanup.
      
      The pfn_array_pin() routine returns the number of pages that were
      pinned, but now might be skipped for some CCWs.  Thus we need to
      calculate the expected number of pages ourselves such that we are
      guaranteed to allocate a reasonable number of IDAWs, which will
      provide a valid address in CCW.CDA regardless of whether the IDAWs
      are filled in with pinned/translated addresses or not.
      Signed-off-by: default avatarEric Farman <farman@linux.ibm.com>
      Message-Id: <20190516161403.79053-2-farman@linux.ibm.com>
      Acked-by: default avatarFarhan Ali <alifm@linux.ibm.com>
      Signed-off-by: default avatarCornelia Huck <cohuck@redhat.com>
      5d87fbf7
    • Eric Farman's avatar
      s390/cio: Initialize the host addresses in pfn_array · c34a12e6
      Eric Farman authored
      Let's initialize the host address to something that is invalid,
      rather than letting it default to zero.  This just makes it easier
      to notice when a pin operation has failed or been skipped.
      Signed-off-by: default avatarEric Farman <farman@linux.ibm.com>
      Message-Id: <20190514234248.36203-5-farman@linux.ibm.com>
      Reviewed-by: default avatarFarhan Ali <alifm@linux.ibm.com>
      Signed-off-by: default avatarCornelia Huck <cohuck@redhat.com>
      c34a12e6
    • Eric Farman's avatar
      s390/cio: Split pfn_array_alloc_pin into pieces · e4f3f18b
      Eric Farman authored
      The pfn_array_alloc_pin routine is doing too much.  Today, it does the
      alloc of the pfn_array struct and its member arrays, builds the iova
      address lists out of a contiguous piece of guest memory, and asks vfio
      to pin the resulting pages.
      
      Let's effectively revert a significant portion of commit 5c1cfb1c
      ("vfio: ccw: refactor and improve pfn_array_alloc_pin()") such that we
      break pfn_array_alloc_pin() into its component pieces, and have one
      routine that allocates/populates the pfn_array structs, and another
      that actually pins the memory.  In the future, we will be able to
      handle scenarios where pinning memory isn't actually appropriate.
      Signed-off-by: default avatarEric Farman <farman@linux.ibm.com>
      Message-Id: <20190514234248.36203-4-farman@linux.ibm.com>
      Reviewed-by: default avatarFarhan Ali <alifm@linux.ibm.com>
      Signed-off-by: default avatarCornelia Huck <cohuck@redhat.com>
      e4f3f18b
    • Eric Farman's avatar
      s390/cio: Set vfio-ccw FSM state before ioeventfd · 4e31d6ae
      Eric Farman authored
      Otherwise, the guest can believe it's okay to start another I/O
      and bump into the non-idle state.  This results in a cc=2 (with
      the asynchronous CSCH/HSCH code) returned to the guest, which is
      unfortunate since everything is otherwise working normally.
      Signed-off-by: default avatarEric Farman <farman@linux.ibm.com>
      Reviewed-by: default avatarPierre Morel <pmorel@linux.ibm.com>
      Message-Id: <20190514234248.36203-3-farman@linux.ibm.com>
      Reviewed-by: default avatarFarhan Ali <alifm@linux.ibm.com>
      Signed-off-by: default avatarCornelia Huck <cohuck@redhat.com>
      4e31d6ae
    • Eric Farman's avatar
      s390/cio: Update SCSW if it points to the end of the chain · 15f0eb3d
      Eric Farman authored
      Per the POPs [1], when processing an interrupt the SCSW.CPA field of an
      IRB generally points to 8 bytes after the last CCW that was executed
      (there are exceptions, but this is the most common behavior).
      
      In the case of an error, this points us to the first un-executed CCW
      in the chain.  But in the case of normal I/O, the address points beyond
      the end of the chain.  While the guest generally only cares about this
      when possibly restarting a channel program after error recovery, we
      should convert the address even in the good scenario so that we provide
      a consistent, valid, response upon I/O completion.
      
      [1] Figure 16-6 in SA22-7832-11.  The footnotes in that table also state
      that this is true even if the resulting address is invalid or protected,
      but moving to the end of the guest chain should not be a surprise.
      Signed-off-by: default avatarEric Farman <farman@linux.ibm.com>
      Message-Id: <20190514234248.36203-2-farman@linux.ibm.com>
      Reviewed-by: default avatarFarhan Ali <alifm@linux.ibm.com>
      Signed-off-by: default avatarCornelia Huck <cohuck@redhat.com>
      15f0eb3d