RE: [PATCH 1/3] qapi/net: Add new QMP command for COLO passthrough
> -Original Message- > From: Jason Wang > Sent: Tuesday, January 5, 2021 12:17 PM > To: Zhang, Chen ; qemu-dev de...@nongnu.org>; Eric Blake ; Dr. David Alan > Gilbert ; Markus Armbruster > Cc: Zhang Chen > Subject: Re: [PATCH 1/3] qapi/net: Add new QMP command for COLO > passthrough > > > On 2021/1/5 上午11:28, Zhang, Chen wrote: > > > >> -Original Message- > >> From: Jason Wang > >> Sent: Wednesday, December 30, 2020 11:57 AM > >> To: Zhang, Chen ; qemu-dev >> de...@nongnu.org>; Eric Blake ; Dr. David Alan > >> Gilbert ; Markus Armbruster > > >> Cc: Zhang Chen > >> Subject: Re: [PATCH 1/3] qapi/net: Add new QMP command for COLO > >> passthrough > >> > >> > >> On 2020/12/29 上午10:56, Zhang, Chen wrote: > I think we can start form COLO. To avoid QMP compatibility issues, > I would like to add the n tuple and wildcard support now. > >>> OK, I will do this job in next version. > >>> For the QMP compatibility issues, please give me a demo of what we > >>> want > >> to see, Like some existing commands. > >> > >> > >> I meant if we start from port and then want to add e.g n-tuple support. > >> Do we need to introduce another command? Or is there any > >> introspection that can let management layer know about this? > > OK, I will add the n-tuple support. > > It looks basic command are add/del connection, Do you think something > needs to be introduced? > > > It looks to me it's fine to start with them. > > > > For the management layer, I don't know the detail process of how to add > new Qemu command support for example libvirt. > > Maybe depend on libvirt community's plan? > > > So a question here, how COLO is being used now. Is it expected to be > managed by libvirt or not? Yes, they use libvirt to manage COLO. Currently, China CSP integrated COLO on edge computing product, they need change a small part of the code on libvirt, Most of COLO parameter use libvirt bypass mechanism direct input to Qemu. For our side, we focus on Qemu COLO code. Thanks Chen > > Thanks > > > > > > Thanks > > Chen > > > >> Thanks > >> > >> > >>> Thanks > >>> Chen > >>>
Re: [PATCH] hw/riscv: microchip_pfsoc: specify XIP image
+Alistair Francis
On Sat, Dec 19, 2020 at 8:24 AM Vitaly Wool wrote:
>
> Add command line parameter to microchip_pfsoc machine to be able
> to specify XIP kernel image file. To pass over XIP image file, it
> will be enough to run
>
> $ qemu-system-riscv64 -M microchip-icicle-kit,xipImage= ...
>
> Signed-off-by: Vitaly Wool
> ---
> hw/riscv/microchip_pfsoc.c | 42 +++---
> include/hw/riscv/microchip_pfsoc.h | 1 +
> 2 files changed, 39 insertions(+), 4 deletions(-)
>
> diff --git a/hw/riscv/microchip_pfsoc.c b/hw/riscv/microchip_pfsoc.c
> index e952b49e8c..04d81d52fe 100644
> --- a/hw/riscv/microchip_pfsoc.c
> +++ b/hw/riscv/microchip_pfsoc.c
> @@ -181,6 +181,7 @@ static void microchip_pfsoc_soc_instance_init(Object *obj)
> static void microchip_pfsoc_soc_realize(DeviceState *dev, Error **errp)
> {
> MachineState *ms = MACHINE(qdev_get_machine());
> +MicrochipIcicleKitState *mks = MICROCHIP_ICICLE_KIT_MACHINE(ms);
> MicrochipPFSoCState *s = MICROCHIP_PFSOC(dev);
> const struct MemmapEntry *memmap = microchip_pfsoc_memmap;
> MemoryRegion *system_memory = get_system_memory();
> @@ -415,10 +416,19 @@ static void microchip_pfsoc_soc_realize(DeviceState
> *dev, Error **errp)
> memmap[MICROCHIP_PFSOC_IOSCB].base);
>
> /* QSPI Flash */
> -memory_region_init_rom(qspi_xip_mem, OBJECT(dev),
I believe we only need to change this to memory_region_init_ram(),
then use the device loader the load the XIP image into this space. The
remove the need to introduce the XIP image property as you did.
> - "microchip.pfsoc.qspi_xip",
> - memmap[MICROCHIP_PFSOC_QSPI_XIP].size,
> - &error_fatal);
> +if (mks->xip_image) {
> +memory_region_init_ram_from_file(qspi_xip_mem, OBJECT(dev),
> + "microchip.pfsoc.qspi_xip",
> +
> memmap[MICROCHIP_PFSOC_QSPI_XIP].size,
> + 0x1 /* align */, 0 /* ram_flags
> */,
> + mks->xip_image, &error_fatal);
> +qspi_xip_mem->readonly = true;
> +} else {
> +memory_region_init_rom(qspi_xip_mem, OBJECT(dev),
> + "microchip.pfsoc.qspi_xip",
> + memmap[MICROCHIP_PFSOC_QSPI_XIP].size,
> + &error_fatal);
> +}
> memory_region_add_subregion(system_memory,
> memmap[MICROCHIP_PFSOC_QSPI_XIP].base,
> qspi_xip_mem);
> @@ -517,6 +527,24 @@ static void
> microchip_icicle_kit_machine_init(MachineState *machine)
> }
> }
>
Regards,
Bin
Re: [PATCH v4 19/43] accel/tcg: Support split-wx for darwin/iOS with vm_remap
Guarding MAP_JIT with
if (!splitwx) {
flags |= MAP_JIT;
}
is better because MAP_JIT tells the kernel that we want a RWX mapping
which is not the case. On iOS, special entitlements are needed for
MAP_JIT.
-j
On Mon, Dec 14, 2020 at 6:03 AM Richard Henderson
wrote:
>
> Cribbed from code posted by Joelle van Dyne ,
> and rearranged to a cleaner structure.
>
> Reviewed-by: Joelle van Dyne
> Signed-off-by: Richard Henderson
> ---
> accel/tcg/translate-all.c | 65 +++
> 1 file changed, 65 insertions(+)
>
> diff --git a/accel/tcg/translate-all.c b/accel/tcg/translate-all.c
> index 1931e65365..17df6c94fa 100644
> --- a/accel/tcg/translate-all.c
> +++ b/accel/tcg/translate-all.c
> @@ -1166,9 +1166,71 @@ static bool alloc_code_gen_buffer_splitwx_memfd(size_t
> size, Error **errp)
> }
> #endif /* CONFIG_POSIX */
>
> +#ifdef CONFIG_DARWIN
> +#include
> +
> +extern kern_return_t mach_vm_remap(vm_map_t target_task,
> + mach_vm_address_t *target_address,
> + mach_vm_size_t size,
> + mach_vm_offset_t mask,
> + int flags,
> + vm_map_t src_task,
> + mach_vm_address_t src_address,
> + boolean_t copy,
> + vm_prot_t *cur_protection,
> + vm_prot_t *max_protection,
> + vm_inherit_t inheritance);
> +
> +static bool alloc_code_gen_buffer_splitwx_vmremap(size_t size, Error **errp)
> +{
> +kern_return_t ret;
> +mach_vm_address_t buf_rw, buf_rx;
> +vm_prot_t cur_prot, max_prot;
> +
> +/* Map the read-write portion via normal anon memory. */
> +if (!alloc_code_gen_buffer_anon(size, PROT_READ | PROT_WRITE,
> +MAP_PRIVATE | MAP_ANONYMOUS, errp)) {
> +return false;
> +}
> +
> +buf_rw = (mach_vm_address_t)tcg_ctx->code_gen_buffer;
> +buf_rx = 0;
> +ret = mach_vm_remap(mach_task_self(),
> +&buf_rx,
> +size,
> +0,
> +VM_FLAGS_ANYWHERE,
> +mach_task_self(),
> +buf_rw,
> +false,
> +&cur_prot,
> +&max_prot,
> +VM_INHERIT_NONE);
> +if (ret != KERN_SUCCESS) {
> +/* TODO: Convert "ret" to a human readable error message. */
> +error_setg(errp, "vm_remap for jit splitwx failed");
> +munmap((void *)buf_rw, size);
> +return false;
> +}
> +
> +if (mprotect((void *)buf_rx, size, PROT_READ | PROT_EXEC) != 0) {
> +error_setg_errno(errp, errno, "mprotect for jit splitwx");
> +munmap((void *)buf_rx, size);
> +munmap((void *)buf_rw, size);
> +return false;
> +}
> +
> +tcg_splitwx_diff = buf_rx - buf_rw;
> +return true;
> +}
> +#endif /* CONFIG_DARWIN */
> +
> static bool alloc_code_gen_buffer_splitwx(size_t size, Error **errp)
> {
> if (TCG_TARGET_SUPPORT_MIRROR) {
> +#ifdef CONFIG_DARWIN
> +return alloc_code_gen_buffer_splitwx_vmremap(size, errp);
> +#endif
> #ifdef CONFIG_POSIX
> return alloc_code_gen_buffer_splitwx_memfd(size, errp);
> #endif
> @@ -1201,6 +1263,9 @@ static bool alloc_code_gen_buffer(size_t size, int
> splitwx, Error **errp)
> #ifdef CONFIG_TCG_INTERPRETER
> /* The tcg interpreter does not need execute permission. */
> prot = PROT_READ | PROT_WRITE;
> +#elif defined(CONFIG_DARWIN)
> +/* Applicable to both iOS and macOS (Apple Silicon). */
> +flags |= MAP_JIT;
> #endif
>
> return alloc_code_gen_buffer_anon(size, prot, flags, errp);
> --
> 2.25.1
>
Re: [PATCH v2 1/7] target/ppc: Add infrastructure for prefixed instructions
On Wed, Dec 16, 2020 at 06:07:58AM -0300, Gustavo Romero wrote:
> From: Michael Roth
>
> Some prefixed instructions (Type 0 and 1, e.g. 8-byte Load/Store or 8LS),
> have a completely seperate namespace for their primary opcodes.
>
> Other prefixed instructions (Type 2 and 3, e.g. Modified Load/Store or MLS)
> actually re-use existing opcodes to provide a modified variant. We could
> handle these by extending the existing opcode handlers to check for the
> prefix and handle accordingly, but in some cases it is cleaner to define
> seperate handlers for these in their own table entry, and avoids the need
> to add error-handling to existing handlers for cases where they are called
> for a prefixed Type 2/3 instruction but don't implement the handling for
> them. In the future we can re-work things to support both approaches if
> cases arise where that seems warranted.
>
> Then we have the normal non-prefixed instructions.
>
> To handle all 3 of these cases we extend the table size 3x, with normal
> instructions indexed directly by their primary opcodes, Type 0/1 indexed by
> primary opcode + PPC_CPU_PREFIXED_OPCODE_OFFSET, and Type 2/3 indexed by
> primary opcode + PPC_CPU_PREFIXED_MODIFIED_OPCODE_OFFSET.
>
> Various exception/SRR handling changes related to prefixed instructions are
> yet to be implemented. For instance, no alignment interrupt is generated if
> a prefixed instruction crosses the 64-byte boundary; no SRR bit related to
> prefixed instructions is set on any interrupt, like for FP unavailable
> interrupt, data storage interrupt, etc.
>
> For details, please see PowerISA v3.1, particularly the following sections:
>
> 1.6 Instruction Formats, p. 11
> 1.6.3 Instruction Prefix Formats, p. 22
> 3.3.2 Fixed-Point Load Instructions, p. 51
> 4.6.2 Floating-Point Load Instructions, p. 149
> Chapter 7 Interrupts, p. 1247
>
> Signed-off-by: Michael Roth
> [ gromero: - comments clean up and updates
>- additional comments in the commit log ]
> Signed-off-by: Gustavo Romero
I'm still not seeing any advantage to putting both the plain and
prefixed opcodes into a single table. Essentially you're taking the
prefix and base opcode and encoding them into a single index. Which
isn't inherently wrong, except that the only thing you do with that
single index is effectively decode it back into the original two
parts.
More specifically
[snip]
> +static uint32_t opc1_idx(DisasContext *ctx)
> +{
> +uint32_t table_offset = 0;
> +
> +switch (ctx->prefix_subtype) {
> +case PREFIX_ST_8LS:
> +case PREFIX_ST_8MLS:
> +case PREFIX_ST_8RR:
> +case PREFIX_ST_8MRR:
> +table_offset = PPC_CPU_PREFIXED_OPCODE_OFFSET;
> +break;
> +case PREFIX_ST_MLS:
> +case PREFIX_ST_MMLS:
> +case PREFIX_ST_MRR:
> +case PREFIX_ST_MMRR:
> +case PREFIX_ST_MMIRR:
> +table_offset = PPC_CPU_PREFIXED_MODIFIED_OPCODE_OFFSET;
> +break;
> +}
> +
> +return table_offset + opc1(ctx->opcode);
> +}
Here, you translate the prefix type into a table offset, but...
> +
> static void ppc_tr_translate_insn(DisasContextBase *dcbase, CPUState *cs)
> {
> DisasContext *ctx = container_of(dcbase, DisasContext, base);
> @@ -8004,14 +8142,40 @@ static void ppc_tr_translate_insn(DisasContextBase
> *dcbase, CPUState *cs)
>
> ctx->opcode = translator_ldl_swap(env, ctx->base.pc_next,
>need_byteswap(ctx));
> +/* check for prefix */
> +ctx->prefix_subtype = parse_prefix_subtype(ctx->opcode);
> +if (ctx->prefix_subtype == PREFIX_ST_INVALID) {
> +qemu_log_mask(LOG_GUEST_ERROR, "invalid/unsupported prefix: "
> + "%08x " TARGET_FMT_lx "\n",
> + ctx->prefix, ctx->base.pc_next);
> +} else if (ctx->prefix_subtype != PREFIX_ST_NONE) {
> +/*
> + * this is the 4-byte prefix of an instruction, read the
> + * next 4 and advance the PC
> + *
> + * TODO: we can optimize this to do a single load since we
> + * read in target_long anyways already
> + *
> + * double-check endianess cases.
> + *
> + * engineering note about endianess changing based on rfid
> + * or interrupt. does this need to be accounted for here?
> + */
> +ctx->prefix = ctx->opcode;
> +ctx->base.pc_next += 4;
> +ctx->opcode = translator_ldl_swap(env, ctx->base.pc_next,
> + need_byteswap(ctx));
> +} else {
> +ctx->prefix = 0;
> +}
>
> -LOG_DISAS("translate opcode %08x (%02x %02x %02x %02x) (%s)\n",
> +LOG_DISAS("translate opcode %08x (%02x %02x %02x %02x) prefix %08x
> (%s)\n",
>ctx->opcode, opc1(ctx->opcode), opc2(ctx->opcode),
> - opc3(ctx->opcode), opc4(ctx->opcode),
> + opc3(ctx->opcode), opc4(ctx->opcode), ctx->prefix,
>ctx->le_mode ? "little" : "big");
[Bug 1877418] Re: qemu-nbd freezes access to VDI file
[Expired for btrfs-progs (Ubuntu) because there has been no activity for 60 days.] ** Changed in: btrfs-progs (Ubuntu) Status: Incomplete => Expired -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1877418 Title: qemu-nbd freezes access to VDI file Status in QEMU: Expired Status in btrfs-progs package in Ubuntu: Expired Bug description: Mounted Oracle Virtualbox .vdi drive (dynamically allocated), which has GTP+BTRFS: sudo modprobe nbd max_part=16 sudo qemu-nbd -c /dev/nbd0 /storage/btrfs.vdi mount /dev/nbd0p1 /mydata/ Then I am operating on the btrfs filesystem and suddenly it freezes. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1877418/+subscriptions
[Bug 1877418] Re: qemu-nbd freezes access to VDI file
[Expired for QEMU because there has been no activity for 60 days.] ** Changed in: qemu Status: Incomplete => Expired -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1877418 Title: qemu-nbd freezes access to VDI file Status in QEMU: Expired Status in btrfs-progs package in Ubuntu: Expired Bug description: Mounted Oracle Virtualbox .vdi drive (dynamically allocated), which has GTP+BTRFS: sudo modprobe nbd max_part=16 sudo qemu-nbd -c /dev/nbd0 /storage/btrfs.vdi mount /dev/nbd0p1 /mydata/ Then I am operating on the btrfs filesystem and suddenly it freezes. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1877418/+subscriptions
Re: [PATCH 1/3] qapi/net: Add new QMP command for COLO passthrough
On 2021/1/5 上午11:28, Zhang, Chen wrote: -Original Message- From: Jason Wang Sent: Wednesday, December 30, 2020 11:57 AM To: Zhang, Chen ; qemu-dev ; Eric Blake ; Dr. David Alan Gilbert ; Markus Armbruster Cc: Zhang Chen Subject: Re: [PATCH 1/3] qapi/net: Add new QMP command for COLO passthrough On 2020/12/29 上午10:56, Zhang, Chen wrote: I think we can start form COLO. To avoid QMP compatibility issues, I would like to add the n tuple and wildcard support now. OK, I will do this job in next version. For the QMP compatibility issues, please give me a demo of what we want to see, Like some existing commands. I meant if we start from port and then want to add e.g n-tuple support. Do we need to introduce another command? Or is there any introspection that can let management layer know about this? OK, I will add the n-tuple support. It looks basic command are add/del connection, Do you think something needs to be introduced? It looks to me it's fine to start with them. For the management layer, I don't know the detail process of how to add new Qemu command support for example libvirt. Maybe depend on libvirt community's plan? So a question here, how COLO is being used now. Is it expected to be managed by libvirt or not? Thanks Thanks Chen Thanks Thanks Chen
Re: [PATCH v2 1/4] hw/misc: imx6_ccm: Update PMU_MISC0 reset value
On Wed, Dec 23, 2020 at 2:26 PM Bin Meng wrote: > > From: Bin Meng > > U-Boot expects PMU_MISC0 register bit 7 is set (see init_bandgap() > in arch/arm/mach-imx/mx6/soc.c) during boot. This bit indicates the > bandgap has stabilized. > > With this change, the latest upstream U-Boot (v2021.01-rc3) for imx6 > sabrelite board (mx6qsabrelite_defconfig), with a slight change made > by switching CONFIG_OF_SEPARATE to CONFIG_OF_EMBED, boots to U-Boot > shell on QEMU with the following command: > > $ qemu-system-arm -M sabrelite -smp 4 -m 1G -kernel u-boot \ > -display none -serial null -serial stdio > > Boot log below: > > U-Boot 2021.01-rc3 (Dec 12 2020 - 17:40:02 +0800) > > CPU: Freescale i.MX?? rev1.0 at 792 MHz > Reset cause: POR > Model: Freescale i.MX6 Quad SABRE Lite Board > Board: SABRE Lite > I2C: ready > DRAM: 1 GiB > force_idle_bus: sda=0 scl=0 sda.gp=0x5c scl.gp=0x55 > force_idle_bus: failed to clear bus, sda=0 scl=0 > force_idle_bus: sda=0 scl=0 sda.gp=0x6d scl.gp=0x6c > force_idle_bus: failed to clear bus, sda=0 scl=0 > force_idle_bus: sda=0 scl=0 sda.gp=0xcb scl.gp=0x5 > force_idle_bus: failed to clear bus, sda=0 scl=0 > MMC: FSL_SDHC: 0, FSL_SDHC: 1 > Loading Environment from MMC... *** Warning - No block device, using > default environment > > In:serial > Out: serial > Err: serial > Net: Board Net Initialization Failed > No ethernet found. > starting USB... > Bus usb@2184000: usb dr_mode not found > USB EHCI 1.00 > Bus usb@2184200: USB EHCI 1.00 > scanning bus usb@2184000 for devices... 1 USB Device(s) found > scanning bus usb@2184200 for devices... 1 USB Device(s) found > scanning usb for storage devices... 0 Storage Device(s) found > scanning usb for ethernet devices... 0 Ethernet Device(s) found > Hit any key to stop autoboot: 0 > => > > Signed-off-by: Bin Meng > --- > > (no changes since v1) > > hw/misc/imx6_ccm.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > Ping?
Re: [PATCH v5 1/2] hw/block: m25p80: Don't write to flash if write is disabled
On Wed, Dec 23, 2020 at 10:00 AM Bin Meng wrote:
>
> From: Bin Meng
>
> When write is disabled, the write to flash should be avoided
> in flash_write8().
>
> Fixes: 82a2499011a7 ("m25p80: Initial implementation of SPI flash device")
> Signed-off-by: Bin Meng
> Reviewed-by: Philippe Mathieu-Daudé
> Reviewed-by: Francisco Iglesias
>
> ---
>
> (no changes since v2)
>
> Changes in v2:
> - new patch: honor write enable flag in flash write
>
> hw/block/m25p80.c | 1 +
> 1 file changed, 1 insertion(+)
>
Ping?
Re: [PATCH v4 1/2] hw/block: m25p80: Don't write to flash if write is disabled
On Tue, Jan 5, 2021 at 11:46 AM Bin Meng wrote:
>
> Hello,
>
> On Tue, Dec 22, 2020 at 2:45 PM Bin Meng wrote:
> >
> > From: Bin Meng
> >
> > When write is disabled, the write to flash should be avoided
> > in flash_write8().
> >
> > Fixes: 82a2499011a7 ("m25p80: Initial implementation of SPI flash device")
> > Signed-off-by: Bin Meng
> >
> > ---
> >
> > (no changes since v2)
> >
> > Changes in v2:
> > - new patch: honor write enable flag in flash write
> >
> > hw/block/m25p80.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
>
> Who is going to pick up this series? Is it Alistair, or Peter?
>
Oops, I replied to the wrong thread. There is a v5 series that should
be applied.
Regards,
Bin
Re: [PATCH v4 1/2] hw/block: m25p80: Don't write to flash if write is disabled
Hello,
On Tue, Dec 22, 2020 at 2:45 PM Bin Meng wrote:
>
> From: Bin Meng
>
> When write is disabled, the write to flash should be avoided
> in flash_write8().
>
> Fixes: 82a2499011a7 ("m25p80: Initial implementation of SPI flash device")
> Signed-off-by: Bin Meng
>
> ---
>
> (no changes since v2)
>
> Changes in v2:
> - new patch: honor write enable flag in flash write
>
> hw/block/m25p80.c | 1 +
> 1 file changed, 1 insertion(+)
>
Who is going to pick up this series? Is it Alistair, or Peter?
Regards,
Bin
RE: [PATCH 0/3] Bypass specific network traffic in COLO
> -Original Message- > From: Dr. David Alan Gilbert > Sent: Monday, January 4, 2021 9:07 PM > To: Zhang, Chen > Cc: Jason Wang ; qemu-dev de...@nongnu.org>; Eric Blake ; Markus Armbruster > ; Zhang Chen > Subject: Re: [PATCH 0/3] Bypass specific network traffic in COLO > > * Zhang Chen (chen.zh...@intel.com) wrote: > > From: Zhang Chen > > > > Since the real user scenario does not need to monitor all traffic. > > Can you explain the type of real user case where they only need to compare > some connections? Sure. For example, windows guest user want to enable windows remote desktop to touch guest(UDP/TCP 3389), This case use UDP and TCP mixed, and the tcp part payload always different caused by real desktop display data(for guest time/ mouse display). Another case is some real user application will actively transmit information include guest time part, primary guest send data with time 10:01.000, At the same time secondary guest send data with time 10:01.001, it will always trigger COLO checkpoint to drop guest performance. Thanks Chen > > Dave > > > This series give user ability to bypass kinds of network stream. > > > > Zhang Chen (3): > > qapi/net: Add new QMP command for COLO passthrough > > hmp-commands: Add new HMP command for COLO passthrough > > net/colo-compare: Add handler for passthrough connection > > > > hmp-commands.hx | 26 +++ > > include/monitor/hmp.h | 2 ++ > > monitor/hmp-cmds.c| 20 ++ > > net/colo-compare.c| 49 > +++ > > net/colo-compare.h| 2 ++ > > net/net.c | 39 ++ > > qapi/net.json | 46 > > > 7 files changed, 184 insertions(+) > > > > -- > > 2.17.1 > > > -- > Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
RE: [PATCH 1/3] qapi/net: Add new QMP command for COLO passthrough
> -Original Message- > From: Jason Wang > Sent: Wednesday, December 30, 2020 11:57 AM > To: Zhang, Chen ; qemu-dev de...@nongnu.org>; Eric Blake ; Dr. David Alan > Gilbert ; Markus Armbruster > Cc: Zhang Chen > Subject: Re: [PATCH 1/3] qapi/net: Add new QMP command for COLO > passthrough > > > On 2020/12/29 上午10:56, Zhang, Chen wrote: > >> I think we can start form COLO. To avoid QMP compatibility issues, I > >> would like to add the n tuple and wildcard support now. > > OK, I will do this job in next version. > > For the QMP compatibility issues, please give me a demo of what we want > to see, Like some existing commands. > > > I meant if we start from port and then want to add e.g n-tuple support. > Do we need to introduce another command? Or is there any introspection > that can let management layer know about this? OK, I will add the n-tuple support. It looks basic command are add/del connection, Do you think something needs to be introduced? For the management layer, I don't know the detail process of how to add new Qemu command support for example libvirt. Maybe depend on libvirt community's plan? Thanks Chen > > Thanks > > > > > > Thanks > > Chen > >
Re: [PATCH] RISC-V: Place DTB at 3GB boundary instead of 4GB
On Fri, Dec 18, 2020 at 5:48 AM Atish Patra wrote:
>
> Currently, we place the DTB at 2MB from 4GB or end of DRAM which ever is
> lesser. However, Linux kernel can address only 1GB of memory for RV32.
> Thus, it can not map anything beyond 3GB (assuming 2GB is the starting
> address).
> As a result, it can not process DT and panic if opensbi dynamic firmware
> is used.
>
> Fix this by placing the DTB at 2MB from 3GB or end of DRAM whichever is lower.
>
Fixes: 66b1205bc5ab ("RISC-V: Copy the fdt in dram instead of ROM")
> Signed-off-by: Atish Patra
> ---
> hw/riscv/boot.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
Reviewed-by: Bin Meng
Tested-by: Bin Meng
Re: [PATCH] RISC-V: Place DTB at 3GB boundary instead of 4GB
Hi Atish, On Tue, Jan 5, 2021 at 4:24 AM Atish Patra wrote: > > On Tue, 2020-12-29 at 12:49 +0800, Bin Meng wrote: > > Hi Atish, > > > > On Wed, Dec 23, 2020 at 9:20 AM Bin Meng wrote: > > > > > > Hi Atish, > > > > > > On Wed, Dec 23, 2020 at 3:59 AM Atish Patra > > > wrote: > > > > > > > > On Tue, 2020-12-22 at 13:35 +0800, Bin Meng wrote: > > > > > Hi Atish, > > > > > > > > > > On Sat, Dec 19, 2020 at 3:46 AM Atish Patra < > > > > > atish.pa...@wdc.com> > > > > > wrote: > > > > > > > > > > > > On Fri, 2020-12-18 at 16:42 +0800, Bin Meng wrote: > > > > > > > Hi Atish, > > > > > > > > > > > > > > On Fri, Dec 18, 2020 at 4:00 PM Atish Patra < > > > > > > > atish.pa...@wdc.com> > > > > > > > wrote: > > > > > > > > > > > > > > > > On Fri, 2020-12-18 at 15:33 +0800, Bin Meng wrote: > > > > > > > > > Hi Atish, > > > > > > > > > > > > > > > > > > On Fri, Dec 18, 2020 at 3:27 PM Atish Patra < > > > > > > > > > atish.pa...@wdc.com> > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > On Fri, 2020-12-18 at 15:21 +0800, Bin Meng wrote: > > > > > > > > > > > Hi Atish, > > > > > > > > > > > > > > > > > > > > > > On Fri, Dec 18, 2020 at 5:48 AM Atish Patra > > > > > > > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > Currently, we place the DTB at 2MB from 4GB or > > > > > > > > > > > > end of > > > > > > > > > > > > DRAM > > > > > > > > > > > > which > > > > > > > > > > > > ever is > > > > > > > > > > > > lesser. However, Linux kernel can address only > > > > > > > > > > > > 1GB of > > > > > > > > > > > > memory > > > > > > > > > > > > for > > > > > > > > > > > > RV32. > > > > > > > > > > > > Thus, it can not map anything beyond 3GB > > > > > > > > > > > > (assuming 2GB > > > > > > > > > > > > is > > > > > > > > > > > > the > > > > > > > > > > > > starting address). > > > > > > > > > > > > As a result, it can not process DT and panic if > > > > > > > > > > > > opensbi > > > > > > > > > > > > dynamic > > > > > > > > > > > > firmware > > > > > > > > > > > > is used. > > > > > > > > > > > > > > > > > > > > > > > > Fix this by placing the DTB at 2MB from 3GB or > > > > > > > > > > > > end of > > > > > > > > > > > > DRAM > > > > > > > > > > > > whichever is lower. > > > > > > > > > > > > > > > > > > > > > > > > Signed-off-by: Atish Patra > > > > > > > > > > > > --- > > > > > > > > > > > > hw/riscv/boot.c | 4 ++-- > > > > > > > > > > > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > With this patch, 32-bit sifive_u still does not > > > > > > > > > > > boot > > > > > > > > > > > kernel > > > > > > > > > > > with > > > > > > > > > > > the > > > > > > > > > > > following patch applied on 5.10: > > > > > > > > > > > > > > > > > > > > > > https://patchwork.kernel.org/project/linux-riscv/patch/20201217074855.1948743-1-atish.pa...@wdc.com/ > > > > > > > > > > > > > > > > > > > > > > Command I used: > > > > > > > > > > > $ qemu-system-riscv32 -nographic -M sifive_u -m 1G > > > > > > > > > > > -smp 5 > > > > > > > > > > > - > > > > > > > > > > > kernel > > > > > > > > > > > arch/riscv/boot/Image > > > > > > > > > > > > > > > > > > > > > > 32-bit virt cannot boot the same kernel image with > > > > > > > > > > > memory > > > > > > > > > > > set > > > > > > > > > > > to > > > > > > > > > > > 2G > > > > > > > > > > > either: > > > > > > > > > > > $ qemu-system-riscv32 -nographic -M virt -m 2G -smp > > > > > > > > > > > 4 - > > > > > > > > > > > kernel > > > > > > > > > > > arch/riscv/boot/Image > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Bin, > > > > > > > > > > As mentioned in the email on the linux mailing list, > > > > > > > > > > this > > > > > > > > > > patch > > > > > > > > > > only > > > > > > > > > > solves 2GB problem. sifive_u problem is solved by > > > > > > > > > > Alistair's > > > > > > > > > > patch[1]. > > > > > > > > > > > > > > > > > > > > He is planning to send the PR soon. The issue with > > > > > > > > > > sifive_u > > > > > > > > > > boot > > > > > > > > > > was it > > > > > > > > > > was failing the 32 bit test earlier resulting a 2MB > > > > > > > > > > aligned > > > > > > > > > > address > > > > > > > > > > instead of 4MB. > > > > > > > > > > > > > > > > > > Ah, I see. However my testing shows that virt with 2G > > > > > > > > > still > > > > > > > > > does > > > > > > > > > not > > > > > > > > > boot with this patch. > > > > > > > > > > > > > > > > > > > > > > > > > Strange. I verified again with following combination with > > > > > > > > -bios > > > > > > > > and > > > > > > > > without bios parameter. > > > > > > > > > > > > > > > > 1. virt 32/64 with 1GB/2GB memory > > > > > > > > 2. sifive_u 32/64 bit with 1GB/2GB memory (Alistair's > > > > > > > > patch > > > > > > > > included) > > > > > > > > > > > > > > > > Can you share the boot log along with the head commit of > > > > > > > > Qemu > > > > > > > > and > > > > > > > > commandline ? I am using 5.10 kernel wit
Re: [PATCH 0/4] A few preliminary bsd-user patches
On Fri, Dec 18, 2020 at 1:55 PM wrote: > From: Warner Losh > > Here's the first round of bsd-user patches. There's on the order of 280 > that > we've done, but that's too much to review all at once. In addition, 3.1 > release > was the last rebase point that we've been successful with for a number of > reasons > unrelated to qemu. Now that those have been resolved, we have a new push > under way > to push things forward, but wanted to upstream as many of the patches as > we can > directly to qemu's head to lighten the load of carrying all these. > > This first small series updates the system call lists, moves things around > to > make it easier to support divergence in the BSD world, and adjusts to the > new > meson build. It's also designed to help me learn how to land such a large > set > upstream. > > These patches have passed through several hands, with different tweaks > over the > years so have an unusually large number of signed-off-by lines that are the > result of this refinement process where several hands have touched the > patches > in the last 7 years. > > Sean Bruno (1): > tcg: Additional Trap type for FreeBSD > > Stacey Son (1): > bsd-user: move strace OS/arch dependent code to host/arch dirs > > Warner Losh (2): > bsd-user: regenerate FreeBSD's system call numbers > bsd-user: Update strace.list for FreeBSD's latest syscalls > > accel/tcg/user-exec.c | 8 +- > bsd-user/arm/target_arch_sysarch.h | 78 +++ > bsd-user/arm/target_syscall.h | 36 ++ > bsd-user/freebsd/os-strace.h | 29 ++ > bsd-user/freebsd/strace.list | 65 ++- > bsd-user/freebsd/syscall_nr.h | 695 ++--- > bsd-user/i386/target_arch_sysarch.h| 77 +++ > bsd-user/i386/target_syscall.h | 19 + > bsd-user/mips/target_arch_sysarch.h| 69 +++ > bsd-user/mips/target_syscall.h | 52 ++ > bsd-user/mips64/target_arch_sysarch.h | 69 +++ > bsd-user/mips64/target_syscall.h | 53 ++ > bsd-user/netbsd/os-strace.h| 1 + > bsd-user/openbsd/os-strace.h | 1 + > bsd-user/sparc/target_arch_sysarch.h | 52 ++ > bsd-user/sparc/target_syscall.h| 24 +- > bsd-user/sparc64/target_arch_sysarch.h | 52 ++ > bsd-user/sparc64/target_syscall.h | 24 +- > bsd-user/strace.c | 11 + > bsd-user/x86_64/target_arch_sysarch.h | 76 +++ > bsd-user/x86_64/target_syscall.h | 21 +- > meson.build| 1 + > 22 files changed, 1186 insertions(+), 327 deletions(-) > create mode 100644 bsd-user/arm/target_arch_sysarch.h > create mode 100644 bsd-user/arm/target_syscall.h > create mode 100644 bsd-user/freebsd/os-strace.h > create mode 100644 bsd-user/i386/target_arch_sysarch.h > create mode 100644 bsd-user/mips/target_arch_sysarch.h > create mode 100644 bsd-user/mips/target_syscall.h > create mode 100644 bsd-user/mips64/target_arch_sysarch.h > create mode 100644 bsd-user/mips64/target_syscall.h > create mode 100644 bsd-user/netbsd/os-strace.h > create mode 100644 bsd-user/openbsd/os-strace.h > create mode 100644 bsd-user/sparc/target_arch_sysarch.h > create mode 100644 bsd-user/sparc64/target_arch_sysarch.h > create mode 100644 bsd-user/x86_64/target_arch_sysarch.h > ping?
[PATCH v6 7/7] block: check availablity for preadv/pwritev on mac
macOS 11/iOS 14 added preadv/pwritev APIs. Due to weak linking, configure
will succeed with CONFIG_PREADV even when targeting a lower OS version.
We therefore need to check at run time if we can actually use these APIs.
Signed-off-by: Joelle van Dyne
---
block/file-posix.c | 33 +
1 file changed, 33 insertions(+)
diff --git a/block/file-posix.c b/block/file-posix.c
index 9f556322e6..f109e1f305 100644
--- a/block/file-posix.c
+++ b/block/file-posix.c
@@ -1390,17 +1390,50 @@ static int handle_aiocb_flush(void *opaque)
#ifdef CONFIG_PREADV
static bool preadv_present = true;
+static bool preadv_checked;
static ssize_t
qemu_preadv(int fd, const struct iovec *iov, int nr_iov, off_t offset)
{
+#ifdef CONFIG_DARWIN /* preadv introduced in macOS 11 */
+if (unlikely(!preadv_checked)) {
+if (__builtin_available(macOS 11, iOS 14, watchOS 7, tvOS 14, *)) {
+preadv_checked = true;
+} else {
+preadv_present = false;
+return -ENOSYS;
+}
+}
+/* Now we suppress the availability warning since we use the cached check
*/
+#pragma clang diagnostic push
+#pragma clang diagnostic ignored "-Wunguarded-availability-new"
+return preadv(fd, iov, nr_iov, offset);
+#pragma clang diagnostic pop
+#else /* CONFIG_DARWIN */
return preadv(fd, iov, nr_iov, offset);
+#endif
}
static ssize_t
qemu_pwritev(int fd, const struct iovec *iov, int nr_iov, off_t offset)
{
+#ifdef CONFIG_DARWIN /* preadv introduced in macOS 11 */
+if (unlikely(!preadv_checked)) {
+if (__builtin_available(macOS 11, iOS 14, watchOS 7, tvOS 14, *)) {
+preadv_checked = true;
+} else {
+preadv_present = false;
+return -ENOSYS;
+}
+}
+/* Now we suppress the availability warning since we use the cached check
*/
+#pragma clang diagnostic push
+#pragma clang diagnostic ignored "-Wunguarded-availability-new"
+return pwritev(fd, iov, nr_iov, offset);
+#pragma clang diagnostic pop
+#else /* CONFIG_DARWIN */
return pwritev(fd, iov, nr_iov, offset);
+#endif
}
#else
--
2.28.0
[PATCH v6 5/7] configure: cross compile should use x86_64 cpu_family
Signed-off-by: Joelle van Dyne --- configure | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/configure b/configure index 09dd22ebad..79dc9811e8 100755 --- a/configure +++ b/configure @@ -7033,9 +7033,12 @@ if test "$cross_compile" = "yes"; then echo "system = 'darwin'" >> $cross fi case "$ARCH" in -i386|x86_64) +i386) echo "cpu_family = 'x86'" >> $cross ;; +x86_64) +echo "cpu_family = 'x86_64'" >> $cross +;; ppc64le) echo "cpu_family = 'ppc64'" >> $cross ;; -- 2.28.0
[PATCH v6 3/7] qemu: add support for iOS host
This introduces support for building for iOS hosts. When the correct Xcode
toolchain is used, iOS host will be detected automatically.
* block: disable features not supported by iOS sandbox
* slirp: disable SMB features for iOS
* osdep: disable system() calls for iOS
Signed-off-by: Joelle van Dyne
---
docs/devel/index.rst| 1 +
docs/devel/ios.rst | 28 +++
configure | 43 -
meson.build | 2 +-
include/qemu/osdep.h| 11 +++
block.c | 2 +-
block/file-posix.c | 31 +
net/slirp.c | 16 +++
qga/commands-posix.c| 6 ++
MAINTAINERS | 7 +++
tests/qtest/meson.build | 7 +++
11 files changed, 127 insertions(+), 27 deletions(-)
create mode 100644 docs/devel/ios.rst
diff --git a/docs/devel/index.rst b/docs/devel/index.rst
index f10ed77e4c..2cc8a13ebe 100644
--- a/docs/devel/index.rst
+++ b/docs/devel/index.rst
@@ -35,3 +35,4 @@ Contents:
clocks
qom
block-coroutine-wrapper
+ ios
diff --git a/docs/devel/ios.rst b/docs/devel/ios.rst
new file mode 100644
index 00..b4ab11bec1
--- /dev/null
+++ b/docs/devel/ios.rst
@@ -0,0 +1,28 @@
+===
+iOS Support
+===
+
+To run qemu on the iOS platform, some modifications were required. Most of the
+modifications are conditioned on the ``CONFIG_IOS`` and configuration variable.
+
+Build support
+-
+
+For the code to compile, certain changes in the block driver and the slirp
+driver had to be made. There is no ``system()`` call, so it has been replaced
+with an assertion error. There should be no code path that call system() from
+iOS.
+
+``ucontext`` support is broken on iOS. The implementation from ``libucontext``
+is used instead.
+
+JIT support
+---
+
+On iOS, allocating RWX pages require special entitlements not usually granted
to
+apps. However, it is possible to use `bulletproof JIT`_ with a development
+certificate. This means that we need to allocate one chunk of memory with RX
+permissions and then mirror map the same memory with RW permissions. We
generate
+code to the mirror mapping and execute the original mapping.
+
+.. _bulletproof JIT:
https://www.blackhat.com/docs/us-16/materials/us-16-Krstic.pdf
diff --git a/configure b/configure
index 744d1990be..c1a08f0171 100755
--- a/configure
+++ b/configure
@@ -560,6 +560,19 @@ EOF
compile_object
}
+check_ios() {
+ cat > $TMPC < $TMPC <
@@ -602,7 +615,11 @@ elif check_define __DragonFly__ ; then
elif check_define __NetBSD__; then
targetos='NetBSD'
elif check_define __APPLE__; then
- targetos='Darwin'
+ if check_ios ; then
+targetos='iOS'
+ else
+targetos='Darwin'
+ fi
else
# This is a fatal error, but don't report it yet, because we
# might be going to just print the --help text, or it might
@@ -779,6 +796,22 @@ Darwin)
# won't work when we're compiling with gcc as a C compiler.
QEMU_CFLAGS="-DOS_OBJECT_USE_OBJC=0 $QEMU_CFLAGS"
;;
+iOS)
+ bsd="yes"
+ darwin="yes"
+ ios="yes"
+ if [ "$cpu" = "x86_64" ] ; then
+QEMU_CFLAGS="-arch x86_64 $QEMU_CFLAGS"
+QEMU_LDFLAGS="-arch x86_64 $QEMU_LDFLAGS"
+ fi
+ host_block_device_support="no"
+ audio_drv_list=""
+ audio_possible_drivers=""
+ QEMU_LDFLAGS="-framework CoreFoundation $QEMU_LDFLAGS"
+ # Disable attempts to use ObjectiveC features in os/object.h since they
+ # won't work when we're compiling with gcc as a C compiler.
+ QEMU_CFLAGS="-DOS_OBJECT_USE_OBJC=0 $QEMU_CFLAGS"
+;;
SunOS)
solaris="yes"
make="${MAKE-gmake}"
@@ -5992,6 +6025,10 @@ if test "$darwin" = "yes" ; then
echo "CONFIG_DARWIN=y" >> $config_host_mak
fi
+if test "$ios" = "yes" ; then
+ echo "CONFIG_IOS=y" >> $config_host_mak
+fi
+
if test "$solaris" = "yes" ; then
echo "CONFIG_SOLARIS=y" >> $config_host_mak
fi
@@ -6956,6 +6993,7 @@ echo "cpp_link_args = [${LDFLAGS:+$(meson_quote
$LDFLAGS)}]" >> $cross
echo "[binaries]" >> $cross
echo "c = [$(meson_quote $cc)]" >> $cross
test -n "$cxx" && echo "cpp = [$(meson_quote $cxx)]" >> $cross
+test -n "$objcc" && echo "objc = [$(meson_quote $objcc)]" >> $cross
echo "ar = [$(meson_quote $ar)]" >> $cross
echo "nm = [$(meson_quote $nm)]" >> $cross
echo "pkgconfig = [$(meson_quote $pkg_config_exe)]" >> $cross
@@ -6974,6 +7012,9 @@ if test "$cross_compile" = "yes"; then
if test "$linux" = "yes" ; then
echo "system = 'linux'" >> $cross
fi
+if test "$darwin" = "yes" ; then
+echo "system = 'darwin'" >> $cross
+fi
case "$ARCH" in
i386|x86_64)
echo "cpu_family = 'x86'" >> $cross
diff --git a/meson.build b/meson.build
index 9a640d3407..ee333b7a94 100644
--- a/meson.build
+++ b/meson.build
@@ -181,7 +181,7 @@ if targetos == 'windows'
include_directories:
include_directories('.'))
elif targetos == 'darwin'
coref = dependency('appl
[PATCH v6 4/7] coroutine: add libucontext as external library
iOS does not support ucontext natively for aarch64 and the sigaltstack is
also unsupported (even worse, it fails silently, see:
https://openradar.appspot.com/13002712 )
As a workaround we include a library implementation of ucontext and add it
as a build option.
Signed-off-by: Joelle van Dyne
---
configure | 23 ---
meson.build | 11 ++-
util/coroutine-ucontext.c | 9 +
.gitmodules | 3 +++
meson_options.txt | 2 ++
subprojects/libucontext | 1 +
6 files changed, 45 insertions(+), 4 deletions(-)
create mode 16 subprojects/libucontext
diff --git a/configure b/configure
index c1a08f0171..09dd22ebad 100755
--- a/configure
+++ b/configure
@@ -1767,7 +1767,7 @@ Advanced options (experts only):
--oss-libpath to OSS library
--cpu=CPUBuild for host CPU [$cpu]
--with-coroutine=BACKEND coroutine backend. Supported options:
- ucontext, sigaltstack, windows
+ ucontext, libucontext, sigaltstack, windows
--enable-gcovenable test coverage analysis with gcov
--disable-blobs disable installing provided firmware blobs
--with-vss-sdk=SDK-path enable Windows VSS support in QEMU Guest Agent
@@ -4913,6 +4913,8 @@ if test "$coroutine" = ""; then
coroutine=win32
elif test "$ucontext_works" = "yes"; then
coroutine=ucontext
+ elif test "$ios" = "yes"; then
+coroutine=libucontext
else
coroutine=sigaltstack
fi
@@ -4936,12 +4938,27 @@ else
error_exit "only the 'windows' coroutine backend is valid for Windows"
fi
;;
+ libucontext)
+ ;;
*)
error_exit "unknown coroutine backend $coroutine"
;;
esac
fi
+case $coroutine in
+libucontext)
+ git_submodules="${git_submodules} subprojects/libucontext"
+ mkdir -p libucontext
+ coroutine_impl=ucontext
+ libucontext="enabled"
+ ;;
+*)
+ coroutine_impl=$coroutine
+ libucontext="disabled"
+ ;;
+esac
+
if test "$coroutine_pool" = ""; then
coroutine_pool=yes
fi
@@ -6487,7 +6504,7 @@ if test "$rbd" = "yes" ; then
echo "RBD_LIBS=$rbd_libs" >> $config_host_mak
fi
-echo "CONFIG_COROUTINE_BACKEND=$coroutine" >> $config_host_mak
+echo "CONFIG_COROUTINE_BACKEND=$coroutine_impl" >> $config_host_mak
if test "$coroutine_pool" = "yes" ; then
echo "CONFIG_COROUTINE_POOL=1" >> $config_host_mak
else
@@ -7069,7 +7086,7 @@ NINJA=$ninja $meson setup \
-Dcocoa=$cocoa -Dmpath=$mpath -Dsdl=$sdl -Dsdl_image=$sdl_image \
-Dvnc=$vnc -Dvnc_sasl=$vnc_sasl -Dvnc_jpeg=$vnc_jpeg
-Dvnc_png=$vnc_png \
-Dgettext=$gettext -Dxkbcommon=$xkbcommon -Du2f=$u2f
-Dvirtiofsd=$virtiofsd \
--Dcapstone=$capstone -Dslirp=$slirp -Dfdt=$fdt \
+-Dcapstone=$capstone -Dslirp=$slirp -Dfdt=$fdt -Ducontext=$libucontext
\
-Diconv=$iconv -Dcurses=$curses -Dlibudev=$libudev\
-Ddocs=$docs -Dsphinx_build=$sphinx_build -Dinstall_blobs=$blobs \
-Dvhost_user_blk_server=$vhost_user_blk_server \
diff --git a/meson.build b/meson.build
index ee333b7a94..900dbc36c8 100644
--- a/meson.build
+++ b/meson.build
@@ -1308,9 +1308,17 @@ if not fdt.found() and fdt_required.length() > 0
error('fdt not available but required by targets ' + ', '.join(fdt_required))
endif
+ucontext = dependency('libucontext', required : false)
+if not ucontext.found() and get_option('ucontext').enabled()
+ libucontext_proj = subproject('libucontext',
+default_options: ['freestanding=true'])
+ ucontext = libucontext_proj.get_variable('libucontext_dep')
+endif
+
config_host_data.set('CONFIG_CAPSTONE', capstone.found())
config_host_data.set('CONFIG_FDT', fdt.found())
config_host_data.set('CONFIG_SLIRP', slirp.found())
+config_host_data.set('CONFIG_LIBUCONTEXT', ucontext.found())
#
# Generated sources #
@@ -1528,7 +1536,7 @@ util_ss.add_all(trace_ss)
util_ss = util_ss.apply(config_all, strict: false)
libqemuutil = static_library('qemuutil',
sources: util_ss.sources() + stub_ss.sources() +
genh,
- dependencies: [util_ss.dependencies(), m, glib,
socket, malloc])
+ dependencies: [util_ss.dependencies(), m, glib,
socket, malloc, ucontext])
qemuutil = declare_dependency(link_with: libqemuutil,
sources: genh + version_res)
@@ -2188,6 +2196,7 @@ if targetos == 'windows'
summary_info += {'QGA MSI support': config_host.has_key('CONFIG_QGA_MSI')}
endif
summary_info += {'seccomp support': config_host.has_key('CONFIG_SECCOMP')}
+summary_info += {'libucontext support': ucontext.found()}
summary_info += {'coroutine backend': config_host['CONFIG_COROUTINE_BACKEND']}
summary_info += {'coroutine pool':config_host['CONFIG_COROUTINE_POOL'] ==
'1'}
summary_info += {'debug stack usage':
config_host.has_key('CONFIG_DEBUG_STACK_US
[PATCH v6 2/7] configure: cross-compiling with empty cross_prefix
The iOS toolchain does not use the host prefix naming convention. So we need to enable cross-compile options while allowing the PREFIX to be blank. Reviewed-by: Philippe Mathieu-Daudé Signed-off-by: Joelle van Dyne --- configure | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/configure b/configure index 7cd2ee0b9c..744d1990be 100755 --- a/configure +++ b/configure @@ -234,6 +234,7 @@ cpu="" iasl="iasl" interp_prefix="/usr/gnemul/qemu-%M" static="no" +cross_compile="no" cross_prefix="" audio_drv_list="" block_drv_rw_whitelist="" @@ -461,6 +462,7 @@ for opt do optarg=$(expr "x$opt" : 'x[^=]*=\(.*\)') case "$opt" in --cross-prefix=*) cross_prefix="$optarg" +cross_compile="yes" ;; --cc=*) CC="$optarg" ;; @@ -1674,7 +1676,7 @@ $(echo Deprecated targets: $deprecated_targets_list | \ --target-list-exclude=LIST exclude a set of targets from the default target-list Advanced options (experts only): - --cross-prefix=PREFIXuse PREFIX for compile tools [$cross_prefix] + --cross-prefix=PREFIXuse PREFIX for compile tools, PREFIX can be blank [$cross_prefix] --cc=CC use C compiler CC [$cc] --iasl=IASL use ACPI compiler IASL [$iasl] --host-cc=CC use C compiler CC [$host_cc] for code run at @@ -6963,7 +6965,7 @@ if has $sdl2_config; then fi echo "strip = [$(meson_quote $strip)]" >> $cross echo "windres = [$(meson_quote $windres)]" >> $cross -if test -n "$cross_prefix"; then +if test "$cross_compile" = "yes"; then cross_arg="--cross-file config-meson.cross" echo "[host_machine]" >> $cross if test "$mingw32" = "yes" ; then -- 2.28.0
[PATCH v6 0/7] iOS and Apple Silicon host support
Based-on: 20201214140314.18544-1-richard.hender...@linaro.org ([PATCH v4 00/43] Mirror map JIT memory for TCG) These set of changes brings QEMU TCG to iOS devices and future Apple Silicon devices. They were originally developed last year and have been working in the UTM app. Recently, we ported the changes to master, re-wrote a lot of the build script changes for meson, and broke up the patches into more distinct units. A summary of the changes: * `CONFIG_IOS` defined when building for iOS and iOS specific changes (as well as unsupported code) are gated behind it. * A new dependency, libucontext is added since iOS does not have native ucontext and broken support for sigaltstack. libucontext is available as a new option for coroutine backend. Since v6: * Dropped the Apple Silicon JIT support patch (superseded by another patchset) * Changed libucontext to be a Meson subproject * Cache availablity check for preadv/pwritev on macOS 11 and iOS 14 Since v5: * Fixed some more instances of QAPI define of CONFIG_HOST_BLOCK_DEVICE * Fixed libucontext build on newer version of GCC Since v4: * Updated QAPI schema for CONFIG_HOST_BLOCK_DEVICE * Updated maintainers file for iOS host support * Moved system() changes to osdep.h * Fixed typo in libucontext meson.build change Since v3: * Moved mirror JIT support to a different patch set. * Removed dependency on `pthread_jit_write_protect_np` because it was redundent and also crashes if called on a non-jailbroken iOS device. * Removed `--enable-cross-compile` option * Fixed checkpatch errors * Fixed iOS build on master due to new test recently added which calls system() Since v2: * Changed getting mirror pointer from a macro to inline functions * Split constification of TCG code pointers to separate patch * Removed slirp updates (will send future patch once slirp changes are in) * Removed shared library patch (will send future patch) -j Joelle van Dyne (7): configure: option to disable host block devices configure: cross-compiling with empty cross_prefix qemu: add support for iOS host coroutine: add libucontext as external library configure: cross compile should use x86_64 cpu_family slirp: update build flags for iOS resolv fix block: check availablity for preadv/pwritev on mac docs/devel/index.rst | 1 + docs/devel/ios.rst| 28 ++ configure | 81 +++ meson.build | 16 +++- qapi/block-core.json | 10 +++-- include/qemu/osdep.h | 11 ++ block.c | 2 +- block/file-posix.c| 74 --- net/slirp.c | 16 qga/commands-posix.c | 6 +++ util/coroutine-ucontext.c | 9 + .gitmodules | 3 ++ MAINTAINERS | 7 meson_options.txt | 2 + subprojects/libucontext | 1 + tests/qtest/meson.build | 7 ++-- 16 files changed, 236 insertions(+), 38 deletions(-) create mode 100644 docs/devel/ios.rst create mode 16 subprojects/libucontext -- 2.28.0
[PATCH v6 6/7] slirp: update build flags for iOS resolv fix
A future libslirp update will use libresolv on Darwin systems, so we add the
flags in QEMU build now.
Reviewed-by: Stefan Hajnoczi
Signed-off-by: Joelle van Dyne
---
meson.build | 2 ++
1 file changed, 2 insertions(+)
diff --git a/meson.build b/meson.build
index 900dbc36c8..d8951d4d6c 100644
--- a/meson.build
+++ b/meson.build
@@ -1205,6 +1205,8 @@ if have_system
slirp_deps = []
if targetos == 'windows'
slirp_deps = cc.find_library('iphlpapi')
+elif targetos == 'darwin'
+ slirp_deps = cc.find_library('resolv')
endif
slirp_conf = configuration_data()
slirp_conf.set('SLIRP_MAJOR_VERSION',
meson.project_version().split('.')[0])
--
2.28.0
[PATCH v6 1/7] configure: option to disable host block devices
Some hosts (iOS) have a sandboxed filesystem and do not provide low-level
APIs for interfacing with host block devices.
Signed-off-by: Joelle van Dyne
---
configure| 4
meson.build | 1 +
qapi/block-core.json | 10 +++---
block/file-posix.c | 10 +-
4 files changed, 21 insertions(+), 4 deletions(-)
diff --git a/configure b/configure
index 3f823ed163..7cd2ee0b9c 100755
--- a/configure
+++ b/configure
@@ -451,6 +451,7 @@ skip_meson=no
gettext=""
fuse="auto"
fuse_lseek="auto"
+host_block_device_support="yes"
bogus_os="no"
malloc_trim="auto"
@@ -5937,6 +5938,9 @@ if test "$default_devices" = "yes" ; then
else
echo "CONFIG_MINIKCONF_MODE=--allnoconfig" >> $config_host_mak
fi
+if test "$host_block_device_support" = "yes" ; then
+ echo "CONFIG_HOST_BLOCK_DEVICE=y" >> $config_host_mak
+fi
if test "$debug_tcg" = "yes" ; then
echo "CONFIG_DEBUG_TCG=y" >> $config_host_mak
fi
diff --git a/meson.build b/meson.build
index f344b25955..9a640d3407 100644
--- a/meson.build
+++ b/meson.build
@@ -2219,6 +2219,7 @@ summary_info += {'vvfat support':
config_host.has_key('CONFIG_VVFAT')}
summary_info += {'qed support': config_host.has_key('CONFIG_QED')}
summary_info += {'parallels support': config_host.has_key('CONFIG_PARALLELS')}
summary_info += {'sheepdog support': config_host.has_key('CONFIG_SHEEPDOG')}
+summary_info += {'host block dev support':
config_host.has_key('CONFIG_HOST_BLOCK_DEVICE')}
summary_info += {'capstone': capstone_opt == 'disabled' ? false :
capstone_opt}
summary_info += {'libpmem support': config_host.has_key('CONFIG_LIBPMEM')}
summary_info += {'libdaxctl support': config_host.has_key('CONFIG_LIBDAXCTL')}
diff --git a/qapi/block-core.json b/qapi/block-core.json
index 04c5196e59..516b823461 100644
--- a/qapi/block-core.json
+++ b/qapi/block-core.json
@@ -959,7 +959,8 @@
'discriminator': 'driver',
'data': {
'file': 'BlockStatsSpecificFile',
- 'host_device': 'BlockStatsSpecificFile',
+ 'host_device': { 'type': 'BlockStatsSpecificFile',
+ 'if': 'defined(CONFIG_HOST_BLOCK_DEVICE)' },
'nvme': 'BlockStatsSpecificNvme' } }
##
@@ -2827,7 +2828,9 @@
{ 'enum': 'BlockdevDriver',
'data': [ 'blkdebug', 'blklogwrites', 'blkreplay', 'blkverify', 'bochs',
'cloop', 'compress', 'copy-on-read', 'dmg', 'file', 'ftp', 'ftps',
-'gluster', 'host_cdrom', 'host_device', 'http', 'https', 'iscsi',
+'gluster', 'host_cdrom',
+{'name': 'host_device', 'if': 'defined(CONFIG_HOST_BLOCK_DEVICE)'
},
+'http', 'https', 'iscsi',
'luks', 'nbd', 'nfs', 'null-aio', 'null-co', 'nvme', 'parallels',
'qcow', 'qcow2', 'qed', 'quorum', 'raw', 'rbd',
{ 'name': 'replication', 'if': 'defined(CONFIG_REPLICATION)' },
@@ -3995,7 +3998,8 @@
'ftps': 'BlockdevOptionsCurlFtps',
'gluster':'BlockdevOptionsGluster',
'host_cdrom': 'BlockdevOptionsFile',
- 'host_device':'BlockdevOptionsFile',
+ 'host_device': { 'type': 'BlockdevOptionsFile',
+ 'if': 'defined(CONFIG_HOST_BLOCK_DEVICE)' },
'http': 'BlockdevOptionsCurlHttp',
'https': 'BlockdevOptionsCurlHttps',
'iscsi': 'BlockdevOptionsIscsi',
diff --git a/block/file-posix.c b/block/file-posix.c
index 83e2cc5530..c34bb9fac1 100644
--- a/block/file-posix.c
+++ b/block/file-posix.c
@@ -41,7 +41,7 @@
#include "scsi/pr-manager.h"
#include "scsi/constants.h"
-#if defined(__APPLE__) && (__MACH__)
+#if defined(CONFIG_HOST_BLOCK_DEVICE) && defined(__APPLE__) && (__MACH__)
#include
#include
#include
@@ -3014,6 +3014,7 @@ static BlockStatsSpecific
*raw_get_specific_stats(BlockDriverState *bs)
return stats;
}
+#if defined(CONFIG_HOST_BLOCK_DEVICE)
static BlockStatsSpecific *hdev_get_specific_stats(BlockDriverState *bs)
{
BlockStatsSpecific *stats = g_new(BlockStatsSpecific, 1);
@@ -3023,6 +3024,7 @@ static BlockStatsSpecific
*hdev_get_specific_stats(BlockDriverState *bs)
return stats;
}
+#endif /* CONFIG_HOST_BLOCK_DEVICE */
static QemuOptsList raw_create_opts = {
.name = "raw-create-opts",
@@ -3247,6 +3249,8 @@ BlockDriver bdrv_file = {
/***/
/* host device */
+#if defined(CONFIG_HOST_BLOCK_DEVICE)
+
#if defined(__APPLE__) && defined(__MACH__)
static kern_return_t GetBSDPath(io_iterator_t mediaIterator, char *bsdPath,
CFIndex maxPathSize, int flags);
@@ -3872,6 +3876,8 @@ static BlockDriver bdrv_host_cdrom = {
};
#endif /* __FreeBSD__ */
+#endif /* CONFIG_HOST_BLOCK_DEVICE */
+
static void bdrv_file_init(void)
{
/*
@@ -3879,6 +3885,7 @@ static void bdrv_file_init(void)
* registered last will get probed first.
*/
bdrv_register(&bdrv_file);
+#if defined(CONFIG_HOST_BLOCK_DEVICE)
bdrv_register(&bdrv_host_device);
#ifdef __linux__
Re: [PATCH v2] tcg: Fix execution on Apple Silicon
Tested-by: Joelle van Dyne
It works for me. But one thing is that if you build it with the macOS
11.x SDK it won't run on < 11.x. This is why apple recommends
something like:
if (__builtin_available(macOS 11, *)) {
pthread_jit_write_protect_np();
}
You still need a compile time check like MAC_OS_VERSION_11_0 to
support linking with older SDKs.
On Sun, Jan 3, 2021 at 6:54 AM Roman Bolshakov wrote:
>
> Pages can't be both write and executable at the same time on Apple
> Silicon. macOS provides public API to switch write protection [1] for
> JIT applications, like TCG.
>
> 1.
> https://developer.apple.com/documentation/apple_silicon/porting_just-in-time_compilers_to_apple_silicon
>
> Signed-off-by: Roman Bolshakov
> ---
> v1: https://lists.gnu.org/archive/html/qemu-devel/2021-01/msg00073.html
> Changes since v1:
>
> - Pruned not needed fiddling with W^X and dropped symmetry from write
>lock/unlock and renamed related functions.
>Similar approach is used in JavaScriptCore [1].
>
> - Moved jit helper functions to util/osdep
>
> As
> outlined in osdep.h, this matches to (2):
>
>
>* In an ideal world this
> header would contain only:
> * (1) things which everybody needs
>
>* (2) things without which code would work on
> most platforms but
> * fail to compile or misbehave on a minority of host
> OSes
>
> - Fixed a checkpatch error
>
> - Limit new behaviour only to macOS 11.0 and above, because of the
>following declarations:
>
>__API_AVAILABLE(macos(11.0))
>__API_UNAVAILABLE(ios, tvos, watchos)
>void pthread_jit_write_protect_np(int enabled);
>
>__API_AVAILABLE(macos(11.0))
>__API_UNAVAILABLE(ios, tvos, watchos)
>int pthread_jit_write_protect_supported_np(void);
>
> 1. https://bugs.webkit.org/attachment.cgi?id=402515&action=prettypatch
>
> accel/tcg/cpu-exec.c | 2 ++
> accel/tcg/translate-all.c | 6 ++
> include/qemu/osdep.h | 3 +++
> tcg/tcg.c | 1 +
> util/osdep.c | 22 ++
> 5 files changed, 34 insertions(+)
>
> diff --git a/accel/tcg/cpu-exec.c b/accel/tcg/cpu-exec.c
> index 8689c54499..374060eb45 100644
> --- a/accel/tcg/cpu-exec.c
> +++ b/accel/tcg/cpu-exec.c
> @@ -175,6 +175,7 @@ static inline tcg_target_ulong cpu_tb_exec(CPUState *cpu,
> TranslationBlock *itb)
> }
> #endif /* DEBUG_DISAS */
>
> +qemu_thread_jit_execute();
> ret = tcg_qemu_tb_exec(env, tb_ptr);
> cpu->can_do_io = 1;
> last_tb = (TranslationBlock *)(ret & ~TB_EXIT_MASK);
> @@ -382,6 +383,7 @@ static inline void tb_add_jump(TranslationBlock *tb, int
> n,
> {
> uintptr_t old;
>
> +qemu_thread_jit_write();
> assert(n < ARRAY_SIZE(tb->jmp_list_next));
> qemu_spin_lock(&tb_next->jmp_lock);
>
> diff --git a/accel/tcg/translate-all.c b/accel/tcg/translate-all.c
> index b7d50a73d4..88ae5d35ef 100644
> --- a/accel/tcg/translate-all.c
> +++ b/accel/tcg/translate-all.c
> @@ -1072,6 +1072,9 @@ static inline void *alloc_code_gen_buffer(void)
> size_t size = tcg_ctx->code_gen_buffer_size;
> void *buf;
>
> +#if defined(__APPLE__) && defined(MAC_OS_VERSION_11_0)
> +flags |= MAP_JIT;
> +#endif
> buf = mmap(NULL, size, prot, flags, -1, 0);
> if (buf == MAP_FAILED) {
> return NULL;
> @@ -1485,7 +1488,9 @@ static void do_tb_phys_invalidate(TranslationBlock *tb,
> bool rm_from_page_list)
>
> static void tb_phys_invalidate__locked(TranslationBlock *tb)
> {
> +qemu_thread_jit_write();
> do_tb_phys_invalidate(tb, true);
> +qemu_thread_jit_execute();
> }
>
> /* invalidate one TB
> @@ -1687,6 +1692,7 @@ TranslationBlock *tb_gen_code(CPUState *cpu,
> #endif
>
> assert_memory_lock();
> +qemu_thread_jit_write();
>
> phys_pc = get_page_addr_code(env, pc);
>
> diff --git a/include/qemu/osdep.h b/include/qemu/osdep.h
> index f9ec8c84e9..89abebcf5d 100644
> --- a/include/qemu/osdep.h
> +++ b/include/qemu/osdep.h
> @@ -686,4 +686,7 @@ char *qemu_get_host_name(Error **errp);
> */
> size_t qemu_get_host_physmem(void);
>
> +void qemu_thread_jit_write(void);
> +void qemu_thread_jit_execute(void);
> +
> #endif
> diff --git a/tcg/tcg.c b/tcg/tcg.c
> index 43c6cf8f52..ab8488f5d5 100644
> --- a/tcg/tcg.c
> +++ b/tcg/tcg.c
> @@ -1065,6 +1065,7 @@ void tc
Re: [PATCH v3 3/8] acpi/gpex: Inform os to keep firmware resource map
On 2021/1/5 8:35, Igor Mammedov wrote: > On Wed, 30 Dec 2020 16:22:08 -0500 > "Michael S. Tsirkin" wrote: > >> On Tue, Dec 29, 2020 at 02:41:42PM +0100, Igor Mammedov wrote: >>> On Wed, 23 Dec 2020 17:08:31 +0800 >>> Jiahui Cen wrote: >>> There may be some differences in pci resource assignment between guest os and firmware. Eg. A Bridge with Bus [d2] -+-[:d2]---01.0-[d3]01.0 where [d2:01.00] is a pcie-pci-bridge with BAR0 (mem, 64-bit, non-pref) [size=256] [d3:01.00] is a PCI Device with BAR0 (mem, 64-bit, pref) [size=128K] BAR4 (mem, 64-bit, pref) [size=64M] In EDK2, the Resource Map would be: PciBus: Resource Map for Bridge [D2|01|00] Type = PMem64; Base = 0x800400; Length = 0x410; Alignment = 0x3FF Base = 0x800400; Length = 0x400; Alignment = 0x3FF; Owner = PCI [D3|01|00:20] Base = 0x800800; Length = 0x2; Alignment = 0x1;Owner = PCI [D3|01|00:10] Type = Mem64; Base = 0x800810; Length = 0x100; Alignment = 0xFFF It would use 0x410 to calculate the root bus's PMem64 resource window. While in Linux, kernel will use 0x1FF as the alignment to calculate the PMem64 size, which would be 0x600. So kernel would try to allocate 0x600 from the PMem64 resource window, but since the window size is 0x410 as assigned by EDK2, the allocation would fail. The diffences could result in resource assignment failure. Using _DSM #5 method to inform guest os not to ignore the PCI configuration that firmware has done at boot time could handle the differences. >>> >>> I'm not sure about this one, >>> OS should able to reconfigure PCI resources according to what and where is >>> plugged >>> (and it even more true is hotplug is taken into account) >> >> spec says this: >> >> 0: No (The operating system must not ignore the PCI configuration that >> firmware has done >> at boot time. However, the operating system is free to configure the devices >> in this hierarchy >> that have not been configured by the firmware. There may be a reduced level >> of hot plug >> capability support in this hierarchy due to resource constraints. This >> situation is the same as >> the legacy situation where this _DSM is not provided.) >> 1: Yes (The operating system may ignore the PCI configuration that the >> firmware has done >> at boot time, and reconfigure/rebalance the resources in the hierarchy.) > I sort of convinced my self that's is just hotplug work might need to > implement reconfiguration > in guest kernel and maybe QEMU > > Though I have a question, > > 1. does it work for PC machine with current kernel, if so why? > 2. what it would take to make it work for arm/virt? > 1. For x86, it generally keeps the configuration by firmware, so there is nothing wrong for PC machine. 2. We add DSM method in DSDT to inform guest to keep firmware's configuration, just like x86. >> and >> >> IMPLEMENTATION NOTE >> This _DSM function provides backwards compatibility on platforms that can >> run legacy operating >> systems. >> Operating systems for two different architectures (e.g., x86 and x64) can be >> installed on a platform. >> The firmware cannot distinguish the operating system in time to change the >> boot configuration of >> devices. Say for instance, an x86 operating system in non-PAE mode is >> installed on a system. The >> x86 operating system cannot access device resource space above 4 GiB. So the >> firmware is required >> to configure devices at boot time using addresses below 4 GiB. On the other >> hand, if an x64 >> operating system is installed on this system, it can access device resources >> above the 4 GiB so it does >> not want the firmware to constrain the resource assignment below 4 GiB that >> the firmware >> configures at boot time. It is not possible for the firmware to change this >> by the time it boots the >> operating system. Ignoring the configurations done by firmware at boot time >> will allow the >> operating system to push resource assignment using addresses above 4 GiB for >> an x64 operating >> system while constrain it to addresses below 4 GiB for an x86 operating >> system. >> >> so fundamentally, saying "1" here just means "you can ignore what >> firmware configured if you like". >> >> >> I have a different question though: our CRS etc is based on what >> firmware configured. Is that ok? Or is ACPI expected to somehow >> reconfigure itself when OS reconfigures devices? >> Think it's ok but could not find documentation either way. > > guest consume DSDT only at boot time, > reconfiguration can done later by PCI subsystem without > ACPI (at least it used to be so). > >
Re: [PULL 00/35] MIPS patches for 2021-01-03
Hi, Philippe and Peter,
On Tue, Jan 5, 2021 at 2:30 AM Philippe Mathieu-Daudé wrote:
>
> On 1/4/21 7:24 PM, Philippe Mathieu-Daudé wrote:
> > On 1/4/21 6:39 PM, Philippe Mathieu-Daudé wrote:
> >> On 1/4/21 4:01 PM, Peter Maydell wrote:
> >>> On Mon, 4 Jan 2021 at 13:59, Philippe Mathieu-Daudé
> >>> wrote:
> I don't have access to OSX host. I'll see to install an aarch32 chroot
> and
> keep testing (not sure what can differ from an i386 guest).
> If I can't find anything I'll resend the same series without the
> Loongson-3
> machine, which is the single part adding QOM objects.
> >
> > OK I guess I found the problem, we have:
> >
> > struct LoongsonMachineState {
> > MachineState parent_obj;
> > MemoryRegion *pio_alias;
> > MemoryRegion *mmio_alias;
> > MemoryRegion *ecam_alias;
> > };
> >
> > Then:
> >
> > static inline void loongson3_virt_devices_init(MachineState *machine,
> >DeviceState *pic)
> > {
> > int i;
> > qemu_irq irq;
> > PCIBus *pci_bus;
> > DeviceState *dev;
> > MemoryRegion *mmio_reg, *ecam_reg;
> > LoongsonMachineState *s = LOONGSON_MACHINE(machine);
> >
> > LoongsonMachineState is never allocated... Accessing its MR lead
> > to BOF.
>
> I'm going to respin with this (pass 32-bit tests):
>
> -- >8 --
> diff --git a/hw/mips/loongson3_virt.c b/hw/mips/loongson3_virt.c
> index e3723d3dd0f..d4a82fa5367 100644
> --- a/hw/mips/loongson3_virt.c
> +++ b/hw/mips/loongson3_virt.c
> @@ -612,8 +612,10 @@ static void mips_loongson3_virt_init(MachineState
> *machine)
> loongson3_virt_devices_init(machine, liointc);
> }
>
> -static void mips_loongson3_virt_machine_init(MachineClass *mc)
> +static void loongson3v_machine_class_init(ObjectClass *oc, void *data)
> {
> +MachineClass *mc = MACHINE_CLASS(oc);
> +
> mc->desc = "Loongson-3 Virtualization Platform";
> mc->init = mips_loongson3_virt_init;
> mc->block_default_type = IF_IDE;
> @@ -624,4 +626,13 @@ static void
> mips_loongson3_virt_machine_init(MachineClass *mc)
> mc->minimum_page_bits = 14;
> }
>
> -DEFINE_MACHINE("loongson3-virt", mips_loongson3_virt_machine_init)
> +static const TypeInfo loongson3_machine_types[] = {
> +{
> +.name = TYPE_LOONGSON_MACHINE,
> +.parent = TYPE_MACHINE,
> +.instance_size = sizeof(LoongsonMachineState),
> +.class_init = loongson3v_machine_class_init,
> +}
> +};
> +
> +DEFINE_TYPES(loongson3_machine_types)
> ---
>
> Thanks Peter for catching this (we really need a 32-bit host runner
> on GitLab...).
>
Should I send a new version?
Huacai
> Phil.
Re: [PATCH v3 3/8] acpi/gpex: Inform os to keep firmware resource map
On Wed, 30 Dec 2020 16:22:08 -0500 "Michael S. Tsirkin" wrote: > On Tue, Dec 29, 2020 at 02:41:42PM +0100, Igor Mammedov wrote: > > On Wed, 23 Dec 2020 17:08:31 +0800 > > Jiahui Cen wrote: > > > > > There may be some differences in pci resource assignment between guest os > > > and firmware. > > > > > > Eg. A Bridge with Bus [d2] > > > -+-[:d2]---01.0-[d3]01.0 > > > > > > where [d2:01.00] is a pcie-pci-bridge with BAR0 (mem, 64-bit, > > > non-pref) [size=256] > > > [d3:01.00] is a PCI Device with BAR0 (mem, 64-bit, pref) > > > [size=128K] > > > BAR4 (mem, 64-bit, pref) > > > [size=64M] > > > > > > In EDK2, the Resource Map would be: > > > PciBus: Resource Map for Bridge [D2|01|00] > > > Type = PMem64; Base = 0x800400; Length = 0x410; > > > Alignment = 0x3FF > > >Base = 0x800400; Length = 0x400; Alignment = > > > 0x3FF; Owner = PCI [D3|01|00:20] > > >Base = 0x800800; Length = 0x2; Alignment = > > > 0x1;Owner = PCI [D3|01|00:10] > > > Type = Mem64; Base = 0x800810; Length = 0x100; Alignment > > > = 0xFFF > > > It would use 0x410 to calculate the root bus's PMem64 resource > > > window. > > > > > > While in Linux, kernel will use 0x1FF as the alignment to > > > calculate > > > the PMem64 size, which would be 0x600. So kernel would try to > > > allocate 0x600 from the PMem64 resource window, but since the > > > window > > > size is 0x410 as assigned by EDK2, the allocation would fail. > > > > > > The diffences could result in resource assignment failure. > > > > > > Using _DSM #5 method to inform guest os not to ignore the PCI > > > configuration > > > that firmware has done at boot time could handle the differences. > > > > I'm not sure about this one, > > OS should able to reconfigure PCI resources according to what and where is > > plugged > > (and it even more true is hotplug is taken into account) > > spec says this: > > 0: No (The operating system must not ignore the PCI configuration that > firmware has done > at boot time. However, the operating system is free to configure the devices > in this hierarchy > that have not been configured by the firmware. There may be a reduced level > of hot plug > capability support in this hierarchy due to resource constraints. This > situation is the same as > the legacy situation where this _DSM is not provided.) > 1: Yes (The operating system may ignore the PCI configuration that the > firmware has done > at boot time, and reconfigure/rebalance the resources in the hierarchy.) I sort of convinced my self that's is just hotplug work might need to implement reconfiguration in guest kernel and maybe QEMU Though I have a question, 1. does it work for PC machine with current kernel, if so why? 2. what it would take to make it work for arm/virt? > and > > IMPLEMENTATION NOTE > This _DSM function provides backwards compatibility on platforms that can run > legacy operating > systems. > Operating systems for two different architectures (e.g., x86 and x64) can be > installed on a platform. > The firmware cannot distinguish the operating system in time to change the > boot configuration of > devices. Say for instance, an x86 operating system in non-PAE mode is > installed on a system. The > x86 operating system cannot access device resource space above 4 GiB. So the > firmware is required > to configure devices at boot time using addresses below 4 GiB. On the other > hand, if an x64 > operating system is installed on this system, it can access device resources > above the 4 GiB so it does > not want the firmware to constrain the resource assignment below 4 GiB that > the firmware > configures at boot time. It is not possible for the firmware to change this > by the time it boots the > operating system. Ignoring the configurations done by firmware at boot time > will allow the > operating system to push resource assignment using addresses above 4 GiB for > an x64 operating > system while constrain it to addresses below 4 GiB for an x86 operating > system. > > so fundamentally, saying "1" here just means "you can ignore what > firmware configured if you like". > > > I have a different question though: our CRS etc is based on what > firmware configured. Is that ok? Or is ACPI expected to somehow > reconfigure itself when OS reconfigures devices? > Think it's ok but could not find documentation either way. guest consume DSDT only at boot time, reconfiguration can done later by PCI subsystem without ACPI (at least it used to be so). However DSM is dynamic, and maybe evaluated at runtime, though I don't know if kernel would re-evaluate this feature bit after boot > > > > > > > > Signed-off-by: Jiahui Cen > > > --- > > > hw/pci-host/gpex-acpi.c | 18 -- > > > 1 file changed, 1
Re: [PATCH v3 5/8] acpi/gpex: Append pxb devs in ascending order
On Wed, 30 Dec 2020 16:17:14 -0500
"Michael S. Tsirkin" wrote:
> On Tue, Dec 29, 2020 at 02:47:35PM +0100, Igor Mammedov wrote:
> > On Wed, 23 Dec 2020 17:08:33 +0800
> > Jiahui Cen wrote:
> >
> > > The overlap check of IO resource window would fail when Linux kernel
> > > registers an IO resource [b, c) earlier than another resource [a, b).
> > > Though this incorrect check could be fixed by [1], it would be better to
> > > append pxb devs into DSDT table in ascending order.
> > >
> > > [1]:
> > > https://lore.kernel.org/lkml/20201218062335.5320-1-cenjia...@huawei.com/
> >
> > considering there is acceptable fix for kernel I'd rather avoid
> > workarounds on QEMU side. So I suggest dropping this patch.
>
> Well there's something to be said for a defined order of things.
> And patch is from Dec 2020 will take ages for guests to be fixed,
> and changing pci core on stable kernels is risky and needs
> a ton of testing, not done eaily ...
> Which guests are affected by the bug?
it's workaround for a trivial bug for niche configuration
for a new QEMU feature that never worked for arm/virt machine
Downstream that think that it is important enough to support
can backport and test patch thus helping stable trees to merge
it sooner.
> There are also some issues with the patch see below.
>
> > it also should reduce noise in [8/8] masking other changes.
> >
> > > Signed-off-by: Jiahui Cen
> > > ---
> > > hw/pci-host/gpex-acpi.c | 11 +--
> > > 1 file changed, 9 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/hw/pci-host/gpex-acpi.c b/hw/pci-host/gpex-acpi.c
> > > index 4bf1e94309..95a7a0f12b 100644
> > > --- a/hw/pci-host/gpex-acpi.c
> > > +++ b/hw/pci-host/gpex-acpi.c
> > > @@ -141,7 +141,7 @@ static void acpi_dsdt_add_pci_osc(Aml *dev)
> > > void acpi_dsdt_add_gpex(Aml *scope, struct GPEXConfig *cfg)
> > > {
> > > int nr_pcie_buses = cfg->ecam.size / PCIE_MMCFG_SIZE_MIN;
> > > -Aml *method, *crs, *dev, *rbuf;
> > > +Aml *method, *crs, *dev, *rbuf, *pxb_devs[nr_pcie_buses];
>
> dynamically sized array on stack poses security issues
>
> > > PCIBus *bus = cfg->bus;
> > > CrsRangeSet crs_range_set;
> > > CrsRangeEntry *entry;
> > > @@ -149,6 +149,7 @@ void acpi_dsdt_add_gpex(Aml *scope, struct GPEXConfig
> > > *cfg)
> > >
> > > /* start to construct the tables for pxb */
> > > crs_range_set_init(&crs_range_set);
> > > +memset(pxb_devs, 0, sizeof(pxb_devs));
> > > if (bus) {
> > > QLIST_FOREACH(bus, &bus->child, sibling) {
> > > uint8_t bus_num = pci_bus_num(bus);
> > > @@ -190,7 +191,7 @@ void acpi_dsdt_add_gpex(Aml *scope, struct GPEXConfig
> > > *cfg)
> > >
> > > acpi_dsdt_add_pci_osc(dev);
> > >
> > > -aml_append(scope, dev);
> > > +pxb_devs[bus_num] = dev;
>
> If bus numbers intersect this will overwrite old one.
> I'd rather not worry about it, just have an array
> of structs with bus numbers and sort it.
>
>
> > > }
> > > }
> > >
> > > @@ -278,5 +279,11 @@ void acpi_dsdt_add_gpex(Aml *scope, struct
> > > GPEXConfig *cfg)
> > > aml_append(dev, dev_res0);
> > > aml_append(scope, dev);
> > >
> > > +for (i = 0; i < ARRAY_SIZE(pxb_devs); i++) {
> > > +if (pxb_devs[i]) {
> > > +aml_append(scope, pxb_devs[i]);
> > > +}
> > > +}
>
>
> so this sorts them by bus number not by io address.
> Probably happens to help since bios numbers them in the same order ...
> Is there a way to address this more robustly in case
> bios changes? E.g. I see the bug is only in PIO so sort by that address maybe?
>
> Also pls add a code comment explaining why we are doing all this
> with link to patch, which guests are affected etc.
>
> > > +
> > > crs_range_set_free(&crs_range_set);
> > > }
>
>
Re: [PATCH v5 0/2] util/oslib: qemu_try_memalign() improvements
On 12/16/20 9:24 AM, Richard Henderson wrote: > On 10/21/20 12:38 PM, Philippe Mathieu-Daudé wrote: >> - Use _aligned_malloc for qemu_try_memalign on win32 >> - Assert qemu_try_memalign() alignment is a power of 2 >> >> Since v4: >> - Drop superfluous assert (Richard) >> >> Philippe Mathieu-Daudé (1): >> util/oslib: Assert qemu_try_memalign() alignment is a power of 2 >> >> Richard Henderson (1): >> util/oslib-win32: Use _aligned_malloc for qemu_try_memalign >> >> util/oslib-posix.c | 2 ++ >> util/oslib-win32.c | 12 +--- >> 2 files changed, 7 insertions(+), 7 deletions(-) >> > > Ping. Ping2. Shall I just queue this to tcg-next? r~
Re: [PATCH 0/2] tcg: Eliminate scratch regs from i386 backend
Ping? On 12/10/20 3:14 PM, Richard Henderson wrote: > Eliminating these cleans up the backend a bit, allows the > code generator more freedom to properly place the inputs. > > > r~ > > > Richard Henderson (2): > tcg/i386: Adjust TCG_TARGET_HAS_MEMORY_BSWAP > tcg: Introduce INDEX_op_qemu_st8_i32 > > include/tcg/tcg-opc.h | 5 ++ > tcg/aarch64/tcg-target.h | 1 + > tcg/arm/tcg-target.h | 1 + > tcg/i386/tcg-target.h | 6 +- > tcg/mips/tcg-target.h | 1 + > tcg/ppc/tcg-target.h | 1 + > tcg/riscv/tcg-target.h| 1 + > tcg/s390/tcg-target.h | 1 + > tcg/sparc/tcg-target.h| 1 + > tcg/tci/tcg-target.h | 1 + > tcg/optimize.c| 1 + > tcg/tcg-op.c | 6 +- > tcg/tcg.c | 4 ++ > tcg/README| 5 ++ > tcg/i386/tcg-target.c.inc | 138 -- > 15 files changed, 91 insertions(+), 82 deletions(-) >
Re: [PATCH v4 1/4] ppc440_pcix: Improve comment for IRQ mapping
On Mon, 4 Jan 2021 at 23:23, BALATON Zoltan wrote:
>
> The code mapping all PCI interrupts to a single CPU IRQ works but is
> not trivial so document it in a comment.
>
> Signed-off-by: BALATON Zoltan
> ---
> hw/ppc/ppc440_pcix.c | 11 +--
> 1 file changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/hw/ppc/ppc440_pcix.c b/hw/ppc/ppc440_pcix.c
> index ee952314c8..eb1290ffc8 100644
> --- a/hw/ppc/ppc440_pcix.c
> +++ b/hw/ppc/ppc440_pcix.c
> @@ -415,8 +415,15 @@ static void ppc440_pcix_reset(DeviceState *dev)
> s->sts = 0;
> }
>
> -/* All pins from each slot are tied to a single board IRQ.
> - * This may need further refactoring for other boards. */
> +/*
> + * All four IRQ[ABCD] pins from all slots are tied to a single board
> + * IRQ, so our mapping function here maps everything to IRQ 0.
> + * The code in pci_change_irq_level() tracks the number of times
> + * the mapped IRQ is asserted and deasserted, so if multiple devices
> + * assert an IRQ at the same time the behaviour is correct.
> + *
> + * This may need further refactoring for boards that use multiple IRQ lines.
> + */
> static int ppc440_pcix_map_irq(PCIDevice *pci_dev, int irq_num)
> {
> trace_ppc440_pcix_map_irq(pci_dev->devfn, irq_num, 0);
> --
Reviewed-by: Peter Maydell
thanks
-- PMM
[PATCH, BUILD-FIX] linux-user: Conditionalize TUNSETVNETLE
This fixes the build for older ppc64 kernel headers. Fixes: 6addf06a3c4 Cc: Josh Kunz Cc: Shu-Chun Weng Cc: Laurent Vivier Signed-off-by: Richard Henderson --- linux-user/ioctls.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/linux-user/ioctls.h b/linux-user/ioctls.h index 661b5daa9f..7193c3b226 100644 --- a/linux-user/ioctls.h +++ b/linux-user/ioctls.h @@ -748,8 +748,10 @@ IOCTL(TUNSETQUEUE, IOC_W, MK_PTR(MK_STRUCT(STRUCT_short_ifreq))) IOCTL(TUNSETIFINDEX , IOC_W, MK_PTR(TYPE_INT)) /* TUNGETFILTER is not supported: see TUNATTACHFILTER. */ +#ifdef TUNSETVNETLE IOCTL(TUNSETVNETLE,IOC_W, MK_PTR(TYPE_INT)) IOCTL(TUNGETVNETLE,IOC_R, MK_PTR(TYPE_INT)) +#endif #ifdef TUNSETVNETBE IOCTL(TUNSETVNETBE,IOC_W, MK_PTR(TYPE_INT)) IOCTL(TUNGETVNETBE,IOC_R, MK_PTR(TYPE_INT)) -- 2.25.1
Re: [PATCH 5/5] i386: provide simple 'hyperv=on' option to x86 machine types
On Mon, 4 Jan 2021 13:29:06 -0500
Eduardo Habkost wrote:
> On Mon, Jan 04, 2021 at 01:54:32PM +0100, Vitaly Kuznetsov wrote:
> > Igor Mammedov writes:
> >
> > >> >
> > >> > +/* Hyper-V features enabled with 'hyperv=on' */
> > >> > +x86mc->default_hyperv_features = BIT(HYPERV_FEAT_RELAXED) |
> > >> > +BIT(HYPERV_FEAT_VAPIC) | BIT(HYPERV_FEAT_TIME) |
> > >> > +BIT(HYPERV_FEAT_CRASH) | BIT(HYPERV_FEAT_RESET) |
> > >> > +BIT(HYPERV_FEAT_VPINDEX) | BIT(HYPERV_FEAT_RUNTIME) |
> > >> > +BIT(HYPERV_FEAT_SYNIC) | BIT(HYPERV_FEAT_STIMER) |
> > >> > +BIT(HYPERV_FEAT_FREQUENCIES) |
> > >> > BIT(HYPERV_FEAT_REENLIGHTENMENT) |
> > >> > +BIT(HYPERV_FEAT_TLBFLUSH) | BIT(HYPERV_FEAT_EVMCS) |
> > >> > +BIT(HYPERV_FEAT_IPI) | BIT(HYPERV_FEAT_STIMER_DIRECT);
> > > I'd argue that feature bits do not belong to machine code at all.
> > > If we have to involve machine at all then it should be a set
> > > property/value pairs
> > > that machine will set on CPU object (I'm not convinced that doing it
> > > from machine code is good idea though).
> > >
> >
> > These are 'features' and not feature bits. 'Bits' here are just our
> > internal (to QEMU) representation of which features are enable and which
> > are not, we could've just used booleans instead. These feature, when
> > enabled, will result in some CPUID changes (not 1:1) but I don't see how
> > it's different from
> >
> > " -machine q35,accel=kvm "
> >
> > which also results in CPUID changes.
>
> This is a good point, although having accel affect CPUID bits was
> also a source of complexity for query-cpu-model-expansion and
> other QMP queries.
why was, it's still a headache (mutating CPU models depending on accelerator)
>
> >
> > The main reason for putting this to x86 machine type is versioning, as
> > we go along we will (hopefully) be implementing more and more Hyper-V
> > features but we want to provide 'one knob to rule them all' but do it in
> > a way that will allow migration. We already have 'hv_passthrough' for
> > CPU.
>
> I agree completely that the set of bits needs to be on
> MachineClass. We just need to agree on the external interface.
That's where I disagree,
let me exaggerate for demo purpose:
- let's move all CPU models feature defaults to MachineClass and forget about
compat properties
since in that case we can opencode changes in machine_class_init
It's rather hard code integration between device models, which we try
to avoid and still refactoring QEMU code to get rid of it.
(sure it works until it's not and someone else need to rewrite half of QEMU
to accomplish it's own task because we mixed things together)
>
> >
> > >> >
> > >> > +if (x86ms->hyperv_enabled) {
> > >> > +feat = x86mc->default_hyperv_features;
> > >> > +/* Enlightened VMCS is only available on Intel/VMX */
> > >> > +if (!cpu_has_vmx(&cpu->env)) {
> > >> > +feat &= ~BIT(HYPERV_FEAT_EVMCS);
> > >> > +}
> > >> > +
> > >> > +cpu->hyperv_features |= feat;
> > > that will ignore features user explicitly doesn't want,
> > > ex:
> > > -machine hyperv=on -cpu foo,hv-foo=off
> > >
> >
> > Existing 'hv_passthrough' mode can also affect the result. Personally, I
> > don't see where 'hv-foo=off' is needed outside of debugging and these
> > use-cases can probably be covered by explicitly listing required
> > features but I'm not against making this work, shouldn't be hard.
>
> I'm all for not wasting time supporting use cases that are not
> necessary in practice. We just need to document the expected
> behavior clearly, whatever we decide to do.
documenting is good, but if it adds new semantics to how CPU features are
handled
users up the stack will need code it up as well and juggle with
-machine + -cpu + -device cpu-foo
not to mention poor developers who will have to figure out why we do
set CPU properties in multiple different ways.
however if we add it as CPU properties that behave the same way as other
properties, all mgmt has to do is expose new property to user for usage.
it even more true when building machine from QMP interface would be available,
where we would want '-device foo' more or less the same way instead of
special casing some of them, i.e. I'd rather have one device to configure,
instead of doing it in multiple places. It's not possible in reality
but for new code we should try to minimize split brain issues.
> >
> > > not sure we would like to introduce such invariant,
> > > in normal qom property handling the latest set property should have effect
> > > (all other invariants we have in x86 cpu property semantics are comming
> > > from legacy handling
> > > and I plan to deprecate them (it will affect x86 and sparc cpus) so CPUs
> > > will behave like
> > > any other QOM object when it come to property handling)
> > >
> > > anyways it's confusing a bit to have cpu flags to come from 2 different
Re: [PATCH v3 05/15] hw/mips/boston: Check 64-bit support with cpu_type_is_64bit()
On 1/4/21 12:11 PM, Philippe Mathieu-Daudé wrote: > Directly check if the CPU supports 64-bit with the recently > added cpu_type_is_64bit() helper (inlined). > > Signed-off-by: Philippe Mathieu-Daudé > --- > hw/mips/boston.c | 6 ++ > 1 file changed, 2 insertions(+), 4 deletions(-) Reviewed-by: Richard Henderson r~
Re: [PATCH v3 03/15] target/mips/mips-defs: Rename CPU_MIPSxx Release 1 as CPU_MIPSxxR1
On 1/4/21 12:11 PM, Philippe Mathieu-Daudé wrote: > 'CPU_MIPS32' and 'CPU_MIPS64' definitions concern CPUs implementing > the "Release 1" ISA. Rename it with the 'R1' suffix, as the other > CPU definitions do. > > Signed-off-by: Philippe Mathieu-Daudé > --- > target/mips/mips-defs.h | 8 > target/mips/translate_init.c.inc | 14 +++--- > 2 files changed, 11 insertions(+), 11 deletions(-) Reviewed-by: Richard Henderson r~
Re: [PATCH 01/22] hw/block: m25p80: Add ISSI SPI flash support
Hi Francisco,
On Tue, Jan 5, 2021 at 12:00 AM Francisco Iglesias
wrote:
>
> Hi Bin,
>
> On [2020 Dec 31] Thu 19:29:49, Bin Meng wrote:
> > From: Bin Meng
> >
> > This adds the ISSI SPI flash support. The number of dummy cycles in
> > fast read, fast read dual output and fast read quad output commands
> > is currently using the default 8. Per the datasheet [1], the number
> > of dummy cycles configurable, but this is not modeled.
> >
> > For flash whose size is larger than 16 MiB, the sequence of 3-byte
> > address along with EXTADD bit in the bank address register (BAR) is
> > not supported. Currently we assume that guest software will alawys
> > use op codes with 4-byte address sequence. Fortunately this is the
> > case for both U-Boot and Linux.
> >
> > [1] http://www.issi.com/WW/pdf/25LP-WP256.pdf
> >
> > Signed-off-by: Bin Meng
> > ---
> >
> > hw/block/m25p80.c | 38 +-
> > 1 file changed, 37 insertions(+), 1 deletion(-)
> >
> > diff --git a/hw/block/m25p80.c b/hw/block/m25p80.c
> > index 844cabea21..8a62bc4bc4 100644
> > --- a/hw/block/m25p80.c
> > +++ b/hw/block/m25p80.c
> > @@ -411,6 +411,7 @@ typedef enum {
> > MAN_NUMONYX,
> > MAN_WINBOND,
> > MAN_SST,
> > +MAN_ISSI,
> > MAN_GENERIC,
> > } Manufacturer;
> >
> > @@ -486,6 +487,8 @@ static inline Manufacturer get_man(Flash *s)
> > return MAN_MACRONIX;
> > case 0xBF:
> > return MAN_SST;
> > +case 0x9D:
> > +return MAN_ISSI;
> > default:
> > return MAN_GENERIC;
> > }
> > @@ -705,6 +708,9 @@ static void complete_collecting_data(Flash *s)
> > case MAN_SPANSION:
> > s->quad_enable = !!(s->data[1] & 0x02);
> > break;
> > +case MAN_ISSI:
> > +s->quad_enable = extract32(s->data[0], 6, 1);
> > +break;
> > case MAN_MACRONIX:
> > s->quad_enable = extract32(s->data[0], 6, 1);
> > if (s->len > 1) {
> > @@ -897,6 +903,16 @@ static void decode_fast_read_cmd(Flash *s)
> > SPANSION_DUMMY_CLK_LEN
> > );
> > break;
> > +case MAN_ISSI:
> > +/*
> > + * The fast read instruction code is followed by address bytes and
> > + * dummy cycles, transmitted via the SI line.
> > + *
> > + * The number of dummy cycles are configurable but this is
> > currently
> > + * unmodeled, hence the default value 8 is used.
> > + */
> > +s->needed_bytes += ((8 * 1) / 8);
>
> According to how m25p80 models dummy clock cycles above
> means that the command is being modeled with 1 dummy clock cycle (and below is
> modeling the dio/qio commands with 1 and 3 dummy clock cycles). To model
> the command with 8 dummy clock cycles you only add +8 above (+4 and +6
> would be the values to add below). One can look into how one of the other
> flashes model the commands for examples. This might also mean that the
> controller will need a change and do the opposite what above calculation
> does, and convert the dummy bytes into dummy clock cycles (when
> transmitting on 1 line it generates 8 dummy clock cycles for each dummy
> byte, when it uses 2 lines it generates 4 etc..).
>
I now am more inclined to say something is wrong in the Xilinx SPI
models and I just don't have time to check what is wrong there. As I
mentioned here [1] for SPI controllers that use fifo to stuff the
dummy bits on the line, there is no way for hardware to tell what is
dummy bits in the fifo or not. The hardware just sends whatever in the
fifo which is prepared by the software. Hence the only way to get such
hardware to work is to use bytes, instead of bits in QEMU.
[1]
http://patchwork.ozlabs.org/project/qemu-devel/patch/1606704602-59435-1-git-send-email-bmeng...@gmail.com/
Regards,
Bin
Re: [PATCH v3 04/15] target/mips/mips-defs: Introduce CPU_MIPS64 and cpu_type_is_64bit()
On 1/4/21 12:11 PM, Philippe Mathieu-Daudé wrote: > MIPS 64-bit ISA is introduced with MIPS3. > > Introduce the CPU_MIPS64 definition aliased to the MIPS3 ISA, > and the cpu_type_is_64bit() method to check if a CPU supports > this ISA (thus is 64-bit). > > Suggested-by: Jiaxun Yang > Signed-off-by: Philippe Mathieu-Daudé > --- > target/mips/cpu.h | 5 + > target/mips/mips-defs.h | 4 +++- > 2 files changed, 8 insertions(+), 1 deletion(-) I still don't understand this as an alias, as opposed to a separate bit. (ISA_MIPS3 | CPU_MIPS64R6) does not make sense, because R6 removes instructions. But if this is an intermediate step, Reviewed-by: Richard Henderson r~
Re: [PATCH v3 01/15] target/mips/mips-defs: Remove USE_HOST_FLOAT_REGS comment
On 1/4/21 12:11 PM, Philippe Mathieu-Daudé wrote: > Remove a comment added 12 years ago but never used (commit > b6d96beda3a: "Use temporary registers for the MIPS FPU emulation"). > > Signed-off-by: Philippe Mathieu-Daudé > --- > target/mips/mips-defs.h | 6 -- > 1 file changed, 6 deletions(-) Reviewed-by: Richard Henderson r~
[PATCH v4 3/4] ppc440_pcix: Fix up pci config access
This fixes a long standing issue with MorphOS booting on sam460ex
which turns out to be because of suspicious values written to PCI
config address that apparently works on real machine but caused wrong
access on this device model. This replaces a previous work around for
this with a better fix that makes it work.
Signed-off-by: BALATON Zoltan
---
hw/ppc/ppc440_pcix.c | 37 ++---
1 file changed, 22 insertions(+), 15 deletions(-)
diff --git a/hw/ppc/ppc440_pcix.c b/hw/ppc/ppc440_pcix.c
index 7829d3e556..91cbcd0504 100644
--- a/hw/ppc/ppc440_pcix.c
+++ b/hw/ppc/ppc440_pcix.c
@@ -449,28 +449,35 @@ static AddressSpace *ppc440_pcix_set_iommu(PCIBus *b,
void *opaque, int devfn)
return &s->bm_as;
}
-/* The default pci_host_data_{read,write} functions in pci/pci_host.c
- * deny access to registers without bit 31 set but our clients want
- * this to work so we have to override these here */
-static void pci_host_data_write(void *opaque, hwaddr addr,
-uint64_t val, unsigned len)
+/*
+ * Some guests on sam460ex write all kinds of garbage here such as
+ * missing enable bit and low bits set and still expect this to work
+ * (apparently it does on real hardware because these boot there) so
+ * we have to override these ops here and fix it up
+ */
+static void pci_host_config_write(void *opaque, hwaddr addr,
+ uint64_t val, unsigned len)
{
PCIHostState *s = opaque;
-pci_data_write(s->bus, s->config_reg | (addr & 3), val, len);
+
+if (addr != 0 || len != 4) {
+return;
+}
+s->config_reg = (val & 0xfffcULL) | (1UL << 31);
}
-static uint64_t pci_host_data_read(void *opaque,
- hwaddr addr, unsigned len)
+static uint64_t pci_host_config_read(void *opaque, hwaddr addr,
+ unsigned len)
{
PCIHostState *s = opaque;
-uint32_t val;
-val = pci_data_read(s->bus, s->config_reg | (addr & 3), len);
+uint32_t val = s->config_reg;
+
return val;
}
-const MemoryRegionOps ppc440_pcix_host_data_ops = {
-.read = pci_host_data_read,
-.write = pci_host_data_write,
+const MemoryRegionOps ppc440_pcix_host_conf_ops = {
+.read = pci_host_config_read,
+.write = pci_host_config_write,
.endianness = DEVICE_LITTLE_ENDIAN,
};
@@ -497,9 +504,9 @@ static void ppc440_pcix_realize(DeviceState *dev, Error
**errp)
pci_setup_iommu(h->bus, ppc440_pcix_set_iommu, s);
memory_region_init(&s->container, OBJECT(s), "pci-container",
PCI_ALL_SIZE);
-memory_region_init_io(&h->conf_mem, OBJECT(s), &pci_host_conf_le_ops,
+memory_region_init_io(&h->conf_mem, OBJECT(s), &ppc440_pcix_host_conf_ops,
h, "pci-conf-idx", 4);
-memory_region_init_io(&h->data_mem, OBJECT(s), &ppc440_pcix_host_data_ops,
+memory_region_init_io(&h->data_mem, OBJECT(s), &pci_host_data_le_ops,
h, "pci-conf-data", 4);
memory_region_init_io(&s->iomem, OBJECT(s), &pci_reg_ops, s,
"pci.reg", PPC440_REG_SIZE);
--
2.21.3
[PATCH v4 4/4] sam460ex: Use type cast macro instead of simple cast
Use the PCI_BUS type cast macro to convert result of
qdev_get_child_bus(). Also remove the check for NULL afterwards which
should not be needed because sysbus_create_simple() uses error_abort
and PCI_BUS macro also checks its argument by default so this
shouldn't fail here.
Signed-off-by: BALATON Zoltan
---
hw/ppc/sam460ex.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/hw/ppc/sam460ex.c b/hw/ppc/sam460ex.c
index 14e6583eb0..cc67e9c39b 100644
--- a/hw/ppc/sam460ex.c
+++ b/hw/ppc/sam460ex.c
@@ -384,11 +384,8 @@ static void sam460ex_init(MachineState *machine)
ppc460ex_pcie_init(env);
/* All PCI irqs are connected to the same UIC pin (cf. UBoot source) */
dev = sysbus_create_simple("ppc440-pcix-host", 0xc0ec0, uic[1][0]);
-pci_bus = (PCIBus *)qdev_get_child_bus(dev, "pci.0");
-if (!pci_bus) {
-error_report("couldn't create PCI controller!");
-exit(1);
-}
+pci_bus = PCI_BUS(qdev_get_child_bus(dev, "pci.0"));
+
memory_region_init_alias(isa, NULL, "isa_mmio", get_system_io(),
0, 0x1);
memory_region_add_subregion(get_system_memory(), 0xc0800, isa);
--
2.21.3
[PATCH v4 2/4] ppc440_pcix: Fix register write trace event
The trace event for pci_host_config_write() was also using the trace
event for read. Add corresponding trace and correct this.
Signed-off-by: BALATON Zoltan
Reviewed-by: Philippe Mathieu-Daudé
---
hw/ppc/ppc440_pcix.c | 2 +-
hw/ppc/trace-events | 1 +
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/hw/ppc/ppc440_pcix.c b/hw/ppc/ppc440_pcix.c
index eb1290ffc8..7829d3e556 100644
--- a/hw/ppc/ppc440_pcix.c
+++ b/hw/ppc/ppc440_pcix.c
@@ -169,7 +169,7 @@ static void ppc440_pcix_reg_write4(void *opaque, hwaddr
addr,
{
struct PPC440PCIXState *s = opaque;
-trace_ppc440_pcix_reg_read(addr, val);
+trace_ppc440_pcix_reg_write(addr, val, size);
switch (addr) {
case PCI_VENDOR_ID ... PCI_MAX_LAT:
stl_le_p(s->dev->config + addr, val);
diff --git a/hw/ppc/trace-events b/hw/ppc/trace-events
index ed05f2fc9a..017c48624f 100644
--- a/hw/ppc/trace-events
+++ b/hw/ppc/trace-events
@@ -117,3 +117,4 @@ ppc440_pcix_set_irq(int irq_num) "PCI irq %d"
ppc440_pcix_update_pim(int idx, uint64_t size, uint64_t la) "Added window %d
of size=0x%" PRIx64 " to CPU=0x%" PRIx64
ppc440_pcix_update_pom(int idx, uint32_t size, uint64_t la, uint64_t pcia)
"Added window %d of size=0x%x from CPU=0x%" PRIx64 " to PCI=0x%" PRIx64
ppc440_pcix_reg_read(uint64_t addr, uint32_t val) "addr 0x%" PRIx64 " = 0x%"
PRIx32
+ppc440_pcix_reg_write(uint64_t addr, uint32_t val, uint32_t size) "addr 0x%"
PRIx64 " = 0x%" PRIx32 " size 0x%" PRIx32
--
2.21.3
[PATCH v4 0/4] Misc sam460ex fixes (was: Clean up sam460ex irq mapping)
Changes from v3: - removed first two patches changing Kconfig because the FDT one seems to be needed so we should not remove those from KConfig and there was some question about patch 1 - added a new patch to use type cast macro in sam460ex.c - the other 3 patches should be the same as in v3 Regards, BALATON Zoltan BALATON Zoltan (4): ppc440_pcix: Improve comment for IRQ mapping ppc440_pcix: Fix register write trace event ppc440_pcix: Fix up pci config access sam460ex: Use type cast macro instead of simple cast hw/ppc/ppc440_pcix.c | 50 hw/ppc/sam460ex.c| 7 ++- hw/ppc/trace-events | 1 + 3 files changed, 35 insertions(+), 23 deletions(-) -- 2.21.3
[PATCH v4 1/4] ppc440_pcix: Improve comment for IRQ mapping
The code mapping all PCI interrupts to a single CPU IRQ works but is
not trivial so document it in a comment.
Signed-off-by: BALATON Zoltan
---
hw/ppc/ppc440_pcix.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/hw/ppc/ppc440_pcix.c b/hw/ppc/ppc440_pcix.c
index ee952314c8..eb1290ffc8 100644
--- a/hw/ppc/ppc440_pcix.c
+++ b/hw/ppc/ppc440_pcix.c
@@ -415,8 +415,15 @@ static void ppc440_pcix_reset(DeviceState *dev)
s->sts = 0;
}
-/* All pins from each slot are tied to a single board IRQ.
- * This may need further refactoring for other boards. */
+/*
+ * All four IRQ[ABCD] pins from all slots are tied to a single board
+ * IRQ, so our mapping function here maps everything to IRQ 0.
+ * The code in pci_change_irq_level() tracks the number of times
+ * the mapped IRQ is asserted and deasserted, so if multiple devices
+ * assert an IRQ at the same time the behaviour is correct.
+ *
+ * This may need further refactoring for boards that use multiple IRQ lines.
+ */
static int ppc440_pcix_map_irq(PCIDevice *pci_dev, int irq_num)
{
trace_ppc440_pcix_map_irq(pci_dev->devfn, irq_num, 0);
--
2.21.3
Re: [PATCH 5/5] i386: provide simple 'hyperv=on' option to x86 machine types
On Mon, 04 Jan 2021 13:54:32 +0100
Vitaly Kuznetsov wrote:
> Igor Mammedov writes:
>
> >> >
> >> > +/* Hyper-V features enabled with 'hyperv=on' */
> >> > +x86mc->default_hyperv_features = BIT(HYPERV_FEAT_RELAXED) |
> >> > +BIT(HYPERV_FEAT_VAPIC) | BIT(HYPERV_FEAT_TIME) |
> >> > +BIT(HYPERV_FEAT_CRASH) | BIT(HYPERV_FEAT_RESET) |
> >> > +BIT(HYPERV_FEAT_VPINDEX) | BIT(HYPERV_FEAT_RUNTIME) |
> >> > +BIT(HYPERV_FEAT_SYNIC) | BIT(HYPERV_FEAT_STIMER) |
> >> > +BIT(HYPERV_FEAT_FREQUENCIES) | BIT(HYPERV_FEAT_REENLIGHTENMENT)
> >> > |
> >> > +BIT(HYPERV_FEAT_TLBFLUSH) | BIT(HYPERV_FEAT_EVMCS) |
> >> > +BIT(HYPERV_FEAT_IPI) | BIT(HYPERV_FEAT_STIMER_DIRECT);
> > I'd argue that feature bits do not belong to machine code at all.
> > If we have to involve machine at all then it should be a set property/value
> > pairs
> > that machine will set on CPU object (I'm not convinced that doing it
> > from machine code is good idea though).
> >
>
> These are 'features' and not feature bits. 'Bits' here are just our
> internal (to QEMU) representation of which features are enable and which
> are not, we could've just used booleans instead. These feature, when
> enabled, will result in some CPUID changes (not 1:1) but I don't see how
> it's different from
>
> " -machine q35,accel=kvm "
>
> which also results in CPUID changes.
>
> The main reason for putting this to x86 machine type is versioning, as
> we go along we will (hopefully) be implementing more and more Hyper-V
> features but we want to provide 'one knob to rule them all' but do it in
> a way that will allow migration. We already have 'hv_passthrough' for
> CPU.
for versioning device models (cpu included), we typically set some default in
device's ininfn, and if later on we need to change it to another default
we use compat properties to keep old default to old machine types.
For example using it with CPU look at pc_compat_3_1
>
> >> >
> >> > +if (x86ms->hyperv_enabled) {
> >> > +feat = x86mc->default_hyperv_features;
> >> > +/* Enlightened VMCS is only available on Intel/VMX */
> >> > +if (!cpu_has_vmx(&cpu->env)) {
> >> > +feat &= ~BIT(HYPERV_FEAT_EVMCS);
> >> > +}
> >> > +
> >> > +cpu->hyperv_features |= feat;
> > that will ignore features user explicitly doesn't want,
> > ex:
> > -machine hyperv=on -cpu foo,hv-foo=off
> >
>
> Existing 'hv_passthrough' mode can also affect the result. Personally, I
> don't see where 'hv-foo=off' is needed outside of debugging and these
> use-cases can probably be covered by explicitly listing required
> features but I'm not against making this work, shouldn't be hard.
there is a lot of way to implement something, in this case point is to
keep it consistent with the way we handle cpu features/properties.
And not to make up new semantics unless there is no other way.
> > not sure we would like to introduce such invariant,
> > in normal qom property handling the latest set property should have effect
> > (all other invariants we have in x86 cpu property semantics are comming
> > from legacy handling
> > and I plan to deprecate them (it will affect x86 and sparc cpus) so CPUs
> > will behave like
> > any other QOM object when it come to property handling)
> >
> > anyways it's confusing a bit to have cpu flags to come from 2 different
> > places
> >
> > -cpu hyperv-use-preset=on,hv-foo=off
> >
> > looks less confusing and will heave expected effect
> >
>
> Honestly, 'hyperv-use-preset' is confusing even to me :-)
that was just an example
>
> What if we for a second stop thinking about Hyper-V features being CPU
> features only, e.g. if we want to create Dynamic Memory or PTP or any
> other Hyper-V specific device in a simple way? We'll have to put these
> under machine type.
ideally it would be a property of device that implements the feature
and machine might enable it depending on its own properties defaults,
but if you change the default behavior of the device model, you do
it in device model and use compat properties infrastructure to keep
old machine types happy.
>
Re: [PATCH v2 3/3] hw/i386: expose a "smbios-ep" PC machine property
On Mon, 14 Dec 2020 15:50:29 -0500
Eduardo Habkost wrote:
> From: Daniel P. Berrangé
>
> The i440fx and Q35 machine types are both hardcoded to use the legacy
> SMBIOS 2.1 entry point. This is a sensible conservative choice because
> SeaBIOS only supports SMBIOS 2.1
>
> EDK2, however, can also support SMBIOS 3.0 and QEMU already uses this on
> the ARM virt machine type.
>
> This adds a property to allow the choice of SMBIOS entry point versions
> For example to opt in to version 3.0
>
>$QEMU -machine q35,smbios-ep=3_0
>
> Signed-off-by: Daniel P. Berrangé
> Signed-off-by: Eduardo Habkost
Reviewed-by: Igor Mammedov
> ---
> This is patch was previously submitted at:
> https://lore.kernel.org/qemu-devel/20200908165438.1008942-6-berra...@redhat.com
>
> Changes from v1:
> * Include qapi-visit-smbios.h instead of qapi-visit-machine.h
> * Commit message fix: s/smbios_ep/smbios-ep/
> ---
> include/hw/i386/pc.h | 3 +++
> hw/i386/pc.c | 26 ++
> hw/i386/pc_piix.c| 2 +-
> hw/i386/pc_q35.c | 2 +-
> 4 files changed, 31 insertions(+), 2 deletions(-)
>
> diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h
> index 2aa8797c6e..2075093b32 100644
> --- a/include/hw/i386/pc.h
> +++ b/include/hw/i386/pc.h
> @@ -11,6 +11,7 @@
> #include "hw/acpi/acpi_dev_interface.h"
> #include "hw/hotplug.h"
> #include "qom/object.h"
> +#include "hw/firmware/smbios.h"
>
> #define HPET_INTCAP "hpet-intcap"
>
> @@ -38,6 +39,7 @@ typedef struct PCMachineState {
> /* Configuration options: */
> uint64_t max_ram_below_4g;
> OnOffAuto vmport;
> +SmbiosEntryPointType smbios_ep;
>
> bool acpi_build_enabled;
> bool smbus_enabled;
> @@ -62,6 +64,7 @@ typedef struct PCMachineState {
> #define PC_MACHINE_SATA "sata"
> #define PC_MACHINE_PIT "pit"
> #define PC_MACHINE_MAX_FW_SIZE "max-fw-size"
> +#define PC_MACHINE_SMBIOS_EP"smbios-ep"
>
> /**
> * PCMachineClass:
> diff --git a/hw/i386/pc.c b/hw/i386/pc.c
> index 640fb5b0b7..3cc559e0d9 100644
> --- a/hw/i386/pc.c
> +++ b/hw/i386/pc.c
> @@ -81,6 +81,7 @@
> #include "hw/mem/nvdimm.h"
> #include "qapi/error.h"
> #include "qapi/qapi-visit-common.h"
> +#include "qapi/qapi-visit-smbios.h"
> #include "qapi/visitor.h"
> #include "hw/core/cpu.h"
> #include "hw/usb.h"
> @@ -1532,6 +1533,23 @@ static void pc_machine_set_hpet(Object *obj, bool
> value, Error **errp)
> pcms->hpet_enabled = value;
> }
>
> +static void pc_machine_get_smbios_ep(Object *obj, Visitor *v, const char
> *name,
> + void *opaque, Error **errp)
> +{
> +PCMachineState *pcms = PC_MACHINE(obj);
> +SmbiosEntryPointType smbios_ep = pcms->smbios_ep;
> +
> +visit_type_SmbiosEntryPointType(v, name, &smbios_ep, errp);
> +}
> +
> +static void pc_machine_set_smbios_ep(Object *obj, Visitor *v, const char
> *name,
> + void *opaque, Error **errp)
> +{
> +PCMachineState *pcms = PC_MACHINE(obj);
> +
> +visit_type_SmbiosEntryPointType(v, name, &pcms->smbios_ep, errp);
> +}
> +
> static void pc_machine_get_max_ram_below_4g(Object *obj, Visitor *v,
> const char *name, void *opaque,
> Error **errp)
> @@ -1621,6 +1639,8 @@ static void pc_machine_initfn(Object *obj)
> pcms->vmport = ON_OFF_AUTO_OFF;
> #endif /* CONFIG_VMPORT */
> pcms->max_ram_below_4g = 0; /* use default */
> +pcms->smbios_ep = SMBIOS_ENTRY_POINT_TYPE_2_1;
> +
> /* acpi build is enabled by default if machine supports it */
> pcms->acpi_build_enabled = PC_MACHINE_GET_CLASS(pcms)->has_acpi_build;
> pcms->smbus_enabled = true;
> @@ -1759,6 +1779,12 @@ static void pc_machine_class_init(ObjectClass *oc,
> void *data)
> NULL, NULL);
> object_class_property_set_description(oc, PC_MACHINE_MAX_FW_SIZE,
> "Maximum combined firmware size");
> +
> +object_class_property_add(oc, PC_MACHINE_SMBIOS_EP, "str",
> +pc_machine_get_smbios_ep, pc_machine_set_smbios_ep,
> +NULL, NULL);
> +object_class_property_set_description(oc, PC_MACHINE_SMBIOS_EP,
> +"SMBIOS Entry Point version [v2_1, v3_0]");
> }
>
> static const TypeInfo pc_machine_info = {
> diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
> index 08b82df4d1..30ae7f27af 100644
> --- a/hw/i386/pc_piix.c
> +++ b/hw/i386/pc_piix.c
> @@ -179,7 +179,7 @@ static void pc_init1(MachineState *machine,
> smbios_set_defaults("QEMU", "Standard PC (i440FX + PIIX, 1996)",
> mc->name, pcmc->smbios_legacy_mode,
> pcmc->smbios_uuid_encoded,
> -SMBIOS_ENTRY_POINT_TYPE_2_1);
> +pcms->smbios_ep);
> }
>
> /* allocate ram and load rom/bios */
> diff --git a/hw/i386/pc_q35.c b/hw/i386/pc_q35.c
> index f71b1e2dcf..99
[PATCH v3 13/15] target/mips/mips-defs: Rename ISA_MIPS32R3 as ISA_MIPS_R3
The MIPS ISA release 3 is common to 32/64-bit CPUs. To avoid holes in the insn_flags type, update the definition with the next available bit. Reviewed-by: Richard Henderson Signed-off-by: Philippe Mathieu-Daudé --- target/mips/mips-defs.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/target/mips/mips-defs.h b/target/mips/mips-defs.h index d1eeb69dfd7..12ff2b3280c 100644 --- a/target/mips/mips-defs.h +++ b/target/mips/mips-defs.h @@ -18,7 +18,7 @@ #define ISA_MIPS5 0x0010ULL #define ISA_MIPS_R1 0x0020ULL #define ISA_MIPS_R2 0x0040ULL -#define ISA_MIPS32R3 0x0200ULL +#define ISA_MIPS_R3 0x0080ULL #define ISA_MIPS32R5 0x0800ULL #define ISA_MIPS32R6 0x2000ULL #define ISA_NANOMIPS320x8000ULL @@ -77,7 +77,7 @@ #define CPU_MIPS64R2(CPU_MIPS64R1 | CPU_MIPS32R2) /* MIPS Technologies "Release 3" */ -#define CPU_MIPS32R3(CPU_MIPS32R2 | ISA_MIPS32R3) +#define CPU_MIPS32R3(CPU_MIPS32R2 | ISA_MIPS_R3) #define CPU_MIPS64R3(CPU_MIPS64R2 | CPU_MIPS32R3) /* MIPS Technologies "Release 5" */ -- 2.26.2
[PATCH v3 14/15] target/mips/mips-defs: Rename ISA_MIPS32R5 as ISA_MIPS_R5
The MIPS ISA release 5 is common to 32/64-bit CPUs.
To avoid holes in the insn_flags type, update the
definition with the next available bit.
Reviewed-by: Richard Henderson
Signed-off-by: Philippe Mathieu-Daudé
---
target/mips/mips-defs.h | 4 ++--
target/mips/translate.c | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/target/mips/mips-defs.h b/target/mips/mips-defs.h
index 12ff2b3280c..181f3715472 100644
--- a/target/mips/mips-defs.h
+++ b/target/mips/mips-defs.h
@@ -19,7 +19,7 @@
#define ISA_MIPS_R1 0x0020ULL
#define ISA_MIPS_R2 0x0040ULL
#define ISA_MIPS_R3 0x0080ULL
-#define ISA_MIPS32R5 0x0800ULL
+#define ISA_MIPS_R5 0x0100ULL
#define ISA_MIPS32R6 0x2000ULL
#define ISA_NANOMIPS320x8000ULL
/*
@@ -81,7 +81,7 @@
#define CPU_MIPS64R3(CPU_MIPS64R2 | CPU_MIPS32R3)
/* MIPS Technologies "Release 5" */
-#define CPU_MIPS32R5(CPU_MIPS32R3 | ISA_MIPS32R5)
+#define CPU_MIPS32R5(CPU_MIPS32R3 | ISA_MIPS_R5)
#define CPU_MIPS64R5(CPU_MIPS64R3 | CPU_MIPS32R5)
/* MIPS Technologies "Release 6" */
diff --git a/target/mips/translate.c b/target/mips/translate.c
index 9c71d306ee5..83fd6c473a5 100644
--- a/target/mips/translate.c
+++ b/target/mips/translate.c
@@ -10993,7 +10993,7 @@ static void gen_cp0(CPUMIPSState *env, DisasContext
*ctx, uint32_t opc,
if (ctx->opcode & (1 << bit_shift)) {
/* OPC_ERETNC */
opn = "eretnc";
-check_insn(ctx, ISA_MIPS32R5);
+check_insn(ctx, ISA_MIPS_R5);
gen_helper_eretnc(cpu_env);
} else {
/* OPC_ERET */
--
2.26.2
[PATCH v3 12/15] target/mips/mips-defs: Rename ISA_MIPS32R2 as ISA_MIPS_R2
The MIPS ISA release 2 is common to 32/64-bit CPUs.
Reviewed-by: Richard Henderson
Signed-off-by: Philippe Mathieu-Daudé
---
target/mips/internal.h | 2 +-
target/mips/mips-defs.h| 4 +-
linux-user/mips/cpu_loop.c | 2 +-
target/mips/cp0_timer.c| 4 +-
target/mips/helper.c | 2 +-
target/mips/translate.c| 138 ++---
6 files changed, 76 insertions(+), 76 deletions(-)
diff --git a/target/mips/internal.h b/target/mips/internal.h
index 94910f75a61..23ae31ef989 100644
--- a/target/mips/internal.h
+++ b/target/mips/internal.h
@@ -407,7 +407,7 @@ static inline void compute_hflags(CPUMIPSState *env)
}
}
-if (env->insn_flags & ISA_MIPS32R2) {
+if (env->insn_flags & ISA_MIPS_R2) {
if (env->active_fpu.fcr0 & (1 << FCR0_F64)) {
env->hflags |= MIPS_HFLAG_COP1X;
}
diff --git a/target/mips/mips-defs.h b/target/mips/mips-defs.h
index a7048ffaffe..d1eeb69dfd7 100644
--- a/target/mips/mips-defs.h
+++ b/target/mips/mips-defs.h
@@ -17,7 +17,7 @@
#define ISA_MIPS4 0x0008ULL
#define ISA_MIPS5 0x0010ULL
#define ISA_MIPS_R1 0x0020ULL
-#define ISA_MIPS32R2 0x0040ULL
+#define ISA_MIPS_R2 0x0040ULL
#define ISA_MIPS32R3 0x0200ULL
#define ISA_MIPS32R5 0x0800ULL
#define ISA_MIPS32R6 0x2000ULL
@@ -73,7 +73,7 @@
#define CPU_MIPS64R1(CPU_MIPS5 | CPU_MIPS32R1)
/* MIPS Technologies "Release 2" */
-#define CPU_MIPS32R2(CPU_MIPS32R1 | ISA_MIPS32R2)
+#define CPU_MIPS32R2(CPU_MIPS32R1 | ISA_MIPS_R2)
#define CPU_MIPS64R2(CPU_MIPS64R1 | CPU_MIPS32R2)
/* MIPS Technologies "Release 3" */
diff --git a/linux-user/mips/cpu_loop.c b/linux-user/mips/cpu_loop.c
index e400166c583..748e1c664f1 100644
--- a/linux-user/mips/cpu_loop.c
+++ b/linux-user/mips/cpu_loop.c
@@ -384,7 +384,7 @@ void target_cpu_copy_regs(CPUArchState *env, struct
target_pt_regs *regs)
prog_req.frdefault &= interp_req.frdefault;
prog_req.fre &= interp_req.fre;
-bool cpu_has_mips_r2_r6 = env->insn_flags & ISA_MIPS32R2 ||
+bool cpu_has_mips_r2_r6 = env->insn_flags & ISA_MIPS_R2 ||
env->insn_flags & ISA_MIPS32R6;
if (prog_req.fre && !prog_req.frdefault && !prog_req.fr1) {
diff --git a/target/mips/cp0_timer.c b/target/mips/cp0_timer.c
index 5ec0d6249e9..70de95d338f 100644
--- a/target/mips/cp0_timer.c
+++ b/target/mips/cp0_timer.c
@@ -44,7 +44,7 @@ static void cpu_mips_timer_update(CPUMIPSState *env)
static void cpu_mips_timer_expire(CPUMIPSState *env)
{
cpu_mips_timer_update(env);
-if (env->insn_flags & ISA_MIPS32R2) {
+if (env->insn_flags & ISA_MIPS_R2) {
env->CP0_Cause |= 1 << CP0Ca_TI;
}
qemu_irq_raise(env->irq[(env->CP0_IntCtl >> CP0IntCtl_IPTI) & 0x7]);
@@ -93,7 +93,7 @@ void cpu_mips_store_compare(CPUMIPSState *env, uint32_t value)
if (!(env->CP0_Cause & (1 << CP0Ca_DC))) {
cpu_mips_timer_update(env);
}
-if (env->insn_flags & ISA_MIPS32R2) {
+if (env->insn_flags & ISA_MIPS_R2) {
env->CP0_Cause &= ~(1 << CP0Ca_TI);
}
qemu_irq_lower(env->irq[(env->CP0_IntCtl >> CP0IntCtl_IPTI) & 0x7]);
diff --git a/target/mips/helper.c b/target/mips/helper.c
index 5b74815beb0..98d6ecaa65e 100644
--- a/target/mips/helper.c
+++ b/target/mips/helper.c
@@ -431,7 +431,7 @@ void cpu_mips_store_cause(CPUMIPSState *env, target_ulong
val)
uint32_t old = env->CP0_Cause;
int i;
-if (env->insn_flags & ISA_MIPS32R2) {
+if (env->insn_flags & ISA_MIPS_R2) {
mask |= 1 << CP0Ca_DC;
}
if (env->insn_flags & ISA_MIPS32R6) {
diff --git a/target/mips/translate.c b/target/mips/translate.c
index a59fbd94bac..9c71d306ee5 100644
--- a/target/mips/translate.c
+++ b/target/mips/translate.c
@@ -7612,7 +7612,7 @@ static void gen_mfc0(DisasContext *ctx, TCGv arg, int
reg, int sel)
register_name = "PageMask";
break;
case CP0_REG05__PAGEGRAIN:
-check_insn(ctx, ISA_MIPS32R2);
+check_insn(ctx, ISA_MIPS_R2);
gen_mfc0_load32(arg, offsetof(CPUMIPSState, CP0_PageGrain));
register_name = "PageGrain";
break;
@@ -7660,27 +7660,27 @@ static void gen_mfc0(DisasContext *ctx, TCGv arg, int
reg, int sel)
register_name = "Wired";
break;
case CP0_REG06__SRSCONF0:
-check_insn(ctx, ISA_MIPS32R2);
+check_insn(ctx, ISA_MIPS_R2);
gen_mfc0_load32(arg, offsetof(CPUMIPSState, CP0_SRSConf0));
register_name = "SRSConf0";
break;
case CP0_REG06__SRSCONF1:
-check_insn(ctx, ISA_MIPS32R2);
+check_insn(ctx, ISA_MIPS_R2);
gen_mfc0_load32(arg, offsetof(CPUMIPSState, CP0_SRSConf1));
register_name = "SRSConf1";
break;
case CP0
[PATCH v3 10/15] target/mips/mips-defs: Use ISA_MIPS32R6 definition to check Release 6
Use the single ISA_MIPS32R6 definition to check if the Release 6
ISA is supported, whether the CPU support 32/64-bit.
For now we keep '32' in the definition name, we will rename it
as ISA_MIPS_R6 in few commits.
Reviewed-by: Richard Henderson
Signed-off-by: Philippe Mathieu-Daudé
---
target/mips/internal.h | 2 +-
target/mips/mips-defs.h| 3 +--
linux-user/mips/cpu_loop.c | 3 +--
target/mips/helper.c | 6 +++---
target/mips/translate.c| 2 +-
5 files changed, 7 insertions(+), 9 deletions(-)
diff --git a/target/mips/internal.h b/target/mips/internal.h
index e4d2d9f44f9..3466725b761 100644
--- a/target/mips/internal.h
+++ b/target/mips/internal.h
@@ -354,7 +354,7 @@ static inline void compute_hflags(CPUMIPSState *env)
} else if (((env->hflags & MIPS_HFLAG_KSU) == MIPS_HFLAG_UM) &&
!(env->CP0_Status & (1 << CP0St_UX))) {
env->hflags |= MIPS_HFLAG_AWRAP;
-} else if (env->insn_flags & ISA_MIPS64R6) {
+} else if (env->insn_flags & ISA_MIPS32R6) {
/* Address wrapping for Supervisor and Kernel is specified in R6 */
if env->hflags & MIPS_HFLAG_KSU) == MIPS_HFLAG_SM) &&
!(env->CP0_Status & (1 << CP0St_SX))) ||
diff --git a/target/mips/mips-defs.h b/target/mips/mips-defs.h
index b71127ddd7c..fea547508f0 100644
--- a/target/mips/mips-defs.h
+++ b/target/mips/mips-defs.h
@@ -21,7 +21,6 @@
#define ISA_MIPS32R3 0x0200ULL
#define ISA_MIPS32R5 0x0800ULL
#define ISA_MIPS32R6 0x2000ULL
-#define ISA_MIPS64R6 0x4000ULL
#define ISA_NANOMIPS320x8000ULL
/*
* bits 24-39: MIPS ASEs
@@ -87,7 +86,7 @@
/* MIPS Technologies "Release 6" */
#define CPU_MIPS32R6(CPU_MIPS32R5 | ISA_MIPS32R6)
-#define CPU_MIPS64R6(CPU_MIPS64R5 | CPU_MIPS32R6 | ISA_MIPS64R6)
+#define CPU_MIPS64R6(CPU_MIPS64R5 | CPU_MIPS32R6)
/* Wave Computing: "nanoMIPS" */
#define CPU_NANOMIPS32 (CPU_MIPS32R6 | ISA_NANOMIPS32)
diff --git a/linux-user/mips/cpu_loop.c b/linux-user/mips/cpu_loop.c
index f0831379cc4..e400166c583 100644
--- a/linux-user/mips/cpu_loop.c
+++ b/linux-user/mips/cpu_loop.c
@@ -385,8 +385,7 @@ void target_cpu_copy_regs(CPUArchState *env, struct
target_pt_regs *regs)
prog_req.fre &= interp_req.fre;
bool cpu_has_mips_r2_r6 = env->insn_flags & ISA_MIPS32R2 ||
- env->insn_flags & ISA_MIPS32R6 ||
- env->insn_flags & ISA_MIPS64R6;
+ env->insn_flags & ISA_MIPS32R6;
if (prog_req.fre && !prog_req.frdefault && !prog_req.fr1) {
env->CP0_Config5 |= (1 << CP0C5_FRE);
diff --git a/target/mips/helper.c b/target/mips/helper.c
index 87296fbad69..5b74815beb0 100644
--- a/target/mips/helper.c
+++ b/target/mips/helper.c
@@ -1145,7 +1145,7 @@ void mips_cpu_do_interrupt(CPUState *cs)
enter_debug_mode:
if (env->insn_flags & ISA_MIPS3) {
env->hflags |= MIPS_HFLAG_64;
-if (!(env->insn_flags & ISA_MIPS64R6) ||
+if (!(env->insn_flags & ISA_MIPS32R6) ||
env->CP0_Status & (1 << CP0St_KX)) {
env->hflags &= ~MIPS_HFLAG_AWRAP;
}
@@ -1174,7 +1174,7 @@ void mips_cpu_do_interrupt(CPUState *cs)
env->CP0_Status |= (1 << CP0St_ERL) | (1 << CP0St_BEV);
if (env->insn_flags & ISA_MIPS3) {
env->hflags |= MIPS_HFLAG_64;
-if (!(env->insn_flags & ISA_MIPS64R6) ||
+if (!(env->insn_flags & ISA_MIPS32R6) ||
env->CP0_Status & (1 << CP0St_KX)) {
env->hflags &= ~MIPS_HFLAG_AWRAP;
}
@@ -1360,7 +1360,7 @@ void mips_cpu_do_interrupt(CPUState *cs)
env->CP0_Status |= (1 << CP0St_EXL);
if (env->insn_flags & ISA_MIPS3) {
env->hflags |= MIPS_HFLAG_64;
-if (!(env->insn_flags & ISA_MIPS64R6) ||
+if (!(env->insn_flags & ISA_MIPS32R6) ||
env->CP0_Status & (1 << CP0St_KX)) {
env->hflags &= ~MIPS_HFLAG_AWRAP;
}
diff --git a/target/mips/translate.c b/target/mips/translate.c
index 9fc9dedf30d..fc93b9da8eb 100644
--- a/target/mips/translate.c
+++ b/target/mips/translate.c
@@ -31438,7 +31438,7 @@ static void mips_tr_init_disas_context(DisasContextBase
*dcbase, CPUState *cs)
#else
ctx->mem_idx = hflags_mmu_index(ctx->hflags);
#endif
-ctx->default_tcg_memop_mask = (ctx->insn_flags & (ISA_MIPS32R6 |
ISA_MIPS64R6 |
+ctx->default_tcg_memop_mask = (ctx->insn_flags & (ISA_MIPS32R6 |
INSN_LOONGSON3A)) ? MO_UNALN : MO_ALIGN;
LOG_DISAS("\ntb %p idx %d hflags %04x\n", ctx->base.tb, ctx->mem_idx,
--
2.26.2
[PATCH v3 09/15] target/mips/mips-defs: Use ISA_MIPS32R5 definition to check Release 5
Use the single ISA_MIPS32R5 definition to check if the Release 5 ISA is supported, whether the CPU support 32/64-bit. For now we keep '32' in the definition name, we will rename it as ISA_MIPS_R5 in few commits. Reviewed-by: Richard Henderson Signed-off-by: Philippe Mathieu-Daudé --- target/mips/mips-defs.h | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/target/mips/mips-defs.h b/target/mips/mips-defs.h index ccdde0b4a43..b71127ddd7c 100644 --- a/target/mips/mips-defs.h +++ b/target/mips/mips-defs.h @@ -20,7 +20,6 @@ #define ISA_MIPS32R2 0x0040ULL #define ISA_MIPS32R3 0x0200ULL #define ISA_MIPS32R5 0x0800ULL -#define ISA_MIPS64R5 0x1000ULL #define ISA_MIPS32R6 0x2000ULL #define ISA_MIPS64R6 0x4000ULL #define ISA_NANOMIPS320x8000ULL @@ -84,7 +83,7 @@ /* MIPS Technologies "Release 5" */ #define CPU_MIPS32R5(CPU_MIPS32R3 | ISA_MIPS32R5) -#define CPU_MIPS64R5(CPU_MIPS64R3 | CPU_MIPS32R5 | ISA_MIPS64R5) +#define CPU_MIPS64R5(CPU_MIPS64R3 | CPU_MIPS32R5) /* MIPS Technologies "Release 6" */ #define CPU_MIPS32R6(CPU_MIPS32R5 | ISA_MIPS32R6) -- 2.26.2
[PATCH v3 15/15] target/mips/mips-defs: Rename ISA_MIPS32R6 as ISA_MIPS_R6
The MIPS ISA release 6 is common to 32/64-bit CPUs.
To avoid holes in the insn_flags type, update the
definition with the next available bit.
Reviewed-by: Richard Henderson
Signed-off-by: Philippe Mathieu-Daudé
---
target/mips/internal.h | 4 +-
target/mips/mips-defs.h| 4 +-
linux-user/mips/cpu_loop.c | 2 +-
target/mips/cp0_helper.c | 18 +-
target/mips/cpu.c | 6 +-
target/mips/fpu_helper.c | 4 +-
target/mips/helper.c | 10 +-
target/mips/translate.c| 426 ++---
8 files changed, 237 insertions(+), 237 deletions(-)
diff --git a/target/mips/internal.h b/target/mips/internal.h
index 23ae31ef989..77a648bcf9c 100644
--- a/target/mips/internal.h
+++ b/target/mips/internal.h
@@ -354,7 +354,7 @@ static inline void compute_hflags(CPUMIPSState *env)
} else if (((env->hflags & MIPS_HFLAG_KSU) == MIPS_HFLAG_UM) &&
!(env->CP0_Status & (1 << CP0St_UX))) {
env->hflags |= MIPS_HFLAG_AWRAP;
-} else if (env->insn_flags & ISA_MIPS32R6) {
+} else if (env->insn_flags & ISA_MIPS_R6) {
/* Address wrapping for Supervisor and Kernel is specified in R6 */
if env->hflags & MIPS_HFLAG_KSU) == MIPS_HFLAG_SM) &&
!(env->CP0_Status & (1 << CP0St_SX))) ||
@@ -365,7 +365,7 @@ static inline void compute_hflags(CPUMIPSState *env)
}
#endif
if (((env->CP0_Status & (1 << CP0St_CU0)) &&
- !(env->insn_flags & ISA_MIPS32R6)) ||
+ !(env->insn_flags & ISA_MIPS_R6)) ||
!(env->hflags & MIPS_HFLAG_KSU)) {
env->hflags |= MIPS_HFLAG_CP0;
}
diff --git a/target/mips/mips-defs.h b/target/mips/mips-defs.h
index 181f3715472..97866019a72 100644
--- a/target/mips/mips-defs.h
+++ b/target/mips/mips-defs.h
@@ -20,7 +20,7 @@
#define ISA_MIPS_R2 0x0040ULL
#define ISA_MIPS_R3 0x0080ULL
#define ISA_MIPS_R5 0x0100ULL
-#define ISA_MIPS32R6 0x2000ULL
+#define ISA_MIPS_R6 0x0200ULL
#define ISA_NANOMIPS320x8000ULL
/*
* bits 24-39: MIPS ASEs
@@ -85,7 +85,7 @@
#define CPU_MIPS64R5(CPU_MIPS64R3 | CPU_MIPS32R5)
/* MIPS Technologies "Release 6" */
-#define CPU_MIPS32R6(CPU_MIPS32R5 | ISA_MIPS32R6)
+#define CPU_MIPS32R6(CPU_MIPS32R5 | ISA_MIPS_R6)
#define CPU_MIPS64R6(CPU_MIPS64R5 | CPU_MIPS32R6)
/* Wave Computing: "nanoMIPS" */
diff --git a/linux-user/mips/cpu_loop.c b/linux-user/mips/cpu_loop.c
index 748e1c664f1..19947448a25 100644
--- a/linux-user/mips/cpu_loop.c
+++ b/linux-user/mips/cpu_loop.c
@@ -385,7 +385,7 @@ void target_cpu_copy_regs(CPUArchState *env, struct
target_pt_regs *regs)
prog_req.fre &= interp_req.fre;
bool cpu_has_mips_r2_r6 = env->insn_flags & ISA_MIPS_R2 ||
- env->insn_flags & ISA_MIPS32R6;
+ env->insn_flags & ISA_MIPS_R6;
if (prog_req.fre && !prog_req.frdefault && !prog_req.fr1) {
env->CP0_Config5 |= (1 << CP0C5_FRE);
diff --git a/target/mips/cp0_helper.c b/target/mips/cp0_helper.c
index 36a92857bfb..aae2af6eccc 100644
--- a/target/mips/cp0_helper.c
+++ b/target/mips/cp0_helper.c
@@ -527,7 +527,7 @@ void helper_mtc0_index(CPUMIPSState *env, target_ulong arg1)
uint32_t index_p = env->CP0_Index & 0x8000;
uint32_t tlb_index = arg1 & 0x7fff;
if (tlb_index < env->tlb->nb_tlb) {
-if (env->insn_flags & ISA_MIPS32R6) {
+if (env->insn_flags & ISA_MIPS_R6) {
index_p |= arg1 & 0x8000;
}
env->CP0_Index = index_p | tlb_index;
@@ -960,7 +960,7 @@ void helper_mtc0_pwfield(CPUMIPSState *env, target_ulong
arg1)
uint32_t old_ptei = (env->CP0_PWField >> CP0PF_PTEI) & 0x3FULL;
uint32_t new_ptei = (arg1 >> CP0PF_PTEI) & 0x3FULL;
-if ((env->insn_flags & ISA_MIPS32R6)) {
+if ((env->insn_flags & ISA_MIPS_R6)) {
if (((arg1 >> CP0PF_BDI) & 0x3FULL) < 12) {
mask &= ~(0x3FULL << CP0PF_BDI);
}
@@ -980,7 +980,7 @@ void helper_mtc0_pwfield(CPUMIPSState *env, target_ulong
arg1)
env->CP0_PWField = arg1 & mask;
if ((new_ptei >= 32) ||
-((env->insn_flags & ISA_MIPS32R6) &&
+((env->insn_flags & ISA_MIPS_R6) &&
(new_ptei == 0 || new_ptei == 1))) {
env->CP0_PWField = (env->CP0_PWField & ~0x3FULL) |
(old_ptei << CP0PF_PTEI);
@@ -990,7 +990,7 @@ void helper_mtc0_pwfield(CPUMIPSState *env, target_ulong
arg1)
uint32_t old_ptew = (env->CP0_PWField >> CP0PF_PTEW) & 0x3F;
uint32_t new_ptew = (arg1 >> CP0PF_PTEW) & 0x3F;
-if ((env->insn_flags & ISA_MIPS32R6)) {
+if ((env->insn_flags & ISA_MIPS_R6)) {
if (((arg1 >> CP0PF_GDW) & 0x3F) < 12) {
mask &= ~(0x3F << CP0PF_GDW);
}
@@ -1007,7 +1007,7 @@ void helper_mtc0_pwfield(CPUMIPSState *env, target_ulong
arg1)
env->CP0_PWField = arg1 & mask;
if ((new_ptew >=
[PATCH v3 05/15] hw/mips/boston: Check 64-bit support with cpu_type_is_64bit()
Directly check if the CPU supports 64-bit with the recently
added cpu_type_is_64bit() helper (inlined).
Signed-off-by: Philippe Mathieu-Daudé
---
hw/mips/boston.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/hw/mips/boston.c b/hw/mips/boston.c
index c3b94c68e1b..467fbc1c8be 100644
--- a/hw/mips/boston.c
+++ b/hw/mips/boston.c
@@ -444,7 +444,6 @@ static void boston_mach_init(MachineState *machine)
DriveInfo *hd[6];
Chardev *chr;
int fw_size, fit_err;
-bool is_64b;
if ((machine->ram_size % GiB) ||
(machine->ram_size > (2 * GiB))) {
@@ -463,8 +462,6 @@ static void boston_mach_init(MachineState *machine)
exit(1);
}
-is_64b = cpu_type_supports_isa(machine->cpu_type, ISA_MIPS64);
-
object_initialize_child(OBJECT(machine), "cps", &s->cps, TYPE_MIPS_CPS);
object_property_set_str(OBJECT(&s->cps), "cpu-type", machine->cpu_type,
&error_fatal);
@@ -545,7 +542,8 @@ static void boston_mach_init(MachineState *machine)
}
gen_firmware(memory_region_get_ram_ptr(flash) + 0x7c0,
- s->kernel_entry, s->fdt_base, is_64b);
+ s->kernel_entry, s->fdt_base,
+ cpu_type_is_64bit(machine->cpu_type));
} else if (!qtest_enabled()) {
error_report("Please provide either a -kernel or -bios argument");
exit(1);
--
2.26.2
[PATCH v3 07/15] target/mips/mips-defs: Use ISA_MIPS32R2 definition to check Release 2
Use the single ISA_MIPS32R2 definition to check if the Release 2 ISA is supported, whether the CPU support 32/64-bit. For now we keep '32' in the definition name, we will rename it as ISA_MIPS_R2 in few commits. Reviewed-by: Richard Henderson Signed-off-by: Philippe Mathieu-Daudé --- target/mips/mips-defs.h| 3 +-- linux-user/mips/cpu_loop.c | 1 - target/mips/translate.c| 4 ++-- 3 files changed, 3 insertions(+), 5 deletions(-) diff --git a/target/mips/mips-defs.h b/target/mips/mips-defs.h index 23ce8b8406f..b36b59c12d3 100644 --- a/target/mips/mips-defs.h +++ b/target/mips/mips-defs.h @@ -18,7 +18,6 @@ #define ISA_MIPS5 0x0010ULL #define ISA_MIPS320x0020ULL #define ISA_MIPS32R2 0x0040ULL -#define ISA_MIPS64R2 0x0100ULL #define ISA_MIPS32R3 0x0200ULL #define ISA_MIPS64R3 0x0400ULL #define ISA_MIPS32R5 0x0800ULL @@ -78,7 +77,7 @@ /* MIPS Technologies "Release 2" */ #define CPU_MIPS32R2(CPU_MIPS32R1 | ISA_MIPS32R2) -#define CPU_MIPS64R2(CPU_MIPS64R1 | CPU_MIPS32R2 | ISA_MIPS64R2) +#define CPU_MIPS64R2(CPU_MIPS64R1 | CPU_MIPS32R2) /* MIPS Technologies "Release 3" */ #define CPU_MIPS32R3(CPU_MIPS32R2 | ISA_MIPS32R3) diff --git a/linux-user/mips/cpu_loop.c b/linux-user/mips/cpu_loop.c index cfe7ba5c47d..f0831379cc4 100644 --- a/linux-user/mips/cpu_loop.c +++ b/linux-user/mips/cpu_loop.c @@ -385,7 +385,6 @@ void target_cpu_copy_regs(CPUArchState *env, struct target_pt_regs *regs) prog_req.fre &= interp_req.fre; bool cpu_has_mips_r2_r6 = env->insn_flags & ISA_MIPS32R2 || - env->insn_flags & ISA_MIPS64R2 || env->insn_flags & ISA_MIPS32R6 || env->insn_flags & ISA_MIPS64R6; diff --git a/target/mips/translate.c b/target/mips/translate.c index 172027f9d6e..9fc9dedf30d 100644 --- a/target/mips/translate.c +++ b/target/mips/translate.c @@ -28621,7 +28621,7 @@ static void decode_opc_special3(CPUMIPSState *env, DisasContext *ctx) case OPC_DINSM: case OPC_DINSU: case OPC_DINS: -check_insn(ctx, ISA_MIPS64R2); +check_insn(ctx, ISA_MIPS32R2); check_mips_64(ctx); gen_bitops(ctx, op1, rt, rs, sa, rd); break; @@ -28641,7 +28641,7 @@ static void decode_opc_special3(CPUMIPSState *env, DisasContext *ctx) decode_opc_special3_r6(env, ctx); break; default: -check_insn(ctx, ISA_MIPS64R2); +check_insn(ctx, ISA_MIPS32R2); check_mips_64(ctx); op2 = MASK_DBSHFL(ctx->opcode); gen_bshfl(ctx, op2, rt, rd); -- 2.26.2
[PATCH v3 08/15] target/mips/mips-defs: Use ISA_MIPS32R3 definition to check Release 3
Use the single ISA_MIPS32R3 definition to check if the Release 3 ISA is supported, whether the CPU support 32/64-bit. For now we keep '32' in the definition name, we will rename it as ISA_MIPS_R3 in few commits. Reviewed-by: Richard Henderson Signed-off-by: Philippe Mathieu-Daudé --- target/mips/mips-defs.h | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/target/mips/mips-defs.h b/target/mips/mips-defs.h index b36b59c12d3..ccdde0b4a43 100644 --- a/target/mips/mips-defs.h +++ b/target/mips/mips-defs.h @@ -19,7 +19,6 @@ #define ISA_MIPS320x0020ULL #define ISA_MIPS32R2 0x0040ULL #define ISA_MIPS32R3 0x0200ULL -#define ISA_MIPS64R3 0x0400ULL #define ISA_MIPS32R5 0x0800ULL #define ISA_MIPS64R5 0x1000ULL #define ISA_MIPS32R6 0x2000ULL @@ -81,7 +80,7 @@ /* MIPS Technologies "Release 3" */ #define CPU_MIPS32R3(CPU_MIPS32R2 | ISA_MIPS32R3) -#define CPU_MIPS64R3(CPU_MIPS64R2 | CPU_MIPS32R3 | ISA_MIPS64R3) +#define CPU_MIPS64R3(CPU_MIPS64R2 | CPU_MIPS32R3) /* MIPS Technologies "Release 5" */ #define CPU_MIPS32R5(CPU_MIPS32R3 | ISA_MIPS32R5) -- 2.26.2
[PATCH v3 04/15] target/mips/mips-defs: Introduce CPU_MIPS64 and cpu_type_is_64bit()
MIPS 64-bit ISA is introduced with MIPS3.
Introduce the CPU_MIPS64 definition aliased to the MIPS3 ISA,
and the cpu_type_is_64bit() method to check if a CPU supports
this ISA (thus is 64-bit).
Suggested-by: Jiaxun Yang
Signed-off-by: Philippe Mathieu-Daudé
---
target/mips/cpu.h | 5 +
target/mips/mips-defs.h | 4 +++-
2 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/target/mips/cpu.h b/target/mips/cpu.h
index 4cbc31c3e8d..7c60a335f97 100644
--- a/target/mips/cpu.h
+++ b/target/mips/cpu.h
@@ -1297,6 +1297,11 @@ static inline bool ase_mt_available(CPUMIPSState *env)
return env->CP0_Config3 & (1 << CP0C3_MT);
}
+static inline bool cpu_type_is_64bit(const char *cpu_type)
+{
+return cpu_type_supports_isa(cpu_type, CPU_MIPS64);
+}
+
void cpu_set_exception_base(int vp_index, target_ulong address);
/* addr.c */
diff --git a/target/mips/mips-defs.h b/target/mips/mips-defs.h
index 1630ae20d59..89a9a4dda31 100644
--- a/target/mips/mips-defs.h
+++ b/target/mips/mips-defs.h
@@ -13,7 +13,7 @@
*/
#define ISA_MIPS1 0x0001ULL
#define ISA_MIPS2 0x0002ULL
-#define ISA_MIPS3 0x0004ULL
+#define ISA_MIPS3 0x0004ULL /* 64-bit */
#define ISA_MIPS4 0x0008ULL
#define ISA_MIPS5 0x0010ULL
#define ISA_MIPS320x0020ULL
@@ -71,6 +71,8 @@
#define CPU_LOONGSON2E (CPU_MIPS3 | INSN_LOONGSON2E)
#define CPU_LOONGSON2F (CPU_MIPS3 | INSN_LOONGSON2F | ASE_LMMI)
+#define CPU_MIPS64 (ISA_MIPS3)
+
/* MIPS Technologies "Release 1" */
#define CPU_MIPS32R1(CPU_MIPS2 | ISA_MIPS32)
#define CPU_MIPS64R1(CPU_MIPS5 | CPU_MIPS32R1 | ISA_MIPS64)
--
2.26.2
[PATCH v3 06/15] target/mips/mips-defs: Use ISA_MIPS32 definition to check Release 1
Use the single ISA_MIPS32 definition to check if the Release 1
ISA is supported, whether the CPU support 32/64-bit.
For now we keep '32' in the definition name, we will rename it
as ISA_MIPS_R1 in few commits.
Reviewed-by: Richard Henderson
Signed-off-by: Philippe Mathieu-Daudé
---
target/mips/mips-defs.h | 3 +--
target/mips/translate.c | 10 +-
2 files changed, 6 insertions(+), 7 deletions(-)
diff --git a/target/mips/mips-defs.h b/target/mips/mips-defs.h
index 89a9a4dda31..23ce8b8406f 100644
--- a/target/mips/mips-defs.h
+++ b/target/mips/mips-defs.h
@@ -18,7 +18,6 @@
#define ISA_MIPS5 0x0010ULL
#define ISA_MIPS320x0020ULL
#define ISA_MIPS32R2 0x0040ULL
-#define ISA_MIPS640x0080ULL
#define ISA_MIPS64R2 0x0100ULL
#define ISA_MIPS32R3 0x0200ULL
#define ISA_MIPS64R3 0x0400ULL
@@ -75,7 +74,7 @@
/* MIPS Technologies "Release 1" */
#define CPU_MIPS32R1(CPU_MIPS2 | ISA_MIPS32)
-#define CPU_MIPS64R1(CPU_MIPS5 | CPU_MIPS32R1 | ISA_MIPS64)
+#define CPU_MIPS64R1(CPU_MIPS5 | CPU_MIPS32R1)
/* MIPS Technologies "Release 2" */
#define CPU_MIPS32R2(CPU_MIPS32R1 | ISA_MIPS32R2)
diff --git a/target/mips/translate.c b/target/mips/translate.c
index 19933b7868c..172027f9d6e 100644
--- a/target/mips/translate.c
+++ b/target/mips/translate.c
@@ -8943,7 +8943,7 @@ static void gen_dmfc0(DisasContext *ctx, TCGv arg, int
reg, int sel)
const char *register_name = "invalid";
if (sel != 0) {
-check_insn(ctx, ISA_MIPS64);
+check_insn(ctx, ISA_MIPS32);
}
switch (reg) {
@@ -9669,7 +9669,7 @@ static void gen_dmtc0(DisasContext *ctx, TCGv arg, int
reg, int sel)
const char *register_name = "invalid";
if (sel != 0) {
-check_insn(ctx, ISA_MIPS64);
+check_insn(ctx, ISA_MIPS32);
}
if (tb_cflags(ctx->base.tb) & CF_USE_ICOUNT) {
@@ -14907,12 +14907,12 @@ static int decode_mips16_opc(CPUMIPSState *env,
DisasContext *ctx)
break;
#if defined(TARGET_MIPS64)
case RR_RY_CNVT_ZEW:
-check_insn(ctx, ISA_MIPS64);
+check_insn(ctx, ISA_MIPS32);
check_mips_64(ctx);
tcg_gen_ext32u_tl(cpu_gpr[rx], cpu_gpr[rx]);
break;
case RR_RY_CNVT_SEW:
-check_insn(ctx, ISA_MIPS64);
+check_insn(ctx, ISA_MIPS32);
check_mips_64(ctx);
tcg_gen_ext32s_tl(cpu_gpr[rx], cpu_gpr[rx]);
break;
@@ -27612,7 +27612,7 @@ static void decode_opc_special2_legacy(CPUMIPSState
*env, DisasContext *ctx)
#if defined(TARGET_MIPS64)
case OPC_DCLO:
case OPC_DCLZ:
-check_insn(ctx, ISA_MIPS64);
+check_insn(ctx, ISA_MIPS32);
check_mips_64(ctx);
gen_cl(ctx, op1, rd, rs);
break;
--
2.26.2
[PATCH v3 02/15] target/mips/mips-defs: Reorder CPU_MIPS5 definition
Move CPU_MIPS5 after CPU_MIPS4 :) Reviewed-by: Jiaxun Yang Reviewed-by: Richard Henderson Signed-off-by: Philippe Mathieu-Daudé --- target/mips/mips-defs.h | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/target/mips/mips-defs.h b/target/mips/mips-defs.h index 555e165fb01..48544ba73b4 100644 --- a/target/mips/mips-defs.h +++ b/target/mips/mips-defs.h @@ -65,13 +65,12 @@ #define CPU_MIPS2 (CPU_MIPS1 | ISA_MIPS2) #define CPU_MIPS3 (CPU_MIPS2 | ISA_MIPS3) #define CPU_MIPS4 (CPU_MIPS3 | ISA_MIPS4) +#define CPU_MIPS5 (CPU_MIPS4 | ISA_MIPS5) #define CPU_VR54XX (CPU_MIPS4 | INSN_VR54XX) #define CPU_R5900 (CPU_MIPS3 | INSN_R5900) #define CPU_LOONGSON2E (CPU_MIPS3 | INSN_LOONGSON2E) #define CPU_LOONGSON2F (CPU_MIPS3 | INSN_LOONGSON2F | ASE_LMMI) -#define CPU_MIPS5 (CPU_MIPS4 | ISA_MIPS5) - /* MIPS Technologies "Release 1" */ #define CPU_MIPS32 (CPU_MIPS2 | ISA_MIPS32) #define CPU_MIPS64 (CPU_MIPS5 | CPU_MIPS32 | ISA_MIPS64) -- 2.26.2
[PATCH v3 11/15] target/mips/mips-defs: Rename ISA_MIPS32 as ISA_MIPS_R1
The MIPS ISA release '1' is common to 32/64-bit CPUs.
Reviewed-by: Richard Henderson
Signed-off-by: Philippe Mathieu-Daudé
---
target/mips/internal.h | 2 +-
target/mips/mips-defs.h | 4 +--
target/mips/translate.c | 54 -
3 files changed, 30 insertions(+), 30 deletions(-)
diff --git a/target/mips/internal.h b/target/mips/internal.h
index 3466725b761..94910f75a61 100644
--- a/target/mips/internal.h
+++ b/target/mips/internal.h
@@ -411,7 +411,7 @@ static inline void compute_hflags(CPUMIPSState *env)
if (env->active_fpu.fcr0 & (1 << FCR0_F64)) {
env->hflags |= MIPS_HFLAG_COP1X;
}
-} else if (env->insn_flags & ISA_MIPS32) {
+} else if (env->insn_flags & ISA_MIPS_R1) {
if (env->hflags & MIPS_HFLAG_64) {
env->hflags |= MIPS_HFLAG_COP1X;
}
diff --git a/target/mips/mips-defs.h b/target/mips/mips-defs.h
index fea547508f0..a7048ffaffe 100644
--- a/target/mips/mips-defs.h
+++ b/target/mips/mips-defs.h
@@ -16,7 +16,7 @@
#define ISA_MIPS3 0x0004ULL /* 64-bit */
#define ISA_MIPS4 0x0008ULL
#define ISA_MIPS5 0x0010ULL
-#define ISA_MIPS320x0020ULL
+#define ISA_MIPS_R1 0x0020ULL
#define ISA_MIPS32R2 0x0040ULL
#define ISA_MIPS32R3 0x0200ULL
#define ISA_MIPS32R5 0x0800ULL
@@ -69,7 +69,7 @@
#define CPU_MIPS64 (ISA_MIPS3)
/* MIPS Technologies "Release 1" */
-#define CPU_MIPS32R1(CPU_MIPS2 | ISA_MIPS32)
+#define CPU_MIPS32R1(CPU_MIPS2 | ISA_MIPS_R1)
#define CPU_MIPS64R1(CPU_MIPS5 | CPU_MIPS32R1)
/* MIPS Technologies "Release 2" */
diff --git a/target/mips/translate.c b/target/mips/translate.c
index fc93b9da8eb..a59fbd94bac 100644
--- a/target/mips/translate.c
+++ b/target/mips/translate.c
@@ -7411,7 +7411,7 @@ static void gen_mfc0(DisasContext *ctx, TCGv arg, int
reg, int sel)
const char *register_name = "invalid";
if (sel != 0) {
-check_insn(ctx, ISA_MIPS32);
+check_insn(ctx, ISA_MIPS_R1);
}
switch (reg) {
@@ -8179,7 +8179,7 @@ static void gen_mtc0(DisasContext *ctx, TCGv arg, int
reg, int sel)
const char *register_name = "invalid";
if (sel != 0) {
-check_insn(ctx, ISA_MIPS32);
+check_insn(ctx, ISA_MIPS_R1);
}
if (tb_cflags(ctx->base.tb) & CF_USE_ICOUNT) {
@@ -8943,7 +8943,7 @@ static void gen_dmfc0(DisasContext *ctx, TCGv arg, int
reg, int sel)
const char *register_name = "invalid";
if (sel != 0) {
-check_insn(ctx, ISA_MIPS32);
+check_insn(ctx, ISA_MIPS_R1);
}
switch (reg) {
@@ -9669,7 +9669,7 @@ static void gen_dmtc0(DisasContext *ctx, TCGv arg, int
reg, int sel)
const char *register_name = "invalid";
if (sel != 0) {
-check_insn(ctx, ISA_MIPS32);
+check_insn(ctx, ISA_MIPS_R1);
}
if (tb_cflags(ctx->base.tb) & CF_USE_ICOUNT) {
@@ -11006,7 +11006,7 @@ static void gen_cp0(CPUMIPSState *env, DisasContext
*ctx, uint32_t opc,
break;
case OPC_DERET:
opn = "deret";
-check_insn(ctx, ISA_MIPS32);
+check_insn(ctx, ISA_MIPS_R1);
if ((ctx->insn_flags & ISA_MIPS32R6) &&
(ctx->hflags & MIPS_HFLAG_BMASK)) {
goto die;
@@ -11021,7 +11021,7 @@ static void gen_cp0(CPUMIPSState *env, DisasContext
*ctx, uint32_t opc,
break;
case OPC_WAIT:
opn = "wait";
-check_insn(ctx, ISA_MIPS3 | ISA_MIPS32);
+check_insn(ctx, ISA_MIPS3 | ISA_MIPS_R1);
if ((ctx->insn_flags & ISA_MIPS32R6) &&
(ctx->hflags & MIPS_HFLAG_BMASK)) {
goto die;
@@ -11056,7 +11056,7 @@ static void gen_compute_branch1(DisasContext *ctx,
uint32_t op,
}
if (cc != 0) {
-check_insn(ctx, ISA_MIPS4 | ISA_MIPS32);
+check_insn(ctx, ISA_MIPS4 | ISA_MIPS_R1);
}
btarget = ctx->base.pc_next + 4 + offset;
@@ -14425,7 +14425,7 @@ static int decode_extended_mips16_opc(CPUMIPSState
*env, DisasContext *ctx)
gen_arith_imm(ctx, OPC_ADDIU, 29, 29, imm);
break;
case I8_SVRS:
-check_insn(ctx, ISA_MIPS32);
+check_insn(ctx, ISA_MIPS_R1);
{
int xsregs = (ctx->opcode >> 24) & 0x7;
int aregs = (ctx->opcode >> 16) & 0xf;
@@ -14675,7 +14675,7 @@ static int decode_mips16_opc(CPUMIPSState *env,
DisasContext *ctx)
((int8_t)ctx->opcode) << 3);
break;
case I8_SVRS:
-check_insn(ctx, ISA_MIPS32);
+check_insn(ctx, ISA_MIPS_R1);
{
int do_ra = ctx->opcode & (1 << 6);
int do_s0 = ctx->opcode & (1 << 5);
@@ -14819,7 +14819,7 @@ static int decode_mips16_opc(CPUMIPSState *env,
DisasContext *ctx)
int ra = (ctx->opcode >
[PATCH v3 03/15] target/mips/mips-defs: Rename CPU_MIPSxx Release 1 as CPU_MIPSxxR1
'CPU_MIPS32' and 'CPU_MIPS64' definitions concern CPUs implementing
the "Release 1" ISA. Rename it with the 'R1' suffix, as the other
CPU definitions do.
Signed-off-by: Philippe Mathieu-Daudé
---
target/mips/mips-defs.h | 8
target/mips/translate_init.c.inc | 14 +++---
2 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/target/mips/mips-defs.h b/target/mips/mips-defs.h
index 48544ba73b4..1630ae20d59 100644
--- a/target/mips/mips-defs.h
+++ b/target/mips/mips-defs.h
@@ -72,12 +72,12 @@
#define CPU_LOONGSON2F (CPU_MIPS3 | INSN_LOONGSON2F | ASE_LMMI)
/* MIPS Technologies "Release 1" */
-#define CPU_MIPS32 (CPU_MIPS2 | ISA_MIPS32)
-#define CPU_MIPS64 (CPU_MIPS5 | CPU_MIPS32 | ISA_MIPS64)
+#define CPU_MIPS32R1(CPU_MIPS2 | ISA_MIPS32)
+#define CPU_MIPS64R1(CPU_MIPS5 | CPU_MIPS32R1 | ISA_MIPS64)
/* MIPS Technologies "Release 2" */
-#define CPU_MIPS32R2(CPU_MIPS32 | ISA_MIPS32R2)
-#define CPU_MIPS64R2(CPU_MIPS64 | CPU_MIPS32R2 | ISA_MIPS64R2)
+#define CPU_MIPS32R2(CPU_MIPS32R1 | ISA_MIPS32R2)
+#define CPU_MIPS64R2(CPU_MIPS64R1 | CPU_MIPS32R2 | ISA_MIPS64R2)
/* MIPS Technologies "Release 3" */
#define CPU_MIPS32R3(CPU_MIPS32R2 | ISA_MIPS32R3)
diff --git a/target/mips/translate_init.c.inc b/target/mips/translate_init.c.inc
index f72fee3b40a..427da84768b 100644
--- a/target/mips/translate_init.c.inc
+++ b/target/mips/translate_init.c.inc
@@ -72,7 +72,7 @@ const mips_def_t mips_defs[] =
.CP0_Status_rw_bitmask = 0x1278FF17,
.SEGBITS = 32,
.PABITS = 32,
-.insn_flags = CPU_MIPS32,
+.insn_flags = CPU_MIPS32R1,
.mmu_type = MMU_TYPE_R4000,
},
{
@@ -94,7 +94,7 @@ const mips_def_t mips_defs[] =
.CP0_Status_rw_bitmask = 0x1258FF17,
.SEGBITS = 32,
.PABITS = 32,
-.insn_flags = CPU_MIPS32 | ASE_MIPS16,
+.insn_flags = CPU_MIPS32R1 | ASE_MIPS16,
.mmu_type = MMU_TYPE_FMT,
},
{
@@ -114,7 +114,7 @@ const mips_def_t mips_defs[] =
.CP0_Status_rw_bitmask = 0x1278FF17,
.SEGBITS = 32,
.PABITS = 32,
-.insn_flags = CPU_MIPS32,
+.insn_flags = CPU_MIPS32R1,
.mmu_type = MMU_TYPE_R4000,
},
{
@@ -134,7 +134,7 @@ const mips_def_t mips_defs[] =
.CP0_Status_rw_bitmask = 0x1258FF17,
.SEGBITS = 32,
.PABITS = 32,
-.insn_flags = CPU_MIPS32 | ASE_MIPS16,
+.insn_flags = CPU_MIPS32R1 | ASE_MIPS16,
.mmu_type = MMU_TYPE_FMT,
},
{
@@ -550,7 +550,7 @@ const mips_def_t mips_defs[] =
.CP0_Status_rw_bitmask = 0x12F8,
.SEGBITS = 42,
.PABITS = 36,
-.insn_flags = CPU_MIPS64,
+.insn_flags = CPU_MIPS64R1,
.mmu_type = MMU_TYPE_R4000,
},
{
@@ -576,7 +576,7 @@ const mips_def_t mips_defs[] =
.CP1_fcr31_rw_bitmask = 0xFF83,
.SEGBITS = 42,
.PABITS = 36,
-.insn_flags = CPU_MIPS64,
+.insn_flags = CPU_MIPS64R1,
.mmu_type = MMU_TYPE_R4000,
},
{
@@ -605,7 +605,7 @@ const mips_def_t mips_defs[] =
.CP1_fcr31_rw_bitmask = 0xFF83,
.SEGBITS = 40,
.PABITS = 36,
-.insn_flags = CPU_MIPS64 | ASE_MIPS3D,
+.insn_flags = CPU_MIPS64R1 | ASE_MIPS3D,
.mmu_type = MMU_TYPE_R4000,
},
{
--
2.26.2
[PATCH v3 01/15] target/mips/mips-defs: Remove USE_HOST_FLOAT_REGS comment
Remove a comment added 12 years ago but never used (commit b6d96beda3a: "Use temporary registers for the MIPS FPU emulation"). Signed-off-by: Philippe Mathieu-Daudé --- target/mips/mips-defs.h | 6 -- 1 file changed, 6 deletions(-) diff --git a/target/mips/mips-defs.h b/target/mips/mips-defs.h index ed6a7a9e545..555e165fb01 100644 --- a/target/mips/mips-defs.h +++ b/target/mips/mips-defs.h @@ -1,12 +1,6 @@ #ifndef QEMU_MIPS_DEFS_H #define QEMU_MIPS_DEFS_H -/* - * If we want to use host float regs... - * - * #define USE_HOST_FLOAT_REGS - */ - /* Real pages are variable size... */ #define MIPS_TLB_MAX 128 -- 2.26.2
[PATCH v3 00/15] target/mips/mips-defs: Simplify ISA definitions
v3: Replace ISA_MIPS3 by ISA_MIPS64 (Richard) v2: Do not use MIPS3 for 64R1 (Jiaxun) Missing review: 1, 3, 4, 5 As we don't need to duplicate 32/64-bit ISA defititions, this series remove the duplicated 64-bit variants, simplifying the overall. Regards, Phil. $ git backport-diff -u v2 -r ..v3 Key: [] : patches are identical [] : number of functional differences between upstream/downstream patch [down] : patch is downstream-only The flags [FC] indicate (F)unctional and (C)ontextual differences, respective= ly 001/15:[down] 'target/mips/mips-defs: Remove USE_HOST_FLOAT_REGS comment' 002/15:[] [--] 'target/mips/mips-defs: Reorder CPU_MIPS5 definition' 003/15:[down] 'target/mips/mips-defs: Rename CPU_MIPSxx Release 1 as CPU_MIPS= xxR1' 004/15:[down] 'target/mips/mips-defs: Introduce CPU_MIPS64 and cpu_type_is_64= bit()' 005/15:[down] 'hw/mips/boston: Check 64-bit support with cpu_type_is_64bit()' 006/15:[0004] [FC] 'target/mips/mips-defs: Use ISA_MIPS32 definition to check= Release 1' 007/15:[0004] [FC] 'target/mips/mips-defs: Use ISA_MIPS32R2 definition to che= ck Release 2' 008/15:[] [--] 'target/mips/mips-defs: Use ISA_MIPS32R3 definition to che= ck Release 3' 009/15:[] [--] 'target/mips/mips-defs: Use ISA_MIPS32R5 definition to che= ck Release 5' 010/15:[0002] [FC] 'target/mips/mips-defs: Use ISA_MIPS32R6 definition to che= ck Release 6' 011/15:[0004] [FC] 'target/mips/mips-defs: Rename ISA_MIPS32 as ISA_MIPS_R1' 012/15:[0006] [FC] 'target/mips/mips-defs: Rename ISA_MIPS32R2 as ISA_MIPS_R2' 013/15:[] [-C] 'target/mips/mips-defs: Rename ISA_MIPS32R3 as ISA_MIPS_R3' 014/15:[] [--] 'target/mips/mips-defs: Rename ISA_MIPS32R5 as ISA_MIPS_R5' 015/15:[0018] [FC] 'target/mips/mips-defs: Rename ISA_MIPS32R6 as ISA_MIPS_R6' Philippe Mathieu-Daud=C3=A9 (15): target/mips/mips-defs: Remove USE_HOST_FLOAT_REGS comment target/mips/mips-defs: Reorder CPU_MIPS5 definition target/mips/mips-defs: Rename CPU_MIPSxx Release 1 as CPU_MIPSxxR1 target/mips/mips-defs: Introduce CPU_MIPS64 and cpu_type_is_64bit() hw/mips/boston: Check 64-bit support with cpu_type_is_64bit() target/mips/mips-defs: Use ISA_MIPS32 definition to check Release 1 target/mips/mips-defs: Use ISA_MIPS32R2 definition to check Release 2 target/mips/mips-defs: Use ISA_MIPS32R3 definition to check Release 3 target/mips/mips-defs: Use ISA_MIPS32R5 definition to check Release 5 target/mips/mips-defs: Use ISA_MIPS32R6 definition to check Release 6 target/mips/mips-defs: Rename ISA_MIPS32 as ISA_MIPS_R1 target/mips/mips-defs: Rename ISA_MIPS32R2 as ISA_MIPS_R2 target/mips/mips-defs: Rename ISA_MIPS32R3 as ISA_MIPS_R3 target/mips/mips-defs: Rename ISA_MIPS32R5 as ISA_MIPS_R5 target/mips/mips-defs: Rename ISA_MIPS32R6 as ISA_MIPS_R6 target/mips/cpu.h| 5 + target/mips/internal.h | 8 +- target/mips/mips-defs.h | 46 +-- hw/mips/boston.c | 6 +- linux-user/mips/cpu_loop.c | 6 +- target/mips/cp0_helper.c | 18 +- target/mips/cp0_timer.c | 4 +- target/mips/cpu.c| 6 +- target/mips/fpu_helper.c | 4 +- target/mips/helper.c | 12 +- target/mips/translate.c | 620 +++ target/mips/translate_init.c.inc | 14 +- 12 files changed, 370 insertions(+), 379 deletions(-) --=20 2.26.2
Re: [PATCH v2 0/3] pc: Support configuration of SMBIOS entry point type
On Tue, Dec 29, 2020 at 02:20:01PM +0100, Igor Mammedov wrote: > On Mon, 14 Dec 2020 15:50:26 -0500 > Eduardo Habkost wrote: > > > This includes code previously submitted[1] by Daniel P. Berrangé > > to add a "smbios-ep" machine property on PC. > > > > SMBIOS 3.0 is necessary to support more than ~720 VCPUs, as a > > large number of VCPUs can easily hit the table size limit of > > SMBIOS 2.1 entry points. > > Eduardo, > do you plan to submit Seabios patches for SMBIOS 3.0? > will OVMF pick up new tables automatically? OVMF will pick the new tables automatically. SeaBIOS patches are at: https://www.mail-archive.com/search?l=mid&q=20201210212640.2023885-1-ehabk...@redhat.com -- Eduardo
Re: [PATCH v2 2/3] hostmem-file: add readonly=on|off option
On Mon, Jan 04, 2021 at 03:42:23PM +, Stefan Hajnoczi wrote:
> On Mon, Dec 14, 2020 at 12:10:15PM +0100, Igor Mammedov wrote:
> > On Wed, 16 Sep 2020 10:51:49 +0100
> > Stefan Hajnoczi wrote:
> >
> > > Let -object memory-backend-file work on read-only files when the
> > > readonly=on option is given. This can be used to share the contents of a
> > > file between multiple guests while preventing them from consuming
> > > Copy-on-Write memory if guests dirty the pages, for example.
> > >
> > > Acked-by: Michael S. Tsirkin
> > > Reviewed-by: Philippe Mathieu-Daudé
> > > Signed-off-by: Stefan Hajnoczi
> >
> > cosmetic/style nits only
> >
> > s/Object *o/Object *obj/
> >
> > for consistency with the rest of the code in file.
>
> Will fix.
>
> > > @@ -153,6 +154,26 @@ static void file_memory_backend_set_pmem(Object *o,
> > > bool value, Error **errp)
> > > fb->is_pmem = value;
> > > }
> > >
> > > +static bool file_memory_backend_get_readonly(Object *o, Error **errp)
> > > +{
> > > +return MEMORY_BACKEND_FILE(o)->readonly;
> >
> > I thought using macro this way not acceptable and one should use
> >
> > HostMemoryBackendFile *fb = MEMORY_BACKEND_FILE(o);
> >
> > return fb->readonly;
>
> I'm not sure where this is forbidden or why? I've updated the patch as
> suggested anyway.
I have a vague memory of seeing this documented somewhere, but I
can't find it anywhere in the QOM documentation or git log.
I don't think we need to make this a rule, though.
--
Eduardo
Re: [PATCH v2 04/12] libqtest: add qtest_remove_abrt_handler()
On 12/7/20 2:20 PM, Stefan Hajnoczi wrote:
Add a function to remove previously-added abrt handler functions.
Now that a symmetric pair of add/remove functions exists we can also
balance the SIGABRT handler installation. The signal handler was
installed each time qtest_add_abrt_handler() was called. Now it is
installed when the abrt handler list becomes non-empty and removed again
when the list becomes empty.
The qtest_remove_abrt_handler() function will be used by
vhost-user-blk-test.
Signed-off-by: Stefan Hajnoczi
---
tests/qtest/libqos/libqtest.h | 18 ++
tests/qtest/libqtest.c| 35 +--
2 files changed, 47 insertions(+), 6 deletions(-)
Reviewed-by: Wainer dos Santos Moschetta
diff --git a/tests/qtest/libqos/libqtest.h b/tests/qtest/libqos/libqtest.h
index 51287b9276..a68dcd79d4 100644
--- a/tests/qtest/libqos/libqtest.h
+++ b/tests/qtest/libqos/libqtest.h
@@ -649,8 +649,26 @@ void qtest_add_data_func_full(const char *str, void *data,
g_free(path); \
} while (0)
+/**
+ * qtest_add_abrt_handler:
+ * @fn: Handler function
+ * @data: Argument that is passed to the handler
+ *
+ * Add a handler function that is invoked on SIGABRT. This can be used to
+ * terminate processes and perform other cleanup. The handler can be removed
+ * with qtest_remove_abrt_handler().
+ */
void qtest_add_abrt_handler(GHookFunc fn, const void *data);
+/**
+ * qtest_remove_abrt_handler:
+ * @data: Argument previously passed to qtest_add_abrt_handler()
+ *
+ * Remove an abrt handler that was previously added with
+ * qtest_add_abrt_handler().
+ */
+void qtest_remove_abrt_handler(void *data);
+
/**
* qtest_qmp_assert_success:
* @qts: QTestState instance to operate on
diff --git a/tests/qtest/libqtest.c b/tests/qtest/libqtest.c
index cc2cec4a35..7cf247baf0 100644
--- a/tests/qtest/libqtest.c
+++ b/tests/qtest/libqtest.c
@@ -196,15 +196,30 @@ static void cleanup_sigabrt_handler(void)
sigaction(SIGABRT, &sigact_old, NULL);
}
+static bool hook_list_is_empty(GHookList *hook_list)
+{
+GHook *hook = g_hook_first_valid(hook_list, TRUE);
+
+if (!hook) {
+return false;
+}
+
+g_hook_unref(hook_list, hook);
+return true;
+}
+
void qtest_add_abrt_handler(GHookFunc fn, const void *data)
{
GHook *hook;
-/* Only install SIGABRT handler once */
if (!abrt_hooks.is_setup) {
g_hook_list_init(&abrt_hooks, sizeof(GHook));
}
-setup_sigabrt_handler();
+
+/* Only install SIGABRT handler once */
+if (hook_list_is_empty(&abrt_hooks)) {
+setup_sigabrt_handler();
+}
hook = g_hook_alloc(&abrt_hooks);
hook->func = fn;
@@ -213,6 +228,17 @@ void qtest_add_abrt_handler(GHookFunc fn, const void *data)
g_hook_prepend(&abrt_hooks, hook);
}
+void qtest_remove_abrt_handler(void *data)
+{
+GHook *hook = g_hook_find_data(&abrt_hooks, TRUE, data);
+g_hook_destroy_link(&abrt_hooks, hook);
+
+/* Uninstall SIGABRT handler on last instance */
+if (hook_list_is_empty(&abrt_hooks)) {
+cleanup_sigabrt_handler();
+}
+}
+
static const char *qtest_qemu_binary(void)
{
const char *qemu_bin;
@@ -369,10 +395,7 @@ QTestState *qtest_init_with_serial(const char *extra_args,
int *sock_fd)
void qtest_quit(QTestState *s)
{
-g_hook_destroy_link(&abrt_hooks, g_hook_find_data(&abrt_hooks, TRUE, s));
-
-/* Uninstall SIGABRT handler on last instance */
-cleanup_sigabrt_handler();
+qtest_remove_abrt_handler(s);
qtest_kill_qemu(s);
close(s->fd);
Re: [PATCH v3 0/3] nvdimm: read-only file support
Is anybody already going to merge this? If not, I can merge it. On Mon, Jan 04, 2021 at 05:13:17PM +, Stefan Hajnoczi wrote: > v3: > * Produce an error when -device nvdimm,unarmed=off is used with -object >memory-backend-file,readonly=on instead of silently switching on >unarmed. [Igor] > * Use Object *obj instead of Object *o [Igor] > * Do not dereference MEMORY_BACKEND_FILE(o)->readonly directly, use a >local variable to hold the HostMemoryBackendFile pointer. [Igor] > v2: > * s/the the/the/ in documentation [Philippe] > * Assign nvdimm->unarmed earlier [Philippe] > > There is currently no way to back an NVDIMM with a read-only file so it can be > safely shared between untrusted guests. > > Introduce an -object memory-backend-file,readonly=on|off option. > > Julio Montes sent an earlier patch here: > https://patchew.org/QEMU/20190708211936.8037-1-julio.mon...@intel.com/ > > Eric Ernst requested this feature again for Kata Containers so I gave it a > try. > > Stefan Hajnoczi (3): > memory: add readonly support to memory_region_init_ram_from_file() > hostmem-file: add readonly=on|off option > nvdimm: check -object memory-backend-file,readonly=on option > > docs/nvdimm.txt | 24 +--- > include/exec/memory.h | 2 ++ > include/exec/ram_addr.h | 5 +++-- > include/qemu/mmap-alloc.h | 2 ++ > backends/hostmem-file.c | 28 +++- > hw/mem/nvdimm.c | 9 + > softmmu/memory.c | 7 +-- > softmmu/physmem.c | 18 +++--- > util/mmap-alloc.c | 10 ++ > util/oslib-posix.c| 2 +- > qemu-options.hx | 5 - > 11 files changed, 87 insertions(+), 25 deletions(-) > > -- > 2.29.2 > -- Eduardo
Re: [PATCH] meson: Propagate gnutls dependency
On 04/01/21 18:24, Roman Bolshakov wrote:
Hi Paolo,
I'm sorry I didn't reply earlier. As I showed in an example to Peter
(https://lists.gnu.org/archive/html/qemu-devel/2021-01/msg00085.html):
https://github.com/mesonbuild/meson/commit/ff5dc65ef841857dd306694dff1fb1cd2bf801e4
The approach doesn't propogate dependencies of crypto beyond libcrypto.
i.e. if you specify crypto somewhere else as depedency, it won't pull
CFLAGS needed for gnutls.
Hi Roman,
After writing the meson patch in fact I noticed that get_dependencies()
is used only for linker flags. I got a very quick reply from the Meson
maintainer (https://github.com/mesonbuild/meson/pull/8151):
The fact that header flags are not passed transitively but libraries
are (in some cases) is intentional. Otherwise compiler flag counts
explode in deep hierarchies. Because of this include paths must be
exported manually, typically by adding the appropriate bits to a
declare_dependency.
Libs are a bit stupid, because you need to add direct dependencies
if, for example, you link to a static library.
Does it work if you do:
crypto_ss.add(authz, qom)
libcrypto = static_library('crypto', crypto_ss.sources() + genh,
dependencies: crypto_ss.dependencies(),
...)
crypto = declare_dependency(link_whole: libcrypto,
dependencies: crypto_ss.dependencies())
? If so, that is also a good option. If not, I will try to extend the
test case to pitch the Meson change.
Paolo
Re: [PATCH v2] tcg: Fix execution on Apple Silicon
Alexander Graf writes:
> On 04.01.21 16:23, Alex Bennée wrote:
>> Roman Bolshakov writes:
>>
>>> Pages can't be both write and executable at the same time on Apple
>>> Silicon. macOS provides public API to switch write protection [1] for
>>> JIT applications, like TCG.
>>>
>>> 1.
>>> https://developer.apple.com/documentation/apple_silicon/porting_just-in-time_compilers_to_apple_silicon
>>>
>>> Signed-off-by: Roman Bolshakov
>>> ---
>>> v1: https://lists.gnu.org/archive/html/qemu-devel/2021-01/msg00073.html
>>> Changes since v1:
>>>
>>> - Pruned not needed fiddling with W^X and dropped symmetry from write
>>> lock/unlock and renamed related functions.
>>> Similar approach is used in JavaScriptCore [1].
>>>
>>> - Moved jit helper functions to util/osdep
>>>
>>>As
>>> outlined in osdep.h, this matches to (2):
>>>
>>>
>>> * In an ideal
>>> world this header would contain only:
>>> * (1) things which
>>> everybody needs
>>>* (2) things without which
>>> code would work on most platforms but
>>>* fail to compile or misbehave
>>> on a minority of host OSes
>>>
>>> - Fixed a checkpatch error
>>>
>>> - Limit new behaviour only to macOS 11.0 and above, because of the
>>> following declarations:
>>>
>>> __API_AVAILABLE(macos(11.0))
>>> __API_UNAVAILABLE(ios, tvos, watchos)
>>> void pthread_jit_write_protect_np(int enabled);
>>>
>>> __API_AVAILABLE(macos(11.0))
>>> __API_UNAVAILABLE(ios, tvos, watchos)
>>> int pthread_jit_write_protect_supported_np(void);
>>>
>>> 1. https://bugs.webkit.org/attachment.cgi?id=402515&action=prettypatch
>>>
>>> accel/tcg/cpu-exec.c | 2 ++
>>> accel/tcg/translate-all.c | 6 ++
>>> include/qemu/osdep.h | 3 +++
>>> tcg/tcg.c | 1 +
>>> util/osdep.c | 22 ++
>>> 5 files changed, 34 insertions(+)
>>>
>>> diff --git a/accel/tcg/cpu-exec.c b/accel/tcg/cpu-exec.c
>>> index 8689c54499..374060eb45 100644
>>> --- a/accel/tcg/cpu-exec.c
>>> +++ b/accel/tcg/cpu-exec.c
>>> @@ -175,6 +175,7 @@ static inline tcg_target_ulong cpu_tb_exec(CPUState
>>> *cpu, TranslationBlock *itb)
>>> }
>>> #endif /* DEBUG_DISAS */
>>>
>>> +qemu_thread_jit_execute();
>>> ret = tcg_qemu_tb_exec(env, tb_ptr);
>>> cpu->can_do_io = 1;
>>> last_tb = (TranslationBlock *)(ret & ~TB_EXIT_MASK);
>>> @@ -382,6 +383,7 @@ static inline void tb_add_jump(TranslationBlock *tb,
>>> int n,
>>> {
>>> uintptr_t old;
>>>
>>> +qemu_thread_jit_write();
>>> assert(n < ARRAY_SIZE(tb->jmp_list_next));
>>> qemu_spin_lock(&tb_next->jmp_lock);
>>>
>>> diff --git a/accel/tcg/translate-all.c b/accel/tcg/translate-all.c
>>> index b7d50a73d4..88ae5d35ef 100644
>>> --- a/accel/tcg/translate-all.c
>>> +++ b/accel/tcg/translate-all.c
>>> @@ -1072,6 +1072,9 @@ static inline void *alloc_code_gen_buffer(void)
>>> size_t size = tcg_ctx->code_gen_buffer_size;
>>> void *buf;
>>>
>>> +#if defined(__APPLE__) && defined(MAC_OS_VERSION_11_0)
>>> +flags |= MAP_JIT;
>>> +#endif
>>> buf = mmap(NULL, size, prot, flags, -1, 0);
>>> if (buf == MAP_FAILED) {
>>> return NULL;
>>> @@ -1485,7 +1488,9 @@ static void do_tb_phys_invalidate(TranslationBlock
>>> *tb, bool rm_from_page_list)
>>>
>>> static void tb_phys_invalidate__locked(TranslationBlock *tb)
>>> {
>>> +qemu_thread_jit_write();
>>> do_tb_phys_invalidate(tb, true);
>>> +qemu_thread_jit_execute();
>>> }
>>>
>>> /* invalidate one TB
>>> @@ -1687,6 +1692,7 @@ TranslationBlock *tb_gen_code(CPUState *cpu,
>>> #endif
>>>
>>> assert_memory_lock();
>>> +qemu_thread_jit_write();
>>>
>>> phys_pc = get_page_addr_code(env, pc);
>>>
>>> diff --git a/include/qemu/osdep.h b/include/qemu/osdep.h
>>> index f9ec8c84e9..89abebcf5d 100644
>>> --- a/include/qemu/osdep.h
>>> +++ b/include/qemu/osdep.h
>>> @@ -686,4 +686,7 @@ char *qemu_get_host_name(Error **errp);
>>>*/
>>> size_t qemu_get_host_physmem(void);
>>>
>>> +void qemu_thread_jit_write(void);
>>> +void qemu_thread_jit_execute(void);
>>> +
>>> #endif
>>> diff --git a/tcg/tcg.c b/tcg/tcg.c
>>> index 43c6cf8f52..ab8488f5d5 100644
>>> --- a/tcg/tcg.c
>>> +++ b/tcg/tcg.c
>>> @@ -1065,6 +1065,7 @@ void tcg_prologue_i
Re: [PULL for-5.2 2/2] scripts/tracetool: silence SystemTap dtrace(1) long long warnings
On 11/11/2020 16:56, Stefan Hajnoczi wrote:
> SystemTap's dtrace(1) prints the following warning when it encounters
> long long arguments:
>
> Warning: /usr/bin/dtrace:trace/trace-dtrace-hw_virtio.dtrace:76: syntax
> error near:
> probe vhost_vdpa_dev_start
>
> Warning: Proceeding as if --no-pyparsing was given.
>
> Use the uint64_t and int64_t types, respectively. This works with all
> host CPU 32- and 64-bit data models (ILP32, LP64, and LLP64) that QEMU
> supports.
>
> Reported-by: Markus Armbruster
> Signed-off-by: Stefan Hajnoczi
> Reviewed-by: Daniel P. Berrangé
> Reviewed-by: Philippe Mathieu-Daudé
> Message-id: 20201020094043.159935-1-stefa...@redhat.com
> Suggested-by: Daniel P. Berrangé
> Signed-off-by: Stefan Hajnoczi
> ---
> scripts/tracetool/format/d.py | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/scripts/tracetool/format/d.py b/scripts/tracetool/format/d.py
> index 353722f89c..ebfb714200 100644
> --- a/scripts/tracetool/format/d.py
> +++ b/scripts/tracetool/format/d.py
> @@ -57,6 +57,12 @@ def generate(events, backend, group):
> # Avoid it by changing probe type to signed char *
> beforehand.
> if type_ == 'int8_t *':
> type_ = 'signed char *'
> +
> +# SystemTap dtrace(1) emits a warning when long long is used
> +type_ = type_.replace('unsigned long long', 'uint64_t')
> +type_ = type_.replace('signed long long', 'int64_t')
> +type_ = type_.replace('long long', 'int64_t')
> +
> if name in RESERVED_WORDS:
> name += '_'
> args.append(type_ + ' ' + name)
>
This patch fixes the warning with "d" format, but we have the same kind of
problem with
log-stap format:
$ sudo stap -e 'probe begin{printf ("BEGIN")}' -I .
parse error: invalid or missing conversion specifier
saw: operator ',' at ./qemu-system-x86_64-log.stp:15118:101
source: printf("%d@%d vhost_vdpa_set_log_base dev: %p base: 0x%x
size: %llu
refcnt: %d fd: %d log: %p\n", pid(), gettimeofday_ns(), dev, base, size,
refcnt, fd, log)
^
1 parse error.
WARNING: tapset "./qemu-system-x86_64-log.stp" has errors, and will be skipped
BEGIN
This happens because of the "%llu" in the format string.
I'm wondering if we need to fix all the stap based format or simply replace the
"unsigned
long long" by "uint64_t" in hw/virtio/trace-events?
Thanks,
Laurent
[PATCH v3 3/3] vfio-ccw: Connect the device request notifier
Now that the vfio-ccw code has a notifier interface to request that
a device be unplugged, let's wire that together.
Signed-off-by: Eric Farman
Reviewed-by: Cornelia Huck
---
hw/vfio/ccw.c | 40
1 file changed, 36 insertions(+), 4 deletions(-)
diff --git a/hw/vfio/ccw.c b/hw/vfio/ccw.c
index d2755d7fc5..bc78a0ad76 100644
--- a/hw/vfio/ccw.c
+++ b/hw/vfio/ccw.c
@@ -49,6 +49,7 @@ struct VFIOCCWDevice {
struct ccw_crw_region *crw_region;
EventNotifier io_notifier;
EventNotifier crw_notifier;
+EventNotifier req_notifier;
bool force_orb_pfch;
bool warned_orb_pfch;
};
@@ -287,6 +288,21 @@ static void vfio_ccw_crw_read(VFIOCCWDevice *vcdev)
} while (1);
}
+static void vfio_ccw_req_notifier_handler(void *opaque)
+{
+VFIOCCWDevice *vcdev = opaque;
+Error *err = NULL;
+
+if (!event_notifier_test_and_clear(&vcdev->req_notifier)) {
+return;
+}
+
+qdev_unplug(DEVICE(vcdev), &err);
+if (err) {
+warn_reportf_err(err, VFIO_MSG_PREFIX, vcdev->vdev.name);
+}
+}
+
static void vfio_ccw_crw_notifier_handler(void *opaque)
{
VFIOCCWDevice *vcdev = opaque;
@@ -386,6 +402,10 @@ static void vfio_ccw_register_irq_notifier(VFIOCCWDevice
*vcdev,
notifier = &vcdev->crw_notifier;
fd_read = vfio_ccw_crw_notifier_handler;
break;
+case VFIO_CCW_REQ_IRQ_INDEX:
+notifier = &vcdev->req_notifier;
+fd_read = vfio_ccw_req_notifier_handler;
+break;
default:
error_setg(errp, "vfio: Unsupported device irq(%d)", irq);
return;
@@ -440,6 +460,9 @@ static void vfio_ccw_unregister_irq_notifier(VFIOCCWDevice
*vcdev,
case VFIO_CCW_CRW_IRQ_INDEX:
notifier = &vcdev->crw_notifier;
break;
+case VFIO_CCW_REQ_IRQ_INDEX:
+notifier = &vcdev->req_notifier;
+break;
default:
error_report("vfio: Unsupported device irq(%d)", irq);
return;
@@ -661,20 +684,28 @@ static void vfio_ccw_realize(DeviceState *dev, Error
**errp)
vfio_ccw_register_irq_notifier(vcdev, VFIO_CCW_IO_IRQ_INDEX, &err);
if (err) {
-goto out_notifier_err;
+goto out_io_notifier_err;
}
if (vcdev->crw_region) {
vfio_ccw_register_irq_notifier(vcdev, VFIO_CCW_CRW_IRQ_INDEX, &err);
if (err) {
-vfio_ccw_unregister_irq_notifier(vcdev, VFIO_CCW_IO_IRQ_INDEX);
-goto out_notifier_err;
+goto out_crw_notifier_err;
}
}
+vfio_ccw_register_irq_notifier(vcdev, VFIO_CCW_REQ_IRQ_INDEX, &err);
+if (err) {
+goto out_req_notifier_err;
+}
+
return;
-out_notifier_err:
+out_req_notifier_err:
+vfio_ccw_unregister_irq_notifier(vcdev, VFIO_CCW_CRW_IRQ_INDEX);
+out_crw_notifier_err:
+vfio_ccw_unregister_irq_notifier(vcdev, VFIO_CCW_IO_IRQ_INDEX);
+out_io_notifier_err:
vfio_ccw_put_region(vcdev);
out_region_err:
vfio_ccw_put_device(vcdev);
@@ -696,6 +727,7 @@ static void vfio_ccw_unrealize(DeviceState *dev)
S390CCWDeviceClass *cdc = S390_CCW_DEVICE_GET_CLASS(cdev);
VFIOGroup *group = vcdev->vdev.group;
+vfio_ccw_unregister_irq_notifier(vcdev, VFIO_CCW_REQ_IRQ_INDEX);
vfio_ccw_unregister_irq_notifier(vcdev, VFIO_CCW_CRW_IRQ_INDEX);
vfio_ccw_unregister_irq_notifier(vcdev, VFIO_CCW_IO_IRQ_INDEX);
vfio_ccw_put_region(vcdev);
--
2.17.1
Re: [PATCH] RISC-V: Place DTB at 3GB boundary instead of 4GB
On Tue, 2020-12-29 at 12:49 +0800, Bin Meng wrote: > Hi Atish, > > On Wed, Dec 23, 2020 at 9:20 AM Bin Meng wrote: > > > > Hi Atish, > > > > On Wed, Dec 23, 2020 at 3:59 AM Atish Patra > > wrote: > > > > > > On Tue, 2020-12-22 at 13:35 +0800, Bin Meng wrote: > > > > Hi Atish, > > > > > > > > On Sat, Dec 19, 2020 at 3:46 AM Atish Patra < > > > > atish.pa...@wdc.com> > > > > wrote: > > > > > > > > > > On Fri, 2020-12-18 at 16:42 +0800, Bin Meng wrote: > > > > > > Hi Atish, > > > > > > > > > > > > On Fri, Dec 18, 2020 at 4:00 PM Atish Patra < > > > > > > atish.pa...@wdc.com> > > > > > > wrote: > > > > > > > > > > > > > > On Fri, 2020-12-18 at 15:33 +0800, Bin Meng wrote: > > > > > > > > Hi Atish, > > > > > > > > > > > > > > > > On Fri, Dec 18, 2020 at 3:27 PM Atish Patra < > > > > > > > > atish.pa...@wdc.com> > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > On Fri, 2020-12-18 at 15:21 +0800, Bin Meng wrote: > > > > > > > > > > Hi Atish, > > > > > > > > > > > > > > > > > > > > On Fri, Dec 18, 2020 at 5:48 AM Atish Patra > > > > > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > Currently, we place the DTB at 2MB from 4GB or > > > > > > > > > > > end of > > > > > > > > > > > DRAM > > > > > > > > > > > which > > > > > > > > > > > ever is > > > > > > > > > > > lesser. However, Linux kernel can address only > > > > > > > > > > > 1GB of > > > > > > > > > > > memory > > > > > > > > > > > for > > > > > > > > > > > RV32. > > > > > > > > > > > Thus, it can not map anything beyond 3GB > > > > > > > > > > > (assuming 2GB > > > > > > > > > > > is > > > > > > > > > > > the > > > > > > > > > > > starting address). > > > > > > > > > > > As a result, it can not process DT and panic if > > > > > > > > > > > opensbi > > > > > > > > > > > dynamic > > > > > > > > > > > firmware > > > > > > > > > > > is used. > > > > > > > > > > > > > > > > > > > > > > Fix this by placing the DTB at 2MB from 3GB or > > > > > > > > > > > end of > > > > > > > > > > > DRAM > > > > > > > > > > > whichever is lower. > > > > > > > > > > > > > > > > > > > > > > Signed-off-by: Atish Patra > > > > > > > > > > > --- > > > > > > > > > > > hw/riscv/boot.c | 4 ++-- > > > > > > > > > > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > With this patch, 32-bit sifive_u still does not > > > > > > > > > > boot > > > > > > > > > > kernel > > > > > > > > > > with > > > > > > > > > > the > > > > > > > > > > following patch applied on 5.10: > > > > > > > > > > > > > > > > > > > > https://patchwork.kernel.org/project/linux-riscv/patch/20201217074855.1948743-1-atish.pa...@wdc.com/ > > > > > > > > > > > > > > > > > > > > Command I used: > > > > > > > > > > $ qemu-system-riscv32 -nographic -M sifive_u -m 1G > > > > > > > > > > -smp 5 > > > > > > > > > > - > > > > > > > > > > kernel > > > > > > > > > > arch/riscv/boot/Image > > > > > > > > > > > > > > > > > > > > 32-bit virt cannot boot the same kernel image with > > > > > > > > > > memory > > > > > > > > > > set > > > > > > > > > > to > > > > > > > > > > 2G > > > > > > > > > > either: > > > > > > > > > > $ qemu-system-riscv32 -nographic -M virt -m 2G -smp > > > > > > > > > > 4 - > > > > > > > > > > kernel > > > > > > > > > > arch/riscv/boot/Image > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Bin, > > > > > > > > > As mentioned in the email on the linux mailing list, > > > > > > > > > this > > > > > > > > > patch > > > > > > > > > only > > > > > > > > > solves 2GB problem. sifive_u problem is solved by > > > > > > > > > Alistair's > > > > > > > > > patch[1]. > > > > > > > > > > > > > > > > > > He is planning to send the PR soon. The issue with > > > > > > > > > sifive_u > > > > > > > > > boot > > > > > > > > > was it > > > > > > > > > was failing the 32 bit test earlier resulting a 2MB > > > > > > > > > aligned > > > > > > > > > address > > > > > > > > > instead of 4MB. > > > > > > > > > > > > > > > > Ah, I see. However my testing shows that virt with 2G > > > > > > > > still > > > > > > > > does > > > > > > > > not > > > > > > > > boot with this patch. > > > > > > > > > > > > > > > > > > > > > > Strange. I verified again with following combination with > > > > > > > -bios > > > > > > > and > > > > > > > without bios parameter. > > > > > > > > > > > > > > 1. virt 32/64 with 1GB/2GB memory > > > > > > > 2. sifive_u 32/64 bit with 1GB/2GB memory (Alistair's > > > > > > > patch > > > > > > > included) > > > > > > > > > > > > > > Can you share the boot log along with the head commit of > > > > > > > Qemu > > > > > > > and > > > > > > > commandline ? I am using 5.10 kernel with my kernel fix. > > > > > > > > > > > > > > > > > > > I was using Alistair's QEMU repo for testing and 5.10 > > > > > > kernel with > > > > > > your > > > > > > kernel fix: > > > > > > > > > > > > $ git checkout -b testing pull-riscv-to-apply-20201217-1 > > > > > > $ apply this patch > > > > > > $ mkdir bu
[PATCH v3 2/3] Update linux headers to 5.11-rc2
Signed-off-by: Eric Farman
---
.../infiniband/hw/vmw_pvrdma/pvrdma_ring.h| 14 +-
.../infiniband/hw/vmw_pvrdma/pvrdma_verbs.h | 2 +-
include/standard-headers/drm/drm_fourcc.h | 175 +-
include/standard-headers/linux/const.h| 36
include/standard-headers/linux/ethtool.h | 2 +-
include/standard-headers/linux/fuse.h | 30 ++-
include/standard-headers/linux/kernel.h | 9 +-
include/standard-headers/linux/pci_regs.h | 16 ++
include/standard-headers/linux/vhost_types.h | 9 +
include/standard-headers/linux/virtio_gpu.h | 82
include/standard-headers/linux/virtio_ids.h | 44 +++--
linux-headers/asm-arm64/kvm.h | 3 -
linux-headers/asm-generic/unistd.h| 6 +-
linux-headers/asm-mips/unistd_n32.h | 1 +
linux-headers/asm-mips/unistd_n64.h | 1 +
linux-headers/asm-mips/unistd_o32.h | 1 +
linux-headers/asm-powerpc/unistd_32.h | 1 +
linux-headers/asm-powerpc/unistd_64.h | 1 +
linux-headers/asm-s390/unistd_32.h| 1 +
linux-headers/asm-s390/unistd_64.h| 1 +
linux-headers/asm-x86/kvm.h | 1 +
linux-headers/asm-x86/unistd_32.h | 1 +
linux-headers/asm-x86/unistd_64.h | 1 +
linux-headers/asm-x86/unistd_x32.h| 1 +
linux-headers/linux/kvm.h | 56 +-
linux-headers/linux/userfaultfd.h | 9 +
linux-headers/linux/vfio.h| 1 +
linux-headers/linux/vhost.h | 4 +
28 files changed, 461 insertions(+), 48 deletions(-)
create mode 100644 include/standard-headers/linux/const.h
diff --git
a/include/standard-headers/drivers/infiniband/hw/vmw_pvrdma/pvrdma_ring.h
b/include/standard-headers/drivers/infiniband/hw/vmw_pvrdma/pvrdma_ring.h
index 7b4062a1a1..acd4c8346d 100644
--- a/include/standard-headers/drivers/infiniband/hw/vmw_pvrdma/pvrdma_ring.h
+++ b/include/standard-headers/drivers/infiniband/hw/vmw_pvrdma/pvrdma_ring.h
@@ -68,7 +68,7 @@ static inline int pvrdma_idx_valid(uint32_t idx, uint32_t
max_elems)
static inline int32_t pvrdma_idx(int *var, uint32_t max_elems)
{
- const unsigned int idx = qatomic_read(var);
+ const unsigned int idx = atomic_read(var);
if (pvrdma_idx_valid(idx, max_elems))
return idx & (max_elems - 1);
@@ -77,17 +77,17 @@ static inline int32_t pvrdma_idx(int *var, uint32_t
max_elems)
static inline void pvrdma_idx_ring_inc(int *var, uint32_t max_elems)
{
- uint32_t idx = qatomic_read(var) + 1; /* Increment. */
+ uint32_t idx = atomic_read(var) + 1;/* Increment. */
idx &= (max_elems << 1) - 1;/* Modulo size, flip gen. */
- qatomic_set(var, idx);
+ atomic_set(var, idx);
}
static inline int32_t pvrdma_idx_ring_has_space(const struct pvrdma_ring *r,
uint32_t max_elems, uint32_t
*out_tail)
{
- const uint32_t tail = qatomic_read(&r->prod_tail);
- const uint32_t head = qatomic_read(&r->cons_head);
+ const uint32_t tail = atomic_read(&r->prod_tail);
+ const uint32_t head = atomic_read(&r->cons_head);
if (pvrdma_idx_valid(tail, max_elems) &&
pvrdma_idx_valid(head, max_elems)) {
@@ -100,8 +100,8 @@ static inline int32_t pvrdma_idx_ring_has_space(const
struct pvrdma_ring *r,
static inline int32_t pvrdma_idx_ring_has_data(const struct pvrdma_ring *r,
uint32_t max_elems, uint32_t
*out_head)
{
- const uint32_t tail = qatomic_read(&r->prod_tail);
- const uint32_t head = qatomic_read(&r->cons_head);
+ const uint32_t tail = atomic_read(&r->prod_tail);
+ const uint32_t head = atomic_read(&r->cons_head);
if (pvrdma_idx_valid(tail, max_elems) &&
pvrdma_idx_valid(head, max_elems)) {
diff --git
a/include/standard-headers/drivers/infiniband/hw/vmw_pvrdma/pvrdma_verbs.h
b/include/standard-headers/drivers/infiniband/hw/vmw_pvrdma/pvrdma_verbs.h
index 0a8c7c9311..1677208a41 100644
--- a/include/standard-headers/drivers/infiniband/hw/vmw_pvrdma/pvrdma_verbs.h
+++ b/include/standard-headers/drivers/infiniband/hw/vmw_pvrdma/pvrdma_verbs.h
@@ -176,7 +176,7 @@ struct pvrdma_port_attr {
uint8_t subnet_timeout;
uint8_t init_type_reply;
uint8_t active_width;
- uint16_tactive_speed;
+ uint8_t active_speed;
uint8_t phys_state;
uint8_t reserved[2];
};
diff --git a/include/standard-headers/drm/drm_fourcc.h
b/include/standard-headers/drm/drm_fourcc.h
index 0de1a552ca..c47e19810c 100644
--- a/include/standard-headers/drm/drm_fourcc.h
+++ b/include/standard-headers/drm/drm_fourcc.h
@@ -57,6 +57,30 @@ extern "C" {
* may preserve meaning
[PATCH v3 1/3] update-linux-headers: Include const.h
Kernel commit a85cbe6159ff ("uapi: move constants from
to ") breaks our script
because of the unrecognized include. Let's add that to
our processing.
Signed-off-by: Eric Farman
---
scripts/update-linux-headers.sh | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/scripts/update-linux-headers.sh b/scripts/update-linux-headers.sh
index 9efbaf2f84..fa6f2b6272 100755
--- a/scripts/update-linux-headers.sh
+++ b/scripts/update-linux-headers.sh
@@ -41,6 +41,7 @@ cp_portable() {
-e 'pvrdma_verbs' \
-e 'drm.h' \
-e 'limits' \
+ -e 'linux/const' \
-e 'linux/kernel' \
-e 'linux/sysinfo' \
-e 'asm-generic/kvm_para' \
@@ -190,7 +191,9 @@ for i in "$tmpdir"/include/linux/*virtio*.h \
"$tmpdir/include/linux/input.h" \
"$tmpdir/include/linux/input-event-codes.h" \
"$tmpdir/include/linux/pci_regs.h" \
- "$tmpdir/include/linux/ethtool.h" "$tmpdir/include/linux/kernel.h" \
+ "$tmpdir/include/linux/ethtool.h" \
+ "$tmpdir/include/linux/const.h" \
+ "$tmpdir/include/linux/kernel.h" \
"$tmpdir/include/linux/vhost_types.h" \
"$tmpdir/include/linux/sysinfo.h"; do
cp_portable "$i" "$output/include/standard-headers/linux"
--
2.17.1
[PATCH v3 0/3] vfio-ccw: Implement request notifier
Conny, et al, Here is an updated (final?) version of the QEMU series for the vfio-ccw request notifier now that the kernel code landed upstream [1]. The actual meat (patch 3) is identical to its counterpart in v2 [2]. Earlier versions didn't use update-linux-headers.sh; they just carried a dummy patch with the define that was needed to work, without the noise. Here, I have run the script properly and patch 2 is its output. Of course it wasn't that simple, as a change on the kernel side of things breaks the script and causes processing to end prematurely as cp_portable() takes its error exit. So I am adding a small patch to the front of this series to accommodate that, and hopefully isn't goofed up too badly. :) [1] https://lore.kernel.org/kvm/20201216123701.00517...@omen.home/ [2] https://lore.kernel.org/qemu-devel/20201120181526.96446-1-far...@linux.ibm.com/ Eric Farman (3): update-linux-headers: Include const.h Update linux headers to 5.11-rc2 vfio-ccw: Connect the device request notifier hw/vfio/ccw.c | 40 +++- .../infiniband/hw/vmw_pvrdma/pvrdma_ring.h| 14 +- .../infiniband/hw/vmw_pvrdma/pvrdma_verbs.h | 2 +- include/standard-headers/drm/drm_fourcc.h | 175 +- include/standard-headers/linux/const.h| 36 include/standard-headers/linux/ethtool.h | 2 +- include/standard-headers/linux/fuse.h | 30 ++- include/standard-headers/linux/kernel.h | 9 +- include/standard-headers/linux/pci_regs.h | 16 ++ include/standard-headers/linux/vhost_types.h | 9 + include/standard-headers/linux/virtio_gpu.h | 82 include/standard-headers/linux/virtio_ids.h | 44 +++-- linux-headers/asm-arm64/kvm.h | 3 - linux-headers/asm-generic/unistd.h| 6 +- linux-headers/asm-mips/unistd_n32.h | 1 + linux-headers/asm-mips/unistd_n64.h | 1 + linux-headers/asm-mips/unistd_o32.h | 1 + linux-headers/asm-powerpc/unistd_32.h | 1 + linux-headers/asm-powerpc/unistd_64.h | 1 + linux-headers/asm-s390/unistd_32.h| 1 + linux-headers/asm-s390/unistd_64.h| 1 + linux-headers/asm-x86/kvm.h | 1 + linux-headers/asm-x86/unistd_32.h | 1 + linux-headers/asm-x86/unistd_64.h | 1 + linux-headers/asm-x86/unistd_x32.h| 1 + linux-headers/linux/kvm.h | 56 +- linux-headers/linux/userfaultfd.h | 9 + linux-headers/linux/vfio.h| 1 + linux-headers/linux/vhost.h | 4 + scripts/update-linux-headers.sh | 5 +- 30 files changed, 501 insertions(+), 53 deletions(-) create mode 100644 include/standard-headers/linux/const.h -- 2.17.1
Re: [BUG] qemu git error with virgl
Hi Igor, yes, that fixes my issue. Regards, Torsten Am 04.01.21 um 19:50 schrieb Igor Mammedov: On Sun, 3 Jan 2021 18:28:11 +0100 Philippe Mathieu-Daudé wrote: Cc'ing Gerd + patch author/reviewer. On 1/2/21 2:11 PM, Torsten Wohlfarth wrote: Hello, i can't start any system if i use virgl. I get the following error: qemu-x86_64: ../ui/console.c:1791: dpy_gl_ctx_create: Assertion `con->gl' failed. Does following fix issue: [PULL 12/55] vl: initialize displays _after_ exiting preconfiguration ./and.sh: line 27: 3337167 Aborted qemu-x86_64 -m 4096 -smp cores=4,sockets=1 -cpu host -machine pc-q35-4.0,accel=kvm -device virtio-vga,virgl=on,xres=1280,yres=800 -display sdl,gl=on -device intel-hda,id=sound0,msi=on -device hda-micro,id=sound0-codec0,bus=sound0.0,cad=0 -device qemu-xhci,id=xhci -device usb-tablet,bus=xhci.0 -net nic,macaddr=52:54:00:12:34:62,model=e1000 -net tap,ifname=$INTERFACE,script=no,downscript=no -drive file=/media/daten2/image/lineageos.qcow2,if=virtio,index=1,media=disk,cache=none,aio=threads Set 'tap3' nonpersistent i have bicected the issue: towo:Defiant> git bisect good b4e1a342112e50e05b609e857f38c1f2b7aafdc4 is the first bad commit commit b4e1a342112e50e05b609e857f38c1f2b7aafdc4 Author: Paolo Bonzini Date: Tue Oct 27 08:44:23 2020 -0400 vl: remove separate preconfig main_loop Move post-preconfig initialization to the x-exit-preconfig. If preconfig is not requested, just exit preconfig mode immediately with the QMP command. As a result, the preconfig loop will run with accel_setup_post and os_setup_post restrictions (xen_restrict, chroot, etc.) already done. Reviewed-by: Igor Mammedov Signed-off-by: Paolo Bonzini include/sysemu/runstate.h | 1 - monitor/qmp-cmds.c | 9 - softmmu/vl.c | 95 --- 3 files changed, 41 insertions(+), 64 deletions(-) Regards, Torsten Wohlfarth
Re: [PATCH v2 03/12] libqtest: add qtest_kill_qemu()
On 12/7/20 2:20 PM, Stefan Hajnoczi wrote:
Tests that manage multiple processes may wish to kill QEMU before
destroying the QTestState. Expose a function to do that.
The vhost-user-blk-test testcase will need this.
Signed-off-by: Stefan Hajnoczi
---
tests/qtest/libqos/libqtest.h | 11 +++
tests/qtest/libqtest.c| 7 ---
2 files changed, 15 insertions(+), 3 deletions(-)
Reviewed-by: Wainer dos Santos Moschetta
diff --git a/tests/qtest/libqos/libqtest.h b/tests/qtest/libqos/libqtest.h
index e5f1ec590c..51287b9276 100644
--- a/tests/qtest/libqos/libqtest.h
+++ b/tests/qtest/libqos/libqtest.h
@@ -74,6 +74,17 @@ QTestState *qtest_init_without_qmp_handshake(const char
*extra_args);
*/
QTestState *qtest_init_with_serial(const char *extra_args, int *sock_fd);
+/**
+ * qtest_kill_qemu:
+ * @s: #QTestState instance to operate on.
+ *
+ * Kill the QEMU process and wait for it to terminate. It is safe to call this
+ * function multiple times. Normally qtest_quit() is used instead because it
+ * also frees QTestState. Use qtest_kill_qemu() when you just want to kill QEMU
+ * and qtest_quit() will be called later.
+ */
+void qtest_kill_qemu(QTestState *s);
+
/**
* qtest_quit:
* @s: #QTestState instance to operate on.
diff --git a/tests/qtest/libqtest.c b/tests/qtest/libqtest.c
index bc389d422b..cc2cec4a35 100644
--- a/tests/qtest/libqtest.c
+++ b/tests/qtest/libqtest.c
@@ -133,7 +133,7 @@ void qtest_set_expected_status(QTestState *s, int status)
s->expected_status = status;
}
-static void kill_qemu(QTestState *s)
+void qtest_kill_qemu(QTestState *s)
{
pid_t pid = s->qemu_pid;
int wstatus;
@@ -143,6 +143,7 @@ static void kill_qemu(QTestState *s)
kill(pid, SIGTERM);
TFR(pid = waitpid(s->qemu_pid, &s->wstatus, 0));
assert(pid == s->qemu_pid);
+s->qemu_pid = -1;
}
/*
@@ -169,7 +170,7 @@ static void kill_qemu(QTestState *s)
static void kill_qemu_hook_func(void *s)
{
-kill_qemu(s);
+qtest_kill_qemu(s);
}
static void sigabrt_handler(int signo)
@@ -373,7 +374,7 @@ void qtest_quit(QTestState *s)
/* Uninstall SIGABRT handler on last instance */
cleanup_sigabrt_handler();
-kill_qemu(s);
+qtest_kill_qemu(s);
close(s->fd);
close(s->qmp_fd);
g_string_free(s->rx, true);
Re: [PATCH v2 02/12] libqtest: add qtest_socket_server()
On 12/7/20 2:20 PM, Stefan Hajnoczi wrote:
Add an API that returns a new UNIX domain socket in the listen state.
The code for this was already there but only used internally in
init_socket().
This new API will be used by vhost-user-blk-test.
Signed-off-by: Stefan Hajnoczi
---
tests/qtest/libqos/libqtest.h | 8 +++
tests/qtest/libqtest.c| 40 ---
2 files changed, 31 insertions(+), 17 deletions(-)
Reviewed-by: Wainer dos Santos Moschetta
diff --git a/tests/qtest/libqos/libqtest.h b/tests/qtest/libqos/libqtest.h
index 724f65aa94..e5f1ec590c 100644
--- a/tests/qtest/libqos/libqtest.h
+++ b/tests/qtest/libqos/libqtest.h
@@ -132,6 +132,14 @@ void qtest_qmp_send(QTestState *s, const char *fmt, ...)
void qtest_qmp_send_raw(QTestState *s, const char *fmt, ...)
GCC_FMT_ATTR(2, 3);
+/**
+ * qtest_socket_server:
+ * @socket_path: the UNIX domain socket path
+ *
+ * Create and return a listen socket file descriptor, or abort on failure.
+ */
+int qtest_socket_server(const char *socket_path);
+
/**
* qtest_vqmp_fds:
* @s: #QTestState instance to operate on.
diff --git a/tests/qtest/libqtest.c b/tests/qtest/libqtest.c
index e49f3a1e45..bc389d422b 100644
--- a/tests/qtest/libqtest.c
+++ b/tests/qtest/libqtest.c
@@ -81,24 +81,8 @@ static void qtest_client_set_rx_handler(QTestState *s,
QTestRecvFn recv);
static int init_socket(const char *socket_path)
{
-struct sockaddr_un addr;
-int sock;
-int ret;
-
-sock = socket(PF_UNIX, SOCK_STREAM, 0);
-g_assert_cmpint(sock, !=, -1);
-
-addr.sun_family = AF_UNIX;
-snprintf(addr.sun_path, sizeof(addr.sun_path), "%s", socket_path);
+int sock = qtest_socket_server(socket_path);
qemu_set_cloexec(sock);
-
-do {
-ret = bind(sock, (struct sockaddr *)&addr, sizeof(addr));
-} while (ret == -1 && errno == EINTR);
-g_assert_cmpint(ret, !=, -1);
-ret = listen(sock, 1);
-g_assert_cmpint(ret, !=, -1);
-
return sock;
}
@@ -636,6 +620,28 @@ QDict *qtest_qmp_receive_dict(QTestState *s)
return qmp_fd_receive(s->qmp_fd);
}
+int qtest_socket_server(const char *socket_path)
+{
+struct sockaddr_un addr;
+int sock;
+int ret;
+
+sock = socket(PF_UNIX, SOCK_STREAM, 0);
+g_assert_cmpint(sock, !=, -1);
+
+addr.sun_family = AF_UNIX;
+snprintf(addr.sun_path, sizeof(addr.sun_path), "%s", socket_path);
+
+do {
+ret = bind(sock, (struct sockaddr *)&addr, sizeof(addr));
+} while (ret == -1 && errno == EINTR);
+g_assert_cmpint(ret, !=, -1);
+ret = listen(sock, 1);
+g_assert_cmpint(ret, !=, -1);
+
+return sock;
+}
+
/**
* Allow users to send a message without waiting for the reply,
* in the case that they choose to discard all replies up until
Re: [BUG] qemu git error with virgl
On Sun, 3 Jan 2021 18:28:11 +0100 Philippe Mathieu-Daudé wrote: > Cc'ing Gerd + patch author/reviewer. > > On 1/2/21 2:11 PM, Torsten Wohlfarth wrote: > > Hello, > > > > i can't start any system if i use virgl. I get the following error: > > > > qemu-x86_64: ../ui/console.c:1791: dpy_gl_ctx_create: Assertion > > `con->gl' failed. Does following fix issue: [PULL 12/55] vl: initialize displays _after_ exiting preconfiguration > > ./and.sh: line 27: 3337167 Aborted qemu-x86_64 -m 4096 > > -smp cores=4,sockets=1 -cpu host -machine pc-q35-4.0,accel=kvm -device > > virtio-vga,virgl=on,xres=1280,yres=800 -display sdl,gl=on -device > > intel-hda,id=sound0,msi=on -device > > hda-micro,id=sound0-codec0,bus=sound0.0,cad=0 -device qemu-xhci,id=xhci > > -device usb-tablet,bus=xhci.0 -net > > nic,macaddr=52:54:00:12:34:62,model=e1000 -net > > tap,ifname=$INTERFACE,script=no,downscript=no -drive > > file=/media/daten2/image/lineageos.qcow2,if=virtio,index=1,media=disk,cache=none,aio=threads > > > > Set 'tap3' nonpersistent > > > > i have bicected the issue: > > > > towo:Defiant> git bisect good > > b4e1a342112e50e05b609e857f38c1f2b7aafdc4 is the first bad commit > > commit b4e1a342112e50e05b609e857f38c1f2b7aafdc4 > > Author: Paolo Bonzini > > Date: Tue Oct 27 08:44:23 2020 -0400 > > > > vl: remove separate preconfig main_loop > > > > Move post-preconfig initialization to the x-exit-preconfig. If > > preconfig > > is not requested, just exit preconfig mode immediately with the QMP > > command. > > > > As a result, the preconfig loop will run with accel_setup_post > > and os_setup_post restrictions (xen_restrict, chroot, etc.) > > already done. > > > > Reviewed-by: Igor Mammedov > > Signed-off-by: Paolo Bonzini > > > > include/sysemu/runstate.h | 1 - > > monitor/qmp-cmds.c | 9 - > > softmmu/vl.c | 95 > > --- > > 3 files changed, 41 insertions(+), 64 deletions(-) > > > > Regards, > > > > Torsten Wohlfarth > > > > > > > >
RE: [for-6.0 v5 11/13] spapr: PEF: prevent migration
On Mon, Jan 04, 2021 at 01:46:29PM +0100, Halil Pasic wrote:
> On Sun, 3 Jan 2021 23:15:50 -0800
> Ram Pai wrote:
>
> > On Fri, Dec 18, 2020 at 12:41:11PM +0100, Cornelia Huck wrote:
> > > On Thu, 17 Dec 2020 15:15:30 +0100
> [..]
> > > > > > > > +int kvmppc_svm_init(SecurableGuestMemory *sgm, Error **errp)
> > > > > > > > {
> > > > > > > > if (!kvm_check_extension(kvm_state,
> > > > > > > > KVM_CAP_PPC_SECURABLE_GUEST)) {
> > > > > > > > error_setg(errp,
> > > > > > > > @@ -54,6 +58,11 @@ static int kvmppc_svm_init(Error **errp)
> > > > > > > > }
> > > > > > > > }
> > > > > > > >
> > > > > > > > +/* add migration blocker */
> > > > > > > > +error_setg(&pef_mig_blocker, "PEF: Migration is not
> > > > > > > > implemented");
> > > > > > > > +/* NB: This can fail if --only-migratable is used */
> > > > > > > > +migrate_add_blocker(pef_mig_blocker, &error_fatal);
> > > > > > >
> > > > > > > Just so that I understand: is PEF something that is enabled by
> > > > > > > the host
> > > > > > > (and the guest is either secured or doesn't start), or is it
> > > > > > > using a
> > > > > > > model like s390x PV where the guest initiates the transition into
> > > > > > > secured mode?
> > > > > >
> > > > > > Like s390x PV it's initiated by the guest.
> > > > > >
> > > > > > > Asking because s390x adds the migration blocker only when the
> > > > > > > transition is actually happening (i.e. guests that do not
> > > > > > > transition
> > > > > > > into secure mode remain migratable.) This has the side effect
> > > > > > > that you
> > > > > > > might be able to start a machine with --only-migratable that
> > > > > > > transitions into a non-migratable machine via a guest action, if
> > > > > > > I'm
> > > > > > > not mistaken. Without the new object, I don't see a way to block
> > > > > > > with
> > > > > > > --only-migratable; with it, we should be able to do that. Not
> > > > > > > sure what
> > > > > > > the desirable behaviour is here.
> > > > > >
> > > >
> > > > The purpose of --only-migratable is specifically to prevent the machine
> > > > to transition to a non-migrate state IIUC. The guest transition to
> > > > secure mode should be nacked in this case.
> > >
> > > Yes, that's what happens for s390x: The guest tries to transition, QEMU
> > > can't add a migration blocker and fails the instruction used for
> > > transitioning, the guest sees the error.
> > >
> > > The drawback is that we see the failure only when we already launched
> > > the machine and the guest tries to transition. If I start QEMU with
> > > --only-migratable, it will refuse to start when non-migratable devices
> > > are configured in the command line, so I see the issue right from the
> > > start. (For s390x, that would possibly mean that we should not even
> > > present the cpu feature bit when only_migratable is set?)
> >
> > What happens in s390x, if the guest tries to transition to secure, when
> > the secure object is NOT configured on the machine?
> >
>
> Nothing in particular.
>
> > On PEF systems, the transition fails and the guest is terminated.
> >
> > My point is -- QEMU will not be able to predict in advance, what the
> > guest might or might not do, regardless of what devices and objects are
> > configured in the machine. If the guest does something unexpected, it
> > has to be terminated.
>
> We can't fail transition to secure when the secure object is not
> configured on the machine, because that would break pre-existing
> setups.
So the instruction to switch-to-secure; which I believe is a ultracall
on S390, will return success even though the switch-to-secure has failed?
Will the guest continue as a normal guest or as a secure guest?
> This feature is still to be shipped, but secure execution has
> already been shipped, but without migration support.
>
> That's why when you have both the secure object configured, and mandate
> migratability, the we can fail. Actually we should fail now, because the
> two options are not compatible: you can't have a qemu that is guaranteed
> to be migratable, and guaranteed to be able to operate in secure
> execution mode today. Failing early, and not on the guests opt-in would
> be preferable.
>
> After migration support is added, the combo should be fine, and probably
> also the default for secure execution machines.
>
> >
> > So one possible design choice is to let the guest know that migration
> > must be facilitated. It can then decide if it wants to continue as a
> > normal VM or terminate itself, or take the plunge and switch to secure.
> > A well behaving guest will not switch to secure.
> >
>
> I don't understand this point. Sorry.
Qemu will present the 'must-support-migrate' and the 'secure-object' capability
to the guest.
The secure-aware guest, has three choices
(a) terminate itself. OR
(b) not call the switch-to-secure ucall, and continue as normal guest. OR
(
Re: [PATCH v2] tcg: Fix execution on Apple Silicon
On 04.01.21 16:23, Alex Bennée wrote:
Roman Bolshakov writes:
Pages can't be both write and executable at the same time on Apple
Silicon. macOS provides public API to switch write protection [1] for
JIT applications, like TCG.
1.
https://developer.apple.com/documentation/apple_silicon/porting_just-in-time_compilers_to_apple_silicon
Signed-off-by: Roman Bolshakov
---
v1: https://lists.gnu.org/archive/html/qemu-devel/2021-01/msg00073.html
Changes since v1:
- Pruned not needed fiddling with W^X and dropped symmetry from write
lock/unlock and renamed related functions.
Similar approach is used in JavaScriptCore [1].
- Moved jit helper functions to util/osdep
As outlined
in osdep.h, this matches to (2):
* In an ideal world this header would
contain only:
* (1) things which everybody needs
* (2) things without which code would work on most platforms but
*
fail to compile or misbehave on a minority of host OSes
- Fixed a checkpatch error
- Limit new behaviour only to macOS 11.0 and above, because of the
following declarations:
__API_AVAILABLE(macos(11.0))
__API_UNAVAILABLE(ios, tvos, watchos)
void pthread_jit_write_protect_np(int enabled);
__API_AVAILABLE(macos(11.0))
__API_UNAVAILABLE(ios, tvos, watchos)
int pthread_jit_write_protect_supported_np(void);
1. https://bugs.webkit.org/attachment.cgi?id=402515&action=prettypatch
accel/tcg/cpu-exec.c | 2 ++
accel/tcg/translate-all.c | 6 ++
include/qemu/osdep.h | 3 +++
tcg/tcg.c | 1 +
util/osdep.c | 22 ++
5 files changed, 34 insertions(+)
diff --git a/accel/tcg/cpu-exec.c b/accel/tcg/cpu-exec.c
index 8689c54499..374060eb45 100644
--- a/accel/tcg/cpu-exec.c
+++ b/accel/tcg/cpu-exec.c
@@ -175,6 +175,7 @@ static inline tcg_target_ulong cpu_tb_exec(CPUState *cpu,
TranslationBlock *itb)
}
#endif /* DEBUG_DISAS */
+qemu_thread_jit_execute();
ret = tcg_qemu_tb_exec(env, tb_ptr);
cpu->can_do_io = 1;
last_tb = (TranslationBlock *)(ret & ~TB_EXIT_MASK);
@@ -382,6 +383,7 @@ static inline void tb_add_jump(TranslationBlock *tb, int n,
{
uintptr_t old;
+qemu_thread_jit_write();
assert(n < ARRAY_SIZE(tb->jmp_list_next));
qemu_spin_lock(&tb_next->jmp_lock);
diff --git a/accel/tcg/translate-all.c b/accel/tcg/translate-all.c
index b7d50a73d4..88ae5d35ef 100644
--- a/accel/tcg/translate-all.c
+++ b/accel/tcg/translate-all.c
@@ -1072,6 +1072,9 @@ static inline void *alloc_code_gen_buffer(void)
size_t size = tcg_ctx->code_gen_buffer_size;
void *buf;
+#if defined(__APPLE__) && defined(MAC_OS_VERSION_11_0)
+flags |= MAP_JIT;
+#endif
buf = mmap(NULL, size, prot, flags, -1, 0);
if (buf == MAP_FAILED) {
return NULL;
@@ -1485,7 +1488,9 @@ static void do_tb_phys_invalidate(TranslationBlock *tb,
bool rm_from_page_list)
static void tb_phys_invalidate__locked(TranslationBlock *tb)
{
+qemu_thread_jit_write();
do_tb_phys_invalidate(tb, true);
+qemu_thread_jit_execute();
}
/* invalidate one TB
@@ -1687,6 +1692,7 @@ TranslationBlock *tb_gen_code(CPUState *cpu,
#endif
assert_memory_lock();
+qemu_thread_jit_write();
phys_pc = get_page_addr_code(env, pc);
diff --git a/include/qemu/osdep.h b/include/qemu/osdep.h
index f9ec8c84e9..89abebcf5d 100644
--- a/include/qemu/osdep.h
+++ b/include/qemu/osdep.h
@@ -686,4 +686,7 @@ char *qemu_get_host_name(Error **errp);
*/
size_t qemu_get_host_physmem(void);
+void qemu_thread_jit_write(void);
+void qemu_thread_jit_execute(void);
+
#endif
diff --git a/tcg/tcg.c b/tcg/tcg.c
index 43c6cf8f52..ab8488f5d5 100644
--- a/tcg/tcg.c
+++ b/tcg/tcg.c
@@ -1065,6 +1065,7 @@ void tcg_prologue_init(TCGContext *s)
s->pool_labels = NULL;
#endif
+qemu_thread_jit_write();
/* Generate the prologue. */
tcg_target_qemu_prologue(s);
diff --git a/util/osdep.c b/util/osdep.c
index 66d01b9160..80ec7185da 100644
--- a/util/osdep.c
+++ b/util/osdep.c
@@ -606,3 +606,25 @@ writev(int fd, const struct iovec *iov, int iov_cnt)
return readv_writev(fd, iov, iov_cnt, true);
}
#endif
+
+#if defined(__APPLE__) && defined(MAC_OS_VERSION_11_0)
Will this be defined in future
Re: [PULL 00/35] MIPS patches for 2021-01-03
On 1/4/21 7:24 PM, Philippe Mathieu-Daudé wrote:
> On 1/4/21 6:39 PM, Philippe Mathieu-Daudé wrote:
>> On 1/4/21 4:01 PM, Peter Maydell wrote:
>>> On Mon, 4 Jan 2021 at 13:59, Philippe Mathieu-Daudé wrote:
I don't have access to OSX host. I'll see to install an aarch32 chroot and
keep testing (not sure what can differ from an i386 guest).
If I can't find anything I'll resend the same series without the Loongson-3
machine, which is the single part adding QOM objects.
>
> OK I guess I found the problem, we have:
>
> struct LoongsonMachineState {
> MachineState parent_obj;
> MemoryRegion *pio_alias;
> MemoryRegion *mmio_alias;
> MemoryRegion *ecam_alias;
> };
>
> Then:
>
> static inline void loongson3_virt_devices_init(MachineState *machine,
>DeviceState *pic)
> {
> int i;
> qemu_irq irq;
> PCIBus *pci_bus;
> DeviceState *dev;
> MemoryRegion *mmio_reg, *ecam_reg;
> LoongsonMachineState *s = LOONGSON_MACHINE(machine);
>
> LoongsonMachineState is never allocated... Accessing its MR lead
> to BOF.
I'm going to respin with this (pass 32-bit tests):
-- >8 --
diff --git a/hw/mips/loongson3_virt.c b/hw/mips/loongson3_virt.c
index e3723d3dd0f..d4a82fa5367 100644
--- a/hw/mips/loongson3_virt.c
+++ b/hw/mips/loongson3_virt.c
@@ -612,8 +612,10 @@ static void mips_loongson3_virt_init(MachineState
*machine)
loongson3_virt_devices_init(machine, liointc);
}
-static void mips_loongson3_virt_machine_init(MachineClass *mc)
+static void loongson3v_machine_class_init(ObjectClass *oc, void *data)
{
+MachineClass *mc = MACHINE_CLASS(oc);
+
mc->desc = "Loongson-3 Virtualization Platform";
mc->init = mips_loongson3_virt_init;
mc->block_default_type = IF_IDE;
@@ -624,4 +626,13 @@ static void
mips_loongson3_virt_machine_init(MachineClass *mc)
mc->minimum_page_bits = 14;
}
-DEFINE_MACHINE("loongson3-virt", mips_loongson3_virt_machine_init)
+static const TypeInfo loongson3_machine_types[] = {
+{
+.name = TYPE_LOONGSON_MACHINE,
+.parent = TYPE_MACHINE,
+.instance_size = sizeof(LoongsonMachineState),
+.class_init = loongson3v_machine_class_init,
+}
+};
+
+DEFINE_TYPES(loongson3_machine_types)
---
Thanks Peter for catching this (we really need a 32-bit host runner
on GitLab...).
Phil.
Re: [PATCH 5/5] i386: provide simple 'hyperv=on' option to x86 machine types
On Mon, Jan 04, 2021 at 01:54:32PM +0100, Vitaly Kuznetsov wrote:
> Igor Mammedov writes:
>
> >> >
> >> > +/* Hyper-V features enabled with 'hyperv=on' */
> >> > +x86mc->default_hyperv_features = BIT(HYPERV_FEAT_RELAXED) |
> >> > +BIT(HYPERV_FEAT_VAPIC) | BIT(HYPERV_FEAT_TIME) |
> >> > +BIT(HYPERV_FEAT_CRASH) | BIT(HYPERV_FEAT_RESET) |
> >> > +BIT(HYPERV_FEAT_VPINDEX) | BIT(HYPERV_FEAT_RUNTIME) |
> >> > +BIT(HYPERV_FEAT_SYNIC) | BIT(HYPERV_FEAT_STIMER) |
> >> > +BIT(HYPERV_FEAT_FREQUENCIES) | BIT(HYPERV_FEAT_REENLIGHTENMENT)
> >> > |
> >> > +BIT(HYPERV_FEAT_TLBFLUSH) | BIT(HYPERV_FEAT_EVMCS) |
> >> > +BIT(HYPERV_FEAT_IPI) | BIT(HYPERV_FEAT_STIMER_DIRECT);
> > I'd argue that feature bits do not belong to machine code at all.
> > If we have to involve machine at all then it should be a set property/value
> > pairs
> > that machine will set on CPU object (I'm not convinced that doing it
> > from machine code is good idea though).
> >
>
> These are 'features' and not feature bits. 'Bits' here are just our
> internal (to QEMU) representation of which features are enable and which
> are not, we could've just used booleans instead. These feature, when
> enabled, will result in some CPUID changes (not 1:1) but I don't see how
> it's different from
>
> " -machine q35,accel=kvm "
>
> which also results in CPUID changes.
This is a good point, although having accel affect CPUID bits was
also a source of complexity for query-cpu-model-expansion and
other QMP queries.
>
> The main reason for putting this to x86 machine type is versioning, as
> we go along we will (hopefully) be implementing more and more Hyper-V
> features but we want to provide 'one knob to rule them all' but do it in
> a way that will allow migration. We already have 'hv_passthrough' for
> CPU.
I agree completely that the set of bits needs to be on
MachineClass. We just need to agree on the external interface.
>
> >> >
> >> > +if (x86ms->hyperv_enabled) {
> >> > +feat = x86mc->default_hyperv_features;
> >> > +/* Enlightened VMCS is only available on Intel/VMX */
> >> > +if (!cpu_has_vmx(&cpu->env)) {
> >> > +feat &= ~BIT(HYPERV_FEAT_EVMCS);
> >> > +}
> >> > +
> >> > +cpu->hyperv_features |= feat;
> > that will ignore features user explicitly doesn't want,
> > ex:
> > -machine hyperv=on -cpu foo,hv-foo=off
> >
>
> Existing 'hv_passthrough' mode can also affect the result. Personally, I
> don't see where 'hv-foo=off' is needed outside of debugging and these
> use-cases can probably be covered by explicitly listing required
> features but I'm not against making this work, shouldn't be hard.
I'm all for not wasting time supporting use cases that are not
necessary in practice. We just need to document the expected
behavior clearly, whatever we decide to do.
>
> > not sure we would like to introduce such invariant,
> > in normal qom property handling the latest set property should have effect
> > (all other invariants we have in x86 cpu property semantics are comming
> > from legacy handling
> > and I plan to deprecate them (it will affect x86 and sparc cpus) so CPUs
> > will behave like
> > any other QOM object when it come to property handling)
> >
> > anyways it's confusing a bit to have cpu flags to come from 2 different
> > places
> >
> > -cpu hyperv-use-preset=on,hv-foo=off
> >
> > looks less confusing and will heave expected effect
> >
>
> Honestly, 'hyperv-use-preset' is confusing even to me :-)
>
> What if we for a second stop thinking about Hyper-V features being CPU
> features only, e.g. if we want to create Dynamic Memory or PTP or any
> other Hyper-V specific device in a simple way? We'll have to put these
> under machine type.
I agree. Hyper-V is not just a set of CPU features.
Also, those two approaches are not mutually exclusive.
"-machine hyperv=on" can be implemented internally using
"hyperv-use-preset=on" if necessary. I don't think it has to,
however.
--
Eduardo
Re: [PULL 00/35] MIPS patches for 2021-01-03
On 1/4/21 6:39 PM, Philippe Mathieu-Daudé wrote:
> On 1/4/21 4:01 PM, Peter Maydell wrote:
>> On Mon, 4 Jan 2021 at 13:59, Philippe Mathieu-Daudé wrote:
>>> I don't have access to OSX host. I'll see to install an aarch32 chroot and
>>> keep testing (not sure what can differ from an i386 guest).
>>> If I can't find anything I'll resend the same series without the Loongson-3
>>> machine, which is the single part adding QOM objects.
OK I guess I found the problem, we have:
struct LoongsonMachineState {
MachineState parent_obj;
MemoryRegion *pio_alias;
MemoryRegion *mmio_alias;
MemoryRegion *ecam_alias;
};
Then:
static inline void loongson3_virt_devices_init(MachineState *machine,
DeviceState *pic)
{
int i;
qemu_irq irq;
PCIBus *pci_bus;
DeviceState *dev;
MemoryRegion *mmio_reg, *ecam_reg;
LoongsonMachineState *s = LOONGSON_MACHINE(machine);
LoongsonMachineState is never allocated... Accessing its MR lead
to BOF.
[Bug 1909921] Re: Raspberry Pi 4 qemu:handle_cpu_signal received signal outside vCPU context @ pc=0xffff87709b0e
Hello, I'm trying to start a TeamSpeak 3 Server inside my Docker container. Yes, this application is publicly available on the developer website and is free to install and use. Feel free to ask more question or test in other to resolve this matter. Thank you. Regards, -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1909921 Title: Raspberry Pi 4 qemu:handle_cpu_signal received signal outside vCPU context @ pc=0x87709b0e Status in QEMU: New Bug description: Hello, I have a Raspberry Pi 4 with an ESXi hypervisor installed on it (ESXi ARM Edition). I created a CentOS 7 VM on it and I'm using a Docker container which is running qemu inside it. This container is a Debian Bullseye OS and I'm using qemu-i386 to start my application inside it. The error given by qemu is the following : qemu:handle_cpu_signal received signal outside vCPU context @ pc=0x9d5f9b0e qemu:handle_cpu_signal received signal outside vCPU context @ pc=0x82f29b0e (The pc= value is always different, I guess it is randomly generated). My qemu version is : qemu-i386 version 5.1.0 (Debian 1:5.1+dfsg-4+b1) Could you please help me? Why am I facing this error? Feel free to ask any questions regarding this matter in order to find a solution to it! Regards To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1909921/+subscriptions
Re: [Question] SR-IOV VF 'surprise removal' and vfio_reset behavior in pSeries
On Mon, 4 Jan 2021 10:35:45 -0300
Daniel Henrique Barboza wrote:
> Hi,
>
> This question came up while I was investigating a Libvirt bug [1], where an
> user is removing
> VFs from the host while Libvirt domains was using them, causing Libvirt to
> remain in
> an inconsistent state. I'm trying to alleviate the effects of this in Libvirt
> (see [2] if curious),
> but QEMU is throwing some messages in the terminal that, although it appears
> to be benign,
> I'm not sure if it's a symptom of something that should be fixed.
>
> In a Power 9 server running a Mellanox MT28800 SR-IOV netcard I have the
> following IOMMU
> settings, where the physical card is at Group 0 and all the VFs are allocated
> from Group 12 and
> onwards:
>
> IOMMU Group 0 :01:00.0 Infiniband controller [0207]: Mellanox
> Technologies MT28800 Family [ConnectX-5 Ex] [15b3:1019]
> (...)
> IOMMU Group 12 :01:00.2 Infiniband controller [0207]: Mellanox
> Technologies MT27800 Family [ConnectX-5 Virtual Function] [15b3:1018]
> IOMMU Group 13 :01:00.3 Infiniband controller [0207]: Mellanox
> Technologies MT27800 Family [ConnectX-5 Virtual Function] [15b3:1018]
> (...)
>
>
> Creating a guest with the Group 12 VF and trying to remove the VF from the
> host via
>
> echo 0 > /sys/bus/pci/devices/\:01\:00.0/sriov_numvfs
FWIW, "surprise" removal is when the device is essentially already
removed, for example a hotplug NVMe drive that is simply yanked out of
the slot. What you're describing in the above is a coordinated
removal where the PF driver will issue removal callbacks for each VF
device to ask the driver to unbind.
> Makes the guest remove the VF card, but throwing a warning/error message in
> QEMU log:
>
> "qemu-system-ppc64: vfio: Cannot reset device :01:00.2, depends on group
> 0 which is not owned."
This looks like QEMU has hit the but reset code, where a bus reset of a
VF would necessarily require owning the PF, but VFs should always
support FLR. I note that QEMU will try a bus reset if the
VFIO_DEVICE_RESET ioctl fails, which is where we'd try the FLR. I
wonder if we're taking this path simply because locking issues in the
kernel prevent us from performing an FLR in this code path (ie. when
userspace is releasing the device from the driver remove callback).
> I found this message confusing because the VF was occupying IOMMU group 12,
> but the message is
> claiming that the reset wasn't possible because Group 0 wasn't owned by the
> process.
A bus reset would affect all the devices in the slot and therefore
requires ownership of all devices in the slot, but QEMU doesn't own the
PF.
> Digging it a bit, the hotunplug is fired up via the poweroff state of the
> card triggering pSeries internals,
> and then reaching spapr_pci_unplug() in hw/ppc/spapr_pci.c. The body of the
> function reads:
>
> ---
> /* some version guests do not wait for completion of a device
> * cleanup (generally done asynchronously by the kernel) before
> * signaling to QEMU that the device is safe, but instead sleep
> * for some 'safe' period of time. unfortunately on a busy host
> * this sleep isn't guaranteed to be long enough, resulting in
> * bad things like IRQ lines being left asserted during final
> * device removal. to deal with this we call reset just prior
> * to finalizing the device, which will put the device back into
> * an 'idle' state, as the device cleanup code expects.
> */
> pci_device_reset(PCI_DEVICE(plugged_dev));
> ---
>
> My first question is right at this point: do we need PCI reset for a VF
> removal? I am not sure about
> handling IRQ lines asserted for a device that the kernel is going to remove.
I can't speak to this specific code, but it's not uncommon to reset a
device in order to quiesce it. For a VF, it should be sufficient to
disable bus master to quiesce any interrupts since it would only
support MSI/X based interrupts.
> Going on further to the origin on the warning message we get to
> hw/vfio/pci.c, vfio_pci_hot_reset().
> The VFIO_DEVICE_GET_PCI_HOT_RESET_INFO ioctl() is returning all VFs of the
> card, including
> the physical function, in the vfio_pci_hot_reset_info struct. Then, down
> where it verifies if all
> IOMMU groups required for reset belongs to the process, it fails to reset the
> VF because QEMU
> does not have Group 0 ownership:
>
> ---
> ret = ioctl(vdev->vbasedev.fd, VFIO_DEVICE_GET_PCI_HOT_RESET_INFO, info);
> if (ret) {
> ret = -errno;
> error_report("vfio: hot reset info failed: %m");
> goto out_single;
> }
>
> (...)
>
> QLIST_FOREACH(group, &vfio_group_list, next) {
> if (group->groupid == devices[i].group_id) {
> break;
> }
> }
>
> if (!group) {
> if (!vdev->has_pm_reset) {
> error_report("vfio: Cannot reset device %s, "
>
Re: [PATCH] meson: Propagate gnutls dependency
On Mon, 4 Jan 2021 at 17:49, Paolo Bonzini wrote: > On 04/01/21 16:19, Peter Maydell wrote: > > Does this work recursively? For instance monitor/qmp-cmds.c > > needs the gnutls CFLAGS because: > > * qmp-cmds.c includes ui/vnc.h > > * ui/vnc.h includes include/crypto/tlssession.h > > * include/crypto/tlssession.h includes gnutls.h > > > > I don't see anything in monitor/meson.build that says "qmp-cmds.c > > needs whatever ui's dependencies are". > > Hmm, I would have thought it would be handled, but Roman said otherwise. > I'll look into it, at worst we can fix Meson and temporarily apply > Roman's patch until it makes it into a release. NB that for qmp-cmds.c in particular https://patchew.org/QEMU/20210104161200.15068-1-peter.mayd...@linaro.org/ will avoid the accidental inclusion of , though I guess in principle the monitor still needs to say it depends on ui... thanks -- PMM
Re: [PATCH] meson: Propagate gnutls dependency
On 04/01/21 16:19, Peter Maydell wrote: On Mon, 4 Jan 2021 at 14:40, Paolo Bonzini wrote: On 04/01/21 14:21, Peter Maydell wrote: The rest of QEMU should only ever be using QEMU's TLS abstractions and not directly be tied to GNUTLS. So ideally the gnutls flags should only ever be added in the crypto/meson.build, and anything which depends on that should then get the flags indirectly. Unfortunately include/crypto/tlscreds.h leaks this implementation detail That is not a problem. As Daniel said, anything depending on crypto can still get the gnutls flags _indirectly_. In my proposed solution to the bug you'd get that via io_ss.add(crypto, qom) libio = static_library(..., dependencies: io_ss.dependencies()) Does this work recursively? For instance monitor/qmp-cmds.c needs the gnutls CFLAGS because: * qmp-cmds.c includes ui/vnc.h * ui/vnc.h includes include/crypto/tlssession.h * include/crypto/tlssession.h includes gnutls.h I don't see anything in monitor/meson.build that says "qmp-cmds.c needs whatever ui's dependencies are". Hmm, I would have thought it would be handled, but Roman said otherwise. I'll look into it, at worst we can fix Meson and temporarily apply Roman's patch until it makes it into a release. Paolo
[PULL 3/3] tcg: Add tcg_gen_bswap_tl alias
The alias is intended to indicate that the bswap is for the entire target_long. This should avoid ifdefs on some targets. Reviewed-by: Frank Chang Signed-off-by: Richard Henderson --- include/tcg/tcg-op.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/include/tcg/tcg-op.h b/include/tcg/tcg-op.h index 5abf17fecc..5b3bdacc39 100644 --- a/include/tcg/tcg-op.h +++ b/include/tcg/tcg-op.h @@ -1085,6 +1085,7 @@ void tcg_gen_stl_vec(TCGv_vec r, TCGv_ptr base, TCGArg offset, TCGType t); #define tcg_gen_bswap16_tl tcg_gen_bswap16_i64 #define tcg_gen_bswap32_tl tcg_gen_bswap32_i64 #define tcg_gen_bswap64_tl tcg_gen_bswap64_i64 +#define tcg_gen_bswap_tl tcg_gen_bswap64_i64 #define tcg_gen_concat_tl_i64 tcg_gen_concat32_i64 #define tcg_gen_extr_i64_tl tcg_gen_extr32_i64 #define tcg_gen_andc_tl tcg_gen_andc_i64 @@ -1197,6 +1198,7 @@ void tcg_gen_stl_vec(TCGv_vec r, TCGv_ptr base, TCGArg offset, TCGType t); #define tcg_gen_ext32s_tl tcg_gen_mov_i32 #define tcg_gen_bswap16_tl tcg_gen_bswap16_i32 #define tcg_gen_bswap32_tl tcg_gen_bswap32_i32 +#define tcg_gen_bswap_tl tcg_gen_bswap32_i32 #define tcg_gen_concat_tl_i64 tcg_gen_concat_i32_i64 #define tcg_gen_extr_i64_tl tcg_gen_extr_i64_i32 #define tcg_gen_andc_tl tcg_gen_andc_i32 -- 2.25.1
Re: [PULL 00/35] MIPS patches for 2021-01-03
On 1/4/21 4:01 PM, Peter Maydell wrote: > On Mon, 4 Jan 2021 at 13:59, Philippe Mathieu-Daudé wrote: >> I don't have access to OSX host. I'll see to install an aarch32 chroot and >> keep testing (not sure what can differ from an i386 guest). >> If I can't find anything I'll resend the same series without the Loongson-3 >> machine, which is the single part adding QOM objects. > > You might also try using valgrind/address-sanitizer/etc, which can > sometimes flag up this kind of bug on x86-64 even if by default > it happens to work. On 32-bit I hit https://github.com/google/sanitizers/issues/954: $ qemu-system-mips64el AddressSanitizer:DEADLYSIGNAL = ==18063==ERROR: AddressSanitizer: SEGV on unknown address 0xb7f20e40 (pc 0xb7f20e54 bp 0xbf86556c sp 0xbf86552c T16777215) ==18063==The signal is caused by a WRITE memory access. #0 0xb7f20e53 (/lib/ld-linux.so.2+0x11e53) #1 0xeb9b59 (/tmp/build/qemu-system-mips64el+0xa86b59) #2 0xe9c1c2 (/tmp/build/qemu-system-mips64el+0xa691c2) #3 0xb7f1e8ea (/lib/ld-linux.so.2+0xf8ea) #4 0xb7f0fcb9 (/lib/ld-linux.so.2+0xcb9) AddressSanitizer can not provide additional info. SUMMARY: AddressSanitizer: SEGV (/lib/ld-linux.so.2+0x11e53) ==18063==ABORTING What is funny is Aurelien is mentioned in the GCC BZ =) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84761 What libc do you use? I'll try to downgrade or reinstall an old distrib...
[PULL 1/3] tcg: Use memset for large vector byte replication
In f47db80cc07, we handled odd-sized tail clearing for
the case of hosts that have vector operations, but did
not handle the case of hosts that do not have vector ops.
This was ok until e2e7168a214b, which changed the encoding
of simd_desc such that the odd sizes are impossible.
Add memset as a tcg helper, and use that for all out-of-line
byte stores to vectors. This includes, but is not limited to,
the tail clearing operation in question.
Cc: qemu-sta...@nongnu.org
Buglink: https://bugs.launchpad.net/bugs/1907817
Reviewed-by: Philippe Mathieu-Daudé
Signed-off-by: Richard Henderson
---
accel/tcg/tcg-runtime.h | 11 +++
include/exec/helper-proto.h | 4
tcg/tcg-op-gvec.c | 32
3 files changed, 47 insertions(+)
diff --git a/accel/tcg/tcg-runtime.h b/accel/tcg/tcg-runtime.h
index 4eda24e63a..2e36d6eb0c 100644
--- a/accel/tcg/tcg-runtime.h
+++ b/accel/tcg/tcg-runtime.h
@@ -28,6 +28,17 @@ DEF_HELPER_FLAGS_1(lookup_tb_ptr, TCG_CALL_NO_WG_SE, ptr,
env)
DEF_HELPER_FLAGS_1(exit_atomic, TCG_CALL_NO_WG, noreturn, env)
+#ifndef IN_HELPER_PROTO
+/*
+ * Pass calls to memset directly to libc, without a thunk in qemu.
+ * Do not re-declare memset, especially since we fudge the type here;
+ * we assume sizeof(void *) == sizeof(size_t), which is true for
+ * all supported hosts.
+ */
+#define helper_memset memset
+DEF_HELPER_FLAGS_3(memset, TCG_CALL_NO_RWG, ptr, ptr, int, ptr)
+#endif /* IN_HELPER_PROTO */
+
#ifdef CONFIG_SOFTMMU
DEF_HELPER_FLAGS_5(atomic_cmpxchgb, TCG_CALL_NO_WG,
diff --git a/include/exec/helper-proto.h b/include/exec/helper-proto.h
index a0a8d9aa46..659f9298e8 100644
--- a/include/exec/helper-proto.h
+++ b/include/exec/helper-proto.h
@@ -35,11 +35,15 @@ dh_ctype(ret) HELPER(name) (dh_ctype(t1), dh_ctype(t2),
dh_ctype(t3), \
dh_ctype(t4), dh_ctype(t5), dh_ctype(t6), \
dh_ctype(t7));
+#define IN_HELPER_PROTO
+
#include "helper.h"
#include "trace/generated-helpers.h"
#include "tcg-runtime.h"
#include "plugin-helpers.h"
+#undef IN_HELPER_PROTO
+
#undef DEF_HELPER_FLAGS_0
#undef DEF_HELPER_FLAGS_1
#undef DEF_HELPER_FLAGS_2
diff --git a/tcg/tcg-op-gvec.c b/tcg/tcg-op-gvec.c
index ddbe06b71a..1a41dfa908 100644
--- a/tcg/tcg-op-gvec.c
+++ b/tcg/tcg-op-gvec.c
@@ -547,6 +547,9 @@ static void do_dup(unsigned vece, uint32_t dofs, uint32_t
oprsz,
in_c = dup_const(vece, in_c);
if (in_c == 0) {
oprsz = maxsz;
+vece = MO_8;
+} else if (in_c == dup_const(MO_8, in_c)) {
+vece = MO_8;
}
}
@@ -628,6 +631,35 @@ static void do_dup(unsigned vece, uint32_t dofs, uint32_t
oprsz,
/* Otherwise implement out of line. */
t_ptr = tcg_temp_new_ptr();
tcg_gen_addi_ptr(t_ptr, cpu_env, dofs);
+
+/*
+ * This may be expand_clr for the tail of an operation, e.g.
+ * oprsz == 8 && maxsz == 64. The size of the clear is misaligned
+ * wrt simd_desc and will assert. Simply pass all replicated byte
+ * stores through to memset.
+ */
+if (oprsz == maxsz && vece == MO_8) {
+TCGv_ptr t_size = tcg_const_ptr(oprsz);
+TCGv_i32 t_val;
+
+if (in_32) {
+t_val = in_32;
+} else if (in_64) {
+t_val = tcg_temp_new_i32();
+tcg_gen_extrl_i64_i32(t_val, in_64);
+} else {
+t_val = tcg_const_i32(in_c);
+}
+gen_helper_memset(t_ptr, t_ptr, t_val, t_size);
+
+if (!in_32) {
+tcg_temp_free_i32(t_val);
+}
+tcg_temp_free_ptr(t_size);
+tcg_temp_free_ptr(t_ptr);
+return;
+}
+
t_desc = tcg_const_i32(simd_desc(oprsz, maxsz, 0));
if (vece == MO_64) {
--
2.25.1
[PULL 2/3] tcg/riscv: Fix illegal shift instructions
From: Zihao Yu
Out-of-range shifts have undefined results, but must not trap.
Mask off immediate shift counts to solve this problem.
This bug can be reproduced by running the following guest instructions:
xor %ecx,%ecx
sar %cl,%eax
cmovne %edi,%eax
After optimization, the tcg opcodes of the sar are
movi_i32 tmp3,$0x pref=all
sar_i32 tmp3,eax,tmp3 dead: 2 pref=all
mov_i32 cc_dst,eax sync: 0 dead: 1 pref=0xffc0300
mov_i32 cc_src,tmp3sync: 0 dead: 0 1 pref=all
movi_i32 cc_op,$0x31 sync: 0 dead: 0 pref=all
The sar_i32 opcode is a shift by -1, which unmasked generates
0x200808d618: fffa5b9b illegal
Signed-off-by: Zihao Yu
Message-Id: <20201216081206.9628-1-yuzi...@ict.ac.cn>
[rth: Reworded the patch description.]
Signed-off-by: Richard Henderson
---
tcg/riscv/tcg-target.c.inc | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/tcg/riscv/tcg-target.c.inc b/tcg/riscv/tcg-target.c.inc
index d536f3ccc1..4089e29cd9 100644
--- a/tcg/riscv/tcg-target.c.inc
+++ b/tcg/riscv/tcg-target.c.inc
@@ -1462,14 +1462,14 @@ static void tcg_out_op(TCGContext *s, TCGOpcode opc,
case INDEX_op_shl_i32:
if (c2) {
-tcg_out_opc_imm(s, OPC_SLLIW, a0, a1, a2);
+tcg_out_opc_imm(s, OPC_SLLIW, a0, a1, a2 & 0x1f);
} else {
tcg_out_opc_reg(s, OPC_SLLW, a0, a1, a2);
}
break;
case INDEX_op_shl_i64:
if (c2) {
-tcg_out_opc_imm(s, OPC_SLLI, a0, a1, a2);
+tcg_out_opc_imm(s, OPC_SLLI, a0, a1, a2 & 0x3f);
} else {
tcg_out_opc_reg(s, OPC_SLL, a0, a1, a2);
}
@@ -1477,14 +1477,14 @@ static void tcg_out_op(TCGContext *s, TCGOpcode opc,
case INDEX_op_shr_i32:
if (c2) {
-tcg_out_opc_imm(s, OPC_SRLIW, a0, a1, a2);
+tcg_out_opc_imm(s, OPC_SRLIW, a0, a1, a2 & 0x1f);
} else {
tcg_out_opc_reg(s, OPC_SRLW, a0, a1, a2);
}
break;
case INDEX_op_shr_i64:
if (c2) {
-tcg_out_opc_imm(s, OPC_SRLI, a0, a1, a2);
+tcg_out_opc_imm(s, OPC_SRLI, a0, a1, a2 & 0x3f);
} else {
tcg_out_opc_reg(s, OPC_SRL, a0, a1, a2);
}
@@ -1492,14 +1492,14 @@ static void tcg_out_op(TCGContext *s, TCGOpcode opc,
case INDEX_op_sar_i32:
if (c2) {
-tcg_out_opc_imm(s, OPC_SRAIW, a0, a1, a2);
+tcg_out_opc_imm(s, OPC_SRAIW, a0, a1, a2 & 0x1f);
} else {
tcg_out_opc_reg(s, OPC_SRAW, a0, a1, a2);
}
break;
case INDEX_op_sar_i64:
if (c2) {
-tcg_out_opc_imm(s, OPC_SRAI, a0, a1, a2);
+tcg_out_opc_imm(s, OPC_SRAI, a0, a1, a2 & 0x3f);
} else {
tcg_out_opc_reg(s, OPC_SRA, a0, a1, a2);
}
--
2.25.1
[PULL 0/3] tcg patch queue
The following changes since commit 41192db338588051f21501abc13743e62b0a5605: Merge remote-tracking branch 'remotes/ehabkost-gl/tags/machine-next-pull-request' into staging (2021-01-01 22:57:15 +) are available in the Git repository at: https://gitlab.com/rth7680/qemu.git tags/pull-tcg-20210104 for you to fetch changes up to a66424ba17d661007dc13d78c9e3014ccbaf0efb: tcg: Add tcg_gen_bswap_tl alias (2021-01-04 06:32:58 -1000) Fix vector clear issue. Fix riscv host shift issue. Add tcg_gen_bswap_tl. Richard Henderson (2): tcg: Use memset for large vector byte replication tcg: Add tcg_gen_bswap_tl alias Zihao Yu (1): tcg/riscv: Fix illegal shift instructions accel/tcg/tcg-runtime.h | 11 +++ include/exec/helper-proto.h | 4 include/tcg/tcg-op.h| 2 ++ tcg/tcg-op-gvec.c | 32 tcg/riscv/tcg-target.c.inc | 12 ++-- 5 files changed, 55 insertions(+), 6 deletions(-)
Re: [PATCH] meson: Propagate gnutls dependency
On Sat, Jan 02, 2021 at 08:43:51PM +0100, Paolo Bonzini wrote:
> On 02/01/21 14:25, Peter Maydell wrote:
> > Question to Paolo -- it seems pretty fragile to have to explicitly
> > list "these source files need these extra CFLAGS" in half a dozen
> > meson.build files, because it's pretty non-obvious that adding
> > eg '#include "block/nbd.h"' to a .c file means that you also
> > need to update the meson.build file to say "and now it needs these
> > extra CFLAGS". Isn't there some way we can just have the CFLAGS
> > added more globally so that if we use gnutls.h directly or
> > indirectly from more .c files in future it Just Works ?
> >
> > If the build failed for the common Linux case then it would be
> > at least more obvious that you needed to update the meson.build
> > files. I think it's better to avoid "you need to do this special
> > thing that you'll only notice you're missing if you happen to test
> > on a somewhat obscure host configuration" where we can.
> >
> > (We don't want to link helper binaries etc against gnutls if
> > they don't need it, but that's LDFLAGS, not CFLAGS.)
>
> The gnutls dependency will already propagate from
>
> if 'CONFIG_GNUTLS' in config_host
> crypto_ss.add(gnutls)
> endif
>
> to
>
> libcrypto = static_library('crypto', crypto_ss.sources() + genh,
> dependencies: [crypto_ss.dependencies()], ...)
> crypto = declare_dependency(link_whole: libcrypto,
> dependencies: [authz, qom])
>
Hi Paolo,
I'm sorry I didn't reply earlier. As I showed in an example to Peter
(https://lists.gnu.org/archive/html/qemu-devel/2021-01/msg00085.html):
https://github.com/mesonbuild/meson/commit/ff5dc65ef841857dd306694dff1fb1cd2bf801e4
The approach doesn't propogate dependencies of crypto beyond libcrypto.
i.e. if you specify crypto somewhere else as depedency, it won't pull
CFLAGS needed for gnutls.
> That is, Meson does know that everything that needs crypto needs gnutls (see
> get_dependencies in mesonbuild/build.py if you're curious).
>
Thanks. I've been thinking to tinker with it (that's why I made the test case).
Sounds like meson has some issues with transitive dependencies.
> I think the issue is that dependencies are listed too late---in the
> declare_dependency rather than the static_library. Take io/ for example:
>
> libio = static_library('io', io_ss.sources() + genh,
>dependencies: [io_ss.dependencies()],
>link_with: libqemuutil,
>name_suffix: 'fa',
>build_by_default: false)
> io = declare_dependency(link_whole: libio, dependencies: [crypto, qom])
>
> Listing "crypto" in io's declare_dependency is enough to propagate the
> gnutls LDFLAGS down to the executables, but it does not add the CFLAGS to
> io/ files itself. So for the io/ files we aren't telling meson that they
> need crypto (and thus in turn gnutls on the include path).
>
> The fix should be pretty simple and localized to the "Library dependencies"
> section of meson.build. For the two libraries above, the fixed version
> would look like:
>
> crypto_ss.add(authz, qom)
> libcrypto = ... # same as above
> crypto = declare_dependency(link_whole: libcrypto)
>
> io_ss.add(crypto, qom)
> ...
> libio = ... # same as above
> io = declare_dependency(link_whole: libio)
>
> (Roman, feel free to plunder the above if you want to turn it into a commit
> message, and if it's correct of course).
>
Unfortunately it doesn't work, even if crypto is added to io_ss. I think
that's the same issue as in shown in test case above. The patch is
below:
diff --git a/hw/nvram/meson.build b/hw/nvram/meson.build
index fd2951a860..1f2ed013b2 100644
--- a/hw/nvram/meson.build
+++ b/hw/nvram/meson.build
@@ -1,6 +1,3 @@
-# QOM interfaces must be available anytime QOM is used.
-qom_ss.add(files('fw_cfg-interface.c'))
-
softmmu_ss.add(files('fw_cfg.c'))
softmmu_ss.add(when: 'CONFIG_CHRP_NVRAM', if_true: files('chrp_nvram.c'))
softmmu_ss.add(when: 'CONFIG_DS1225Y', if_true: files('ds1225y.c'))
diff --git a/io/meson.build b/io/meson.build
index bcd8b1e737..a844271b17 100644
--- a/io/meson.build
+++ b/io/meson.build
@@ -12,4 +12,4 @@ io_ss.add(files(
'dns-resolver.c',
'net-listener.c',
'task.c',
-))
+), crypto)
diff --git a/meson.build b/meson.build
index 372576f82c..c293ee39e4 100644
--- a/meson.build
+++ b/meson.build
@@ -1538,6 +1538,33 @@ libqemuutil = static_library('qemuutil',
qemuutil = declare_dependency(link_with: libqemuutil,
sources: genh + version_res)
+# QOM interfaces must be available anytime QOM is used.
+qom_ss.add(files('hw/nvram/fw_cfg-interface.c'))
+qom_ss = qom_ss.apply(config_host, strict: false)
+libqom = static_library('qom', qom_ss.sources() + genh,
+dependencies: [qom_ss.dependencies()],
+name_suffix: 'fa')
+
+qom = declare_dependency(link_whole: libqom)
+
+authz_ss = aut
Re: [PULL 0/1] Block patches
On Mon, 4 Jan 2021 at 14:23, Stefan Hajnoczi wrote: > > The following changes since commit 41192db338588051f21501abc13743e62b0a5605: > > Merge remote-tracking branch > 'remotes/ehabkost-gl/tags/machine-next-pull-request' into staging (2021-01-01 > 22:57:15 +) > > are available in the Git repository at: > > https://gitlab.com/stefanha/qemu.git tags/block-pull-request > > for you to fetch changes up to 593621f36b716eb091c4ec791db72dd4461789da: > > readline: Fix possible array index out of bounds in readline_hist_add() > (2021-01-04 11:13:39 +) > > > Pull request > > Applied, thanks. Please update the changelog at https://wiki.qemu.org/ChangeLog/6.0 for any user-visible changes. -- PMM
[PATCH v3 3/3] nvdimm: check -object memory-backend-file, readonly=on option
Check that -device nvdimm,unarmed=on is used when -object
memory-backend-file,readonly=on and document that -device
nvdimm,unarmed=on|off controls whether the NVDIMM appears read-only to
the guest.
Acked-by: Michael S. Tsirkin
Reviewed-by: Philippe Mathieu-Daudé
Reviewed-by: Liam Merwick
Signed-off-by: Stefan Hajnoczi
---
v3:
* Produce an error when -device nvdimm,unarmed=off is used with -object
memory-backend-file,readonly=on instead of silently switching on
unarmed. [Igor]
---
docs/nvdimm.txt | 24 +---
hw/mem/nvdimm.c | 9 +
2 files changed, 26 insertions(+), 7 deletions(-)
diff --git a/docs/nvdimm.txt b/docs/nvdimm.txt
index c2c6e441b3..0aae682be3 100644
--- a/docs/nvdimm.txt
+++ b/docs/nvdimm.txt
@@ -17,8 +17,8 @@ following command line options:
-machine pc,nvdimm
-m $RAM_SIZE,slots=$N,maxmem=$MAX_SIZE
- -object memory-backend-file,id=mem1,share=on,mem-path=$PATH,size=$NVDIMM_SIZE
- -device nvdimm,id=nvdimm1,memdev=mem1
+ -object
memory-backend-file,id=mem1,share=on,mem-path=$PATH,size=$NVDIMM_SIZE,readonly=off
+ -device nvdimm,id=nvdimm1,memdev=mem1,unarmed=off
Where,
@@ -31,9 +31,10 @@ Where,
of normal RAM devices and vNVDIMM devices, e.g. $MAX_SIZE should be
>= $RAM_SIZE + $NVDIMM_SIZE here.
- - "object
memory-backend-file,id=mem1,share=on,mem-path=$PATH,size=$NVDIMM_SIZE"
- creates a backend storage of size $NVDIMM_SIZE on a file $PATH. All
- accesses to the virtual NVDIMM device go to the file $PATH.
+ - "object memory-backend-file,id=mem1,share=on,mem-path=$PATH,
+ size=$NVDIMM_SIZE,readonly=off" creates a backend storage of size
+ $NVDIMM_SIZE on a file $PATH. All accesses to the virtual NVDIMM device go
+ to the file $PATH.
"share=on/off" controls the visibility of guest writes. If
"share=on", then guest writes will be applied to the backend
@@ -42,8 +43,17 @@ Where,
"share=off", then guest writes won't be applied to the backend
file and thus will be invisible to other guests.
- - "device nvdimm,id=nvdimm1,memdev=mem1" creates a virtual NVDIMM
- device whose storage is provided by above memory backend device.
+ "readonly=on/off" controls whether the file $PATH is opened read-only or
+ read/write (default).
+
+ - "device nvdimm,id=nvdimm1,memdev=mem1,unarmed=off" creates a read/write
+ virtual NVDIMM device whose storage is provided by above memory backend
+ device.
+
+ "unarmed" controls the ACPI NFIT NVDIMM Region Mapping Structure "NVDIMM
+ State Flags" Bit 3 indicating that the device is "unarmed" and cannot accept
+ persistent writes. Linux guest drivers set the device to read-only when this
+ bit is present. Set unarmed to on when the memdev has readonly=on.
Multiple vNVDIMM devices can be created if multiple pairs of "-object"
and "-device" are provided.
diff --git a/hw/mem/nvdimm.c b/hw/mem/nvdimm.c
index 03c2201b56..e0a9d606e1 100644
--- a/hw/mem/nvdimm.c
+++ b/hw/mem/nvdimm.c
@@ -146,6 +146,15 @@ static void nvdimm_prepare_memory_region(NVDIMMDevice
*nvdimm, Error **errp)
return;
}
+if (!nvdimm->unarmed && memory_region_is_rom(mr)) {
+HostMemoryBackend *hostmem = dimm->hostmem;
+
+error_setg(errp, "'unarmed' property must be off since memdev %s "
+ "is read-only",
+ object_get_canonical_path_component(OBJECT(hostmem)));
+return;
+}
+
nvdimm->nvdimm_mr = g_new(MemoryRegion, 1);
memory_region_init_alias(nvdimm->nvdimm_mr, OBJECT(dimm),
"nvdimm-memory", mr, 0, pmem_size);
--
2.29.2
Re: [PATCH] monitor/qmp-cmds.c: Don't include ui/vnc.h
On Mon, 4 Jan 2021 at 16:30, Philippe Mathieu-Daudé wrote: > > On 1/4/21 5:12 PM, Peter Maydell wrote: > > The qmp-cmds.c file currently includes ui/vnc.h, which (being located > > in the ui/ directory rather than include) is really supposed to be > > for use only by the ui subsystem. > > That makes me remember yet another cleanup series I started few months > ago to remove -I$(srcdir) from $CFLAGS. Now that Meson is in, I might > eventually refresh it. Yeah, I just floated that idea on IRC. I bet we have a ton of places that don't follow the "headers not in include/ are supposed to be subsystem-internal" guideline, though, so it feels like one of those "whether it's worth the effort depends on how painful it is" cleanups... thanks -- PMM
[PATCH v3 0/3] nvdimm: read-only file support
v3: * Produce an error when -device nvdimm,unarmed=off is used with -object memory-backend-file,readonly=on instead of silently switching on unarmed. [Igor] * Use Object *obj instead of Object *o [Igor] * Do not dereference MEMORY_BACKEND_FILE(o)->readonly directly, use a local variable to hold the HostMemoryBackendFile pointer. [Igor] v2: * s/the the/the/ in documentation [Philippe] * Assign nvdimm->unarmed earlier [Philippe] There is currently no way to back an NVDIMM with a read-only file so it can be safely shared between untrusted guests. Introduce an -object memory-backend-file,readonly=on|off option. Julio Montes sent an earlier patch here: https://patchew.org/QEMU/20190708211936.8037-1-julio.mon...@intel.com/ Eric Ernst requested this feature again for Kata Containers so I gave it a try. Stefan Hajnoczi (3): memory: add readonly support to memory_region_init_ram_from_file() hostmem-file: add readonly=on|off option nvdimm: check -object memory-backend-file,readonly=on option docs/nvdimm.txt | 24 +--- include/exec/memory.h | 2 ++ include/exec/ram_addr.h | 5 +++-- include/qemu/mmap-alloc.h | 2 ++ backends/hostmem-file.c | 28 +++- hw/mem/nvdimm.c | 9 + softmmu/memory.c | 7 +-- softmmu/physmem.c | 18 +++--- util/mmap-alloc.c | 10 ++ util/oslib-posix.c| 2 +- qemu-options.hx | 5 - 11 files changed, 87 insertions(+), 25 deletions(-) -- 2.29.2
[PATCH v3 1/3] memory: add readonly support to memory_region_init_ram_from_file()
There is currently no way to open(O_RDONLY) and mmap(PROT_READ) when creating a memory region from a file. This functionality is needed since the underlying host file may not allow writing. Add a bool readonly argument to memory_region_init_ram_from_file() and the APIs it calls. Extend memory_region_init_ram_from_file() rather than introducing a memory_region_init_rom_from_file() API so that callers can easily make a choice between read/write and read-only at runtime without calling different APIs. No new RAMBlock flag is introduced for read-only because it's unclear whether RAMBlocks need to know that they are read-only. Pass a bool readonly argument instead. Both of these design decisions can be changed in the future. It just seemed like the simplest approach to me. Acked-by: Michael S. Tsirkin Reviewed-by: Philippe Mathieu-Daudé Reviewed-by: Igor Mammedov Reviewed-by: Liam Merwick Signed-off-by: Stefan Hajnoczi --- include/exec/memory.h | 2 ++ include/exec/ram_addr.h | 5 +++-- include/qemu/mmap-alloc.h | 2 ++ backends/hostmem-file.c | 2 +- softmmu/memory.c | 7 +-- softmmu/physmem.c | 18 +++--- util/mmap-alloc.c | 10 ++ util/oslib-posix.c| 2 +- 8 files changed, 31 insertions(+), 17 deletions(-) diff --git a/include/exec/memory.h b/include/exec/memory.h index 521d9901d7..c6ce74fb79 100644 --- a/include/exec/memory.h +++ b/include/exec/memory.h @@ -966,6 +966,7 @@ void memory_region_init_resizeable_ram(MemoryRegion *mr, * - RAM_PMEM: the memory is persistent memory * Other bits are ignored now. * @path: the path in which to allocate the RAM. + * @readonly: true to open @path for reading, false for read/write. * @errp: pointer to Error*, to store an error if it happens. * * Note that this function does not do anything to cause the data in the @@ -978,6 +979,7 @@ void memory_region_init_ram_from_file(MemoryRegion *mr, uint64_t align, uint32_t ram_flags, const char *path, + bool readonly, Error **errp); /** diff --git a/include/exec/ram_addr.h b/include/exec/ram_addr.h index c6d2ef1d07..40b16609ab 100644 --- a/include/exec/ram_addr.h +++ b/include/exec/ram_addr.h @@ -110,6 +110,7 @@ long qemu_maxrampagesize(void); * - RAM_PMEM: the backend @mem_path or @fd is persistent memory * Other bits are ignored. * @mem_path or @fd: specify the backing file or device + * @readonly: true to open @path for reading, false for read/write. * @errp: pointer to Error*, to store an error if it happens * * Return: @@ -118,9 +119,9 @@ long qemu_maxrampagesize(void); */ RAMBlock *qemu_ram_alloc_from_file(ram_addr_t size, MemoryRegion *mr, uint32_t ram_flags, const char *mem_path, - Error **errp); + bool readonly, Error **errp); RAMBlock *qemu_ram_alloc_from_fd(ram_addr_t size, MemoryRegion *mr, - uint32_t ram_flags, int fd, + uint32_t ram_flags, int fd, bool readonly, Error **errp); RAMBlock *qemu_ram_alloc_from_ptr(ram_addr_t size, void *host, diff --git a/include/qemu/mmap-alloc.h b/include/qemu/mmap-alloc.h index e786266b92..8b7a5c70f3 100644 --- a/include/qemu/mmap-alloc.h +++ b/include/qemu/mmap-alloc.h @@ -14,6 +14,7 @@ size_t qemu_mempath_getpagesize(const char *mem_path); * @size: the number of bytes to be mmaped * @align: if not zero, specify the alignment of the starting mapping address; * otherwise, the alignment in use will be determined by QEMU. + * @readonly: true for a read-only mapping, false for read/write. * @shared: map has RAM_SHARED flag. * @is_pmem: map has RAM_PMEM flag. * @@ -24,6 +25,7 @@ size_t qemu_mempath_getpagesize(const char *mem_path); void *qemu_ram_mmap(int fd, size_t size, size_t align, +bool readonly, bool shared, bool is_pmem); diff --git a/backends/hostmem-file.c b/backends/hostmem-file.c index 40e1e5b3e3..e827692124 100644 --- a/backends/hostmem-file.c +++ b/backends/hostmem-file.c @@ -56,7 +56,7 @@ file_backend_memory_alloc(HostMemoryBackend *backend, Error **errp) backend->size, fb->align, (backend->share ? RAM_SHARED : 0) | (fb->is_pmem ? RAM_PMEM : 0), - fb->mem_path, errp); + fb->mem_path, false, errp); g_free(name); #endif } diff --git a/softmmu/memory.c b/softmmu/memory.c index 333e1ed7b0..676c298b60 10
[PATCH v3 2/3] hostmem-file: add readonly=on|off option
Let -object memory-backend-file work on read-only files when the
readonly=on option is given. This can be used to share the contents of a
file between multiple guests while preventing them from consuming
Copy-on-Write memory if guests dirty the pages, for example.
Acked-by: Michael S. Tsirkin
Reviewed-by: Philippe Mathieu-Daudé
Reviewed-by: Liam Merwick
Signed-off-by: Stefan Hajnoczi
---
v3:
* Use Object *obj instead of Object *o [Igor]
* Do not dereference MEMORY_BACKEND_FILE(o)->readonly directly, use a
local variable to hold the HostMemoryBackendFile pointer. [Igor]
---
backends/hostmem-file.c | 28 +++-
qemu-options.hx | 5 -
2 files changed, 31 insertions(+), 2 deletions(-)
diff --git a/backends/hostmem-file.c b/backends/hostmem-file.c
index e827692124..733408e076 100644
--- a/backends/hostmem-file.c
+++ b/backends/hostmem-file.c
@@ -29,6 +29,7 @@ struct HostMemoryBackendFile {
uint64_t align;
bool discard_data;
bool is_pmem;
+bool readonly;
};
static void
@@ -56,7 +57,7 @@ file_backend_memory_alloc(HostMemoryBackend *backend, Error
**errp)
backend->size, fb->align,
(backend->share ? RAM_SHARED : 0) |
(fb->is_pmem ? RAM_PMEM : 0),
- fb->mem_path, false, errp);
+ fb->mem_path, fb->readonly, errp);
g_free(name);
#endif
}
@@ -151,6 +152,28 @@ static void file_memory_backend_set_pmem(Object *o, bool
value, Error **errp)
fb->is_pmem = value;
}
+static bool file_memory_backend_get_readonly(Object *obj, Error **errp)
+{
+HostMemoryBackendFile *fb = MEMORY_BACKEND_FILE(obj);
+
+return fb->readonly;
+}
+
+static void file_memory_backend_set_readonly(Object *obj, bool value,
+ Error **errp)
+{
+HostMemoryBackend *backend = MEMORY_BACKEND(obj);
+HostMemoryBackendFile *fb = MEMORY_BACKEND_FILE(obj);
+
+if (host_memory_backend_mr_inited(backend)) {
+error_setg(errp, "cannot change property 'readonly' of %s.",
+ object_get_typename(obj));
+return;
+}
+
+fb->readonly = value;
+}
+
static void file_backend_unparent(Object *obj)
{
HostMemoryBackend *backend = MEMORY_BACKEND(obj);
@@ -182,6 +205,9 @@ file_backend_class_init(ObjectClass *oc, void *data)
NULL, NULL);
object_class_property_add_bool(oc, "pmem",
file_memory_backend_get_pmem, file_memory_backend_set_pmem);
+object_class_property_add_bool(oc, "readonly",
+file_memory_backend_get_readonly,
+file_memory_backend_set_readonly);
}
static void file_backend_instance_finalize(Object *o)
diff --git a/qemu-options.hx b/qemu-options.hx
index 459c916d3d..4732c6b45e 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -4407,7 +4407,7 @@ SRST
they are specified. Note that the 'id' property must be set. These
objects are placed in the '/objects' path.
-``-object
memory-backend-file,id=id,size=size,mem-path=dir,share=on|off,discard-data=on|off,merge=on|off,dump=on|off,prealloc=on|off,host-nodes=host-nodes,policy=default|preferred|bind|interleave,align=align``
+``-object
memory-backend-file,id=id,size=size,mem-path=dir,share=on|off,discard-data=on|off,merge=on|off,dump=on|off,prealloc=on|off,host-nodes=host-nodes,policy=default|preferred|bind|interleave,align=align,readonly=on|off``
Creates a memory file backend object, which can be used to back
the guest RAM with huge pages.
@@ -4490,6 +4490,9 @@ SRST
4.15) and the filesystem of ``mem-path`` mounted with DAX
option.
+The ``readonly`` option specifies whether the backing file is opened
+read-only or read-write (default).
+
``-object
memory-backend-ram,id=id,merge=on|off,dump=on|off,share=on|off,prealloc=on|off,size=size,host-nodes=host-nodes,policy=default|preferred|bind|interleave``
Creates a memory backend object, which can be used to back the
guest RAM. Memory backend objects offer more control than the
--
2.29.2
Re: [PATCH] monitor/qmp-cmds.c: Don't include ui/vnc.h
On 1/4/21 5:12 PM, Peter Maydell wrote: > The qmp-cmds.c file currently includes ui/vnc.h, which (being located > in the ui/ directory rather than include) is really supposed to be > for use only by the ui subsystem. That makes me remember yet another cleanup series I started few months ago to remove -I$(srcdir) from $CFLAGS. Now that Meson is in, I might eventually refresh it. > In fact the function prototypes we > need (vnc_display_password(), etc) are all declared in > include/ui/console.h, so we can switch to including that instead. > > (ui/vnc.h includes include/ui/console.h, so this change strictly > reduces the quantity of headers qmp-cmds.c pulls in.) > > Signed-off-by: Peter Maydell Reviewed-by: Philippe Mathieu-Daudé > --- > Spotted while trying to reduce the number of source files that > indirectly include ... > --- > monitor/qmp-cmds.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/monitor/qmp-cmds.c b/monitor/qmp-cmds.c > index 34f7e75b7bf..c95e5001d72 100644 > --- a/monitor/qmp-cmds.c > +++ b/monitor/qmp-cmds.c > @@ -23,7 +23,7 @@ > #include "qemu/uuid.h" > #include "chardev/char.h" > #include "ui/qemu-spice.h" > -#include "ui/vnc.h" > +#include "ui/console.h" > #include "sysemu/kvm.h" > #include "sysemu/runstate.h" > #include "sysemu/runstate-action.h" >
