1. 30 Jan, 2019 1 commit
    • Andre Przywara's avatar
      arm: turn pr_info() into pr_debug() messages · e1c7c62a
      Andre Przywara authored
      
      
      For whatever reason on ARM/arm64 machines kvmtool greets us with quite
      some elaborate messages:
        Info: Loaded kernel to 0x80080000 (18704896 bytes)
        Info: Placing fdt at 0x8fe00000 - 0x8fffffff
        Info: virtio-mmio.devices=0x200@0x10000:36
      
        Info: virtio-mmio.devices=0x200@0x10200:37
      
        Info: virtio-mmio.devices=0x200@0x10400:38
      
      This is not really useful information for the casual user, so change
      those lines to use pr_debug().
      This also fixes the long standing line ending issue for the mmio output.
      Signed-off-by: Andre Przywara's avatarAndre Przywara <andre.przywara@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      e1c7c62a
  2. 22 Jan, 2019 2 commits
  3. 19 Jun, 2018 1 commit
    • Jean-Philippe Brucker's avatar
      Extend memory bank API with memory types · 8f46c736
      Jean-Philippe Brucker authored
      
      
      Introduce memory types RAM and DEVICE, along with a way for subsystems to
      query the global memory banks. This is required by VFIO, which will need
      to pin and map guest RAM so that assigned devices can safely do DMA to it.
      Depending on the architecture, the physical map is made of either one or
      two RAM regions. In addition, this new memory types API paves the way to
      reserved memory regions introduced in a subsequent patch.
      
      For the moment we put vesa and ivshmem memory into the DEVICE category, so
      they don't have to be pinned. This means that physical devices assigned
      with VFIO won't be able to DMA to the vesa frame buffer or ivshmem. In
      order to do that, simply changing the type to "RAM" would work. But to
      keep the types consistent, it would be better to introduce flags such as
      KVM_MEM_TYPE_DMA that would complement both RAM and DEVICE type. We could
      then reuse the API for generating firmware information (that is, for x86
      bios; DT supports reserved-memory description).
      Reviewed-by: default avatarPunit Agrawal <punit.agrawal@arm.com>
      Signed-off-by: default avatarJean-Philippe Brucker <jean-philippe.brucker@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      8f46c736
  4. 24 Oct, 2017 1 commit
    • Wei Chen's avatar
      arm: Allow all terminal ports to be bi-directional · 83042d1e
      Wei Chen authored
      
      
      In kvmtool, the terminal has 4 term-devices at most. And these term-devices
      can connect to serial8250 or virtio console ports. The kvmtool has a loop
      thread to detect the incoming data on these term-devices and then send the
      data to guest through serial8250 or virtio console ports. On x86, kvmtool
      allow to read data from all 4 term-devices. But on ARM, we only support reading
      data from the first term-devices. The data from the other term-devices will
      be ignored.
      
      Currently, we're adding the kvmtool support to runv (a kind of hyper container)
      with Hyperhq guys. Here we're using 3 serial ports in guest to communicate with
      host (Container runtime). On x86, it works fine, but on ARM it could not work.
      Because we're using terminal 2 to send/receive control message, but terminal 2
      is single direction.
      
      In this case, we change the kvm__arch_read_term for ARM to allow reading data
      from all term-devices.
      Signed-off-by: default avatarWei Chen <Wei.Chen@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      83042d1e
  5. 09 Aug, 2016 1 commit
  6. 29 Jul, 2016 1 commit
  7. 18 Nov, 2015 1 commit
  8. 08 Jul, 2015 3 commits
  9. 01 Jun, 2015 10 commits