Re: [PATCH v4 00/14] Fixes for DP8393X SONIC device emulation

Le 19/02/2020 à 02:57, Aleksandar Markovic a écrit : > 2:54 AM Sre, 19.02.2020. Aleksandar Markovic > mailto:aleksandar.m.m...@gmail.com>> је > написао/ла: >> >> 2:06 AM Sre, 19.02.2020. Finn Thain > је написао/ла: >> > >> > On Tue, 18 Feb 2020, Aleksandar Markov

Re: [PATCH v2] scsi-disk: define props in scsi_block_disk to avoid memleaks

On 1/22/2020 1:05 AM, Paolo Bonzini wrote: > On 14/01/20 10:16, pannengy...@huawei.com wrote: >> From: Pan Nengyuan >> >> scsi_block_realize() use scsi_realize() to init some props, but >> these props is not defined in scsi_block_disk_properties, so they will >> not be freed. >> >> This patch d

Re: [PULL SUBSYSTEM qemu-pseries] pseries: Update SLOF firmware image

On 2/19/20 7:44 AM, Alexey Kardashevskiy wrote: > > > On 19/02/2020 12:20, Alexey Kardashevskiy wrote: >> >> >> On 18/02/2020 23:59, Cédric Le Goater wrote: >>> On 2/18/20 1:48 PM, Cédric Le Goater wrote: On 2/18/20 10:40 AM, Cédric Le Goater wrote: > On 2/18/20 10:10 AM, Alexey Kardashe

Re: [PATCH v2 12/22] qemu-iotests/199: fix style

On 17/02/2020 18:02, Vladimir Sementsov-Ogievskiy wrote: Mostly, satisfy pep8 complains. Signed-off-by: Vladimir Sementsov-Ogievskiy --- tests/qemu-iotests/199 | 13 +++-- 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/tests/qemu-iotests/199 b/tests/qemu-iotests/199 in

Re: [PATCH 1/5] aio-posix: fix use after leaving scope in aio_poll()

On Fri, Feb 14, 2020 at 05:17:08PM +, Stefan Hajnoczi wrote: > epoll_handler is a stack variable and must not be accessed after it goes > out of scope: > > if (aio_epoll_check_poll(ctx, pollfds, npfd, timeout)) { > AioHandler epoll_handler; > ... > add_pollf

Re: [PULL SUBSYSTEM qemu-pseries] pseries: Update SLOF firmware image

On 19/02/2020 12:20, Alexey Kardashevskiy wrote: > > > On 18/02/2020 23:59, Cédric Le Goater wrote: >> On 2/18/20 1:48 PM, Cédric Le Goater wrote: >>> On 2/18/20 10:40 AM, Cédric Le Goater wrote: On 2/18/20 10:10 AM, Alexey Kardashevskiy wrote: > > > On 18/02/2020 20:05, Alexe

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

I remembered asking a QEMU developer about this. He suggested me to send an email to the developer mailing list, or send messages to IRC channel. I don't have time to do this right now, but if someone else finds this bug report and wants to get the help, please email them instead. -- You receive

Re: [PATCH] migration/throttle: Make throttle slower at tail stage

On 2020/2/14 20:28, Dr. David Alan Gilbert wrote: > * Keqian Zhu (zhukeqi...@huawei.com) wrote: >> At the tail stage of throttle, VM is very sensitive to >> CPU percentage. We just throttle 30% of remaining CPU >> when throttle is more than 80 percentage. > > This is a bit unusual; all of the

Re: [PATCH] migration/throttle: Make throttle slower at tail stage

On 2020/2/14 19:46, Eric Blake wrote: > On 2/13/20 9:27 PM, Keqian Zhu wrote: >> At the tail stage of throttle, VM is very sensitive to >> CPU percentage. We just throttle 30% of remaining CPU >> when throttle is more than 80 percentage. >> >> This doesn't conflict with cpu_throttle_increment. >

Re: [PATCH] migration/throttle: Make throttle slower at tail stage

Hi, Juan On 2020/2/14 20:37, Juan Quintela wrote: > Keqian Zhu wrote: >> At the tail stage of throttle, VM is very sensitive to >> CPU percentage. We just throttle 30% of remaining CPU >> when throttle is more than 80 percentage. > > Why? > My original idea is that if we throttle a fixed percen

Re: QEMU Sockets Networking Backend Multicast Networking Fix

On 2020/2/17 下午6:05, Faisal Al-Humaimidi wrote: Hello Jason, But, the local address is not meant to be added to the group, rather we listen to it, hence we bind to the local address. The multicast group is a higher layer that would be requested to join to by the listening host. Here's a sim

Re: [PATCH v12 Kernel 4/7] vfio iommu: Implementation of ioctl to for dirty pages tracking.

On Wed, 19 Feb 2020 09:51:32 +0530 Kirti Wankhede wrote: > On 2/19/2020 3:11 AM, Alex Williamson wrote: > > On Tue, 18 Feb 2020 11:28:53 +0530 > > Kirti Wankhede wrote: > > > >> > >> > >>> As I understand the above algorithm, we find a vfio_dma > >>> overlapping the request and

Re: [PATCH v12 Kernel 4/7] vfio iommu: Implementation of ioctl to for dirty pages tracking.

On 2/19/2020 3:11 AM, Alex Williamson wrote: On Tue, 18 Feb 2020 11:28:53 +0530 Kirti Wankhede wrote: As I understand the above algorithm, we find a vfio_dma overlapping the request and populate the bitmap for that range. Then we go back and put_user() for each byte that we touched.

Re: [PATCH] pcie_root_port: Add disable_hotplug option

On Tue, Feb 18, 2020 at 10:02:19PM -0500, Laine Stump wrote: > Also, is there a rhyme/reason for some options having true/false, and some > being off/on? disable-acs seems to be true/false, but disable-modern is > on/off. Doesn't make any difference to me in the end, but just thought I'd > bring it

RE: Emulating Solaris 10 on SPARC64 sun4u

Excuse the delay. I believe the reason why I am unable to locate the error string "Interrupt not seen after set_features" in the OpenSolaris source code is because it belongs to a proprietary driver that was not distributed with OpenSolaris. Rather than rely on source code I've had to debug this

Re: [PATCH v4 00/14] Fixes for DP8393X SONIC device emulation

On 2020/2/19 上午2:30, Aleksandar Markovic wrote: On Tuesday, February 4, 2020, Jason Wang > wrote: On 2020/1/29 下午5:27, Finn Thain wrote: Hi All, There are bugs in the emulated dp8393x device that can stop packet reception in a Linux

Re: [PATCH] pcie_root_port: Add disable_hotplug option

On 2/18/20 1:40 PM, Julia Suvorova wrote: On Tue, Feb 18, 2020 at 6:18 PM Laine Stump wrote: On 2/18/20 11:17 AM, Julia Suvorova wrote: Make hot-plug/hot-unplug on PCIe Root Ports optional to allow libvirt to manage it and restrict unplug for the entire machine. This is going to prevent user-

Re: [PATCH v2] Avoid address_space_rw() with a constant is_write argument

On Tue, Feb 18, 2020 at 11:24:57AM +, Peter Maydell wrote: > The address_space_rw() function allows either reads or writes > depending on the is_write argument passed to it; this is useful > when the direction of the access is determined programmatically > (as for instance when handling the KVM

Re: [RFC PATCH v2] target/ppc: Enable hardfloat for PPC

> On Feb 18, 2020, at 12:10 PM, BALATON Zoltan wrote: > > While other targets take advantage of using host FPU to do floating > point computations, this was disabled for PPC target because always > clearing exception flags before every FP op made it slightly slower > than emulating everyting wi

[PATCH v4 11/12] target/ppc: Streamline construction of VRMA SLB entry

When in VRMA mode (i.e. a guest thinks it has the MMU off, but the hypervisor is still applying translation) we use a special SLB entry, rather than looking up an SLBE by address as we do when guest translation is on. We build that special entry in ppc_hash64_update_vrma() along with some logic fo

[PATCH v4 10/12] target/ppc: Only calculate RMLS derived RMA limit on demand

When the LPCR is written, we update the env->rmls field with the RMA limit it implies. Simplify things by just calculating the value directly from the LPCR value when we need it. It's possible this is a little slower, but it's unlikely to be significant, since this is only for real mode accesses

[PATCH v4 12/12] target/ppc: Don't store VRMA SLBE persistently

Currently, we construct the SLBE used for VRMA translations when the LPCR is written (which controls some bits in the SLBE), then use it later for translations. This is a bit complex and confusing - simplify it by simply constructing the SLBE directly from the LPCR when we need it. Signed-off-by:

[PATCH v4 06/12] target/ppc: Remove RMOR register from POWER9 & POWER10

Currently we create the Real Mode Offset Register (RMOR) on all Book3S cpus from POWER7 onwards. However the translation mode which the RMOR controls is no longer supported in POWER9, and so the register has been removed from the architecture. Remove it from our model on POWER9 and POWER10. Sign

[PATCH v4 07/12] target/ppc: Use class fields to simplify LPCR masking

When we store the Logical Partitioning Control Register (LPCR) we have a big switch statement to work out which are valid bits for the cpu model we're emulating. As well as being ugly, this isn't really conceptually correct, since it is based on the mmu_model variable, whereas the LPCR isn't (only

[PATCH v4 02/12] ppc: Remove stub of PPC970 HID4 implementation

The PowerPC 970 CPU was a cut-down POWER4, which had hypervisor capability. However, it can be (and often was) strapped into "Apple mode", where the hypervisor capabilities were disabled (essentially putting it always in hypervisor mode). That's actually the only mode of the 970 we support in qemu

[PATCH v4 04/12] target/ppc: Introduce ppc_hash64_use_vrma() helper

When running guests under a hypervisor, the hypervisor obviously needs to be protected from guest accesses even if those are in what the guest considers real mode (translation off). The POWER hardware provides two ways of doing that: The old way has guest real mode accesses simply offset and bound

[PATCH v4 08/12] target/ppc: Streamline calculation of RMA limit from LPCR[RMLS]

Currently we use a big switch statement in ppc_hash64_update_rmls() to work out what the right RMA limit is based on the LPCR[RMLS] field. There's no formula for this - it's just an arbitrary mapping defined by the existing CPU implementations - but we can make it a bit more readable by using a lo

[PATCH v4 05/12] spapr, ppc: Remove VPM0/RMLS hacks for POWER9

For the "pseries" machine, we use "virtual hypervisor" mode where we only model the CPU in non-hypervisor privileged mode. This means that we need guest physical addresses within the modelled cpu to be treated as absolute physical addresses. We used to do that by clearing LPCR[VPM0] and setting L

[PATCH v4 01/12] ppc: Remove stub support for 32-bit hypervisor mode

a4f30719a8cd, way back in 2007 noted that "PowerPC hypervisor mode is not fundamentally available only for PowerPC 64" and added a 32-bit version of the MSR[HV] bit. But nothing was ever really done with that; there is no meaningful support for 32-bit hypervisor mode 13 years later. Let's stop pr

[PATCH v4 03/12] target/ppc: Correct handling of real mode accesses with vhyp on hash MMU

On ppc we have the concept of virtual hypervisor ("vhyp") mode, where we only model the non-hypervisor-privileged parts of the cpu. Essentially we model the hypervisor's behaviour from the point of view of a guest OS, but we don't model the hypervisor's execution. In particular, in this mode, qem

[PATCH v4 09/12] target/ppc: Correct RMLS table

The table of RMA limits based on the LPCR[RMLS] field is slightly wrong. We're missing the RMLS == 0 => 256 GiB RMA option, which is available on POWER8, so add that. The comment that goes with the table is much more wrong. We *don't* filter invalid RMLS values when writing the LPCR, and there's

Re: [PATCH v3 00/12] target/ppc: Correct some errors with real mode handling

On Wed, Feb 19, 2020 at 11:54:02AM +1100, David Gibson wrote: > POWER "book S" (server class) cpus have a concept of "real mode" where > MMU translation is disabled... sort of. In fact this can mean a bunch > of slightly different things when hypervisor mode and other > considerations are present.

[PATCH v4 00/12] target/ppc: Correct some errors with real mode handling

POWER "book S" (server class) cpus have a concept of "real mode" where MMU translation is disabled... sort of. In fact this can mean a bunch of slightly different things when hypervisor mode and other considerations are present. We had some errors in edge cases here, so clean some things up and c

Re: [PATCH v4 00/14] Fixes for DP8393X SONIC device emulation

2:54 AM Sre, 19.02.2020. Aleksandar Markovic је написао/ла: > > 2:06 AM Sre, 19.02.2020. Finn Thain је написао/ла: > > > > On Tue, 18 Feb 2020, Aleksandar Markovic wrote: > > > > > On Wednesday, January 29, 2020, Finn Thain > > > wrote: > > > > > > > Hi All, > > > > > > > > There are bugs in the

Re: [PATCH v4 00/14] Fixes for DP8393X SONIC device emulation

2:06 AM Sre, 19.02.2020. Finn Thain је написао/ла: > > On Tue, 18 Feb 2020, Aleksandar Markovic wrote: > > > On Wednesday, January 29, 2020, Finn Thain > > wrote: > > > > > Hi All, > > > > > > There are bugs in the emulated dp8393x device that can stop packet > > > reception in a Linux/m68k guest

Re: [PATCH v3 00/12] target/ppc: Correct some errors with real mode handling

Patchew URL: https://patchew.org/QEMU/20200219005414.15635-1-da...@gibson.dropbear.id.au/ Hi, This series seems to have some coding style problems. See output below for more information: Subject: [PATCH v3 00/12] target/ppc: Correct some errors with real mode handling Message-id: 20200219005

Re: [PULL SUBSYSTEM qemu-pseries] pseries: Update SLOF firmware image

On 18/02/2020 23:59, Cédric Le Goater wrote: > On 2/18/20 1:48 PM, Cédric Le Goater wrote: >> On 2/18/20 10:40 AM, Cédric Le Goater wrote: >>> On 2/18/20 10:10 AM, Alexey Kardashevskiy wrote: On 18/02/2020 20:05, Alexey Kardashevskiy wrote: > > > On 18/02/2020 18:12, C

Re: [PATCH] xilinx_spips: Correct the number of dummy cycles for the FAST_READ_4 cmd

On Tue, Feb 18, 2020 at 12:33:50PM +0100, Francisco Iglesias wrote: > From: Francisco Iglesias > > Correct the number of dummy cycles required by the FAST_READ_4 command (to > be eight, one dummy byte). > > Fixes: ef06ca3946 ("xilinx_spips: Add support for RX discard and RX drain") > Suggested-b

Re: [PATCH v4 2/4] target/riscv: configure and turn on vector extension from command line

On Tue, Feb 18, 2020 at 4:46 PM LIU Zhiwei wrote: > > Hi, Alistair > > On 2020/2/19 6:34, Alistair Francis wrote: > > On Mon, Feb 10, 2020 at 12:12 AM LIU Zhiwei wrote: > >> Vector extension is default on only for "any" cpu. It can be turned > >> on by command line "-cpu rv64,v=true,vlen=128,elen

Re: [PATCH v1] block/nvme: introduce PMR support from NVMe 1.4 spec

Patchew URL: https://patchew.org/QEMU/20200218224811.30050-1-andrzej.jakow...@linux.intel.com/ Hi, This series failed the docker-mingw@fedora build test. Please find the testing commands and their output below. If you have Docker installed, you can probably reproduce it locally. === TEST SCR

Re: [PATCH v4 00/14] Fixes for DP8393X SONIC device emulation

On Tue, 18 Feb 2020, Aleksandar Markovic wrote: > On Wednesday, January 29, 2020, Finn Thain > wrote: > > > Hi All, > > > > There are bugs in the emulated dp8393x device that can stop packet > > reception in a Linux/m68k guest (q800 machine). > > > > With a Linux/m68k v5.5 guest (q800), it's pos

[PATCH v3 08/12] target/ppc: Streamline calculation of RMA limit from LPCR[RMLS]

Currently we use a big switch statement in ppc_hash64_update_rmls() to work out what the right RMA limit is based on the LPCR[RMLS] field. There's no formula for this - it's just an arbitrary mapping defined by the existing CPU implementations - but we can make it a bit more readable by using a lo

[PATCH v3 07/12] target/ppc: Use class fields to simplify LPCR masking

When we store the Logical Partitioning Control Register (LPCR) we have a big switch statement to work out which are valid bits for the cpu model we're emulating. As well as being ugly, this isn't really conceptually correct, since it is based on the mmu_model variable, whereas the LPCR isn't (only

[PATCH v3 09/12] target/ppc: Correct RMLS table

The table of RMA limits based on the LPCR[RMLS] field is slightly wrong. We're missing the RMLS == 0 => 256 GiB RMA option, which is available on POWER8, so add that. The comment that goes with the table is much more wrong. We *don't* filter invalid RMLS values when writing the LPCR, and there's

[PATCH v3 11/12] target/ppc: Streamline construction of VRMA SLB entry

When in VRMA mode (i.e. a guest thinks it has the MMU off, but the hypervisor is still applying translation) we use a special SLB entry, rather than looking up an SLBE by address as we do when guest translation is on. We build that special entry in ppc_hash64_update_vrma() along with some logic fo

[PATCH v3 06/12] target/ppc: Remove RMOR register from POWER9 & POWER10

Currently we create the Real Mode Offset Register (RMOR) on all Book3S cpus from POWER7 onwards. However the translation mode which the RMOR controls is no longer supported in POWER9, and so the register has been removed from the architecture. Remove it from our model on POWER9 and POWER10. Sign

[PATCH v3 05/12] spapr, ppc: Remove VPM0/RMLS hacks for POWER9

For the "pseries" machine, we use "virtual hypervisor" mode where we only model the CPU in non-hypervisor privileged mode. This means that we need guest physical addresses within the modelled cpu to be treated as absolute physical addresses. We used to do that by clearing LPCR[VPM0] and setting L

[Bug 1863819] [NEW] repeated KVM single step crashes leaks into SMP guest and crashes guest application

Public bug reported: Guest: Windows 7 x64 Host: Ubuntu 18.04.4 (kernel 5.3.0-40-generic) QEMU: master 6c599282f8ab382fe59f03a6cae755b89561a7b3 If I try to use GDB to repeatedly single-step a userspace process while running a KVM guest, the userspace process will eventually crash with a 0x8004

[PATCH v1] block/nvme: introduce PMR support from NVMe 1.4 spec

This patch introduces support for PMR that has been defined as part of NVMe 1.4 spec. User can now specify a pmr_file which will be mmap'ed into qemu address space and subsequently in PCI BAR 2. Guest OS can perform mmio read and writes to the PMR region that will stay persistent accross system reb

[PATCH v3 12/12] target/ppc: Don't store VRMA SLBE persistently

Currently, we construct the SLBE used for VRMA translations when the LPCR is written (which controls some bits in the SLBE), then use it later for translations. This is a bit complex and confusing - simplify it by simply constructing the SLBE directly from the LPCR when we need it. Signed-off-by:

[PATCH v3 10/12] target/ppc: Only calculate RMLS derived RMA limit on demand

When the LPCR is written, we update the env->rmls field with the RMA limit it implies. Simplify things by just calculating the value directly from the LPCR value when we need it. It's possible this is a little slower, but it's unlikely to be significant, since this is only for real mode accesses

[PATCH v3 00/12] target/ppc: Correct some errors with real mode handling

POWER "book S" (server class) cpus have a concept of "real mode" where MMU translation is disabled... sort of. In fact this can mean a bunch of slightly different things when hypervisor mode and other considerations are present. We had some errors in edge cases here, so clean some things up and c

[PATCH v3 04/12] target/ppc: Introduce ppc_hash64_use_vrma() helper

When running guests under a hypervisor, the hypervisor obviously needs to be protected from guest accesses even if those are in what the guest considers real mode (translation off). The POWER hardware provides two ways of doing that: The old way has guest real mode accesses simply offset and bound

[PATCH v3 02/12] ppc: Remove stub of PPC970 HID4 implementation

The PowerPC 970 CPU was a cut-down POWER4, which had hypervisor capability. However, it can be (and often was) strapped into "Apple mode", where the hypervisor capabilities were disabled (essentially putting it always in hypervisor mode). That's actually the only mode of the 970 we support in qemu

[PATCH v3 01/12] ppc: Remove stub support for 32-bit hypervisor mode

a4f30719a8cd, way back in 2007 noted that "PowerPC hypervisor mode is not fundamentally available only for PowerPC 64" and added a 32-bit version of the MSR[HV] bit. But nothing was ever really done with that; there is no meaningful support for 32-bit hypervisor mode 13 years later. Let's stop pr

[PATCH v3 03/12] target/ppc: Correct handling of real mode accesses with vhyp on hash MMU

On ppc we have the concept of virtual hypervisor ("vhyp") mode, where we only model the non-hypervisor-privileged parts of the cpu. Essentially we model the hypervisor's behaviour from the point of view of a guest OS, but we don't model the hypervisor's execution. In particular, in this mode, qem

Re: [PATCH v4 2/4] target/riscv: configure and turn on vector extension from command line

Hi, Alistair On 2020/2/19 6:34, Alistair Francis wrote: On Mon, Feb 10, 2020 at 12:12 AM LIU Zhiwei wrote: Vector extension is default on only for "any" cpu. It can be turned on by command line "-cpu rv64,v=true,vlen=128,elen=64,vext_spec=v0.7.1". vlen is the vector register length, default v

Re: [PULL SUBSYSTEM qemu-pseries] pseries: Update SLOF firmware image

On Tue, Feb 18, 2020 at 06:48:43AM +0100, Philippe Mathieu-Daudé wrote: > On 2/17/20 11:46 PM, David Gibson wrote: > > On Mon, Feb 17, 2020 at 11:24:11AM +0100, Philippe Mathieu-Daudé wrote: > > > On 2/17/20 10:26 AM, Philippe Mathieu-Daudé wrote: > > > > Hi Alexey, > > > > > > > > On 2/17/20 3:12

Re: [PATCH] spapr: Rework hash<->radix transitions at CAS

On Fri, Feb 14, 2020 at 07:19:00PM +0100, Greg Kurz wrote: > On Fri, 14 Feb 2020 09:28:35 +1100 > David Gibson wrote: > > > On Thu, Feb 13, 2020 at 04:38:38PM +0100, Greg Kurz wrote: > > > Until the CAS negotiation is over, an HPT can be allocated on three > > > different paths: > > > > > > 1) d

Re: [PULL SUBSYSTEM qemu-pseries] pseries: Update SLOF firmware image

On Tue, Feb 18, 2020 at 01:59:44PM +0100, Cédric Le Goater wrote: > On 2/18/20 1:48 PM, Cédric Le Goater wrote: > > On 2/18/20 10:40 AM, Cédric Le Goater wrote: > >> On 2/18/20 10:10 AM, Alexey Kardashevskiy wrote: > >>> > >>> > >>> On 18/02/2020 20:05, Alexey Kardashevskiy wrote: > > > >

Re: [PATCH v4 1/3] target/arm: Support SError injection

Hi Marc, On 2/19/20 3:28 AM, Marc Zyngier wrote: On 2020-02-18 02:04, Gavin Shan wrote: This supports SError injection, which will be used by "virt" board to simulating the behavior of NMI injection in next patch. As Peter Maydell suggested, this adds a new interrupt (ARM_CPU_SERROR), which is

Re: [PATCH v2] Avoid address_space_rw() with a constant is_write argument

On Tue, Feb 18, 2020 at 11:24:57AM +, Peter Maydell wrote: > The address_space_rw() function allows either reads or writes > depending on the is_write argument passed to it; this is useful > when the direction of the access is determined programmatically > (as for instance when handling the KVM

Re: [PATCH 2/3] hw/ppc/virtex_ml507:fix leak of fdevice tree blob

On Tue, Feb 18, 2020 at 05:11:53PM +0800, kuhn.chen...@huawei.com wrote: > From: Chen Qun > > The device tree blob returned by load_device_tree is malloced. > We should free it after cpu_physical_memory_write(). > > Reported-by: Euler Robot > Signed-off-by: Chen Qun I've applied this patch to

Re: [PATCH 00/22] linux-user: generate syscall_nr.sh

On Mon, Feb 17, 2020 at 2:36 PM Laurent Vivier wrote: > > This series copies the files syscall.tbl from linux v5.5 and generates > the file syscall_nr.h from them. > > This is done for all the QEMU targets that have a syscall.tbl > in the linux source tree: mips, mips64, i386, x86_64, sparc, s390x

Re: [PATCH v4 2/4] target/riscv: configure and turn on vector extension from command line

On Mon, Feb 10, 2020 at 12:12 AM LIU Zhiwei wrote: > > Vector extension is default on only for "any" cpu. It can be turned > on by command line "-cpu rv64,v=true,vlen=128,elen=64,vext_spec=v0.7.1". > > vlen is the vector register length, default value is 128 bit. > elen is the max operator size in

Re: [PATCH v2] Avoid address_space_rw() with a constant is_write argument

On Tue, Feb 18, 2020 at 3:25 AM Peter Maydell wrote: > > The address_space_rw() function allows either reads or writes > depending on the is_write argument passed to it; this is useful > when the direction of the access is determined programmatically > (as for instance when handling the KVM_EXIT_M

Re: [PATCH v3 0/3] arm: allwinner: Wire up USB ports

Hi Guenter, Philippe, On Tue, Feb 18, 2020 at 7:39 AM Philippe Mathieu-Daudé wrote: > Cc'ing Niek. > > On 2/17/20 9:48 PM, Guenter Roeck wrote: > > Instantiate EHCI and OHCI controllers on Allwinner A10. > > > > The first patch in the series moves the declaration of EHCISysBusState > > from hcd-

Re: [PATCH v2 fixed 07/16] exec: Drop "shared" parameter from ram_block_add()

On Wed, Feb 12, 2020 at 02:42:45PM +0100, David Hildenbrand wrote: > Properly store it in the flags of the ram block instead (and the flag > even already exists and is used). > > E.g., qemu_ram_is_shared() now properly succeeds on all ram blocks that are > actually shared. > > Reviewed-by: Igor K

Re: [PATCH v2 fixed 06/16] exec: Reuse qemu_ram_apply_settings() in qemu_ram_remap()

On Wed, Feb 12, 2020 at 02:42:44PM +0100, David Hildenbrand wrote: > I don't see why we shouldn't apply all settings to make it look like the > surrounding RAM (and enable proper VMA merging). > > Note: memory backend settings might have overridden these settings. We > would need a callback to let

Re: [PATCH v2 fixed 05/16] exec: Factor out setting ram settings (madvise ...) into qemu_ram_apply_settings()

On Wed, Feb 12, 2020 at 02:42:43PM +0100, David Hildenbrand wrote: > Factor all settings out into qemu_ram_apply_settings(). > > For memory_try_enable_merging(), the important bit is that it won't be > called with XEN - which is now still the case as new_block->host will > remain NULL. > > Review

Re: [PATCH v2 fixed 04/16] util: vfio-helpers: Factor out removal from qemu_vfio_undo_mapping()

On Wed, Feb 12, 2020 at 02:42:42PM +0100, David Hildenbrand wrote: > Factor it out and properly use it where applicable. Make > qemu_vfio_undo_mapping() look like qemu_vfio_do_mapping(), passing the > size and iova, not the mapping. > > Cc: Richard Henderson > Cc: Paolo Bonzini > Cc: Eduardo Hab

Re: [PATCH v2 fixed 03/16] util: vfio-helpers: Remove Error parameter from qemu_vfio_undo_mapping()

On Wed, Feb 12, 2020 at 02:42:41PM +0100, David Hildenbrand wrote: > Everybody discards the error. Let's error_report() instead so this error > doesn't get lost. > > Cc: Richard Henderson > Cc: Paolo Bonzini > Cc: Eduardo Habkost > Cc: Marcel Apfelbaum > Cc: Alex Williamson > Cc: Stefan Hajno

Re: [PATCH v2 fixed 02/16] util: vfio-helpers: Fix qemu_vfio_close()

On Wed, Feb 12, 2020 at 02:42:40PM +0100, David Hildenbrand wrote: > qemu_vfio_undo_mapping() will decrement the number of mappings and > reshuffle the array elements to fit into the reduced size. > > Iterating over all elements like this does not work as expected, let's make > sure to remove all

Re: [PATCH v2 fixed 01/16] util: vfio-helpers: Factor out and fix processing of existing ram blocks

On Wed, Feb 12, 2020 at 02:42:39PM +0100, David Hildenbrand wrote: > Factor it out into common code when a new notifier is registered, just > as done with the memory region notifier. This allows us to have the > logic about how to process existing ram blocks at a central place (which > will be exte

Re: [PATCH v4 00/20] Add Allwinner H3 SoC and Orange Pi PC Machine

Hi Peter & Philippe, On Tue, Feb 18, 2020 at 11:05 AM Peter Maydell wrote: > On Tue, 18 Feb 2020 at 06:46, Philippe Mathieu-Daudé > wrote: > > IIRC from the specs, cards are block devices and the only alignment > > required is the size of a block (512KiB for your 4GiB card). > > Isn't there som

Re: [PATCH] memory: batch allocate ioeventfds[] in address_space_update_ioeventfds()

On Tue, Feb 18, 2020 at 06:22:26PM +, Stefan Hajnoczi wrote: > Reallocing the ioeventfds[] array each time an element is added is very > expensive as the number of ioeventfds increases. Batch allocate instead > to amortize the cost of realloc. > > This patch reduces Linux guest boot times fro

Re: [PATCH v12 Kernel 4/7] vfio iommu: Implementation of ioctl to for dirty pages tracking.

On Tue, 18 Feb 2020 11:28:53 +0530 Kirti Wankhede wrote: > > > >As I understand the above algorithm, we find a vfio_dma > > overlapping the request and populate the bitmap for that range. Then > > we go back and put_user() for each byte that we touched. We could > > instea

Re: [Qemu-devel] [PATCH] linux-user: Implement membarrier syscall

Le 13/05/2019 à 11:02, Andreas Schwab a écrit : > Signed-off-by: Andreas Schwab > --- > linux-user/syscall.c | 7 +++ > 1 file changed, 7 insertions(+) > > diff --git a/linux-user/syscall.c b/linux-user/syscall.c > index f5ff6f5dc8..80399f4eb0 100644 > --- a/linux-user/syscall.c > +++ b/linu

Re: [Qemu-devel] [PATCH] linux-user: implement getsockopt SO_RCVTIMEO and SO_SNDTIMEO

Le 13/05/2019 à 11:06, Andreas Schwab a écrit : > Signed-off-by: Andreas Schwab > --- > linux-user/syscall.c | 36 ++-- > 1 file changed, 34 insertions(+), 2 deletions(-) > > diff --git a/linux-user/syscall.c b/linux-user/syscall.c > index d113a65831..ba5775a94e 1

[PATCH] linux-user: fix socket() strace

print_socket_type() doesn't manage flags and the correct type cannot be displayed Signed-off-by: Laurent Vivier --- linux-user/strace.c | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/linux-user/strace.c b/linux-user/strace.c index 4f7130b2ff63..bdfc5177555e 100644 ---

Re: [PATCH v2 4/4] linux-user: Add support for FDGETFDCSTAT ioctl

Le 24/01/2020 à 16:47, Aleksandar Markovic a écrit : > From: Aleksandar Markovic > > FDGETFDCSTAT's third agrument is a pointer to the structure: > > struct floppy_fdc_state { > int spec1; > int spec2; > int dtr; > unsigned char version; > unsigned char dor; > unsigned lo

Re: [PATCH] Avoid cpu_physical_memory_rw() with a constant is_write argument

On Tue, 18 Feb 2020 at 20:07, Philippe Mathieu-Daudé wrote: > I don't understand well cpu_physical_memory*(). Aren't these obsolete? > They confuse me when using multi-core CPUs. They sort of are, but there is no simple mechanical replacement for them -- you need to look at the individual use to

Re: [PATCH v2 3/4] linux-user: Add support for FIFREEZE and FITHAW ioctls

Le 24/01/2020 à 16:47, Aleksandar Markovic a écrit : > From: Aleksandar Markovic > > Both FIFREEZE and FITHAW ioctls accept an integer as their third > argument. > > All ioctls in this group (FI* ioctl) are guarded with "#ifdef", so the > guards are used in this implementation too for consistenc

[Bug 1863685] Re: ARM: HCR.TSW traps are not implemented

Makes sense. Debugging is on me then :) Both patches behave as expected, thanks! -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1863685 Title: ARM: HCR.TSW traps are not implemented Status in QEMU:

Re: [PATCH v2 00/22] Fix error handling during bitmap postcopy

On 2/18/20 2:02 PM, Andrey Shinkevich wrote: qemu-iotests:$ ./check -qcow2 PASSED (except always failed 261 and 272) Have you reported those failures on the threads that introduced those tests? -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization:

Re: [PATCH v2 2/4] linux-user: Add support for FITRIM ioctl

Le 18/02/2020 à 21:53, Laurent Vivier a écrit : > Le 24/01/2020 à 16:47, Aleksandar Markovic a écrit : >> From: Aleksandar Markovic >> >> FITRIM ioctl accepts a pointer to the structure >> >> struct fstrim_range { >> __u64 start; >> __u64 len; >> __u64 minlen; >> }; >> >> as its third

Re: Cross-project NBD extension proposal: NBD_INFO_INIT_STATE

On 2/17/20 9:13 AM, Max Reitz wrote: Hi, It’s my understanding that without some is_zero infrastructure for QEMU, it’s impossible to implement this flag in qemu’s NBD server. You're right that we may need some more infrastructure before being able to decide when to report this bit in all case

Re: [PATCH v2 2/4] linux-user: Add support for FITRIM ioctl

Le 24/01/2020 à 16:47, Aleksandar Markovic a écrit : > From: Aleksandar Markovic > > FITRIM ioctl accepts a pointer to the structure > > struct fstrim_range { > __u64 start; > __u64 len; > __u64 minlen; > }; > > as its third argument. > > All ioctls in this group (FI* ioctl) are gu

RE: [PATCH] WHPX: Assigning maintainer for Windows Hypervisor Platform

Looks good to me! Thanks Sunil. Signed-off-by: Justin Terry (VM) > -Original Message- > From: Sunil Muthuswamy > Sent: Tuesday, February 18, 2020 12:39 PM > To: Eduardo Habkost ; Paolo Bonzini > ; Richard Henderson > Cc: Stefan Weil ; qemu-devel@nongnu.org; Justin Terry > (SF) > Subje

[Bug 1863685] Re: ARM: HCR.TSW traps are not implemented

I can't think of any reason that DACR would have an incorrect register value. It would be treated as any other system register, and there's only one code path involved. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.lau

Re: [PATCH v2 1/4] linux-user: Add support for FS_IOC_FSXATTR ioctls

Le 24/01/2020 à 16:47, Aleksandar Markovic a écrit : > From: Aleksandar Markovic > > Both FS_IOC_FSGETXATTR and FS_IOC_FSSETXATTR accept a pointer to > the structure > > struct fsxattr { > __u32 fsx_xflags; /* xflags field value (get/set) */ > __u32 fsx_extsize;/*

[PATCH] WHPX: Assigning maintainer for Windows Hypervisor Platform

Signed-off-by: Sunil Muthuswamy --- MAINTAINERS | 8 1 file changed, 8 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 1740a4fddc..9b3ba4e1b5 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -404,6 +404,14 @@ S: Supported F: target/i386/kvm.c F: scripts/kvm/vmxcap +WHPX CPUs

Re: [PATCH v8 00/13] linux-user: Add support for real time clock and

Le 15/01/2020 à 20:36, Filip Bozuta a écrit : > This series covers following RTC and sound timer ioctls: > > RTC ioctls(22): > > * RTC_AIE_ON * RTC_ALM_SET * RTC_WKALM_SET > * RTC_AIE_OFF * RTC_ALM_READ* RTC_WKALM_RD > * RTC_UIE_ON * RTC_RD_

[Bug 1863685] Re: ARM: HCR.TSW traps are not implemented

Sorry, I meant the operation is a write (TVM is on). The result of the operation is setting DACR to 0 so the guest stops progressing after that. Anyway, since the issue could also be on my side, I don't want to block you with this. -- You received this bug notification because you are a member o

[Bug 1863685] Re: ARM: HCR.TSW traps are not implemented

Thanks for the quick turn around! I tested both your patches together (it's useful to have both to emulate set/way flushing inside a guest) and I am getting something unexpected. At some point, we are trapping on an access to DACR but ESR_EL2 doesn't seem to make a lot of sense: 0xfe00dc0. I am run

Re: [PATCH v3 0/4] migration: Replace gemu_log with qemu_log

Le 04/02/2020 à 03:54, Josh Kunz a écrit : > Summary of v2->v3 changes: > * Removed assert for CMSG handling, replaced with LOG_UNIMP. Will > switch to assert in follow-up patch. > * Fixed BSD-user build (dangling references to qemu_add_log), and > verified the user-mode build works. >

[PATCH v2] sh4: Fix PCI ISA IO memory subregion

Booting the r2d machine from flash fails because flash is not discovered. Looking at the flattened memory tree, we see the following. FlatView #1 AS "memory", root: system AS "cpu-memory-0", root: system AS "sh_pci_host", root: bus master container Root memory region: system

Re: [PATCH v3 1/4] linux-user: Use `qemu_log' for non-strace logging

Le 04/02/2020 à 03:54, Josh Kunz a écrit : > Since most calls to `gemu_log` are actually logging unimplemented features, > this change replaces most non-strace calls to `gemu_log` with calls to > `qemu_log_mask(LOG_UNIMP, ...)`. This allows the user to easily log to > a file, and to mask out these

Re: [PATCH] Avoid cpu_physical_memory_rw() with a constant is_write argument

On 2/18/20 7:49 PM, Peter Maydell wrote: On Tue, 18 Feb 2020 at 17:57, Stefan Weil wrote: Am 18.02.20 um 14:20 schrieb Philippe Mathieu-Daudé: This commit was produced with the included Coccinelle script scripts/coccinelle/as-rw-const.patch. Inspired-by: Peter Maydell Signed-off-by: Philip

Re: [PATCH v2 00/22] Fix error handling during bitmap postcopy

qemu-iotests:$ ./check -qcow2 PASSED (except always failed 261 and 272) Andrey On 17/02/2020 18:02, Vladimir Sementsov-Ogievskiy wrote: Original idea of bitmaps postcopy migration is that bitmaps are non critical data, and their loss is not serious problem. So, using postcopy method on any fail

  1   2   3   4   5   >