summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2017-05-19s390x/css: ccw translation infrastructureXiao Feng Ren
Implement a basic infrastructure of handling channel I/O instruction interception for passed through subchannels: 1. Branch the code path of instruction interception handling by SubChannel type. 2. For a passed-through subchannel, issue the ORB to kernel to do ccw translation and perform an I/O operation. 3. Assign different condition code based on the I/O result, or trigger a program check. Signed-off-by: Xiao Feng Ren <renxiaof@linux.vnet.ibm.com> Signed-off-by: Dong Jia Shi <bjsdjshi@linux.vnet.ibm.com> Message-Id: <20170517004813.58227-12-bjsdjshi@linux.vnet.ibm.com> Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
2017-05-19s390x/css: introduce and realize ccw-request callbackXiao Feng Ren
Introduce a new callback on subchannel to handle ccw-request. Realize the callback in vfio-ccw device. Besides, resort to the event notifier handler to handling the ccw-request results. 1. Pread the I/O results via MMIO region. 2. Update the scsw info to guest. 3. Inject an I/O interrupt to notify guest the I/O result. Acked-by: Alex Williamson <alex.williamson@redhat.com> Signed-off-by: Xiao Feng Ren <renxiaof@linux.vnet.ibm.com> Signed-off-by: Dong Jia Shi <bjsdjshi@linux.vnet.ibm.com> Message-Id: <20170517004813.58227-11-bjsdjshi@linux.vnet.ibm.com> Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
2017-05-19vfio/ccw: get irqs info and set the eventfd fdDong Jia Shi
vfio-ccw resorts to the eventfd mechanism to communicate with userspace. We fetch the irqs info via the ioctl VFIO_DEVICE_GET_IRQ_INFO, register a event notifier to get the eventfd fd which is sent to kernel via the ioctl VFIO_DEVICE_SET_IRQS, then we can implement read operation once kernel sends the signal. Reviewed-by: Eric Auger <eric.auger@redhat.com> Acked-by: Alex Williamson <alex.williamson@redhat.com> Signed-off-by: Dong Jia Shi <bjsdjshi@linux.vnet.ibm.com> Message-Id: <20170517004813.58227-10-bjsdjshi@linux.vnet.ibm.com> Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
2017-05-19vfio/ccw: get io region infoDong Jia Shi
vfio-ccw provides an MMIO region for I/O operations. We fetch its information via ioctls here, then we can use it performing I/O instructions and retrieving I/O results later on. Reviewed-by: Eric Auger <eric.auger@redhat.com> Acked-by: Alex Williamson <alex.williamson@redhat.com> Signed-off-by: Dong Jia Shi <bjsdjshi@linux.vnet.ibm.com> Message-Id: <20170517004813.58227-9-bjsdjshi@linux.vnet.ibm.com> Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
2017-05-19vfio/ccw: vfio based subchannel passthrough driverXiao Feng Ren
We use the IOMMU_TYPE1 of VFIO to realize the subchannels passthrough, implement a vfio based subchannels passthrough driver called "vfio-ccw". Support qemu parameters in the style of: "-device vfio-ccw,sysfsdev=$mdev_file_path,devno=xx.x.xxxx' Reviewed-by: Eric Auger <eric.auger@redhat.com> Acked-by: Alex Williamson <alex.williamson@redhat.com> Signed-off-by: Xiao Feng Ren <renxiaof@linux.vnet.ibm.com> Signed-off-by: Dong Jia Shi <bjsdjshi@linux.vnet.ibm.com> Message-Id: <20170517004813.58227-8-bjsdjshi@linux.vnet.ibm.com> Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
2017-05-19s390x/css: device support for s390-ccw passthroughDong Jia Shi
In order to support subchannels pass-through, we introduce a s390 subchannel device called "s390-ccw" to hold the real subchannel info. The s390-ccw devices inherit from the abstract CcwDevice which connect to the existing virtual-css-bus. Reviewed-by: Eric Auger <eric.auger@redhat.com> Signed-off-by: Dong Jia Shi <bjsdjshi@linux.vnet.ibm.com> Message-Id: <20170517004813.58227-7-bjsdjshi@linux.vnet.ibm.com> Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
2017-05-19s390x/css: realize css_create_schDong Jia Shi
The S390 virtual css support already has a mechanism to create a virtual subchannel and provide it to the guest. However, to pass-through subchannels to a guest, we need to introduce a new mechanism to create the subchannel according to the real device information. Thus we reconstruct css_create_virtual_sch to a new css_create_sch function to handle all these cases and do allocation and initialization of the subchannel according to the device type and machine configuration. Reviewed-by: Pierre Morel <pmorel@linux.vnet.ibm.com> Signed-off-by: Dong Jia Shi <bjsdjshi@linux.vnet.ibm.com> Message-Id: <20170517004813.58227-6-bjsdjshi@linux.vnet.ibm.com> Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
2017-05-19s390x/css: realize css_sch_build_schibXiao Feng Ren
The S390 virtual css support already has a mechanism to build a virtual subchannel information block (schib) and provide virtual subchannels to the guest. However, to pass-through subchannels to a guest, we need to introduce a new mechanism to build its schib according to the real device information. Thus we realize a new css sch_build_schib function to extract the path_masks, chpids, chpid type from sysfs. To reuse the existing code, we refactor css_add_virtual_chpid to css_add_chpid. Reviewed-by: Pierre Morel <pmorel@linux.vnet.ibm.com> Signed-off-by: Xiao Feng Ren <renxiaof@linux.vnet.ibm.com> Signed-off-by: Dong Jia Shi <bjsdjshi@linux.vnet.ibm.com> Message-Id: <20170517004813.58227-5-bjsdjshi@linux.vnet.ibm.com> Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
2017-05-19s390x/css: add s390-squash-mcss machine optionXiao Feng Ren
We want to support real (i.e. not virtual) channel devices even for guests that do not support MCSS-E (where guests may see devices from any channel subsystem image at once). As all virtio-ccw devices are in css 0xfe (and show up in the default css 0 for guests not activating MCSS-E), we need an option to squash both the virtio subchannels and e.g. passed-through subchannels from their real css (0-3, or 0 for hosts not activating MCSS-E) into the default css. This will be exploited in a later patch. Signed-off-by: Xiao Feng Ren <renxiaof@linux.vnet.ibm.com> Signed-off-by: Dong Jia Shi <bjsdjshi@linux.vnet.ibm.com> Message-Id: <20170517004813.58227-4-bjsdjshi@linux.vnet.ibm.com> Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
2017-05-19linux-headers: updateCornelia Huck
Update against Linux v4.12-rc1. Also include the new vfio_ccw.h header. Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
2017-05-19pc-bios/s390-ccw.img: rebuild imageEric Farman
Contains the following commits: - pc-bios/s390-ccw: Remove duplicate blk_factor adjustment - pc-bios/s390-ccw: Move SCSI block factor to outer read - pc-bios/s390-ccw: Break up virtio-scsi read into multiples - pc-bios/s390-ccw: Refactor scsi_inquiry function - pc-bios/s390-ccw: Get list of supported EVPD pages - pc-bios/s390-ccw: Get Block Limits VPD device data - pc-bios/s390-ccw: Build a reasonable max_sectors limit Signed-off-by: Eric Farman <farman@linux.vnet.ibm.com> Message-Id: <20170510155359.32727-9-farman@linux.vnet.ibm.com> Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
2017-05-19pc-bios/s390-ccw: Build a reasonable max_sectors limitEric Farman
Now that we've read all the possible limits that have been defined for a virtio-scsi controller and the disk we're booting from, it's possible that we are STILL going to exceed the limits of the host device. For example, a "-device scsi-generic" device does not support the Block Limits VPD page. So, let's fallback to something that seems to work for most boot configurations if larger values were specified (including if nothing was explicitly specified, and we took default values). Signed-off-by: Eric Farman <farman@linux.vnet.ibm.com> Message-Id: <20170510155359.32727-8-farman@linux.vnet.ibm.com> Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
2017-05-19pc-bios/s390-ccw: Get Block Limits VPD device dataEric Farman
The "Block Limits" Inquiry VPD page is optional for any SCSI device, but if it's supported it provides a hint of the maximum I/O transfer length for this particular device. If this page is supported by the disk, let's issue that Inquiry and use the minimum of it and the SCSI controller limit. That will cover this scenario: qemu-system-s390x ... -device virtio-scsi-ccw,id=scsi0,max_sectors=32768 ... -drive file=/dev/sda,if=none,id=drive0,format=raw ... -device scsi-hd,bus=scsi0.0,channel=0,scsi-id=0, drive=drive0,id=disk0,max_io_size=1048576 controller: 32768 sectors x 512 bytes/sector = 16777216 bytes disk: 1048576 bytes Now that we have a limit for a virtio-scsi disk, compare that with the limit for the virtio-scsi controller when we actually build the I/O. The minimum of these two limits should be the one we use. Signed-off-by: Eric Farman <farman@linux.vnet.ibm.com> Message-Id: <20170510155359.32727-7-farman@linux.vnet.ibm.com> Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
2017-05-19pc-bios/s390-ccw: Get list of supported VPD pagesEric Farman
The "Supported Pages" Inquiry EVPD page is mandatory for all SCSI devices, and is used as a gateway for what VPD pages the device actually supports. Let's issue this Inquiry, and dump that list with the debug facility. Signed-off-by: Eric Farman <farman@linux.vnet.ibm.com> Message-Id: <20170510155359.32727-6-farman@linux.vnet.ibm.com> Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
2017-05-19pc-bios/s390-ccw: Refactor scsi_inquiry functionEric Farman
If we want to issue any of the SCSI Inquiry EVPD pages, which we do, we could use this function to issue both types of commands with a little bit of refactoring. Signed-off-by: Eric Farman <farman@linux.vnet.ibm.com> Message-Id: <20170510155359.32727-5-farman@linux.vnet.ibm.com> Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
2017-05-19pc-bios/s390-ccw: Break up virtio-scsi read into multiplesEric Farman
A virtio-scsi request that goes through the host sd driver and exceeds the maximum transfer size is automatically broken up for us. But the equivalent request going to the sg driver presumes that any length requirements have already been honored. Let's use the max_sectors field on the virtio-scsi controller device, and break up all requests (both sd and sg) to avoid this problem. Signed-off-by: Eric Farman <farman@linux.vnet.ibm.com> Message-Id: <20170510155359.32727-4-farman@linux.vnet.ibm.com> Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
2017-05-19pc-bios/s390-ccw: Move SCSI block factor to outer readEric Farman
Simple refactoring so that the blk_factor adjustment is moved into virtio_scsi_read_many routine, in preparation for another change. Signed-off-by: Eric Farman <farman@linux.vnet.ibm.com> Message-Id: <20170510155359.32727-3-farman@linux.vnet.ibm.com> Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
2017-05-19pc-bios/s390-ccw: Remove duplicate blk_factor adjustmentEric Farman
When using virtio-scsi, we multiply the READ(10) data_size by a block factor twice when building the I/O. This is fine, since it's only 1 for SCSI disks, but let's clean it up. Signed-off-by: Eric Farman <farman@linux.vnet.ibm.com> Reviewed-by: Christian Borntraeger <borntraeger@de.ibm.com> Message-Id: <20170510155359.32727-2-farman@linux.vnet.ibm.com> Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
2017-05-18Merge remote-tracking branch 'dgilbert/tags/pull-hmp-20170517' into stagingStefan Hajnoczi
HMP pull # gpg: Signature made Wed 17 May 2017 07:03:39 PM BST # gpg: using RSA key 0x0516331EBC5BFDE7 # gpg: Good signature from "Dr. David Alan Gilbert (RH2) <dgilbert@redhat.com>" # gpg: WARNING: This key is not certified with a trusted signature! # gpg: There is no indication that the signature belongs to the owner. # Primary key fingerprint: 45F5 C71B 4A0C B7FB 977A 9FA9 0516 331E BC5B FDE7 * dgilbert/tags/pull-hmp-20170517: ramblock: add new hmp command "info ramblock" utils: provide size_to_str() ramblock: add RAMBLOCK_FOREACH() Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2017-05-18Merge remote-tracking branch 'quintela/tags/migration/20170517' into stagingStefan Hajnoczi
migration/next for 20170517 # gpg: Signature made Wed 17 May 2017 11:46:36 AM BST # gpg: using RSA key 0xF487EF185872D723 # gpg: Good signature from "Juan Quintela <quintela@redhat.com>" # gpg: aka "Juan Quintela <quintela@trasno.org>" # Primary key fingerprint: 1899 FF8E DEBF 58CC EE03 4B82 F487 EF18 5872 D723 * quintela/tags/migration/20170517: migration: Move check_migratable() into qdev.c migration: Move postcopy stuff to postcopy-ram.c migration: Move page_cache.c to migration/ migration: Create migration/blocker.h ram: Rename RAM_SAVE_FLAG_COMPRESS to RAM_SAVE_FLAG_ZERO migration: Pass Error ** argument to {save,load}_vmstate migration: Fix regression with compression threads Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2017-05-18Merge remote-tracking branch 'mst/tags/for_upstream' into stagingStefan Hajnoczi
pci, virtio, vhost: fixes A bunch of fixes that missed the release. Most notably we are reverting shpc back to enabled by default state as guests uses that as an indicator that hotplug is supported (even though it's unused). Unfortunately we can't fix this on the stable branch since that would break migration. Signed-off-by: Michael S. Tsirkin <mst@redhat.com> # gpg: Signature made Wed 17 May 2017 10:42:06 PM BST # gpg: using RSA key 0x281F0DB8D28D5469 # gpg: Good signature from "Michael S. Tsirkin <mst@kernel.org>" # gpg: aka "Michael S. Tsirkin <mst@redhat.com>" # Primary key fingerprint: 0270 606B 6F3C DF3D 0B17 0970 C350 3912 AFBE 8E67 # Subkey fingerprint: 5D09 FD08 71C8 F85B 94CA 8A0D 281F 0DB8 D28D 5469 * mst/tags/for_upstream: exec: abstract address_space_do_translate() pci: deassert intx when pci device unrealize virtio: allow broken device to notify guest Revert "hw/pci: disable pci-bridge's shpc by default" acpi-defs: clean up open brace usage ACPI: don't call acpi_pcihp_device_plug_cb on xen iommu: Don't crash if machine is not PC_MACHINE pc: add 2.10 machine type pc/fwcfg: unbreak migration from qemu-2.5 and qemu-2.6 during firmware boot libvhost-user: fix crash when rings aren't ready hw/virtio: fix vhost user fails to startup when MQ hw/arm/virt: generate 64-bit addressable ACPI objects hw/acpi-defs: replace leading X with x_ in FADT field names Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2017-05-18exec: abstract address_space_do_translate()Peter Xu
This function is an abstraction helper for address_space_translate() and address_space_get_iotlb_entry(). It does the lookup of address into memory region section, then does proper IOMMU translation if necessary. Refactor the two existing functions to use it. This fixes vhost when IOMMU is disabled by guest. Tested-by: Maxime Coquelin <maxime.coquelin@redhat.com> Signed-off-by: Peter Xu <peterx@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2017-05-18pci: deassert intx when pci device unrealizeHerongguang (Stephen)
If a pci device is not reset by VM (by writing into config space) and unplugged by VM, after that when VM reboots, qemu may assert: pcibus_reset: Assertion `bus->irq_count[i] == 0' failed Cc: qemu-stable@nongnu.org Signed-off-by: herongguang <herongguang.he@huawei.com> Reviewed-by: Marcel Apfelbaum <marcel@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2017-05-18virtio: allow broken device to notify guestGreg Kurz
According to section 2.1.2 of the virtio-1 specification: "The device SHOULD set DEVICE_NEEDS_RESET when it enters an error state that a reset is needed. If DRIVER_OK is set, after it sets DEVICE_NEEDS_RESET, the device MUST send a device configuration change notification to the driver." Commit "f5ed36635d8f virtio: stop virtqueue processing if device is broken" introduced a virtio_error() call that just does that: - internally mark the device as broken - set the DEVICE_NEEDS_RESET bit in the status - send a configuration change notification Unfortunately, virtio_notify_vector(), called by virtio_notify_config(), returns right away when the device is marked as broken and the notification isn't sent in this case. The spec doesn't say whether a broken device can send notifications in other situations or not. But since the driver isn't supposed to do anything but to reset the device, it makes sense to keep the check in virtio_notify_config(). Marking the device as broken AFTER the configuration change notification was sent is enough to fix the issue. Signed-off-by: Greg Kurz <groug@kaod.org> Reviewed-by: Cornelia Huck <cornelia.huck@de.ibm.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
2017-05-18Revert "hw/pci: disable pci-bridge's shpc by default"Marcel Apfelbaum
This reverts commit dc0ae767700c156894e36fab89a745a2dc4173de. Disabling the shpc controller has an undesired side effect. The PCI bridge remains with no attached devices at boot time, and the guest operating systems do not allocate any resources for it, leaving the bridge unusable. Note that the behaviour is dictated by the pci bridge specification. Revert the commit and leave the shpc controller even if is not actually used by any architecture. Slot 0 remains unusable at boot time. Keep shpc off for QEMU 2.9 machines. Signed-off-by: Marcel Apfelbaum <marcel@redhat.com> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2017-05-17ramblock: add new hmp command "info ramblock"Peter Xu
To dump information about ramblocks. It looks like: (qemu) info ramblock Block Name PSize Offset Used Total /objects/mem 2 MiB 0x0000000000000000 0x0000000080000000 0x0000000080000000 vga.vram 4 KiB 0x0000000080060000 0x0000000001000000 0x0000000001000000 /rom@etc/acpi/tables 4 KiB 0x00000000810b0000 0x0000000000020000 0x0000000000200000 pc.bios 4 KiB 0x0000000080000000 0x0000000000040000 0x0000000000040000 0000:00:03.0/e1000.rom 4 KiB 0x0000000081070000 0x0000000000040000 0x0000000000040000 pc.rom 4 KiB 0x0000000080040000 0x0000000000020000 0x0000000000020000 0000:00:02.0/vga.rom 4 KiB 0x0000000081060000 0x0000000000010000 0x0000000000010000 /rom@etc/table-loader 4 KiB 0x00000000812b0000 0x0000000000001000 0x0000000000001000 /rom@etc/acpi/rsdp 4 KiB 0x00000000812b1000 0x0000000000001000 0x0000000000001000 Ramblock is something hidden internally in QEMU implementation, and this command should only be used by mostly QEMU developers on RAM stuff. It is not a command suitable for QMP interface. So only HMP interface is provided for it. Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Signed-off-by: Peter Xu <peterx@redhat.com> Message-Id: <1494562661-9063-4-git-send-email-peterx@redhat.com> Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
2017-05-17utils: provide size_to_str()Peter Xu
Moving the algorithm from print_type_size() into size_to_str() so that other component can also leverage it. With that, refactor print_type_size(). The assert() in that logic is removed though, since even UINT64_MAX would not overflow. Signed-off-by: Peter Xu <peterx@redhat.com> Message-Id: <1494562661-9063-3-git-send-email-peterx@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
2017-05-17ramblock: add RAMBLOCK_FOREACH()Peter Xu
So that it can simplifies the iterators. Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Signed-off-by: Peter Xu <peterx@redhat.com> Message-Id: <1494562661-9063-2-git-send-email-peterx@redhat.com> Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
2017-05-17Merge remote-tracking branch 'ehabkost/tags/x86-and-machine-pull-request' ↵Stefan Hajnoczi
into staging x86 and machine queue, 2017-05-17 # gpg: Signature made Wed 17 May 2017 02:37:54 PM BST # gpg: using RSA key 0x2807936F984DC5A6 # gpg: Good signature from "Eduardo Habkost <ehabkost@redhat.com>" # Primary key fingerprint: 5A32 2FD5 ABC4 D3DB ACCF D1AA 2807 936F 984D C5A6 * ehabkost/tags/x86-and-machine-pull-request: (22 commits) tests: Add [+-]feature and feature=on|off test cases s390-pcibus: No need to set user_creatable=false explicitly xen-sysdev: Remove user_creatable flag virtio-mmio: Remove user_creatable flag sysbus-ohci: Remove user_creatable flag hpet: Remove user_creatable flag generic-sdhci: Remove user_creatable flag esp: Remove user_creatable flag fw_cfg: Remove user_creatable flag unimplemented-device: Remove user_creatable flag isabus-bridge: Remove user_creatable flag allwinner-ahci: Remove user_creatable flag sysbus-ahci: Remove user_creatable flag kvmvapic: Remove user_creatable flag ioapic: Remove user_creatable flag kvmclock: Remove user_creatable flag pflash_cfi01: Remove user_creatable flag fdc: Remove user_creatable flag from sysbus-fdc & SUNW,fdtwo iommu: Remove FIXME comment about user_creatable=true xen-backend: Remove FIXME comment about user_creatable flag ... Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2017-05-17tests: Add [+-]feature and feature=on|off test casesEduardo Habkost
Add test code to ensure features are enabled/disabled correctly in the command-line. The test case use the "feature-words" and "filtered-features" properties to check if the features were enabled/disabled correctly. Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Message-Id: <20170508183205.10884-1-ehabkost@redhat.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2017-05-17s390-pcibus: No need to set user_creatable=false explicitlyEduardo Habkost
TYPE_S390_PCI_HOST_BRIDGE is a subclass of TYPE_PCI_HOST_BRIDGE, which is a subclass of TYPE_SYS_BUS_DEVICE. TYPE_SYS_BUS_DEVICE already sets user_creatable=false, so we don't require an explicit user_creatable=false assignment in s390_pcihost_class_init(). Cc: Alexander Graf <agraf@suse.de> Cc: Christian Borntraeger <borntraeger@de.ibm.com> Cc: Cornelia Huck <cornelia.huck@de.ibm.com> Cc: Frank Blaschka <frank.blaschka@de.ibm.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Marcel Apfelbaum <marcel@redhat.com> Cc: Markus Armbruster <armbru@redhat.com> Cc: Peter Maydell <peter.maydell@linaro.org> Cc: Pierre Morel <pmorel@linux.vnet.ibm.com> Cc: Richard Henderson <rth@twiddle.net> Cc: Thomas Huth <thuth@redhat.com> Cc: Yi Min Zhao <zyimin@linux.vnet.ibm.com> Acked-by: Cornelia Huck <cornelia.huck@de.ibm.com> Acked-by: Marcel Apfelbaum <marcel@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Message-Id: <20170503203604.31462-22-ehabkost@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2017-05-17xen-sysdev: Remove user_creatable flagEduardo Habkost
TYPE_XENSYSDEV is only used internally by xen_be_init(), and is not supposed to be plugged/unplugged dynamically. Remove the user_creatable flag from the device class. Cc: Juergen Gross <jgross@suse.com>, Cc: Peter Maydell <peter.maydell@linaro.org>, Cc: Thomas Huth <thuth@redhat.com> Cc: sstabellini@kernel.org Cc: Markus Armbruster <armbru@redhat.com>, Cc: Marcel Apfelbaum <marcel@redhat.com>, Cc: Laszlo Ersek <lersek@redhat.com> Acked-by: Juergen Gross <jgross@suse.com> Acked-by: Marcel Apfelbaum <marcel@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Message-Id: <20170503203604.31462-21-ehabkost@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2017-05-17virtio-mmio: Remove user_creatable flagEduardo Habkost
virtio-mmio needs to be wired and mapped by other device or board code, and won't work with -device. Remove the user_creatable flag from the device class. Cc: Laszlo Ersek <lersek@redhat.com> Cc: Marcel Apfelbaum <marcel@redhat.com> Cc: Peter Maydell <peter.maydell@linaro.org> Cc: Shannon Zhao <zhaoshenglong@huawei.com> Cc: "Michael S. Tsirkin" <mst@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Acked-by: Marcel Apfelbaum <marcel@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Message-Id: <20170503203604.31462-20-ehabkost@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2017-05-17sysbus-ohci: Remove user_creatable flagEduardo Habkost
sysbus-ohci needs to be mapped and wired by device or board code, and won't work with -device. Remove the user_creatable flag from the device class. Cc: Marcel Apfelbaum <marcel@redhat.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Marcel Apfelbaum <marcel@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Message-Id: <20170503203604.31462-19-ehabkost@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2017-05-17hpet: Remove user_creatable flagEduardo Habkost
hpet needs to be mapped and wired by the board code and won't work with -device. Remove the user_creatable flag from the device class. Cc: Marcel Apfelbaum <marcel@redhat.com> Cc: "Michael S. Tsirkin" <mst@redhat.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Acked-by: Marcel Apfelbaum <marcel@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Message-Id: <20170503203604.31462-18-ehabkost@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2017-05-17generic-sdhci: Remove user_creatable flagEduardo Habkost
generic-sdhci needs to be wired by other devices' code, so it can't be used with -device. Remove the user_creatable flag from the device class. Cc: Peter Maydell <peter.maydell@linaro.org> Cc: "Edgar E. Iglesias" <edgar.iglesias@gmail.com> Cc: David Gibson <david@gibson.dropbear.id.au> Cc: Alexander Graf <agraf@suse.de> Cc: "Michael S. Tsirkin" <mst@redhat.com> Cc: Marcel Apfelbaum <marcel@redhat.com> Cc: Prasad J Pandit <pjp@fedoraproject.org> Cc: Alistair Francis <alistair.francis@xilinx.com> Reviewed-by: Alistair Francis <alistair.francis@xilinx.com> Acked-by: Marcel Apfelbaum <marcel@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Message-Id: <20170503203604.31462-17-ehabkost@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2017-05-17esp: Remove user_creatable flagEduardo Habkost
esp devices aren't going to work with -device, as they need IRQs to be connected and mmio to be mapped (this is done by esp_init()). Remove the user_creatable flag from the device class. Cc: Marcel Apfelbaum <marcel@redhat.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Acked-by: Marcel Apfelbaum <marcel@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Message-Id: <20170503203604.31462-16-ehabkost@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2017-05-17fw_cfg: Remove user_creatable flagEduardo Habkost
fw_cfg won't work with -device, as: * fw_cfg_init1() won't get called for the device; * The device won't appear at /machine/fw_cfg, and won't work with the -fw_cfg command-line option. Remove the user_creatable flag from the device class. Cc: Marcel Apfelbaum <marcel@redhat.com> Cc: "Michael S. Tsirkin" <mst@redhat.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Gabriel L. Somlo <somlo@cmu.edu> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Acked-by: Marcel Apfelbaum <marcel@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Message-Id: <20170503203604.31462-15-ehabkost@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2017-05-17unimplemented-device: Remove user_creatable flagEduardo Habkost
unimplemented-device needs to be created and mapped using create_unimplemented_device() (or equivalent code), and won't work with -device. Remove the user_creatable flag from the device class. Cc: Marcel Apfelbaum <marcel@redhat.com> Cc: Peter Maydell <peter.maydell@linaro.org> Cc: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Acked-by: Marcel Apfelbaum <marcel@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Message-Id: <20170503203604.31462-14-ehabkost@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2017-05-17isabus-bridge: Remove user_creatable flagEduardo Habkost
isabus-bridge needs to be created by isa_bus_new(), and won't work with -device, as it won't create the TYPE_ISA_BUS bus itself. Remove the user_creatable flag from the device class. Cc: Marcel Apfelbaum <marcel@redhat.com> Cc: "Michael S. Tsirkin" <mst@redhat.com> Acked-by: Marcel Apfelbaum <marcel@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Message-Id: <20170503203604.31462-13-ehabkost@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2017-05-17allwinner-ahci: Remove user_creatable flagEduardo Habkost
allwinner-ahci needs its IRQ to be connected and mmio to be mapped (this is done by the alwinner-a10 device realize method), and won't work with -device. Remove the user_creatable flag from the device class. Cc: John Snow <jsnow@redhat.com> Cc: qemu-block@nongnu.org Cc: Beniamino Galvani <b.galvani@gmail.com> Cc: Peter Maydell <peter.maydell@linaro.org> Cc: qemu-arm@nongnu.org Cc: Marcel Apfelbaum <marcel@redhat.com> Acked-by: John Snow <jsnow@redhat.com> Acked-by: Marcel Apfelbaum <marcel@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Message-Id: <20170503203604.31462-12-ehabkost@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2017-05-17sysbus-ahci: Remove user_creatable flagEduardo Habkost
The sysbus-ahci devices are supposed to be created and wired by code from other devices, like calxeda_init() and xlnx_zynqmp_realize(), and won't work with -device. Remove the user_creatable flag from the device class. Cc: John Snow <jsnow@redhat.com> Cc: qemu-block@nongnu.org Cc: Rob Herring <robh@kernel.org> Cc: Peter Maydell <peter.maydell@linaro.org> Cc: Alistair Francis <alistair.francis@xilinx.com> Cc: "Edgar E. Iglesias" <edgar.iglesias@gmail.com> Cc: Marcel Apfelbaum <marcel@redhat.com> Reviewed-by: Alistair Francis <alistair.francis@xilinx.com> Acked-by: John Snow <jsnow@redhat.com> Acked-by: Marcel Apfelbaum <marcel@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Message-Id: <20170503203604.31462-11-ehabkost@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2017-05-17kvmvapic: Remove user_creatable flagEduardo Habkost
The kvmvapic device is only usable when created by apic_common_realize(), not using -device. Remove the user_creatable flag from the device class. Cc: Igor Mammedov <imammedo@redhat.com> Cc: Marcel Apfelbaum <marcel@redhat.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Richard Henderson <rth@twiddle.net> Cc: Eduardo Habkost <ehabkost@redhat.com> Cc: "Michael S. Tsirkin" <mst@redhat.com> Acked-by: Marcel Apfelbaum <marcel@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Message-Id: <20170503203604.31462-10-ehabkost@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2017-05-17ioapic: Remove user_creatable flagEduardo Habkost
An ioapic device is already created by the q35 initialization code, and using "-device ioapic" or "-device kvm-ioapic" will always fail with "Only 1 ioapics allowed". Remove the user_creatable flag from the ioapic device classes. Cc: Igor Mammedov <imammedo@redhat.com> Cc: Marcel Apfelbaum <marcel@redhat.com> Cc: "Michael S. Tsirkin" <mst@redhat.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Richard Henderson <rth@twiddle.net> Cc: Eduardo Habkost <ehabkost@redhat.com> Acked-by: Marcel Apfelbaum <marcel@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Message-Id: <20170503203604.31462-9-ehabkost@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2017-05-17kvmclock: Remove user_creatable flagEduardo Habkost
kvmclock should be used by guests only when the appropriate CPUID feature flags are set on the VCPU, and it is automatically created by kvmclock_create() when those feature flags are set. This means creating a kvmclock device using -device is useless. Remove user_creatable from its device class. Cc: Marcel Apfelbaum <marcel@redhat.com> Cc: "Michael S. Tsirkin" <mst@redhat.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Richard Henderson <rth@twiddle.net> Cc: Thomas Huth <thuth@redhat.com> Acked-by: Marcel Apfelbaum <marcel@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Message-Id: <20170503203604.31462-8-ehabkost@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2017-05-17pflash_cfi01: Remove user_creatable flagEduardo Habkost
TYPE_CFI_PFLASH01 devices need to be mapped by pflash_cfi01_register() (or equivalent) and can't be used with -device. Remove user_creatable from the device class. Cc: Kevin Wolf <kwolf@redhat.com> Cc: Max Reitz <mreitz@redhat.com> Cc: qemu-block@nongnu.org Cc: Laszlo Ersek <lersek@redhat.com> Cc: Philippe Mathieu-Daudé <f4bug@amsat.org> Cc: Marcel Apfelbaum <marcel@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Acked-by: Marcel Apfelbaum <marcel@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Message-Id: <20170503203604.31462-7-ehabkost@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2017-05-17fdc: Remove user_creatable flag from sysbus-fdc & SUNW,fdtwoEduardo Habkost
sysbus-fdc and SUNW,fdtwo devices need IRQs to be wired and mmio to be mapped, and can't be used with -device. Unset user_creatable on their device classes. Cc: John Snow <jsnow@redhat.com> Cc: Kevin Wolf <kwolf@redhat.com> Cc: Marcel Apfelbaum <marcel@redhat.com> Cc: Max Reitz <mreitz@redhat.com> Cc: qemu-block@nongnu.org Cc: Thomas Huth <thuth@redhat.com> Acked-by: John Snow <jsnow@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Acked-by: Marcel Apfelbaum <marcel@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Message-Id: <20170503203604.31462-6-ehabkost@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2017-05-17iommu: Remove FIXME comment about user_creatable=trueEduardo Habkost
amd-iommu and intel-iommu are really meant to be used with -device, so they need user_creatable=true. Remove the FIXME comment. Cc: Marcel Apfelbaum <marcel@redhat.com> Cc: "Michael S. Tsirkin" <mst@redhat.com> Reviewed-by: Marcel Apfelbaum <marcel@redhat.com> Acked-by: Marcel Apfelbaum <marcel@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Message-Id: <20170503203604.31462-5-ehabkost@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2017-05-17xen-backend: Remove FIXME comment about user_creatable flagEduardo Habkost
xen-backend can be plugged/unplugged dynamically when using the Xen accelerator, so keep the user_creatable flag on the device class and remove the FIXME comment. Cc: Juergen Gross <jgross@suse.com>, Cc: Peter Maydell <peter.maydell@linaro.org>, Cc: Thomas Huth <thuth@redhat.com> Cc: sstabellini@kernel.org Cc: Markus Armbruster <armbru@redhat.com>, Cc: Marcel Apfelbaum <marcel@redhat.com>, Cc: Laszlo Ersek <lersek@redhat.com> Acked-by: Juergen Gross <jgross@suse.com> Acked-by: Marcel Apfelbaum <marcel@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Message-Id: <20170503203604.31462-4-ehabkost@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2017-05-17sysbus: Set user_creatable=false by default on TYPE_SYS_BUS_DEVICEEduardo Habkost
commit 33cd52b5d7b9adfd009e95f07e6c64dd88ae2a31 unset cannot_instantiate_with_device_add_yet in TYPE_SYSBUS, making all sysbus devices appear on "-device help" and lack the "no-user" flag in "info qdm". To fix this, we can set user_creatable=false by default on TYPE_SYS_BUS_DEVICE, but this requires setting user_creatable=true explicitly on the sysbus devices that actually work with -device. Fortunately today we have just a few has_dynamic_sysbus=1 machines: virt, pc-q35-*, ppce500, and spapr. virt, ppce500, and spapr have extra checks to ensure just a few device types can be instantiated: * virt supports only TYPE_VFIO_CALXEDA_XGMAC, TYPE_VFIO_AMD_XGBE. * ppce500 supports only TYPE_ETSEC_COMMON. * spapr supports only TYPE_SPAPR_PCI_HOST_BRIDGE. This patch sets user_creatable=true explicitly on those 4 device classes. Now, the more complex cases: pc-q35-*: q35 has no sysbus device whitelist yet (which is a separate bug). We are in the process of fixing it and building a sysbus whitelist on q35, but in the meantime we can fix the "-device help" and "info qdm" bugs mentioned above. Also, despite not being strictly necessary for fixing the q35 bug, reducing the list of user_creatable=true devices will help us be more confident when building the q35 whitelist. xen: We also have a hack at xen_set_dynamic_sysbus(), that sets has_dynamic_sysbus=true at runtime when using the Xen accelerator. This hack is only used to allow xen-backend devices to be dynamically plugged/unplugged. This means today we can use -device with the following 22 device types, that are the ones compiled into the qemu-system-x86_64 and qemu-system-i386 binaries: * allwinner-ahci * amd-iommu * cfi.pflash01 * esp * fw_cfg_io * fw_cfg_mem * generic-sdhci * hpet * intel-iommu * ioapic * isabus-bridge * kvmclock * kvm-ioapic * kvmvapic * SUNW,fdtwo * sysbus-ahci * sysbus-fdc * sysbus-ohci * unimplemented-device * virtio-mmio * xen-backend * xen-sysdev This patch adds user_creatable=true explicitly to those devices, temporarily, just to keep 100% compatibility with existing behavior of q35. Subsequent patches will remove user_creatable=true from the devices that are really not meant to user-creatable on any machine, and remove the FIXME comment from the ones that are really supposed to be user-creatable. This is being done in separate patches because we still don't have an obvious list of devices that will be whitelisted by q35, and I would like to get each device reviewed individually. Cc: Alexander Graf <agraf@suse.de> Cc: Alex Williamson <alex.williamson@redhat.com> Cc: Alistair Francis <alistair.francis@xilinx.com> Cc: Beniamino Galvani <b.galvani@gmail.com> Cc: Christian Borntraeger <borntraeger@de.ibm.com> Cc: Cornelia Huck <cornelia.huck@de.ibm.com> Cc: David Gibson <david@gibson.dropbear.id.au> Cc: "Edgar E. Iglesias" <edgar.iglesias@gmail.com> Cc: Eduardo Habkost <ehabkost@redhat.com> Cc: Frank Blaschka <frank.blaschka@de.ibm.com> Cc: Gabriel L. Somlo <somlo@cmu.edu> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Igor Mammedov <imammedo@redhat.com> Cc: Jason Wang <jasowang@redhat.com> Cc: John Snow <jsnow@redhat.com> Cc: Juergen Gross <jgross@suse.com> Cc: Kevin Wolf <kwolf@redhat.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Marcel Apfelbaum <marcel@redhat.com> Cc: Markus Armbruster <armbru@redhat.com> Cc: Max Reitz <mreitz@redhat.com> Cc: "Michael S. Tsirkin" <mst@redhat.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Peter Maydell <peter.maydell@linaro.org> Cc: Pierre Morel <pmorel@linux.vnet.ibm.com> Cc: Prasad J Pandit <pjp@fedoraproject.org> Cc: qemu-arm@nongnu.org Cc: qemu-block@nongnu.org Cc: qemu-ppc@nongnu.org Cc: Richard Henderson <rth@twiddle.net> Cc: Rob Herring <robh@kernel.org> Cc: Shannon Zhao <zhaoshenglong@huawei.com> Cc: sstabellini@kernel.org Cc: Thomas Huth <thuth@redhat.com> Cc: Yi Min Zhao <zyimin@linux.vnet.ibm.com> Acked-by: John Snow <jsnow@redhat.com> Acked-by: Juergen Gross <jgross@suse.com> Acked-by: Marcel Apfelbaum <marcel@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Message-Id: <20170503203604.31462-3-ehabkost@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> [ehabkost: Small changes at sysbus_device_class_init() comments] Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-16 05:53:47 +0000