1. 24 2月, 2015 2 次提交
  2. 20 10月, 2014 2 次提交
  3. 14 10月, 2014 1 次提交
  4. 03 10月, 2014 1 次提交
    • J
      ide: Update ide_drive_get to be HBA agnostic · d8f94e1b
      John Snow 提交于
      Instead of duplicating the logic for the if_ide
      (bus,unit) mappings, rely on the blockdev layer
      for managing those mappings for us, and use the
      drive_get_by_index call instead.
      
      This allows ide_drive_get to work for AHCI HBAs
      as well, and can be used in the Q35 initialization.
      
      Lastly, change the nature of the argument to
      ide_drive_get so that represents the number of
      total drives we can support, and not the total
      number of buses. This will prevent array overflows
      if the units-per-default-bus property ever needs
      to be adjusted for compatibility reasons.
      Signed-off-by: NJohn Snow <jsnow@redhat.com>
      Reviewed-by: NMarkus Armbruster <armbru@redhat.com>
      Reviewed-by: NMichael S. Tsirkin <mst@redhat.com>
      Message-id: 1412187569-23452-5-git-send-email-jsnow@redhat.com
      Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com>
      d8f94e1b
  5. 09 9月, 2014 1 次提交
  6. 10 7月, 2014 2 次提交
  7. 20 6月, 2014 1 次提交
  8. 19 6月, 2014 1 次提交
  9. 18 6月, 2014 1 次提交
  10. 05 6月, 2014 1 次提交
  11. 28 5月, 2014 1 次提交
  12. 14 2月, 2014 1 次提交
  13. 10 9月, 2013 1 次提交
    • P
      mips_malta: support up to 2GiB RAM · 94c2b6af
      Paul Burton 提交于
      A Malta board can support up to 2GiB of RAM. Since the unmapped kseg0/1
      regions are only 512MiB large & the latter 256MiB of those are taken up
      by the IO region, access to RAM beyond 256MiB must be done through a
      mapped region. In the case of a Linux guest this means we need to use
      highmem.
      
      The mainline Linux kernel does not support highmem for Malta at this
      time, however this can be tested using the linux-mti-3.8 kernel branch
      available from:
      
        git://git.linux-mips.org/pub/scm/linux-mti.git
      
      You should be able to boot a Linux kernel built from the linux-mti-3.8
      branch, with CONFIG_HIGHMEM enabled, using 2GiB RAM by passing "-m 2G"
      to QEMU and appending the following kernel parameters:
      
        mem=256m@0x0 mem=256m@0x90000000 mem=1536m@0x20000000
      
      Note that the upper half of the physical address space of a Malta
      mirrors the lower half (hence the 2GiB limit) except that the IO region
      (0x10000000-0x1fffffff in the lower half) is not mirrored in the upper
      half. That is, physical addresses 0x90000000-0x9fffffff access RAM
      rather than the IO region, resulting in a physical address space
      resembling the following:
      
        0x00000000 -> 0x0fffffff  RAM
        0x10000000 -> 0x1fffffff  I/O
        0x20000000 -> 0x7fffffff  RAM
        0x80000000 -> 0x8fffffff  RAM (mirror of 0x00000000 -> 0x0fffffff)
        0x90000000 -> 0x9fffffff  RAM
        0xa0000000 -> 0xffffffff  RAM (mirror of 0x20000000 -> 0x7fffffff)
      
      The second mem parameter provided to the kernel above accesses the
      second 256MiB of RAM through the upper half of the physical address
      space, making use of the aliasing described above in order to avoid
      the IO region and use the whole 2GiB RAM.
      
      The memory setup may be seen as 'backwards' in this commit since the
      'real' memory is mapped in the upper half of the physical address space
      and the lower half contains the aliases. On real hardware it would be
      typical to see the upper half of the physical address space as the alias
      since the bus addresses generated match the lower half of the physical
      address space. However since the memory accessible in the upper half of
      the physical address space is uninterrupted by the IO region it is
      easiest to map the RAM as a whole there, and functionally it makes no
      difference to the target code.
      
      Due to the requirements of accessing the second 256MiB of RAM through
      a mapping to the upper half of the physical address space it is usual
      for the bootloader to indicate a maximum of 256MiB memory to a kernel.
      This allows kernels which do not support such access to boot on systems
      with more than 256MiB of RAM. It is also the behaviour assumed by Linux.
      QEMUs small generated bootloader is modified to provide this behaviour.
      Signed-off-by: NPaul Burton <paul.burton@imgtec.com>
      Signed-off-by: NYongbok Kim <yongbok.kim@imgtec.com>
      Reviewed-by: NAurelien Jarno <aurelien@aurel32.net>
      Signed-off-by: NAurelien Jarno <aurelien@aurel32.net>
      94c2b6af
  14. 28 8月, 2013 1 次提交
    • M
      hw: Clean up bogus default boot order · c1654732
      Markus Armbruster 提交于
      We set default boot order "cad" in every single machine definition
      except "pseries" and "moxiesim", even though very few boards actually
      care for boot order, and "cad" makes sense for even fewer.
      
      Machines that care:
      
      * pc and its variants
      
        Accept up to three letters 'a', 'b' (undocumented alias for 'a'),
        'c', 'd' and 'n'.  Reject all others (fatal with -boot).
      
      * nseries (n800, n810)
      
        Check whether order starts with 'n'.  Silently ignored otherwise.
      
      * prep, g3beige, mac99
      
        Extract the first character the machine understands (subset of
        'a'..'f').  Silently ignored otherwise.
      
      * spapr
      
        Accept an arbitrary string (vl.c restricts it to contain only
        'a'..'p', no duplicates).
      
      * sun4[mdc]
      
        Use the first character.  Silently ignored otherwise.
      
      Strip characters these machines ignore from their default boot order.
      
      For all other machines, remove the unused default boot order
      alltogether.
      
      Note that my rename of QEMUMachine member boot_order to
      default_boot_order and QEMUMachineInitArgs member boot_device to
      boot_order has a welcome side effect: it makes every use of boot
      orders visible in this patch, for easy review.
      Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
      Reviewed-by: NLaszlo Ersek <lersek@redhat.com>
      Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
      c1654732
  15. 14 8月, 2013 1 次提交
  16. 09 8月, 2013 1 次提交
  17. 31 7月, 2013 1 次提交
  18. 29 7月, 2013 8 次提交
  19. 25 7月, 2013 1 次提交
  20. 10 7月, 2013 2 次提交
  21. 08 7月, 2013 1 次提交
    • D
      pci: Add root bus parameter to pci_nic_init() · 29b358f9
      David Gibson 提交于
      At present, pci_nic_init() and pci_nic_init_nofail() assume that they will
      only create a NIC under the primary PCI root.  As we add support for
      multiple PCI roots, that may no longer be the case.  This patch adds a root
      bus parameter to pci_nic_init() (and updates callers accordingly) to allow
      the machine init code using it to specify the right PCI root for NICs
      created by old-style -net nic parameters.  NICs created new-style, with
      -device can of course be put anywhere.
      Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
      Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
      29b358f9
  22. 04 7月, 2013 1 次提交
  23. 28 6月, 2013 1 次提交
  24. 18 5月, 2013 1 次提交
  25. 30 4月, 2013 2 次提交
  26. 16 4月, 2013 1 次提交
  27. 09 4月, 2013 1 次提交
    • P
      hw: move headers to include/ · 0d09e41a
      Paolo Bonzini 提交于
      Many of these should be cleaned up with proper qdev-/QOM-ification.
      Right now there are many catch-all headers in include/hw/ARCH depending
      on cpu.h, and this makes it necessary to compile these files per-target.
      However, fixing this does not belong in these patches.
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      0d09e41a
  28. 01 3月, 2013 1 次提交