1. 17 12月, 2015 1 次提交
  2. 10 11月, 2015 1 次提交
  3. 27 10月, 2015 1 次提交
    • A
      hw/arm/virt: don't use a15memmap directly · 4b280b72
      Andrew Jones 提交于
      We should always go through VirtBoardInfo when we need the memmap.
      To avoid using a15memmap directly, in this case, we need to defer
      the max-cpus check from class init time to instance init time. In
      class init we now use MAX_CPUMASK_BITS for max_cpus initialization,
      which is the maximum QEMU supports, and also, incidentally, the
      maximum KVM/gicv3 currently supports. Also, a nice side-effect of
      delaying the max-cpus check is that we now get more appropriate
      error messages for gicv2 machines that try to configure more than
      123 cpus. Before this patch it would complain that the requested
      number of cpus was greater than 123, but for gicv2 configs, it
      should complain that the number is greater than 8.
      Signed-off-by: NAndrew Jones <drjones@redhat.com>
      Message-id: 1445189728-860-3-git-send-email-drjones@redhat.com
      Reviewed-by: NPeter Maydell <peter.maydell@linaro.org>
      Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
      4b280b72
  4. 19 10月, 2015 2 次提交
  5. 16 10月, 2015 2 次提交
  6. 24 9月, 2015 1 次提交
  7. 19 9月, 2015 2 次提交
  8. 09 9月, 2015 2 次提交
  9. 07 9月, 2015 3 次提交
  10. 13 8月, 2015 4 次提交
  11. 26 6月, 2015 1 次提交
    • P
      hw/arm/virt: Make block devices default to virtio · 4e2c0b2a
      Peter Maydell 提交于
      Now we have virtio-pci, we can make the virt board's default block
      device type be IF_VIRTIO. This allows users to use simplified
      command lines that don't have to explicitly create virtio-pci-blk
      devices; the -hda &c very short options now also work.
      
      This means we also need to set no_cdrom to avoid getting a
      default cdrom device -- this is needed because the virtio-blk
      device will fail if it is connected to a block backend with
      no media, which is what the default cdrom device typically is.
      Providing a cdrom with media via -cdrom will succeed, but silently
      create a device with non-removable medium. this is probably
      not really what the user wants, but is the best we can do now.
      
      Note that this change means that some command lines which used
      to work (by accident) will stop working. Where a drive was connected
      manually to a device but without 'if=none' being specified, we
      used to treat this as an IDE drive, which we would then not autoplug
      because the board doesn't support IDE. Now we will treat it as a
      virtio disk and autoplug it, which means the attempt to use the
      drive manually will fail:
        qemu-system-arm: -drive file=img.qcow2,id=foo: Drive 'foo' is already
        in use because it has been automatically connected to another device
        (did you need 'if=none' in the drive options?)
      The command line will have to be changed to include 'if=none', as the
      error message suggests.
      Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
      Reviewed-by: NMarkus Armbruster <armbru@redhat.com>
      Reviewed-by: NStefan Hajnoczi <stefanha@redhat.com>
      Message-id: 1435068107-12594-4-git-send-email-peter.maydell@linaro.org
      4e2c0b2a
  12. 19 6月, 2015 1 次提交
  13. 16 6月, 2015 2 次提交
  14. 05 6月, 2015 1 次提交
  15. 02 6月, 2015 5 次提交
  16. 29 5月, 2015 4 次提交
  17. 12 5月, 2015 1 次提交
  18. 09 4月, 2015 1 次提交
  19. 02 4月, 2015 2 次提交
  20. 19 3月, 2015 2 次提交
  21. 11 3月, 2015 1 次提交
    • A
      hw/arm/virt: fix cmdline parsing bug with CPU options and smp > 1 · 886bc7a0
      Ard Biesheuvel 提交于
      The recently introduced feature that allows 32 bit guests to be
      executed under KVM on a 64-bit host incorrectly handles the case
      where more than 1 cpu is specified using '-smp N'
      
      For instance, this invocation of qemu
      
        qemu-system-aarch64 -M virt -cpu cortex-a57,aarch64=off -smp 2
      
      produces the following error
      
        qemu-system-aarch64: Expected key=value format, found aarch64
      
      which is caused by the destructive parsing performed by
      cpu_common_parse_features(), resulting in subsequent attempts
      to parse the CPU option string (for each additional CPU) to fail.
      
      So duplicate the string before parsing it, and free it directly
      afterwards.
      Signed-off-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
      Reviewed-by: NGreg Bellows <greg.bellows@linaro.org>
      Message-id: 1425402380-10488-1-git-send-email-ard.biesheuvel@linaro.org
      Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
      886bc7a0