1. 15 6月, 2019 10 次提交
  2. 11 6月, 2019 5 次提交
    • H
      s390/kdump: get rid of compile warning · 2980ba6a
      Heiko Carstens 提交于
      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: NHeiko Carstens <heiko.carstens@de.ibm.com>
      2980ba6a
    • V
      RAID/s390: remove invalid 'r' inline asm operand modifier · eec0a43d
      Vasily Gorbik 提交于
      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: NVasily Gorbik <gor@linux.ibm.com>
      Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
      eec0a43d
    • M
      s390: include/asm/debug.h add kerneldoc markups · a20aa857
      Mauro Carvalho Chehab 提交于
      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: NMauro Carvalho Chehab <mchehab+samsung@kernel.org>
      Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
      a20aa857
    • M
      docs: s390: convert docs to ReST and rename to *.rst · 8b4a503d
      Mauro Carvalho Chehab 提交于
      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: NMauro Carvalho Chehab <mchehab+samsung@kernel.org>
      Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
      8b4a503d
    • M
      docs: Debugging390.txt: convert table to ascii artwork · dc3988f4
      Mauro Carvalho Chehab 提交于
      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: NMauro Carvalho Chehab <mchehab+samsung@kernel.org>
      Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
      dc3988f4
  3. 07 6月, 2019 9 次提交
  4. 04 6月, 2019 11 次提交
  5. 03 6月, 2019 5 次提交
    • E
      s390/cio: Remove vfio-ccw checks of command codes · 9b6e57e5
      Eric Farman 提交于
      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: NEric Farman <farman@linux.ibm.com>
      Message-Id: <20190516161403.79053-4-farman@linux.ibm.com>
      Acked-by: NFarhan Ali <alifm@linux.ibm.com>
      Signed-off-by: NCornelia Huck <cohuck@redhat.com>
      9b6e57e5
    • E
      s390/cio: Allow zero-length CCWs in vfio-ccw · 453eac31
      Eric Farman 提交于
      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: NEric Farman <farman@linux.ibm.com>
      Message-Id: <20190516161403.79053-3-farman@linux.ibm.com>
      Acked-by: NFarhan Ali <alifm@linux.ibm.com>
      Signed-off-by: NCornelia Huck <cohuck@redhat.com>
      453eac31
    • E
      s390/cio: Don't pin vfio pages for empty transfers · 5d87fbf7
      Eric Farman 提交于
      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: NEric Farman <farman@linux.ibm.com>
      Message-Id: <20190516161403.79053-2-farman@linux.ibm.com>
      Acked-by: NFarhan Ali <alifm@linux.ibm.com>
      Signed-off-by: NCornelia Huck <cohuck@redhat.com>
      5d87fbf7
    • E
      s390/cio: Initialize the host addresses in pfn_array · c34a12e6
      Eric Farman 提交于
      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: NEric Farman <farman@linux.ibm.com>
      Message-Id: <20190514234248.36203-5-farman@linux.ibm.com>
      Reviewed-by: NFarhan Ali <alifm@linux.ibm.com>
      Signed-off-by: NCornelia Huck <cohuck@redhat.com>
      c34a12e6
    • E
      s390/cio: Split pfn_array_alloc_pin into pieces · e4f3f18b
      Eric Farman 提交于
      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: NEric Farman <farman@linux.ibm.com>
      Message-Id: <20190514234248.36203-4-farman@linux.ibm.com>
      Reviewed-by: NFarhan Ali <alifm@linux.ibm.com>
      Signed-off-by: NCornelia Huck <cohuck@redhat.com>
      e4f3f18b