Hi,
> -if (!cmd->finished) {
> +if (!cmd->finished && !(cmd->cmd_hdr.flags & VIRTIO_GPU_FLAG_FENCE)) {
> virtio_gpu_ctrl_response_nodata(g, cmd, cmd->error ? cmd->error :
> VIRTIO_GPU_RESP_OK_NODATA);
> }
My idea would be more
On Thu, Jun 10, 2021 at 01:46:47PM -0300, Lucas Mateus Castro (alqotel) wrote:
> Moved functions in mmu_helper.c that should be compiled in build to
"should be compiled in build" is not very clear to me. What's the
distinction between both the files.
> mmu_common.c, moved declaration of
On Thu, Jun 10, 2021 at 01:46:46PM -0300, Lucas Mateus Castro (alqotel) wrote:
> The function ppc_tlb_invalid_all is now a no op when compiling without TCG.
>
> Signed-off-by: Lucas Mateus Castro (alqotel)
Hm, I think I suggested making ppc_tlb_invalidate_all() a stub, rather
than removing the
On Mon, Jun 14, 2021 at 10:33:04PM -0300, Daniel Henrique Barboza wrote:
> spapr_numa_write_rtas_dt() is called from spapr_dt_rtas(), which in
> turned is called by spapr_build_fdt(). spapr_build_fdt() is called in
> two places: spapr_machine_reset() and do_client_architecture_support().
> When
Hi,
> +void egl_dmabuf_create_fence(QemuDmaBuf *dmabuf)
> +{
> +if (dmabuf->sync) {
> +dmabuf->fence_fd = eglDupNativeFenceFDANDROID(qemu_egl_display,
> + dmabuf->sync);
> +eglDestroySyncKHR(qemu_egl_display,
On 6/9/21 12:58 PM, Joel Stanley wrote:
> This contains some hardcoded register values that were obtained from the
> hardware after reading the temperature.
>
> It does enough to test the Linux kernel driver.
It should say briefly what are the device features, which are modeled and
which are
On Mon, Jun 14, 2021 at 10:19:27PM +, José Ricardo Ziviani wrote:
> Hello Gerd,
>
> On sexta-feira, 11 de junho de 2021 10:03:21 -03 Gerd Hoffmann wrote:
> > Hi,
> >
> > > Are there any pending patches to handle the remaining tcg dependencies
> > > in qemu? When trying to build tcg
> > Problem with that approach is that it doesn't work for module
> > dependencies ...
> >
> > Comments on the idea? Suggestions for the module dependency problem?
> > Could maybe libbfd be used to find module (symbol) dependencies
> > automatically without writing a full dynamic linker?
>
> Is
In the documentation of the '-detached' param "be" and "not" has been
used side by side, fix that.
Signed-off-by: Gollu Appalanaidu
---
hw/nvme/ctrl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/nvme/ctrl.c b/hw/nvme/ctrl.c
index d513b022c4..21883e4b3c 100644
---
Hi,
> Another possibility to eschew .o parsing is to add something like this to
> the sources
>
> #ifdef QEMU_MODINFO
> #define MODULE_METADATA(key, value) \
>=<>= MODINFO key value
> #else
> #define MODULE_METADATA(key, value)
> #endif
>
> MODULE_METADATA("opts", "spice")
>
> A Python
Add the controller identifiers list CNS 0x13, available list of ctrls
in NVM Subsystem that may or may not be attached to namespaces.
In Identify Ctrl List of the CNS 0x12 and 0x13 no endian conversion
for the nsid field.
These two CNS values shows affect when there exists a Subsystem.
Added
ping
On 17.05.2021 16:06, Pavel Dovgalyuk wrote:
virtio devices support separate iothreads waiting for
events from file descriptors. These are asynchronous
events that can't be recorded and replayed, therefore
this patch disables ioeventfd for all devices when
record or replay is enabled.
There are several new L1D cache flush bits added to the hcall which reflect
hardware security features for speculative cache access issues.
These behaviours are now being specified as negative in order to simplify
patched kernel compatibility with older firmware (a new problem found in
existing
Excerpts from David Gibson's message of May 5, 2021 2:20 pm:
> On Tue, May 04, 2021 at 06:50:54PM +1000, Nicholas Piggin wrote:
>> Excerpts from David Gibson's message of May 4, 2021 10:41 am:
>> > On Mon, May 03, 2021 at 10:58:33PM +1000, Nicholas Piggin wrote:
>> >> There are several new bits
On 6/9/21 12:58 PM, Joel Stanley wrote:
> Witherspoon uses the DPS310 as a temperature sensor. Rainier uses it as
> a temperature and humidity sensor.
>
> Signed-off-by: Joel Stanley
Reviewed-by: Cédric Le Goater
Thanks,
C.
> ---
> hw/arm/aspeed.c | 4 ++--
> 1 file changed, 2
> On Jun 14, 2021, at 9:20 PM, Richard Henderson
> wrote:
>
> On 6/13/21 2:15 PM, Jason Thorpe wrote:
>> +/* The following was copied from hw/isa/i82378.c and modified to provide
>> + only the minimal PCI device node. */
>> +
>> +/*
>> + * QEMU Intel i82378 emulation (PCI to ISA bridge)
>>
On 6/13/21 2:15 PM, Jason Thorpe wrote:
+/* The following was copied from hw/isa/i82378.c and modified to provide
+ only the minimal PCI device node. */
+
+/*
+ * QEMU Intel i82378 emulation (PCI to ISA bridge)
+ *
Why can't we just use the existing device model?
Certainly duplicating code
Cc: paolo and mst
On 6/13/21 2:15 PM, Jason Thorpe wrote:
Make the PF flag behave like real hardware by always running the
periodic timer without regard to the setting of the PIE bit, so
that the PF will be set when the period expires even if an interrupt
will not be raised. This behavior is
On 6/13/21 2:15 PM, Jason Thorpe wrote:
Redefine the a2 register passed by Qemu at start-up to also include
some configuration flags, in addition to the CPU count, and define
a flag to mirror the "-nographics" option.
Signed-off-by: Jason Thorpe
---
hw/alpha/dp264.c | 11 +++
1 file
On 6/13/21 2:15 PM, Jason Thorpe wrote:
Since we are emulating a Clipper device topology, we need to set the
minimum PCI device ID to 1, as there is no IRQ mapping for a device
at ID 0 (see sys_dp264.c:clipper_map_irq()).
- Add a 'devfn_min' argument to typhoon_init(). Pass that argument
On Mon, Jun 14, 2021 at 01:32:11PM -0400, John Snow wrote:
> Hi, I'd like to work out our collective preferences for how we triage issues
> that concern the execution environment; namely the arch (now "target", os,
> and accel labels.
>
> If you're CC'd on this mail, you're either listed as a TCG
On 6/14/21 5:29 PM, Jason Thorpe wrote:
On Jun 13, 2021, at 2:09 PM, Jason Thorpe wrote:
but there is still some research going on about how
real DEC SRM initializes a particular field in various circumstances;
this is my best guess based on available documentation and observed
behavior of
On 6/14/21 6:41 PM, David Gibson wrote:
I think move these to mmu-book3s-v3.h, since they're correct for both
the radix and hash sides of the modern book3s mmu.
They're also correct for all non-booke mmus, e.g. hash32 and 6xx, which is why I
recommended internal.h (or some new
Use s390_cpu_get_psw_mask so that we print the correct
architectural value of psw.mask. Do not print cc_op
unless tcg_enabled.
Signed-off-by: Richard Henderson
---
target/s390x/helper.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/target/s390x/helper.c
At present, we're referencing env->psw.mask directly, which
fails to ensure that env->cc_op is incorporated or updated.
Use s390_cpu_{set_psw,get_psw_mask} to fix this.
Mirror the kernel's cleaning of the psw.mask in save_sigregs
and restore_sigregs. Ignore PSW_MASK_RI for now, as qemu does
not
No change in behaviour, as gdbstub was correctly written to
install and extract the cc value.
Signed-off-by: Richard Henderson
---
target/s390x/gdbstub.c | 15 ++-
1 file changed, 2 insertions(+), 13 deletions(-)
diff --git a/target/s390x/gdbstub.c b/target/s390x/gdbstub.c
index
The PSW_MASK_CC component of psw.mask was not handled properly
in the creation or restoration of signal frames.
r~
Richard Henderson (5):
target/s390x: Expose load_psw and get_psw_mask to cpu.h
target/s390x: Do not modify cpu state in s390_cpu_get_psw_mask
target/s390x: Improve
Rename to s390_cpu_set_psw and s390_cpu_get_psw_mask at the
same time. Adjust so that they compile for user-only.
Signed-off-by: Richard Henderson
---
target/s390x/cpu.h | 3 ++
target/s390x/internal.h| 5 ---
target/s390x/cc_helper.c | 2 +-
target/s390x/excp_helper.c | 28
We want to use this function for debugging, and debug should
not modify cpu state (even non-architectural cpu state) lest
we introduce heisenbugs.
Signed-off-by: Richard Henderson
---
target/s390x/helper.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git
> -Original Message-
> From: Markus Armbruster
> Sent: Friday, June 11, 2021 5:37 PM
> To: Zhang, Chen
> Cc: Eric Blake ; Lukas Straub ;
> Daniel P.Berrangé ; Li Zhijian
> ; Jason Wang ; Markus
> Armbruster ; qemu-dev ;
> Gerd Hoffmann ; Zhang Chen ;
> Dr. David Alan Gilbert
>
On Jun 11 2021, at 4:30 am, Peter Maydell wrote:
> On Fri, 11 Jun 2021 at 00:39, Shashi Mallela
> wrote:
> >
> > Have addressed all comments except the ones with responses(inline) below:-
> >
> > On Jun 8 2021, at 9:57 am, Peter Maydell wrote:
> >
> > > + cs->lpivalid = false;
> > > +
On Tue, Jun 15, 2021 at 10:19 AM Bin Meng wrote:
>
> On Sun, Jun 13, 2021 at 10:12 PM Lukas Jünger
> wrote:
> >
> > Make function names consistent
> >
> > Signed-off-by: Lukas Jünger
> > ---
> > hw/char/sifive_uart.c | 46 ++-
> > 1 file changed, 24
On Sun, Jun 13, 2021 at 10:12 PM Lukas Jünger
wrote:
>
> Make function names consistent
>
> Signed-off-by: Lukas Jünger
> ---
> hw/char/sifive_uart.c | 46 ++-
> 1 file changed, 24 insertions(+), 22 deletions(-)
>
Reviewed-by: Bin Meng
On 6/14/2021 1:45 AM, Philippe Mathieu-Daudé wrote:
On 6/13/21 8:33 AM, Stefan Weil wrote:
Am 13.06.21 um 03:40 schrieb Brad Smith:
This same problem also applies to OpenBSD as we have the same
version of ncurses with support for wide characters. I have a similar
patch in our QEMU port.
On Mon, Jun 14, 2021 at 09:37:54PM +0200, Philippe Mathieu-Daudé wrote:
> On 6/14/21 9:16 PM, Bruno Larsen (billionai) wrote:
> > This patch changes ppc_cpu_get_phys_page_debug so that it is now
> > able to translate both, priviledged and real mode addresses
> > independently of whether the CPU
On Mon, Jun 14, 2021 at 06:04:13PM -0300, Fabiano Rosas wrote:
> "Bruno Larsen (billionai)" writes:
>
> > +/*
> > + * These correspond to the mmu_idx values computed in
> > + * hreg_compute_hflags_value. See the tables therein
> > + */
> > +static inline bool mmuidx_pr(int idx) { return !(idx &
On Mon, Jun 14, 2021 at 04:16:29PM -0300, Bruno Larsen (billionai) wrote:
> Based-on: <20210518201146.794854-1-richard.hender...@linaro.org>
>
> This commit attempts to fix the first bug mentioned by Richard Henderson in
> https://lists.nongnu.org/archive/html/qemu-devel/2021-05/msg06247.html
>
Using the new 'device-node' property, write it in the nvdimm DT to set a
secondary domain for the persistent memory operation mode.
Note that this is only available in FORM2 affinity. FORM1 affinity
NVDIMMs aren't affected by this change.
CC: Shivaprasad G Bhat
Signed-off-by: Daniel Henrique
FORM2 NUMA affinity is prepared to deal with memory/cpu less
NUMA nodes. This is used by the DAX KMEM driver to locate a
PAPR SCM device that has a different latency than the original
NUMA node from the regular memory.
Move this verification to FORM1 affinity code.
Signed-off-by: Daniel Henrique
When spapr_numa_associativity_init() was introduced it was being
called from spapr_machine_init(), where we have pointers to a
SpaprMachineState and a MachineState. Having both being passed
as params spared us from calling a macro to get the MachineState.
Previous patches moved the function away
The spapr-nvdimm driver is able to operate in two ways. The first
one is as a regular memory in which the NUMA node of the parent
pc-dimm class is used. The second mode, as persistent memory, allows for
a different NUMA node to be used based on the locality of the device.
At this moment we don't
The upcoming FORM2 NUMA affinity will support asymmetric NUMA topologies
and doesn't need be concerned with all the legacy support for older
pseries FORM1 guests.
We're also not going to calculate associativity domains based on numa
distance (via spapr_numa_define_associativity_domains) since the
spapr_numa_write_rtas_dt() is called from spapr_dt_rtas(), which in
turned is called by spapr_build_fdt(). spapr_build_fdt() is called in
two places: spapr_machine_reset() and do_client_architecture_support().
When called in machine_reset() we're writing RTAS nodes with NUMA
artifacts without
The main feature of FORM2 affinity support is the separation of NUMA
distances from ibm,associativity information. This allows for a more
flexible and straightforward NUMA distance assignment without relying on
complex associations between several levels of NUMA via
ibm,associativity matches.
The pSeries machine will support a new NUMA affinity form, FORM2.
This new FORM will be negotiated via ibm,architecture-vec5 during
CAS. All artifacts and assumptions that are currently on use for
FORM1 affinity will be deprecated in a guest that chooses to use
FORM2.
This means that we're going
Hi,
This RFC series implements FORM2 NUMA associativity support in
the pSeries machine. This new associativity format is going to
be added in the LOPAR spec in the near future. For now, the preview
of the specification can be found in Aneesh kernel side patches that
implements this support,
N¬Æ¦º[b¥ªíë,j¢Â ú+«g{Oj»vëß:ëâè4f
íz{S©ì}êÄÊ x*º^vâÖà¨×§µ<©z×±·úej)Ü
ªìz
signature.asc
Description: This is a digitally signed message part.
> On Jun 13, 2021, at 2:09 PM, Jason Thorpe wrote:
>
> but there is still some research going on about how
> real DEC SRM initializes a particular field in various circumstances;
> this is my best guess based on available documentation and observed
> behavior of real machines, and is
This no longer reproduces for me.
** Changed in: qemu
Status: Confirmed => Incomplete
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1913668
Title:
FPE in npcm7xx_pwm_calculate_freq
Status
OSS-Fuzz still has a functioning reproducer. I'll copy this one over to
gitlab
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1911216
Title:
abort issue locates in
On 6/7/21 11:31 AM, John Snow wrote:
Add "Bug" and "Feature Request" templates to the Gitlab interface to
help improve the quality of newly reported issues.
To see what this looks like, I've temporarily allowed my Gitlab fork to
diverge with these files merged. See my fork's "new issue" page
No. If we figure out some way to consistently reproduce double-fetches
in a non-fuzzer build, I'll report the issue again, but this can
probably be closed
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
OSS-Fuzz never came across this one. Probably fixed
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1892962
Title:
Segfault in usb_bus_from_device
Status in QEMU:
Incomplete
Bug description:
OSS-Fuzz says it was fixed some months ago, and it has not found a
reproducer since.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1888606
Title:
Heap-use-after-free in virtio_gpu_ctrl_response
This should have been fixed by the qemu_receive_packet/network loopback
patches from a few months ago
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1886362
Title:
Heap use-after-free in lduw_he_p
Patchew URL:
https://patchew.org/QEMU/20210614233143.1221879-1-richard.hender...@linaro.org/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Type: series
Message-id: 20210614233143.1221879-1-richard.hender...@linaro.org
Subject: [PATCH v2 0/8]
OSS-Fuzz never saw it. It was probably fixed
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1879223
Title:
Assertion failure in e1000e_write_rx_descr
Status in QEMU:
Incomplete
Bug description:
OSS-Fuzz never saw it. It was probably fixed
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1879227
Title:
Assertion failure in e1000e_write_lgcy_rx_descr
Status in QEMU:
Incomplete
Bug
This no longer causes timeout/excessive CPU usage for me. Probably fixed
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1880355
Title:
Length restrictions for fw_cfg_dma_transfer?
Status in QEMU:
All previous users now use C11 _Generic.
Signed-off-by: Richard Henderson
---
include/qemu/compiler.h | 40
1 file changed, 40 deletions(-)
diff --git a/include/qemu/compiler.h b/include/qemu/compiler.h
index 091c45248b..5766d61589 100644
---
_Static_assert is part of C11, which is now required.
Signed-off-by: Richard Henderson
---
configure | 18 --
include/qemu/compiler.h | 11 ---
2 files changed, 29 deletions(-)
diff --git a/configure b/configure
index 0489864667..debd50c085 100755
---
Create macros for file+line expansion in qemu_rec_mutex_unlock
like we have for qemu_mutex_unlock.
Signed-off-by: Richard Henderson
---
include/qemu/thread.h| 10 +-
util/qemu-thread-posix.c | 4 ++--
util/qemu-thread-win32.c | 2 +-
3 files changed, 12 insertions(+), 4
Looks like OSS-Fuzz has a reproducer that still works:
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=29192#c3
I'll move this one over to gitlab
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
This is both more and less complicated than our expansion
using __builtin_choose_expr and __builtin_types_compatible_p.
The expansion through QEMU_MAKE_LOCKABLE_ doesn't work because
we're not emumerating all of the types within the same _Generic,
which results in errors about unhandled cases.
We will shortly convert lockable.h to _Generic, and we cannot
have two compatible types in the same expansion. Wrap QemuMutex
in a struct, and unwrap in qemu-thread-posix.c.
Signed-off-by: Richard Henderson
---
include/qemu/thread-posix.h | 10 --
util/qemu-thread-posix.c| 12
Signed-off-by: Richard Henderson
---
fpu/softfloat.c | 16 ++--
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/fpu/softfloat.c b/fpu/softfloat.c
index 4d0160fe9c..6e769f990c 100644
--- a/fpu/softfloat.c
+++ b/fpu/softfloat.c
@@ -686,11 +686,13 @@ static float128
Now that we assume gcc 7.5 as a minimum, we have the option of
changing to a newer C standard. The two major new features that
I think apply are _Generic and _Static_assert.
While Paolo created a remarkably functional replacement for _Generic
using builtins, the error messages that you get out
Move the declarations from thread-win32.h into thread.h
and remove the macro redirection from thread-posix.h.
This will be required by following cleanups.
Signed-off-by: Richard Henderson
---
include/qemu/thread-posix.h | 4
include/qemu/thread-win32.h | 6 --
include/qemu/thread.h
Now that the minimum gcc version is 7.5, we can use C11.
This will allow lots of cleanups to the code, currently
hidden behind macros in include/qemu/compiler.h.
Signed-off-by: Richard Henderson
---
configure | 4 ++--
meson.build | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff
OSS-Fuzz never found it, though we are fuzzing a slightly different ehci
configuration there. I made a note of the arguments we should start
fuzzing on OSS-Fuzz, but I think this is safe to close.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is
Patchew URL:
https://patchew.org/QEMU/20210610133538.608390-1-pbonz...@redhat.com/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Type: series
Message-id: 20210610133538.608390-1-pbonz...@redhat.com
Subject: [PATCH 00/11] vl: compound
Patchew URL:
https://patchew.org/QEMU/20210610075908.3305506-1-zhiwei_...@c-sky.com/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Type: series
Message-id: 20210610075908.3305506-1-zhiwei_...@c-sky.com
Subject: [PATCH v2 00/37] target/riscv:
Patchew URL:
https://patchew.org/QEMU/20210610085831.19779-1-lizhij...@cn.fujitsu.com/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Type: series
Message-id: 20210610085831.19779-1-lizhij...@cn.fujitsu.com
Subject: [RFC PATCH]
Patchew URL:
https://patchew.org/QEMU/20210611162033.437690-1-mcasc...@redhat.com/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Type: series
Message-id: 20210611162033.437690-1-mcasc...@redhat.com
Subject: [PATCH] Test comment for
Patchew URL:
https://patchew.org/QEMU/20210610224837.670192-1-vivek.kasire...@intel.com/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Type: series
Message-id: 20210610224837.670192-1-vivek.kasire...@intel.com
Subject: [PATCH v2 0/8]
Patchew URL:
https://patchew.org/QEMU/20210614183849.20622-1-em...@aabouzied.com/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Type: series
Message-id: 20210614183849.20622-1-em...@aabouzied.com
Subject: [PATCH] net: Replace TAB
Patchew URL:
https://patchew.org/QEMU/20210611060024.46763-1-jasow...@redhat.com/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Type: series
Message-id: 20210611060024.46763-1-jasow...@redhat.com
Subject: [PULL 00/12] Net patches
=== TEST
Patchew URL:
https://patchew.org/QEMU/20210614083800.1166166-1-richard.hender...@linaro.org/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Type: series
Message-id: 20210614083800.1166166-1-richard.hender...@linaro.org
Subject: [PATCH 00/28]
Patchew URL:
https://patchew.org/QEMU/20210610114624.304681-1-jakub.jer...@kernkonzept.com/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Type: series
Message-id: 20210610114624.304681-1-jakub.jer...@kernkonzept.com
Subject: [PATCH] hw/nvme:
Patchew URL:
https://patchew.org/QEMU/20210611233347.653129-1-richard.hender...@linaro.org/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Type: series
Message-id: 20210611233347.653129-1-richard.hender...@linaro.org
Subject: [PATCH 0/8]
On 6/14/21 12:16 PM, Bruno Larsen (billionai) wrote:
This patch changes ppc_cpu_get_phys_page_debug so that it is now
able to translate both, priviledged and real mode addresses
independently of whether the CPU executing it has those permissions
This was mentioned by Fabiano as something that
Patchew URL:
https://patchew.org/QEMU/20210611164305.440633-1-mcasc...@redhat.com/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Type: series
Message-id: 20210611164305.440633-1-mcasc...@redhat.com
Subject: [PATCH v2] Test comment for
On 6/14/21 8:09 AM, Peter Maydell wrote:
- pass only ESIZE, not H, to macros in mve_helper.c
I've been thinking about the H* macros again while reading this.
While H##ESIZE is an improvement over passing in HN, I think we can do better and force
the adjustment to match the type --
Patchew URL: https://patchew.org/QEMU/20210610224450.23425-1-jzivi...@suse.de/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Type: series
Message-id: 20210610224450.23425-1-jzivi...@suse.de
Subject: [PATCH] tcg/arm: Fix tcg_out_op function
Patchew URL:
https://patchew.org/QEMU/20210614151007.4545-1-peter.mayd...@linaro.org/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Type: series
Message-id: 20210614151007.4545-1-peter.mayd...@linaro.org
Subject: [PATCH v2 00/57] target/arm:
Patchew URL:
https://patchew.org/QEMU/bcb8773b-fc54-4c25-9b60-92c263165...@gmail.com/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Type: series
Message-id: bcb8773b-fc54-4c25-9b60-92c263165...@gmail.com
Subject: tb_flush() calls causing
Patchew URL: https://patchew.org/QEMU/20210613211549.18094-1-thor...@me.com/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Type: series
Message-id: 20210613211549.18094-1-thor...@me.com
Subject: [PATCH 0/4] Emulator fixes to enable running
Patchew URL:
https://patchew.org/QEMU/20210609144512.211746-1-dgilb...@redhat.com/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Type: series
Message-id: 20210609144512.211746-1-dgilb...@redhat.com
Subject: [PULL 0/9] migration queue
===
On 6/14/21 8:10 AM, Peter Maydell wrote:
Implement the MVE VHCADD insn, which is similar to VCADD
but performs a halving step. This one overlaps with VADC.
Signed-off-by: Peter Maydell
---
target/arm/helper-mve.h| 8
target/arm/mve.decode | 8 ++--
On 6/14/21 8:10 AM, Peter Maydell wrote:
Implement the MVE VADC and VSBC insns. These perform an
add-with-carry or subtract-with-carry of the 32-bit elements in each
lane of the input vectors, where the carry-out of each add is the
carry-in of the next. The initial carry input is either 1 or
Patchew URL:
https://patchew.org/QEMU/20210602084106.43186-1-jasow...@redhat.com/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Type: series
Message-id: 20210602084106.43186-1-jasow...@redhat.com
Subject: [PATCH V2 0/2] vhost-vDPA: vq
On 6/14/21 4:12 PM, Philippe Mathieu-Daudé wrote:
G I forgot to commit:
-- >8 --
diff --git a/MAINTAINERS b/MAINTAINERS
index 7d9cd290426..636bf2f5365 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2707,7 +2707,6 @@ TPM
M: Stefan Berger
S: Maintained
F: tpm.c
-F: stubs/tpm.c
F:
On 6/14/21 8:09 AM, Peter Maydell wrote:
Implement the MVE VQSHL insn (encoding T4, which is the
vector-shift-by-vector version).
The DO_SQSHL_OP and DO_UQSHL_OP macros here are derived from
the neon_helper.c code for qshl_u{8,16,32} and qshl_s{8,16,32}.
Signed-off-by: Peter Maydell
---
On 6/14/21 8:09 AM, Peter Maydell wrote:
Implement the scalar form of the MVE VADD insn. This takes the
scalar operand from a general purpose register.
Signed-off-by: Peter Maydell
---
Reviewed-by: Richard Henderson
r~
On 6/14/21 8:09 AM, Peter Maydell wrote:
Implement the MVE VRMLALDAVH and VRMLSLDAVH insns, which accumulate
the results of a rounded multiply of pairs of elements into a 72-bit
accumulator, returning the top 64 bits in a pair of general purpose
registers.
Signed-off-by: Peter Maydell
---
"Bruno Larsen (billionai)" writes:
> This patch changes ppc_cpu_get_phys_page_debug so that it is now
> able to translate both, priviledged and real mode addresses
> independently of whether the CPU executing it has those permissions
>
> This was mentioned by Fabiano as something that would be
"Bruno Larsen (billionai)" writes:
> +/*
> + * These correspond to the mmu_idx values computed in
> + * hreg_compute_hflags_value. See the tables therein
> + */
> +static inline bool mmuidx_pr(int idx) { return !(idx & 1); }
> +/*
> + * If we want to use these macros for hash-style MMUs, we need
This patch adds entry for the vhost-user-rng related files.
Signed-off-by: Mathieu Poirier
---
MAINTAINERS | 9 +
1 file changed, 9 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 36055f14c594..4fedca72c183 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1951,6 +1951,15 @@ F:
This patch provides the vhost-user backend implementation to work
in tandem with the vhost-user-rng implementation of the QEMU VMM.
It uses the vhost-user API so that other VMM can re-use the interface
without having to write the driver again.
Signed-off-by: Mathieu Poirier
---
Add description and example for the vhost-user based RNG implementation.
Tailored on Viresh Kumar's vhost-user-i2c documentation.
Signed-off-by: Mathieu Poirier
---
docs/tools/vhost-user-rng.rst | 74 +++
1 file changed, 74 insertions(+)
create mode 100644
1 - 100 of 438 matches
Mail list logo
