- 31 10月, 2013 2 次提交
-
-
由 Peter Maydell 提交于
Now that arm_load_kernel doesn't insist on a kernel filename being present, we can remove some unnecessary conditionals in board models. Signed-off-by: NPeter Maydell <peter.maydell@linaro.org> Message-id: 1379980897-21277-3-git-send-email-peter.maydell@linaro.org
-
由 Peter Maydell 提交于
Typically ARM boards will have some kind of flash which might contain a boot ROM; it's therefore a valid use case to provide only an image for the boot ROM and not require QEMU's internal boot loader at all. Remove the fatal error if -kernel isn't specified. Signed-off-by: NPeter Maydell <peter.maydell@linaro.org> Message-id: 1379980897-21277-2-git-send-email-peter.maydell@linaro.org
-
- 25 10月, 2013 2 次提交
-
-
由 Edgar E. Iglesias 提交于
Signed-off-by: NEdgar E. Iglesias <edgar.iglesias@gmail.com>
-
由 Edgar E. Iglesias 提交于
Signed-off-by: NEdgar E. Iglesias <edgar.iglesias@gmail.com>
-
- 18 10月, 2013 4 次提交
-
-
由 Amos Kong 提交于
rtl8139 has same problem as e1000, nic info isn't updated when macaddr is changed in guest. This patch updates the nic info when the last bit of macaddr is written. Signed-off-by: NAmos Kong <akong@redhat.com> Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com>
-
由 Amos Kong 提交于
If we change macaddr in guest by 'ifconfig eth0 hw ether 12:12:12:34:35:36', the mac register of e1000 is already updated, but we don't update network information in qemu. Therefor, the information in monitor is wrong. This patch updates nic info when the second part of macaddr is written. Signed-off-by: NAmos Kong <akong@redhat.com> Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com>
-
由 Amos Kong 提交于
macaddr is reset during device reset, but nic info isn't updated, this problem exists in e1000 & rtl8139 Signed-off-by: NAmos Kong <akong@redhat.com> Acked-by: NMichael S. Tsirkin <mst@redhat.com> Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com>
-
由 Stefan Weil 提交于
Report from valgrind: ==19521== Source and destination overlap in memcpy(0x31d38938, 0x31d38938, 64) ==19521== at 0x4A0A343: memcpy@@GLIBC_2.14 (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==19521== by 0x42774E: virtio_blk_device_init (virtio-blk.c:686) ==19521== by 0x46EE9E: virtio_device_init (virtio.c:1158) ==19521== by 0x25405E: device_realize (qdev.c:178) ==19521== by 0x2559B5: device_set_realized (qdev.c:699) ==19521== by 0x3A819B: property_set_bool (object.c:1315) ==19521== by 0x3A6CE0: object_property_set (object.c:803) Valgrind is right: blk == &s->blks, so it is a memcpy of 64 byte with source == destination which can be removed. Reported-by: NDave Airlie <airlied@gmail.com> Signed-off-by: NStefan Weil <sw@weilnetz.de> Reviewed-by: NPeter Maydell <peter.maydell@linaro.org> Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com>
-
- 17 10月, 2013 6 次提交
-
-
由 Jan Kiszka 提交于
This allows to remove the explicit qemu_flush_coalesced_mmio_buffer calls. Signed-off-by: NJan Kiszka <jan.kiszka@siemens.com> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
-
由 Jan Kiszka 提交于
This allows to remove the explicit qemu_flush_coalesced_mmio_buffer calls - the memory core will invoke them now. Signed-off-by: NJan Kiszka <jan.kiszka@siemens.com> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
-
由 Gerd Hoffmann 提交于
This patch fixes spice display initialization to handle multihead properly. spice-core now keeps track of which QemuConsole has a spice display channel attached to it and which has not. It also manages display channel ids. spice-display looks at all QemuConsoles and will pick up any graphic console not yet bound to a spice channel (which in practice are all non-qxl graphic devices). Result is that (a) you'll get a spice client window for each graphical device now (first only without this patch), and (b) mixing qxl and non-qxl vga cards works properly. Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
-
由 Marc-André Lureau 提交于
hose API are deprecated since 0.11, and qemu depends on 0.12 already. Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
-
由 Andreas Färber 提交于
Commit 4f8a066b (blockdev: Remove IF_* check for read-only blockdev_init) added a usage of bdrv_is_read_only() to sd_init(), which is called for versatilepb, versatileab and xilinx-zynq-a9 machines among others with NULL argument by default, causing the new qom-test to fail. Add a check to prevent this. Suggested-by: NKevin Wolf <kwolf@redhat.com> Signed-off-by: NAndreas Färber <afaerber@suse.de> Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com>
-
由 Ákos Kovács 提交于
CONFIG_NO_* variables replaced with the lnot logical function Signed-off-by: NÁkos Kovács <akoskovacs@gmx.com> [PMM: fixed a few CONFIG_NO_* uses that were missed] Signed-off-by: NPeter Maydell <peter.maydell@linaro.org> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
-
- 11 10月, 2013 2 次提交
-
-
由 Kevin Wolf 提交于
IF_NONE allows read-only, which makes forbidding it in this place for other types pretty much pointless. Instead, make sure that all devices for which the check would have errored out check in their init function that they don't get a read-only BlockDriverState. This catches even cases where IF_NONE and -device is used. Signed-off-by: NKevin Wolf <kwolf@redhat.com> Reviewed-by: NEric Blake <eblake@redhat.com>
-
由 Michael S. Tsirkin 提交于
ATM we set AHCI mode on 1st GHC write. Spec says we should set it on reset. Signed-off-by: NMichael S. Tsirkin <mst@redhat.com> Signed-off-by: NKevin Wolf <kwolf@redhat.com>
-
- 10 10月, 2013 2 次提交
-
-
由 Roger Pau Monné 提交于
Qemu has several hardcoded xenstore paths that are only valid on Dom0. Attempts to launch a Qemu instance (to act as a userspace backend for PV disks) will fail because Qemu is not able to access those paths when running on a domain different than Dom0. Instead make the xenstore paths relative to the domain where Qemu is actually running. Signed-off-by: NRoger Pau Monné <roger.pau@citrix.com> Signed-off-by: NStefano Stabellini <stefano.stabellini@eu.citrix.com> Reviewed-by: NAnthony PERARD <anthony.perard@citrix.com> Cc: xen-devel@lists.xenproject.org Cc: Anthony PERARD <anthony.perard@citrix.com>
-
由 Matthew Daley 提交于
Commit 4472beae modified the semantics of ioreq_{un,}map so that they are idempotent if called when they're not needed (ie., twice in a row). However, it neglected to handle the case where batch mapping is not being used (the default), and one of the grants fails to map. In this case, ioreq_unmap will be called to unwind and unmap any mappings already performed, but ioreq_unmap simply returns due to the aforementioned change (the ioreq has not already been marked as mapped). The frontend user can therefore force xen_disk to leak grant mappings, a per-domain limited resource. Fix by marking the ioreq as mapped before calling ioreq_unmap in this situation. Signed-off-by: NMatthew Daley <mattjd@gmail.com> Signed-off-by: NStefano Stabellini <stefano.stabellini@eu.citrix.com>
-
- 09 10月, 2013 1 次提交
-
-
由 Asias He 提交于
r->buf is hardcoded to 2056 which is (256 + 1) * 8, allowing 256 luns at most. If more than 256 luns are specified by user, we have buffer overflow in scsi_target_emulate_report_luns. To fix, we allocate the buffer dynamically. Signed-off-by: NAsias He <asias@redhat.com> Tested-by: NMichael Roth <mdroth@linux.vnet.ibm.com> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
-
- 05 10月, 2013 2 次提交
-
-
由 Daniel P. Berrange 提交于
If there is no operation driver for the xattr type the functions return '-1' and set errno to '-EOPNOTSUPP'. When the calling code sets 'ret = -errno' this turns into a large positive number. In Linux 3.11, the kernel has switched to using 9p version 9p2000.L, instead of 9p2000.u, which enables support for xattr operations. This on its own is harmless, but for another change which makes it request the xattr with a name 'security.capability'. The result is that the guest sees a succesful return of 95 bytes of data, instead of a failure with errno set to 95. Since the kernel expects a maximum of 20 bytes for an xattr return this gets translated to the unexpected errno ERANGE. This all means that when running a binary off a 9p fs in 3.11 kernels you get a fun result of: # ./date sh: ./date: Numerical result out of range The only workaround is to pass 'version=9p2000.u' when mounting the 9p fs in the guest, to disable all use of xattrs. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com> Reviewed-by: NAneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com> Signed-off-by: NMichael Tokarev <mjt@tls.msk.ru>
-
由 Alex Williamson 提交于
VFIO is always little endian so do byte swapping of our mask on the way in and byte swapping of the size on the way out. Signed-off-by: NAlex Williamson <alex.williamson@redhat.com> Reported-by: NAlexey Kardashevskiy <aik@ozlabs.ru>
-
- 04 10月, 2013 2 次提交
-
-
由 Alex Williamson 提交于
Just to be sure we don't jump off any NULL pointer cliffs. Signed-off-by: NAlex Williamson <alex.williamson@redhat.com> Reported-by: NPaolo Bonzini <pbonzini@redhat.com>
-
由 Jan Kiszka 提交于
rom_state_paddr is guest provided (caller address of outw(VAPIC_PORT) + writen 16-bit value) and can be influenced to point beyond the end of the host memory backing the guest's RAM. Make sure we do not use this pointer to actually read beyond the limits. Reading arbitrary guest bytes is harmless, the guest kernel has to manage access to this I/O port anyway. Signed-off-by: NJan Kiszka <jan.kiszka@siemens.com> Acked-by: NMichael S. Tsirkin <mst@redhat.com> Signed-off-by: NGleb Natapov <gleb@redhat.com>
-
- 03 10月, 2013 9 次提交
-
-
由 Alexey Kardashevskiy 提交于
Memory regions can easily be 2^64 byte long and therefore overflow for just a bit but that is enough for int128_get64() to assert. This takes care of debug printing of huge section sizes. Signed-off-by: NAlexey Kardashevskiy <aik@ozlabs.ru> Signed-off-by: NAlex Williamson <alex.williamson@redhat.com>
-
由 Alex Williamson 提交于
Now that VFIO has a PCI hot reset interface, take advantage of it. There are two modes that we need to consider. The first is when only one device within the set of devices affected is actually assigned to the guest. In this case the other devices are are just held by VFIO for isolation and we can pretend they're not there, doing an entire bus reset whenever the device reset callback is triggered. Supporting this case separately allows us to do the best reset we can do of the device even if the device is hotplugged. The second mode is when multiple affected devices are all exposed to the guest. In this case we can only do a hot reset when the entire system is being reset. However, this also allows us to track which individual devices are affected by a reset and only do them once. We split our reset function into pre- and post-reset helper functions prioritize the types of device resets available to us, and create separate _one vs _multi reset interfaces to handle the distinct cases above. Signed-off-by: NAlex Williamson <alex.williamson@redhat.com>
-
由 Ján Veselý 提交于
Device communication errors need to be reported to driver. Add a debug message while at it. Signed-off-by: NJan Vesely <jano.vesely@gmail.com> Acked-by: NGerd Hoffmann <kraxel@gmail.com> Signed-off-by: NMichael Tokarev <mjt@tls.msk.ru>
-
由 Guenter Roeck 提交于
With Linux kernel version 3.3 or later, qemu fails with the following message: sh_serial: unsupported read from 0x18 Aborted Reported-and-analyzed-by: NRob Landley <rob@landley.net> Signed-off-by: NGuenter Roeck <linux@roeck-us.net> Reviewed-by: NPeter Maydell <peter.maydell@linaro.org> Signed-off-by: NMichael Tokarev <mjt@tls.msk.ru>
-
由 Stefan Weil 提交于
From buildbot default_i386_rhel61: CC alpha-softmmu/hw/alpha/typhoon.o hw/alpha/typhoon.c: In function 'typhoon_translate_iommu': hw/alpha/typhoon.c:703: warning: integer constant is too large for 'long' type hw/alpha/typhoon.c:703: warning: integer constant is too large for 'long' type Signed-off-by: NStefan Weil <sw@weilnetz.de> Acked-by: NRichard Henderson <rth@twiddle.net> Signed-off-by: NMichael Tokarev <mjt@tls.msk.ru>
-
由 Alex Williamson 提交于
Remove carriage returns and tweak formatting for error_reports. Signed-off-by: NAlex Williamson <alex.williamson@redhat.com>
-
由 Alex Williamson 提交于
During vfio-pci initfn, the device is not always in a state where the option ROM can be read. In the case of graphics cards, there's often no per function reset, which means we have host driver state affecting whether the option ROM is usable. Ideally we want to move reading the option ROM past any co-assigned device resets to the point where the guest first tries to read the ROM itself. To accomplish this, we switch the memory region for the option rom to an I/O region rather than a memory mapped region. This has the side benefit that we don't waste KVM memory slots for a BAR where we don't care about performance. This also allows us to delay loading the ROM from the device until the first read by the guest. We then use the PCI config space size of the ROM BAR when setting up the BAR through QEMU PCI. Another benefit of this approach is that previously when a user set the ROM to a file using the romfile= option, we still probed VFIO for the parameters of the ROM, which can result in dmesg errors about an invalid ROM. We now only probe VFIO to get the ROM contents if the guest actually tries to read the ROM. Signed-off-by: NAlex Williamson <alex.williamson@redhat.com>
-
由 Alex Williamson 提交于
Not all resets are created equal. PM reset is not very reliable, especially for GPUs, so we might want to opt for a bus reset if a standard reset will only do a D3hot->D0 transition. We can also use this to tell if the standard reset will do a bus reset (if neither has_pm_reset or has_flr is probed, but the device still supports reset). Signed-off-by: NAlex Williamson <alex.williamson@redhat.com>
-
由 Alex Williamson 提交于
When MSI is accelerated through KVM the vectors are only programmed when the guest first enables MSI support. Subsequent writes to the vector address or data fields are ignored. Unfortunately that means we're ignore updates done to adjust SMP affinity of the vectors. MSI SMP affinity already works in non-KVM mode because the address and data fields are read from their backing store on each interrupt. This patch stores the MSIMessage programmed into KVM so that we can determine when changes are made and update the routes. Signed-off-by: NAlex Williamson <alex.williamson@redhat.com>
-
- 29 9月, 2013 5 次提交
-
-
由 Markus Armbruster 提交于
Signed-off-by: NMarkus Armbruster <armbru@redhat.com> Reviewed-by: NEric Blake <eblake@redhat.com> Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
-
由 Markus Armbruster 提交于
Currently, -smbios type=T,NAME=VAL,... adds one field (T,NAME) with value VAL to fw_cfg for each unique NAME. If NAME occurs multiple times, the last one's VAL is used (before the QemuOpts conversion, the first one was used). Multiple -smbios can add multiple fields with the same (T, NAME). SeaBIOS reads all of them from fw_cfg, but uses only the first field (T, NAME). The others are ignored. "First one wins, subsequent ones get ignored silently" isn't nice. We commonly let the last option win. Useful, because it lets you -readconfig first, then selectively override with command line options. Clean up -smbios to work the common way. Accumulate the settings, with later ones overwriting earlier ones. Put the result into fw_cfg (no more useless duplicates). Bonus cleanup: qemu_uuid_parse() no longer sets SMBIOS system uuid by side effect. Signed-off-by: NMarkus Armbruster <armbru@redhat.com> Reviewed-by: NEric Blake <eblake@redhat.com> Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
-
由 Markus Armbruster 提交于
We allow either tables or fields for the same type. Makes sense, because SeaBIOS uses fields only when no tables are present. We do this by searching the SMBIOS blob for a previously added table or field. Error messages look like this: qemu-system-x86_64: -smbios type=1,serial=42: SMBIOS type 1 table already defined, cannot add field User needs to know that "table" is defined by -smbios file=..., and "field" by -smbios type=... Instead of searching the blob, record additions of interest, and check that. Simpler, and makes better error messages possible: qemu-system-x86_64: -smbios file=smbios_type_1.bin: Can't mix file= and type= for same type qemu-system-x86_64: -smbios type=1,serial=42,serial=99: This is the conflicting setting Signed-off-by: NMarkus Armbruster <armbru@redhat.com> Reviewed-by: NEric Blake <eblake@redhat.com> Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
-
由 Markus Armbruster 提交于
So that it can be set in config file for -readconfig. This tightens parsing of -smbios, and makes it more consistent with other options: unknown parameters are rejected, numbers with trailing junk are rejected, when a parameter is given multiple times, last rather than first wins, ... MST: drop one chunk to fix build errors Signed-off-by: NMarkus Armbruster <armbru@redhat.com> Reviewed-by: NEric Blake <eblake@redhat.com> Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
-
由 Markus Armbruster 提交于
It exits on all error conditions but one, where it returns -1. Normalize, and return void. Signed-off-by: NMarkus Armbruster <armbru@redhat.com> Reviewed-by: NEric Blake <eblake@redhat.com> Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
-
- 26 9月, 2013 2 次提交
-
-
由 Anthony PERARD 提交于
Signed-off-by: NAnthony PERARD <anthony.perard@citrix.com> Signed-off-by: NStefano Stabellini <stefano.stabellini@eu.citrix.com>
-
由 Liu, Jinsong 提交于
Currently Xen hvm s3 has a bug coming from the difference between qemu-traditioanl and qemu-xen. For qemu-traditional, the way to resume from hvm s3 is via 'xl trigger' command. However, for qemu-xen, the way to resume from hvm s3 inherited from standard qemu, i.e. via QMP, and it doesn't work under Xen. The root cause is, for qemu-xen, 'xl trigger' command didn't reset devices, while QMP didn't unpause hvm domain though they did qemu system reset. We have two qemu patches and one xl patch to fix Xen hvm s3 bug. This patch is the qemu patch 1. It adjusts qemu wakeup so that Xen s3 resume logic (which will be implemented at qemu patch 2) will be notified after qemu system reset. Signed-off-by: NLiu Jinsong <jinsong.liu@intel.com> Signed-off-by: NStefano Stabellini <stefano.stabellini@eu.citrix.com> Reviewed-by: NPaolo Bonzini <pbonzini@redhat.com> Reviewed-by: NAnthony PERARD <anthony.perard@citrix.com>
-
- 24 9月, 2013 1 次提交
-
-
由 Bandan Das 提交于
Signed-off-by: NBandan Das <bsd@redhat.com> Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
-