Re:

Re:

[Alex Bennée]

Eric Auger <eauger@redhat.com> writes:

> Hi Alex,
>
> On 4/7/22 5:00 PM, Alex Bennée wrote:
>> When trying to work out what the virtio-net-tests where doing it was
>> hard because the g_test_trap_subprocess redirects all output to
>> /dev/null. Lift this restriction by using the appropriate flags so you
>> can see something similar to what the vhost-user-blk tests show when
>> running.
>> 
>> While we are at it remove the g_test_verbose() check so we always show
>> how the QEMU is run.
>> 
>> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
>> ---
>>  tests/qtest/qos-test.c | 7 +++----
>>  1 file changed, 3 insertions(+), 4 deletions(-)
>> 
>> diff --git a/tests/qtest/qos-test.c b/tests/qtest/qos-test.c
>> index f97d0a08fd..c6c196cc95 100644
>> --- a/tests/qtest/qos-test.c
>> +++ b/tests/qtest/qos-test.c
>> @@ -89,9 +89,7 @@ static void qos_set_machines_devices_available(void)
>>  
>>  static void restart_qemu_or_continue(char *path)
>>  {
>> -    if (g_test_verbose()) {
>> -        qos_printf("Run QEMU with: '%s'\n", path);
>> -    }
>> +    qos_printf("Run QEMU with: '%s'\n", path);
>>      /* compares the current command line with the
>>       * one previously executed: if they are the same,
>>       * don't restart QEMU, if they differ, stop previous
>> @@ -185,7 +183,8 @@ static void run_one_test(const void *arg)
>>  static void subprocess_run_one_test(const void *arg)
>>  {
>>      const gchar *path = arg;
>> -    g_test_trap_subprocess(path, 0, 0);
>> +    g_test_trap_subprocess(path, 0,
>> +                           G_TEST_SUBPROCESS_INHERIT_STDOUT | G_TEST_SUBPROCESS_INHERIT_STDERR);
> While workling on libqos/pci tests on aarch64 I also did that but I
> noticed there were a bunch of errors such as:
>
> /aarch64/virt/generic-pcihost/pci-bus-generic/pci-bus/virtio-net-pci/virtio-net/virtio-net-tests/vhost-user/multiqueue:
> qemu-system-aarch64: Failed to set msg fds.
> qemu-system-aarch64: vhost VQ 0 ring restore failed: -22: Invalid
> argument (22)
> qemu-system-aarch64: Failed to set msg fds.
> qemu-system-aarch64: vhost VQ 1 ring restore failed: -22: Invalid
> argument (22)
> qemu-system-aarch64: Failed to set msg fds.
> qemu-system-aarch64: vhost VQ 2 ring restore failed: -22: Invalid
> argument (22)
> qemu-system-aarch64: Failed to set msg fds.
> qemu-system-aarch64: vhost VQ 3 ring restore failed: -22: Invalid
> argument (22)
>
> I see those also when running with x86_64-softmmu/qemu-system-x86_64
> (this is no aarch64 specific).

I think this is a symptom of an unclean tear down (which might be too
much to ask for our fake vhost backend) or something we should handle
better. I still have to get my gpio test working so I'll have a look
tomorrow.


>
> I don't know if it is an issue to get those additional errors?
>
> Thanks
>
> Eric
>
>>      g_test_trap_assert_passed();
>>  }
>>  
>> 


-- 
Alex Bennée

(no subject)

[Phil Dennis-Jordan]

Date: Mon, 15 Jul 2024 21:07:12 +0200
Subject: [PATCH 00/26] hw/display/apple-gfx: New macOS PV Graphics device
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

This sequence of patches integrates the paravirtualised graphics device
implemented by macOS's ParavirtualizedGraphics.Framework into Qemu.
Combined with the guest drivers which ship with macOS versions 11 and up,
this allows the guest OS to use the host's GPU for hardware accelerated
3D graphics, GPGPU compute (both using the 'Metal' graphics API), and
window compositing.

Some background:
----------------

The device exposed by the ParavirtualizedGraphics.Framework's (henceforth
PVG) public API consists of a PCI device with a single memory-mapped BAR;
the VMM is expected to pass reads and writes through to the framework, and
to forward interrupts emenating from it to the guest VM.

The bulk of data exchange between host and guest occurs via shared memory,
however. For this purpose, PVG makes callbacks to VMM code for allocating,
mapping, unmapping, and deallocating "task" memory ranges. Each task
represents a contiguous host virtual address range, and PVG expects the
VMM to map specific guest system memory ranges to these host addresses via
subsequent map callbacks. Multiple tasks can exist at a time, each with
many mappings.

Data is exchanged via an undocumented, Apple-proprietary protocol. The
PVG API only acts as a facilitator for establishing the communication
mechanism. This is perhaps not ideal, and among other things means it
only works on macOS hosts, but it's the only serious option we've got for
good performance and quality graphics with macOS guests at this time.

The first iterations of this PVG integration into Qemu were developed
by Alexander Graf as part of his "vmapple" machine patch series for
supporting aarch64 macOS guests, and posted to qemu-devel in June and
August 2023:

https://lore.kernel.org/all/20230830161425.91946-1-graf@amazon.com/T/

This integration mimics the "vmapple"/"apple-gfx" variant of the PVG device
used by Apple's own VMM, Virtualization.framework. This variant does not use
PCI but acts as a direct MMIO system device; there are two MMIO ranges, one
behaving identically to the PCI BAR, while the other's functionality is
exposed by private APIs in the PVG framework. It is only available on aarch64
macOS hosts.

I had prior to this simultaneously and independently developed my own PVG
integration for Qemu using the public PCI device APIs, with x86-64 and
corresponding macOS guests and hosts as the target. After some months of
use in production, I was slowly reviewing the code and readying it for
upstreaming around the time Alexander posted his vmapple patches.

I ended up reviewing the vmapple PVG code in detail; I identified a number
of issues with it (mainly thanks to my prior trial-and-error working with
the framework) but overall I thought it a better basis for refinement
than my own version:

 - It implemented the vmapple variant of the device. I thought it better to
   port the part I understood well (PCI variant) to this than trying to port
   the part I didn't understand well (MMIO vmapple variant) to my own code.
 - The code was already tidier than my own.

It also became clear in out-of-band communication that Alexander would
probably not end up having the time to see the patch through to inclusion,
and was happy for me to start making changes and to integrate my PCI code.

It's taken a while, but I'm happy with the result and think it will be a
welcome addition for anyone running macOS VMs.

What doesn't work:
------------------

 * State (de-)serialisation and thus migration. There is no fundamental
   technical obstacle to this. PVG supports saving and loading device state.
   I have simply not had the resources to implement (and crucially, test it)
   it yet.
 * Setting the list of display modes via a property is currently only
   implemented on the PCI version, which is the only one readily testable
   without the out-of-tree vmapple patches. (See review notes for patch 24)
 * End-to-end GPU-only rendering. After the host GPU has rendered the guest's
   screen, the framebuffer is copied into a system memory buffer (surface).
   When using the Qemu Cocoa UI, this buffer is drawn by the CPU into a GPU
   texture used for hardware window compositing. It would be vastly more
   efficient to retain the Metal texture and pass it directly through to the
   Cocoa window. We currently have no mechanism for doing so; it would need
   to be similar to the end-to-end OpenGL rendering support, with the added
   complication that Metal textures are Objective-C types and would need to
   traverse the plain C code of the Qemu display subsystem.
 * Dirty region detection. Similarly, the whole framebuffer is marked modified
   even if there has only been a small change. This hurts network data volume
   when using VNC.
 * Multi-head support. PVG allows "connecting" more than one virtual display.
   This integration currently always uses exactly 1 display.
 * The vmapple/aarch64 variant of the device is only testable with Alexander's
   vmapple machine type patch set. I've been maintaining this out-of-tree and
   have made a few improvements, but it doesn't yet run smoothly. (Graphics
   work fine with this code, issues are with other devices.) I can push my
   current draft to a git forge if anyone wants to test with them. I'm
   definitely hoping to eventually resolve the remaining problems and submit
   a revised version of that patch set as well.


I think we can live without these for the moment, and I'd prefer to work on
them only if and when the baseline functionality has been merged.

Patch review notes:
-------------------

I have aimed to submit the patches roughly in order of descending importance
and increasing debatability. From patch 18 it becomes usable and useful in
practice without further modification. Patches 19-23 fix issues that only occur
in certain host configurations or that can otherwise be worked around. Patch
24 is more of an RFC; patch 26 is needed if recently submitted Cocoa UI patches
end up being merged.

Brief meta-discussion of specific patches and groups of patches:

 01:    I have retained Alexander Graf's original patch intact as far as
        possible as patch 01. My only modifications are those required for
        fixing rebase conflicts.
 02:    Resolves build errors caused by upstream API changes since original
        patch submission.
 03:    This moves the device code to hw/display from its original hw/vmapple.
        With the PCI variant added later, it doesn't make much sense to put
        this inside a machine type directory.
 04-13: These patches address issues identified during code review in the
        original e-mail threads as well as my own review.
 14-15: These patches split the monolithic source file into a common core and
        vmapple/mmio specific parts.
        NOTE: checkpatch.pl complains about #ifdef __OBJC__ in the header file.
        This is needed for allowing the file to be #included from pure C.
        Ensuring that isn't currently critical, but I expect it to be useful
        in future.
 16-17: Preparation for x86-64. The x86-64 variant of PVG seems to behave
        slightly differently than the aarch64 version in terms of threading
        and control flow edge cases. We need to do some things asynchronously
        to avoid deadlock and performance problems.
 18:    The PCI variant. This builds on the split from 14/15 and the async
        changes to create the PVG PCI device which works with x86-64 macOS
        guests.
 19-23: Fixes for various additional problems and limitations. Without these
        the PVG device will only work with the Cocoa UI, on Macs which
        have an integrated (shared memory) GPU only, and mouse cursors will
        be slightly off, for example.
 24:    QOM property for specifying the display mode list (resolutions) the
        device will report to the guest. I checked other display devices and
        found none supported this, though I personally find it very useful.
        I'm wondering whether this should be a more generic feature optionally
        usable by any display device in Qemu?
 25:    Adding myself as maintainer for the PVG code, and reviewer for HVF.
 26:    Required if/when Akihiko Odaki's pending patch for removing
        dpy_cursor_define_supported is merged.

I don't know if it's useful/wise to keep these all as separate patches.
I'm happy to squash any number or groups of them. Personally, I find
smaller patches easier to review, and the git blame history acts as
a sort of documentation, so I've kept them for now.

Alexander Graf (1):
  hw/vmapple/apple-gfx: Introduce ParavirtualizedGraphics.Framework
    support

Phil Dennis-Jordan (25):
  hw/vmapple/apple-gfx: BQL renaming update
  hw/display/apple-gfx: Moved from hw/vmapple/
  hw/display/apple-gfx: uses DEFINE_TYPES macro
  hw/display/apple-gfx: native -> little endian memory ops
  hw/display/apple-gfx: Removes dead/superfluous code
  hw/display/apple-gfx: Makes set_mode thread & memory safe
  hw/display/apple-gfx: Adds migration blocker
  hw/display/apple-gfx: Wraps ObjC autorelease code in pool
  hw/display/apple-gfx: Fixes ObjC new/init misuse, plugs leaks
  hw/display/apple-gfx: Uses ObjC category extension for private
    property
  hw/display/apple-gfx: Task memory mapping cleanup
  hw/display/apple-gfx: Defines PGTask_s struct instead of casting
  hw/display/apple-gfx: Refactoring of realize function
  hw/display/apple-gfx: Separates generic & vmapple-specific
    functionality
  hw/display/apple-gfx: Asynchronous MMIO writes on x86-64
  hw/display/apple-gfx: Asynchronous rendering and graphics update
  hw/display/apple-gfx: Adds PCI implementation
  ui/cocoa: Adds non-app runloop on main thread mode
  hw/display/apple-gfx: Fixes cursor hotspot handling
  hw/display/apple-gfx: Implements texture syncing for non-UMA GPUs
  hw/display/apple-gfx: Replaces magic number with queried MMIO length
  hw/display/apple-gfx: Host GPU picking improvements
  hw/display/apple-gfx: Adds configurable mode list
  MAINTAINERS: Add myself as maintainer for apple-gfx, reviewer for HVF
  hw/display/apple-gfx: Removes UI pointer support check

 MAINTAINERS                    |   7 +
 hw/display/Kconfig             |  13 +
 hw/display/apple-gfx-pci.m     | 166 +++++++++
 hw/display/apple-gfx-vmapple.m | 194 ++++++++++
 hw/display/apple-gfx.h         |  72 ++++
 hw/display/apple-gfx.m         | 659 +++++++++++++++++++++++++++++++++
 hw/display/meson.build         |   3 +
 hw/display/trace-events        |  26 ++
 include/qemu-main.h            |   2 +
 meson.build                    |   4 +
 ui/cocoa.m                     |  15 +-
 11 files changed, 1159 insertions(+), 2 deletions(-)
 create mode 100644 hw/display/apple-gfx-pci.m
 create mode 100644 hw/display/apple-gfx-vmapple.m
 create mode 100644 hw/display/apple-gfx.h
 create mode 100644 hw/display/apple-gfx.m

-- 
2.39.3 (Apple Git-146)

Re:

[Akihiko Odaki]

On 2024/07/16 6:06, Phil Dennis-Jordan wrote:
> Date: Mon, 15 Jul 2024 21:07:12 +0200
> Subject: [PATCH 00/26] hw/display/apple-gfx: New macOS PV Graphics device
> MIME-Version: 1.0
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 8bit
> 
> This sequence of patches integrates the paravirtualised graphics device
> implemented by macOS's ParavirtualizedGraphics.Framework into Qemu.
> Combined with the guest drivers which ship with macOS versions 11 and up,
> this allows the guest OS to use the host's GPU for hardware accelerated
> 3D graphics, GPGPU compute (both using the 'Metal' graphics API), and
> window compositing.
> 
> Some background:
> ----------------
> 
> The device exposed by the ParavirtualizedGraphics.Framework's (henceforth
> PVG) public API consists of a PCI device with a single memory-mapped BAR;
> the VMM is expected to pass reads and writes through to the framework, and
> to forward interrupts emenating from it to the guest VM.
> 
> The bulk of data exchange between host and guest occurs via shared memory,
> however. For this purpose, PVG makes callbacks to VMM code for allocating,
> mapping, unmapping, and deallocating "task" memory ranges. Each task
> represents a contiguous host virtual address range, and PVG expects the
> VMM to map specific guest system memory ranges to these host addresses via
> subsequent map callbacks. Multiple tasks can exist at a time, each with
> many mappings.
> 
> Data is exchanged via an undocumented, Apple-proprietary protocol. The
> PVG API only acts as a facilitator for establishing the communication
> mechanism. This is perhaps not ideal, and among other things means it
> only works on macOS hosts, but it's the only serious option we've got for
> good performance and quality graphics with macOS guests at this time.
> 
> The first iterations of this PVG integration into Qemu were developed
> by Alexander Graf as part of his "vmapple" machine patch series for
> supporting aarch64 macOS guests, and posted to qemu-devel in June and
> August 2023:
> 
> https://lore.kernel.org/all/20230830161425.91946-1-graf@amazon.com/T/
> 
> This integration mimics the "vmapple"/"apple-gfx" variant of the PVG device
> used by Apple's own VMM, Virtualization.framework. This variant does not use
> PCI but acts as a direct MMIO system device; there are two MMIO ranges, one
> behaving identically to the PCI BAR, while the other's functionality is
> exposed by private APIs in the PVG framework. It is only available on aarch64
> macOS hosts.
> 
> I had prior to this simultaneously and independently developed my own PVG
> integration for Qemu using the public PCI device APIs, with x86-64 and
> corresponding macOS guests and hosts as the target. After some months of
> use in production, I was slowly reviewing the code and readying it for
> upstreaming around the time Alexander posted his vmapple patches.
> 
> I ended up reviewing the vmapple PVG code in detail; I identified a number
> of issues with it (mainly thanks to my prior trial-and-error working with
> the framework) but overall I thought it a better basis for refinement
> than my own version:
> 
>   - It implemented the vmapple variant of the device. I thought it better to
>     port the part I understood well (PCI variant) to this than trying to port
>     the part I didn't understand well (MMIO vmapple variant) to my own code.
>   - The code was already tidier than my own.
> 
> It also became clear in out-of-band communication that Alexander would
> probably not end up having the time to see the patch through to inclusion,
> and was happy for me to start making changes and to integrate my PCI code.

Hi,

Thanks for continuing his effort.

Please submit a patch series that includes his patches. Please also 
merge fixes for his patches into them. This saves the effort to review 
the obsolete code and keeps git bisect working.

Regards,
Akihiko Odaki

Re:

[Phil Dennis-Jordan]

[-- Attachment #1: Type: text/plain, Size: 717 bytes --]

On Tue, 16 Jul 2024 at 08:07, Akihiko Odaki <akihiko.odaki@daynix.com>
wrote:

> Hi,
>
> Thanks for continuing his effort.
>
> Please submit a patch series that includes his patches. Please also
> merge fixes for his patches into them. This saves the effort to review
> the obsolete code and keeps git bisect working.
>
>
Sorry about that - it looks like (a) my edits to the cover letter messed
something up and (b) patch 1 got email-filtered somewhere along the way for
having the "wrong" From: address. I've submitted v2 with most patches
squashed into patch 1, whose authorship I've also changed to myself (with
Co-authored-by tag for the original code) so hopefully this time around it
shows up OK.

Thanks,
Phil

[-- Attachment #2: Type: text/html, Size: 1122 bytes --]

[PATCH v3 00/60] target/arm: Cleanups, new features, new cpus

[Richard Henderson]

Supercedes: 20220412003326.588530-1-richard.henderson@linaro.org
("target/arm: 8 new features, A76 and N1")

Changes for v3:
  * More field updates for H.a.  This is not nearly complete, but what
    I've encountered so far as I've begun implementing SME.
  * Use bool instead of uint32_t for env->{aarch64,thumb}.
    I had anticipated other changes for implementing PSTATE.{SM,FA},
    but dropped those; these seemed like worth keeping.
  * Use tcg_constant_* more -- got stuck on this while working on...
  * Lots of cleanups to ARMCPRegInfo.
  * Discard unreachable cpregs when ELx not available.
  * Transform EL2 regs to RES0 when EL3 present but EL2 isn't.
    This greatly simplifies registration of cpregs for new features.
    Changes contextidr_el2, minimal_ras_reginfo, scxtnum_reginfo
    within this patch set; other uses coming for SME.


r~


Richard Henderson (60):
  tcg: Add tcg_constant_ptr
  target/arm: Update ISAR fields for ARMv8.8
  target/arm: Update SCR_EL3 bits to ARMv8.8
  target/arm: Update SCTLR bits to ARMv9.2
  target/arm: Change DisasContext.aarch64 to bool
  target/arm: Change CPUArchState.aarch64 to bool
  target/arm: Extend store_cpu_offset to take field size
  target/arm: Change DisasContext.thumb to bool
  target/arm: Change CPUArchState.thumb to bool
  target/arm: Remove fpexc32_access
  target/arm: Split out set_btype_raw
  target/arm: Split out gen_rebuild_hflags
  target/arm: Use tcg_constant in translate-a64.c
  target/arm: Simplify GEN_SHIFT in translate.c
  target/arm: Simplify gen_sar
  target/arm: Simplify aa32 DISAS_WFI
  target/arm: Use tcg_constant in translate.c
  target/arm: Use tcg_constant in translate-m-nocp.c
  target/arm: Use tcg_constant in translate-neon.c
  target/arm: Use smin/smax for do_sat_addsub_32
  target/arm: Use tcg_constant in translate-sve.c
  target/arm: Use tcg_constant in translate-vfp.c
  target/arm: Use tcg_constant_i32 in translate.h
  target/arm: Split out cpregs.h
  target/arm: Reorg CPAccessResult and access_check_cp_reg
  target/arm: Replace sentinels with ARRAY_SIZE in cpregs.h
  target/arm: Make some more cpreg data static const
  target/arm: Reorg ARMCPRegInfo type field bits
  target/arm: Change cpreg access permissions to enum
  target/arm: Name CPState type
  target/arm: Name CPSecureState type
  target/arm: Update sysreg fields when redirecting for E2H
  target/arm: Store cpregs key in the hash table directly
  target/arm: Cleanup add_cpreg_to_hashtable
  target/arm: Handle cpreg registration for missing EL
  target/arm: Drop EL3 no EL2 fallbacks
  target/arm: Merge zcr reginfo
  target/arm: Add isar predicates for FEAT_Debugv8p2
  target/arm: Adjust definition of CONTEXTIDR_EL2
  target/arm: Move cortex impdef sysregs to cpu_tcg.c
  target/arm: Update qemu-system-arm -cpu max to cortex-a57
  target/arm: Set ID_DFR0.PerfMon for qemu-system-arm -cpu max
  target/arm: Split out aa32_max_features
  target/arm: Annotate arm_max_initfn with FEAT identifiers
  target/arm: Use field names for manipulating EL2 and EL3 modes
  target/arm: Enable FEAT_Debugv8p2 for -cpu max
  target/arm: Enable FEAT_Debugv8p4 for -cpu max
  target/arm: Add isar_feature_{aa64,any}_ras
  target/arm: Add minimal RAS registers
  target/arm: Enable SCR and HCR bits for RAS
  target/arm: Implement virtual SError exceptions
  target/arm: Implement ESB instruction
  target/arm: Enable FEAT_RAS for -cpu max
  target/arm: Enable FEAT_IESB for -cpu max
  target/arm: Enable FEAT_CSV2 for -cpu max
  target/arm: Enable FEAT_CSV2_2 for -cpu max
  target/arm: Enable FEAT_CSV3 for -cpu max
  target/arm: Enable FEAT_DGH for -cpu max
  target/arm: Define cortex-a76
  target/arm: Define neoverse-n1

 docs/system/arm/emulation.rst |  10 +
 docs/system/arm/virt.rst      |   2 +
 include/tcg/tcg.h             |   2 +
 target/arm/cpregs.h           | 459 +++++++++++++++++
 target/arm/cpu.h              | 475 ++++--------------
 target/arm/helper.h           |   1 +
 target/arm/internals.h        |  16 +
 target/arm/syndrome.h         |   5 +
 target/arm/translate-a32.h    |  13 +-
 target/arm/translate.h        |  17 +-
 target/arm/a32.decode         |  16 +-
 target/arm/t32.decode         |  18 +-
 hw/arm/pxa2xx.c               |   2 +-
 hw/arm/pxa2xx_pic.c           |   2 +-
 hw/arm/sbsa-ref.c             |   2 +
 hw/arm/virt.c                 |   2 +
 hw/intc/arm_gicv3_cpuif.c     |   6 +-
 hw/intc/arm_gicv3_kvm.c       |   3 +-
 linux-user/arm/cpu_loop.c     |   2 +-
 target/arm/cpu.c              |  88 ++--
 target/arm/cpu64.c            | 349 +++++++------
 target/arm/cpu_tcg.c          | 232 ++++++---
 target/arm/gdbstub.c          |   5 +-
 target/arm/helper-a64.c       |   4 +-
 target/arm/helper.c           | 897 ++++++++++++++++++----------------
 target/arm/hvf/hvf.c          |   2 +-
 target/arm/m_helper.c         |   6 +-
 target/arm/op_helper.c        | 113 +++--
 target/arm/translate-a64.c    | 395 ++++++---------
 target/arm/translate-m-nocp.c |  12 +-
 target/arm/translate-neon.c   |  21 +-
 target/arm/translate-sve.c    | 207 +++-----
 target/arm/translate-vfp.c    |  76 +--
 target/arm/translate.c        | 400 +++++++--------
 34 files changed, 2026 insertions(+), 1834 deletions(-)
 create mode 100644 target/arm/cpregs.h

-- 
2.25.1

[PATCH v3 06/60] target/arm: Change CPUArchState.aarch64 to bool

[Richard Henderson]

Bool is a more appropriate type for this value.
Adjust the assignments to use true/false.

Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
---
 target/arm/cpu.h        | 2 +-
 target/arm/cpu.c        | 2 +-
 target/arm/helper-a64.c | 4 ++--
 target/arm/helper.c     | 2 +-
 target/arm/hvf/hvf.c    | 2 +-
 5 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/target/arm/cpu.h b/target/arm/cpu.h
index 9ae9c935a2..a61a52e2f6 100644
--- a/target/arm/cpu.h
+++ b/target/arm/cpu.h
@@ -258,7 +258,7 @@ typedef struct CPUArchState {
      *  all other bits are stored in their correct places in env->pstate
      */
     uint32_t pstate;
-    uint32_t aarch64; /* 1 if CPU is in aarch64 state; inverse of PSTATE.nRW */
+    bool aarch64; /* True if CPU is in aarch64 state; inverse of PSTATE.nRW */
 
     /* Cached TBFLAGS state.  See below for which bits are included.  */
     CPUARMTBFlags hflags;
diff --git a/target/arm/cpu.c b/target/arm/cpu.c
index 5d4ca7a227..30e0d16ad4 100644
--- a/target/arm/cpu.c
+++ b/target/arm/cpu.c
@@ -189,7 +189,7 @@ static void arm_cpu_reset(DeviceState *dev)
 
     if (arm_feature(env, ARM_FEATURE_AARCH64)) {
         /* 64 bit CPUs always start in 64 bit mode */
-        env->aarch64 = 1;
+        env->aarch64 = true;
 #if defined(CONFIG_USER_ONLY)
         env->pstate = PSTATE_MODE_EL0t;
         /* Userspace expects access to DC ZVA, CTL_EL0 and the cache ops */
diff --git a/target/arm/helper-a64.c b/target/arm/helper-a64.c
index 7cf953b1e6..77a8502b6b 100644
--- a/target/arm/helper-a64.c
+++ b/target/arm/helper-a64.c
@@ -952,7 +952,7 @@ void HELPER(exception_return)(CPUARMState *env, uint64_t new_pc)
     qemu_mutex_unlock_iothread();
 
     if (!return_to_aa64) {
-        env->aarch64 = 0;
+        env->aarch64 = false;
         /* We do a raw CPSR write because aarch64_sync_64_to_32()
          * will sort the register banks out for us, and we've already
          * caught all the bad-mode cases in el_from_spsr().
@@ -975,7 +975,7 @@ void HELPER(exception_return)(CPUARMState *env, uint64_t new_pc)
     } else {
         int tbii;
 
-        env->aarch64 = 1;
+        env->aarch64 = true;
         spsr &= aarch64_pstate_valid_mask(&env_archcpu(env)->isar);
         pstate_write(env, spsr);
         if (!arm_singlestep_active(env)) {
diff --git a/target/arm/helper.c b/target/arm/helper.c
index 7d14650615..47fe790854 100644
--- a/target/arm/helper.c
+++ b/target/arm/helper.c
@@ -10182,7 +10182,7 @@ static void arm_cpu_do_interrupt_aarch64(CPUState *cs)
     }
 
     pstate_write(env, PSTATE_DAIF | new_mode);
-    env->aarch64 = 1;
+    env->aarch64 = true;
     aarch64_restore_sp(env, new_el);
     helper_rebuild_hflags_a64(env, new_el);
 
diff --git a/target/arm/hvf/hvf.c b/target/arm/hvf/hvf.c
index 8c34f86792..11176ef252 100644
--- a/target/arm/hvf/hvf.c
+++ b/target/arm/hvf/hvf.c
@@ -565,7 +565,7 @@ int hvf_arch_init_vcpu(CPUState *cpu)
     hv_return_t ret;
     int i;
 
-    env->aarch64 = 1;
+    env->aarch64 = true;
     asm volatile("mrs %0, cntfrq_el0" : "=r"(arm_cpu->gt_cntfrq_hz));
 
     /* Allocate enough space for our sysreg sync */
-- 
2.25.1

Re:

[Alex Bennée]

Richard Henderson <richard.henderson@linaro.org> writes:

> Bool is a more appropriate type for this value.
> Adjust the assignments to use true/false.
>
> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>

Reviewed-by: Alex Bennée <alex.bennee@linaro.org>

-- 
Alex Bennée

(no subject)

[罗勇刚(Yonggang Luo)]

[-- Attachment #1: Type: text/plain, Size: 1827 bytes --]

qapi docs tests building failed on win32

looking for now-outdated files... none found
pickling environment... done
checking consistency... done
preparing documents... done
writing output... [100%] doc-good

build succeeded.

The text files are in tests/qapi-schema.
"C:/CI-Tools/msys64/mingw64/bin/python3.exe"
"C:/work/xemu/qemu/meson/meson.py" "--internal" "exe" "--capture"
"tests/qapi-schema/doc-good.txt.nocr" "--" "perl" "-pe" "$x = chr 13;
s/$x$//" "tests/qapi-schema/doc-good.txt" && if test -e
tests/qapi-schema/doc-good.txt.nocr; then printf '%s\n'
tests/qapi-schema/doc-good.txt.nocr >
tests/qapi-schema/doc-good.txt.nocr.stamp; fi
syntax error at -e line 1, near "="
Execution of -e aborted due to compilation errors.
make: *** [Makefile.ninja:2555：tests/qapi-schema/doc-good.txt.nocr.stamp]
错误 255
"C:/CI-Tools/msys64/mingw64/bin/python3.exe"
"C:/work/xemu/qemu/meson/meson.py" "--internal" "exe" "--capture"
"qemu-version.h" "--" "C:/CI-Tools/msys64/mingw64/bin/python3.exe"
"C:/work/xemu/qemu/scripts/qemu-version.py" "C:/work/xemu/qemu" "" "5.1.50"
&& if test -e qemu-version.h; then printf '%s\n' qemu-version.h >
qemu-version.h.stamp; fi
"C:/CI-Tools/msys64/mingw64/bin/python3.exe"
"C:/work/xemu/qemu/meson/meson.py" "--internal" "exe" "--capture"
"tests/qapi-schema/doc-good.txt.nocr" "--" "perl" "-pe" "$x = chr 13;
s/$x$//" "tests/qapi-schema/doc-good.txt" && if test -e
tests/qapi-schema/doc-good.txt.nocr; then printf '%s\n'
tests/qapi-schema/doc-good.txt.nocr >
tests/qapi-schema/doc-good.txt.nocr.stamp; fi
syntax error at -e line 1, near "="
Execution of -e aborted due to compilation errors.
make: *** [Makefile.ninja:2555：tests/qapi-schema/doc-good.txt.nocr.stamp]
错误 255
--
         此致
礼
罗勇刚
Yours
    sincerely,
Yonggang Luo

[-- Attachment #2: Type: text/html, Size: 2305 bytes --]

Re:

[Paolo Bonzini]

On 08/10/20 20:30, 罗勇刚(Yonggang Luo) wrote:
> 
> 
> The text files are in tests/qapi-schema.
> "C:/CI-Tools/msys64/mingw64/bin/python3.exe"
> "C:/work/xemu/qemu/meson/meson.py" "--internal" "exe" "--capture"
> "tests/qapi-schema/doc-good.txt.nocr" "--" "perl" "-pe" "$x = chr 13;
> s/$x$//" "tests/qapi-schema/doc-good.txt" && if test -e
> tests/qapi-schema/doc-good.txt.nocr; then printf '%s\n'
> tests/qapi-schema/doc-good.txt.nocr >
> tests/qapi-schema/doc-good.txt.nocr.stamp; fi
> syntax error at -e line 1, near "="
> Execution of -e aborted due to compilation errors.
> make: *** [Makefile.ninja:2555：tests/qapi-schema/doc-
> good.txt.nocr.stamp] 错误 255
> "C:/CI-Tools/msys64/mingw64/bin/python3.exe"
> "C:/work/xemu/qemu/meson/meson.py" "--internal" "exe" "--capture"
> "qemu-version.h" "--" "C:/CI-Tools/msys64/mingw64/bin/python3.exe"
> "C:/work/xemu/qemu/scripts/qemu-version.py" "C:/work/xemu/qemu" ""
> "5.1.50" && if test -e qemu-version.h; then printf '%s\n' qemu-version.h
>> qemu-version.h.stamp; fi
> "C:/CI-Tools/msys64/mingw64/bin/python3.exe"
> "C:/work/xemu/qemu/meson/meson.py" "--internal" "exe" "--capture"
> "tests/qapi-schema/doc-good.txt.nocr" "--" "perl" "-pe" "$x = chr 13;
> s/$x$//" "tests/qapi-schema/doc-good.txt" && if test -e
> tests/qapi-schema/doc-good.txt.nocr; then printf '%s\n'
> tests/qapi-schema/doc-good.txt.nocr >
> tests/qapi-schema/doc-good.txt.nocr.stamp; fi
> syntax error at -e line 1, near "="
> Execution of -e aborted due to compilation errors.
> make: *** [Makefile.ninja:2555：tests/qapi-schema/doc-
> good.txt.nocr.stamp] 错误 255

I think I know what's going on, but it's easiest to just switch to
Ninja.  I'll post patches next week.

Paolo

Re:

[罗勇刚(Yonggang Luo)]

[-- Attachment #1: Type: text/plain, Size: 2022 bytes --]

Oh, I've fixed it and patch are sent.

On Fri, Oct 9, 2020 at 3:24 AM Paolo Bonzini <pbonzini@redhat.com> wrote:
>
> On 08/10/20 20:30, 罗勇刚(Yonggang Luo) wrote:
> >
> >
> > The text files are in tests/qapi-schema.
> > "C:/CI-Tools/msys64/mingw64/bin/python3.exe"
> > "C:/work/xemu/qemu/meson/meson.py" "--internal" "exe" "--capture"
> > "tests/qapi-schema/doc-good.txt.nocr" "--" "perl" "-pe" "$x = chr 13;
> > s/$x$//" "tests/qapi-schema/doc-good.txt" && if test -e
> > tests/qapi-schema/doc-good.txt.nocr; then printf '%s\n'
> > tests/qapi-schema/doc-good.txt.nocr >
> > tests/qapi-schema/doc-good.txt.nocr.stamp; fi
> > syntax error at -e line 1, near "="
> > Execution of -e aborted due to compilation errors.
> > make: *** [Makefile.ninja:2555：tests/qapi-schema/doc-
> > good.txt.nocr.stamp] 错误 255
> > "C:/CI-Tools/msys64/mingw64/bin/python3.exe"
> > "C:/work/xemu/qemu/meson/meson.py" "--internal" "exe" "--capture"
> > "qemu-version.h" "--" "C:/CI-Tools/msys64/mingw64/bin/python3.exe"
> > "C:/work/xemu/qemu/scripts/qemu-version.py" "C:/work/xemu/qemu" ""
> > "5.1.50" && if test -e qemu-version.h; then printf '%s\n' qemu-version.h
> >> qemu-version.h.stamp; fi
> > "C:/CI-Tools/msys64/mingw64/bin/python3.exe"
> > "C:/work/xemu/qemu/meson/meson.py" "--internal" "exe" "--capture"
> > "tests/qapi-schema/doc-good.txt.nocr" "--" "perl" "-pe" "$x = chr 13;
> > s/$x$//" "tests/qapi-schema/doc-good.txt" && if test -e
> > tests/qapi-schema/doc-good.txt.nocr; then printf '%s\n'
> > tests/qapi-schema/doc-good.txt.nocr >
> > tests/qapi-schema/doc-good.txt.nocr.stamp; fi
> > syntax error at -e line 1, near "="
> > Execution of -e aborted due to compilation errors.
> > make: *** [Makefile.ninja:2555：tests/qapi-schema/doc-
> > good.txt.nocr.stamp] 错误 255
>
> I think I know what's going on, but it's easiest to just switch to
> Ninja.  I'll post patches next week.
>
> Paolo
>


--
         此致
礼
罗勇刚
Yours
    sincerely,
Yonggang Luo

[-- Attachment #2: Type: text/html, Size: 2841 bytes --]

(no subject)

[Wayne Li]

[-- Attachment #1: Type: text/plain, Size: 1536 bytes --]

Dear QEMU list members,

This will kind of be a repost but I'd like to post my question again
because I've gained some more knowledge that makes me feel that my question
would be easier to answer.  So we developed a custom-made QEMU VM that
emulates a custom machine that has an e5500 processor.  I'm running this VM
on a T4240-RDB board which has an e6500 processor and I'm trying to get the
VM running with KVM enabled.  The problem I'm having is the program counter
refuses to increment at all.  It just stays at the address 0xFFFFFFFC.  On
a run without KVM enabled, the VM will also start executing at this same
address but the program counter beings to increment immediately.  I know
this is a custom QEMU VM and maybe some of the startup stuff we do could be
causing problems, but what could possibly stop the program counter from
incrementing altogether?

Also, I do have another side question.  When running with KVM enabled, I
see the kernel-level ioctl call KVM_RUN running and then returning over and
over again (by the way before the VM kinda grinds to a halt I only see QEMU
make the KVM_RUN call twice, but the kernel-level ioctl function is being
called over and over again for some reason).  And each time the KVM_RUN
call returns, the return-from-interrupt takes the VM to the address
0xFFFFFFFC.  What is the KVM_RUN ioctl call used for?  Why is it being
called over and over again?  Maybe if I understood this better I'd be able
to figure out what's stopping my program counter from incrementing.

-Thanks, Wayne Li

[-- Attachment #2: Type: text/html, Size: 1669 bytes --]

Re:

[Peter Maydell]

On Thu, 20 Feb 2020 at 05:41, Wayne Li <waynli329@gmail.com> wrote:
> Also, I do have another side question.  When running with KVM enabled, I
>see the kernel-level ioctl call KVM_RUN running and then returning over
>and over again (by the way before the VM kinda grinds to a halt I only see
>QEMU make the KVM_RUN call twice, but the kernel-level ioctl function
>is being called over and over again for some reason).  And each time the
>KVM_RUN call returns, the return-from-interrupt takes the VM to the
>address 0xFFFFFFFC.  What is the KVM_RUN ioctl call used for?  Why
>is it being called over and over again?  Maybe if I understood this better
>I'd be able to figure out what's stopping my program counter from incrementing.

KVM_RUN is the ioctl which QEMU uses to tell the kernel "hey, please
start running the guest". The kernel will not return control to QEMU
(ie the syscall will not return) until something happens that needs
QEMU's intervention, of which the main one is "guest made a device
access that QEMU must handle". (You can see this run loop in
accel/kvm/kvm-all.c:kvm_cpu_exec()). So in normal operation,
QEMU will do a bunch of setup, and then call KVM_RUN, which
will cause the guest to run, probably for quite a long time. The
ioctl will return when the guest does some IO a QEMU-provided
device, and QEMU will then do that device emulation, set up the
kvm_run struct fields to hold the results of the device access,
and call KVM_RUN again. The cycle continues like this until the
VM is shut down. If the guest goes into an infinite loop, you
should expect that KVM_RUN will never return, as there's never
any need for the kernel to ask QEMU to do anything.

Also important to note: before we call KVM_RUN we push
the CPU register state up to the kernel (using various arch-specific
ioctls), and after that the 'live copy' of the data is in the kernel,
and values in the CPU state struct in QEMU are stale. We only
get the up to date data out of the kernel when we need it, by
calling kvm_cpu_synchronize_state(). So if your 0xfffffffc value
comes from the CPU state struct and you're reading it at a
point before the state has been synchronized back from the
kernel it's not going to be the actual PC value.

The KVM kernel API is comparatively well documented at
https://www.kernel.org/doc/html/latest/virt/kvm/api.html
though the section on KVM_RUN is pretty weak.

thanks
-- PMM

Re:

[Wayne Li]

[-- Attachment #1: Type: text/plain, Size: 3111 bytes --]

Thanks for the KVM_RUN explanation, that makes a lot of sense.  Though I'm
pretty sure I'm getting the live program counter value because I use the
"info registers" command in QEMU monitor and that calls
kvm_cpu_synchronize_state().  And also to be more sure, I added a few
assembly instructions into the kernel code that stored a value that
constantly incremented and the program counter into two general purpose
registers.  I was able to see both of these in QEMU monitor so the program
counter must actually be stuck at 0xfffffffc.

On Thu, Feb 20, 2020 at 3:57 AM Peter Maydell <peter.maydell@linaro.org>
wrote:

> On Thu, 20 Feb 2020 at 05:41, Wayne Li <waynli329@gmail.com> wrote:
> > Also, I do have another side question.  When running with KVM enabled, I
> >see the kernel-level ioctl call KVM_RUN running and then returning over
> >and over again (by the way before the VM kinda grinds to a halt I only see
> >QEMU make the KVM_RUN call twice, but the kernel-level ioctl function
> >is being called over and over again for some reason).  And each time the
> >KVM_RUN call returns, the return-from-interrupt takes the VM to the
> >address 0xFFFFFFFC.  What is the KVM_RUN ioctl call used for?  Why
> >is it being called over and over again?  Maybe if I understood this better
> >I'd be able to figure out what's stopping my program counter from
> incrementing.
>
> KVM_RUN is the ioctl which QEMU uses to tell the kernel "hey, please
> start running the guest". The kernel will not return control to QEMU
> (ie the syscall will not return) until something happens that needs
> QEMU's intervention, of which the main one is "guest made a device
> access that QEMU must handle". (You can see this run loop in
> accel/kvm/kvm-all.c:kvm_cpu_exec()). So in normal operation,
> QEMU will do a bunch of setup, and then call KVM_RUN, which
> will cause the guest to run, probably for quite a long time. The
> ioctl will return when the guest does some IO a QEMU-provided
> device, and QEMU will then do that device emulation, set up the
> kvm_run struct fields to hold the results of the device access,
> and call KVM_RUN again. The cycle continues like this until the
> VM is shut down. If the guest goes into an infinite loop, you
> should expect that KVM_RUN will never return, as there's never
> any need for the kernel to ask QEMU to do anything.
>
> Also important to note: before we call KVM_RUN we push
> the CPU register state up to the kernel (using various arch-specific
> ioctls), and after that the 'live copy' of the data is in the kernel,
> and values in the CPU state struct in QEMU are stale. We only
> get the up to date data out of the kernel when we need it, by
> calling kvm_cpu_synchronize_state(). So if your 0xfffffffc value
> comes from the CPU state struct and you're reading it at a
> point before the state has been synchronized back from the
> kernel it's not going to be the actual PC value.
>
> The KVM kernel API is comparatively well documented at
> https://www.kernel.org/doc/html/latest/virt/kvm/api.html
> though the section on KVM_RUN is pretty weak.
>
> thanks
> -- PMM
>

[-- Attachment #2: Type: text/html, Size: 3811 bytes --]