On 11/25/20 3:49 AM, Joel Stanley wrote:
> On Fri, 20 Nov 2020 at 16:16, Cédric Le Goater wrote:
>>
>> The controller has a set of hidden bits to request/grant DMA access.
>
> Do you have the ast2600 datasheet? It describes these bits:
>
> 31 RW DMA Request
>
> Write SPIR80 = 0xAEED to set
Public bug reported:
Hello,
I found an assertion failure in hw/scsi/lsi53c895a.c:624
This was found in latest version 5.2.0.
my reproduced environment is as follows:
Host: ubuntu 18.04
Guest: ubuntu 18.04
QEMU boot command line:
qemu-system-x86_64 -enable-kvm -boot c -m 4G -drive
On 2020/11/21 上午2:50, Eugenio Pérez wrote:
This series enable vDPA software assisted live migration for vhost-net
devices. This is a new method of vhost devices migration: Instead of
relay on vDPA device's dirty logging capability, SW assisted LM
intercepts dataplane, forwarding the
Eduardo Habkost writes:
> On Tue, Nov 24, 2020 at 04:20:37PM +0100, Markus Armbruster wrote:
>> Eduardo Habkost writes:
>>
>> > On Tue, Nov 24, 2020 at 09:49:30AM +0100, Markus Armbruster wrote:
>> >> Eduardo Habkost writes:
>> >>
>> >> > On Mon, Nov 23, 2020 at 08:51:27AM +0100, Markus
Proposed patches:
https://patchew.org/QEMU/20201125040642.2339476-1-richard.hender...@linaro.org/
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1905356
Title:
No check for unaligned data access in
On 24/11/2020 22.19, Olaf Hering wrote:
> Since meson.git#0240d760c7699a059cc89e584363c6431cdd2b61 setuptools is not
> required anymore.
That commit was part of meson 0.55.1. We require at least meson 0.55.3. So
right, this should be fine.
> Signed-off-by: Olaf Hering
> ---
> configure | 3
Signed-off-by: Richard Henderson
---
target/arm/translate-neon.c.inc | 39 ++---
1 file changed, 31 insertions(+), 8 deletions(-)
diff --git a/target/arm/translate-neon.c.inc b/target/arm/translate-neon.c.inc
index 330b5fc7b0..160dc3d755 100644
---
Signed-off-by: Richard Henderson
---
target/arm/translate-neon.c.inc | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/target/arm/translate-neon.c.inc b/target/arm/translate-neon.c.inc
index f6c68e30ab..32e47331a5 100644
--- a/target/arm/translate-neon.c.inc
+++
Signed-off-by: Richard Henderson
---
target/arm/translate.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/target/arm/translate.c b/target/arm/translate.c
index 4406f6a67c..b1f43bfb8f 100644
--- a/target/arm/translate.c
+++ b/target/arm/translate.c
@@ -5124,11 +5124,13
Signed-off-by: Richard Henderson
---
target/arm/translate-neon.c.inc | 16 +---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/target/arm/translate-neon.c.inc b/target/arm/translate-neon.c.inc
index 32e47331a5..c4be019d9c 100644
--- a/target/arm/translate-neon.c.inc
Because for user-only, we cheat and use host load/store
operations directly. This makes for much faster emulation
but imposes a number of limitations -- including ignoring
of the alignment bits on hosts that have native unaligned
accesses.
As a corollary, when running user-only on a host that
The encoding of size = 2 and size = 3 had the incorrect decode
for align, overlapping the stride field. This error was hidden
by what should have been unnecessary masking in translate.
Signed-off-by: Richard Henderson
---
target/arm/neon-ls.decode | 4 ++--
Signed-off-by: Richard Henderson
---
target/arm/translate.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/target/arm/translate.c b/target/arm/translate.c
index 73b3d8cbbf..fe4400fa6c 100644
--- a/target/arm/translate.c
+++ b/target/arm/translate.c
@@ -7814,7 +7814,7 @@
Signed-off-by: Richard Henderson
---
target/arm/translate.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/target/arm/translate.c b/target/arm/translate.c
index 17883d00f4..73b3d8cbbf 100644
--- a/target/arm/translate.c
+++ b/target/arm/translate.c
@@ -6876,7 +6876,7
Signed-off-by: Richard Henderson
---
target/arm/translate-vfp.c.inc | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/target/arm/translate-vfp.c.inc b/target/arm/translate-vfp.c.inc
index 96948f5a2d..58b31ecc3f 100644
--- a/target/arm/translate-vfp.c.inc
+++
Signed-off-by: Richard Henderson
---
target/arm/translate-vfp.c.inc | 18 --
1 file changed, 12 insertions(+), 6 deletions(-)
diff --git a/target/arm/translate-vfp.c.inc b/target/arm/translate-vfp.c.inc
index 58b31ecc3f..51e85c2767 100644
--- a/target/arm/translate-vfp.c.inc
+++
Signed-off-by: Richard Henderson
---
target/arm/translate.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/target/arm/translate.c b/target/arm/translate.c
index fe4400fa6c..4406f6a67c 100644
--- a/target/arm/translate.c
+++ b/target/arm/translate.c
@@ -8250,10 +8250,12
Signed-off-by: Richard Henderson
---
target/arm/translate.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/target/arm/translate.c b/target/arm/translate.c
index 6d04ca3a8a..17883d00f4 100644
--- a/target/arm/translate.c
+++ b/target/arm/translate.c
@@ -6458,7 +6458,7
As reported in https://bugs.launchpad.net/bugs/1905356
Not implementing SCTLR.A, but all of the other required
alignment for SCTLR.A=0 in Table A3-1.
r~
Richard Henderson (11):
target/arm: Enforce word alignment for LDRD/STRD
target/arm: Enforce alignment for LDA/LDAH/STL/STLH
Thanks for confirmation.
Btw: I was wondering why the fix will only apply to system mode rather
than user-only mode. Unaligned data access is not permitted in user
level programs, either.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to
** Changed in: qemu
Assignee: (unassigned) => Richard Henderson (rth)
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1905356
Title:
No check for unaligned data access in ARM32 instructions
On Fri, 20 Nov 2020 at 16:16, Cédric Le Goater wrote:
>
> The controller can be configured to disable or enable address and data
> byte lanes when issuing commands. This is useful in read command mode
> to send SPI NOR commands that don't have an address space, such as
> RDID. It's a good way to
On Fri, 20 Nov 2020 at 16:16, Cédric Le Goater wrote:
>
> The controller has a set of hidden bits to request/grant DMA access.
Do you have the ast2600 datasheet? It describes these bits:
31 RW DMA Request
Write SPIR80 = 0xAEED to set this bit ot '1'.
And hardware will clear the request to
On Tue, Nov 24, 2020 at 02:07:27PM +0100, Greg Kurz wrote:
> On Mon, 23 Nov 2020 16:13:18 +1100
> David Gibson wrote:
>
> > On Sat, Nov 21, 2020 at 12:42:04AM +0100, Greg Kurz wrote:
> > > spapr_core_pre_plug() already guarantees that the slot for the given core
> > > ID is available. It is thus
On Mon, Nov 23, 2020 at 12:51:08PM +0100, Greg Kurz wrote:
> On Mon, 23 Nov 2020 16:11:30 +1100
> David Gibson wrote:
>
> > On Sat, Nov 21, 2020 at 12:42:03AM +0100, Greg Kurz wrote:
> > > When it comes to resetting the compat mode of the vCPUS, there are
> > > two situations to consider:
> > >
A lot of users of UTM are on iOS 13 (a large number of devices only
have jailbreak for iOS 13 and below), but if the QEMU community thinks
it's better that way, we are willing to compromise.
-j
On Tue, Nov 24, 2020 at 7:15 PM Alexander Graf wrote:
>
>
> On 20.11.20 16:58, Joelle van Dyne wrote:
Delete '#' and use '0x' prefix instead
Signed-off-by: Yutao Ai
---
monitor/misc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/monitor/misc.c b/monitor/misc.c
index 7588f12053..2eb563f6f3 100644
--- a/monitor/misc.c
+++ b/monitor/misc.c
@@ -910,7 +910,7 @@ static void
Move the open brace '{' following struct go on the same line
Signed-off-by: Yutao Ai
---
monitor/hmp-cmds.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/monitor/hmp-cmds.c b/monitor/hmp-cmds.c
index 8d7f5fee7e..64188c9fa2 100644
--- a/monitor/hmp-cmds.c
+++
Fix the errors by add {}
Signed-off-by: Yutao Ai
---
monitor/misc.c | 14 +-
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/monitor/misc.c b/monitor/misc.c
index 398211a034..7588f12053 100644
--- a/monitor/misc.c
+++ b/monitor/misc.c
@@ -492,8 +492,10 @@ static void
I find some style problems while using checkpatch.pl to check monitor codes.
And I fixed these style problems in the submit patches.
Yutao Ai (3):
monitor:open brace '{' following struct go on the same line
monitor:braces {} are necessary for all arms of this statement
monitor:Don't use '#'
The 'elem' is allocated memory in vu_queue_pop(), and its memory should be
freed in all error branches after vu_queue_pop().
In addition, in order to free the 'elem' memory outside of while(1) loop, move
the definition of 'elem' to the beginning of vus_proc_req().
Reported-by: Euler Robot
Sorry, I forgot to add the Reviewed-by information, I will send patch v3.
On 2020/11/25 9:25, Alex Chen wrote:
> The 'elem' is allocated memory in vu_queue_pop(), and its memory should be
> freed in all error branches after vu_queue_pop().
> In addition, in order to free the 'elem' memory outside
The 'elem' is allocated memory in vu_queue_pop(), and its memory should be
freed in all error branches after vu_queue_pop().
In addition, in order to free the 'elem' memory outside of while(1) loop, move
the definition of 'elem' to the beginning of vus_proc_req().
Reported-by: Euler Robot
On 2020/11/24 23:37, Raphael Norwitz wrote:
> On Tue, Nov 24, 2020 at 9:50 AM Alex Chen wrote:
>>
>> The 'elem' is allocated memory in vu_queue_pop(), and it's memory should be
>> freed in all error branchs after vu_queue_pop().
>
> s/branchs/branches
>
>> In addition, in order to free 'elem'
On 2020/11/24 23:29, Peter Maydell wrote:
> On Tue, 24 Nov 2020 at 12:15, Alex Chen wrote:
>>
>> Hi everyone，
>>
>> Who can help me merge this patch into the master branch? This patch may be
>> need for qemu-5.2
>
> This code has been like this since 2018, so this is not
> a regression in 5.2.
Reviewed-by: Huacai Chen
On Tue, Nov 24, 2020 at 6:42 PM Philippe Mathieu-Daudé wrote:
>
> Huacai, ping?
>
> On 5/12/20 9:09 AM, Philippe Mathieu-Daudé wrote:
> > +Paolo
> >
> > On 4/29/20 10:29 AM, Philippe Mathieu-Daudé wrote:
> >> This code must not be used outside of KVM. Abort if it is.
>
On 20.11.20 16:58, Joelle van Dyne wrote:
On Fri, Nov 20, 2020 at 3:08 AM Alexander Graf wrote:
On 09.11.20 00:24, Joelle van Dyne wrote:
When entitlements are available (macOS or jailbroken iOS), a hardware
feature called APRR exists on newer Apple Silicon that can cheaply mark JIT
pages
We don't implement SCTLR.A, but you're right that we should be
checking the mandatory alignments.
Note! Any fix will only apply to system mode (qemu-system-arm)
and not user-only mode (qemu-arm).
** Changed in: qemu
Status: New => Confirmed
--
You received this bug notification because
Hello,
On behalf of the QEMU Team, I'd like to announce the availability of the
fourth release candidate for the QEMU 5.2 release. This release is meant
for testing purposes and should not be used in a production environment.
http://download.qemu-project.org/qemu-5.2.0-rc3.tar.xz
On 20-11-17 12:29:40, Jonathan Cameron wrote:
[snip]
> > >
> > > > +
> > > > +/* 8.2.5.10 - CXL Security Capability Structure */
> > > > +#define CXL_SEC_REGISTERS_OFFSET (CXL_RAS_REGISTERS_OFFSET +
> > > > CXL_RAS_REGISTERS_SIZE)
> > > > +#define CXL_SEC_REGISTERS_SIZE 0 /* We don't
On 11/24/20 13:25, Igor Mammedov wrote:
> If firmware negotiates ICH9_LPC_SMI_F_CPU_HOT_UNPLUG_BIT feature,
> OSPM on CPU eject will set bit #4 in CPU hotplug block for to be
> ejected CPU to mark it for removal by firmware and trigger SMI
> upcall to let firmware do actual eject.
>
>
On Tue, 24 Nov 2020 at 15:16, Eduardo Habkost wrote:
>
> The following changes since commit d536d9578ec3ac5029a70b8126cb84bb6f2124a4:
>
> Merge remote-tracking branch 'remotes/jasowang/tags/net-pull-request' into
> staging (2020-11-24 10:59:12 +)
>
> are available in the Git repository at:
On Tue, 24 Nov 2020 at 14:12, Philippe Mathieu-Daudé wrote:
> As we are going to tag 5.2-rc3, what is the status of this fix?
'git blame' says none of the code changed here is newer than 2018,
so it seems unlikely that this is a regression since 5.1. rc3 is
now ready to tag, so this is going to
On Tue, Nov 24, 2020 at 09:13:13PM +0100, Paolo Bonzini wrote:
> On 24/11/20 17:22, Claudio Fontana wrote:
> > +static void x86_cpu_accel_init(void)
> > {
> > -X86CPUAccelClass *acc;
> > +const char *ac_name;
> > +ObjectClass *ac;
> > +char *xac_name;
> > +ObjectClass *xac;
>
Since meson.git#0240d760c7699a059cc89e584363c6431cdd2b61 setuptools is not
required anymore.
Signed-off-by: Olaf Hering
---
configure | 3 ---
1 file changed, 3 deletions(-)
diff --git a/configure b/configure
index 8c5d2f9a69..ce9b3c0a33 100755
--- a/configure
+++ b/configure
@@ -1913,9
On Tue, 24 Nov 2020 at 14:25, Kevin Wolf wrote:
>
> The following changes since commit 23895cbd82be95428e90168b12e925d0d3ca2f06:
>
> Merge remote-tracking branch 'remotes/awilliam/tags/vfio-update-20201123.0'
> into staging (2020-11-23 18:51:13 +)
>
> are available in the Git repository
On Tue, Nov 24, 2020 at 08:39:33PM +0100, Claudio Fontana wrote:
> On 11/24/20 8:27 PM, Eduardo Habkost wrote:
> > On Tue, Nov 24, 2020 at 07:52:15PM +0100, Claudio Fontana wrote:
> > [...]
> +}
> >>>
> >>> Additionally, if you call arch_cpu_accel_init() here, you won't
> >>> need
On 24/11/20 17:21, Claudio Fontana wrote:
In this version I basically QOMified X86CPUAccel, taking the
suggestions from Eduardo as the starting point,
but stopping just short of making it an actual QOM interface,
using a plain abstract class, and then subclasses for the
actual objects.
On 24/11/20 17:22, Claudio Fontana wrote:
+static void x86_cpu_accel_init(void)
{
-X86CPUAccelClass *acc;
+const char *ac_name;
+ObjectClass *ac;
+char *xac_name;
+ObjectClass *xac;
-acc = X86_CPU_ACCEL_CLASS(object_class_by_name(accel_name));
-g_assert(acc !=
Cc'ing qemu-arm list too.
On 11/24/20 5:52 PM, Michael Peter wrote:
> Pass an additional argument to zynq_slcr_compute_clocks that indicates
> whether an reset-exit condition
> applies. If called from zynq_slcr_reset_exit, external clocks are
> assumed to be active, even if the
> device state
On 24/11/20 20:08, Eduardo Habkost wrote:
Not a big advantage I agree,
I think however there is one, in using the existing framework that exists, for
the purposes that it was built for.
As I understand it, the global module init framework is supposed to mark the
major initialization steps,
On 24/11/20 18:54, Richard Henderson wrote:
+test-i386-bmi2: CFLAGS += -mbmi2
+run-test-i386-bmi2: QEMU_OPTS += -cpu max
+run-plugin-test-i386-bmi2-%: QEMU_OPTS += -cpu max
I suspect that we still support host operating systems whose compilers do not
support -mbmi2. This might require a bit in
On 11/24/20 8:27 PM, Eduardo Habkost wrote:
> On Tue, Nov 24, 2020 at 07:52:15PM +0100, Claudio Fontana wrote:
> [...]
+}
>>>
>>> Additionally, if you call arch_cpu_accel_init() here, you won't
>>> need MODULE_INIT_ACCEL_CPU anymore. The
>>>
>>> module_call_init(MODULE_INIT_ACCEL_CPU)
On Tue, 2020-11-24 at 20:59 +0200, Maxim Levitsky wrote:
> On Tue, 2020-11-24 at 19:59 +0100, Alberto Garcia wrote:
> > On Tue 24 Nov 2020 10:17:23 AM CET, Kevin Wolf wrote:
> > > We can then continue work to find a minimal reproducer and merge the
> > > test case in the early 6.0 cycle.
> >
> >
On Tue, Nov 24, 2020 at 07:52:15PM +0100, Claudio Fontana wrote:
[...]
> >> +}
> >
> > Additionally, if you call arch_cpu_accel_init() here, you won't
> > need MODULE_INIT_ACCEL_CPU anymore. The
> >
> > module_call_init(MODULE_INIT_ACCEL_CPU)
> >
> > call with implicit dependencies on
On 24.11.20 19:11, Jonathan Cameron wrote:
> On Mon, 9 Nov 2020 20:47:09 +0100
> David Hildenbrand wrote:
>
> +CC Eric based on similar query in other branch of the thread.
>
>> On 05.11.20 18:43, Jonathan Cameron wrote:
>>> Basically a cut and paste job from the x86 support with the exception
On Tue, Nov 24, 2020 at 07:29:50PM +0100, Claudio Fontana wrote:
> On 11/24/20 6:08 PM, Eduardo Habkost wrote:
> > On Tue, Nov 24, 2020 at 05:22:07PM +0100, Claudio Fontana wrote:
> >> apply this to the registration of the cpus accel interfaces,
> >>
> >> but this will be also in preparation for
On Tue, 2020-11-24 at 19:59 +0100, Alberto Garcia wrote:
> On Tue 24 Nov 2020 10:17:23 AM CET, Kevin Wolf wrote:
> > We can then continue work to find a minimal reproducer and merge the
> > test case in the early 6.0 cycle.
>
> I haven't been able to reproduce the problem yet, do you have any
>
On Tue 24 Nov 2020 10:17:23 AM CET, Kevin Wolf wrote:
> We can then continue work to find a minimal reproducer and merge the
> test case in the early 6.0 cycle.
I haven't been able to reproduce the problem yet, do you have any
findings?
Berto
On 11/24/20 6:48 PM, Eduardo Habkost wrote:
> On Tue, Nov 24, 2020 at 05:22:10PM +0100, Claudio Fontana wrote:
>> Signed-off-by: Claudio Fontana
>> ---
>> accel/kvm/kvm-all.c | 9 ---
>> accel/kvm/kvm-cpus.c | 26 +-
>> accel/kvm/kvm-cpus.h | 2 --
Pass an additional argument to zynq_slcr_compute_clocks that indicates whether
an reset-exit condition
applies. If called from zynq_slcr_reset_exit, external clocks are assumed to be
active, even if the
device state indicates a reset state.
Signed-off-by: Michael Peter
---
hw/misc/zynq_slcr.c
Hi Peter,
> (a) what does "fails to load" mean here? In the sample binary
> I had, we got a SIGSEGV in zero_bss() when it tried to memset()
> memory that hadn't been mmap()ed. Is that the only failure mode,
> or can this manifest in other ways too?
Apologies for the unclear commit msg. I was
On 11/24/20 5:59 PM, Eduardo Habkost wrote:
> On Tue, Nov 24, 2020 at 05:22:09PM +0100, Claudio Fontana wrote:
>> Signed-off-by: Claudio Fontana
>
> Probably this can be squashed into patch 10/12.
Yes, you are right, no point building things fragmented and then merging
together later.
>
>>
On 11/24/20 6:08 PM, Eduardo Habkost wrote:
> On Tue, Nov 24, 2020 at 05:22:07PM +0100, Claudio Fontana wrote:
>> apply this to the registration of the cpus accel interfaces,
>>
>> but this will be also in preparation for later use of this
>> new module init step to also register per-accel x86 cpu
Hi Eduardo,
thanks for looking at this,
On 11/24/20 6:56 PM, Eduardo Habkost wrote:
> On Tue, Nov 24, 2020 at 05:22:06PM +0100, Claudio Fontana wrote:
>> Signed-off-by: Claudio Fontana
>> ---
> [...]
>> @@ -908,8 +909,12 @@ int main(int argc, char **argv)
>> }
>>
>> /* init tcg
On Mon, 9 Nov 2020 20:47:09 +0100
David Hildenbrand wrote:
+CC Eric based on similar query in other branch of the thread.
> On 05.11.20 18:43, Jonathan Cameron wrote:
> > Basically a cut and paste job from the x86 support with the exception of
> > needing a larger block size as the Memory Block
On Tue, Nov 24, 2020 at 05:22:06PM +0100, Claudio Fontana wrote:
> Signed-off-by: Claudio Fontana
> ---
[...]
> @@ -908,8 +909,12 @@ int main(int argc, char **argv)
> }
>
> /* init tcg before creating CPUs and to get qemu_host_page_size */
> -tcg_exec_init(0);
> +{
> +
* Andrey Gruzdev (andrey.gruz...@virtuozzo.com) wrote:
> Implemented support for the whole RAM block memory
> protection/un-protection. Introduced higher level
> ram_write_tracking_start() and ram_write_tracking_stop()
> to start/stop tracking guest memory writes.
>
> Signed-off-by: Andrey
On 11/24/20 6:01 PM, Greg Kurz wrote:
> On Tue, 24 Nov 2020 14:54:38 +0100
> Cédric Le Goater wrote:
>
>> On 11/23/20 12:16 PM, Greg Kurz wrote:
>>> On Mon, 23 Nov 2020 10:46:38 +0100
>>> Cédric Le Goater wrote:
>>>
On 11/20/20 6:46 PM, Greg Kurz wrote:
> We're going to kill the
On 11/23/20 5:14 AM, Paolo Bonzini wrote:
> For PDEP and PEXT, the mask is provided in the memory (mod+r/m)
> operand, and therefore is loaded in s->T0 by gen_ldst_modrm.
> The source is provided in the second source operand (VEX.)
> and therefore is loaded in s->T1. Fix the order in which
>
On Tue, Nov 24, 2020 at 05:22:10PM +0100, Claudio Fontana wrote:
> Signed-off-by: Claudio Fontana
> ---
> accel/kvm/kvm-all.c | 9 ---
> accel/kvm/kvm-cpus.c | 26 +-
> accel/kvm/kvm-cpus.h | 2 --
> accel/qtest/qtest.c | 31
On 11/24/20 9:28 AM, Richard Henderson wrote:
>> +tcg_gen_extract_i64(t0, cpu_gpr[a->rt], 0, 16);
>> +tcg_gen_deposit_i64(cpu_gpr[a->rd], cpu_gpr[a->rd], t0, 0, 16);
>> +tcg_gen_deposit_i64(cpu_gpr[a->rd], cpu_gpr[a->rd], t0, 16, 16);
>> +
On 24.11.2020 18:17, Peter Xu wrote:
On Tue, Nov 24, 2020 at 11:02:09AM +0300, Andrey Gruzdev wrote:
On 24.11.2020 00:34, Peter Xu wrote:
On Fri, Nov 20, 2020 at 07:53:34PM +0300, Andrey Gruzdev wrote:
On 20.11.2020 19:43, Peter Xu wrote:
On Fri, Nov 20, 2020 at 07:15:07PM +0300, Andrey
On Tue, 24 Nov 2020 at 12:08, Greg Kurz wrote:
>
> The following changes since commit 683685e72dccaf8cb9fe8ffa20f5c5aacea72118:
>
> Merge remote-tracking branch
> 'remotes/stefanha-gitlab/tags/block-pull-request' into staging (2020-11-23
> 13:03:13 +)
>
> are available in the Git
On Wed, 18 Nov 2020 at 16:55, Stephen Long wrote:
>
> qemu-user fails to load ELFs with only BSS and no data section
>
> Signed-off-by: Ben Hutchings
> Signed-off-by: Stephen Long
> ---
>
> Submitting this on behalf of Ben Hutchings. Feel free to edit the commit
> msg.
>
> linux-user/elfload.c
On 11/18/20 8:52 AM, Stephen Long wrote:
> qemu-user fails to load ELFs with only BSS and no data section
>
> Signed-off-by: Ben Hutchings
> Signed-off-by: Stephen Long
> ---
Reviewed-by: Richard Henderson
r~
On Tue, 24 Nov 2020 at 17:18, Richard Henderson
wrote:
>
> On 11/23/20 11:52 AM, Peter Maydell wrote:
> > Somebody reported this on stackoverflow. Before I spend too
> > much time thinking about how this ought to work, does anybody
> > have the elfload.c intended operation in their head still?
>
Public bug reported:
affects qemu
OSS-Fuzz Report: https://bugs.chromium.org/p/oss-
fuzz/issues/detail?id=27796
=== Reproducer (build with --enable-sanitizers) ===
cat << EOF | ./qemu-system-i386 -display none -machine accel=qtest, \
-m 512M -machine q35 -nodefaults \
-drive
* Stefan Hajnoczi (stefa...@redhat.com) wrote:
> On Wed, Nov 11, 2020 at 04:18:34PM +, Thanos Makatos wrote:
> >
> > > VFIO Migration
> > > ==
> > > This document describes how to ensure migration compatibility for VFIO
> > > devices,
> > > including mdev and vfio-user devices.
>
On 11/24/20 2:38 AM, Philippe Mathieu-Daudé wrote:
> Simplify (and optimize) the Parallel Copy Halfword
> instruction using deposit() / extract() helpers.
>
> Ref: C790-Specific Instruction Set, Appendix B-63.
>
> Signed-off-by: Philippe Mathieu-Daudé
> ---
> target/mips/translate.c | 35
* Alex Williamson (alex.william...@redhat.com) wrote:
> On Mon, 16 Nov 2020 14:52:26 +0100
> Cornelia Huck wrote:
>
> > On Mon, 16 Nov 2020 11:02:51 +
> > Stefan Hajnoczi wrote:
> >
> > > On Wed, Nov 11, 2020 at 04:35:43PM +0100, Cornelia Huck wrote:
> > > > On Wed, 11 Nov 2020 15:14:49
On 24.11.2020 19:55, Dr. David Alan Gilbert wrote:
* Peter Xu (pet...@redhat.com) wrote:
On Thu, Nov 19, 2020 at 01:51:50PM -0500, Peter Xu wrote:
On Thu, Nov 19, 2020 at 03:59:34PM +0300, Andrey Gruzdev via wrote:
Signed-off-by: Andrey Gruzdev
---
migration/migration.c | 96
Paolo sent a patch here:
https://lists.gnu.org/archive/html/qemu-devel/2020-11/msg05700.html
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1605123
Title:
PEXT returns wrong values, seemingly
On 11/23/20 11:52 AM, Peter Maydell wrote:
> Somebody reported this on stackoverflow. Before I spend too
> much time thinking about how this ought to work, does anybody
> have the elfload.c intended operation in their head still?
> Bug description and analysis of what goes wrong below:
>
>
On Mon, 23 Nov 2020 11:13:21 +0100
Cédric Le Goater wrote:
> On 11/20/20 6:46 PM, Greg Kurz wrote:
> > The sPAPR XIVE device exposes a range of LISNs that the guest uses
> > for IPIs. This range is currently sized according to the highest
> > vCPU id, ie. spapr_max_server_number(), as obtained
In the meantime, target/m68k has implemented these trig
functions for its (only slightly different) 96-bit
extended-float format.
With a minor amount of work this code could be shared.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
Hi Phil,
thanks for your advise and patience.
I created a new patch (this time with a sign-off) and sent it to qemu-
de...@nongnu.org.
Since I have to use a corporate email system, I hope that the formatting
is not gone.
Best regards,
Michael
--
You received this bug notification because
On Tue, Nov 24, 2020 at 05:22:07PM +0100, Claudio Fontana wrote:
> apply this to the registration of the cpus accel interfaces,
>
> but this will be also in preparation for later use of this
> new module init step to also register per-accel x86 cpu type
> interfaces.
>
> Signed-off-by: Claudio
* Peter Xu (pet...@redhat.com) wrote:
> On Thu, Nov 19, 2020 at 01:51:50PM -0500, Peter Xu wrote:
> > On Thu, Nov 19, 2020 at 03:59:34PM +0300, Andrey Gruzdev via wrote:
> > > Signed-off-by: Andrey Gruzdev
> > > ---
> > > migration/migration.c | 96 +++
> >
On Tue, 24 Nov 2020 14:54:38 +0100
Cédric Le Goater wrote:
> On 11/23/20 12:16 PM, Greg Kurz wrote:
> > On Mon, 23 Nov 2020 10:46:38 +0100
> > Cédric Le Goater wrote:
> >
> >> On 11/20/20 6:46 PM, Greg Kurz wrote:
> >>> We're going to kill the "nr_ends" field in a subsequent patch.
> >>
> >>
*** This bug is a duplicate of bug 1900779 ***
https://bugs.launchpad.net/bugs/1900779
Looking at your patch and the fix in commit 437588d81d99ac91cb1e, the
modifications are the same, so this issue should be fixed, indeed. Big
sorry that your bug report here fell through the cracks, but at
On Tue, Nov 24, 2020 at 05:22:09PM +0100, Claudio Fontana wrote:
> Signed-off-by: Claudio Fontana
Probably this can be squashed into patch 10/12.
> ---
> target/i386/cpu-qom.h | 2 --
> target/i386/cpu.c | 27 ---
> target/i386/hvf/cpu.c | 9 -
>
Is this still reproducible with the latest version of QEMU, or could
this ticket be closed nowadays?
** Changed in: qemu
Status: New => Incomplete
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
The QEMU project is currently considering to move its bug tracking to another
system. For this we need to know which bugs are still valid and which could be
closed already. Thus we are setting older bugs to "Incomplete" now.
If you still think this bug report here is valid, then please switch
The QEMU project is currently considering to move its bug tracking to another
system. For this we need to know which bugs are still valid and which could be
closed already. Thus we are setting older bugs to "Incomplete" now.
If you still think this bug report here is valid, then please switch
Has this ever been sent?
** Changed in: qemu
Status: New => 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/1777235
Title:
NVME is missing support for Get Log Page command
Status
* Andrey Gruzdev (andrey.gruz...@virtuozzo.com) wrote:
> Changes with v3:
> * coding style fixes to pass checkpatch test
> * qapi/migration.json: change 'track-writes-ram' capability
> * supported version to 6.0
> * fixes to commit message format
>
cc'ing in COLO people,
*** This bug is a duplicate of bug 1900779 ***
https://bugs.launchpad.net/bugs/1900779
I think this is likely a duplicate of bug
https://bugs.launchpad.net/qemu/+bug/1900779 which has recently been
fixed. Could you please check with the latest release candidate of QEMU
5.2 whether the issue
Did you ever send your patch to the mailing list for discussion?
** Changed in: qemu
Status: New => 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/186
Title:
virtio-gpu-3d.c:
Looking through old bug tickets ... Did you ever send your patch to the
qemu-devel mailing list? See
https://wiki.qemu.org/Contribute/SubmitAPatch for more information
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
1 - 100 of 239 matches
Mail list logo
