On Fri, Apr 26, 2019 at 10:30:35AM +0530, Pankaj Gupta wrote:
> This patch adds virtio-pmem driver for KVM guest.
>
> Guest reads the persistent memory range information from
> Qemu over VIRTIO and registers it on nvdimm_bus. It also
> creates a nd_region object with the persistent memory
> range
On 4/29/19 2:33 AM, driver1998 wrote:
> Windows ARM64 uses LLP64 model, which breaks current assumptions.
>
> Signed-off-by: driver1998
> ---
> util/cacheinfo.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/util/cacheinfo.c b/util/cacheinfo.c
> index
Hi,
On 4/29/19 2:33 AM, driver1998 wrote:
> Signed-off-by: driver1998
Is driver1998 your real name? :)
> ---
> include/qemu/osdep.h | 10 +-
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/include/qemu/osdep.h b/include/qemu/osdep.h
> index 303d315c5d..af2b91f0b8
On 29.04.19 21:24, David Hildenbrand wrote:
> On 29.04.19 11:02, Christian Borntraeger wrote:
>> Provide the MSA9 facility (stfle.155).
>> This also contains pckmo functions for key wrapping. Keep them in a
>> separate group to disable those as a block if necessary.
>>
>> Signed-off-by:
On 2019/4/30 13:06, Philippe Mathieu-Daudé wrote:
> On 4/30/19 4:02 AM, Longpeng (Mike) wrote:
>> On 2019/4/29 20:10, Philippe Mathieu-Daudé wrote:
>>> On 4/29/19 1:42 PM, Longpeng (Mike) wrote:
Hi Philippe,
On 2019/4/29 19:16, Philippe Mathieu-Daudé wrote:
> Hi Mike,
On 4/30/19 4:02 AM, Longpeng (Mike) wrote:
> On 2019/4/29 20:10, Philippe Mathieu-Daudé wrote:
>> On 4/29/19 1:42 PM, Longpeng (Mike) wrote:
>>> Hi Philippe,
>>>
>>> On 2019/4/29 19:16, Philippe Mathieu-Daudé wrote:
>>>
Hi Mike,
On 4/29/19 9:39 AM, Longpeng(Mike) wrote:
> From:
All systems have an RTC.
The IRQ is hooked up but the model does not use it at this stage. There
is no guest code that uses it, so this limitation is acceptable.
Signed-off-by: Joel Stanley
---
v3: Add commit message
v2: Rebase on Cedric's patches (20190411161013.4514-4-...@kaod.org)
---
The RTC is modeled to provide time and date functionality. It is
initialised at zero to match the hardware.
There is no modelling of the alarm functionality, which includes the IRQ
line. As there is no guest code to exercise this function that is
acceptable for now.
Signed-off-by: Joel Stanley
v3: Add some commit messages, resend as v2 didn't send properly
v2: Minor fixes, added vmstate and reset, and rebased on Cédric's series
Based-on: 20190411161013.4514-4-...@kaod.org
[PATCH 3/3] aspeed: use sysbus_init_child_obj() to initialize children
A model for the ASPEED BMC real time clock
RAMBlock->offset is calculated by find_ram_offset, which makes sure the
offset is aligned to a word.
This patch removes the alignment check on offset and unnecessary
variable *word*.
Signed-off-by: Wei Yang
---
include/exec/ram_addr.h | 15 +--
1 file changed, 9 insertions(+), 6
The *start* of migration_bitmap_sync_range is always 0, we can remove this
parameter.
Since RAMBlock->offset is always *word* aligned, we can remove the check on
offset and simplify the logic a little.
Wei Yang (3):
migration/ram.c: start of migration_bitmap_sync_range is always 0
We can eliminate to pass 0.
Signed-off-by: Wei Yang
---
migration/ram.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/migration/ram.c b/migration/ram.c
index 35bd6213e9..9948b2d021 100644
--- a/migration/ram.c
+++ b/migration/ram.c
@@ -1643,10 +1643,10 @@ static
Since start of cpu_physical_memory_sync_dirty_bitmap is always 0, we can
remove this parameter and simplify the calculation a bit.
Signed-off-by: Wei Yang
---
include/exec/ram_addr.h | 15 ++-
migration/ram.c | 2 +-
2 files changed, 7 insertions(+), 10 deletions(-)
diff
Currently, the cpuid passed from the device tree may still contain
non-affinity fields, which will cause arm_set_cpu_on failure.
Therefore, we mask the cpuid with affinity fields here to
improve qemu compatibility.
Signed-off-by: Yang Chuanlong
---
target/arm/arm-powerctl.c | 8 +++-
1 file
Patchew URL: https://patchew.org/QEMU/cover.1556540297.git.be...@igalia.com/
Hi,
This series failed the docker-mingw@fedora build test. Please find the testing
commands and
their output below. If you have Docker installed, you can probably reproduce it
locally.
=== TEST SCRIPT BEGIN ===
On 2019/4/29 20:10, Philippe Mathieu-Daudé wrote:
> On 4/29/19 1:42 PM, Longpeng (Mike) wrote:
>> Hi Philippe,
>>
>> On 2019/4/29 19:16, Philippe Mathieu-Daudé wrote:
>>
>>> Hi Mike,
>>>
>>> On 4/29/19 9:39 AM, Longpeng(Mike) wrote:
From: Longpeng
we found the following core in
>>> On 4/29/2019 at 7:37 PM, Eric Blake wrote:
> On 4/29/19 6:51 PM, Bruce Rogers wrote:
>> While investigating link-time-optimization, the compiler flagged this
>> case of not handling the error return from scsi_cdb_length(). Handle
>> this error case with a trace report.
>>
>> Signed-off-by:
On 4/29/19 6:51 PM, Bruce Rogers wrote:
> While investigating link-time-optimization, the compiler flagged this
> case of not handling the error return from scsi_cdb_length(). Handle
> this error case with a trace report.
>
> Signed-off-by: Bruce Rogers
> ---
> hw/scsi/scsi-disk.c | 4
> 1
While investigating link-time-optimization, the compiler flagged this
case of not handling the error return from scsi_cdb_length(). Handle
this error case with a trace report.
Signed-off-by: Bruce Rogers
---
hw/scsi/scsi-disk.c | 4
1 file changed, 4 insertions(+)
diff --git
Please let me know if further work or another patch submission is
required.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1814352
Title:
SIOCGIFNAME takes a struct ifreq not an integer
Status in
Rebased for v2.
The following changes since commit 82b2865e0d0ea4c1001e9e7ed7920bcc0458f6de:
Merge remote-tracking branch 'remotes/pmaydell/tags/pull-target-arm-20190429'
into staging (2019-04-29 18:05:56 +0100)
are available in the Git repository at:
https://github.com/rth7680/qemu.git
On 4/29/19 9:25 PM, Thomas Huth wrote:
> On 25/04/2019 23.41, Philippe Mathieu-Daudé wrote:
>> Hi Thomas,
>>
>> On 4/18/19 8:00 PM, Thomas Huth wrote:
>>> This patch is slightly based on earlier work by Ákos Kovács (i.e.
>>> his "hw/arm/Kconfig: Add ARM Kconfig" patch).
>>>
>>> Signed-off-by:
On 4/29/19 12:28 PM, David Hildenbrand wrote:
> Hi Richard,
>
> what are your plans with this series? (and shlv and friends?)
>
I expect to submit them this week, barring any other comment on the patches
themselves.
r~
On 4/29/19 9:17 AM, Peter Maydell wrote:
>> +struct elf_phdr *eppnt = phdr + i;
>> +
>> +switch (eppnt->p_type) {
>> +case PT_LOAD:
>> +{
>
> I think you have an extra layer of indent here that we usually
> don't do for switch statement cases.
No, that indent
On 11.03.19 17:50, Kevin Wolf wrote:
> Until now, with auto-read-only=on we tried to open the file read-write
> first and if that failed, read-only was tried. This is actually not good
> enough for libvirt, which gives QEMU SELinux permissions for read-write
> only as soon as it actually intends
On 4/29/19 9:21 AM, Peter Maydell wrote:
> This looks ok code-wise, but we'd need to hide it behind
> a defaults-to-off x-something property if we wanted to
> commit it before the kernel ABI is fixed.
I'm not intending to change the user-level abi, only the
internal abi within qemu, for handling
Please note the updates on:
https://bugzilla.redhat.com/show_bug.cgi?id=1701736
It turns out that you can reproduce the broken images on glusterfs fuse
mounts by using:
aio=native
cache=none,
write-cache=on
I have a set of vms running here on my
On 4/29/19 1:42 PM, Alberto Garcia wrote:
> Hi,
>
> this API only had a few users left so it can be easily removed.
Sounds very similar to my earlier attempt at the same:
https://lists.gnu.org/archive/html/qemu-devel/2018-11/msg02769.html
>
> Regards,
>
> Berto
>
> Alberto Garcia (5):
>
Patchew URL:
https://patchew.org/QEMU/20190429090250.7648-1-borntrae...@de.ibm.com/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Type: series
Message-id: 20190429090250.7648-1-borntrae...@de.ibm.com
Subject: [Qemu-devel] [PATCH v3 0/9]
On 20.04.19 09:34, Richard Henderson wrote:
> Based-on: tcg-next, which at present is only tcg_gen_extract2.
>
> The dupm patches have been on list before, with a larger context
> of supporting tcg/ppc. The rest of the set was written to support
> David's s390 vector patches. In particular:
>
On 25/04/2019 23.41, Philippe Mathieu-Daudé wrote:
> Hi Thomas,
>
> On 4/18/19 8:00 PM, Thomas Huth wrote:
>> This patch is slightly based on earlier work by Ákos Kovács (i.e.
>> his "hw/arm/Kconfig: Add ARM Kconfig" patch).
>>
>> Signed-off-by: Thomas Huth
>> ---
>>
On 29.04.19 11:02, Christian Borntraeger wrote:
> Provide the MSA9 facility (stfle.155).
> This also contains pckmo functions for key wrapping. Keep them in a
> separate group to disable those as a block if necessary.
>
> Signed-off-by: Christian Borntraeger
> ---
> target/s390x/cpu_features.c
On 29/04/2019 16:46, Marc-André Lureau wrote:
> Hi
>
> On Mon, Apr 29, 2019 at 4:26 PM Laurent Vivier wrote:
>>
>> On 29/04/2019 15:47, Marc-André Lureau wrote:
>>> $ ./x86_64-softmmu/qemu-system-x86_64 -sandbox off
>>> qemu-system-x86_64: -sandbox off: There is no option group 'sandbox'
>>>
Hi,
this API only had a few users left so it can be easily removed.
Regards,
Berto
Alberto Garcia (5):
qcow2: Replace bdrv_write() with bdrv_pwrite()
vdi: Replace bdrv_{read,write}() with bdrv_{pread,pwrite}()
vvfat: Replace bdrv_{read,write}() with bdrv_{pread,pwrite}()
block: Remove
The last user of this field disappeared when we replace the
sector-based bdrv_write() with the byte-based bdrv_pwrite().
Signed-off-by: Alberto Garcia
---
block/qcow2.c | 1 -
block/qcow2.h | 1 -
2 files changed, 2 deletions(-)
diff --git a/block/qcow2.c b/block/qcow2.c
index
There's only a couple of bdrv_read() and bdrv_write() calls left in
the vdi code, and they can be trivially replaced with the byte-based
bdrv_pread() and bdrv_pwrite().
Signed-off-by: Alberto Garcia
---
block/vdi.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git
There's only a couple of bdrv_read() and bdrv_write() calls left in
the vvfat code, and they can be trivially replaced with the byte-based
bdrv_pread() and bdrv_pwrite().
Signed-off-by: Alberto Garcia
---
block/vvfat.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git
There's only one bdrv_write() call left in the qcow2 code, and it can
be trivially replaced with the byte-based bdrv_pwrite().
Signed-off-by: Alberto Garcia
---
block/qcow2-refcount.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/block/qcow2-refcount.c
No one is using these functions anymore, all callers have switched to
the byte-based bdrv_pread() and bdrv_pwrite()
Signed-off-by: Alberto Garcia
---
block/io.c| 36
include/block/block.h | 4
2 files changed, 40 deletions(-)
diff --git
On 4/29/19 6:51 PM, Peter Maydell wrote:
> On Fri, 12 Apr 2019 at 17:55, Philippe Mathieu-Daudé
> wrote:
>>
>> Hi,
>>
>> As his first comment describes itself, the "hw/devices.h" contains
>> declarations for "Devices that have nowhere better to go."
>> This series remove it, creating new headers
On Thu, 25 Apr 2019 at 17:42, Antonio Ospite
wrote:
> Now that 4.0 has been released, maybe we can move on with this minor change.
>
> I will send a fix for https://bugs.launchpad.net/qemu/+bug/1817345 after
> this patch lands.
This patch has just gone in to master, so that should be ok
for you
itory at:
>
> https://git.linaro.org/people/pmaydell/qemu-arm.git
> tags/pull-target-arm-20190429
>
> for you to fetch changes up to 437cc27ddfded3bbab6afd5ac1761e0e195edba7:
>
> hw/devices: Move SMSC 91C111 declaration into a new header (2019-04-29
> 17:57:21 +0100)
>
>
On Wed, 3 Apr 2019 at 05:01, Richard Henderson
wrote:
>
> Cc: Aurelien Jarno
> Signed-off-by: Richard Henderson
> ---
Reviewed-by: Peter Maydell
thanks
-- PMM
Patchew URL:
https://patchew.org/QEMU/1556523569-44480-1-git-send-email-longpe...@huawei.com/
Hi,
This series failed the asan build test. Please find the testing commands and
their output below. If you have Docker installed, you can probably reproduce it
locally.
=== TEST SCRIPT BEGIN ===
Thanks Stefan!
Does this mean the performance could be improved via adding Batch I/O
submission support in Guest driver side which will be able to reduce the number
of virtqueue kicks?
Thanks,
Wei
On 4/29/19, 6:40 AM, "Stefan Hajnoczi" wrote:
On Fri, Apr 26, 2019 at 10:14:16AM +0200,
^This is on version:
% qemu-system-x86_64 --version
QEMU emulator version 4.0.50 (v4.0.0-rc4-52-g3284aa1281-dirty)
Copyright (c) 2003-2019 Fabrice Bellard and the QEMU Project developers
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to
I can reproduce this by booting the Windows 10 x64 install ISO with the
command line:
+ WINIMG=Win10.iso
+ VIRTIMG=virtio-win-0.1.164.iso
+ qemu-system-x86_64 -accel hvf -drive driver=raw,file=Win10.img,if=virtio -m
1536 -net nic,model=virtio -net user -cdrom Win10.iso -drive
*** This bug is a duplicate of bug 1818937 ***
https://bugs.launchpad.net/bugs/1818937
** This bug has been marked a duplicate of bug 1818937
Crash with HV_ERROR on macOS host
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
Thanks Paolo for your clarification!
Just wanted to double confirm, does this mean batch I/O submission won't apply
to aio=threads (which is the default mode)?
Thanks,
Wei
On 4/26/19, 9:25 PM, "Paolo Bonzini" wrote:
> Thanks Stefan and Paolo for your response and advice!
>
On Wed, 3 Apr 2019 at 04:49, Richard Henderson
wrote:
>
> Signed-off-by: Richard Henderson
> ---
> target/alpha/cpu.h| 5 ++--
> target/alpha/cpu.c| 5 ++--
> target/alpha/helper.c | 50 +++
> target/alpha/mem_helper.c | 16 -
On Sat, Apr 27, 2019 at 7:15 AM Philippe Mathieu-Daudé
wrote:
>
> The xlnx_dpdma device is only used by the ZynqMP AArch64 machine
> (not the MicroBlaze PMU). Remove it from the ZynqMP generic objects.
> (Note, this entry was duplicated for the AArch64).
>
> Signed-off-by: Philippe Mathieu-Daudé
On Sat, Apr 27, 2019 at 7:15 AM Philippe Mathieu-Daudé
wrote:
>
> The XLNX_ZYNQMP config is used in multiple subdirectories
> (timer, intc). Move it to the root hw/Kconfig.
>
> Signed-off-by: Philippe Mathieu-Daudé
Reviewed-by: Alistair Francis
Alistair
> ---
> hw/Kconfig | 3 +++
>
On Wed, 3 Apr 2019 at 05:05, Richard Henderson
wrote:
>
> Most of the existing users would continue around a loop which
> would fault the tlb entry in via a normal load/store. But for
> SVE we have a true non-faulting case which requires the new
> probing form of tlb_fill.
So am I right in
On Wed, 3 Apr 2019 at 05:05, Richard Henderson
wrote:
>
> We can now use the CPUClass hook instead of a named function.
>
> Create a static tlb_fill function to avoid other changes within
> cputlb.c. This also which also isolates the asserts implied.
I'm not sure what this sentence is trying to
On Wed, 3 Apr 2019 at 04:49, Richard Henderson
wrote:
>
> This hook will replace the (user-only mode specific) handle_mmu_fault
> hook, and the (system mode specific) tlb_fill function.
>
> The handle_mmu_fault hook was written as if there was a valid
> way to recover from an mmu fault, and had 3
On 29.04.19 18:37, Max Reitz wrote:
> On 02.04.19 17:37, Vladimir Sementsov-Ogievskiy wrote:
>> Background: decryption will be done in threads, to take benefit of it,
>> we should move it out of the lock first.
>
> ...which is safe after your commit c972fa123c73501b4, I presume.
>
> (At first
On 02.04.19 17:37, Vladimir Sementsov-Ogievskiy wrote:
> v5: rebase on master, some conflicts resolved due to data-file feature
>
> 01: new patch, just move test from cover letter to a file. I really hope that
> it
> will not hang the whole series, so, if we don't want it as is or with
>
Implement the code which updates the FPCCR register on an
exception entry where we are going to use lazy FP stacking.
We have to defer to the NVIC to determine whether the
various exceptions are currently ready or not.
Signed-off-by: Peter Maydell
Message-id:
On Wed, 3 Apr 2019 at 05:03, Richard Henderson
wrote:
>
> This hook is now completely replaced by tlb_fill.
>
> Signed-off-by: Richard Henderson
Reviewed-by: Peter Maydell
thanks
-- PMM
From: Philippe Mathieu-Daudé
Reviewed-by: Thomas Huth
Reviewed-by: Cédric Le Goater
Reviewed-by: Markus Armbruster
Signed-off-by: Philippe Mathieu-Daudé
Message-id: 20190412165416.7977-2-phi...@redhat.com
Signed-off-by: Peter Maydell
---
hw/arm/aspeed.c | 13 +
1 file changed,
Pushing registers to the stack for v7M needs to handle three cases:
* the "normal" case where we pend exceptions
* an "ignore faults" case where we set FSR bits but
do not pend exceptions (this is used when we are
handling some kinds of derived exception on exception entry)
* a "lazy FP
The M-profile architecture floating point system supports
lazy FP state preservation, where FP registers are not
pushed to the stack when an exception occurs but are instead
only saved if and when the first FP instruction in the exception
handler is executed. Implement this in QEMU, corresponding
On Sat, Apr 27, 2019 at 7:17 AM Philippe Mathieu-Daudé
wrote:
>
> The Xilinx I/O Module Interrupt Controller is only used by the
> MicroBlaze PMU, not by the AArch64 machine.
> Move it from the generic ZynqMP object list to the PMU specific.
>
> Signed-off-by: Philippe Mathieu-Daudé
From: Philippe Mathieu-Daudé
Reviewed-by: Thomas Huth
Reviewed-by: Markus Armbruster
Signed-off-by: Philippe Mathieu-Daudé
Message-id: 20190412165416.7977-7-phi...@redhat.com
Signed-off-by: Peter Maydell
---
include/hw/devices.h | 14 --
include/hw/misc/cbus.h | 32
From: Philippe Mathieu-Daudé
Reviewed-by: Thomas Huth
Reviewed-by: Markus Armbruster
Signed-off-by: Philippe Mathieu-Daudé
Message-id: 20190412165416.7977-11-phi...@redhat.com
Signed-off-by: Peter Maydell
---
include/hw/net/ne2000-isa.h | 6 ++
1 file changed, 6 insertions(+)
diff
From: Philippe Mathieu-Daudé
Reviewed-by: Markus Armbruster
Signed-off-by: Philippe Mathieu-Daudé
Message-id: 20190412165416.7977-8-phi...@redhat.com
Signed-off-by: Peter Maydell
---
include/hw/devices.h | 3 ---
include/hw/input/gamepad.h | 19 +++
hw/arm/stellaris.c
From: Philippe Mathieu-Daudé
This commit finally deletes "hw/devices.h".
Reviewed-by: Markus Armbruster
Signed-off-by: Philippe Mathieu-Daudé
Message-id: 20190412165416.7977-13-phi...@redhat.com
Signed-off-by: Peter Maydell
---
include/hw/devices.h | 11 ---
On Mon, Apr 29, 2019 at 5:43 AM Philippe Mathieu-Daudé
wrote:
>
> On 4/29/19 7:33 AM, Alistair Francis wrote:
> > Signed-off-by: Alistair Francis
> > ---
> > MAINTAINERS | 8 +
> > default-configs/arm-softmmu.mak | 1 +
> > hw/arm/Kconfig | 3 +
> >
Add a new helper function which returns the MMU index to use
for v7M, where the caller specifies all of the security
state, privilege level and whether the execution priority
is negative, and reimplement the existing
arm_v7m_mmu_idx_for_secstate_and_priv() in terms of it.
We are going to need
From: Philippe Mathieu-Daudé
Reviewed-by: Markus Armbruster
Signed-off-by: Philippe Mathieu-Daudé
Message-id: 20190412165416.7977-12-phi...@redhat.com
Signed-off-by: Peter Maydell
---
include/hw/net/lan9118.h | 2 ++
hw/arm/exynos4_boards.c | 3 ++-
hw/arm/mps2-tz.c | 3 ++-
Handle floating point registers in exception return.
This corresponds to pseudocode functions ValidateExceptionReturn(),
ExceptionReturn(), PopStack() and ConsumeExcStackFrame().
Signed-off-by: Peter Maydell
Reviewed-by: Richard Henderson
Message-id:
From: Philippe Mathieu-Daudé
No code used the tc6393xb_gpio_in_get() and tc6393xb_gpio_out_set()
functions since their introduction in commit 88d2c950b002. Time to
remove them.
Suggested-by: Markus Armbruster
Signed-off-by: Philippe Mathieu-Daudé
Message-id:
From: Philippe Mathieu-Daudé
Reviewed-by: Markus Armbruster
Signed-off-by: Philippe Mathieu-Daudé
Message-id: 20190412165416.7977-10-phi...@redhat.com
Signed-off-by: Peter Maydell
---
include/hw/devices.h | 3 ---
include/hw/net/lan9118.h | 19 +++
hw/arm/kzm.c
The M-profile CONTROL register has two bits -- SFPA and FPCA --
which relate to floating-point support, and should be RES0 otherwise.
Handle them correctly in the MSR/MRS register access code.
Neither is banked between security states, so they are stored
in v7m.control[M_REG_S] regardless of
From: Philippe Mathieu-Daudé
Add an entries the Blizzard device in MAINTAINERS.
Reviewed-by: Thomas Huth
Reviewed-by: Markus Armbruster
Signed-off-by: Philippe Mathieu-Daudé
Message-id: 20190412165416.7977-6-phi...@redhat.com
Signed-off-by: Peter Maydell
---
include/hw/devices.h |
Enable the FPU by default for the Cortex-M4 and Cortex-M33.
Signed-off-by: Peter Maydell
Reviewed-by: Richard Henderson
Message-id: 20190416125744.27770-27-peter.mayd...@linaro.org
---
target/arm/cpu.c | 8
1 file changed, 8 insertions(+)
diff --git a/target/arm/cpu.c
Implement the VLSTM instruction for v7M for the FPU present case.
Signed-off-by: Peter Maydell
Reviewed-by: Richard Henderson
Message-id: 20190416125744.27770-25-peter.mayd...@linaro.org
---
target/arm/cpu.h | 2 +
target/arm/helper.h| 2 +
target/arm/helper.c| 84
Implement the VLLDM instruction for v7M for the FPU present cas.
Signed-off-by: Peter Maydell
Reviewed-by: Richard Henderson
Message-id: 20190416125744.27770-26-peter.mayd...@linaro.org
---
target/arm/helper.h| 1 +
target/arm/helper.c| 54 ++
In the v7M architecture, if an exception is generated in the process
of doing the lazy stacking of FP registers, the handling of
possible escalation to HardFault is treated differently to the normal
approach: it works based on the saved information about exception
readiness that was stored in the
Move the NS TBFLAG down from bit 19 to bit 6, which has not
been used since commit c1e3781090b9d36c60 in 2015, when we
started passing the entire MMU index in the TB flags rather
than just a 'privilege level' bit.
This rearrangement is not strictly necessary, but means that
we can put
From: Philippe Mathieu-Daudé
Since uWireSlave is only used in this new header, there is no
need to expose it via "qemu/typedefs.h".
Reviewed-by: Markus Armbruster
Signed-off-by: Philippe Mathieu-Daudé
Message-id: 20190412165416.7977-9-phi...@redhat.com
Signed-off-by: Peter Maydell
---
From: Philippe Mathieu-Daudé
Suggested-by: Markus Armbruster
Signed-off-by: Philippe Mathieu-Daudé
Message-id: 20190412165416.7977-3-phi...@redhat.com
Reviewed-by: Peter Maydell
Signed-off-by: Peter Maydell
---
hw/arm/nseries.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff
Like AArch64, M-profile floating point has no FPEXC enable
bit to gate floating point; so always set the VFPEN TB flag.
M-profile also has CPACR and NSACR similar to A-profile;
they behave slightly differently:
* the CPACR is banked between Secure and Non-Secure
* if the NSACR forces a trap
Currently the code in v7m_push_stack() which detects a violation
of the v8M stack limit simply returns early if it does so. This
is OK for the current integer-only code, but won't work for the
floating point handling we're about to add. We need to continue
executing the rest of the function so
Enforce that for M-profile various FPSCR bits which are RES0 there
but have defined meanings on A-profile are never settable. This
ensures that M-profile code can't enable the A-profile behaviour
(notably vector length/stride handling) by accident.
Signed-off-by: Peter Maydell
Reviewed-by:
The TailChain() pseudocode specifies that a tail chaining
exception should sanitize the excReturn all-ones bits and
(if there is no FPU) the excReturn FType bits; we weren't
doing this.
Signed-off-by: Peter Maydell
Reviewed-by: Richard Henderson
Message-id:
If the floating point extension is present, then the SG instruction
must clear the CONTROL_S.SFPA bit. Implement this.
(On a no-FPU system the bit will always be zero, so we don't need
to make the clearing of the bit conditional on ARM_FEATURE_VFP.)
Signed-off-by: Peter Maydell
Reviewed-by:
We are close to running out of TB flags for AArch32; we could
start using the cs_base word, but before we do that we can
economise on our usage by sharing the same bits for the VFP
VECSTRIDE field and the XScale XSCALE_CPAR field. This
works because no XScale CPU ever had VFP.
Signed-off-by:
Correct the decode of the M-profile "coprocessor and
floating-point instructions" space:
* op0 == 0b11 is always unallocated
* if the CPU has an FPU then all insns with op1 == 0b101
are floating point and go to disas_vfp_insn()
For the moment we leave VLLDM and VLSTM as NOPs; in
a later
From: Philippe Mathieu-Daudé
This device is used by both ARM (BCM2836, for raspi2) and AArch64
(BCM2837, for raspi3) targets, and is not CPU-specific.
Move it to common object, so we build it once for all targets.
Signed-off-by: Philippe Mathieu-Daudé
Message-id:
The M-profile FPCCR.ASPEN bit indicates that automatic floating-point
context preservation is enabled. Before executing any floating-point
instruction, if FPCCR.ASPEN is set and the CONTROL FPCA/SFPA bits
indicate that there is no active floating point context then we
must create a new context (by
From: Philippe Mathieu-Daudé
Reviewed-by: Markus Armbruster
Signed-off-by: Philippe Mathieu-Daudé
Message-id: 20190412165416.7977-5-phi...@redhat.com
Signed-off-by: Peter Maydell
---
include/hw/devices.h | 6 --
include/hw/display/tc6393xb.h | 24
The only "system register" that M-profile floating point exposes
via the VMRS/VMRS instructions is FPSCR, and it does not have
the odd special case for rd==15. Add a check to ensure we only
expose FPSCR.
Signed-off-by: Peter Maydell
Reviewed-by: Richard Henderson
Message-id:
The M-profile FPCCR.S bit indicates the security status of
the floating point context. In the pseudocode ExecuteFPCheck()
function it is unconditionally set to match the current
security state whenever a floating point instruction is
executed.
Implement this by adding a new TB flag which tracks
The magic value pushed onto the callee stack as an integrity
check is different if floating point is present.
Signed-off-by: Peter Maydell
Reviewed-by: Richard Henderson
Message-id: 20190416125744.27770-15-peter.mayd...@linaro.org
---
target/arm/helper.c | 22 +++---
1 file
On Mon, Apr 29, 2019 at 5:38 AM KONRAD Frederic
wrote:
>
> Hi Alistair,
>
> Le 4/29/19 à 7:33 AM, Alistair Francis a écrit :
> > Signed-off-by: Alistair Francis
> > ---
> > MAINTAINERS | 8 +
> > default-configs/arm-softmmu.mak | 1 +
> > hw/arm/Kconfig
Handle floating point registers in exception entry.
This corresponds to the FP-specific parts of the pseudocode
functions ActivateException() and PushStack().
We defer the code corresponding to UpdateFPCCR() to a later patch.
Signed-off-by: Peter Maydell
Reviewed-by: Richard Henderson
The M-profile floating point support has three associated config
registers: FPCAR, FPCCR and FPDSCR. It also makes the registers
CPACR and NSACR have behaviour other than reads-as-zero.
Add support for all of these as simple reads-as-written registers.
We will hook up actual functionality later.
The following changes since commit 413a99a92c13ec408dcf2adaa87918dc81e890c8:
Add Nios II semihosting support. (2019-04-29 16:09:51 +0100)
are available in the Git repository at:
https://git.linaro.org/people/pmaydell/qemu-arm.git
tags/pull-target-arm-20190429
for you to fetch changes up
For v8M floating point support, transitions from Secure
to Non-secure state via BLNS and BLXNS must clear the
CONTROL.SFPA bit. (This corresponds to the pseudocode
BranchToNS() function.)
Signed-off-by: Peter Maydell
Reviewed-by: Richard Henderson
Message-id:
1 - 100 of 277 matches
Mail list logo
