On 2/14/20 3:28 AM, Peter Maydell wrote:
>> +static inline bool isar_feature_aa32_pan(const ARMISARegisters *id)
>> +{
>> +return FIELD_EX64(id->mvfr0, ID_MMFR3, PAN) != 0;
>> +}
>> +
>> +static inline bool isar_feature_aa32_ats1e1(const ARMISARegisters *id)
>> +{
>> +return FIELD_EX64(id->
Have the calls adjacent as an intermediate step toward
actually merging the decodes.
Signed-off-by: Richard Henderson
---
target/arm/translate.c | 80 +-
1 file changed, 24 insertions(+), 56 deletions(-)
diff --git a/target/arm/translate.c b/target/arm/tr
On 14.02.20 19:11, Peter Xu wrote:
> On Fri, Feb 14, 2020 at 06:32:35PM +0100, David Hildenbrand wrote:
>> On 14.02.20 18:29, Peter Xu wrote:
>>> On Fri, Feb 14, 2020 at 01:02:46PM +0100, David Hildenbrand wrote:
From c0049ac2e95d6756037db918852c507fb88297d9 Mon Sep 17 00:00:00 2001
From:
Passing the raw op field from the manual is less instructive
than it might be. Do the full decode and use the existing
helpers to perform the expansion.
Since these are v8 insns, VECLEN+VECSTRIDE are already RES0.
Signed-off-by: Richard Henderson
---
target/arm/vfp-uncond.decode | 12 ++--
On 2/14/20 3:52 PM, Oksana Vohchana wrote:
Improves EXEC migration to run whole test stage
Signed-off-by: Oksana Vohchana
Fixes: 2e768cb682bf
---
tests/acceptance/migration.py | 2 ++
1 file changed, 2 insertions(+)
diff --git a/tests/acceptance/migration.py b/tests/acceptance/migration
I found it just by launching Ubuntu 19.10 live cd with QXL driver. I
will re-test this weekend.
The workaround I had is to check the number of TLB flushes and to re-try
obtaining the TB if the number changes. There is a penalty for the case
where TLB is flushed but should not degrade performance i
On 2/14/20 7:15 PM, Richard Henderson wrote:
These registers are 32-bits wide. Cut and paste used FIELD_EX64
instead of the more proper FIELD_EX32. In practice all this did
was use an unnecessary 64-bit operation, producing correct results.
Signed-off-by: Richard Henderson
---
target/arm/cp
Apologies, the patch got messed up.
diff --git a/accel/tcg/cpu-exec.c b/accel/tcg/cpu-exec.c
index c01f59c743..7a9e8c94bd 100644
--- a/accel/tcg/cpu-exec.c
+++ b/accel/tcg/cpu-exec.c
@@ -238,8 +238,11 @@ void cpu_exec_step_atomic(CPUState *cpu)
uint32_t flags;
uint32_t cflags = 1;
u
On Fri, 14 Feb 2020 at 18:15, Richard Henderson
wrote:
>
> These registers are 32-bits wide. Cut and paste used FIELD_EX64
> instead of the more proper FIELD_EX32. In practice all this did
> was use an unnecessary 64-bit operation, producing correct results.
>
> Signed-off-by: Richard Henderson
On Thu, 13 Feb 2020 at 13:21, Juan Quintela wrote:
>
> The following changes since commit e18e5501d8ac692d32657a3e1ef545b14e72b730:
>
> Merge remote-tracking branch
> 'remotes/dgilbert-gitlab/tags/pull-virtiofs-20200210' into staging
> (2020-02-10 18:09:14 +)
>
> are available in the Git r
As we plan to introduce a sysbus TPM_TIS, let's rename
TPM_TIS into TPM_TIS_ISA.
Signed-off-by: Eric Auger
---
hw/i386/acpi-build.c | 6 +++---
hw/tpm/tpm_tis.c | 4 ++--
include/sysemu/tpm.h | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/hw/i386/acpi-build.c b/hw
This series adds the capability to instantiate an MMIO TPM TIS
in ARM virt.
The existing TPM TIS code is reshuffled into a generic part,
the ISA device and the sysbus device. The last patch allows
the instantiation of the TPM TIS sysbus device in ARM virt.
The series was tested with the swtpm/lib
Introduce the tpm-tis-device which is a sysbus device
and is bound to be used on ARM.
Signed-off-by: Eric Auger
---
hw/tpm/Kconfig | 5 ++
hw/tpm/Makefile.objs| 1 +
hw/tpm/tpm_tis_sysbus.c | 159
include/sysemu/tpm.h| 1 +
4 files
As we plan to introdce a SysBus TPM TIS device, let's
make the TPMState a common struct usable by both the
ISADevice and the SysBusDevice. TPMStateISA embeds the
struct and inherits from the ISADevice.
The prototype of functions bound to be used by both
the ISA and SysBus devices is changed to tak
Move the device agnostic code into tpm_tis_common.c and
put the ISA device specific code into tpm_tis_isa.c
Signed-off-by: Eric Auger
---
hw/tpm/Makefile.objs | 2 +-
hw/tpm/tpm_tis.h | 91 +++
hw/tpm/{tpm_tis.c => tpm_tis_common.c} | 209 ++
Let the TPM TIS SYSBUS device be dynamically instantiable
in ARM virt. A device tree node is dynamically created
(TPM via MMIO).
The TPM Physical Presence interface (PPI) is not supported.
To run with the swtmp TPM emulator, the qemu command line must
be augmented with:
-chardev socket,
Let's separate the compilation of tpm_tis_common.c from
the compilation of tpm_tis_isa.c
The common part will be also compiled along with the
tpm_tis_sysbus device.
Signed-off-by: Eric Auger
---
default-configs/i386-softmmu.mak | 2 +-
hw/i386/Kconfig | 2 +-
hw/tpm/Kconfig
On 2/14/20 7:15 PM, Richard Henderson wrote:
The old name, isar_feature_aa32_fp_d32, does not reflect
the MVFR0 field name, SIMDReg.
Signed-off-by: Richard Henderson
---
target/arm/cpu.h | 2 +-
target/arm/translate-vfp.inc.c | 52 +-
2 files c
* Markus Armbruster (arm...@redhat.com) wrote:
> Juan Quintela writes:
>
> > Markus Armbruster wrote:
> >> "Dr. David Alan Gilbert" writes:
> >>
> >>> * Juan Quintela (quint...@redhat.com) wrote:
> Signed-off-by: Juan Quintela
> ---
> migration/migration.c | 15 +++
On 2/14/20 7:15 PM, Richard Henderson wrote:
The old name, isar_feature_aa32_fpdp, does not reflect
that the test includes VFPv2. We will introduce another
feature tests for VFPv3.
Signed-off-by: Richard Henderson
---
target/arm/cpu.h | 4 ++--
target/arm/translate-vfp.inc.c
On 2/14/20 7:36 PM, Eric Auger wrote:
As we plan to introduce a sysbus TPM_TIS, let's rename
TPM_TIS into TPM_TIS_ISA.
Signed-off-by: Eric Auger
---
hw/i386/acpi-build.c | 6 +++---
hw/tpm/tpm_tis.c | 4 ++--
include/sysemu/tpm.h | 6 +++---
3 files changed, 8 insertions(+), 8 deletion
On 2/14/20 7:37 PM, Eric Auger wrote:
As we plan to introdce a SysBus TPM TIS device, let's
typo "introduce"
make the TPMState a common struct usable by both the
ISADevice and the SysBusDevice. TPMStateISA embeds the
struct and inherits from the ISADevice.
The prototype of functions bound to
On 2/14/20 7:37 PM, Eric Auger wrote:
Let's separate the compilation of tpm_tis_common.c from
the compilation of tpm_tis_isa.c
The common part will be also compiled along with the
tpm_tis_sysbus device.
Signed-off-by: Eric Auger
---
default-configs/i386-softmmu.mak | 2 +-
hw/i386/Kconfig
On Thu, 13 Feb 2020 at 18:00, Alex Bennée wrote:
>
> Pointer authentication isn't perfect so measure the percentage of
> failed checks. As we want to vary the pointer that is authenticated we
> recurse down the stack.
>
> Signed-off-by: Alex Bennée
Reviewed-by: Robert Foley
On 14/02/2020 11:47, Philippe Mathieu-Daudé wrote:
> Hi Mark,
>
> On Fri, Feb 14, 2020 at 9:48 AM Mark Cave-Ayland
> wrote:
>>
>> Remove the call to pci_cmd646_ide_init() since global device init functions
>> are deprecated in preference of using qdev directly.
>>
>> Signed-off-by: Mark Cave-Ayl
On Thu, 13 Feb 2020 at 18:00, Alex Bennée wrote:
>
> The plugin system would throw up a harmless warning when it detected
> that a disassembly of an instruction didn't use all it's bytes. Fix
> the riscv decoder to only load the instruction bytes it needs as it
> needs them.
>
> This drops opcode
On Thu, 13 Feb 2020 at 17:51, Alex Bennée wrote:
>
> If we have plugins enabled we still need to have built the test to be
> able to run it.
>
> Signed-off-by: Alex Bennée
Reviewed-by: Robert Foley
The launchpad bug only mentions EXT, but I found three more
via inspection. I really should extend RISU so that we can
do AdvSIMD testing with SVE enabled...
r~
Richard Henderson (4):
target/arm: Flush high bits of sve register after AdvSIMD EXT
target/arm: Flush high bits of sve register
Writes to AdvSIMD registers flush the bits above 128.
Signed-off-by: Richard Henderson
---
target/arm/translate-a64.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/target/arm/translate-a64.c b/target/arm/translate-a64.c
index 620a429067..096a854aed 100644
--- a/target/arm/translate-a64.c
+
Writes to AdvSIMD registers flush the bits above 128.
Buglink: https://bugs.launchpad.net/bugs/1863247
Signed-off-by: Richard Henderson
---
target/arm/translate-a64.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/target/arm/translate-a64.c b/target/arm/translate-a64.c
index 7c26c3bfeb..620
On Fri, Feb 14, 2020 at 07:26:59PM +0100, David Hildenbrand wrote:
> +if (!postcopy_is_running()) {
> +Error *err = NULL;
> +
> +/*
> + * Precopy code cannot deal with the size of ram blocks
> changing at
> + * random points in
Writes to AdvSIMD registers flush the bits above 128.
Signed-off-by: Richard Henderson
---
target/arm/translate-a64.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/target/arm/translate-a64.c b/target/arm/translate-a64.c
index 096a854aed..b83d09dbcd 100644
--- a/target/arm/translate-a64.c
+
Writes to AdvSIMD registers flush the bits above 128.
Signed-off-by: Richard Henderson
---
target/arm/translate-a64.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/target/arm/translate-a64.c b/target/arm/translate-a64.c
index b83d09dbcd..bd68588a71 100644
--- a/target/arm/translate-a
> Am 14.02.2020 um 20:45 schrieb Peter Xu :
>
> On Fri, Feb 14, 2020 at 07:26:59PM +0100, David Hildenbrand wrote:
>> +if (!postcopy_is_running()) {
>> +Error *err = NULL;
>> +
>> +/*
>> + * Precopy code cannot deal with the size of ram blocks
>>
All other block jobs already provide a QMP option to control the error
handling policy. It's time to add it to commit, too.
Peter, I guess libvirt wants to expose this?
Nir, as you would probably assume, this is motivated by the recent
finding that VDSM has to preallocate the theoretical maximum
It is not obvious what 'ignore' actually means for block jobs: It could
be continuing the job and returning success in the end despite the error
(no block job does this). It could also mean continuing and returning
failure in the end (this is what stream does). And it can mean retrying
the failed r
block_job_error_action() needs to know if reading from the top node or
writing to the base node failed so that it can set the right 'operation'
in the BLOCK_JOB_ERROR QMP event.
Signed-off-by: Kevin Wolf
---
block/commit.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a
commit_populate() is a very short function and only called in a single
place. Its return value doesn't tell us whether an error happened while
reading or writing, which would be necessary for sending the right data
in the BLOCK_JOB_ERROR QMP event.
Signed-off-by: Kevin Wolf
---
block/commit.c |
This tests both read failure (from the top node) and write failure (to
the base node) for on-error=report/stop/ignore.
As block-commit actually starts two different types of block jobs
(mirror.c for committing the active later, commit.c for intermediate
layers), all tests are run for both cases.
The bytes_written variable is only ever written to, it serves no
purpose. This has actually been the case since the commit job was first
introduced in commit 747ff602636.
Signed-off-by: Kevin Wolf
---
block/commit.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/block/commit.c b/block/comm
On 2/14/20 9:50 AM, Peter Maydell wrote:
> In take_aarch32_exception(), we know we are dealing with a CPU that
> has AArch32, so the right isar_feature test is aa32_pan, not aa64_pan.
>
> Signed-off-by: Peter Maydell
> ---
> target/arm/helper.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletio
The block_job_error_action() error call in the commit job gives the
on_err and is_read arguments in the wrong order. Fix this.
(Of course, hard-coded is_read = false is wrong, too, but that's a
separate problem for a separate patch.)
Signed-off-by: Kevin Wolf
---
block/commit.c | 2 +-
1 file c
Patchew URL:
https://patchew.org/QEMU/20200214181547.21408-1-richard.hender...@linaro.org/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Subject: [PATCH 00/19] target/arm: vfp feature and decodetree cleanup
Message-id: 20200214181547.21408-1-
Now that the error handling in the common block job is fixed, we can
expose the on-error option in QMP instead of hard-coding it as 'report'
in qmp_block_commit().
This fulfills the promise that the old comment in that function made,
even if a bit later than expected: "This will be part of the QMP
On 2/14/20 9:51 AM, Peter Maydell wrote:
> The AArch32 DBGDIDR defines properties like the number of
> breakpoints, watchpoints and context-matching comparators. On an
> AArch64 CPU, the register may not even exist if AArch32 is not
> supported at EL1.
>
> Currently we hard-code use of DBGDIDR to
On 2/14/20 9:51 AM, Peter Maydell wrote:
> We're going to want to read the DBGDIDR register from KVM in
> a subsequent commit, which means it needs to be in the
> ARMISARegisters sub-struct. Move it.
>
> Signed-off-by: Peter Maydell
> ---
> target/arm/cpu.h | 2 +-
> target/arm/internals.h
On 2/14/20 9:51 AM, Peter Maydell wrote:
> +/*
> + * DBGDIDR is a bit complicated because the kernel doesn't
> + * provide an accessor for it in 64-bit mode, which is what this
> + * scratch VM is in, and there's no architected "64-bit sysreg
> + * which read
On 2/14/20 9:51 AM, Peter Maydell wrote:
> The isar_feature_aa32_pan and isar_feature_aa32_ats1e1 functions
> are supposed to be testing fields in ID_MMFR3; but a cut-and-paste
> error meant we were looking at MVFR0 instead.
>
> Fix the functions to look at the right register; this requires
> us t
On 2/14/20 9:51 AM, Peter Maydell wrote:
> Now we have moved ID_MMFR4 into the ARMISARegisters struct, we
> can define and use an isar_feature for the presence of the
> ARMv8.2-AA32HPD feature, rather than open-coding the test.
>
> While we're here, correct a comment typo which missed an 'A'
> fro
On 2/14/20 9:51 AM, Peter Maydell wrote:
> Cut-and-paste errors mean we're using FIELD_EX64() to extract fields from
> some 32-bit ID register fields. Use FIELD_EX32() instead. (This makes
> no difference in behaviour, it's just more consistent.)
>
> Signed-off-by: Peter Maydell
> ---
> target/a
On Fri, Feb 14, 2020 at 03:04:23PM -0500, David Hildenbrand wrote:
>
>
> > Am 14.02.2020 um 20:45 schrieb Peter Xu :
> >
> > On Fri, Feb 14, 2020 at 07:26:59PM +0100, David Hildenbrand wrote:
> >> +if (!postcopy_is_running()) {
> >> +Error *err = NULL;
> >> +
> >> +
On 2/14/20 9:51 AM, Peter Maydell wrote:
> diff --git a/target/arm/cpu.c b/target/arm/cpu.c
> index c46bb5a5c09..9f618e120aa 100644
> --- a/target/arm/cpu.c
> +++ b/target/arm/cpu.c
> @@ -2718,6 +2718,7 @@ static void arm_max_initfn(Object *obj)
>
> t = cpu->isar.id_mmfr4;
>
On Thu, Feb 13, 2020 at 11:24 PM Anup Patel wrote:
>
> Currently, the upstream Spike ISA simulator allows more than
> one CPUs so we update QEMU Spike machine on similar lines to
> allow more than one CPUs.
>
> The maximum number of CPUs for QEMU Spike machine is kept
> same as QEMU Virt machine.
On 02/14/20 19:12, Philippe Mathieu-Daudé wrote:
> On 2/14/20 5:37 PM, Jerry Geis wrote:
>> I dont know how to get all files listing on windows. But, I cd
>> \program files\qemu
>> dir *.fd
>> edk2-x86_64-code.fd
>> edk2-x86_64-secure-code.fd
>>
>> It seems like from other posts these might be the
Hello QEMU developers,
I have noticed a bug in the `mcast` option of the `socket` networking
backend, where I simply cannot join a multicast group (tested in Windows 10
with QEMU 4.2.0 release). I have found a fix to the problem. The problem
was mainly due to the fact that QEMU was binding to the
I recently investigated a bug in which the dump-guest-memory.py script
sees a gdb.MemoryError exception while attempting to dump memory
obtained from a QEMU core dump. (And, yes, dump-guest-core=on was
specified in the -machine option of the QEMU invocation.)
It turns out that memory region in qu
On 2/14/20 6:49 AM, Alex Bennée wrote:
> The bug describes a race whereby cpu_exec_step_atomic can acquire a TB
> which is invalidated by a tb_flush before we execute it. This doesn't
> affect the other cpu_exec modes as a tb_flush by it's nature can only
> occur on a quiescent system. The race was
Patchew URL: https://patchew.org/QEMU/20200214232650.35381-1-kev...@redhat.com/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Subject: [PATCH] Handle gdb.MemoryError exception in dump-guest-memory.py
Message-id: 20200214232650.35381-1-kev...@r
Perhaps this is due to this issue https://github.com/intel/gvt-
linux/issues/71
https://yadi.sk/i/Ejg_6JJEBIc-Zw
** Bug watch added: github.com/intel/gvt-linux/issues #71
https://github.com/intel/gvt-linux/issues/71
--
You received this bug notification because you are a member of qemu-
deve
What race are you thinking of in my patch? The obvious race I can
think of is benign:
Case 1:
A: does TB flush
B: read tb_flush_count
A: increment tb_flush_count
A: end_exclusive
B: tb_lookup__cpu_state/tb_gen_code
B: start_exclusive
B: read tb_flush_count again (increment seen)
B: retries
Case 2
We'll use this property in a follow-up patch to insantiate an EHCI
bus with companion support.
Signed-off-by: Guenter Roeck
---
v2: Added patch
hw/usb/hcd-ehci-sysbus.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/hw/usb/hcd-ehci-sysbus.c b/hw/usb/hcd-ehci-sysbus.c
index b5a014f968..01
Instantiate EHCI and OHCI controllers on Allwinner A10.
The first patch in the series moves the declaration of EHCISysBusState
from hcd-ohci.c to hcd-ohci.h. This lets us add the structure to
AwA10State. Similar, TYPE_SYSBUS_OHCI is moved to be able to use it
outside its driver.
The second patch
We need to be able to use OHCISysBusState outside hcd-ohci.c, so move it
to its include file.
Signed-off-by: Guenter Roeck
---
v2: no changes
hw/usb/hcd-ohci.c | 15 ---
hw/usb/hcd-ohci.h | 16
2 files changed, 16 insertions(+), 15 deletions(-)
diff --git a/hw/usb/
Instantiate EHCI and OHCI controllers on Allwinner A10. OHCI ports are
modeled as companions of the respective EHCI ports.
With this patch applied, USB controllers are discovered and instantiated
when booting the cubieboard machine with a recent Linux kernel.
ehci-platform 1c14000.usb: EHCI Host
[Included a "Signed-off-by" line in this version.]
I recently investigated a bug in which the dump-guest-memory.py script
sees a gdb.MemoryError exception while attempting to dump memory
obtained from a QEMU core dump. (And, yes, dump-guest-core=on was
specified in the -machine option of the QEMU
On 2/14/2020 11:48 PM, Greg Kurz wrote:
> On Fri, 14 Feb 2020 11:32:06 +0800
> wrote:
>
>> From: Pan Nengyuan
>>
>> 'fdt' forgot to clean both e500 and pnv when we call 'system_reset' on ppc,
>> this patch fix it. The leak stacks are as follow:
>>
>> Direct leak of 4194304 byte(s) in 4 object
Hi Dave,
Yes, I agree with you, it does need a timeout.
Hi Hailiang,
We base on qemu-4.1.0 for using COLO feature, in your patch, we found a lot
of difference between your version and ours.
Could you give us a latest release version which is close your developing
code?
Thanks.
Regards
Daniel
From: Chen Qun
We may forget to free fload. ASAN spotted it.
Reported-by: Euler Robot
Signed-off-by: Chen Qun
---
tests/test-vmstate.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/tests/test-vmstate.c b/tests/test-vmstate.c
index cea363dd69..5b2743121b 100644
--- a/tests/test-vmstate.c
On Fri, Feb 14, 2020 at 12:57:34AM +0100, BALATON Zoltan wrote:
> "Deferred" was misspelled as "differed" in some comments, correct this
> typo,
>
> Signed-off-by: BALATON Zoltan
I've replaced the earlier version in my tree.
> ---
> v2: Found one more where even the typo was misspelled
>
> tar
> From: David Gibson < da...@gibson.dropbear.id.au >
> Sent: Friday, February 14, 2020 1:36 PM
> To: Liu, Yi L
> Subject: Re: [RFC v3 03/25] hw/iommu: introduce IOMMUContext
>
> On Wed, Feb 12, 2020 at 07:15:13AM +, Liu, Yi L wrote:
> > Hi Peter,
> >
> > > From: Peter Xu
> > > Sent: Wednesda
201 - 270 of 270 matches
Mail list logo
