When VP enters the Run state it starts execution from the reset vector.
Currently used CPU_INTERRUPT_WAKE does not do that if reset exception
base has been modified. Therefore fix that by simply resetting given VP.
Drop the usage of CPU_INTERRUPT_WAKE also in VP_STOP and instead raise
the CPU_INTERRUPT_HALT to halt a VP.
Signed-off-by: Leon Alrae <leon.alrae@imgtec.com>
Replace hardcoded 0xbfc00000 with exception_base which is initialized with
this default address so there is no functional change here.
However, it is now exposed and consequently it will be possible to modify
it from outside of the CPU.
Signed-off-by: Leon Alrae <leon.alrae@imgtec.com>
The Global Interrupt Controller (GIC) is responsible for mapping each
internal and external interrupt to the correct location for servicing.
The internal representation of registers is different from the specification
in order to consolidate information for each GIC Interrupt Sources and Virtual
Processors with same functionalities. For example SH_MAP00_VP00 registers are
defined like each bit represents a VP but in this implementation the equivalent
map_vp contains VP number in integer form for ease accesses. When it is being
accessed via read write functions an internal data is converted back into the
original format as the specification.
Limitations:
Level triggering only
GIC CounterHi not implemented (Countbits = 32bits)
DINT not implemented
Local WatchDog, Fast Debug Channel, Perf Counter not implemented
Signed-off-by: Yongbok Kim <yongbok.kim@imgtec.com>
Signed-off-by: Leon Alrae <leon.alrae@imgtec.com>
The interval timer is similar to the CP0 Count/Compare timer within
each processor. The difference is the GIC_SH_COUNTER register is global
to the system so that all processors have the same time reference.
To ease implementation, all VPs are having its own QEMU timer but sharing
global settings and registers such as GIC_SH_CONFIG.COUTNSTOP and
GIC_SH_COUNTER.
MIPS GIC Interval Timer does support upto 64 bits of Count register but
in this implementation it is limited to 32 bits only.
Signed-off-by: Yongbok Kim <yongbok.kim@imgtec.com>
Signed-off-by: Leon Alrae <leon.alrae@imgtec.com>
Improve capability checks (count keys and buttons), store results.
Merge the input_linux_event_mouse and input_linux_event_keyboard
functions into one, dispatch into input_linux_handle_mouse and
input_linux_handle_keyboard depending on device capabilities.
Allow calling both handle functions, so we can handle mice which
also send key events, by routing those key events to the keyboard.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Message-id: 1466067800-25434-4-git-send-email-kraxel@redhat.com
It isn't unusual to happen, for example during reboot when the guest
doesn't reveice events for a while. So better don't flood stderr
with alarming messages. Turn them into tracepoints instead so they
can be enabled in case they are needed for trouble-shooting.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Message-id: 1466675495-28797-1-git-send-email-kraxel@redhat.com
Keep track of button changes. Send the extended 4-byte messages for
three button mice only in case we have something to report for the
middle button. Use the short 3-byte messages (original protocol for
two-button microsoft mouse) otherwise.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Message-id: 1467625375-31774-5-git-send-email-kraxel@redhat.com
The msmouse chardev backend writes data without checking whenever there
is enough space.
That happens to work with linux guests, probably by pure luck because
the linux driver enables the fifo and the serial port emulation accepts
more data than announced via qemu_chr_be_can_write() in that case.
Handle this properly by adding a buffer to MouseState. Hook up a
CharDriverState->accept_input() handler which feeds the buffer to the
serial port. msmouse_event() only fills the buffer now, and calls the
accept_input handler too to kick off the transmission.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Paolo Bonzini <pbonzini@redhat.com>
Message-id: 1467625375-31774-3-git-send-email-kraxel@redhat.com
The vnc_client_read() function is called from the vnc_client_io()
event handler callback when there is incoming data to process.
If it detects that the client has disconnected, then it will
trigger cleanup and free'ing of the VncState client struct at
a safe time.
Unfortunately, the vnc_client_io() event handler will also call
vnc_client_write() to handle any outgoing data writes. So if
vnc_client_io() was invoked with both G_IO_IN and G_IO_OUT
events set, and the client disconnects, we may try to write to
a client which has just been freed.
https://bugs.launchpad.net/qemu/+bug/1594861
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Message-id: 1467042529-3372-1-git-send-email-berrange@redhat.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
currently the color counting palette is allocated from heap, used and destroyed
for each single subrect. Use a static palette per thread for this purpose and
avoid the malloc and free for each update.
Signed-off-by: Peter Lieven <pl@kamp.de>
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Message-id: 1467280846-9674-1-git-send-email-pl@kamp.de
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
vs->disconnecting is set to TRUE and vs->ioc is closed, but
vs->ioc isn't set to NULL, so that the vnc_disconnect_finish()
isn't invoked when you update client in vnc_update_client()
after vnc_disconnect_start invoked. Let's using change the checking
condition to avoid resource leak.
Signed-off-by: Haibin Wang <wanghaibin.wang@huawei.com>
Signed-off-by: Gonglei <arei.gonglei@huawei.com>
Reviewed-by: Daniel P. Berrange <berrange@redhat.com>
Message-id: 1467949056-81208-1-git-send-email-arei.gonglei@huawei.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
- A large update of the s390x PCI code, bringing it in line with
the architecture
- Fixes and improvements in the ipl (boot) code
- Refactoring in the css code
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJXg1MjAAoJEN7Pa5PG8C+vOpIP/A0s4oGk056YHN8APCCPEnhD
jQIH7GxMZXsCvBb0w7mcvk0EYqoGBOplWZ9mOzHGr8wzQhL56quOOY3Esidj8yVD
Nulwg4bPtd4SQJoaV0CndZq9Vn6JtWsyS05ncq23VnasrMLPzzAPltI7EuV8OynY
zgpb/B6KM1vk/wN9brci2WGKTaeTeAD9FmHTuPTiYJDZEZL8FjjQkE0sHmCwNm9Z
w0dlwEfRyFPwNtvYYMQmlU8jl9MlizOi/FKIU5G2FtsGlwgyMYPoayAuv455iIm9
a7wb4Sb2VdWeLWzB9E0bqzMJ+mmH+nwxMtMzFw5XYw2uBLbLh0J3PxB1UUDwab12
BJMJc4QRzTNfjddwVD2Yi8xg9da0AEOoynHogK4r2z3mlBaloNBHIm63Dkjmrvfw
2W/FQ67RdcQah54Du62ZezSoyjfxVhCUF0tHfh+PqjhXeC8L8dPvKug/vLp2bgVS
JZfz0ObjGrYGJ3JLIPKobEif4teXPmxiOEzYhCnIUE6ZHFnjlrOdWUiVEpA8laMR
jQn1amp0UkbaPXnNjcS35swnSYHHOGpI3N0cJ5E/xM+uRLZ2W569ceIfAhCRb2Su
oGRQTE8vnSyni+H4SoAXqSttGbXX8ST5mR2BCnvX+vNzUYd/azV+CKckcdgfJtXR
Q+6YDC9Y8SLL/pJFzSfg
=/+SU
-----END PGP SIGNATURE-----
Merge remote-tracking branch 'remotes/cohuck/tags/s390x-20160711' into staging
Last round of s390x patches for 2.7:
- A large update of the s390x PCI code, bringing it in line with
the architecture
- Fixes and improvements in the ipl (boot) code
- Refactoring in the css code
# gpg: Signature made Mon 11 Jul 2016 09:04:51 BST
# gpg: using RSA key 0xDECF6B93C6F02FAF
# gpg: Good signature from "Cornelia Huck <huckc@linux.vnet.ibm.com>"
# gpg: aka "Cornelia Huck <cornelia.huck@de.ibm.com>"
# Primary key fingerprint: C3D0 D66D C362 4FF6 A8C0 18CE DECF 6B93 C6F0 2FAF
* remotes/cohuck/tags/s390x-20160711: (25 commits)
s390x/pci: make hot-unplug handler smoother
s390x/pci: replace fid with idx in msg data of msix
s390x/pci: fix stpcifc_service_call
s390x/pci: refactor list_pci
s390x/pci: refactor s390_pci_find_dev_by_idx
s390x/pci: add checkings in CLP_SET_PCI_FN
s390x/pci: enable zpci hot-plug/hot-unplug
s390x/pci: enable uid-checking
s390x/pci: introduce S390PCIBusDevice qdev
s390x/pci: introduce S390PCIIOMMU
s390x/pci: introduce S390PCIBus
s390x/pci: enforce zPCI state checking
s390x/pci: refactor s390_pci_find_dev_by_fh
s390x/pci: unify FH_ macros
s390x/pci: write fid in CLP_QUERY_PCI_FN
s390x/pci: acceleration for getting S390pciState
s390x/pci: fix failures of dma map/unmap
s390x/css: Unplug handler of virtual css bridge
s390x/css: Factor out virtual css bridge and bus
s390x/css: use define for "virtual-css-bridge" literal
...
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Highlights:
* Improvements on global property error handling
* Translate -cpu options to global properties
* LMCE support
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABCAAGBQJXfrSFAAoJECgHk2+YTcWmrxIP/2eROlseez3HqwNT8ZuPKQVz
gsM1WaRr66ZscpNL7+zEA4CAIOTYnq+f3oYzKO2KT6HIBdVIdiU+c6B87xOVfpdf
WwedDysT9ye073zPW8afiH4d0WHsVoluKfJvCFNynauB1a0eU2sKHS/wnZihOryh
Cruen2SUd4qB14Wp+DXGwDlrJouaqvsqnss+UkYTeMGISQMZbBjbPW7S+gr7W1A5
LCsl0Y2hR3Agco5+8i+KBmfW9Z0+V99ACIq9v6Tf7Iz6s7QkizX1nPPKlpbZtDxz
/HYQgYTCAHGGppdNb+wq32SUCMxDZVbwczdMQVEaSBMdfWhw+7QY37QZPWaSoyTE
NrSQMrsAB5d1nZ3g4I7aeiVRYlmG9XH+kF0GSJ1p3wlnwllF7pLCQwWxKVTldXui
53ldm8ex27MtciHUCxCda0LhOlToIMDjupevCzsHfJgKvqaE4AmHVHfQmKq38xgi
x6T0M6TR6UXD4beQuGWb/P7OJtZSsaMWZqYmPYNgR66cSrWFPAQv/dX+uG6cd2YT
8BVnmw4SY/PGoTaU1zNF1VeoL5Ldzr1EZwuliWqRbLoprzz3LG8yOnZag2XI2RIX
EJRGHkSqxK1yJlrFGn+RqKjmRSvXXzWRCdTP8UcFPl8wZkmiXbkeX1sYeJwsXa81
UXZ3lDd8JF6LgIyE2wB7
=sBs3
-----END PGP SIGNATURE-----
Merge remote-tracking branch 'remotes/ehabkost/tags/x86-pull-request' into staging
x86 and machine queue, 2016-07-07
Highlights:
* Improvements on global property error handling
* Translate -cpu options to global properties
* LMCE support
# gpg: Signature made Thu 07 Jul 2016 20:59:01 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
* remotes/ehabkost/tags/x86-pull-request:
target-i386: Enable LMCE for '-cpu host' if supported by host
target-i386: Publish advised value of MSR_IA32_FEATURE_CONTROL via fw_cfg
target-i386: kvm: Add basic Intel LMCE support
target-i386: Report hyperv feature words through qom
target-i386: Show host and VM TSC frequencies on mismatch
pc: Parse CPU features only once
arm: virt: Parse cpu_model only once
cpu: Use CPUClass->parse_features() as convertor to global properties
target-i386: Avoid using locals outside their scope
target-i386: TCG can support CPUID.07H:EBX.erms
target-sparc: Use sparc_cpu_parse_features() directly
vl: Set errp to &error_abort on machine compat_props
machine: Add machine_register_compat_props() function
qdev: GlobalProperty.errp field
qdev: Eliminate qemu_add_globals() function
qdev: Don't stop applying globals on first error
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Commit "9d8256e virgl: pass whole GL scanout dimensions" missed the
opengl code path for gtk versions >= 3.16. Update that one too and
fix the build with recent gtk versions.
Reported-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Message-id: 1467876563-1351-1-git-send-email-kraxel@redhat.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
The current implementation of hot-unplug handler is abrupt. Any pci
operation will be just rejected if pci device is unconfigured. Thus a
pci device can not be reset or destroyed in a right, smooth and safe
way.
Improve this as follows:
- Notify the guest via a HP_EVENT_DECONFIGURE_REQUEST(0x303) event in
the unplug handler, giving it a chance to deconfigure the device via
sclp and allowing us to continue hot-unplug afterwards.
- Set up a timer that will generate the HP_EVENT_CONFIGURE_TO_STBRES
(0x304) event as before if the guest did not react after an adequate
time.
Signed-off-by: Yi Min Zhao <zyimin@linux.vnet.ibm.com>
Reviewed-by: Pierre Morel <pmorel@linux.vnet.ibm.com>
Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
Present code uses fid as the part of message data of msix for looking
up the specific zpci device. However it limits the usable range of fid,
and the code looking up the zpci device may fail due to truncation of
the fid.
In addition, fh is composed of enabled bit, FH_VIRT and the array index.
So we can use the array index as the identifier to store in msg data.
Signed-off-by: Yi Min Zhao <zyimin@linux.vnet.ibm.com>
Reviewed-by: Pierre Morel <pmorel@linux.vnet.ibm.com>
Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
Firstly the function misses dmaas checking. This patch adds it.
Secondly the function uses s390_pci_find_dev_by_fh() to look up the
zpci device. This may fail if the guest provides a valid and disabled
fh but fh of the associated zpci device is enabled. Thus we use
s390_pci_find_dev_by_idx() instead.
Signed-off-by: Yi Min Zhao <zyimin@linux.vnet.ibm.com>
Reviewed-by: Pierre Morel <pmorel@linux.vnet.ibm.com>
Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
Because of the refactor of s390_pci_find_dev_by_idx(), list_pci()
should be updated. We introduce a new function to get the next
available zpci device. It simplifies the code of looking up zpci
devices.
Signed-off-by: Yi Min Zhao <zyimin@linux.vnet.ibm.com>
Acked-by: Pierre Morel <pmorel@linux.vnet.ibm.com>
Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
s390_find_dev_by_idx() only indexes usable zpci devices. It implies
that the index value of each zpci device is dynamic and may change if
a new zpci device is plugged. So we have to use a constant index to
look up the device.
Signed-off-by: Yi Min Zhao <zyimin@linux.vnet.ibm.com>
Reviewed-by: Pierre Morel <pmorel@linux.vnet.ibm.com>
Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
The code in CLP_SET_PCI_FN case misses some checkings. Let's add
them.
Signed-off-by: Yi Min Zhao <zyimin@linux.vnet.ibm.com>
Reviewed-by: Pierre Morel <pmorel@linux.vnet.ibm.com>
Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
We need to support hot-plug/hot-unplug for the new zpci devices as
well. This patch enables the present hot-plug/hot-unplug handlers
to support not only generic pci devices but also zpci devices.
Signed-off-by: Yi Min Zhao <zyimin@linux.vnet.ibm.com>
Reviewed-by: Pierre Morel <pmorel@linux.vnet.ibm.com>
Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
The uid-checking facility guarantees uniqueness of the uid within the
vm and exposes the real uid to the guest when listing pci devices.
Let's always enable it and present it to the guest in the response to
the list pci clp command.
Signed-off-by: Yi Min Zhao <zyimin@linux.vnet.ibm.com>
Reviewed-by: Pierre Morel <pmorel@linux.vnet.ibm.com>
Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
To support definitions of s390 pci attributes in Qemu cmdline, we have
to make current S390PCIBusDevice struct inherit DeviceState and add
three properties for it. Currently we only support definitions of uid
and fid.
'uid' is optionally defined by users, identifies a zpci device and
must be defined with a 16-bit and non-zero unique value.
'fid' ranges from 0x0 to 0xFFFFFFFF. For fid property, we introduce a
new PropertyInfo by the name of s390_pci_fid_propinfo with our special
setter and getter. As 'fid' is optional, introduce 'fid_defined' to
track whether the user specified a fid.
'target' field is to direct qemu to find the corresponding generic PCI
device. It is equal to the 'id' value of one of generic pci devices.
If the user doesn't specify 'id' parameter for a generic pci device,
its 'id' value will be generated automatically and use this value as
'target' to create an associated zpci device.
If the user did not specify 'uid' or 'fid', values are generated
automatically. 'target' is required.
In addition, if a pci device has no associated zpci device, the code
will generate a zpci device automatically for it.
Signed-off-by: Yi Min Zhao <zyimin@linux.vnet.ibm.com>
Reviewed-by: Pierre Morel <pmorel@linux.vnet.ibm.com>
Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
Currently each zpci device holds its own DMA address space and memory
region. At the same time, all instances of zpci device are stored in
S390pciState. So duirng the initialization of S390pciState, all zpci
devices are created and then all DMA address spaces are created. Thus,
when initializing pci devices, their corresponding DMA address spaces
could be found.
But zpci qdev will be introduced later. Zpci device may be initialized
and plugged afterwards generic pci device. So we should initialize all
DMA address spaces and memory regions before initializing zpci devices.
We introduce a new struct named S390PCIIOMMU. And a new field of
S390pciState, which is an array to store all instances of S390PCIIOMMU,
is added so that qemu pci code could find the corresponding DMA
address space when initializing a generic pci device. And this should
be done before the connection of a zpci device and a generic pci
device is built.
Signed-off-by: Yi Min Zhao <zyimin@linux.vnet.ibm.com>
Acked-by: Pierre Morel <pmorel@linux.vnet.ibm.com>
Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
To enable S390PCIBusDevice as qdev, there should be a new bus to
plug and manage all instances of S390PCIBusDevice. Due to this,
S390PCIBus is introduced.
Signed-off-by: Yi Min Zhao <zyimin@linux.vnet.ibm.com>
Reviewed-by: Pierre Morel <pmorel@linux.vnet.ibm.com>
Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
Current code uses some fields combinatorially to indicate the state of
a s390 pci device. This patch introduces device states in order to make
the code more readable and more logical.
Signed-off-by: Yi Min Zhao <zyimin@linux.vnet.ibm.com>
Reviewed-by: Pierre Morel <pmorel@linux.vnet.ibm.com>
Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
Because this function is called very frequently, we should use a more
effective way to find the zpci device. So we use the FH's index to get
the device directly.
Signed-off-by: Yi Min Zhao <zyimin@linux.vnet.ibm.com>
Reviewed-by: Pierre Morel <pmorel@linux.vnet.ibm.com>
Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
Present code uses some macros to structure PCI Function Handle. But
their names don't have a uniform format. Let's use FH_MASK_ as the
unified prefix.
While we're at it, differentiate the SHM bits: use different bits for
vfio and emulated devices.
Signed-off-by: Yi Min Zhao <zyimin@linux.vnet.ibm.com>
Reviewed-by: Pierre Morel <pmorel@linux.vnet.ibm.com>
Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
We forgot to write the fid; fix that.
Signed-off-by: Yi Min Zhao <zyimin@linux.vnet.ibm.com>
Acked-by: Pierre Morel <pmorel@linux.vnet.ibm.com>
Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
There are a number of places where the code needs to get the instance
of S390pciState. It calls object_resolve_path() every time. This
wastes a lot of time and leads to low performance. Thus we add
s390_get_phb() to improve it.
Because we always have a phb, we remove all return checkings in the
callers and add an assert in s390_get_phb() to make sure that phb is
getted successfully.
Signed-off-by: Yi Min Zhao <zyimin@linux.vnet.ibm.com>
Reviewed-by: Pierre Morel <pmorel@linux.vnet.ibm.com>
Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
In commit d78c19b5cf, vfio code stores
the IOMMU's offset_within_address_space and adjusts the IOVA before
calling vfio_dma_map/vfio_dma_unmap. But s390_translate_iommu already
considers the base address of an IOMMU memory region.
Thus we use pal as the size and 0x0 as the base address to initialize
IOMMU memory subregion.
Signed-off-by: Yi Min Zhao <zyimin@linux.vnet.ibm.com>
Reviewed-by: Pierre Morel <pmorel@linux.vnet.ibm.com>
Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
The previous patch moved virtual css bridge and bus out from
virtio-ccw, but kept the direct reference of virtio-ccw specific
unplug function inside css-bridge.c.
To make the virtual css bus and bridge useful for non-virtio devices,
this introduces a common unplug function pointer "unplug" to call
specific virtio-ccw unplug parts. Thus, the tight coupling to
virtio-ccw can be removed.
This unplug pointer is a member of CCWDeviceClass, which is introduced
as an abstract device layer called "ccw-device". This layer is between
DeviceState and specific devices which are plugged in virtual css bus,
like virtio-ccw device. The specific unplug handlers should be assigned
to "unplug" during initialization.
Signed-off-by: Jing Liu <liujbjl@linux.vnet.ibm.com>
Reviewed-by: Sascha Silbe <silbe@linux.vnet.ibm.com>
Reviewed-by: Dong Jia Shi <bjsdjshi@linux.vnet.ibm.com>
Reviewed-by: Yi Min Zhao <zyimin@linux.vnet.ibm.com>
Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
Currently, common base layers virtual css bridge and bus are
defined in hw/s390x/virtio-ccw.c(h). In order to support
multiple types of devices in the virtual channel subsystem,
especially non virtio-ccw, refactoring work needs to be done.
This work is just a pure code move without any functional change
except dropping an empty function virtual_css_bridge_init() and
virtio_ccw_busdev_unplug() changing. virtio_ccw_busdev_unplug()
is specific to virtio-ccw but gets referenced from the common
virtual css bridge code. To keep the functional changes to a
minimum we export this function from virtio-ccw.c and continue
to reference it inside virtual_css_bridge_class_init()
(now living in hw/s390x/css-bridge.c). A follow-up patch will
clean this up.
Signed-off-by: Jing Liu <liujbjl@linux.vnet.ibm.com>
Reviewed-by: Sascha Silbe <silbe@linux.vnet.ibm.com>
Reviewed-by: Dong Jia Shi <bjsdjshi@linux.vnet.ibm.com>
Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
Introduce a TYPE_* define (like we already use for a couple of other
QOM types) for the name of the virtual CSS bridge QOM type instead of
sprinkling the same string literal over several source files.
Signed-off-by: Sascha Silbe <silbe@linux.vnet.ibm.com>
Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
A lot of what virtio_ccw_device_realize() does isn't specific to
virtio; it would apply to emulated CCW as well. Factor it out to make
it easier to implement emulated CCW devices later on.
Signed-off-by: Sascha Silbe <silbe@linux.vnet.ibm.com>
Reviewed-by: Dong Jia Shi <bjsdjshi@linux.vnet.ibm.com>
Reviewed-by: Halil Pasic <pasic@linux.vnet.ibm.com>
Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
When migrating from a different QEMU version, the start_address and
bios_start_address may differ. During migration these values are migrated
and overwrite the values that were detected by QEMU itself.
On a reboot, QEMU will reload its own BIOS, but use the migrated start
addresses, which does not work if the values differ.
Fix this by not relying on the migrated values anymore, but still
provide them during migration, so existing QEMUs continue to work.
Signed-off-by: David Hildenbrand <dahi@linux.vnet.ibm.com>
Cc: qemu-stable@nongnu.org
Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
If bootindex is specified for a device, we need to IPL from
it. Currently it works for ccw devices, but not for SCSI. To be able to
IPL from the specific device, pc-bios needs to know its address.
For this reason we add special QEMU_SCSI IPL type into the IPLB
structure, that contains the scsi device address.
We enhance the ipl block with a currently qemu-only parameter block
that allows us to specify a concrete scsi device.
Signed-off-by: Alexander Yarygin <yarygin@linux.vnet.ibm.com>
Reviewed-by: Eric Farman <farman@linux.vnet.ibm.com>
Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
There is ,bootindex=%d argument to specify the lookup order of
boot devices.
If a bootindex assigned to the device, then IPL Parameter Info Block
is created for that device when it is IPLed from.
If it is a mere SCSI device (not FCP), then IPIB is created with a
special SCSI type and its fields are used to store SCSI address of the
device. This new ipl block is private to qemu for now.
If the device to IPL from is specified this way, then SCSI bus lookup
is bypassed and prescribed devices uses the address specified.
Signed-off-by: Eugene (jno) Dvurechenski <jno@linux.vnet.ibm.com>
Signed-off-by: Alexander Yarygin <yarygin@linux.vnet.ibm.com>
Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
For clang before 3.5, -fno-integrated-as does not exist,
so the workaround in 5f6f0e27fb fails to build.
Use clang's default assembler for linux-user/safe-syscall.S,
and explicitly change to use the system assembler for the
option roms.
Tested-by: Alex Bennée <alex.bennee@linaro.org>
Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
Signed-off-by: Richard Henderson <rth@twiddle.net>
In user-mode emulation Translation Block can consist of 2 guest pages.
In that case QEMU also mprotects 2 host pages that are dedicated for
guest memory, containing instructions. QEMU detects self-modifying code
with SEGFAULT signal processing.
In case if instruction in 1st page is modifying memory of 2nd
page (or vice versa) QEMU will mark 2nd page with PAGE_WRITE,
invalidate TB, generate new TB contatining 1 guest instruction and
exit to CPU loop. QEMU won't call mprotect, and new TB will cause
same SEGFAULT. Page will have both PAGE_WRITE_ORG and PAGE_WRITE
flags, so QEMU will handle the signal as guest binary problem,
and exit with guest SEGFAULT.
Solution is to do following: In case if current TB was invalidated
continue to invalidate TBs from remaining guest pages and mark pages
as PAGE_WRITE. After that disable host page protection with mprotect.
If current tb was invalidated longjmp to main loop. That is more
efficient, since we won't get SEGFAULT when executing new TB.
Reviewed-by: Sergey Fedorov <sergey.fedorov@linaro.org>
Signed-off-by: Stanislav Shmarov <snarpix@gmail.com>
Message-Id: <1467880392-1043630-1-git-send-email-snarpix@gmail.com>
Signed-off-by: Richard Henderson <rth@twiddle.net>
As it currently stands, QEMU does not properly handle self-modifying code
when the write is unaligned and crosses a page boundary. The procedure
for handling a write to the current translation block is to write-protect
the current translation block, catch the write, split up the translation
block into the current instruction (which remains write-protected so that
the current instruction is not modified) and the remaining instructions
in the translation block, and then restore the CPU state to before the
write occurred so the write will be retried and successfully executed.
However, since unaligned writes across pages are split into one-byte
writes for simplicity, writes to the second page (which is not the
current TB) may succeed before a write to the current TB is attempted,
and since these writes are not invalidated before resuming state after
splitting the TB, these writes will be performed a second time, thus
corrupting the second page. Credit goes to Patrick Hulin for
discovering this.
In recent 64-bit versions of Windows running in emulated mode, this
results in either being very unstable (a BSOD after a couple minutes of
uptime), or being entirely unable to boot. Windows performs one or more
8-byte unaligned self-modifying writes (xors) which intersect the end
of the current TB and the beginning of the next TB, which runs into the
aforementioned issue. This commit fixes that issue by making the
unaligned write loop perform the writes in forwards order, instead of
reverse order. This way, QEMU immediately tries to write to the current
TB, and splits the TB before any write to the second page is executed.
The write then proceeds as intended. With this patch applied, I am able
to boot and use Windows 7 64-bit and Windows 10 64-bit in QEMU without
KVM.
Per Richard Henderson's input, this patch also ensures the second page
is in the TLB before executing the write loop, to ensure the second
page is mapped.
The original discussion of the issue is located at
http://lists.nongnu.org/archive/html/qemu-devel/2014-08/msg02161.html.
Signed-off-by: Samuel Damashek <samuel.damashek@invincea.com>
Message-Id: <20160706182652.16190-1-samuel.damashek@invincea.com>
Signed-off-by: Richard Henderson <rth@twiddle.net>
[rth: Split out from the original patch.]
Signed-off-by: Samuel Damashek <samuel.damashek@invincea.com>
Message-Id: <20160706182652.16190-1-samuel.damashek@invincea.com>
Signed-off-by: Richard Henderson <rth@twiddle.net>
