Skip to content
Snippets Groups Projects
  1. Jan 31, 2017
  2. May 19, 2016
    • Paolo Bonzini's avatar
      hw: remove pio_addr_t · 89a80e74
      Paolo Bonzini authored
      
      pio_addr_t is almost unused, because these days I/O ports are simply
      accessed through the address space.  cpu_{in,out}[bwl] themselves are
      almost unused; monitor.c and xen-hvm.c could use address_space_read/write
      directly, since they have an integer size at hand.  This leaves qtest as
      the only user of those functions.
      
      On the other hand even portio_* functions use this type; the only
      interesting use of pio_addr_t thus is include/hw/sysbus.h.  I guess I
      could move it there, but I don't see much benefit in that either.  Using
      uint32_t is enough and avoids the need to include ioport.h everywhere.
      
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      89a80e74
    • Paolo Bonzini's avatar
  3. Feb 04, 2016
    • Peter Maydell's avatar
      all: Clean up includes · d38ea87a
      Peter Maydell authored
      
      Clean up includes so that osdep.h is included first and headers
      which it implies are not included manually.
      
      This commit was created with scripts/clean-includes.
      
      Signed-off-by: default avatarPeter Maydell <peter.maydell@linaro.org>
      Message-id: 1454089805-5470-16-git-send-email-peter.maydell@linaro.org
      d38ea87a
  4. Nov 04, 2015
  5. Apr 27, 2015
    • Paolo Bonzini's avatar
      ioport: reserve the whole range of an I/O port in the AddressSpace · 4080a13c
      Paolo Bonzini authored
      
      When an I/O port is more than 1 byte long, ioport.c is currently
      creating "short" regions, for example 0x1ce-0x1ce for the 16-bit
      Bochs index port.  When I/O ports are memory mapped, and thus
      accessed via a subpage_ops memory region, subpage_accepts gets
      confused because it finds a hole at 0x1cf and rejects the access.
      
      In order to fix this, modify registration of the region to cover
      the whole size of the I/O port.  Attempts to access an invalid
      port will be blocked by find_portio returning NULL.
      
      This only affects the VBE DISPI regions.  For all other cases,
      the MemoryRegionPortio entries for 2- or 4-byte accesses overlap
      an entry for 1-byte accesses, thus the size of the memory region
      is not affected.
      
      Reported-by: default avatarZoltan Balaton <balaton@eik.bme.hu>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      4080a13c
    • Paolo Bonzini's avatar
      ioport: loosen assertions on emulation of 16-bit ports · 147ed379
      Paolo Bonzini authored
      
      Right now, ioport.c assumes that the entire range specified with
      MemoryRegionPortio includes a region with size == 1.  This however
      is not true for the VBE DISPI ports, which are 16-bit only.  The
      next patch will make these regions' length equal to two, which can
      cause the assertions to trigger.  Replace them with simple conditionals.
      
      Also, ioport.c will emulate a 16-bit ioport with two distinct reads
      or writes, even if one of the two accesses is out of the bounds given
      by the MemoryRegionPortio array.  Do not do this anymore, instead
      discard writes to the incorrect register and read it as all-ones.
      This ensures that the mrp->read and mrp->write callbacks get an
      in-range ioport number.
      
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      147ed379
    • Paolo Bonzini's avatar
      ioport: remove wrong comment · 30476b22
      Paolo Bonzini authored
      
      ioport.c has not been using an alias since commit b40acf99 (ioport:
      Switch dispatching to memory core layer, 2013-06-24).  Remove the
      obsolete comment.
      
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      30476b22
  6. Apr 26, 2015
  7. Aug 18, 2014
  8. Aug 17, 2014
    • Paolo Bonzini's avatar
      ioport: split deletion and destruction · e3fb0ade
      Paolo Bonzini authored
      
      Of the two functions portio_list_del and portio_list_destroy,
      the latter is just freeing a memory area.  However, portio_list_del
      is the logical equivalent of memory_region_del_subregion so
      destruction of memory regions does not belong there.
      
      Actually, neither of these APIs are in use; portio is mostly used by
      ISA devices or VGAs, and neither of these is currently hot-unpluggable.
      
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      e3fb0ade
  9. Oct 17, 2013
  10. Sep 05, 2013
  11. Jul 25, 2013
  12. Jul 12, 2013
    • Anthony Liguori's avatar
      ioport: remove LITTLE_ENDIAN mark for portio · c3cb8e77
      Anthony Liguori authored
      
      Setting it to LE forces a byte swap when host != guest endian but
      this makes no sense at all.
      
      Herve made the suggestion upon observing that word writes/reads
      were broken into byte writes/reads in such a way as to assume
      devices are interpret registers as LE.
      
      However, even if this were a problem, marking the region as LE is
      not useful because what's essentially happening here is that LE is
      open coded.  So by marking it LE in MemoryRegionOps, we're doing a
      superflous swap.
      
      Now, the portio code is suspicious to begin with.  The dispatch
      layer really has no purpose in splitting I/O requests in the first
      place...
      
      Cc: Hervé Poussineau <hpoussin@reactos.org>
      Cc: Alex Graf <agraf@suse.de>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: default avatarAnthony Liguori <aliguori@us.ibm.com>
      c3cb8e77
  13. Jul 04, 2013
  14. Dec 19, 2012
  15. Mar 19, 2012
  16. Mar 05, 2012
    • Avi Kivity's avatar
      ioport: add destructor method to IORange · c5b703ac
      Avi Kivity authored
      
      Previously all callers had a containing object with a destructor that
      could be used to trigger cleanup of the IORange objects (typically
      just freeing the containing object), but a forthcoming memory API
      change doesn't fit this pattern.  Rather than setting up a new global
      table, extend the ioport system to support destructors.
      
      Signed-off-by: default avatarAvi Kivity <avi@redhat.com>
      c5b703ac
  17. Feb 29, 2012
  18. Oct 11, 2011
  19. Jul 29, 2011
  20. Jul 23, 2011
    • Paolo Bonzini's avatar
      report serial devices created with -device in the PIIX4 config space · 6141dbfe
      Paolo Bonzini authored
      
      Serial and parallel devices created with -device are not reported in
      the PIIX4 configuration space, and are hence not picked up by the DSDT.
      This upsets Windows, which hides them altogether from the guest.
      
      To avoid this, check at the end of machine initialization whether the
      corresponding I/O ports have been registered.  The new function in
      ioport.c does this; this also requires a tweak to isa_unassign_ioport.
      
      I left the comment in piix4_pm_initfn since the registers I moved do
      seem to match the 82371AB datasheet.  There are some quirks though.
      We are setting this bit:
      
          "Device 8 EIO Enable (EIO_EN_DEV8)—R/W. 1=Enable PCI access to the
          device 8 enabled I/O ranges to be claimed by PIIX4 and forwarded
          to the ISA/EIO bus. 0=Disable. The LPT_MON_EN must be set to enable
          the decode."
      
      but not LPT_MON_EN (bit 18 at 50h):
      
          LPT Port Enable (LPT_MON_EN)—R/W. 1=Enable accesses to parallel
          port address range (LPT_DEC_SEL) to generate a device 8 (parallel
          port) decode event. 0=Disable.
      
      We're also setting the LPT_DEC_SEL field (that's the 0x60 written to
      63h) to 11, which means reserved, rather than to 01 (378h-37Fh).
      
      Likewise we're not setting SA_MON_EN, SB_MON_EN (respectively bit 14
      and bit 16 at address 50h) for the serial ports.  However, we're setting
      COMA_DEC_SEL and COMB_DEC_SEL correctly, unlike the corresponding register
      for the parallel port.
      
      All these fields are left as they are, since they are probably only
      meant to be used in the DSDT.
      
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: default avatarAnthony Liguori <aliguori@us.ibm.com>
      6141dbfe
  21. Mar 06, 2011
  22. Nov 21, 2010
    • Avi Kivity's avatar
      Type-safe ioport callbacks · acd1c812
      Avi Kivity authored
      
      The current ioport callbacks are not type-safe, in that they accept an "opaque"
      pointer as an argument whose type must match the argument to the registration
      function; this is not checked by the compiler.
      
      This patch adds an alternative that is type-safe.  Instead of an opaque
      argument, both registation and the callback use a new IOPort type.  The
      callback then uses container_of() to access its main structures.
      
      Currently the old and new methods exist side by side; once the old way is gone,
      we can also save a bunch of memory since the new method requires one pointer
      per ioport instead of 6.
      
      Acked-by: default avatarAnthony Liguori <aliguori@us.ibm.com>
      Signed-off-by: default avatarAvi Kivity <avi@redhat.com>
      Signed-off-by: default avatarAnthony Liguori <aliguori@us.ibm.com>
      acd1c812
  23. Sep 09, 2010
  24. Oct 01, 2009
  25. Sep 20, 2009
  26. Sep 06, 2009
  27. Aug 24, 2009
    • Anthony Liguori's avatar
      Unbreak large mem support by removing kqemu · 4a1418e0
      Anthony Liguori authored
      
      kqemu introduces a number of restrictions on the i386 target.  The worst is that
      it prevents large memory from working in the default build.
      
      Furthermore, kqemu is fundamentally flawed in a number of ways.  It relies on
      the TSC as a time source which will not be reliable on a multiple processor
      system in userspace.  Since most modern processors are multicore, this severely
      limits the utility of kqemu.
      
      kvm is a viable alternative for people looking to accelerate qemu and has the
      benefit of being supported by the upstream Linux kernel.  If someone can
      implement work arounds to remove the restrictions introduced by kqemu, I'm
      happy to avoid and/or revert this patch.
      
      N.B. kqemu will still function in the 0.11 series but this patch removes it from
      the 0.12 series.
      
      Paul, please Ack or Nack this patch.
      
      Signed-off-by: default avatarAnthony Liguori <aliguori@us.ibm.com>
      4a1418e0
  28. Jul 16, 2009
  29. Jul 09, 2009
Loading