- 12 6月, 2018 31 次提交
-
-
由 Cédric Le Goater 提交于
A specific MemoryRegion is required for the LPC HC Firmware address space. Signed-off-by: NCédric Le Goater <clg@kaod.org> Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
-
由 David Hildenbrand 提交于
Factor out cpu core unplug into separate function from spapr_core_release(). Then use generic hotplug_handler_unplug() to trigger cpu core unplug, which would call spapr_machine_device_unplug() -> spapr_core_unplug() in the end. This way unplug operation is not buried in spapr internals and located in the same place like in other targets, following similar logic/call chain across targets. Acked-by: NIgor Mammedov <imammedo@redhat.com> Acked-by: NDavid Gibson <david@gibson.dropbear.id.au> Reviewed-by: NGreg Kurz <groug@kaod.org> Signed-off-by: NDavid Hildenbrand <david@redhat.com> Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
-
由 David Hildenbrand 提交于
Factor out memory unplug into separate function from spapr_lmb_release(). Then use generic hotplug_handler_unplug() to trigger memory unplug, which will call spapr_machine_device_unplug() -> spapr_memory_unplug() in the end. This way unplug operation is not buried in lmb internals and located in the same place like in other targets, following similar logic/call chain across targets. Acked-by: NDavid Gibson <david@gibson.dropbear.id.au> Reviewed-by: NGreg Kurz <groug@kaod.org> Reviewed-by: NIgor Mammedov <imammedo@redhat.com> Signed-off-by: NDavid Hildenbrand <david@redhat.com> Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
-
由 David Hildenbrand 提交于
We'll be handling unplug of e.g. CPUs and PCDIMMs via the general hotplug handler soon, so let's add that handler function. Acked-by: NDavid Gibson <david@gibson.dropbear.id.au> Reviewed-by: NGreg Kurz <groug@kaod.org> Signed-off-by: NDavid Hildenbrand <david@redhat.com> Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
-
由 David Hildenbrand 提交于
Let's finish cleaning up the hotplug handler. This check can be performed in the pre_plug code as the very first thing. Signed-off-by: NDavid Hildenbrand <david@redhat.com> Reviewed-by: NGreg Kurz <groug@kaod.org> Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
-
由 David Hildenbrand 提交于
Let's clean the hotplug handler up by moving lookup of the node into the function where it is actually being used. Signed-off-by: NDavid Hildenbrand <david@redhat.com> Reviewed-by: NGreg Kurz <groug@kaod.org> Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
-
由 David Hildenbrand 提交于
The node property can always be queried and the value has already been verified in pc_dimm_realize(). Acked-by: NDavid Gibson <david@gibson.dropbear.id.au> Reviewed-by: NGreg Kurz <groug@kaod.org> Signed-off-by: NDavid Hildenbrand <david@redhat.com> Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
-
由 luporl 提交于
According to PowerISA, the PIR register should be readable in privileged mode also, not only in hypervisor privileged mode. PowerISA 3.0 - 4.3.3 Processor Identification Register "Read access to the PIR is privileged; write access is not provided." Figure 18 in section 4.4.4 explicitly confirms that mfspr PIR is privileged and doesn't require hypervisor state. Cc: David Gibson <david@gibson.dropbear.id.au> Cc: Alexander Graf <agraf@suse.de> Cc: qemu-ppc@nongnu.org Signed-off-by: NLeandro Lupori <leandro.lupori@gmail.com> Reviewed-by: NJose Ricardo Ziviani <joserz@linux.ibm.com> Reviewed-by: NGreg Kurz <groug@kaod.org> Signed-off-by: NGreg Kurz <groug@kaod.org> Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
-
由 BALATON Zoltan 提交于
Make it more readable by converting register indexes to decimal (avoids lot of superfluous 0x0) and distinguish errors caused by accessing non-existent vs. unimplemented registers. No functional change. Signed-off-by: NBALATON Zoltan <balaton@eik.bme.hu> Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
-
由 Cédric Le Goater 提交于
POWER9 introduced a new variant of the eieio instruction using bit 6 as a hint to tell the CPU it is a store-forwarding barrier. The usage of this eieio extension was recently added in Linux 4.17 which activated the "support for a store forwarding barrier at kernel entry/exit". Unfortunately, it is not possible to insert this new eieio instruction without considerable change in ppc_tr_translate_insn(). So instead we loosen the QEMU eieio instruction mask and modify the gen_eieio() helper to test for bit6. On non-POWER9 CPUs, the bit6 is just ignored but a warning is emitted as this is not an instruction software should be using. Signed-off-by: NCédric Le Goater <clg@kaod.org> Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
-
由 Mark Cave-Ayland 提交于
The timers are configured in the mos6522 init function and therefore will always exist, so the function can never return false. Peter also pointed out that this is the only remaining user of VMSTATE_TIMER_PTR_TEST in the codebase, so we might as well just convert it over to VMSTATE_TIMER_PTR and remove mos6522_timer_exist() as it is no longer required. Signed-off-by: NMark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reviewed-by: NPeter Maydell <peter.maydell@linaro.org> Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
-
由 Mark Cave-Ayland 提交于
The 6522 VIA timer frequency cannot be set by altering registers within the device itself and hence it is a fixed property of the machine. Move the initialisation of the timer frequency to the mos6522 reset function and ensure that any subclasses always call the parent reset function so that it isn't required to store the timer frequency within vmstate_mos6522_timer itself. By moving the frequency initialisation to the device reset function then we find that the realize function for both mos6522 and mos6522_cuda becomes obsolete and can simply be removed. Signed-off-by: NMark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
-
由 Mark Cave-Ayland 提交于
Examining the migration stream it can be seen that the mos6522 device state is being stored separately rather than as part of the CUDA device which is incorrect (and likely to cause issues if another mos6522 device is added to the machine). Resolve this by embedding the mos6522_cuda device directly within the CUDA device rather than using a QOM object link to reference the device separately. Note that we also bump the version in vmstate_cuda to reflect this change: this isn't particularly important for the moment as the Mac machine migration isn't 100% reliable due to issues migrating the timebase under TCG. Signed-off-by: NMark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
-
由 Mark Cave-Ayland 提交于
This was accidentally introduced when extracting the 6522 VIA functionality from the CUDA device, and prevents loadvm from completing successfully. Signed-off-by: NMark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
-
由 Mark Cave-Ayland 提交于
This is used in OpenBIOS to define the memory layout of the NVRAM device. Whilst currently left at its default value, add the missing definition to ensure it is reserved. Signed-off-by: NMark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
-
由 Mark Cave-Ayland 提交于
Commits b6712ea3 removed the macio_init() function but missed the header prototype in mac.h. Remove it since it is no longer needed. Signed-off-by: NMark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reviewed-by: NPhilippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
-
由 Mark Cave-Ayland 提交于
Commits 7b19318b and 8ce3f743 removed the pci_pmac_init() and pci_pmac_u3_init() functions but missed the header prototypes in mac.h. Remove them since they are no longer needed. Signed-off-by: NMark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reviewed-by: NPhilippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
-
由 Philippe Mathieu-Daudé 提交于
Signed-off-by: NPhilippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
-
由 Philippe Mathieu-Daudé 提交于
Introduced in 51f233ec. Signed-off-by: NPhilippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
-
由 Philippe Mathieu-Daudé 提交于
Missed while moved in 7092e84d. Signed-off-by: NPhilippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
-
由 Nicholas Piggin 提交于
This allows KVM with the Book3S radix MMU mode to take advantage of THP and install larger pages in the partition scope page tables (the host translation). Signed-off-by: NNicholas Piggin <npiggin@gmail.com> Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
-
由 Cédric Le Goater 提交于
VIO devices have an "irq" property that can be used by the sPAPR IRQ allocator as an IRQ number hint. But it is not set in QEMU nor in libvirt. It brings unnecessary complexity to the underlying layers managing the IRQ number space and it is in full opposition with the new static IRQ allocator we want to introduce in sPAPR. Let's deprecate it to simplify the spapr_irq_alloc routine in the future. Signed-off-by: NCédric Le Goater <clg@kaod.org> Reviewed-by: NThomas Huth <thuth@redhat.com> Reviewed-by: NGreg Kurz <groug@kaod.org> [dwg: Check qtest_enabled() to suppress bogus warnings from make check] Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
-
由 Joel Stanley 提交于
The powerpc Linux kernel[1] and skiboot firmware[2] recently gained changes that cause the Processor Compatibility Register (PCR) SPR to be cleared. These changes cause Linux to fail to boot on the Qemu powernv machine with an error: Trying to write privileged spr 338 (0x152) at 0000000030017f0c With this patch Qemu makes this register available as a hypervisor privileged register. Note that bits set in this register disable features of the processor. Currently the only register state that is supported is when the register is zeroed (enable all features). This is sufficient for guests to once again boot. [1] https://lkml.kernel.org/r/20180518013742.24095-1-mikey@neuling.org [2] https://patchwork.ozlabs.org/patch/915932/Signed-off-by: NJoel Stanley <joel@jms.id.au> Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
-
由 Suraj Jitindar Singh 提交于
Factor out the parsing of struct kvm_ppc_cpu_char in kvmppc_get_cpu_characteristics() into a separate function for each cap for simplicity. Signed-off-by: NSuraj Jitindar Singh <sjitindarsingh@gmail.com> Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
-
由 Mark Cave-Ayland 提交于
Commit 72d3d8f0 "hw/isa/superio: Add a keyboard/mouse controller (8042)" added an 8042 keyboard device to the PC87312 superio device to replace that being used by the prep machine. Unfortunately this commit didn't do the same for the 40p machine which broke the keyboard by registering two 8042 keyboard devices at the same address. Resolve this by similarly removing the 8042 keyboard from the 40p machine as done for the prep machine in commit 72d3d8f0. Signed-off-by: NMark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reviewed-by: NPhilippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: NHervé Poussineau <hpoussin@reactos.org> Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
-
由 Mark Cave-Ayland 提交于
The Linux sandalfoot zImage has an initialisation process which resets the VGA controller by setting all the BAR addresses to zero to access the VGA ioports at their legacy addresses. Unfortunately setting the framebuffer BAR to address 0 makes the framebuffer memory overlap the internal VGA memory causing accesses to fail, and so prevents the kernel from switching successfully to text mode. Since OpenHackWare configures the framebuffer BAR address outside of the legacy VGA internal memory space, remove pci_allow_0_address from the 40p machine class which causes the BAR reprogramming to zero to fail and so the VGA internal memory can be accessed correctly again. Signed-off-by: NMark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
-
由 Thomas Huth 提交于
fprintf() and qemu_log_separate() are frowned upon these days for printing logging information in QEMU. Accessing the wrong SPRs indicates wrong guest behaviour in most cases, and we've got a proper way to log such situations, which is the qemu_log_mask(LOG_GUEST_ERROR, ...) function. So use this function now for logging the bad SPR accesses instead. Signed-off-by: NThomas Huth <thuth@redhat.com> Reviewed-by: NPhilippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: NGreg Kurz <groug@kaod.org> Reviewed-by: NAlistair Francis <alistair.francis@wdc.com> Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
-
由 Philippe Mathieu-Daudé 提交于
Use error_report() + abort() instead of error_setg(&error_abort), as suggested by the "qapi/error.h" documentation: Please don't error_setg(&error_fatal, ...), use error_report() and exit(), because that's more obvious. Likewise, don't error_setg(&error_abort, ...), use assert(). Use abort() instead of the suggested assert() because the error message already got displayed. Suggested-by: NEric Blake <eblake@redhat.com> Signed-off-by: NPhilippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: NEric Auger <eric.auger@redhat.com> Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
-
由 Mark Cave-Ayland 提交于
>From observation of various OS sources it can be seen that the token register introduced in 4e46dcdb "PPC: Newworld: Add uninorth token register" is not required, since the only register currently implemented is the uninorth hardware version which is read-only. Remove the token register implementation and instead return the uninorth version corresponding to the hardware. Signed-off-by: NMark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reviewed-by: NPhilippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
-
由 Mark Cave-Ayland 提交于
Signed-off-by: NMark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reviewed-by: NPhilippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
-
由 BALATON Zoltan 提交于
Signed-off-by: NBALATON Zoltan <balaton@eik.bme.hu> Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
-
- 11 6月, 2018 9 次提交
-
-
由 Peter Maydell 提交于
Block patches: - Various bug fixes - Removal of qemu-img convert's deprecated -s option - qemu-io now exits with an error when a command failed # gpg: Signature made Mon 11 Jun 2018 15:23:42 BST # gpg: using RSA key F407DB0061D5CF40 # gpg: Good signature from "Max Reitz <mreitz@redhat.com>" # Primary key fingerprint: 91BE B60A 30DB 3E88 57D1 1829 F407 DB00 61D5 CF40 * remotes/maxreitz/tags/pull-block-2018-06-11: (29 commits) iotests: Add case for a corrupted inactive image qcow2: Do not mark inactive images corrupt block: Make bdrv_is_writable() public throttle: Fix crash on reopen block/qcow2-bitmap: fix free_bitmap_clusters qemu-img: Remove deprecated -s snapshot_id_or_name option iotests: Fix 219's timing iotests: improve pause_job iotests: Test post-backing convert target behavior qemu-img: Special post-backing convert handling iotests: Add test for rebasing with relative paths qemu-img: Resolve relative backing paths in rebase iotests: Let 216 make use of qemu-io's exit code iotests.py: Add qemu_io_silent qemu-io: Exit with error when a command failed qemu-io: Let command functions return error code qemu-io: Drop command functions' return values iotests: Repairing error during snapshot deletion qcow2: Repair OFLAG_COPIED when fixing leaks iotests: Rework 113 ... Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
-
由 Max Reitz 提交于
Reviewed-by: NJohn Snow <jsnow@redhat.com> Tested-by: NJeff Cody <jcody@redhat.com> Reviewed-by: NJeff Cody <jcody@redhat.com> Signed-off-by: NMax Reitz <mreitz@redhat.com> Message-id: 20180606193702.7113-4-mreitz@redhat.com Signed-off-by: NMax Reitz <mreitz@redhat.com>
-
由 Max Reitz 提交于
When signaling a corruption on a read-only image, qcow2 already makes fatal events non-fatal (i.e., they will not result in the image being closed, and the image header's corrupt flag will not be set). This is necessary because we cannot set the corrupt flag on read-only images, and it is possible because further corruption of read-only images is impossible. Inactive images are effectively read-only, too, so we should do the same for them. bdrv_is_writable() can tell us whether an image can actually be written to, so use its result instead of !bs->read_only. (Otherwise, the assert(!(bs->open_flags & BDRV_O_INACTIVE)) in bdrv_co_pwritev() will fail, crashing qemu.) Cc: qemu-stable@nongnu.org Signed-off-by: NMax Reitz <mreitz@redhat.com> Message-id: 20180606193702.7113-3-mreitz@redhat.com Reviewed-by: NJohn Snow <jsnow@redhat.com> Reviewed-by: NJeff Cody <jcody@redhat.com> Signed-off-by: NMax Reitz <mreitz@redhat.com>
-
由 Max Reitz 提交于
This is a useful function for the whole block layer, so make it public. At the same time, users outside of block.c probably do not need to make use of the reopen functionality, so rename the current function to bdrv_is_writable_after_reopen() create a new bdrv_is_writable() function that just passes NULL to it for the reopen queue. Cc: qemu-stable@nongnu.org Signed-off-by: NMax Reitz <mreitz@redhat.com> Message-id: 20180606193702.7113-2-mreitz@redhat.com Reviewed-by: NJohn Snow <jsnow@redhat.com> Reviewed-by: NJeff Cody <jcody@redhat.com> Signed-off-by: NMax Reitz <mreitz@redhat.com>
-
由 Alberto Garcia 提交于
The throttle block filter can be reopened, and with this it is possible to change the throttle group that the filter belongs to. The way the code does that is the following: - On throttle_reopen_prepare(): create a new ThrottleGroupMember and attach it to the new throttle group. - On throttle_reopen_commit(): detach the old ThrottleGroupMember, delete it and replace it with the new one. The problem with this is that by replacing the ThrottleGroupMember the previous value of io_limits_disabled is lost, causing an assertion failure in throttle_co_drain_end(). This problem can be reproduced by reopening a throttle node: $QEMU -monitor stdio -object throttle-group,id=tg0,x-iops-total=1000 \ -blockdev node-name=hd0,driver=qcow2,file.driver=file,file.filename=hd.qcow2 \ -blockdev node-name=root,driver=throttle,throttle-group=tg0,file=hd0,read-only=on (qemu) block_stream root block/throttle.c:214: throttle_co_drain_end: Assertion `tgm->io_limits_disabled' failed. Since we only want to change the throttle group on reopen there's no need to create a ThrottleGroupMember and discard the old one. It's easier if we simply detach it from its current group and attach it to the new one. Signed-off-by: NAlberto Garcia <berto@igalia.com> Message-id: 20180608151536.7378-1-berto@igalia.com Signed-off-by: NMax Reitz <mreitz@redhat.com>
-
This assert may fail, because bitmap_table is not initialized. Just drop it, as it's obvious, that bitmap_table_load sets bitmap_table parameter only when returning zero. Reported-by: NPavel Butsykin <pbutsykin@virtuozzo.com> Signed-off-by: NVladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Message-id: 20180608101225.2575-1-vsementsov@virtuozzo.com Signed-off-by: NMax Reitz <mreitz@redhat.com>
-
由 Thomas Huth 提交于
It has been marked as deprecated since QEMU v2.0 already, so it is time now to finally remove it. Signed-off-by: NThomas Huth <thuth@redhat.com> Message-id: 1528288551-31641-1-git-send-email-thuth@redhat.com Reviewed-by: NJeff Cody <jcody@redhat.com> Signed-off-by: NMax Reitz <mreitz@redhat.com>
-
由 Max Reitz 提交于
219 has two issues that may lead to sporadic failure, both of which are the result of issuing query-jobs too early after a job has been modified. This can then lead to different results based on whether the modification has taken effect already or not. First, query-jobs is issued right after the job has been created. Besides its current progress possibly being in any random state (which has already been taken care of), its total progress too is basically arbitrary, because the job may not yet have been able to determine it. This patch addresses this by just filtering the total progress, like what has been done for the current progress already. However, for more clarity, the filtering is changed to replace the values by a string 'FILTERED' instead of deleting them. Secondly, query-jobs is issued right after a job has been resumed. The job may or may not yet have had the time to actually perform any I/O, and thus its current progress may or may not have advanced. To make sure it has indeed advanced (which is what the reference output already assumes), keep querying it until it has. Signed-off-by: NMax Reitz <mreitz@redhat.com> Message-id: 20180606190628.8170-1-mreitz@redhat.com Reviewed-by: NEric Blake <eblake@redhat.com> Signed-off-by: NMax Reitz <mreitz@redhat.com>
-
It's possible, that job was finished during waiting. In this case we will see error message "Timeout waiting for job to pause" which is not very informative. So, let's check during waiting iteration that the job exists. Signed-off-by: NVladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Message-id: 20180601115923.17159-1-vsementsov@virtuozzo.com Signed-off-by: NMax Reitz <mreitz@redhat.com>
-