- 17 7月, 2017 20 次提交
-
-
由 Greg Kurz 提交于
In case of error, we must ensure the dynamically allocated base_core_type is freed, like it is done everywhere else in this function. This is a regression introduced in QEMU 2.9 by commit 8149e299. Signed-off-by: NGreg Kurz <groug@kaod.org> Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
-
由 David Gibson 提交于
So far, qemu implements the PAPR Hash Page Table (HPT) resizing extension with TCG. The same implementation will work with KVM PR, but we don't currently allow that. For KVM HV we can only implement resizing with the assistance of the host kernel, which needs a new capability and ioctl()s. This patch adds support for testing the new KVM capability and implementing the resize in terms of KVM facilities when necessary. If we're running on a kernel which doesn't have the new capability flag at all, we fall back to testing for PR vs. HV KVM using the same hack that we already use in a number of places for older kernels. Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
-
由 David Gibson 提交于
We've now implemented a PAPR extension allowing PAPR guest to resize their hash page table (HPT) during runtime. This patch makes use of that facility to allocate smaller HPTs by default. Specifically when a guest is aware of the HPT resize facility, qemu sizes the HPT to the initial memory size, rather than the maximum memory size on the assumption that the guest will resize its HPT if necessary for hot plugged memory. When the initial memory size is much smaller than the maximum memory size (a common configuration with e.g. oVirt / RHEV) then this can save significant memory on the HPT. If the guest does *not* advertise HPT resize awareness when it makes the ibm,client-architecture-support call, qemu resizes the HPT for maxmimum memory size (unless it's been configured not to allow such guests at all). For now we make that reallocation assuming the guest has not yet used the HPT at all. That's true in practice, but not, strictly, an architectural or PAPR requirement. If we need to in future we can fix this by having the client-architecture-support call reboot the guest with the revised HPT size (the client-architecture-support call is explicitly permitted to trigger a reboot in this way). Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au> Reviewed-by: NSuraj Jitindar Singh <sjitindarsingh@gmail.com>
-
由 David Gibson 提交于
We've now implemented a PAPR extensions which allows PAPR guests (i.e. "pseries" machine type) to resize their hash page table during runtime. However, that extension is only enabled if explicitly chosen on the command line. This patch enables it by default for spapr-2.10, but leaves it disabled (by default) for older machine types. Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au> Reviewed-by: NLaurent Vivier <lvivier@redhat.com>
-
由 David Gibson 提交于
This patch implements hypercalls allowing a PAPR guest to resize its own hash page table. This will eventually allow for more flexible memory hotplug. The implementation is partially asynchronous, handled in a special thread running the hpt_prepare_thread() function. The state of a pending resize is stored in SPAPR_MACHINE->pending_hpt. The H_RESIZE_HPT_PREPARE hypercall will kick off creation of a new HPT, or, if one is already in progress, monitor it for completion. If there is an existing HPT resize in progress that doesn't match the size specified in the call, it will cancel it, replacing it with a new one matching the given size. The H_RESIZE_HPT_COMMIT completes transition to a resized HPT, and can only be called successfully once H_RESIZE_HPT_PREPARE has successfully completed initialization of a new HPT. The guest must ensure that there are no concurrent accesses to the existing HPT while this is called (this effectively means stop_machine() for Linux guests). For now H_RESIZE_HPT_COMMIT goes through the whole old HPT, rehashing each HPTE into the new HPT. This can have quite high latency, but it seems to be of the order of typical migration downtime latencies for HPTs of size up to ~2GiB (which would be used in a 256GiB guest). In future we probably want to move more of the rehashing to the "prepare" phase, by having H_ENTER and other hcalls update both current and pending HPTs. That's a project for another day, but should be possible without any changes to the guest interface. Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
-
由 David Gibson 提交于
This introduces stub implementations of the H_RESIZE_HPT_PREPARE and H_RESIZE_HPT_COMMIT hypercalls which we hope to add in a PAPR extension to allow run time resizing of a guest's hash page table. It also adds a new machine property for controlling whether this new facility is available. For now we only allow resizing with TCG, allowing it with KVM will require kernel changes as well. Finally, it adds a new string to the hypertas property in the device tree, advertising to the guest the availability of the HPT resizing hypercalls. This is a tentative suggested value, and would need to be standardized by PAPR before being merged. Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au> Reviewed-by: NSuraj Jitindar Singh <sjitindarsingh@gmail.com> Reviewed-by: NLaurent Vivier <lvivier@redhat.com>
-
由 Alexey Kardashevskiy 提交于
e6f7e110 "ppc/xics: remove the XICSState classes" got rid of XICSState, this is just an leftover. Signed-off-by: NAlexey Kardashevskiy <aik@ozlabs.ru> Reviewed-by: NCédric Le Goater <clg@kaod.org> Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
-
由 Greg Kurz 提交于
Since commit 5c1da812 ("spapr: Remove unnecessary differences between hotplug and coldplug paths"), the CPU DT for the DRC is always allocated. This causes a memory leak for pseries-2.6 and older machine types, that don't support CPU hotplug and don't allocate DRCs for CPUs. Reported-by: NBharata B Rao <bharata@linux.vnet.ibm.com> Signed-off-by: NGreg Kurz <groug@kaod.org> Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
-
由 David Gibson 提交于
According to PAPR, the DR-indicator should only be valid for physical DRCs, not logical DRCs. At the moment we implement it for all DRCs, so restrict it to physical ones only. We move the state to the physical DRC subclass, which means adding some QOM boilerplate to handle the newly distinct type. Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au> Reviewed-by: NDaniel Barboza <danielhb@linux.vnet.ibm.com> Tested-by: NDaniel Barboza <danielhb@linux.vnet.ibm.com>
-
由 David Gibson 提交于
Most of the time, the state of a DRC object is contained in the single 'state' variable. However, during the transition from UNISOLATE to CONFIGURED state requires multiple calls to the ibm,configure-connector RTAS call to retrieve the device tree for the attached device. We need some extra state to keep track of where we're up to in delivering the device tree information to the guest. Currently that extra state is in a sPAPRConfigureConnectorState substructure which is only allocated when we're in the middle of the configure connector process. That sounds like a good idea, but the extra state is only two integers - on many platforms that will take up the same room as the (maybe NULL) ccs pointer even before malloc() overhead. Plus it's another object whose lifetime we need to manage. In short, it's not worth it. So, fold the sPAPRConfigureConnectorState substructure directly into the DRC object. Previously the structure was allocated lazily when the configure-connector call discovers it's not there. Now, we need to initialize the subfields pre-emptively, as soon as we enter UNISOLATE state. Although it's not strictly necessary (the field values should only ever be consulted when in UNISOLATE state), we try to keep them at -1 when in other states, as a debugging aid. Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au> Reviewed-by: NDaniel Barboza <danielhb@linux.vnet.ibm.com> Tested-by: NDaniel Barboza <danielhb@linux.vnet.ibm.com>
-
由 David Gibson 提交于
Each DRC has three fields describing its state: isolation_state, allocation_state and configured. At first this seems like a reasonable representation, since its based directly on the PAPR defined isolation-state and allocation-state indicators. However: * Only a few combinations of the two fields' values are permitted * allocation_state isn't used at all for physical DRCs * The indicators are write only so they don't really have a well defined current value independent of each other This replaces these variables with a single state variable, whose names and numbers are based on the diagram in LoPAPR section 13.4. Along with this we add code to check the current state on various operations and make sure the requested transition is permitted. Strictly speaking, this makes guest visible changes to behaviour (since we probably allowed some transitions we shouldn't have before). However, a hypothetical guest broken by that wasn't PAPR compliant, and probably wouldn't have worked under PowerVM. Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au> Reviewed-by: NDaniel Barboza <danielhb@linux.vnet.ibm.com> Tested-by: NDaniel Barboza <danielhb@linux.vnet.ibm.com>
-
由 David Gibson 提交于
'awaiting_release' indicates that the host has requested an unplug of the device attached to the DRC, but the guest has not (yet) put the device into a state where it is safe to complete removal. 1. Rename it to 'unplug_requested' which to me at least is clearer 2. Remove the ->release_pending() method used to check this from outside spapr_drc.c. The method only plausibly has one implementation, so use a plain function (spapr_drc_unplug_requested()) instead. 3. Remove it from the migration stream. Attempting to migrate mid-unplug is broken not just for spapr - in general management has no good way to determine if the device should be present on the destination or not. So, until that's fixed, there's no point adding extra things to the stream. Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au> Reviewed-by: NGreg Kurz <groug@kaod.org> Tested-by: NDaniel Barboza <danielhb@linux.vnet.ibm.com>
-
由 David Gibson 提交于
This function has two unused parameters - remove them. It also sets awaiting_release on all paths, except one. On that path setting it is harmless, since it will be immediately cleared by spapr_drc_release(). So factor it out of the if statements. Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au> Reviewed-by: NGreg Kurz <groug@kaod.org> Tested-by: NDaniel Barboza <danielhb@linux.vnet.ibm.com>
-
由 David Gibson 提交于
We currently ignore errors from the object_property_del() in spapr_drc_release(). But the only way that could fail is if the property doesn't exist, in which case it's a bug that we're in spapr_drc_release() at all. So change from ignoring to abort()ing on errors. Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
-
由 David Gibson 提交于
spapr_lmb_release() and spapr_core_release() call hotplug_handler_unplug() which after a bunch of indirection calls spapr_memory_unplug() or spapr_core_unplug(). But we already know which is the appropriate thing to call here, so we can just fold it directly into the release function. Once that's done, there's no need for an hc->unplug method in the spapr machine at all: since we also have an hc->unplug_request method, the hotplug core will never use ->unplug. Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au> Reviewed-by: NGreg Kurz <groug@kaod.org> Tested-by: NDaniel Barboza <danielhb@linux.vnet.ibm.com>
-
由 David Gibson 提交于
The awaiting_allocation flag in the DRC was introduced by aab99135 "spapr_drc: Prevent detach racing against attach for CPU DR", allegedly to prevent a guest crash on racing attach and detach. Except.. information from the BZ actually suggests a qemu crash, not a guest crash. And there shouldn't be a problem here anyway: if the guest has already moved the DRC away from UNUSABLE state, the detach would already be deferred, and if it hadn't it should be safe to detach it (the guest should fail gracefully when it attempts to change the allocation state). I think this was probably just a bandaid for some other problem in the state management. So, remove awaiting_allocation and associated code. Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au> Reviewed-by: NLaurent Vivier <lvivier@redhat.com> Reviewed-by: NGreg Kurz <groug@kaod.org> Tested-by: NGreg Kurz <groug@kaod.org> Tested-by: NDaniel Barboza <danielhb@linux.vnet.ibm.com>
-
由 Laurent Vivier 提交于
When migrating a guest which has already had devices hotplugged, libvirt typically starts the destination qemu with -incoming defer, adds those hotplugged devices with qmp, then initiates the incoming migration. This causes problems for the management of spapr DRC state. Because the device is treated as hotplugged, it goes into a DRC state for a device immediately after it's plugged, but before the guest has acknowledged its presence. However, chances are the guest on the source machine *has* acknowledged the device's presence and configured it. If the source has fully configured the device, then DRC state won't be sent in the migration stream: for maximum migration compatibility with earlier versions we don't migrate DRCs in coldplug-equivalent state. That means that the DRC effectively changes state over the migrate, causing problems later on. In addition, logging hotplug events for these devices isn't what we want because a) those events should already have been issued on the source host and b) the event queue should get wiped out by the incoming state anyway. In short, what we really want is to treat devices added before an incoming migration as if they were coldplugged. To do this, we first add a spapr_drc_hotplugged() helper which determines if the device is hotplugged in the sense relevant for DRC state management. We only send hotplug events when this is true. Second, when we add a device which isn't hotplugged in this sense, we force a reset of the DRC state - this ensures the DRC is in a coldplug-equivalent state (there isn't usually a system reset between these device adds and the incoming migration). This is based on an earlier patch by Laurent Vivier, cleaned up and extended. Signed-off-by: NLaurent Vivier <lvivier@redhat.com> Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au> Reviewed-by: NGreg Kurz <groug@kaod.org> Tested-by: NDaniel Barboza <danielhb@linux.vnet.ibm.com>
-
由 David Gibson 提交于
The rtas_error_log structure is marked packed, which strongly suggests its precise layout is important to match an external interface. Along with that one could expect it to have a fixed endianness to match the same interface. That used to be the case - matching the layout of PAPR RTAS event format and requiring BE fields. Now, however, it's only used embedded within sPAPREventLogEntry with the fields in native order, since they're processed internally. Clear that up by removing the nested structure in sPAPREventLogEntry. struct rtas_error_log is moved back to spapr_events.c where it is used as a temporary to help convert the fields in sPAPREventLogEntry to the correct in memory format when delivering an event to the guest. Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
-
由 Daniel Henrique Barboza 提交于
In racing situations between hotplug events and migration operation, a rtas hotplug event could have not yet be delivered to the source guest when migration is started. In this case the pending_events of spapr state need be transmitted to the target so that the hotplug event can be finished on the target. To achieve the minimal VMSD possible to migrate the pending_events list, this patch makes the changes in spapr_events.c: - 'log_type' of sPAPREventLogEntry struct deleted. This information can be derived by inspecting the rtas_error_log summary field. A new function called 'spapr_event_log_entry_type' was added to retrieve the type of a given sPAPREventLogEntry. - sPAPREventLogEntry, epow_log_full and hp_log_full were redesigned. The only data we're going to migrate in the VMSD is the event log data itself, which can be divided in two parts: a rtas_error_log header and an extended event log field. The rtas_error_log header contains information about the size of the extended log field, which can be used inside VMSD as the size parameter of the VBUFFER_ALOC field that will store it. To allow this use, the header.extended_length field must be exposed inline to the VMSD instead of embedded into a 'data' field that holds everything. With this in mind, the following changes were done: * a new 'header' field was added to sPAPREventLogEntry. This field holds a a struct rtas_error_log inline. * the declaration of the 'rtas_error_log' struct was moved to spapr.h to be visible to the VMSD macros. * 'data' field of sPAPREventLogEntry was renamed to 'extended_log' and now holds only the contents of the extended event log. * 'struct rtas_error_log hdr' were taken away from both epow_log_full and hp_log_full. This information is now available at the header field of sPAPREventLogEntry. * epow_log_full and hp_log_full were renamed to epow_extended_log and hp_extended_log respectively. This rename makes it clearer to understand the new purpose of both structures: hold the information of an extended event log field. * spapr_powerdown_req and spapr_hotplug_req_event now creates a sPAPREventLogEntry structure that contains the full rtas log entry. * rtas_event_log_queue and rtas_event_log_dequeue now receives a sPAPREventLogEntry pointer as a parameter instead of a void pointer. - the endianess of the sPAPREventLogEntry header is now native instead of be32. We can use the fields in native endianess internally and write them in be32 in the guest physical memory inside 'check_exception'. This allows the VMSD inside spapr.c to read the correct size of the entended_log field. - inside spapr.c, pending_events is put in a subsection in the spapr state VMSD to make sure migration across different versions is not broken. A small change in rtas_event_log_queue and rtas_event_log_dequeue were also made: instead of calling qdev_get_machine(), both functions now receive a pointer to the sPAPRMachineState. This pointer is already available in the callers of these functions and we don't need to waste resources calling qdev() again. Signed-off-by: NDaniel Henrique Barboza <danielhb@linux.vnet.ibm.com> Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
-
由 David Gibson 提交于
All the DRC subtypes explicitly list instance_size in TypeInfo (all as sizeof(sPAPRDRConnector). This isn't necessary, since if it's not listed it will be derived from the parent type. Worse, this is dangerous, because if a subtype is changed in future to have a larger structure, then subtypes of that subtype also need to have instance_size changed, or it will lead to hard to track memory corruption bugs. Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
-
- 15 7月, 2017 1 次提交
-
-
由 Michael S. Tsirkin 提交于
There's no requirement for RSDP to be installed last by the firmware, so in rare cases vmgen id test hits a race: RSDP is there but VM GEN ID isn't. To fix, switch to common boot sector infrastructure. Cc: Laszlo Ersek <lersek@redhat.com> Cc: Peter Maydell <peter.maydell@linaro.org> Cc: Ben Warren <ben@skyportsystems.com> Signed-off-by: NMichael S. Tsirkin <mst@redhat.com> Reviewed-by: NBen Warren <ben@skyportsystems.com> Message-id: 1500046217-24597-1-git-send-email-mst@redhat.com Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
-
- 14 7月, 2017 19 次提交
-
-
由 Peter Maydell 提交于
Merge sockets 2017/07/11 v3 # gpg: Signature made Fri 14 Jul 2017 16:09:03 BST # gpg: using RSA key 0xBE86EBB415104FDF # gpg: Good signature from "Daniel P. Berrange <dan@berrange.com>" # gpg: aka "Daniel P. Berrange <berrange@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: DAF3 A6FD B26B 6291 2D0E 8E3F BE86 EBB4 1510 4FDF * remotes/berrange/tags/pull-sockets-2017-07-11-3: io: preserve ipv4/ipv6 flags when resolving InetSocketAddress sockets: ensure we don't accept IPv4 clients when IPv4 is disabled sockets: don't block IPv4 clients when listening on "::" sockets: ensure we can bind to both ipv4 & ipv6 separately Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
-
由 Daniel P. Berrange 提交于
The original InetSocketAddress struct may have has_ipv4 and has_ipv6 fields set, which will control both the ai_family used during DNS resolution, and later use of the V6ONLY flag. Currently the standalone DNS resolver code drops the has_ipv4 & has_ipv6 flags after resolving, which means the later bind() code won't correctly set V6ONLY. This fixes the following scenarios -vnc :0,ipv4=off -vnc :0,ipv6=on -vnc :::0,ipv4=off -vnc :::0,ipv6=on which all mistakenly accepted IPv4 clients Acked-by: NGerd Hoffmann <kraxel@gmail.com> Reviewed-by: NPhilippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: NEric Blake <eblake@redhat.com> Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Daniel P. Berrange 提交于
Currently if you disable listening on IPv4 addresses, via the CLI flag ipv4=off, we still mistakenly accept IPv4 clients via the IPv6 listener socket due to IPV6_V6ONLY flag being unset. We must ensure IPV6_V6ONLY is always set if ipv4=off This fixes the following scenarios -incoming tcp::9000,ipv6=on -incoming tcp:[::]:9000,ipv6=on -chardev socket,id=cdev0,host=,port=9000,server,nowait,ipv4=off -chardev socket,id=cdev0,host=,port=9000,server,nowait,ipv6=on -chardev socket,id=cdev0,host=::,port=9000,server,nowait,ipv4=off -chardev socket,id=cdev0,host=::,port=9000,server,nowait,ipv6=on which all mistakenly accepted IPv4 clients Acked-by: NGerd Hoffmann <kraxel@gmail.com> Reviewed-by: NPhilippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: NEric Blake <eblake@redhat.com> Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Daniel P. Berrange 提交于
When inet_parse() parses the hostname, it is forcing the has_ipv6 && ipv6 flags if the address contains a ":". This means that if the user had set the ipv4=on flag, to try to restrict the listener to just ipv4, an error would not have been raised. eg -incoming tcp:[::]:9000,ipv4 should have raised an error because listening for IPv4 on "::" is a non-sensical combination. With this removed, we now call getaddrinfo() on "::" passing PF_INET and so getaddrinfo reports an error about the hostname being incompatible with the requested protocol: qemu-system-x86_64: -incoming tcp:[::]:9000,ipv4: address resolution failed for :::9000: Address family for hostname not supported Likewise it is explicitly setting the has_ipv4 & ipv4 flags when the address contains only digits + '.'. This has no ill-effect, but also has no benefit, so is removed. Acked-by: NGerd Hoffmann <kraxel@gmail.com> Reviewed-by: NPhilippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: NEric Blake <eblake@redhat.com> Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Daniel P. Berrange 提交于
When binding to an IPv6 socket we currently force the IPV6_V6ONLY flag to off. This means that the IPv6 socket will accept both IPv4 & IPv6 sockets when QEMU is launched with something like -vnc :::1 While this is good for that case, it is bad for other cases. For example if an empty hostname is given, getaddrinfo resolves it to 2 addresses 0.0.0.0 and ::, in that order. We will thus bind to 0.0.0.0 first, and then fail to bind to :: on the same port. The same problem can happen if any other hostname lookup causes the IPv4 address to be reported before the IPv6 address. When we get an IPv6 bind failure, we should re-try the same port, but with IPV6_V6ONLY turned on again, to avoid clash with any IPv4 listener. This ensures that -vnc :1 will bind successfully to both 0.0.0.0 and ::, and also avoid -vnc :1,to=2 from mistakenly using a 2nd port for the :: listener. This is a regression due to commit 396f935a "ui: add ability to specify multiple VNC listen addresses". Acked-by: NGerd Hoffmann <kraxel@gmail.com> Reviewed-by: NEric Blake <eblake@redhat.com> Reviewed-by: NPhilippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Peter Maydell 提交于
s390x/kvm/migration/cpumodel: fixes, enhancements and cleanups - add a network boot rom for s390 (Thomas Huth) - migration of storage attributes like the CMMA used/unused state - PCI related enhancements - full support for aen, ais and zpci - migration support for css with vmstates (Halil Pasic) - cpu model enhancements for cpu features - guarded storage support # gpg: Signature made Fri 14 Jul 2017 11:33:04 BST # gpg: using RSA key 0x117BBC80B5A61C7C # gpg: Good signature from "Christian Borntraeger (IBM) <borntraeger@de.ibm.com>" # Primary key fingerprint: F922 9381 A334 08F9 DBAB FBCA 117B BC80 B5A6 1C7C * remotes/borntraeger/tags/s390x-20170714: (40 commits) s390x/gdb: add gs registers s390x/arch_dump: also dump guarded storage control block s390x/kvm: enable guarded storage s390x/kvm: Enable KSS facility for nested virtualization s390x/cpumodel: add esop/esop2 to z12 model s390x/cpumodel: we are always in zarchitecture mode s390x/cpumodel: wire up new hardware features s390x/flic: migrate ais states s390x/cpumodel: add zpci, aen and ais facilities s390x: initialize cpu firstly pc-bios/s390: rebuild s390-ccw.img pc-bios/s390: add s390-netboot.img pc-bios/s390-ccw: Link libnet into the netboot image and do the TFTP load pc-bios/s390-ccw: Add virtio-net driver code pc-bios/s390-ccw: Add core files for the network bootloading program roms/SLOF: Update submodule to latest status pc-bios/s390-ccw: Add code for virtio feature negotiation pc-bios/s390-ccw: Remove unused structs from virtio.h pc-bios/s390-ccw: Move byteswap functions to a separate header pc-bios/s390-ccw: Add a write() function for stdio ... Conflicts: target/s390x/kvm.c Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
-
由 Peter Maydell 提交于
* gdbstub fixes (Alex) * IOMMU MemoryRegion subclass (Alexey) * Chardev hotswap (Anton) * NBD_OPT_GO support (Eric) * Misc bugfixes * DEFINE_PROP_LINK (minus the ARM patches - Fam) * MAINTAINERS updates (Philippe) # gpg: Signature made Fri 14 Jul 2017 11:06:27 BST # gpg: using RSA key 0xBFFBD25F78C7AE83 # gpg: Good signature from "Paolo Bonzini <bonzini@gnu.org>" # gpg: aka "Paolo Bonzini <pbonzini@redhat.com>" # Primary key fingerprint: 46F5 9FBD 57D6 12E7 BFD4 E2F7 7E15 100C CD36 69B1 # Subkey fingerprint: F133 3857 4B66 2389 866C 7682 BFFB D25F 78C7 AE83 * remotes/bonzini/tags/for-upstream: (55 commits) spapr_rng: Convert to DEFINE_PROP_LINK cpu: Convert to DEFINE_PROP_LINK mips_cmgcr: Convert to DEFINE_PROP_LINK ivshmem: Convert to DEFINE_PROP_LINK dimm: Convert to DEFINE_PROP_LINK virtio-crypto: Convert to DEFINE_PROP_LINK virtio-rng: Convert to DEFINE_PROP_LINK virtio-scsi: Convert to DEFINE_PROP_LINK virtio-blk: Convert to DEFINE_PROP_LINK qdev: Add const qualifier to PropertyInfo definitions qmp: Use ObjectProperty.type if present qdev: Introduce DEFINE_PROP_LINK qdev: Introduce PropertyInfo.create qom: enforce readonly nature of link's check callback translate-all: remove redundant !tcg_enabled check in dump_exec_info vl: fix breakage of -tb-size nbd: Implement NBD_INFO_BLOCK_SIZE on client nbd: Implement NBD_INFO_BLOCK_SIZE on server nbd: Implement NBD_OPT_GO on client nbd: Implement NBD_OPT_GO on server ... Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
-
由 Christian Borntraeger 提交于
Let's provide the guarded storage registers via gdb server. Signed-off-by: NChristian Borntraeger <borntraeger@de.ibm.com>
-
由 Christian Borntraeger 提交于
Write the new note section of type 30b (guarded storage control block). Signed-off-by: NChristian Borntraeger <borntraeger@de.ibm.com>
-
由 Fan Zhang 提交于
Introduce guarded storage support for KVM guests on s390. We need to enable the capability, extend machine check validity, sigp store-additional-status-at-address, and migration. The feature is fenced for older machine type versions. Signed-off-by: NFan Zhang <zhangfan@linux.vnet.ibm.com> Reviewed-by: NCornelia Huck <cohuck@redhat.com> Signed-off-by: NChristian Borntraeger <borntraeger@de.ibm.com>
-
由 Farhan Ali 提交于
If the host supports keyless subset (KSS) then first level guest (G2) should enable KSS facility as well. Signed-off-by: NFarhan Ali <alifm@linux.vnet.ibm.com> Reviewed-by: NEric Farman <farman@linux.vnet.ibm.com> Acked-by: NCornelia Huck <cohuck@redhat.com> Signed-off-by: NChristian Borntraeger <borntraeger@de.ibm.com>
-
由 Jason J. Herne 提交于
Add esop and esop2 features to z12 model where esop2 was originally introduced. Disable esop and esop2 when using compatibility machine v2.9 or earlier. Signed-off-by: NJason J. Herne <jjherne@linux.vnet.ibm.com> Acked-by: NChristian Borntraeger <borntraeger@de.ibm.com> Reviewed-by: NCornelia Huck <cohuck@redhat.com> Signed-off-by: NChristian Borntraeger <borntraeger@de.ibm.com>
-
由 Jason J. Herne 提交于
In QEMU, a guest VCPU always started in and never was able to leave z/Architecture mode. Now we have an architected way of showing this condition. The SIGP SET ARCHITECTURE instruction is simply rejected. Linux as guest seems to not care about the return value, which is a good thing The new handling is just like already being in z/Architecture mode. We'll not try to fake absence of this facility, but still not indicate the facility in case some strange CPU model turned z/Architecture off completely (which doesn't work either way but let's us see how a guest would react on a lack of this facility). Signed-off-by: NJason J. Herne <jjherne@linux.vnet.ibm.com> Acked-by: NChristian Borntraeger <borntraeger@de.ibm.com> Acked-by: NCornelia Huck <cornelia.huck@de.ibm.com> Signed-off-by: NChristian Borntraeger <borntraeger@de.ibm.com>
-
由 Jason J. Herne 提交于
Some new guest features have been introduced recently. Let's wire them up in the CPU model. Signed-off-by: NJason J. Herne <jjherne@linux.vnet.ibm.com> Acked-by: NChristian Borntraeger <borntraeger@de.ibm.com> Acked-by: NCornelia Huck <cohuck@redhat.com> Signed-off-by: NChristian Borntraeger <borntraeger@de.ibm.com> [split patch]
-
由 Yi Min Zhao 提交于
During migration we should transfer ais states to the target guest. This patch introduces a subsection to kvm_s390_flic_vmstate and new vmsd for qemu_flic. The ais states need to be migrated only when ais is supported. Signed-off-by: NYi Min Zhao <zyimin@linux.vnet.ibm.com> Signed-off-by: NChristian Borntraeger <borntraeger@de.ibm.com> Reviewed-by: NCornelia Huck <cohuck@redhat.com>
-
由 Yi Min Zhao 提交于
zPCI instructions and facilities are available since IBM zEnterprise EC12. To support z/PCI in QEMU we enable zpci, aen and ais facilities starting with zEC12 GA1. And we always set zpci and aen bits in max cpu model. Later they might be switched off due to applied real cpu model. For ais bit, we only provide it in the full cpu model beginning with zEC12 and defer its enablement in the default cpu model to a later point in time. At the same time, disable them for 2.9 and older machines. Because of introducing AIS facility, we could check if it's enabled to initialize flic->ais_supported with the real value. Signed-off-by: NYi Min Zhao <zyimin@linux.vnet.ibm.com> Signed-off-by: NChristian Borntraeger <borntraeger@de.ibm.com> Reviewed-by: NCornelia Huck <cohuck@redhat.com>
-
由 Yi Min Zhao 提交于
By initializing the CPU firstly, we are able to retrieve and use the CPU model features when initializing other subsystem or devices. Signed-off-by: NYi Min Zhao <zyimin@linux.vnet.ibm.com> Reviewed-by: NPierre Morel <pmorel@linux.vnet.ibm.com> Reviewed-by: NCornelia Huck <cohuck@redhat.com> Signed-off-by: NChristian Borntraeger <borntraeger@de.ibm.com>
-
由 Christian Borntraeger 提交于
rebuild after the following commits 4b996d0 pc-bios/s390-ccw: Link libnet into the netboot image and do the TFTP load e6879a6 pc-bios/s390-ccw: Add virtio-net driver code 766500f pc-bios/s390-ccw: Add core files for the network bootloading program f807e55 pc-bios/s390-ccw: Add code for virtio feature negotiation b4e3b4f pc-bios/s390-ccw: Remove unused structs from virtio.h dd3dc5e pc-bios/s390-ccw: Move byteswap functions to a separate header a20b4fe pc-bios/s390-ccw: Add a write() function for stdio 262e07c pc-bios/s390-ccw: Move virtio-block related functions into a separate file 7438d32 pc-bios/s390-ccw: Move ebc2asc to sclp.c 8760bad pc-bios/s390-ccw: Move libc functions to separate header c68f4503 pc-bios/s390-ccw: use STRIP variable in Makefile Signed-off-by: NChristian Borntraeger <borntraeger@de.ibm.com>
-
由 Christian Borntraeger 提交于
It's already possible to do a network boot of an s390x guest with an external netboot image based on a Linux installation, but it would be much more convenient if the s390-ccw firmware supported network booting right out of the box, without the need to assemble such an external image first. This is an s390-netboot.img that can be used for network booting. You can download a combined kernel + initrd image via TFTP by starting QEMU for example with: qemu-system-s390x ... -device virtio-net,netdev=n1,bootindex=1 \ -netdev user,id=n1,tftp=/path/to/tftp,bootfile=kernel.img Note that this version does not support downloading via config files (i.e. pxelinux config files or .INS config files) yet. This will be added later. Signed-off-by: NChristian Borntraeger <borntraeger@de.ibm.com>
-