On 11/3/23 20:12, Jessica Clarke wrote:
Without this, we just dirty a single byte, and so if the caller writes
more than one byte to the host memory then we won't have invalidated any
translation blocks that start after the first byte and overlap those
writes. In particular, AArch64's DC ZVA impl
Hi!
It looks like --disable-pie configure, which uses -fno-pie -no-pie flags
for the compiler, is broken: it does not not tell the *linker* about the
option, so the link fails (at least on debian bookworm):
/usr/bin/ld: libcommon.fa.p/hw_core_cpu-common.c.o: relocation R_X86_64_32 against `.roda
Reduce the number of direct checks against MMU_PHYS_IDX.
Signed-off-by: Richard Henderson
---
target/hppa/cpu.h| 1 +
target/hppa/mem_helper.c | 4 ++--
target/hppa/translate.c | 20 +++-
3 files changed, 14 insertions(+), 11 deletions(-)
diff --git a/target/hppa/cpu.
From: Helge Deller
Need to use iasq_b and iaoq_b to determine back register of CR_IIASQ.
This fixes random faults when booting up Linux user space.
Signed-off-by: Helge Deller
Reviewed-by: Richard Henderson
Signed-off-by: Richard Henderson
---
target/hppa/int_helper.c | 2 +-
1 file changed,
This is the maximum that was ever supported, in the PA-8700 thru
PA-8900. If we support a larger address space than expected, we
trip up software that did not fill in all of the page table bits,
expecting them to be ignored.
Signed-off-by: Richard Henderson
---
target/hppa/cpu-param.h | 2 +-
From: Helge Deller
Coverty found that the shift of TARGET_PAGE_SIZE (32-bit type) might
overflow. Fix it by casting TARGET_PAGE_SIZE to a 64-bit type before
doing the shift (CID 1523902 and CID 1523908).
Reported-by: Peter Maydell
Signed-off-by: Helge Deller
Message-Id:
Reviewed-by: Richard
During the conversion to decodetree, the 2-bit mask was lost.
Fixes: deee69a19fd ("target/hppa: Convert memory management insns")
Signed-off-by: Richard Henderson
---
target/hppa/translate.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/target/hppa/translate.c b/target/hppa
From: Helge Deller
Apply the "32-bit PCI addressing on 40-bit Runway" as the default
iommu transformation. This allows PCI devices to dma PDC memory.
Signed-off-by: Helge Deller
Acked-by: Richard Henderson
Signed-off-by: Richard Henderson
---
hw/pci-host/astro.c | 73 ++-
From: Helge Deller
The system mask is a restricted subset of the psw, with only
a couple of reserved bits. It is better to handle this up
front in the translator than require helper_swap_system_mask
to use cpu_hppa_get_psw and cpu_hppa_put_psw.
Signed-off-by: Helge Deller
[rth: Handle this in
Direct privilege level to mmu_idx mapping has been
false for some time. Provide the correct value to
hppa_get_physical_address.
Fixes: fa824d99f9b ("target/hppa: Switch to use MMU indices 11-15")
Signed-off-by: Richard Henderson
---
target/hppa/op_helper.c | 5 +++--
1 file changed, 3 insertion
From: Helge Deller
The new SeaBIOS-hppa version 11 includes the necessary fixes to
support emulated PA2.0 CPUs and which allows starting 64-bit Linux
kernels in the guest.
Signed-off-by: Helge Deller
---
hw/hppa/machine.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/h
Align the language with pa2.0, separating absolute and physical.
The translation from absolute to physical depends on PSW.W, and
we prefer not to flush between changes.
Signed-off-by: Richard Henderson
---
target/hppa/cpu.h| 26 +
target/hppa/mem_helper.c | 41 +++
Fixes to the recent hppa64 cpu support to enable booting
the 64-bit linux kernel to user-space.
r~
Helge Deller (6):
target/hppa: Update to SeaBIOS-hppa version 11
hw/hppa: Require at least SeaBIOS-hppa version 11
target/hppa: Mask reserved PSW bits in expand_sm_imm
target/hppa: Fix cal
Fixes to the recent hppa64 cpu support to enable booting
the 64-bit linux kernel to user-space.
r~
Helge Deller (6):
target/hppa: Update to SeaBIOS-hppa version 11
hw/hppa: Require at least SeaBIOS-hppa version 11
target/hppa: Mask reserved PSW bits in expand_sm_imm
target/hppa: Fix cal
In cpu_exec_step_atomic, we did not set CF_LAST_IO, which can
lead to a loop with cpu_io_recompile.
But since 18a536f1f8 ("Always require can_do_io") we no longer need
a flag to indicate when the last insn should have can_do_io set, so
remove the flag entirely.
Reported-by: Clément Chigot
Resolv
The old virtio-fs mailing list address is no longer in use. Switch to
the new mailing list address.
Cc: Philippe Mathieu-Daudé
Cc: Vivek Goyal
Cc: German Maglione
Cc: Hanna Czenczek
Signed-off-by: Stefan Hajnoczi
---
MAINTAINERS | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --g
Two functions were reported to have dead code, remove the bogus
branches altogether, as well as a misplaced qemu_log call.
Reported-by: Peter Maydell
Signed-off-by: Davidlohr Bueso
---
hw/cxl/cxl-mailbox-utils.c | 43 +-
1 file changed, 15 insertions(+), 28 d
On 11/10/23 11:35, Helge Deller wrote:
Coverty found that the shift of TARGET_PAGE_SIZE (32-bit type) might
overflow. Fix it by casting TARGET_PAGE_SIZE to a 64-bit type before
doing the shift (CID 1523902 and CID 1523908).
Reported-by: Peter Maydell
Signed-off-by: Helge Deller
Reviewed-by:
On Fri, Nov 10, 2023 at 6:36 PM Greg Manning wrote:
> Then hopefully when a plugin links to this, it gets the __pfnDliFailureHook2
> symbol defined and set up and everything would work. Except gcc strips
> out any unreferenced symbols from static libs when linking. So the plugin
> would have to be
Hello,
This patch series adds the basic support for virtio-pci for xen-arm
guests. The main changes are in "xen_arm: Add basic virtio-pci
support", while another 5 patches are adding groundwork. First 4
patches are required to run QEMU device model in a driver domain, not
only in Dom0.
Oleksandr
From: Oleksandr Tyshchenko
The PV backend running in other than Dom0 domain (non toolstack domain)
is not allowed to write frontend nodes. The more, the backend does not
need to do that at all, this is purely toolstack/xl devd business.
I do not know for what reason the backend does that here, t
From: Oleksandr Tyshchenko
The PV backend running in other than Dom0 domain (non toolstack domain)
is not allowed to destroy frontend/backend directories. The more,
it does not need to do that at all, this is purely toolstack/xl devd
business.
I do not know for what reason the backend does that
Add option to preserve owner when creating an entry in Xen Store. This
may be needed in cases when Qemu is working as device model in a
domain that is Domain-0, e.g. in driver domain.
"owner" parameter for qemu_xen_xs_create() function can have special
value XS_PRESERVE_OWNER, which will make spec
From: Oleksandr Tyshchenko
Instead of forcing the owner to domid 0, use XS_PRESERVE_OWNER to save
the previous owner of the directory.
Note that for other than Dom0 domain (non toolstack domain) the
"driver_domain" property should be set in domain config file for the
toolstack to create required
From: Oleksandr Tyshchenko
The number of vCPUs used for the IOREQ configuration (machine->smp.cpus)
should really match the system value as for each vCPU we setup a dedicated
evtchn for the communication with Xen at the runtime. This is needed
for the IOREQ to be properly configured and work if t
From: Oleksandr Tyshchenko
Both state (XenbusStateClosed) and online (0) are expected by
toolstack/xl devd to completely destroy the device. But "offline"
is never being set by the backend resulting in timeout during
domain destruction, garbage in Xestore and still running Qemu
instance.
Signed-
On Thu, Nov 09, 2023 at 06:15:51PM +0100, Thomas Huth wrote:
> On 09/11/2023 17.58, Daniel P. Berrangé wrote:
> > On Thu, Nov 09, 2023 at 04:35:56PM +0100, Philippe Mathieu-Daudé wrote:
> > > On 9/11/23 16:35, Philippe Mathieu-Daudé wrote:
> > > > This Cirrus-CI based job takes ~12min, similarly to
From: Oleksandr Tyshchenko
This patch adds basic virtio-pci support for xen_arm machine.
It provides a flexible way to configure virtio-pci resources with
xenstore. We made this for several reasons:
- We don't want to clash with vPCI devices, so we need information
from Xen toolstack on which
When calling trace_vmware_verify_rect_greater_than_bound() replace
"y" with "h" and y with h
Found by Linux Verification Center (linuxtesting.org) with SVACE.
Fixes: 02218aedb1 ("hw/display/vmware_vga: replace fprintf calls with trace
events")
Signed-off-by: Alexandra Diupina
---
hw/display/vm
On 11/10/23 21:25, Helge Deller wrote:
* Sam James :
Helge Deller writes:
On 11/3/23 13:53, Sam James wrote:
Sam James writes:
I recently hit an issue with systemd-254 which tries to use the new
prctl(PR_SET_MDWE) for systemd's MemoryDenyWriteExecute functionality.
Is this still a probl
* Sam James :
>
> Helge Deller writes:
>
> > On 11/3/23 13:53, Sam James wrote:
> >> Sam James writes:
> >>> I recently hit an issue with systemd-254 which tries to use the new
> >>> prctl(PR_SET_MDWE) for systemd's MemoryDenyWriteExecute functionality.
> >
> > Is this still a problem?
>
> Yes
We currently only need p->running to avoid calling qemu_thread_join()
on a non existent thread if the thread has never been created. We
could turn the QemuThread into a pointer and check for NULL instead
and get rid of the p->running flag. Testing the pointer directly is
more precise and less prone
This is being shadowed but the assignments at
multifd_channel_connect() and multifd_tls_channel_connect() .
Signed-off-by: Fabiano Rosas
---
migration/multifd.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/migration/multifd.c b/migration/multifd.c
index ec58c58082..40946
We're currently leaking the resources of the TLS thread by not joining
it and also overwriting the p->thread pointer altogether.
Signed-off-by: Fabiano Rosas
---
migration/multifd.c | 10 +-
migration/multifd.h | 1 +
2 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/migrat
changes:
- dropped the Error patch
- removed p->running
- joined the TLS thread
v1:
https://lore.kernel.org/r/20231109165856.15224-1-faro...@suse.de
We're calling qemu_sem_post() in threads other than the multifd
channel and the migration thread. This is vulnerable to a race with
multifd_save_cle
We cannot operate on the multifd semaphores outside of the multifd
channel thread because multifd_save_cleanup() can run in parallel and
attempt to destroy the mutexes, which causes an assert.
Looking at the places where we use the semaphores aside from the
migration thread, there's only the TLS h
Specs are available here:
https://www.nxp.com/docs/en/data-sheet/PCA9554_9554A.pdf
This is a simple model supporting the basic registers for GPIO
mode. The device also supports an interrupt output line but the
model does not yet support this.
Signed-off-by: Glenn Miles
---
MAINTAINERS
Tests the following for both P9 and P10:
- I2C master POR status
- I2C master status after immediate reset
Tests the following for P10 only:
- Config pca9552 hotplug device pins as inputs then
Read the INPUT0/1 registers to verify all pins are high
- Connected GPIO pin tests of P10 PCA
The PNV I2C Controller was clearing the status register
after a reset without repopulating the "upper threshold
for I2C ports", "Command Complete" and the SCL/SDA input
level fields.
Fixed this for resets caused by a system reset as well
as from writing to the "Immediate Reset" register.
Signed-o
The Power Hypervisor code expects to see a pca9554 device connected
to the 3rd PNV I2C engine on port 1 at I2C address 0x25 (or left-
justified address of 0x4A). This is used by the hypervisor code to
detect if a "Cable Card" is present.
Signed-off-by: Glenn Miles
---
hw/misc/Kconfig | 4 ++
The PNV I2C engines for power9 and power10 were being assigned a base
XSCOM address that was off by one I2C engine's address range such
that engine 0 had engine 1's address and so on. The xscom address
assignment was being based on the device tree engine numbering, which
starts at 1. Rather than
The Power Hypervisor code expects to see a pca9552 device connected
to the 3rd PNV I2C engine on port 1 at I2C address 0x63 (or left-
justified address of 0xC6). This is used by hypervisor code to
control PCIe slot power during hotplug events.
Signed-off-by: Glenn Miles
---
Based-on: <2023102418
This series of patches includes support, tests and fixes for
adding PCA9552 and PCA9554 I2C devices to the powernv10 chip.
The PCA9552 device is used for PCIe slot hotplug power control
and monitoring, while the PCA9554 device is used for presence
detection of IBM CableCard devices. Both devices
For power10, a pca9552 device is used for PCIe slot hotplug power
control by the Power Hypervisor code. The code expects that some
time after it enables power to a PCIe slot by asserting one of the
pca9552 GPIO pins 0-4, it should see a "power good" signal asserted
on one of pca9552 GPIO pins 5-9.
The QEMU I2C buses and devices use the resettable
interface for resetting while the PNV I2C controller
and parent buses and devices have not yet transitioned
to this new interface and use the old reset strategy.
This was preventing the I2C buses and devices wired
to the PNV I2C controller from bein
Coverty found that the shift of TARGET_PAGE_SIZE (32-bit type) might
overflow. Fix it by casting TARGET_PAGE_SIZE to a 64-bit type before
doing the shift (CID 1523902 and CID 1523908).
Reported-by: Peter Maydell
Signed-off-by: Helge Deller
diff --git a/target/hppa/mem_helper.c b/target/hppa/me
Cédric,
I have sent an updated version of the patch that fixes the vsx_f2i_nan.c
compilation errors and ./script/checkpatch.pl errors, and the updated version
of the patch can be found at
https://patchew.org/QEMU/sn6pr05mb5837524077f6c8a2a482b41a9d...@sn6pr05mb5837.namprd05.prod.outlook.com/.
>> From: Antonio Caggiano
>>
>> The first time gd_egl_scanout_texture() is called, there's a possibility
>> that the GTK drawing area might not be realized yet, in which case its
>> associated GdkWindow is NULL. This means gd_egl_init() was also skipped
>> and the EGLContext and EGLSurface stored
On 11/8/23 22:45, Peter Xu wrote:
On Mon, Nov 06, 2023 at 10:38:14PM +0100, William Roche wrote:
But it implies a lot of other changes:
- The source has to flag the error pages to indicate a poison
(new flag in the exchange protocole)
- The destination has to be able to deal wit
The patch below fixes a bug in the VSX_CVT_FP_TO_INT and VSX_CVT_FP_TO_INT2
macros in target/ppc/fpu_helper.c where a non-NaN floating point value from the
source vector is incorrectly converted to 0, 0x8000, or 0x8000
instead of the expected value if a preceding source floating poi
The patch below fixes a bug in the VSX_CVT_FP_TO_INT and VSX_CVT_FP_TO_INT2
macros in target/ppc/fpu_helper.c where a non-NaN floating point value from the
source vector is incorrectly converted to 0, 0x8000, or 0x8000
instead of the expected value if a preceding source floating poi
The patch below fixes a bug in the VSX_CVT_FP_TO_INT and VSX_CVT_FP_TO_INT2
macros in target/ppc/fpu_helper.c where a non-NaN floating point value from the
source vector is incorrectly converted to 0, 0x8000, or 0x8000
instead of the expected value if a preceding source floating poi
Support for probing the Zicboz block size landed in Linux 6.6, which was
released a few weeks ago. This provides the user-configured block size
when Zicboz is enabled.
Signed-off-by: Palmer Dabbelt
---
linux-user/syscall.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/linux-user/sys
The following set of changes are associated with issues exposed by testing
of the 'vfio: Adopt iommufd' series.
The first patch fixes an existing assumption that a vfio device will always
have a group fd (which is no longer true if cdev is used, which can only
happen once the iommufd backend is us
If the host kernel lacks vfio DMA limit reporting, do not attempt
to shrink the guest DMA aperture.
Fixes: df202e3ff3 ("s390x/pci: shrink DMA aperture to be bound by vfio DMA
limit")
Signed-off-by: Matthew Rosato
---
hw/s390x/s390-pci-vfio.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
The current code assumes that there is always a vfio group, but
that's no longer guaranteed with the iommufd backend when using
cdev. In this case, we don't need to track the vfio dma limit
anyway.
Signed-off-by: Matthew Rosato
---
hw/s390x/s390-pci-vfio.c | 4
1 file changed, 4 insertions
On Fri, 2023-11-10 at 11:22 -0600, Glenn Miles wrote:
> This series of patches includes support, tests and fixes for
> adding PCA9552 and PCA9554 I2C devices to the powernv10 chip.
>
> The PCA9552 device is used for PCIe slot hotplug power control
> and monitoring, while the PCA9554 device is used
> Previously, a plugin author needed an implementation of the
> __pfnDliFailureHook2 or __pfnDliNotifyHook2 hook in the plugin. Now all
> they need is a null exported pointer with the right name (as in
> win32_linker.c). If QEMU finds this, it will set it to the hook
> function, which has now moved
On 10/11/23 17:25, Peter Maydell wrote:
When we are doing a FEAT_MOPS copy that must be performed backwards,
we call mte_mops_probe_rev(), passing it the address of the last byte
in the region we are probing. However, allocation_tag_mem_probe()
wants the address of the first byte to get the tag
Commit 49554856f0 fixed a problem, where TPM devices were not appearing
in the FDT, by delaying the FDT creation up until virt_machine_done().
This create a side effect (see gitlab #1925) - devices that need access
to the '/chosen' FDT node during realize() stopped working because, at
that point, w
For power10, a pca9552 device is used for PCIe slot hotplug power
control by the Power Hypervisor code. The code expects that some
time after it enables power to a PCIe slot by asserting one of the
pca9552 GPIO pins 0-4, it should see a "power good" signal asserted
on one of pca9552 GPIO pins 5-9.
The Power Hypervisor code expects to see a pca9554 device connected
to the 3rd PNV I2C engine on port 1 at I2C address 0x25 (or left-
justified address of 0x4A). This is used by the hypervisor code to
detect if a "Cable Card" is present.
Signed-off-by: Glenn Miles
---
hw/misc/Kconfig | 4 ++
The QEMU I2C buses and devices use the resettable
interface for resetting while the PNV I2C controller
and parent buses and devices have not yet transitioned
to this new interface and use the old reset strategy.
This was preventing the I2C buses and devices wired
to the PNV I2C controller from bein
The PNV I2C engines for power9 and power10 were being assigned a base
XSCOM address that was off by one I2C engine's address range such
that engine 0 had engine 1's address and so on. The xscom address
assignment was being based on the device tree engine numbering, which
starts at 1. Rather than
The Power Hypervisor code expects to see a pca9552 device connected
to the 3rd PNV I2C engine on port 1 at I2C address 0x63 (or left-
justified address of 0xC6). This is used by hypervisor code to
control PCIe slot power during hotplug events.
Signed-off-by: Glenn Miles
---
hw/ppc/Kconfig | 1 +
Specs are available here:
https://www.nxp.com/docs/en/data-sheet/PCA9554_9554A.pdf
This is a simple model supporting the basic registers for GPIO
mode. The device also supports an interrupt output line but the
model does not yet support this.
Signed-off-by: Glenn Miles
---
MAINTAINERS
The PNV I2C Controller was clearing the status register
after a reset without repopulating the "upper threshold
for I2C ports", "Command Complete" and the SCL/SDA input
level fields.
Fixed this for resets caused by a system reset as well
as from writing to the "Immediate Reset" register.
Signed-o
Tests the following for both P9 and P10:
- I2C master POR status
- I2C master status after immediate reset
Tests the following for P10 only:
- Config pca9552 hotplug device pins as inputs then
Read the INPUT0/1 registers to verify all pins are high
- Connected GPIO pin tests of P10 PCA
The following changes since commit ea10c3817814b8be75be22c78ea91d633b0d2532:
Merge tag 'tracing-pull-request' of https://gitlab.com/stefanha/qemu into
staging (2023-11-10 08:10:43 +0800)
are available in the Git repository at:
https://repo.or.cz/qemu/kevin.git tags/qdev-array-prop
for you
This series of patches includes support, tests and fixes for
adding PCA9552 and PCA9554 I2C devices to the powernv10 chip.
The PCA9552 device is used for PCIe slot hotplug power control
and monitoring, while the PCA9554 device is used for presence
detection of IBM CableCard devices. Both devices
Observed the following failure while booting the SEV-SNP guest and the
guest fails to boot with the smp parameters:
"-smp 192,sockets=1,dies=12,cores=8,threads=2".
qemu-system-x86_64: sev_snp_launch_update: SNP_LAUNCH_UPDATE ret=-5 fw_error=22
'Invalid parameter'
qemu-system-x86_64: SEV-SNP: CPUI
In cpu_exec_step_atomic, we did not set CF_LAST_IO, which can
lead to a loop with cpu_io_recompile.
But since 18a536f1f8 ("Always require can_do_io") we no longer need
a flag to indicate when the last insn should have can_do_io set, so
remove the flag entirely.
Reported-by: Clément Chigot
Resolv
On Fri, Nov 10, 2023 at 11:44:48AM -0500, Kevin O'Connor wrote:
> On Fri, Nov 10, 2023 at 12:04:24PM +0100, Gerd Hoffmann wrote:
> > -if (CPUPhysBits) {
> > -u64 top = 1LL << CPUPhysBits;
> > +if (pci_phys_bits) {
>
> FYI, this is a change in behavior - previously this
On Fri, Nov 10, 2023 at 12:04:24PM +0100, Gerd Hoffmann wrote:
> Hi,
>
> > This only changes the placement of the PCI bars. The pci setup code is
> > the only consumer of that variable, guess it makes sense to move the
> > quirk to the pci code (as suggested by Kevin) to clarify this.
>
> i.e.
Replace a sweary comment with one that's a bit more helpful to
future readers of the code.
Signed-off-by: Peter Maydell
---
hw/audio/es1370.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/hw/audio/es1370.c b/hw/audio/es1370.c
index 91c47330ad3..fad55412119 100644
-
Hello John,
On 11/10/23 16:37, John Platts wrote:
The patch below fixes a bug in the VSX_CVT_FP_TO_INT and VSX_CVT_FP_TO_INT2
macros in target/ppc/fpu_helper.c where a non-NaN floating point value from the
source vector is incorrectly converted to 0, 0x8000, or 0x8000
instead of
When we are doing a FEAT_MOPS copy that must be performed backwards,
we call mte_mops_probe_rev(), passing it the address of the last byte
in the region we are probing. However, allocation_tag_mem_probe()
wants the address of the first byte to get the tag memory for.
Because we passed it (ptr, siz
From: Carwyn Ellis
Provides a new display option, zoom-interpolation, that enables or
disables smoothing of the scaled display output when the zoom-to-fit
option is enabled.
A 'Zoom Interpolation' item has also been added to the view menu to
allow interpolation to be toggled on and off as requir
From: Carwyn Ellis
Provides a new display option, zoom-interpolation, that enables
interpolation of the scaled display when zoom-to-fit is enabled.
Also provides a corresponding view menu item to allow this to be toggled
as required.
Signed-off-by: Carwyn Ellis
---
qapi/ui.json | 6 +-
u
Hi,
On Fri, Nov 10, 2023 at 01:54:50AM -0800, Andrea Bolognani wrote:
> On Thu, Nov 09, 2023 at 07:35:04PM +0100, Victor Toso wrote:
> > On Thu, Nov 09, 2023 at 09:29:28AM -0800, Andrea Bolognani wrote:
> > > Additionally, this would allow client code that *looks* at the
> > > union to keep workin
Hi,
On Fri, Nov 10, 2023 at 01:58:20AM -0800, Andrea Bolognani wrote:
> On Thu, Nov 09, 2023 at 08:01:48PM +0100, Victor Toso wrote:
> > On Thu, Nov 09, 2023 at 09:34:56AM -0800, Andrea Bolognani wrote:
> > > We should call this Null instead of IsNull, and also make it a
> > > pointer similarly to
The patch below fixes a bug in the VSX_CVT_FP_TO_INT and VSX_CVT_FP_TO_INT2
macros in target/ppc/fpu_helper.c where a non-NaN floating point value from the
source vector is incorrectly converted to 0, 0x8000, or 0x8000
instead of the expected value if a preceding source floating poi
The patch below fixes a bug in the VSX_CVT_FP_TO_INT and VSX_CVT_FP_TO_INT2
macros in target/ppc/fpu_helper.c where a non-NaN floating point value from the
source vector is incorrectly converted to 0, 0x8000, or 0x8000
instead of the expected value if a preceding source floating poi
The patch below fixes a bug in the VSX_CVT_FP_TO_INT and VSX_CVT_FP_TO_INT2
macros in target/ppc/fpu_helper.c where a non-NaN floating point value from the
source vector is incorrectly converted to 0, 0x8000, or 0x8000
instead of the expected value if a preceding source floating
From: Daniel Stone
A new ioctl to shuttle information between host and guest about the
actual buffer allocation, which can be used for interop between GL and
Vulkan when supporting standard window systems.
---
hw/display/virtio-gpu-base.c| 4 ++
hw/display/virtio-gpu-virgl.c
Modify resource_query_layout to handle the use case that need to query
correct stride for guest linear resource before it is created.
Signed-off-by: Julia Zhang
---
hw/display/virtio-gpu-virgl.c | 20 +++-
include/standard-headers/linux/virtio_gpu.h | 8
2
This add implementation of resource_query_layout to get the information of
how the host has actually allocated the buffer. This function is now used
to query the stride for guest linear resource for dGPU prime on guest VMs.
Related mesa mr: https:
//gitlab.freedesktop.org/mesa/mesa/-/merge_request
Hi
On Thu, Nov 9, 2023 at 4:05 PM Janosch Frank wrote:
>
> Small cleanups/fixes to the dump info function pointer assignments as
> well as a new function pointer for cleanup of residual state.
>
> This has come up because test managed to dump a s390 PV vm onto a disk
> that was too small for the
On 10/31/23 18:33, Hanna Czenczek wrote:
> (Sorry, opened another reply window, forgot I already had one open...)
>
> On 20.10.23 23:56, Andrey Drobyshev wrote:
>> This commit makes the discard operation work on the subcluster level
>> rather than cluster level. It introduces discard_l2_subcluste
On 11/3/23 17:19, Hanna Czenczek wrote:
> On 20.10.23 23:56, Andrey Drobyshev wrote:
>> When zeroizing subclusters within single cluster, detect usage of the
>> BDRV_REQ_MAY_UNMAP flag and fall through to the subcluster-based discard
>> operation, much like it's done with the cluster-based discards
On 10/11/2023 03:15, Duan, Zhenzhong wrote:
> Hi Jason, Joao,
>
>> -Original Message-
>> From: Jason Gunthorpe
>> Sent: Thursday, November 9, 2023 10:35 PM
>> Subject: Re: [PATCH v4 28/41] vfio/iommufd: Implement the iommufd backend
>>
>> On Thu, Nov 09, 2023 at 01:21:59PM +, Joao Mar
On 10/11/23 12:20, Daniel P. Berrangé wrote:
On Fri, Nov 10, 2023 at 12:44:56PM +0200, Manos Pitsidianakis wrote:
On Fri, 10 Nov 2023 12:21, Peter Maydell wrote:
This kind of thing is why Coverity's unused-result warning has a
lot of false positives. We shouldn't introduce extra code like
this
Fabiano Rosas writes:
> Peter Xu writes:
>
>> On Thu, Nov 09, 2023 at 01:58:56PM -0300, Fabiano Rosas wrote:
>>> We cannot operate on the multifd semaphores outside of the multifd
>>> channel thread
>>> because multifd_save_cleanup() can run in parallel and
>>> attempt to destroy the mutexes, wh
Taylor Simpson wrote:
>
> RFC - This patch handles gen_tcg_funcs.py. I'd like to get comments
> on the general approach before working on the other Python scripts.
>
> The generators are generally a bunch of Python if-then-else
> statements based on the regtype and regid. Encapsulate regtype/re
Peter Xu writes:
> On Thu, Nov 09, 2023 at 01:58:56PM -0300, Fabiano Rosas wrote:
>> We cannot operate on the multifd semaphores outside of the multifd
>> channel thread
>> because multifd_save_cleanup() can run in parallel and
>> attempt to destroy the mutexes, which causes an assert.
>>
>> Loo
On Fri, Nov 10, 2023 at 10:19:30AM +, Peter Maydell wrote:
> On Fri, 10 Nov 2023 at 09:07, Jean-Philippe Brucker
> wrote:
> >
> > Since commit 9036e917f8 ("{include/}hw/arm: refactor virt PPI logic"),
> > GIC maintenance IRQ registration fails on arm64:
> >
> > [0.979743] kvm [1]: Cannot r
On Fri, Nov 10, 2023 at 12:35:56PM +0100, BALATON Zoltan wrote:
> On Fri, 10 Nov 2023, Daniel P. Berrangé wrote:
> > On Fri, Nov 10, 2023 at 12:44:56PM +0200, Manos Pitsidianakis wrote:
> > > On Fri, 10 Nov 2023 12:21, Peter Maydell wrote:
> > > > This kind of thing is why Coverity's unused-result
On Fri, 10 Nov 2023, Daniel P. Berrangé wrote:
On Fri, Nov 10, 2023 at 12:44:56PM +0200, Manos Pitsidianakis wrote:
On Fri, 10 Nov 2023 12:21, Peter Maydell wrote:
This kind of thing is why Coverity's unused-result warning has a
lot of false positives. We shouldn't introduce extra code like
th
On Fri, 10 Nov 2023 13:23, "Daniel P. Berrangé" wrote:
On Fri, Nov 10, 2023 at 11:18:39AM +, Peter Maydell wrote:
On Fri, 10 Nov 2023 at 11:02, Manos Pitsidianakis
wrote:
>
> On Fri, 10 Nov 2023 12:21, Peter Maydell wrote:
> >This kind of thing is why Coverity's unused-result warning has
On Fri, 10 Nov 2023 13:20, "Daniel P. Berrangé" wrote:
Your approach to the problem:
if (!AUD_register_card("OMAP EAC", &s->codec.card, &error_fatal)) {
exit(1);
}
is adding dead-code because the exit(1) will never be reachable. So while
it lets you squelch the unused result warning, it i
1 - 100 of 149 matches
Mail list logo
