spapr global irq numbers are different from the source numbers on the ICS
when using XICS - they're offset by XICS_IRQ_BASE (0x1000). But
spapr_irq_set_irq_xics() was passing through the global irq number to
the ICS code unmodified.
We only got away with this because of a counteracting bug - we
The irq claim and free paths for both XICS and XIVE check for some
validity conditions. Some of these represent genuine runtime failures,
however others - particularly checking that the basic irq number is in a
sane range - could only fail in the case of bugs in the callin code.
Therefore use
spapr_irq_free() can be used to free multiple irqs at once. That's useful
for its callers, but there's no need to make the individual backend hooks
handle this. We can loop across the irqs in spapr_irq_free() itself and
have the hooks just do one at time.
Signed-off-by: David Gibson
TYPE_ICS_SIMPLE is the only subtype of TYPE_ICS_BASE that's ever
instantiated. The existence of different classes is mostly a hang
over from when we (misguidedly) had separate subtypes for the KVM and
non-KVM version of the device.
There could be some call for an abstract base type for ICS
Currently TYPE_XICS_BASE and TYPE_XICS_SIMPLE have their own reset methods,
using the standard technique for having the subtype call the supertype's
methods before doing its own thing.
But TYPE_XICS_SIMPLE is the only subtype of TYPE_XICS_BASE ever
instantiated, so there's no point having the
This is a substantial rework to clean up the handling of IRQs in
spapr. It includes some cleanups to both the XICS and XIVE interrupt
controller backends, as well as more to the common spapr irq handling
infrastructure.
Changes since v1:
* Lots of extra patches
* Many minor adjustments based
These traces contain some useless information (the always-0 source#) and
have no equivalents for XIVE mode. For now just remove them, and we can
put back something more sensible if and when we need it.
Signed-off-by: David Gibson
Reviewed-by: Cédric Le Goater
Reviewed-by: Greg Kurz
No point having a two-line helper that's used exactly once, and not likely
to be used anywhere else in future.
Signed-off-by: David Gibson
Reviewed-by: Cédric Le Goater
Reviewed-by: Greg Kurz
Reviewed-by: Philippe Mathieu-Daudé
---
hw/ppc/spapr_pci.c | 3 ++-
Currently ics_reject(), ics_resend() and ics_eoi() indirect through
class methods. But there's only one implementation of each method,
the one in TYPE_ICS_SIMPLE. TYPE_ICS_BASE has no implementation, but
it's never instantiated, and has no other subtypes.
So clean up by eliminating the method
Interface instances should never be directly dereferenced. So, the common
practice is to make them incomplete types to make sure no-one does that.
XICSFrabric, however, had a dummy type which is less safe.
We were also using OBJECT_CHECK() where we should have been using
INTERFACE_CHECK().
Currently spapr_qirq(), whic is used to find the qemu_irq for an spapr
global irq number, redirects through the SpaprIrq::qirq method. But
the array of qemu_irqs is allocated in the PAPR layer, not the
backends, and so the method implementations all return the same thing,
just differing in the
There are a number of ics_simple_*() functions that aren't actually
specific to TYPE_XICS_SIMPLE at all, and are equally valid on
TYPE_XICS_BASE. Rename them to ics_*() accordingly.
Signed-off-by: David Gibson
Reviewed-by: Cédric Le Goater
Reviewed-by: Greg Kurz
---
hw/intc/trace-events |
From: "Zhang, Qi"
When dt is supported, TM field should not be Reserved(0).
Refer to VT-d Spec 9.8
Signed-off-by: Zhang, Qi
Signed-off-by: Qi, Yadong
---
hw/i386/intel_iommu.c | 12 ++--
hw/i386/intel_iommu_internal.h | 25 +++--
2 files changed, 25
25.09.2019. 17.53, "Philippe Mathieu-Daudé" је
написао/ла:
>
> On 9/25/19 2:45 PM, Aleksandar Markovic wrote:
> > From: Aleksandar Markovic
> >
> > Mostly fix errors and warnings reported by 'checkpatch.pl -f'.
> >
> > Signed-off-by: Aleksandar Markovic
> > ---
> > target/mips/helper.c | 132
On Fri, Sep 27, 2019 at 8:55 AM Alistair Francis
wrote:
typo "privledge" in the commit title
>
> Signed-off-by: Alistair Francis
> ---
> target/riscv/translate.c | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/target/riscv/translate.c b/target/riscv/translate.c
> index
On Thu, Sep 26, 2019 at 10:36:02AM +0200, Greg Kurz wrote:
> On Wed, 25 Sep 2019 16:45:31 +1000
> David Gibson wrote:
>
> > spapr_irq_claim() and the hooks it is based on return an integer error code
> > as well as taking an Error ** parameter. But none of the callers check the
> > integer, so
QEMU does not allocate PCI resources (BARs) in any case - coldplug devices
are configured by the firmware and hotplug devices rely on the guest
system to do the assignment via the PCI rescan mechanism. Also in order
to create non empty "assigned-addresses", the device has to be enabled
(i.e.
Public bug reported:
I am trying to access the CDROM (iso) from QEMU using FreeDOS and I get
an error when doing a directory for:
i can boot from the iso but if i exit to access the files from the CDROM
ISO i get the attached error.
I believe there is an issue with the QEMU for the Raspberry
Patchew URL:
https://patchew.org/QEMU/919bbd6e0557d2fe2d9c17de394cc0b4c6fa4426.1569445204.git.tgole...@redhat.com/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Type: series
Message-id:
On 9/26/19 8:17 AM, Lakshmi Ramasubramanian wrote:
The following commit for ARM Trusted Firmware for QEMU virt ARMv8-A
is almost 3 years old
https://salsa.debian.org/debian/atf-allwinner/commit/b6b671c4ac4bd5595306863225bb3bece1e6135c
Current limitations:
* Only cold boot is supported
* No
Add the CFI01 PFlash to the RISC-V virt board. This is the same PFlash
from the ARM Virt board and the implementation is based on the ARM Virt
board. This allows users to specify flash files from the command line.
Signed-off-by: Alistair Francis
---
hw/riscv/Kconfig| 1 +
If the user supplied pflash to QEMU then change the reset code to jump
to the pflash base address instead of the DRAM base address.
Signed-off-by: Alistair Francis
Reviewed-by: Bin Meng
Reviewed-by: Philippe Mathieu-Daudé
---
hw/riscv/virt.c | 11 ++-
1 file changed, 10 insertions(+),
Add a property that when set to true QEMU will jump from the ROM code to
the start of flash memory instead of DRAM which is the default
behaviour.
Signed-off-by: Alistair Francis
---
hw/riscv/sifive_u.c | 27 +++
include/hw/riscv/sifive_u.h | 2 ++
2 files
Signed-off-by: Alistair Francis
---
target/riscv/translate.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/target/riscv/translate.c b/target/riscv/translate.c
index adeddb85f6..537af0003e 100644
--- a/target/riscv/translate.c
+++ b/target/riscv/translate.c
@@ -810,7 +810,14 @@
On reset only a single L2 cache way is enabled, the others are exposed
as memory that can be used by early boot firmware. This L2 region is
generally disabled using the WayEnable register at a later stage in the
boot process. To allow firmware to target QEMU and the HiFive Unleashed
let's add the
The HiFive Unleashed uses is25wp256 SPI NOR flash. There is currently no
model of this in QEMU, so to allow boot firmware developers to use QEMU
to target the Unleashed let's add a chunk of memory to represent the QSPI0
memory mapped flash. This can be targeted using QEMU's -device loader
command
Instead of using the DEFINE_MACHINE() macro to define the machine let's
do it manually. This allows us to specify machine properties.
This patch is no functional change.
Signed-off-by: Alistair Francis
---
hw/riscv/sifive_u.c | 44 ++---
This series aims to improve the use of QEMU for developing boot code. It
does a few things:
- sifive_u machine:
- Adds a chunk of memory in the Flash area. This allows boot loaders
to use this memory. I can't find details on the QSPI flash used on
the real board, so this is the best
Instead of using the DEFINE_MACHINE() macro to define the machine let's
do it manually. This allows us to use the machine object to create
RISCVVirtState. This is required to add children and aliases to the
machine.
This patch is no functional change.
Signed-off-by: Alistair Francis
---
(CCing libvir-list)
On Thu, Sep 26, 2019 at 11:58:30PM +0200, Paolo Bonzini wrote:
> Is this really needed? QEMU's value of pconfig=on vs. off should be
> provided by QMP CPU model queries, if a property is not available then
> Libvirt should not try to set it to off.
>
Libvirt can easily work
On Thu, Sep 26, 2019 at 07:57:54PM +0100, Mark Cave-Ayland wrote:
> This patchset fixes the DFP issue reported at
> https://bugs.launchpad.net/qemu/+bug/1841990
> caused by the change in FP register storage in commit ef96e3ae96 "target/ppc:
> move FP and VMX registers into aligned vsr register
Richard Henderson writes:
> On 9/24/19 4:31 AM, Andrew Jones wrote:
>
>> +#if __SIZEOF_LONG__ == 8
>> +#define BIT(n) (1UL << (n))
>> +#else
>> +#define BIT(n) (1ULL << (n))
>> +#endif
>
> There's no reason not to always use 1ULL is there?
Also we already have this helper in bitops.h so
On 8/7/19 10:12 AM, Vladimir Sementsov-Ogievskiy wrote:
> Hi all!
>
> Bitmaps reopening is buggy, reopening-rw just not working at all and
> reopening-ro may lead to producing broken incremental
> backup if we do temporary snapshot in a meantime.
>
> v4: Drop complicated solution around
On 8/7/19 10:12 AM, Vladimir Sementsov-Ogievskiy wrote:
> The only reason I can imagine for this strange code at the very-end of
> bdrv_reopen_commit is the fact that bs->read_only updated after
> calling drv->bdrv_reopen_commit in bdrv_reopen_commit. And in the same
> time, prior to previous
On 8/7/19 10:12 AM, Vladimir Sementsov-Ogievskiy wrote:
> - Correct check for write access to file child, and in correct place
> (only if we want to write).
> - Support reopen rw -> rw (which will be used in following commit),
> for example, !bdrv_dirty_bitmap_readonly() is not a corruption
On 9/24/19 6:12 AM, Max Reitz wrote:
> On 07.08.19 16:12, Vladimir Sementsov-Ogievskiy wrote:
>> It's needed to fix reopening qcow2 with bitmaps to RW. Currently it
>> can't work, as qcow2 needs write access to file child, to mark bitmaps
>> in-image with IN_USE flag. But usually children goes
On 8/7/19 10:12 AM, Vladimir Sementsov-Ogievskiy wrote:
> Two testcases with persistent bitmaps are not added here, as there are
> bugs to be fixed soon.
>
> Signed-off-by: Vladimir Sementsov-Ogievskiy
OK:
Reviewed-by: John Snow
there may or may not be conflicts on test setup, depending
On 8/7/19 10:12 AM, Vladimir Sementsov-Ogievskiy wrote:
> Signed-off-by: Vladimir Sementsov-Ogievskiy
> ---
> tests/qemu-iotests/iotests.py | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/tests/qemu-iotests/iotests.py b/tests/qemu-iotests/iotests.py
> index
On 8/7/19 10:12 AM, Vladimir Sementsov-Ogievskiy wrote:
> Reopening bitmaps to RW was broken prior to previous commit. Check that
> it works now.
>
> Signed-off-by: Vladimir Sementsov-Ogievskiy
> ---
> tests/qemu-iotests/165 | 46 --
>
Is this really needed? QEMU's value of pconfig=on vs. off should be
provided by QMP CPU model queries, if a property is not available then
Libvirt should not try to set it to off.
Paolo
Il gio 26 set 2019, 23:23 Eduardo Habkost ha scritto:
> QEMU 3.1.0 was shipped with the "pconfig" CPU
On 9/26/19 3:28 PM, Eric Blake wrote:
> On 9/26/19 1:54 PM, John Snow wrote:
>>
>>
>> On 9/16/19 10:19 AM, Vladimir Sementsov-Ogievskiy wrote:
>>> bdrv_dirty_bitmap_next is always used in same pattern. So, split it
>>> into _next and _first, instead of combining two functions into one and
>>>
On Thu, 26 Sep 2019 03:07:08 +
"Tian, Kevin" wrote:
> > From: Alex Williamson [mailto:alex.william...@redhat.com]
> > Sent: Thursday, September 26, 2019 3:06 AM
> [...]
> > > > > The second point is about write-protection:
> > > > >
> > > > > > There is another value of recording GPA in
On Thu, Sep 26, 2019 at 06:23:26PM -0300, Eduardo Habkost wrote:
> QEMU 3.1.0 was shipped with the "pconfig" CPU property available,
> added by commit 5131dc433df5 ("i386: Add CPUID bit for PCONFIG").
>
> Then the feature was removed in QEMU 4.0.0 (and 3.1.1), by commit
> 712f807e1965 ("Revert
QEMU 3.1.0 was shipped with the "pconfig" CPU property available,
added by commit 5131dc433df5 ("i386: Add CPUID bit for PCONFIG").
Then the feature was removed in QEMU 4.0.0 (and 3.1.1), by commit
712f807e1965 ("Revert 'i386: Add CPUID bit for PCONFIG'").
In theory this would be OK, but we do
This allows us to remove more endian-specific defines from int_helper.c.
Signed-off-by: Mark Cave-Ayland
---
target/ppc/int_helper.c | 72 ++---
1 file changed, 25 insertions(+), 47 deletions(-)
diff --git a/target/ppc/int_helper.c b/target/ppc/int_helper.c
On Thu, 26 Sep 2019, Philippe Mathieu-Daudé wrote:
and got it almost working (boots Linux kernel to userland, sadly
I'm still having timeout issues with the eMMC block).
[...]
$ make aarch64-softmmu/all check-venv
$ ./tests/venv/bin/avocado --show=app,console run -t machine:raspi2 -t
On Thu, Sep 26, 2019 at 10:10:53AM +0800, Tao Xu wrote:
> Add some comments, clean up comments over 80 chars per line. There
> is an extra line in comment of CPUID_8000_0008_EBX_WBNOINVD, remove
> the extra enter and spaces.
>
> Drop the duplicated definition of cpuid AVX512_VBMI macro and rename
On 9/26/19 1:54 PM, John Snow wrote:
On 9/16/19 10:19 AM, Vladimir Sementsov-Ogievskiy wrote:
bdrv_dirty_bitmap_next is always used in same pattern. So, split it
into _next and _first, instead of combining two functions into one and
add FOR_EACH_DIRTY_BITMAP macro.
Signed-off-by: Vladimir
On 9/20/19 4:25 AM, Vladimir Sementsov-Ogievskiy wrote:
> Hi all!
>
> We need to lock qcow2 mutex on accessing in-image metadata, especially
> on updating this metadata. Let's implement it.
>
> v3:
> 01: add John's r-b
> 02: - fix bdrv_remove_persistent_dirty_bitmap return value
> - drop
On 9/26/19 9:09 PM, Philippe Mathieu-Daudé wrote:
> On 9/26/19 8:26 PM, John Snow wrote:
>> On 9/26/19 5:57 AM, Philippe Mathieu-Daudé wrote:
>>> Hi Sam,
>>>
>>> On 9/25/19 1:06 PM, Sam Eiderman wrote:
From: Sam Eiderman
Using fw_cfg, supply logical CHS values directly from QEMU to
Alistair Francis writes:
> On Thu, Sep 26, 2019 at 8:41 AM Alex Bennée wrote:
>>
>>
>> Thomas Huth writes:
>>
>> > On 26/09/2019 15.46, Christian Borntraeger wrote:
>> >>
>> >>
>> >> On 26.09.19 14:58, Daniel P. Berrangé wrote:
>> >>> On Thu, Sep 26, 2019 at 08:50:36AM +0100, Peter Maydell
On 9/24/19 4:31 AM, Andrew Jones wrote:
> +static uint32_t sve_zcr_get_valid_len(ARMCPU *cpu, uint32_t start_len)
> +{
> +uint32_t start_vq = (start_len & 0xf) + 1;
> +
> +return arm_cpu_vq_map_next_smaller(cpu, start_vq + 1) - 1;
> +}
> +
> /*
> * Given that SVE is enabled, return the
There are several places in dfp_helper.c that access the decimal number
representations in struct PPC_DFP via HI_IDX and LO_IDX defines which are set
at the top of dfp_helper.c according to the host endian.
However we can instead switch to using ppc_vsr_t for decimal numbers and then
make
Since commit ef96e3ae96 "target/ppc: move FP and VMX registers into aligned vsr
register array" FP registers are no longer stored consecutively in memory and so
the current method of combining FP register pairs into DFP numbers is incorrect.
Firstly update the definition of the dh_*_fprp defines
Now that the parameters to both set_dfp64() and set_dfp128() are exactly the
same, there is no need for an explicit if() statement to determine which
function should be called based upon size. Instead we can simply use the
preprocessor to generate the call to set_dfp##size() directly.
On 9/26/19 8:26 PM, John Snow wrote:
> On 9/26/19 5:57 AM, Philippe Mathieu-Daudé wrote:
>> Hi Sam,
>>
>> On 9/25/19 1:06 PM, Sam Eiderman wrote:
>>> From: Sam Eiderman
>>>
>>> Using fw_cfg, supply logical CHS values directly from QEMU to the BIOS.
>>>
>>> Non-standard logical geometries break
From: Philippe Mathieu-Daudé
The WHPX build is broken since commit 12e9493df92 which removed the
"hw/boards.h" where MachineState is declared:
$ ./configure \
--enable-hax --enable-whpx
$ make x86_64-softmmu/all
[...]
CC x86_64-softmmu/target/i386/whpx-all.o
Most of the DFP helper functions call decimal{64,128}FromNumber() just before
returning in order to convert the decNumber stored in dfp.t64 back to a
Decimal{64,128} to write back to the FP registers.
Introduce new dfp_finalize_decimal{64,128}() helper functions which both enable
the parameter
On 9/20/19 4:25 AM, Vladimir Sementsov-Ogievskiy wrote:
> It's more comfortable to not deal with local_err.
>
> Signed-off-by: Vladimir Sementsov-Ogievskiy
Reviewed-by: John Snow
On 9/16/19 10:19 AM, Vladimir Sementsov-Ogievskiy wrote:
> bdrv_dirty_bitmap_next is always used in same pattern. So, split it
> into _next and _first, instead of combining two functions into one and
> add FOR_EACH_DIRTY_BITMAP macro.
>
> Signed-off-by: Vladimir Sementsov-Ogievskiy
> ---
>
This adds two new tests that re-use the memory test to check basic
record replay functionality is still working. We have to define our
own runners rather than using the default pattern as we want to change
the test name but re-use the memory binary.
We declare the test binaries as PHONY as they
On 9/20/19 4:25 AM, Vladimir Sementsov-Ogievskiy wrote:
> Hi all!
>
> We need to lock qcow2 mutex on accessing in-image metadata, especially
> on updating this metadata. Let's implement it.
>
> v3:
> 01: add John's r-b
> 02: - fix bdrv_remove_persistent_dirty_bitmap return value
> - drop
The existing functions (now incorrectly) assume that the MSB and LSB of DFP
numbers are stored as consecutive 64-bit words in memory. Instead of accessing
the DFP numbers directly, introduce get_dfp{64,128}() helper functions to ease
the switch to the correct representation.
Signed-off-by: Mark
On 9/16/19 10:19 AM, Vladimir Sementsov-Ogievskiy wrote:
> mutex field is just a pointer to bs->dirty_bitmap_mutex, so no needs
> to store it in BdrvDirtyBitmap when we have bs pointer in it (since
> previous patch).
>
> Drop mutex field. Constantly use bdrv_dirty_bitmaps_lock/unlock in
>
Switch over all accesses to the decimal numbers held in struct PPC_DFP from
using HI_IDX and LO_IDX to using the VsrD() macro instead. Not only does this
allow the compiler to ensure that the various dfp_* functions are being passed
a ppc_vsr_t rather than an arbitrary uint64_t pointer, but also
From: John Snow
debian-ports is listed as a partial image, so we cannot run tests against it.
Since it isn't used by any other testable image, remove it for now as it
is prone to bitrot.
Signed-off-by: John Snow
Message-Id: <20190923181140.7235-5-js...@redhat.com>
Signed-off-by: Alex Bennée
The existing functions (now incorrectly) assume that the MSB and LSB of DFP
numbers are stored as consecutive 64-bit words in memory. Instead of accessing
the DFP numbers directly, introduce set_dfp{64,128}() helper functions to ease
the switch to the correct representation.
Signed-off-by: Mark
There was in the clean-up code caused by attempting to inspect images
which finished before we got there. Clean up the clean up code by:
- only track the one instance at a time
- use --filter for docker ps instead of doing it by hand
- just call docker rm -f to be done with it
- use
Despite our attempts in 4d26c7fef4 to keep this going it still gets in
the way of "make docker-test-build" completing because of course we
can't build a modern QEMU with the image. Let's put the thing out of
its misery and remove it.
People who really care about building on powerpc can still use
Now we have fixed the signal delivary bug we can remove this horrible
hack from the system.
Cc: Richard Henderson
Signed-off-by: Alex Bennée
Reviewed-by: Richard Henderson
Reviewed-by: Philippe Mathieu-Daudé
Tested-by: Philippe Mathieu-Daudé
diff --git a/tests/tcg/multiarch/Makefile.target
This patchset fixes the DFP issue reported at
https://bugs.launchpad.net/qemu/+bug/1841990
caused by the change in FP register storage in commit ef96e3ae96 "target/ppc:
move FP and VMX registers into aligned vsr register array" along with some
further tidy-up/improvements.
Patches 1 and 2
From: John Snow
We don't have a debian8-mxe dockerfile anymore.
Fixes: 67bd36beda1ae
Signed-off-by: John Snow
Reviewed-by: Philippe Mathieu-Daudé
Message-Id: <20190923181140.7235-2-js...@redhat.com>
Signed-off-by: Alex Bennée
diff --git a/tests/docker/Makefile.include
From: John Snow
As part of the push to drop python2 support, replace any explicit python2
dependencies with python3 versions.
For centos, python2 still exists as an implicit dependency, but by adding
python3 we will be able to build even if the configure script begins to
require python 3.5+.
These were missed in the recent de-tangling so have been updated to be
more actuate. I've also built up ARM_TESTS in a manner similar to
AARCH64_TESTS for better consistency.
Signed-off-by: Alex Bennée
Reviewed-by: Peter Maydell
Reviewed-by: Philippe Mathieu-Daudé
Tested-by: Philippe
This is broadly similar to the existing fcvt test for ARM but using
the generic float testing framework. We should be able to pare down
the ARM fcvt test case to purely half-precision with or without the
Alt HP provision.
Signed-off-by: Alex Bennée
Reviewed-by: Richard Henderson
Tested-by:
The slirp sub-module complains about not being able to find the glib
library on cross-compiles because it is using the default pkg-config
tool (which isn't installed in our cross-build docker images).
Preserve PKG_CONFIG in our host config and pass it down to slirp.
Signed-off-by: Alex Bennée
We were incorrectly using the 64-bit AIX ABI instead of the 32-bit
SYSV ABI for setting NIP for the signal handler.
Signed-off-by: Alex Bennée
Reviewed-by: Richard Henderson
Reviewed-by: Laurent Vivier
diff --git a/linux-user/ppc/signal.c b/linux-user/ppc/signal.c
index 619a56950d..5b82af6cb6
It was pointed out we haven't documented the check-tcg part of the
build system. Attempt to rectify that now.
Signed-off-by: Alex Bennée
Reviewed-by: Richard Henderson
diff --git a/docs/devel/testing.rst b/docs/devel/testing.rst
index bf75675fb0..8e981e062d 100644
--- a/docs/devel/testing.rst
From: John Snow
There isn't a debian.dockerfile anymore,
so perform some ghost-busting.
Signed-off-by: John Snow
Message-Id: <20190923181140.7235-4-js...@redhat.com>
Signed-off-by: Alex Bennée
Reviewed-by: Philippe Mathieu-Daudé
Acked-by: Philippe Mathieu-Daudé
diff --git
From: Richard Henderson
The kernel masks the integer overflow exception with the
software invalid exception mask. Include IOV in the set
of exception bits masked by fpcr_exc_enable.
Fixes the new float_convs test.
Signed-off-by: Richard Henderson
Signed-off-by: Alex Bennée
Message-Id:
From: John Snow
debian-sid is listed as a partial image, so we cannot run tests against it.
Since it isn't used by any other testable image, remove it for now as it
is prone to bitrot.
Signed-off-by: John Snow
Message-Id: <20190923181140.7235-6-js...@redhat.com>
Signed-off-by: Alex Bennée
From: John Snow
debian8 partial base is also not consumed by any image, so remove it.
For QEMU's development cycle, we only support debian9 (stretch) and
debian10 (buster).
Signed-off-by: John Snow
Reviewed-by: Philippe Mathieu-Daudé
Message-Id: <20190923181140.7235-3-js...@redhat.com>
From: John Snow
When it was based on debian8 which uses python-minimal, it needed this.
It no longer does.
Goodbye, python2.7.
Signed-off-by: John Snow
Message-Id: <20190918222546.11696-1-js...@redhat.com>
[AJB: fixed up commit message]
Signed-off-by: Alex Bennée
Reviewed-by: Philippe
From: Richard Henderson
Since we're converting the swcr to fpcr format for exceptions,
it's trivial to add FPCR_DNZ to the set of fpcr bits overriden.
No functional change.
Signed-off-by: Richard Henderson
Signed-off-by: Alex Bennée
Message-Id:
From: John Snow
Oops; there's no argv here.
Signed-off-by: John Snow
Message-Id: <20190913193821.17756-1-js...@redhat.com>
Signed-off-by: Alex Bennée
Reviewed-by: Cleber Rosa
Tested-by: Cleber Rosa
Reviewed-by: Thomas Huth
Tested-by: Thomas Huth
diff --git a/tests/docker/docker.py
Finger trouble in a previous clean-up inadvertently set
DEBIAN_PARTIAL_IMAGES instead of DOCKER_PARTIAL_IMAGES. Also fix the
typo to debian-9-mxe.
Fixes: 44d5a8bf5d2
Signed-off-by: John Snow
[AJB: merged fix from Message-Id: <20190917185537.25417-1-js...@redhat.com>]
Signed-off-by: Alex Bennée
From: Richard Henderson
Remove a redundant masking of ignore. Once that's gone it is
obvious that the system-mode inner test is redundant with the
outer test. Move the fpcr_exc_enable masking up and tidy.
No functional change.
Signed-off-by: Richard Henderson
Signed-off-by: Alex Bennée
The following changes since commit eb13d1cf4a0478fc29f80abfbac8209479325f35:
Merge remote-tracking branch 'remotes/dgilbert/tags/pull-migration-20190925a'
into staging (2019-09-26 14:23:58 +0100)
are available in the Git repository at:
https://github.com/stsquad/qemu.git
From: Richard Henderson
Tidy the computation of the value; no functional change.
Signed-off-by: Richard Henderson
Signed-off-by: Alex Bennée
Message-Id: <20190921043256.4575-6-richard.hender...@linaro.org>
diff --git a/target/alpha/helper.c b/target/alpha/helper.c
index
From: John Snow
Fedora23 is but a distant twinkle. The sanitizer works again, and even
if not, we have --enable-sanitizers now.
Signed-off-by: John Snow
Message-Id: <20190912014442.5757-1-js...@redhat.com>
Signed-off-by: Alex Bennée
diff --git a/tests/docker/test-clang
From: Richard Henderson
The CONFIG_USER_ONLY adjustment blindly mashed the swcr
exception enable bits into the fpcr exception disable bits.
However, fpcr_exc_enable has already converted the exception
disable bits into the exception status bits in order to make
it easier to mask status bits at
From: Richard Henderson
This is a bit more straight-forward than using a switch statement.
No functional change.
Signed-off-by: Richard Henderson
Signed-off-by: Alex Bennée
Reviewed-by: Philippe Mathieu-Daudé
Message-Id: <20190921043256.4575-2-richard.hender...@linaro.org>
diff --git
From: Richard Henderson
We were setting the wrong bit. The fp_status.flush_to_zero
setting is overwritten by either the constant 1 or the value
of fpcr_flush_to_zero depending on bits within an fp insn.
Signed-off-by: Richard Henderson
Signed-off-by: Alex Bennée
Message-Id:
On 9/26/19 5:57 AM, Philippe Mathieu-Daudé wrote:
> Hi Sam,
>
> On 9/25/19 1:06 PM, Sam Eiderman wrote:
>> From: Sam Eiderman
>>
>> Using fw_cfg, supply logical CHS values directly from QEMU to the BIOS.
>>
>> Non-standard logical geometries break under QEMU.
>>
>> A virtual disk which
Reverted 4e6d0920e7547e6af4bbac5ffe9adfe6ea621822, and those 'vsl/vsr'
tests now succeed.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1841990
Title:
instruction 'denbcdq' misbehaving
Status in
On 9/26/19 6:00 AM, Philippe Mathieu-Daudé wrote:
> On 9/25/19 1:06 PM, Sam Eiderman wrote:
>> From: Sam Eiderman
>>
>> Add QTest tests to check the logical geometry override option.
>>
>> The tests in hd-geo-test are out of date - they only test IDE and do not
>> test interesting MBRs.
>>
>>
Add a test which loads the root filesystem on a SD card.
Use a kernel recent enough to also test the thermal sensor.
The kernel image comes from:
https://github.com/sakaki-/bcmrpi3-kernel#description
The cpio image used comes from the linux-build-test project:
As part of the investigation into the DFP number issue reported at
https://bugs.launchpad.net/qemu/+bug/1841990 it appears that there may also be
a bug
introduced by the new optimised vsl/vsr implementation:
commit 4e6d0920e7547e6af4bbac5ffe9adfe6ea621822
Author: Stefan Brankovic
Date: Mon Jul
On 9/26/19 12:08 PM, Philippe Mathieu-Daudé wrote:
> On 9/26/19 6:04 PM, Alex Bennée wrote:
>>
>> Philippe Mathieu-Daudé writes:
>>
>>> Hi Alex,
>>>
>>> On 9/26/19 1:34 AM, Alex Bennée wrote:
Philippe Mathieu-Daudé writes:
> On 9/24/19 11:01 PM, Alex Bennée wrote:
>> From: John
Add a test which boots Linux and run basic commands using the serial
port console.
The kernel image is built by the Debian project:
https://wiki.debian.org/RaspberryPi
The DeviceTree blob comes from the official Raspberry Pi project:
https://www.raspberrypi.org/
The cpio image used comes from
1 - 100 of 349 matches
Mail list logo
