Re: Restrictions of libnet (was: Re: VW ELF loader)

On Wed, Feb 05, 2020 at 07:24:04AM +0100, Thomas Huth wrote: > On 05/02/2020 06.30, David Gibson wrote: > > On Tue, Feb 04, 2020 at 10:20:14AM +0100, Thomas Huth wrote: > >> On 04/02/2020 09.54, Cornelia Huck wrote: > >>> On Tue, 4 Feb 2020 07:16:46 +0100 > >>> Thomas Huth wrote: > >>> > On 0

Re: VW ELF loader

On Thu, Feb 06, 2020 at 09:27:01AM +0100, Paolo Bonzini wrote: > On 05/02/20 07:06, David Gibson wrote: > > On Tue, Feb 04, 2020 at 12:26:32AM +0100, Paolo Bonzini wrote: > >> Il mar 4 feb 2020, 00:20 Alexey Kardashevskiy ha scritto: > >>> Speaking seriously, what would I put into the guest? > >>

Re: VW ELF loader

On Fri, Feb 07, 2020 at 12:45:20AM +0100, Paolo Bonzini wrote: > On 07/02/20 00:17, Alexey Kardashevskiy wrote: > > This is a lot and what is exactly the benefit? My alternative does not > > need drivers at all. > > Anything you put in the host is potential attack surface. Ok, it is attack surfac

[PATCH v3 1/5] target/riscv: add vector unit stride load and store instructions

Vector unit-stride operations access elements stored contiguously in memory starting from the base effective address. The Zvlsseg expands some vector load/store segment instructions, which move multiple contiguous fields in memory to and from consecutively numbered vector register Signed-off-by:

[PATCH v3 2/5] target/riscv: add vector stride load and store instructions

Vector strided operations access the first memory element at the base address, and then access subsequent elements at address increments given by the byte offset contained in the x register specified by rs2. Signed-off-by: LIU Zhiwei --- target/riscv/helper.h | 35 + targe

[PATCH v3 4/5] target/riscv: add fault-only-first unit stride load

The unit-stride fault-only-fault load instructions are used to vectorize loops with data-dependent exit conditions(while loops). These instructions execute as a regular load except that they will only take a trap on element 0. Signed-off-by: LIU Zhiwei --- target/riscv/helper.h

[PATCH v3 5/5] target/riscv: add vector amo operations

Vector AMOs operate as if aq and rl bits were zero on each element with regard to ordering relative to other instructions in the same hart. Vector AMOs provide no ordering guarantee between element operations in the same vector AMO instruction Signed-off-by: LIU Zhiwei --- target/riscv/helper.h

[PATCH v3 0/5] target/riscv: support vector extension part 2

This is the second part of v3 patchset. This changelog of v3 is only coverd the part2. Features: * support specification riscv-v-spec-0.7.1. * support basic vector extension. * support Zvlsseg. * support Zvamo. * not support Zvediv as it is changing. * fixed SLEN 128bit. * element wi

[PATCH v3 3/5] target/riscv: add vector index load and store instructions

Vector indexed operations add the contents of each element of the vector offset operand specified by vs2 to the base effective address to give the effective address of each element. Signed-off-by: LIU Zhiwei --- target/riscv/helper.h | 35 target/riscv/insn32.decode

Re: [PATCH rc4 06/29] target/avr: Add defintions of AVR core types

Hi all. When I decided to implement AVR 8 bit CPU support for QEMU I found this document which listed all AVR instructions. After that I learned that there are several CPU flavours, I looked into this GCC f

[Bug 1759522] Re: windows qemu-img create vpc/vhdx error

I confirm this is still exists using qemu-4.2.0. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1759522 Title: windows qemu-img create vpc/vhdx error Status in QEMU: New Bug description: On wi

Re: [PATCH] migration: Optimization about wait-unplug migration state

On 2020/2/4 17:14, Juan Quintela wrote: > Keqian Zhu wrote: >> qemu_savevm_nr_failover_devices() is originally designed to >> get the number of failover devices, but it actually returns >> the number of "unplug-pending" failover devices now. Moreover, >> what drives migration state to wait-unpl

Re: [PATCH] migration: Optimization about wait-unplug migration state

On 2020/2/5 22:40, Jens Freimann wrote: > On Tue, Feb 04, 2020 at 01:08:41PM +0800, Keqian Zhu wrote: >> qemu_savevm_nr_failover_devices() is originally designed to >> get the number of failover devices, but it actually returns >> the number of "unplug-pending" failover devices now. Moreover, >>

[PATCH v6 4/4] spapr: Add Hcalls to support PAPR NVDIMM device

This patch implements few of the necessary hcalls for the nvdimm support. PAPR semantics is such that each NVDIMM device is comprising of multiple SCM(Storage Class Memory) blocks. The guest requests the hypervisor to bind each of the SCM blocks of the NVDIMM device using hcalls. There can be SCM

[PATCH v6 2/4] nvdimm: add uuid property to nvdimm

For ppc64, PAPR requires the nvdimm device to have UUID property set in the device tree. Add an option to get it from the user. Signed-off-by: Shivaprasad G Bhat Reviewed-by: David Gibson Reviewed-by: Igor Mammedov --- hw/mem/nvdimm.c | 40 in

[PATCH v6 3/4] spapr: Add NVDIMM device support

Add support for NVDIMM devices for sPAPR. Piggyback on existing nvdimm device interface in QEMU to support virtual NVDIMM devices for Power. Create the required DT entries for the device (some entries have dummy values right now). The patch creates the required DT node and sends a hotplug interrup

[PATCH v6 1/4] mem: move nvdimm_device_list to utilities

nvdimm_device_list is required for parsing the list for devices in subsequent patches. Move it to common utility area. Signed-off-by: Shivaprasad G Bhat Reviewed-by: Igor Mammedov Reviewed-by: David Gibson --- hw/acpi/nvdimm.c| 28 +--- include/qemu/nvdimm

[PATCH v6 0/4] ppc: spapr: virtual NVDIMM support

The patchset attempts to implement the virtual NVDIMM for pseries. PAPR semantics is such that each NVDIMM device is comprising of multiple SCM(Storage Class Memory) blocks. The hypervisor is expected to prepare the FDT for the NVDIMM device and send guest a hotplug interrupt with new type RTAS_LO

Re: [PATCH v5 3/4] spapr: Add NVDIMM device support

On 02/04/2020 09:29 AM, David Gibson wrote: On Thu, Jan 30, 2020 at 05:48:15AM -0600, Shivaprasad G Bhat wrote: Add support for NVDIMM devices for sPAPR. Piggyback on existing nvdimm device interface in QEMU to support virtual NVDIMM devices for Power. Create the required DT entries for the de

RE: [PATCH] Add support for a helper with 7 arguments

> -Original Message- > From: Taylor Simpson > Sent: Sunday, February 9, 2020 2:51 PM > To: Richard Henderson ; Richard Henderson > ; qemu-devel@nongnu.org > Cc: Paolo Bonzini > Subject: RE: [PATCH] Add support for a helper with 7 arguments > > > However, you should prefer to use tcg_gen_ad

Re: [PATCH 00/29] Convert QAPI doc comments to generate rST instead of texinfo

On Thursday, February 6, 2020, Peter Maydell wrote: > > > This series switches all our QAPI doc > > > comments over from > > texinfo format to rST. > > Regardeless of the outcome of the discussions over this series, I just want to say that I support it as a potential user of the document (there i

Re: VW ELF loader

On 07/02/2020 10:46, Paolo Bonzini wrote: > On 07/02/20 00:23, Alexey Kardashevskiy wrote: >>> Right, not unlike what you get with vof=on. :) I'm not against at all >>> that idea. I just don't understand what you refer to below as (2). >>> Does petitboot not have the problem because it kexecs

Re: [PATCH v3 0/7] Some cleanup in arm/virt/acpi

Hi Peter, Do you have any other comments? If not, could you help to merge into your tree? Thanks, Heyi On 2020/2/4 9:43, Heyi Guo wrote: Remove conflict _ADR objects, and fix and refine PCI device definition in ACPI/DSDT. History: v3 -> v2: - update commit message for patch 4/7. - remove

Re: [PATCH v3 02/13] hw/arm/raspi: Correct the board descriptions

On 2/9/20 11:51 PM, Niek Linnenbank wrote: > Hi Philippe, > > > On Sat, Feb 8, 2020 at 5:57 PM Philippe Mathieu-Daudé > wrote: > > We hardcode the board revision as 0xa21041 for the raspi2, and > 0xa02082 for the raspi3: > >   166 static void raspi_init(Mach

Re: [PATCH v3 01/13] hw/arm/raspi: Use BCM2708 machine type with pre Device Tree kernels

On Sat, Feb 8, 2020 at 5:57 PM Philippe Mathieu-Daudé wrote: > When booting without device tree, the Linux kernels uses the $R1 > register to determine the machine type. The list of values is > registered at [1]. > > There are two entries for the Raspberry Pi: > > - https://www.arm.linux.org.uk/d

Re: [PATCH v3 02/13] hw/arm/raspi: Correct the board descriptions

Hi Philippe, On Sat, Feb 8, 2020 at 5:57 PM Philippe Mathieu-Daudé wrote: > We hardcode the board revision as 0xa21041 for the raspi2, and > 0xa02082 for the raspi3: > > 166 static void raspi_init(MachineState *machine, int version) > 167 { > ... > 194 int board_rev = version == 3 ?

Re: [PATCH v14 08/11] virtio-iommu-pci: Introduce the x-dt-binding option

On Fri, Feb 07, 2020 at 06:04:05PM -0500, Peter Xu wrote: > On Fri, Feb 07, 2020 at 05:24:54AM -0500, Michael S. Tsirkin wrote: > > On Fri, Feb 07, 2020 at 11:05:40AM +0100, Jean-Philippe Brucker wrote: > > > Hi Eric, > > > > > > On Fri, Feb 07, 2020 at 10:32:00AM +0100, Eric Auger wrote: > > > >

RE: [PATCH] Add support for a helper with 7 arguments

> -Original Message- > From: Richard Henderson > Sent: Sunday, February 9, 2020 12:18 PM > To: Taylor Simpson ; Richard Henderson > ; qemu-devel@nongnu.org > Cc: Paolo Bonzini > Subject: Re: [PATCH] Add support for a helper with 7 arguments > We can optimize them. > > However, you shoul

Re: [PATCH 01/17] qcow2: Comment typo fixes

On Fri 31 Jan 2020 06:44:20 PM CET, Eric Blake wrote: > Various trivial typos noticed while working on this file. > > Signed-off-by: Eric Blake Reviewed-by: Alberto Garcia Berto

Re: [PATCH 03/17] qcow2: Avoid feature name extension on small cluster size

On Fri 31 Jan 2020 06:44:22 PM CET, Eric Blake wrote: > As the feature name table can be quite large (over 9k if all 64 bits > of all three feature fields have names; a mere 8 features leaves only > 8 bytes for a backing file name in a 512-byte cluster), it is unwise > to emit this optional header

Re: [PATCH v1 1/5] docs/devel: document query handle lifetimes

On 2/7/20 3:01 PM, Alex Bennée wrote: > I forgot to document the lifetime of handles in the developer > documentation. Do so now. > > Signed-off-by: Alex Bennée > --- > docs/devel/tcg-plugins.rst | 13 +++-- > 1 file changed, 11 insertions(+), 2 deletions(-) Reviewed-by: Richard Henders

Re: [PATCH] Add support for a helper with 7 arguments

On 2/8/20 5:08 AM, Taylor Simpson wrote: >> { >> r6 = memb(r1) >> r7 = memb(r2) >> } >> >> qemu_ld t0, r1, MO_UB, mmu_idx >> qemu_ld t1, r2, MO_UB, mmu_idx >> mov r6, t0 >> mov r7, t1 >> > > Here is the TCG we generate currently. > movi_i32 tmp0,$0x0 > add_i32 loc2,r1,tmp0 >

[PATCH] block/vvfat: Do not unref qcow on closing backing bdrv

Before this commit, BDRVVVFATState.qcow is unrefed in write_target_close on closing backing bdrv of vvfat. However, qcow bdrv is opend as a child of vvfat in enable_write_target() so it will be also unrefed on closing vvfat itself. This causes use-after-free of qcow on freeing vvfat which has backi

Re: [PATCH v4 53/80] mips/mips_jazz: use memdev for RAM

On 1/31/20 4:09 PM, Igor Mammedov wrote: > memory_region_allocate_system_memory() API is going away, so > replace it with memdev allocated MemoryRegion. The later is > initialized by generic code, so board only needs to opt in > to memdev scheme by providing > MachineClass::default_ram_id > and u

Question: SiFive U SPI and SD

Hello! I am trying to make an SD card working on the sifive_u (hw/riscv/sifive_u.c) SoC machine. As far as I understand there is no way to connect an SD card to the SoC with cmdline for now. So, I started to dig in to the QEMU internals and especially sifive_u SoC implementation to try to understa

Re: [PATCH 1/2] spapr: Disable legacy virtio devices for pseries-5.0 and later

On Fri, Feb 07, 2020 at 01:54:26AM -0500, Michael S. Tsirkin wrote: > On Fri, Feb 07, 2020 at 03:30:54PM +1100, David Gibson wrote: > > PAPR specifies a kind of odd, paravirtualized PCI bus, which looks to > > the guess mostly like classic PCI, even if some of the individual > > devices on the bus

Re: Emulating Solaris 10 on SPARC64 sun4u

On 05/02/2020 06:31, jasper.low...@bt.com wrote: > I'm currently working towards emulating Solaris 10 on sun4u. > >   > > The Solaris 10 ISO image I am attempting to boot is the one from the Oracle > > download page at > https://www.oracle.com/solaris/solaris10/downloads/solaris10-get-jsp-downl