Previously, we required bits 5, 6 and 7 to be zero (0x07 == 0b111). But,
as per the principles of operation, bit 5 is ignored in MSCH and bits 0,
1, 6 and 7 need to be zero.
As both PMCW_FLAGS_MASK_INVALID and ioinst_schib_valid() are only used
by ioinst_handle_msch(), adjust the mask accordingly.
Fixes: db1c8f53bf ("s390: Channel I/O basic definitions.")
Signed-off-by: Nico Boehr <nrb@linux.ibm.com>
Reviewed-by: Pierre Morel <pmorel@linux.ibm.com>
Reviewed-by: Halil Pasic <pasic@linux.ibm.com>
Reviewed-by: Janosch Frank <frankja@linux.ibm.com>
Reviewed-by: Cornelia Huck <cohuck@redhat.com>
Message-Id: <20211216131657.1057978-1-nrb@linux.ibm.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
Currently QEMU defaults to a resolution of 1024x768 when exposing EDID
info to the guest OS. The EDID default info is important as this will
influence what resolution many guest OS will configure the screen with
on boot. It can also potentially influence what resolution the firmware
will configure the screen with, though until very recently EDK2 would
not handle EDID info.
One important thing to bear in mind is that the default graphics card
driver provided by Windows will leave the display set to whatever
resolution was enabled by the firmware on boot. Even if sufficient
VRAM is available, the resolution can't be changed without installing
new drivers. IOW, the default resolution choice is quite important
for usability of Windows.
Modern real world monitor hardware for desktop/laptop has supported
resolutions higher than 1024x768 for a long time now, perhaps as long
as 15+ years. There are quite a wide variety of native resolutions in
use today, however, and in wide screen form factors the height may not
be all that tall.
None the less, it is considered that there is scope for making the
QEMU default resolution slightly larger.
In considering what possible new default could be suitable, choices
considered were 1280x720 (720p), 1280x800 (WXGA) and 1280x1024 (SXGA).
In many ways, vertical space is the most important, and so 720p was
discarded due to loosing vertical space, despite being 25% wider.
The SXGA resolution would be good, but when taking into account
window titlebars/toolbars and window manager desktop UI, this might
be a little too tall for some users to fit the guest on their physical
montior.
This patch thus suggests a modest change to 1280x800 (WXGA). This
only consumes 1 MB per colour channel, allowing double buffered
framebuffer in 8 MB of VRAM. Width wise this is 25% larger than
QEMU's current default, but height wise this only adds 5%, so the
difference isn't massive on the QEMU side.
Overall there doesn't appear to be a compelling reason to stick
with 1024x768 resolution.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Reviewed-by: Gerd Hoffmann <kraxel@redhat.com>
Message-Id: <20211129140508.1745130-1-berrange@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Introduce TYPE_VGA_MMIO, a sysbus device.
While there is no change in the vga_mmio_init()
interface, this is a migration compatibility break
of the MIPS Acer Pica 61 Jazz machine (pica61).
Suggested-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: BALATON Zoltan <balaton@eik.bme.hu>
Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Message-Id: <20211206224528.563588-4-f4bug@amsat.org>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
There is no ISA bus part in the MMIO VGA device, so rename:
* hw/display/vga-isa-mm.c -> hw/display/vga-mmio.c
* CONFIG_VGA_ISA_MM -> CONFIG_VGA_MMIO
* ISAVGAMMState -> VGAMmioState
* isa_vga_mm_init() -> vga_mmio_init()
Reviewed-by: BALATON Zoltan <balaton@eik.bme.hu>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Message-Id: <20211206224528.563588-2-f4bug@amsat.org>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
The return value of virtio_blk_handle_vq() is no longer used. Get rid of
it. This is a step towards unifying the dataplane and non-dataplane
virtqueue handler functions.
Prepare virtio_blk_handle_output() to be used by both dataplane and
non-dataplane by making the condition for starting ioeventfd more
specific. This way it won't trigger when dataplane has already been
started.
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: Stefano Garzarella <sgarzare@redhat.com>
Message-id: 20211207132336.36627-4-stefanha@redhat.com
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
The virtqueue host notifier API
virtio_queue_aio_set_host_notifier_handler() polls the virtqueue for new
buffers. AioContext previously required a bool progress return value
indicating whether an event was handled or not. This is no longer
necessary because the AioContext polling API has been split into a poll
check function and an event handler function. The event handler is only
run when we know there is work to do, so it doesn't return bool.
The VirtIOHandleAIOOutput function signature is now the same as
VirtIOHandleOutput. Get rid of the bool return value.
Further simplifications will be made for virtio-blk and virtio-scsi in
the next patch.
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: Stefano Garzarella <sgarzare@redhat.com>
Message-id: 20211207132336.36627-3-stefanha@redhat.com
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
At this moment, stack->phb is the plain PnvPHB4 device itself instead of
a pointer to the device. This will present a problem when adding user
creatable devices because we can't deal with this struct and the
realize() callback from the user creatable device.
We can't get rid of this attribute, similar to what we did when enabling
pnv-phb3 user creatable devices, because pnv_phb4_update_regions() needs
to access stack->phb to do its job. This function is called twice in
pnv_pec_stk_update_map(), which is one of the nested xscom write
callbacks (via pnv_pec_stk_nest_xscom_write()). In fact,
pnv_pec_stk_update_map() code comment is explicit about how the order of
the unmap/map operations relates with the PHB subregions.
All of this indicates that this code is tied together in a way that we
either go on a crusade, featuring lots of refactories and redesign and
considerable pain, to decouple stack and phb mapping, or we allow stack
update_map operations to access the associated PHB as it is today even
after introducing pnv-phb4 user devices.
This patch chooses the latter. Instead of getting rid of stack->phb,
turn it into a PHB pointer. This will allow us to assign an user created
PHB to an existing stack later. In this process,
pnv_pec_stk_instance_init() is removed because stack->phb is being
initialized in stk_realize() instead.
Reviewed-by: Cédric Le Goater <clg@kaod.org>
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Message-Id: <20220111131027.599784-4-danielhb413@gmail.com>
Signed-off-by: Cédric Le Goater <clg@kaod.org>
The logic inside pnv_pec_phb_offset() will be useful in the next patch
to determine the stack that should contain a PHB4 device.
Move the function to pnv_phb4.c and make it public since there's no
pnv_phb4_pec.h header. While we're at it, add 'stack_index' as a
parameter and make the function return 'phb-id' directly. And rename it
to pnv_phb4_pec_get_phb_id() to be even clearer about the function
intent.
Reviewed-by: Cédric Le Goater <clg@kaod.org>
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Message-Id: <20220110143346.455901-3-danielhb413@gmail.com>
Signed-off-by: Cédric Le Goater <clg@kaod.org>
Similar to what was happening with pnv-phb3 buses,
TYPE_PNV_PHB4_ROOT_BUS set to "pnv-phb4-root-bus" is a bit too long for
a default root bus name. The usual default name for theses buses in QEMU
are 'pcie', but we want to make a distinction between pnv-phb4 buses and
other PCIE buses, at least as far as default name goes, because not all
PCIE devices are attachable to a pnv-phb4 root-bus type.
Changing the default to 'pnv-phb4-root' allow us to have a shorter name
while making this bus distinct, and the user can always set its own bus
naming via the "id" attribute anyway.
This is the 'info qtree' output after this change, using a powernv9
domain with 2 sockets and default settings enabled:
qemu-system-ppc64 -m 4G -machine powernv9,accel=tcg \
-smp 2,sockets=2,cores=1,threads=1
dev: pnv-phb4, id ""
index = 5 (0x5)
chip-id = 1 (0x1)
version = 704374636546 (0xa400000002)
device-id = 1217 (0x4c1)
x-config-reg-migration-enabled = true
bypass-iommu = false
bus: pnv-phb4-root.11
type pnv-phb4-root
dev: pnv-phb4-root-port, id ""
(...)
dev: pnv-phb4, id ""
index = 0 (0x0)
chip-id = 1 (0x1)
version = 704374636546 (0xa400000002)
device-id = 1217 (0x4c1)
x-config-reg-migration-enabled = true
bypass-iommu = false
bus: pnv-phb4-root.6
type pnv-phb4-root
dev: pnv-phb4-root-port, id ""
(..)
dev: pnv-phb4, id ""
index = 5 (0x5)
chip-id = 0 (0x0)
version = 704374636546 (0xa400000002)
device-id = 1217 (0x4c1)
x-config-reg-migration-enabled = true
bypass-iommu = false
bus: pnv-phb4-root.5
type pnv-phb4-root
dev: pnv-phb4-root-port, id ""
(...)
dev: pnv-phb4, id ""
index = 0 (0x0)
chip-id = 0 (0x0)
version = 704374636546 (0xa400000002)
device-id = 1217 (0x4c1)
x-config-reg-migration-enabled = true
bypass-iommu = false
bus: pnv-phb4-root.0
type pnv-phb4-root
dev: pnv-phb4-root-port, id ""
Reviewed-by: Cédric Le Goater <clg@kaod.org>
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Message-Id: <20220110143346.455901-11-danielhb413@gmail.com>
Signed-off-by: Cédric Le Goater <clg@kaod.org>
The TYPE_PNV_PHB3_ROOT_BUS name is used as the default bus name when
the dev has no 'id'. However, pnv-phb3-root-bus is a bit too long to be
used as a bus name.
Most common QEMU buses and PCI controllers are named based on their bus
type (e.g. pSeries spapr-pci-host-bridge is called 'pci'). The most
common name for a PCIE bus controller in QEMU is 'pcie'. Naming it
'pcie' would break the documented use of the pnv-phb3 device, since
'pcie.0' would now refer to the root bus instead of the first root port.
There's nothing particularly wrong with the 'root-bus' name used before,
aside from the fact that 'root-bus' is being used for pnv-phb3 and
pnv-phb4 created buses, which is not quite correct since these buses
aren't implemented the same way in QEMU - you can't plug a
pnv-phb4-root-port into a pnv-phb3 root bus, for example.
This patch renames it as 'pnv-phb3-root', which is a compromise between
the existing and the previously used name. Creating 3 phbs without ID
will result in an "info qtree" output similar to this:
bus: main-system-bus
type System
dev: pnv-phb3, id ""
index = 2 (0x2)
chip-id = 0 (0x0)
x-config-reg-migration-enabled = true
bypass-iommu = false
bus: pnv-phb3-root.2
type pnv-phb3-root
(...)
dev: pnv-phb3, id ""
index = 1 (0x1)
chip-id = 0 (0x0)
x-config-reg-migration-enabled = true
bypass-iommu = false
bus: pnv-phb3-root.1
type pnv-phb3-root
(...)
dev: pnv-phb3, id ""
index = 0 (0x0)
chip-id = 0 (0x0)
x-config-reg-migration-enabled = true
bypass-iommu = false
bus: pnv-phb3-root.0
type pnv-phb3-root
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Message-Id: <20220105212338.49899-11-danielhb413@gmail.com>
Signed-off-by: Cédric Le Goater <clg@kaod.org>
The powernv machine uses the object hierarchy to populate the device
tree and each device should be parented to the chip it belongs to.
This is not the case for user created devices which are parented to
the container "/unattached".
Make sure a PHB3 device is parented to its chip by reparenting the
object if necessary.
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Reviewed-by: Frederic Barrat <fbarrat@linux.ibm.com>
Signed-off-by: Cédric Le Goater <clg@kaod.org>
Message-Id: <20220105212338.49899-8-danielhb413@gmail.com>
Signed-off-by: Cédric Le Goater <clg@kaod.org>
PHB3 devices and PCI devices can now be added to the powernv8 machine
using :
-device pnv-phb3,chip-id=0,index=1 \
-device nec-usb-xhci,bus=pci.1,addr=0x0
The 'index' property identifies the PHB3 in the chip. In case of user
created devices, a lookup on 'chip-id' is required to assign the
owning chip.
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Signed-off-by: Cédric Le Goater <clg@kaod.org>
Message-Id: <20220105212338.49899-7-danielhb413@gmail.com>
Signed-off-by: Cédric Le Goater <clg@kaod.org>
We want to create only the absolutely minimal amount of devices when
running with -nodefaults. The root port is something that the machine
can boot up without. But, to do that, we need to provide a way for the
user to add them by hand.
This patch makes pnv-phb4-root-port user creatable and then uses the
pnv_phb_attach_root_port() helper to add a pnv_phb4_root_port only when
running with default settings.
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Message-Id: <20220105212338.49899-5-danielhb413@gmail.com>
Signed-off-by: Cédric Le Goater <clg@kaod.org>
This cleanups the PHB3 model a bit more since the root port is an
independent device and it will ease our task when adding user created
PHB3s.
pnv_phb_attach_root_port() is made public in pnv.c so it can be reused
with the pnv_phb4 root port later.
Signed-off-by: Cédric Le Goater <clg@kaod.org>
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Message-Id: <20220105212338.49899-4-danielhb413@gmail.com>
Signed-off-by: Cédric Le Goater <clg@kaod.org>
