1. 01 Apr, 2011 1 commit
  2. 10 Jan, 2011 1 commit
  3. 11 Dec, 2010 1 commit
  4. 17 Sep, 2010 1 commit
  5. 11 Jul, 2010 3 commits
    • Isaku Yamahata's avatar
      pci: set PCI multi-function bit appropriately. · 6eab3de1
      Isaku Yamahata authored
      
      
      Set PCI multi-function bit according to multifunction property.
      PCI address, devfn ,is exported to users as addr property,
      so users can populate pci function(PCIDevice in qemu)
      at arbitrary devfn.
      It means each function(PCIDevice) don't know whether pci device
      (PCIDevice[8]) is multi function or not.
      So this patch allows user to set multifunction bit via property
      and checks whether multifunction bit is set correctly.
      
      Cc:  Juan Quintela <quintela@redhat.com>
      Signed-off-by: default avatarIsaku Yamahata <yamahata@valinux.co.jp>
      Signed-off-by: default avatarBlue Swirl <blauwirbel@gmail.com>
      6eab3de1
    • Isaku Yamahata's avatar
      pci: set multifunction property for normal device. · fecb93c4
      Isaku Yamahata authored
      
      
      use pci_create_simple_multifunction() for normal device which sets
      multifunction bit.
      At the moment, only pc_piix.c and mips_malta.c uses multifunction
      devices with piix3/4 pci-isa bridge.
      And other boards don't populate those devices.
      Signed-off-by: default avatarIsaku Yamahata <yamahata@valinux.co.jp>
      Signed-off-by: default avatarBlue Swirl <blauwirbel@gmail.com>
      fecb93c4
    • Isaku Yamahata's avatar
      pci: don't overwrite multi functio bit in pci header type. · b80d4a98
      Isaku Yamahata authored
      
      
      Don't overwrite pci header type.
      Otherwise, multi function bit which pci_init_header_type() sets
      appropriately is lost.
      Anyway PCI_HEADER_TYPE_NORMAL is zero, so it is unnecessary to zero
      which is already zero cleared.
      
      how to test:
      run qemu and issue info pci to see whether a device in question is
      normal device, not pci-to-pci bridge.
      This is handy because guest os isn't required.
      
      tested changes:
      The following files are covered by using following commands.
      sparc64-softmmu
        apb_pci.c, vga-pci.c, cmd646.c, ne2k_pci.c, sun4u.c
      ppc-softmmu
        grackle_pci.c, cmd646.c, ne2k_pci.c, vga-pci.c, macio.c
      ppc-softmmu -M mac99
        unin_pci.c(uni-north, uni-north-agp)
      ppc64-softmmu
        pci-ohci, ne2k_pci, vga-pci, unin_pci.c(u3-agp)
      x86_64-softmmu
        acpi_piix4.c, ide/piix.c, piix_pci.c
        -vga vmware vmware_vga.c
        -watchdog i6300esb wdt_i6300esb.c
        -usb usb-uhci.c
        -sound ac97 ac97.c
        -nic model=rtl8139 rtl8139.c
        -nic model=pcnet pcnet.c
        -balloon virtio virtio-pci.c:
      
      untested changes:
      The following changes aren't tested.
      prep_pci.c: ppc-softmmu -M prep should cover, but core dumped.
      unin_pci.c(uni-north-pci): the caller is commented out.
      openpic.c: the caller is commented out in ppc_prep.c
      Signed-off-by: default avatarIsaku Yamahata <yamahata@valinux.co.jp>
      Signed-off-by: default avatarBlue Swirl <blauwirbel@gmail.com>
      b80d4a98
  6. 28 May, 2010 1 commit
  7. 15 May, 2010 1 commit
  8. 03 May, 2010 1 commit
  9. 23 Dec, 2009 3 commits
  10. 03 Dec, 2009 1 commit
  11. 01 Dec, 2009 1 commit
  12. 09 Nov, 2009 2 commits
  13. 07 Nov, 2009 1 commit
    • Glauber Costa's avatar
      v3: don't call reset functions on cpu initialization · c1699988
      Glauber Costa authored
      
      
      There is absolutely no need to call reset functions when initializing
      devices. Since we are already registering them, calling qemu_system_reset()
      should suffice. Actually, it is what happens when we reboot the machine,
      and using the same process instead of a special case semantics will even
      allow us to find bugs easier.
      
      Furthermore, the fact that we initialize things like the cpu quite early,
      leads to the need to introduce synchronization stuff like qemu_system_cond.
      This patch removes it entirely. All we need to do is call qemu_system_reset()
      only when we're already sure the system is up and running
      
      I tested it with qemu (with and without io-thread) and qemu-kvm, and it
      seems to be doing okay - although qemu-kvm uses a slightly different patch.
      
      [ v2: user mode still needs cpu_reset, so put it in ifdef. ]
      [ v3: leave qemu_system_cond for now. ]
      Signed-off-by: default avatarGlauber Costa <glommer@redhat.com>
      Signed-off-by: default avatarBlue Swirl <blauwirbel@gmail.com>
      c1699988
  14. 07 Oct, 2009 1 commit
    • Markus Armbruster's avatar
      New qdev_init_nofail() · e23a1b33
      Markus Armbruster authored
      
      
      Like qdev_init(), but terminate program via hw_error() instead of
      returning an error value.
      
      Use it instead of qdev_init() where terminating the program on failure
      is okay, either because it's during machine construction, or because
      we know that failure can't happen.
      
      Because relying in the latter is somewhat unclean, and the former is
      not always obvious, it would be nice to go back to qdev_init() in the
      not-so-obvious cases, only with proper error handling.  I'm leaving
      that for another day, because it involves making sure that error
      values are properly checked by all callers.
      
      Patchworks-ID: 35168
      Signed-off-by: default avatarMarkus Armbruster <armbru@redhat.com>
      Signed-off-by: default avatarAnthony Liguori <aliguori@us.ibm.com>
      e23a1b33
  15. 05 Oct, 2009 2 commits
  16. 01 Oct, 2009 2 commits
  17. 11 Sep, 2009 1 commit
  18. 04 Sep, 2009 14 commits
  19. 27 Aug, 2009 1 commit
    • Gerd Hoffmann's avatar
      qdev: add return value to init() callbacks. · 81a322d4
      Gerd Hoffmann authored
      
      
      Sorry folks, but it has to be.  One more of these invasive qdev patches.
      
      We have a serious design bug in the qdev interface:  device init
      callbacks can't signal failure because the init() callback has no
      return value.  This patch fixes it.
      
      We have already one case in-tree where this is needed:
      Try -device virtio-blk-pci (without drive= specified) and watch qemu
      segfault.  This patch fixes it.
      
      With usb+scsi being converted to qdev we'll get more devices where the
      init callback can fail for various reasons.
      Signed-off-by: default avatarGerd Hoffmann <kraxel@redhat.com>
      Signed-off-by: default avatarAnthony Liguori <aliguori@us.ibm.com>
      81a322d4
  20. 10 Aug, 2009 1 commit