Re: [PATCH v3A 1/6] target/i386: add support for FRED in CPUID enumeration

On Fri, Dec 22, 2023 at 03:34:02PM +0800, Zhao Liu wrote: > Date: Fri, 22 Dec 2023 15:34:02 +0800 > From: Zhao Liu > Subject: Re: [PATCH v3A 1/6] target/i386: add support for FRED in CPUID > enumeration > > On Thu, Dec 21, 2023 at 07:03:36PM -0800, Xin Li wrote: > > Date: Thu, 21 Dec 2023 19:03:

Re: [PATCH 23/24] exec/cpu-all: Extract page-protection definitions to page-prot-common.h

On Tue Dec 12, 2023 at 7:20 AM AEST, Philippe Mathieu-Daudé wrote: > Extract page-protection definitions from "exec/cpu-all.h" > to "exec/page-prot-common.h". > > The list of files requiring the new header was generated > using: > > $ git grep -wE \ > 'PAGE_(READ|WRITE|EXEC|BITS|VALID|ANON|RESERV

RE: [PATCH v3A 1/6] target/i386: add support for FRED in CPUID enumeration

> > > NULL, NULL, NULL, NULL, @@ -1552,6 +1552,14 @@ static > > > FeatureDep feature_dependencies[] = { > > > .from = { FEAT_VMX_SECONDARY_CTLS, > VMX_SECONDARY_EXEC_ENABLE_USER_WAIT_PAUSE }, > > > .to = { FEAT_7_0_ECX, CPUID_7_0_ECX_WAITPKG }, > > >

Re: [PATCH v3A 1/6] target/i386: add support for FRED in CPUID enumeration

On Fri, Dec 22, 2023 at 08:24:52AM +, Li, Xin3 wrote: > Date: Fri, 22 Dec 2023 08:24:52 + > From: "Li, Xin3" > Subject: RE: [PATCH v3A 1/6] target/i386: add support for FRED in CPUID > enumeration > > > > > > NULL, NULL, NULL, NULL, @@ -1552,6 +1552,14 @@ static > > > > Fea

[PATCH v2 2/4] hw/cxl/device: read from register values in mdev_reg_read()

In the current mdev_reg_read() implementation, it consistently returns that the Media Status is Ready (01b). This was fine until commit 25a52959f99d ("hw/cxl: Add support for device sanitation") because the media was presumed to be ready. However, as per the CXL 3.0 spec "8.2.9.8.5.1 Sanitize (Opc

[PATCH v2 1/4] hw/cxl: fix build error in cxl_type3_stubs.c

Fix build errors in cxl_type3_stubs.c due to a the incorrect definition of the qmp_cxl_{add,release}_dynamic_capacity functions. Signed-off-by: Hyeonggon Yoo <42.hye...@gmail.com> --- hw/mem/cxl_type3_stubs.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/hw/mem/cxl_type3

[PATCH v2 0/4] A Followup for "QEMU: CXL mailbox rework and features (Part 1)"

v1: https://lore.kernel.org/qemu-devel/20231127105830.2104954-1-42.hye...@gmail.com Changes from v1: - Added patch 1 that fixes a build failure in Jonathan's tree. - Added patch 3, as (partially) suggested by Davidlohr Buseo. One difference is that I dropped sanitize_running(), beca

[PATCH v2 4/4] hw/cxl/events: discard all event records during sanitation

Per spec 8.2.9.9.5.1 Sanitize (Opcode 4400h), sanitize command should delete all event logs. Introduce cxl_discard_all_event_logs() and call this in __do_sanitization(). Signed-off-by: Hyeonggon Yoo <42.hye...@gmail.com> --- hw/cxl/cxl-events.c | 13 + hw/cxl/cxl-mailbox-utils

[PATCH v2 3/4] hw/cxl/mbox: replace sanitize_running() with cxl_dev_media_disabled()

The spec states that reads/writes should have no effect and a part of commands should be ignored when the media is disabled, not when the sanitize command is running. Introduce cxl_dev_media_disabled() to check if the media is disabled and replace sanitize_running() with it. Make sure that the me

Re: [PATCH v2] target/i386: Fix physical address truncation

On Thu, Dec 21, 2023 at 10:33 PM Richard Henderson wrote: > > On 12/22/23 02:49, Michael Brown wrote: > > The address translation logic in get_physical_address() will currently > > truncate physical addresses to 32 bits unless long mode is enabled. > > This is incorrect when using physical address

Re: [PATCH v3 2/6] target/i386: mark CR4.FRED not reserved

On Wed, Nov 08, 2023 at 11:20:08PM -0800, Xin Li wrote: > Date: Wed, 8 Nov 2023 23:20:08 -0800 > From: Xin Li > Subject: [PATCH v3 2/6] target/i386: mark CR4.FRED not reserved > X-Mailer: git-send-email 2.42.0 > > The CR4.FRED bit, i.e., CR4[32], is no longer a reserved bit when FRED > is expose

Re: [PATCH v4 01/13] vdpa: add VhostVDPAShared

QE tested this series v4 with regression tests. It has fixed the qemu core issues that hit last time.And everything works fine. Tested-by: Lei Yang On Fri, Dec 22, 2023 at 1:43 AM Eugenio Pérez wrote: > > It will hold properties shared among all vhost_vdpa instances associated > with of the

[PATCH v2 1/1] dump: Fix HMP dump-guest-memory -z without -R

-z without -R has no effect: the dump format remains @elf. Fix the logic error so it becomes @kdump-zlib. Fixes: e6549197f7ed (dump: Add command interface for kdump-raw formats) Fixes: CID 1523841 Signed-off-by: Markus Armbruster Reviewed-by: Stephen Brennan Reviewed-by: Marc-André Lureau ---

[PATCH v2 0/1] dump: Fix issues flagged by Coverity

v2: * PATCH 1 superseded by commit 95a40c44501 (dump: Add close fd on error return to avoid resource leak) * PATCH 2 fell through the cracks; reposting unchanged Markus Armbruster (1): dump: Fix HMP dump-guest-memory -z without -R dump/dump-hmp-cmds.c | 2 +- 1 file changed, 1 insertion(+),

Re: [v2 1/2] qapi/virtio: Add feature and status bits for x-query-virtio-status

Hyman Huang writes: > This patch allows to display feature and status bits in > virtio-status. > > Applications could find it helpful to compare status and features > that are numeric encoded. For example, an upper application could > use the features (encoded as a number) in the output of "ovs-v

[PATCH] configure: use a native non-cross compiler for linux-user

Commit c2118e9e1ab ("configure: don't try a "native" cross for linux-user", 2023-11-23) sought to avoid issues with using the native compiler with a cross-endian or cross-bitness setup. However, in doing so it ended up requiring a cross compiler setup (and most likely a slow compiler setup) even w

Re: [PULL 20/47] backends/iommufd: Introduce the iommufd object

Hi Cédric, On 12/21/23 22:23, Cédric Le Goater wrote: > On 12/21/23 18:14, Eric Auger wrote: >> Hi Cédric, >> >> On 12/21/23 17:00, Cédric Le Goater wrote: >>> [ ... ] >>> >>> +static void iommufd_backend_init(Object *obj) +{ +    IOMMUFDBackend *be = IOMMUFD_BACKEND(obj); + >>

VIRTIO_GPU_CMD_SUBMIT_3D error feedback?

Hi guys, Is there a way for a client-side driver to know if a VirGL command fails? The function virgl_renderer_submit_cmd() does return an error if one of the commands fail, but virgl_cmd_submit_3d() ignores the return code. It looks like VIRTIO_GPU_CMD_SUBMIT_3D would return a success, even

Re: hw: Audit of qdev properties with same name but different types

Philippe Mathieu-Daudé writes: > Hi, > > I just did an audit of QDev properties from different > models sharing the same name, but of different types > (as of v8.2.0-rc1). > > Nothing wrong, but some having the same meaning could > use the same type :) Yes. > Just sharing: > > --- >2 addr >

Re: [PATCH for-9.0] qapi: Add 'recurse-children' option to qom-list

Alberto Garcia writes: > This allows returning a tree of all object properties under a given > path, in a way similar to scripts/qmp/qom-tree. Use case? We already have that script, and also HMP info qom-tree. > Signed-off-by: Alberto Garcia > --- > qapi/qom.json | 10 +- > qom/

Re: [RFC PATCH v3 06/30] migration/ram: Introduce 'fixed-ram' migration capability

Fabiano Rosas writes: > Add a new migration capability 'fixed-ram'. > > The core of the feature is to ensure that each RAM page has a specific > offset in the resulting migration stream. The reasons why we'd want > such behavior are: > > - The resulting file will have a bounded size, since pages

Re: [PULL 20/47] backends/iommufd: Introduce the iommufd object

On 12/22/23 11:09, Eric Auger wrote: Hi Cédric, On 12/21/23 22:23, Cédric Le Goater wrote: On 12/21/23 18:14, Eric Auger wrote: Hi Cédric, On 12/21/23 17:00, Cédric Le Goater wrote: [ ... ] +static void iommufd_backend_init(Object *obj) +{ +    IOMMUFDBackend *be = IOMMUFD_BACKEND(obj); +

Re: [RFC PATCH v3 23/30] migration: Add direct-io parameter

Fabiano Rosas writes: > Add the direct-io migration parameter that tells the migration code to > use O_DIRECT when opening the migration stream file whenever possible. Why is that useful? > This is currently only used with fixed-ram migration for the multifd > channels that transfer the RAM pag

[RFC PATCH] meson.build: report graphics backends

To enable accelerated VirtIO GPUs for the guest we need the rendering support on the host but currently it's not reported in the configuration summary. Add a graphics backend section and report the status of the VirGL and Rutabaga support libraries. Signed-off-by: Alex Bennée --- meson.build | 6

Re: [PATCH 11/16] target/riscv: move 'cbom_blocksize' to riscv_cpu_properties[]

On 12/22/23 01:40, Richard Henderson wrote: On 12/22/23 04:51, Daniel Henrique Barboza wrote: +const PropertyInfo prop_cbom_blksize = { static?  Same for cboz in the next patch. Same in every other patch where I added a PropertyInfo it seems. I'll fix it in v2. Thanks, Daniel r~

Re: [PATCH V6 03/14] cpus: stop vm in suspended runstate

Steve Sistare writes: > Currently, a vm in the suspended state is not completely stopped. The VCPUs > have been paused, but the cpu clock still runs, and runstate notifiers for > the transition to stopped have not been called. This causes problems for > live migration. Stale cpu timers_state i

[PATCH v2 13/16] target/riscv: remove riscv_cpu_options[]

The array is empty and can be removed. Signed-off-by: Daniel Henrique Barboza --- target/riscv/cpu.c | 5 - target/riscv/cpu.h | 1 - target/riscv/kvm/kvm-cpu.c | 9 - target/riscv/tcg/tcg-cpu.c | 4 4 files changed, 19 deletions(-) diff --git a/target/riscv/cpu

[PATCH v2 09/16] target/riscv: move 'elen' to riscv_cpu_properties[]

Do the same thing we did with 'vlen' in the previous patch with 'elen'. Signed-off-by: Daniel Henrique Barboza --- target/riscv/cpu.c | 52 -- target/riscv/tcg/tcg-cpu.c | 5 2 files changed, 50 insertions(+), 7 deletions(-) diff --git a/target/

[PATCH v2 00/16] target/riscv: deprecate riscv_cpu_options[]

Hi, This new version fixes all instances of 'const PropertyInfo' added, changing it to 'static const PropertyInfo', like suggested by Richard in v1. Patches based on Alistair's riscv-to-apply.next. Series is also found here: https://gitlab.com/danielhb/qemu/-/tree/fix_cpu_opts_v2 Changes from v

[PATCH v2 10/16] target/riscv: create finalize_features() for KVM

To turn cbom_blocksize and cboz_blocksize into class properties we need KVM specific changes. KVM is creating its own version of these options with a customized setter() that prevents users from picking an invalid value during init() time. This comes at the cost of duplicating each option that KVM

[PATCH v2 01/16] target/riscv/cpu_cfg.h: remove user_spec and bext_spec

They aren't being used. Signed-off-by: Daniel Henrique Barboza --- target/riscv/cpu_cfg.h | 2 -- 1 file changed, 2 deletions(-) diff --git a/target/riscv/cpu_cfg.h b/target/riscv/cpu_cfg.h index f4605fb190..c67a8731d3 100644 --- a/target/riscv/cpu_cfg.h +++ b/target/riscv/cpu_cfg.h @@ -136,8 +

[PATCH v2 14/16] target/riscv/cpu.c: move 'mvendorid' to riscv_cpu_properties[]

Keep all class properties in riscv_cpu_properties[]. Signed-off-by: Daniel Henrique Barboza --- target/riscv/cpu.c | 69 +- 1 file changed, 37 insertions(+), 32 deletions(-) diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c index 7b1cc5d0c9..260932

[PATCH v2 07/16] target/riscv: rework 'vext_spec'

The same rework did in 'priv_spec' is done for 'vext_spec'. This time is simpler, since we only accept one value ("v1.0") and we'll always have env->vext_ver set to VEXT_VERSION_1_00_0, thus we don't need helpers to convert string to 'vext_ver' back and forth like we needed for 'priv_spec'. Signed

[PATCH v2 12/16] target/riscv: move 'cboz_blocksize' to riscv_cpu_properties[]

Do the same we did with 'cbom_blocksize' in the previous patch. Remove the now unused kvm_cpu_set_cbomz_blksize() setter. Signed-off-by: Daniel Henrique Barboza --- target/riscv/cpu.c | 45 +- target/riscv/kvm/kvm-cpu.c | 28

[PATCH v2 15/16] target/riscv/cpu.c: move 'mimpid' to riscv_cpu_properties[]

Keep all class properties in riscv_cpu_properties[]. Signed-off-by: Daniel Henrique Barboza --- target/riscv/cpu.c | 68 -- 1 file changed, 36 insertions(+), 32 deletions(-) diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c index 260932e117..613e8d

[PATCH v2 04/16] target/riscv: move 'mmu' to riscv_cpu_properties[]

Commit 7f0bdfb5bfc ("target/riscv/cpu.c: remove cfg setup from riscv_cpu_init()") already did some of the work by making some cpu_init() functions to explictly enable their own 'mmu' default. The generic CPUs didn't get update by that commit, so they are still relying on the defaults set by the 'm

[PATCH v2 16/16] target/riscv/cpu.c: move 'marchid' to riscv_cpu_properties[]

Keep all class properties in riscv_cpu_properties[]. Signed-off-by: Daniel Henrique Barboza --- target/riscv/cpu.c | 110 +++-- 1 file changed, 57 insertions(+), 53 deletions(-) diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c index 613e8d5ddc..d2400f

[PATCH v2 03/16] target/riscv: make riscv_cpu_is_generic() public

We'll use this function in target/riscv/cpu.c to implement setters that won't allow vendor CPU options to be changed. Signed-off-by: Daniel Henrique Barboza --- target/riscv/cpu.c | 5 + target/riscv/cpu.h | 1 + target/riscv/tcg/tcg-cpu.c | 5 - 3 files changed, 6 insert

[PATCH v2 06/16] target/riscv: rework 'priv_spec'

'priv_spec' and 'vext_spec' are two string options used as a fancy way of setting integers in the CPU state (cpu->env.priv_ver and cpu->env.vext_ver). It requires us to deal with string parsing and to store them in cpu_cfg. We must support these string options, but we don't need to store them. We

[PATCH v2 02/16] target/riscv: move 'pmu-mask' and 'pmu-num' to riscv_cpu_properties[]

Every property in riscv_cpu_options[] will be migrated to riscv_cpu_properties[]. This will make their default values init earlier, allowing cpu_init() functions to overwrite them. We'll also implement common getters and setters that both accelerators will use, allowing them to share validations th

[PATCH v2 08/16] target/riscv: move 'vlen' to riscv_cpu_properties[]

Turning 'vlen' into a class property will allow its default value to be overwritten by cpu_init() later on, solving the issue we have now where CPU specific settings are getting overwritten by the default. For 'vlen', 'elen' and the blocksize options we need a way of tracking if the user set a val

[PATCH v2 05/16] target/riscv: move 'pmp' to riscv_cpu_properties[]

Move 'pmp' to riscv_cpu_properties[], creating a new setter() for it that forbids 'pmp' to be changed in vendor CPUs, like we did with the 'mmu' option. We'll also have to manually set 'pmp = true' to generic CPUs that were still relying on the previous default to set it. Signed-off-by: Daniel He

[PATCH v2 11/16] target/riscv: move 'cbom_blocksize' to riscv_cpu_properties[]

After adding a KVM finalize() implementation, turn cbom_blocksize into a class property. Follow the same design we used with 'vlen' and 'elen'. The duplicated 'cbom_blocksize' KVM property can be removed from kvm_riscv_add_cpu_user_properties(). Signed-off-by: Daniel Henrique Barboza --- target

Re: [PATCH v5 1/2] qom: new object to associate device to numa node

writes: > From: Ankit Agrawal > > NVIDIA GPU's support MIG (Mult-Instance GPUs) feature [1], which allows > partitioning of the GPU device resources (including device memory) into > several (upto 8) isolated instances. Each of the partitioned memory needs > a dedicated NUMA node to operate. The

Re: [RFC PATCH 01/11] acpi: hmp/qmp: Add hmp/qmp support for system_sleep

"Annie.li" writes: > Hi Markus, > > On 12/5/2023 3:34 PM, Markus Armbruster wrote: >> You neglected to cc: QAPI schema maintainers. I found it by chance. >> Next time :) > Yep, should have cc to the maintainers. >> >> Annie Li writes: >> >>> Following hmp/qmp commands are implemented for pressi

Re: [PATCH V8 02/12] cpus: stop vm in suspended runstate

Steven Sistare writes: > FYI for Markus and Blake. No change since V6 and V7. I accidentally replied to v6 instead of here. Sorry for the inconvenience!

Re: [PATCH v7 0/4] compare machine type compat_props

Something odd is going on here. Your cover letter and PATCH 4 arrived here with Content-Type: text/plain; charset=UTF-8 Good. PATCH 2: Content-Type: text/plain; charset="US-ASCII"; x-default=true PATCH 1 and 3: Content-Type: text/plain; charset=N git-am chokes on that: erro

Re: [PATCH v3 52/70] i386/tdx: handle TDG.VP.VMCALL

On Fri, Dec 22, 2023 at 11:14:12AM +0800, Xiaoyao Li wrote: > On 12/21/2023 7:05 PM, Daniel P. Berrangé wrote: > > On Wed, Nov 15, 2023 at 02:15:01AM -0500, Xiaoyao Li wrote: > > > From: Isaku Yamahata > > > > > > For GetQuote, delegate a request to Quote Generation Service. > > > Add property "q

Re: [PATCH 37/40] plugins: add an API to read registers

Akihiko Odaki writes: > On 2023/12/21 19:38, Alex Bennée wrote: >> We can only request a list of registers once the vCPU has been >> initialised so the user needs to use either call the get function on >> vCPU initialisation or during the translation phase. >> We don't expose the reg number to th

[PULL 02/11] next-cube.c: don't pulse SCSI DMA IRQ upon reception of FLUSH command

From: Mark Cave-Ayland Normally a DMA FLUSH command is used to ensure that data is completely written to the device and/or memory, so remove the pulse of the SCSI DMA IRQ if a DMA FLUSH command is received. This enables the NeXT ROM monitor to start to load from a SCSI disk. Signed-off-by: Mark

[PULL 10/11] next-cube.c: remove val and size arguments from nextscr2_write()

From: Mark Cave-Ayland These are now redundant with the scr2 and old_scr2 fields in NeXTPC. Rename the function from nextscr2_write() to next_scr2_rtc_update() to better reflect its purpose. At the same time replace the manual bit manipulation with the extract32() and deposit32() functions. Sign

[PULL 06/11] next-cube.c: move static led variable to NeXTPC

From: Mark Cave-Ayland The state of the led is stored in the SCR2 register which is part of the NeXTPC device. Note that this is a migration break for the NeXTPC device, but as nothing will currently boot then we simply bump the migration version for now. Signed-off-by: Mark Cave-Ayland Review

[PULL 07/11] next-cube.c: move static phase variable to NextRtc

From: Mark Cave-Ayland The phase variable represents part of the state machine used to clock data out of the NextRtc device. Note that this is a migration break for the NeXTRtc struct, but as nothing will currently boot then we simply bump the migration version for now. Signed-off-by: Mark Cave

[PULL 09/11] next-cube.c: move LED logic to new next_scr2_led_update() function

From: Mark Cave-Ayland Ensure that the LED status is updated by calling next_scr2_led_update() whenever the SC2 register is written. Signed-off-by: Mark Cave-Ayland Reviewed-by: Thomas Huth Message-ID: <20231220131641.592826-10-mark.cave-ayl...@ilande.co.uk> Signed-off-by: Thomas Huth --- hw

[PULL 08/11] next-cube.c: move static old_scr2 variable to NeXTPC

From: Mark Cave-Ayland Move the old_scr2 variable to NeXTPC so that the old SCR2 register state is stored along with the current SCR2 state. Since the SCR2 register is 32-bits wide, convert old_scr2 to uint32_t and update the SCR2 register access code to allow unaligned writes. Note that this i

[PULL 05/11] next-cube.c: update and improve dma_ops

From: Mark Cave-Ayland Rename dma_ops to next_dma_ops and the read/write functions to next_dma_read() and next_dma_write() respectively, mark next_dma_ops as DEVICE_BIG_ENDIAN and also improve the consistency of the val variable in next_dma_read() and next_dma_write(). Signed-off-by: Mark Cave-A

[PULL 11/11] next-cube.c: move machine MemoryRegions into NeXTState

From: Mark Cave-Ayland These static memory regions are contained within the machine and do not need to be dynamically allocated. Signed-off-by: Mark Cave-Ayland Reviewed-by: Thomas Huth Message-ID: <20231220131641.592826-12-mark.cave-ayl...@ilande.co.uk> Signed-off-by: Thomas Huth --- hw/m68

[PULL 00/11] m68k next-cube patches

The following changes since commit 191710c221f65b1542f6ea7fa4d30dde6e134fd7: Merge tag 'pull-request-2023-12-20' of https://gitlab.com/thuth/qemu into staging (2023-12-20 09:40:16 -0500) are available in the Git repository at: https://gitlab.com/huth/qemu.git tags/m68k-pull-2023-12-22 for

[PULL 03/11] next-cube.c: update mmio_ops to properly use modern memory API

From: Mark Cave-Ayland The old QEMU memory accessors used in the original NextCube patch series had separate functions for 1, 2 and 4 byte accessors. When the series was finally merged a simple wrapper function was written to dispatch the memory accesses using the original functions. Convert mmi

[PULL 04/11] next-cube.c: update scr_ops to properly use modern memory API

From: Mark Cave-Ayland The old QEMU memory accessors used in the original NextCube patch series had separate functions for 1, 2 and 4 byte accessors. When the series was finally merged a simple wrapper function was written to dispatch the memory accesses using the original functions. Convert scr

[PULL 01/11] next-cube.c: add dummy Ethernet register to allow diagnostic to timeout

From: Mark Cave-Ayland Add a dummy register at address 0x6000 in the MMIO memory region to allow the initial diagnostic test to timeout rather than getting stuck in a loop continuously writing "en_write: tx not ready" to the console. Signed-off-by: Mark Cave-Ayland Tested-by: Thomas Huth Messa

Re: [RFC PATCH 0/4] target/riscv/kvm: QEMU support for KVM Guest Debug on RISC-V

Hi, It seems that we still need the kernel KVM side to be sorted out first [1], so I believe we should wait a bit until we can review this RFC. Otherwise we might risk reviewing something that has to be changed later. [1] https://lore.kernel.org/kvm/20231221095002.7404-1-duc...@eswincomputing.c

Re: [PATCH 00/35] target/arm: Implement emulation of nested virtualization

Hi Peter, > On 18 Dec 2023, at 10:32, Peter Maydell wrote: > > This patchset adds support for emulating the Arm architectural features > FEAT_NV and FEAT_NV2 which allow nested virtualization, i.e. where a > hypervisor can run a guest which thinks it is running at EL2. > > Nominally FEAT_NV is

[RFC] Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2051

Hi, this patch fixes a bug: https://gitlab.com/qemu-project/qemu/-/issues/2051   From: Elen Avan Date: Fri, 22 Dec 2023 14:39:48 + Subject: [RFC] Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2051   Signed-off-by: Elen Avan ---  include/ui/rect.h | 2 +-  1 file changed, 1 insertio

Re: [v2 1/2] qapi/virtio: Add feature and status bits for x-query-virtio-status

Sure. of course. I'll do that next week. While v3 would be a single patch that only contains the first commit. Thanks, Yong On Fri, Dec 22, 2023 at 5:54 PM Markus Armbruster wrote: > Hyman Huang writes: > > > This patch allows to display feature and status bits in > > virtio-status. > > > > Ap

Re: [PATCH V6 03/14] cpus: stop vm in suspended runstate

On 12/22/2023 7:20 AM, Markus Armbruster wrote: > Steve Sistare writes: > >> Currently, a vm in the suspended state is not completely stopped. The VCPUs >> have been paused, but the cpu clock still runs, and runstate notifiers for >> the transition to stopped have not been called. This causes p

Re: [PATCH v2] target/i386: Fix physical address truncation

On Fri, Dec 22, 2023 at 10:04 AM Paolo Bonzini wrote: > > If the extension is not needed, then the a20 mask isn't either. > > I think it is. The extension is not needed because the masking is > applied by either TCG (e.g. in gen_lea_v_seg_dest or gen_add_A0_im) or > mmu_translate(); but the a20 ma

Re: [PULL 0/2] loongarch-to-apply queue

Applied, thanks. Please update the changelog at https://wiki.qemu.org/ChangeLog/9.0 for any user-visible changes. signature.asc Description: PGP signature

Re: [PULL v2 00/33] Block layer patches

Applied, thanks. Please update the changelog at https://wiki.qemu.org/ChangeLog/9.0 for any user-visible changes. signature.asc Description: PGP signature

Re: [PATCH v2] target/i386: Fix physical address truncation

On Fri, Dec 22, 2023 at 5:16 PM Paolo Bonzini wrote: > > On Fri, Dec 22, 2023 at 10:04 AM Paolo Bonzini wrote: > > > If the extension is not needed, then the a20 mask isn't either. > > > > I think it is. The extension is not needed because the masking is > > applied by either TCG (e.g. in gen_lea

Re: [RFC PATCH 4/5] virtio: Add VMState for early load

On Mon, Sep 18, 2023 at 6:51 AM Yajun Wu wrote: > > Define new virtio device vmstate for early save/load (happens in > LM setup stage). Same as original vmstate, except: > > In LM setup phase of the destination VM, the guest memory has not > been synchronized yet. To address this, a flag has been

Re: [PATCH 3/6] target/riscv: Add pointer masking tb flags

Hi Richard, Thanks for the suggestion. If it's ok to consume another bit(3 bits total) for Pointer Masking flags, I'll do it. >so that the translator can see the true width of the address I guess I'll need a helper to calculate the exact number of bits to shift(0, 7 or 16) based on those 2 extract

[PATCH 0/5] target/i386: Fix physical address masking bugs

The address translation logic in get_physical_address() will currently truncate physical addresses to 32 bits unless long mode is enabled. This is incorrect when using physical address extensions (PAE) outside of long mode, with the result that a 32-bit operating system using PAE to access memory a

[PATCH 4/5] target/i386: remove unnecessary/wrong application of the A20 mask

If ptw_translate() does a MMU_PHYS_IDX access, the A20 mask is already applied in get_physical_address(), which is called via probe_access_full() and x86_cpu_tlb_fill(). If ptw_translate() on the other hand does a MMU_NESTED_IDX access, the A20 mask must not be applied to the address that is looke

[PATCH 5/5] target/i386: leave the A20 bit set in the final NPT walk

The A20 mask is only applied to the final memory access. Nested page tables are always walked with the raw guest-physical address. Unlike the previous patch, in this one the masking must be kept, but it was done too early. Cc: qemu-sta...@nongnu.org Fixes: 4a1e9d4d11c ("target/i386: Use atomic o

[PATCH 1/5] target/i386: mask high bits of CR3 in 32-bit mode

CR3 bits 63:32 are ignored in 32-bit mode (either legacy 2-level paging or PAE paging). Do this in mmu_translate() to remove the last where get_physical_address() meaningfully drops the high bits of the address. Cc: qemu-sta...@nongnu.org Suggested-by: Richard Henderson Fixes: 4a1e9d4d11c ("targ

[PATCH 2/5] target/i386: check validity of VMCB addresses

MSR_VM_HSAVE_PA bits 0-11 are reserved, as are the bits above the maximum physical address width of the processor. Setting them to 1 causes a #GP (see "15.30.4 VM_HSAVE_PA MSR" in the AMD manual). The same is true of VMCB addresses passed to VMRUN/VMLOAD/VMSAVE, even though the manual is not clea

[PATCH 3/5] target/i386: Fix physical address truncation

The address translation logic in get_physical_address() will currently truncate physical addresses to 32 bits unless long mode is enabled. This is incorrect when using physical address extensions (PAE) outside of long mode, with the result that a 32-bit operating system using PAE to access memory a

[PATCH 02/22] target/i386: speedup JO/SETO after MUL or IMUL

OF is equal to the carry flag, so use the same CCPrepare. Signed-off-by: Paolo Bonzini --- target/i386/tcg/translate.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/target/i386/tcg/translate.c b/target/i386/tcg/translate.c index 8fb80011a22..a16eb8d4008 100644 --- a/target/i386/tcg/tran

[PATCH 20/22] target/i386: adjust decoding of J operand

gen_jcc() has been changed to accept a relative offset since the new decoder was written. Adjust the J operand, which is meant to be used with jump instructions such as gen_jcc(), to not include the program counter and to not truncate the result, as both operations are now performed by common code

[PATCH 00/22] target/i386: first part of TCG changes for 9.0

The main things here are a bunch of cleanups to the common logic of the new decoder, some changes to translate.c that prepare for redoing one-byte opcodes in the new framework, and the implementation of the CMPccXADD instruction that is new in Sierra Forest processors. These are all relatively inn

[PATCH 21/22] target/i386: introduce flags writeback mechanism

ALU instructions can write to both memory and flags. If the CC_SRC* and CC_DST locations have been written already when a memory access causes a fault, the value in CC_SRC* and CC_DST might be interpreted with the wrong CC_OP (the one that is in effect before the instruction. Besides just using t

[PATCH 01/22] target/i386: optimize computation of JL and JLE from flags

Take advantage of the fact that there can be no 1 bits between SF and OF. If they were adjacent, you could sum SF and get a carry only if SF was already set. Then the value of OF in the sum is the XOR of OF itself, the carry (which is SF) and 0 (the value of the OF bit in the addend): this is OF^S

[PATCH 03/22] target/i386: remove unnecessary arguments from raise_interrupt

is_int is always 1, and error_code is always zero. Signed-off-by: Paolo Bonzini --- target/i386/tcg/excp_helper.c | 7 +++ target/i386/tcg/helper-tcg.h | 3 +-- target/i386/tcg/misc_helper.c | 2 +- 3 files changed, 5 insertions(+), 7 deletions(-) diff --git a/target/i386/tcg/excp_helper.c

[PATCH 18/22] target/i386: prepare for implementation of STOS/SCAS in new decoder

Do not use gen_op, and pull the load from the accumulator into disas_insn. Signed-off-by: Paolo Bonzini --- target/i386/tcg/translate.c | 9 +++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/target/i386/tcg/translate.c b/target/i386/tcg/translate.c index edbad0ad746..c7d480

[PATCH 19/22] target/i386: move operand load and writeback out of gen_cmovcc1

Similar to gen_setcc1, make gen_cmovcc1 receive TCGv. This is more friendly to simultaneous implementation in the old and the new decoder. A small wart is that s->T0 of CMOV is currently the *second* argument (which would ordinarily be in T1). Therefore, the condition has to be inverted in order

[PATCH 10/22] target/i386: add X86_SPECIALs for MOVSX and MOVZX

Usually the registers are just moved into s->T0 without much care for their operand size. However, in some cases we can get more efficient code if the operand fetching logic syncs with the emission function on what is nicer. All the current uses are mostly demonstrative and only reduce the code i

[PATCH 14/22] target/i386: split eflags computation out of gen_compute_eflags

The new x86 decoder wants the gen_* functions to compute EFLAGS before writeback, which can be an issue for instructions with a memory destination such as ARPL or shifts. Extract code to compute the EFLAGS without clobbering CC_SRC, in case the memory write causes a fault. The flags writeback mec

[PATCH 22/22] target/i386: implement CMPccXADD

The main difficulty here is that a page fault when writing to the destination must not overwrite the flags. Therefore, the compute-flags helper must be called with a temporary destination instead of using gen_jcc1*. For simplicity, I am using an unconditional cmpxchg operation, that becomes a NOP

[PATCH 08/22] target/i386: avoid trunc and ext for MULX and RORX

Use _tl operations for 32-bit operands on 32-bit targets, and only go through trunc and extu ops for 64-bit targets. While the trunc/ext ops should be pretty much free after optimization, the optimizer also does not like having the same temporary used in multiple EBBs. Therefore it is nicer to not

[PATCH 05/22] target/i386: clean up cpu_cc_compute_all

cpu_cc_compute_all() has an argument that is always equal to CC_OP for historical reasons (dating back to commit a7812ae4123, "TCG variable type checking.", 2008-11-17, which added the argument to helper_cc_compute_all). It does not make sense for the argumnt to have any other value, so remove

[PATCH 16/22] target/i386: do not use s->tmp0 for jumps on ECX ==/!= 0

Create a new temporary, to ease the register allocator's work. Creation of the temporary is pushed into gen_ext_tl, which also allows NULL as the first parameter now. Signed-off-by: Paolo Bonzini --- target/i386/tcg/translate.c | 9 ++--- 1 file changed, 6 insertions(+), 3 deletions(-) dif

[PATCH 13/22] target/i386: do not clobber T0 on string operations

The new decoder would rather have the operand in T0 when expanding SCAS, rather than use R_EAX directly as gen_scas currently does. This makes SCAS more similar to CMP and SUB, in that CC_DST = T0 - T1. Signed-off-by: Paolo Bonzini --- target/i386/tcg/translate.c | 45 -

[PATCH 06/22] target/i386: document more deviations from the manual

Signed-off-by: Paolo Bonzini --- target/i386/tcg/decode-new.c.inc | 12 1 file changed, 12 insertions(+) diff --git a/target/i386/tcg/decode-new.c.inc b/target/i386/tcg/decode-new.c.inc index 2bdbb1bba0f..232c6a45c96 100644 --- a/target/i386/tcg/decode-new.c.inc +++ b/target/i386/tc

[PATCH 15/22] target/i386: do not use s->tmp4 for push

Just create a temporary for the occasion. Signed-off-by: Paolo Bonzini --- target/i386/tcg/translate.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/target/i386/tcg/translate.c b/target/i386/tcg/translate.c index b79c312465b..afe0fa6c65f 100644 --- a/target/i386/tcg/transla

[PATCH 12/22] target/i386: do not clobber A0 in POP translation

The new decoder likes to compute the address in A0 very early, so the gen_lea_v_seg in gen_pop_T0 would clobber the address of the memory operand. Instead use T0 since it is already available and will be overwritten immediately after. Reviewed-by: Richard Henderson Signed-off-by: Paolo Bonzini

[PATCH 07/22] target/i386: reimplement check for validity of LOCK prefix

The previous check erroneously allowed CMP to be modified with LOCK. Instead, tag explicitly the instructions that do support LOCK. Signed-off-by: Paolo Bonzini --- target/i386/tcg/decode-new.c.inc | 17 ++--- target/i386/tcg/decode-new.h | 3 +++ target/i386/tcg/emit.c.inc

[PATCH 11/22] target/i386: do not decode string source/destination into decode->mem

decode->mem is only used if one operand has has_ea == true. String operations will not use decode->mem and will load A0 on their own, because they are the only case of two memory operands in a single instruction. Signed-off-by: Paolo Bonzini --- target/i386/tcg/decode-new.c.inc | 20 ++-

[PATCH 04/22] target/i386: remove unnecessary truncations

gen_lea_v_seg (called by gen_add_A0_ds_seg) already zeroes any bits of s->A0 beyond s->aflag. It does so before summing the segment base and, if not in 64-bit mode, also after summing it. Signed-off-by: Paolo Bonzini --- target/i386/tcg/emit.c.inc | 4 +--- target/i386/tcg/translate.c | 2 --

[PATCH 09/22] target/i386: rename zext0/zext2 and make them closer to the manual

X86_SPECIAL_ZExtOp0 and X86_SPECIAL_ZExtOp2 are poorly named; they are a hack that is needed by scalar insertion and extraction instructions, and not really related to zero extension: for PEXTR the zero extension is done by the generation functions, for PINSR the high bits are not used at all and

  1   2   >