Re: [Qemu-devel] [PATCH 0/2] block/file-posix: Fix xfs_write_zeroes()

On 22/08/19 18:26, Max Reitz wrote: > Lukàš ran over a nasty regression in our xfs_write_zeroes() function > (sorry, my fault) made apparent by a recent patch from Anton that makes > qcow2 images heavily exercise the offending code path. > > This series fixes the bug and adds a test to prevent it

Re: [Qemu-devel] [PULL 0/5] tricore queue

00) > > are available in the Git repository at: > > https://github.com/bkoppelmann/qemu.git tags/pull-tricore-20190822-1 > > for you to fetch changes up to d4881da9b39df183f976349f223231ac1d81087b: > > target/tricore: Fix

Re: [Qemu-devel] [PATCH] target/arm: Don't abort on M-profile exception return in linux-user mode

On 8/22/19 6:15 AM, Peter Maydell wrote: > The upshot of all this is that for linux-user mode we should never > do any of the bx_excret magic, so the code change is simple. > > This ought to be a weird corner case that only affects broken guest > code (because Linux user processes should never be

Re: [Qemu-devel] more automated/public CI for QEMU pullreqs

On Thu, Aug 22, 2019 at 06:48:08PM +0200, Paolo Bonzini wrote: > On 22/08/19 18:31, Dr. David Alan Gilbert wrote: > >> With both these points in mind, I think it is pretty hard sell to > >> say we should write & maintain a custom CI system just for QEMU > >> unless it is offering major compelling

Re: [Qemu-devel] more automated/public CI for QEMU pullreqs

On 22/08/19 18:50, Dr. David Alan Gilbert wrote: > * Paolo Bonzini (pbonz...@redhat.com) wrote: >> On 22/08/19 18:31, Dr. David Alan Gilbert wrote: With both these points in mind, I think it is pretty hard sell to say we should write & maintain a custom CI system just for QEMU unles

Re: [Qemu-devel] [PATCH 0/2] block/file-posix: Fix xfs_write_zeroes()

On 22.08.19 18:53, Paolo Bonzini wrote: > On 22/08/19 18:26, Max Reitz wrote: >> Lukàš ran over a nasty regression in our xfs_write_zeroes() function >> (sorry, my fault) made apparent by a recent patch from Anton that makes >> qcow2 images heavily exercise the offending code path. >> >> This serie

Re: [Qemu-devel] [PATCH v2 03/68] target/arm: Convert Data Processing (register)

On 8/22/19 9:00 AM, Peter Maydell wrote: > On Mon, 19 Aug 2019 at 22:38, Richard Henderson > wrote: >> >> Convert the register shifted by immediate form of the data >> processing insns. For A32, we cannot yet remove any code >> because the legacy decoder intertwines the reg-shifted-reg >> and imm

Re: [Qemu-devel] [PULL 00/13] Misc patches for 2019-08-21

On Wed, 21 Aug 2019 at 18:40, Paolo Bonzini wrote: > > The following changes since commit e65472c7bc413d79faa61eb1d05c540b03945894: > > Merge remote-tracking branch 'remotes/dgibson/tags/ppc-for-4.2-20190821' > into staging (2019-08-21 14:04:17 +0100) > > are available in the git repository at:

[Qemu-devel] [PATCH v4 0/5] ARM SMMUv3: Fix spurious notification errors and fail with VFIO

As of today when a guest is assigned with a host PCI device and an SMMUv3, VFIO calls memory_region_iommu_replay() default implementation. This translates the whole address range and completely stalls the execution. As VFIO/SMMUv3 integration is not supported yet (it requires SMMUv3 HW nested pagin

Re: [Qemu-devel] [PATCH v2 00/12] block: qiov_offset parameter for io

22.08.2019 18:50, Stefan Hajnoczi wrote: > On Tue, Jun 04, 2019 at 07:15:02PM +0300, Vladimir Sementsov-Ogievskiy wrote: >> Hi all! >> >> Here is new parameter qiov_offset for io path, to avoid >> a lot of places with same pattern of creating local_qiov or hd_qiov >> variables. >> >> These series a

[Qemu-devel] [PATCH v4 3/5] hw/vfio/common: Fail on VFIO/HW nested paging detection

As of today, VFIO only works along with vIOMMU supporting caching mode. The SMMUv3 does not support this mode and requires HW nested paging to work properly with VFIO. So any attempt to run a VFIO device protected by such IOMMU would prevent the assigned device from working and at the moment the g

[Qemu-devel] [PATCH v4 1/5] memory: Remove unused memory_region_iommu_replay_all()

memory_region_iommu_replay_all is not used. Remove it. Signed-off-by: Eric Auger Reported-by: Peter Maydell Reviewed-by: Philippe Mathieu-Daudé Reviewed-by: Peter Xu --- include/exec/memory.h | 10 -- memory.c | 9 - 2 files changed, 19 deletions(-) diff --git a

[Qemu-devel] [PATCH v4 2/5] memory: Add IOMMU_ATTR_HW_NESTED_PAGING IOMMU memory region attribute

We introduce a new IOMMU Memory Region attribute, IOMMU_ATTR_HW_NESTED_PAGING that tells whether the virtual IOMMU relies on physical IOMMU HW nested paging capability when protecting host assigned devices. Current Intel virtual IOMMU device supports "Caching Mode" and does not require 2 stages at

Re: [Qemu-devel] [PATCH] vhost-user-scsi: prevent using uninitialized vqs

On Thu, Aug 22, 2019 at 10:58:02AM +0200, Philippe Mathieu-Daudé wrote: > Hi Raphael, Stefan, > > On 6/14/19 11:18 AM, Stefan Hajnoczi wrote: > > On Tue, Jun 11, 2019 at 05:35:17PM -0700, Raphael Norwitz wrote: > >> Of the 3 virtqueues, seabios only sets cmd, leaving ctrl > >> and event without a

[Qemu-devel] [PATCH v4 4/5] hw/arm/smmuv3: Log a guest error when decoding an invalid STE

Log a guest error when encountering an invalid STE. Signed-off-by: Eric Auger Reviewed-by: Philippe Mathieu-Daudé --- hw/arm/smmuv3.c | 1 + 1 file changed, 1 insertion(+) diff --git a/hw/arm/smmuv3.c b/hw/arm/smmuv3.c index a37e3da240..c353e4c27b 100644 --- a/hw/arm/smmuv3.c +++ b/hw/arm/smmu

[Qemu-devel] [PATCH v4 5/5] hw/arm/smmuv3: Remove spurious error messages on IOVA invalidations

An IOVA/ASID invalidation is notified to all IOMMU Memory Regions through smmuv3_inv_notifiers_iova/smmuv3_notify_iova. When the notification occurs it is possible that some of the PCIe devices associated to the notified regions do not have a valid stream table entry. In that case we output a LOG_

Re: [Qemu-devel] [PATCH v2 00/12] block: qiov_offset parameter for io

22.08.2019 20:24, Vladimir Sementsov-Ogievskiy wrote: > 22.08.2019 18:50, Stefan Hajnoczi wrote: >> On Tue, Jun 04, 2019 at 07:15:02PM +0300, Vladimir Sementsov-Ogievskiy wrote: >>> Hi all! >>> >>> Here is new parameter qiov_offset for io path, to avoid >>> a lot of places with same pattern of crea

[Qemu-devel] [PATCH] modules-test: fix const cast

Signed-off-by: Paolo Bonzini --- tests/modules-test.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tests/modules-test.c b/tests/modules-test.c index 3aef0e5..a8118e9 100644 --- a/tests/modules-test.c +++ b/tests/modules-test.c @@ -4,7 +4,7 @@ static void test_modules_load(

[Qemu-devel] [PATCH] modules-test: ui-spice-app is not built as module

$(call land, $(CONFIG_SPICE), $(CONFIG_GIO)) will never return "m" so ui-spice-app is always linked into QEMU. Signed-off-by: Paolo Bonzini --- tests/modules-test.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/tests/modules-test.c b/tests/modules-test.c index a8118e9..f9de3af 100644 ---

[Qemu-devel] [PATCH v2] target/alpha: fix tlb_fill trap_arg2 value for instruction fetch

From: Aurelien Jarno Commit e41c94529740cc26 ("target/alpha: Convert to CPUClass::tlb_fill") slightly changed the way the trap_arg2 value is computed in case of TLB fill. The type of the variable used in the ternary operator has been changed from an int to an enum. This causes the -1 value to not

Re: [Qemu-devel] [edk2-rfc] [edk2-devel] CPU hotplug using SMM with QEMU+OVMF

On 08/21/19 17:48, Kinney, Michael D wrote: > Perhaps there is a way to avoid the 3000:8000 startup > vector. > > If a CPU is added after a cold reset, it is already in a > different state because one of the active CPUs needs to > release it by interacting with the hot plug controller. > > Can the

Re: [Qemu-devel] [PATCH 0/2] tests/acceptance: Update MIPS Malta ssh test

22.08.2019. 05.15, "Aleksandar Markovic" је написао/ла: > > > 21.08.2019. 23.00, "Eduardo Habkost" је написао/ла: > > > > On Wed, Aug 21, 2019 at 10:27:11PM +0200, Aleksandar Markovic wrote: > > > 02.08.2019. 17.37, "Aleksandar Markovic" < aleksandar.marko...@rt-rk.com> је > > > написао/ла: > > >

Re: [Qemu-devel] [PATCH v2 00/12] block: qiov_offset parameter for io

22.08.2019 20:39, Vladimir Sementsov-Ogievskiy wrote: > 22.08.2019 20:24, Vladimir Sementsov-Ogievskiy wrote: >> 22.08.2019 18:50, Stefan Hajnoczi wrote: >>> On Tue, Jun 04, 2019 at 07:15:02PM +0300, Vladimir Sementsov-Ogievskiy >>> wrote: Hi all! Here is new parameter qiov_offset f

Re: [Qemu-devel] [edk2-rfc] [edk2-devel] CPU hotplug using SMM with QEMU+OVMF

On 08/21/19 19:05, Paolo Bonzini wrote: > On 21/08/19 17:48, Kinney, Michael D wrote: >> Perhaps there is a way to avoid the 3000:8000 startup >> vector. >> >> If a CPU is added after a cold reset, it is already in a >> different state because one of the active CPUs needs to >> release it by intera

Re: [Qemu-devel] [PATCH] block: posix: Always allocate the first block

On 22.08.19 18:39, Nir Soffer wrote: > On Thu, Aug 22, 2019 at 5:28 PM Max Reitz > wrote: > > On 16.08.19 23:21, Nir Soffer wrote: > > When creating an image with preallocation "off" or "falloc", the first > > block of the image is typically not allocated. Wh

Re: [Qemu-devel] [PATCH 0/3] target/mips: Convert to do_transaction_failed hook

02.08.2019. 18.05, "Peter Maydell" је написао/ла: > > This patchset converts the MIPS target away from the > old broken do_unassigned_access hook to the new (added in > 2017...) do_transaction_failed hook. > Herve, bonjour. As far as I can see these changes are fine. May I ask you for your opini

Re: [Qemu-devel] [edk2-rfc] [edk2-devel] CPU hotplug using SMM with QEMU+OVMF

On 08/22/19 08:18, Paolo Bonzini wrote: > On 21/08/19 22:17, Kinney, Michael D wrote: >> Paolo, >> >> It makes sense to match real HW. > > Note that it'd also be fine to match some kind of official Intel > specification even if no processor (currently?) supports it. I agree, because... >> That pu

[Qemu-devel] [PATCH] block: workaround for unaligned byte range in fallocate()

Revert the commit 118f99442d 'block/io.c: fix for the allocation failure' and make better error handling for the file systems that do not support fallocate() for the unaligned byte range. Allow falling back to pwrite in case fallocate() returns EINVAL. Suggested-by: Kevin Wolf Suggested-by: Eric

[Qemu-devel] [PATCH 1/2] vhost-user-blk: prevent using uninitialized vqs

Same rational as: e6cc11d64fc998c11a4dfcde8fda3fc33a74d844 Of the 3 virtqueues, seabios only sets cmd, leaving ctrl and event without a physical address. This can cause vhost_verify_ring_part_mapping to return ENOMEM, causing the following logs: qemu-system-x86_64: Unable to map available ring fo

Re: [Qemu-devel] [Slirp] [PATCH 1/2] Do not reassemble fragments pointing outside of the original payload

Hello, Philippe Mathieu-Daudé, le jeu. 22 août 2019 16:41:33 +0200, a ecrit: > Later the newly calculated pointer q is converted into ip structure > and values are modified, Due to the wrong calculation of the delta, > ip will be pointing to incorrect location and ip_src and ip_dst can > b

[Qemu-devel] [PATCH 2/2] backends/vhost-user.c: prevent using uninitialized vqs

Similar rational to: e6cc11d64fc998c11a4dfcde8fda3fc33a74d844 For vhost scsi and vhost-user-scsi an issue was observed where, of the 3 virtqueues, seabios would only set cmd, leaving ctrl and event without a physical address. This can caused vhost_verify_ring_part_mapping to return ENOMEM, causing

Re: [Qemu-devel] [edk2-rfc] [edk2-devel] CPU hotplug using SMM with QEMU+OVMF

On 22/08/19 19:59, Laszlo Ersek wrote: > The firmware and QEMU could agree on a formula, which would compute the > CPU-specific SMBASE from a value pre-programmed by the firmware, and the > initial APIC ID of the hot-added CPU. > > Yes, it would duplicate code -- the calculation -- between QEMU an

Re: [Qemu-devel] [edk2-rfc] [edk2-devel] CPU hotplug using SMM with QEMU+OVMF

On 22/08/19 20:29, Laszlo Ersek wrote: > On 08/22/19 08:18, Paolo Bonzini wrote: >> On 21/08/19 22:17, Kinney, Michael D wrote: >>> DMA protection of memory ranges is a chipset feature. For the current >>> QEMU implementation, what ranges of memory are guaranteed to be >>> protected from DMA? Is i

Re: [Qemu-devel] [PATCH] block: workaround for unaligned byte range in fallocate()

22.08.2019 21:31, Andrey Shinkevich wrote: > Revert the commit 118f99442d 'block/io.c: fix for the allocation failure' > and make better error handling for the file systems that do not support > fallocate() for the unaligned byte range. Allow falling back to pwrite > in case fallocate() returns EIN

[Qemu-devel] [PATCH 0/2] linux-user/arm: Adjust MAX_RESERVED_VA for M-profile

This is inspired by the discussion in https://bugs.launchpad.net/qemu/+bug/1840922 Previously I suggested a new CPUClass hook, but when I went to implement that seemed like overkill. r~ Richard Henderson (2): linux-user: Pass CPUState to MAX_RESERVED_VA linux-user/arm: Adjust MAX_RESER

[Qemu-devel] [PATCH 2/2] linux-user/arm: Adjust MAX_RESERVED_VA for M-profile

Limit the virtual address space for M-profile cpus to 2GB, so that we avoid all of the magic addresses in the top half of the M-profile system map. Signed-off-by: Richard Henderson --- linux-user/arm/target_cpu.h | 24 +--- 1 file changed, 21 insertions(+), 3 deletions(-) di

[Qemu-devel] [PATCH 1/2] linux-user: Pass CPUState to MAX_RESERVED_VA

Turn the scalar macro into a functional macro. Move the creation of the cpu up a bit within main() so that we can pass it to the invocation of MAX_RESERVED_VA. Delay the validation of the -R parameter until MAX_RESERVED_VA is computed. So far no changes to any of the MAX_RESERVED_VA macros to ac

Re: [Qemu-devel] [PATCH] block: posix: Always allocate the first block

On Thu, Aug 22, 2019 at 9:11 PM Max Reitz wrote: > On 22.08.19 18:39, Nir Soffer wrote: > > On Thu, Aug 22, 2019 at 5:28 PM Max Reitz > > wrote: > > > > On 16.08.19 23:21, Nir Soffer wrote: > > > When creating an image with preallocation "off" or "falloc", the >

Re: [Qemu-devel] [PATCH] block: gluster: Probe alignment limits

On Thu, Aug 22, 2019 at 10:03 AM Niels de Vos wrote: > On Wed, Aug 21, 2019 at 07:04:17PM +0200, Max Reitz wrote: > > On 17.08.19 23:21, Nir Soffer wrote: > > > Implement alignment probing similar to file-posix, by reading from the > > > first 4k of the image. > > > > > > Before this change, prov

Re: [Qemu-devel] [PATCH v7 04/13] vfio: Add save and load functions for VFIO PCI devices

On 8/22/2019 3:02 PM, Dr. David Alan Gilbert wrote: > * Kirti Wankhede (kwankh...@nvidia.com) wrote: >> Sorry for delay to respond. >> >> On 7/11/2019 5:37 PM, Dr. David Alan Gilbert wrote: >>> * Kirti Wankhede (kwankh...@nvidia.com) wrote: These functions save and restore PCI device specif

Re: [Qemu-devel] [PATCH v7 04/13] vfio: Add save and load functions for VFIO PCI devices

* Kirti Wankhede (kwankh...@nvidia.com) wrote: > > > On 8/22/2019 3:02 PM, Dr. David Alan Gilbert wrote: > > * Kirti Wankhede (kwankh...@nvidia.com) wrote: > >> Sorry for delay to respond. > >> > >> On 7/11/2019 5:37 PM, Dr. David Alan Gilbert wrote: > >>> * Kirti Wankhede (kwankh...@nvidia.com)

Re: [Qemu-devel] [PATCH] block: workaround for unaligned byte range in fallocate()

22.08.2019 21:55, Vladimir Sementsov-Ogievskiy wrote: > 22.08.2019 21:31, Andrey Shinkevich wrote: >> Revert the commit 118f99442d 'block/io.c: fix for the allocation failure' >> and make better error handling for the file systems that do not support >> fallocate() for the unaligned byte range. All

[Qemu-devel] [PATCH v1 1/1] spapr_pci: remove all child functions in function zero unplug

There is nothing wrong with how sPAPR handles multifunction PCI hot unplugs. The problem is that x86 does it simpler. Instead of removing each non-zero function and then removing function zero, x86 can remove any function of the slot to trigger the hot unplug. Libvirt will be directly impacted by

Re: [Qemu-devel] [edk2-rfc] [edk2-devel] CPU hotplug using SMM with QEMU+OVMF

Paolo, The SMBASE register is internal and cannot be directly accessed by any CPU. There is an SMBASE field that is member of the SMM Save State area and can only be modified from SMM and requires the execution of an RSM instruction from SMM for the SMBASE register to be updated from the current

Re: [Qemu-devel] [Qemu-ppc] [PULL 1/2] spapr: Reset CAS & IRQ subsystem after devices

On 13/08/2019 08:59, David Gibson wrote: > This fixes a nasty regression in qemu-4.1 for the 'pseries' machine, > caused by the new "dual" interrupt controller model. Specifically, > qemu can crash when used with KVM if a 'system_reset' is requested > while there's active I/O in the guest. > > Th

Re: [Qemu-devel] [edk2-rfc] [edk2-devel] CPU hotplug using SMM with QEMU+OVMF

Laszlo, I believe all the code for the AP startup vector is already in edk2. It is a combination of the reset vector code in UefiCpuPkg/ResetVecor/Vtf0 and an IA32/X64 specific feature in the GenFv tool. It sets up a 4KB aligned location near 4GB which can be used to start an AP using INIT-SIPI-

Re: [Qemu-devel] [PATCH] block: workaround for unaligned byte range in fallocate()

On 8/22/19 1:31 PM, Andrey Shinkevich wrote: > Revert the commit 118f99442d 'block/io.c: fix for the allocation failure' > and make better error handling for the file systems that do not support s/make/use/ > fallocate() for the unaligned byte range. Allow falling back to pwrite s/the/an/ > in

Re: [Qemu-devel] [PATCH v1 1/1] spapr_pci: remove all child functions in function zero unplug

On 8/22/19 2:59 PM, Daniel Henrique Barboza wrote: > There is nothing wrong with how sPAPR handles multifunction PCI > hot unplugs. The problem is that x86 does it simpler. Instead of > removing each non-zero function and then removing function zero, > x86 can remove any function of the slot to tri

Re: [Qemu-devel] [PATCH 1/4] configure: keep track of Python version

On Thu, Aug 22, 2019 at 05:48:46PM +0100, Peter Maydell wrote: > On Fri, 9 Nov 2018 at 15:09, Cleber Rosa wrote: > > > > Some functionality is dependent on the Python version > > detected/configured on configure. While it's possible to run the > > Python version later and check for the version, d

Re: [Qemu-devel] [PATCH 1/4] configure: keep track of Python version

On Thu, Aug 22, 2019 at 05:19:26PM -0400, Cleber Rosa wrote: > On Thu, Aug 22, 2019 at 05:48:46PM +0100, Peter Maydell wrote: > > On Fri, 9 Nov 2018 at 15:09, Cleber Rosa wrote: > > > > > > Some functionality is dependent on the Python version > > > detected/configured on configure. While it's po

[Qemu-devel] [PATCH v6 2/4] 9p: Added virtfs option 'multidevs=remap|forbid|warn'

'warn' (default): Only log an error message (once) on host if more than one device is shared by same export, except of that just ignore this config error though. This is the default behaviour for not breaking existing installations implying that they really know what they are doing. 'forbid': Like

[Qemu-devel] [PATCH v6 3/4] 9p: stat_to_qid: implement slow path

stat_to_qid attempts via qid_path_prefixmap to map unique files (which are identified by 64 bit inode nr and 32 bit device id) to a 64 QID path value. However this implementation makes some assumptions about inode number generation on the host. If qid_path_prefixmap fails, we still have 48 bits av

[Qemu-devel] [PATCH v6 1/4] 9p: Treat multiple devices on one export as an error

The QID path should uniquely identify a file. However, the inode of a file is currently used as the QID path, which on its own only uniquely identifies files within a device. Here we track the device hosting the 9pfs share, in order to prevent security issues with QID path collisions from other dev

[Qemu-devel] [PATCH v6 0/4] 9p: Fix file ID collisions

This is v6 of a proposed patch set for fixing file ID collisions with 9pfs. v5->v6: * Rebased to https://github.com/gkurz/qemu/commits/9p-next (SHA1 177fd3b6a8). * Replaced previous boolean option 'remap_inodes' by tertiary option 'multidevs=remap|forbid|warn', where 'warn' is the ne

[Qemu-devel] [PATCH v6 4/4] 9p: Use variable length suffixes for inode remapping

Use variable length suffixes for inode remapping instead of the fixed 16 bit size prefixes before. With this change the inode numbers on guest will typically be much smaller (e.g. around >2^1 .. >2^7 instead of >2^48 with the previous fixed size inode remapping. Additionally this solution is more

Re: [Qemu-devel] [edk2-rfc] [edk2-devel] CPU hotplug using SMM with QEMU+OVMF

On 22/08/19 22:06, Kinney, Michael D wrote: > The SMBASE register is internal and cannot be directly accessed > by any CPU. There is an SMBASE field that is member of the SMM Save > State area and can only be modified from SMM and requires the > execution of an RSM instruction from SMM for the SM

Re: [Qemu-devel] [PATCH v6 0/4] 9p: Fix file ID collisions

Patchew URL: https://patchew.org/QEMU/cover.1566503584.git.qemu_...@crudebyte.com/ Hi, This series seems to have some coding style problems. See output below for more information: Type: series Subject: [Qemu-devel] [PATCH v6 0/4] 9p: Fix file ID collisions Message-id: cover.1566503584.git.qem

Re: [Qemu-devel] [PATCH 0/6] Refine exec

On Thu, Aug 22, 2019 at 12:25:44PM +0200, Paolo Bonzini wrote: >On 19/08/19 05:06, Wei Yang wrote: >> On Thu, Mar 21, 2019 at 04:25:49PM +0800, Wei Yang wrote: >>> This serial refine exec a little. >>> >> >> Ping again. > >Queued all except 2, thanks! > Thanks~ >Paolo > >>> Wei Yang (6): >>> ex

Re: [Qemu-devel] [edk2-rfc] [edk2-devel] CPU hotplug using SMM with QEMU+OVMF

Paolo, It is my understanding that real HW hot plug uses the SDM defined methods. Meaning the initial SMI is to 3000:8000 and they rebase to TSEG in the first SMI. They must have chipset specific methods to protect 3000:8000 from DMA. Can we add a chipset feature to prevent DMA to 64KB range fr

Re: [Qemu-devel] [PULL 2/3] tests: Run the iotests during "make check" again

On 17/08/19 10:54, Thomas Huth wrote: > People often forget to run the iotests before submitting patches or pull > requests - this is likely due to the fact that we do not run the tests > during our mandatory "make check" tests yet. Now that we've got a proper > "auto" group of iotests that should

Re: [Qemu-devel] RISC-V: Vector && DSP Extension

On Wed, Aug 21, 2019 at 6:56 PM liuzhiwei wrote: > > > On 2019/8/22 上午3:31, Palmer Dabbelt wrote: > > On Thu, 15 Aug 2019 14:37:52 PDT (-0700), alistai...@gmail.com wrote: > >> On Thu, Aug 15, 2019 at 2:07 AM Peter Maydell > >> wrote: > >>> > >>> On Thu, 15 Aug 2019 at 09:53, Aleksandar Markovic

Re: [Qemu-devel] [Qemu-riscv] RISCV: when will the CLIC be ready?

On Tue, Aug 20, 2019 at 8:38 PM liuzhiwei wrote: > > > On 2019/8/20 上午12:38, Chih-Min Chao wrote: > > > > On Mon, Aug 19, 2019 at 9:47 PM liuzhiwei wrote: >> >> >> On 2019/8/17 上午1:29, Alistair Francis wrote: >> > On Thu, Aug 15, 2019 at 8:39 PM liuzhiwei wrote: >> >> Hi, Palmer >> >> >> >> When

Re: [Qemu-devel] [PATCH v4 27/28] riscv: sifive_u: Remove handcrafted clock nodes for UART and ethernet

On Sun, Aug 18, 2019 at 10:31 PM Bin Meng wrote: > > In the past we did not have a model for PRCI, hence two handcrafted > clock nodes ("/soc/ethclk" and "/soc/uartclk") were created for the > purpose of supplying hard-coded clock frequencies. But now since we > have added the PRCI support in QEMU

Re: [Qemu-devel] [PATCH v4 13/28] riscv: hart: Add a "hartid-base" property to RISC-V hart array

On Sun, Aug 18, 2019 at 10:27 PM Bin Meng wrote: > > At present each hart's hartid in a RISC-V hart array is assigned > the same value of its index in the hart array. But for a system > that has multiple hart arrays, this is not the case any more. > > Add a new "hartid-base" property so that harti

[Qemu-devel] contrib/gitdm: Add group map for RT-RK?

Hi Aleksandar, I noticed this list of contributors: Aleksandar Markovic Dejan Jovicevic Lena Djokic Mateja Marjanovic Mateja Marjanovic Miloš Stojanović Petar Jovanovic Stefan Brankovic I see most of the commits are MIPS related (a few are PPC). Should we add these emails to contrib/git

Re: [Qemu-devel] [PATCH v4 24/28] riscv: sifive: Implement a model for SiFive FU540 OTP

On Sun, Aug 18, 2019 at 10:19 PM Bin Meng wrote: > > This implements a simple model for SiFive FU540 OTP (One-Time > Programmable) Memory interface, primarily for reading out the > stored serial number from the first 1 KiB of the 16 KiB OTP > memory reserved by SiFive for internal use. > > Signed-

[Qemu-devel] [PATCH] i386: Omit all-zeroes entries from KVM CPUID table

KVM has a 80-entry limit at KVM_SET_CPUID2. With the introduction of CPUID[0x1F], it is now possible to hit this limit with unusual CPU configurations, e.g.: $ ./x86_64-softmmu/qemu-system-x86_64 \ -smp 1,dies=2,maxcpus=2 \ -cpu EPYC,check=off,enforce=off \ -machine accel=kvm qemu

Re: [Qemu-devel] [PATCH] i386: Omit all-zeroes entries from KVM CPUID table

On 23/08/19 00:52, Eduardo Habkost wrote: > KVM has a 80-entry limit at KVM_SET_CPUID2. With the > introduction of CPUID[0x1F], it is now possible to hit this limit > with unusual CPU configurations, e.g.: > > $ ./x86_64-softmmu/qemu-system-x86_64 \ > -smp 1,dies=2,maxcpus=2 \ > -cpu EP

Re: [Qemu-devel] contrib/gitdm: Add group map for RT-RK?

23.08.2019. 00.47, "Philippe Mathieu-Daudé" је написао/ла: > > Hi Aleksandar, > > I noticed this list of contributors: > > Aleksandar Markovic > Dejan Jovicevic > Lena Djokic > Mateja Marjanovic > Mateja Marjanovic > Miloš Stojanović > Petar Jovanovic > Stefan Brankovic > > I see most of t

Re: [Qemu-devel] contrib/gitdm: Add group map for RT-RK?

On 8/23/19 1:05 AM, Aleksandar Markovic wrote: > 23.08.2019. 00.47, "Philippe Mathieu-Daudé" > је написао/ла: >> >> Hi Aleksandar, >> >> I noticed this list of contributors: >> >> Aleksandar Markovic > >> Dejan Jovicevic

[Qemu-devel] [PATCH 3/3] mailmap: Add many entries to improve 'git shortlog' statistics

All of these emails have a least 1 commit with utf8/latin1 encoding issue, or one with no author name. When there are multiple commits, keep the author name the most used. Signed-off-by: Philippe Mathieu-Daudé --- .mailmap | 105 +++ 1 file cha

[Qemu-devel] [PATCH 0/3] mailmap: Clean up

Trivial cleanup of .mailmap to have a nice 'git shortlog' output. Philippe Mathieu-Daudé (3): mailmap: Reorder by sections mailmap: Update philmd email address mailmap: Add many entries to improve 'git shortlog' statistics .mailmap | 123 +++-

[Qemu-devel] [PATCH 2/3] mailmap: Update philmd email address

Use the email address where I spend most of my time. Suggested-by: Daniel P. Berrangé Signed-off-by: Philippe Mathieu-Daudé --- .mailmap | 1 + 1 file changed, 1 insertion(+) diff --git a/.mailmap b/.mailmap index e1fdc88d25..e68ddd26e6 100644 --- a/.mailmap +++ b/.mailmap @@ -32,6 +32,7 @@ Al

[Qemu-devel] [PATCH 1/3] mailmap: Reorder by sections

Our mailmap currently has 4 sections somehow documented. Reorder few entries not related to "addresses from the original git import" into the 3rd section, and add a comment to describe it. Signed-off-by: Philippe Mathieu-Daudé --- .mailmap | 17 + 1 file changed, 9 insertions(+),

Re: [Qemu-devel] [edk2-rfc] [edk2-devel] CPU hotplug using SMM with QEMU+OVMF

On 23/08/19 00:32, Kinney, Michael D wrote: > Paolo, > > It is my understanding that real HW hot plug uses the SDM defined > methods. Meaning the initial SMI is to 3000:8000 and they rebase > to TSEG in the first SMI. They must have chipset specific methods > to protect 3000:8000 from DMA. It w

[Qemu-devel] [PATCH 0/2] Adding some setsockopt() options

Shu-Chun Weng (2): linux-user: add missing UDP and IPv6 setsockopt options linux-user: time stamping options for setsockopt() linux-user/generic/sockbits.h | 4 linux-user/mips/sockbits.h| 4 linux-user/syscall.c | 16 +--- 3 files changed, 21 insertions(+

[Qemu-devel] [PATCH] contrib/gitdm: Add RT-RK to the domain-map

This company has at least 7 contributors, add a domain-map entry. Signed-off-by: Philippe Mathieu-Daudé --- contrib/gitdm/domain-map | 1 + 1 file changed, 1 insertion(+) diff --git a/contrib/gitdm/domain-map b/contrib/gitdm/domain-map index fa9d454473..9efe066ec9 100644 --- a/contrib/gitdm/dom

[Qemu-devel] [PATCH 2/2] linux-user: time stamping options for setsockopt()

This change supports SO_TIMESTAMPNS and SO_TIMESTAMPING for setsocketopt() with SOL_SOCKET. The TARGET_SO_TIMESTAMP{NS,ING} constants are already defined for alpha, hppa, and sparc. In include/uapi/asm-generic/socket.h: In arch/mips/include/uapi/asm/socket.h: Signed-off-by: Shu-Chun Weng --- l

[Qemu-devel] [PATCH 1/2] linux-user: add missing UDP and IPv6 setsockopt options

UDP: SOL_UDP manipulate options at UDP level. All six options currently defined in linux source include/uapi/linux/udp.h take integer values. IPv6: IPV6_ADDR_PREFERENCES (RFC5014: Source address selection) was not supported. Signed-off-by: Shu-Chun Weng --- linux-user/syscall.c | 6 +- 1 fi

Re: [Qemu-devel] [PATCH 0/2] Adding some setsockopt() options

Patchew URL: https://patchew.org/QEMU/20190822231443.172099-1-...@google.com/ Hi, This series seems to have some coding style problems. See output below for more information: Type: series Subject: [Qemu-devel] [PATCH 0/2] Adding some setsockopt() options Message-id: 20190822231443.172099-1-...

Re: [Qemu-devel] [PATCH v7 04/13] vfio: Add save and load functions for VFIO PCI devices

> From: Dr. David Alan Gilbert [mailto:dgilb...@redhat.com] > Sent: Friday, August 23, 2019 3:13 AM > > * Kirti Wankhede (kwankh...@nvidia.com) wrote: > > > > > > On 8/22/2019 3:02 PM, Dr. David Alan Gilbert wrote: > > > * Kirti Wankhede (kwankh...@nvidia.com) wrote: > > >> Sorry for delay to resp

Re: [Qemu-devel] [PATCH v7 07/13] vfio: Add migration state change notifier

On Wed, Aug 21, 2019 at 04:24:27AM +0800, Kirti Wankhede wrote: > > > On 7/17/2019 7:55 AM, Yan Zhao wrote: > > On Tue, Jul 09, 2019 at 05:49:14PM +0800, Kirti Wankhede wrote: > >> Added migration state change notifier to get notification on migration > >> state > >> change. These states are tra

Re: [Qemu-devel] [edk2-rfc] [edk2-devel] CPU hotplug using SMM with QEMU+OVMF

Paolo, I find the following links related to the discussions here along with one example feature called GENPROTRANGE. https://csrc.nist.gov/CSRC/media/Presentations/The-Whole-is-Greater/images-media/day1_trusted-computing_200-250.pdf https://cansecwest.com/slides/2017/CSW2017_Cuauhtemoc-Rene_CPU_

Re: [Qemu-devel] [PATCH 2/6] exec.c: remove an unnecessary assert on PHYS_MAP_NODE_NIL in phys_map_node_alloc()

On Thu, Aug 22, 2019 at 12:24:32PM +0200, Paolo Bonzini wrote: >On 21/03/19 09:25, Wei Yang wrote: >> PHYS_MAP_NODE_NIL is assigned to PhysPageEntry.ptr in case this is not a >> leaf entry, while map->nodes_nb range in [0, nodes_nb_alloc). >> >> Seems we are asserting on two different things, just

[Qemu-devel] [PATCH v9 00/20] Invert Endian bit in SPARCv9 MMU TTE

From: Tony Nguyen This patchset implements the IE (Invert Endian) bit in SPARCv9 MMU TTE. It is an attempt of the instructions outlined by Richard Henderson to Mark Cave-Ayland. Tested with OpenBSD on sun4u. Solaris 10 is my actual goal, but unfortunately a separate keyboard issue remains in th

Re: [Qemu-devel] [PATCH v7 08/13] vfio: Register SaveVMHandlers for VFIO device

On Wed, Aug 21, 2019 at 04:33:06AM +0800, Kirti Wankhede wrote: > > > On 7/22/2019 2:04 PM, Yan Zhao wrote: > > On Tue, Jul 09, 2019 at 05:49:15PM +0800, Kirti Wankhede wrote: > >> Define flags to be used as delimeter in migration file stream. > >> Added .save_setup and .save_cleanup functions. M

Re: [Qemu-devel] [PATCH v7 06/13] vfio: Add VM state change handler to know state of VM

On Wed, Aug 21, 2019 at 04:33:50AM +0800, Kirti Wankhede wrote: > > > On 7/22/2019 2:07 PM, Yan Zhao wrote: > > On Tue, Jul 09, 2019 at 05:49:13PM +0800, Kirti Wankhede wrote: > >> VM state change handler gets called on change in VM's state. This is used > >> to set > >> VFIO device state to _RU

Re: [Qemu-devel] [PATCH v4 13/28] riscv: hart: Add a "hartid-base" property to RISC-V hart array

Hi Alistair, On Fri, Aug 23, 2019 at 6:44 AM Alistair Francis wrote: > > On Sun, Aug 18, 2019 at 10:27 PM Bin Meng wrote: > > > > At present each hart's hartid in a RISC-V hart array is assigned > > the same value of its index in the hart array. But for a system > > that has multiple hart arrays

Re: [Qemu-devel] [PATCH v9 00/20] Invert Endian bit in SPARCv9 MMU TTE

On 8/22/19 6:19 PM, Tony Nguyen wrote: > v9: > - Rebase on master and test with git am... again apologies to all, thanks for > the patience =) So... after an hour only the cover letter has arrived. I'm thinking that it didn't work. r~

Re: [Qemu-devel] [PATCH v2 2/3] net/filter.c: Add Options to insert filters anywhere in the filter list

> -Original Message- > From: Lukas Straub [mailto:lukasstra...@web.de] > Sent: Friday, August 16, 2019 2:49 AM > To: qemu-devel > Cc: Zhang, Chen ; Jason Wang > ; Wen Congyang ; Xie > Changlong > Subject: [PATCH v2 2/3] net/filter.c: Add Options to insert filters anywhere > in > the f

Re: [Qemu-devel] [Qemu-block] [PATCH 1/2] vhost-user-blk: prevent using uninitialized vqs

Raphael Norwitz 於 2019-08-23 04:16 寫道： > > Same rational as: e6cc11d64fc998c11a4dfcde8fda3fc33a74d844 > > Of the 3 virtqueues, seabios only sets cmd, leaving ctrl > and event without a physical address. This can cause > vhost_verify_ring_part_mapping to return ENOMEM, causing > the following l

Re: [Qemu-devel] [Qemu-ppc] [GIT PULL for qemu-pseries REPOST] pseries: Update SLOF firmware image

On 14/08/2019 14:33, Aravinda Prasad wrote: On Tuesday 13 August 2019 07:47 PM, David Gibson wrote: On Tue, Aug 13, 2019 at 01:00:24PM +0530, Aravinda Prasad wrote: On Monday 12 August 2019 03:38 PM, David Gibson wrote: On Mon, Aug 05, 2019 at 02:14:39PM +0530, Aravinda Prasad wrote: A

Re: [Qemu-devel] [edk2-rfc] [edk2-devel] CPU hotplug using SMM with QEMU+OVMF

Thank you Mike! That is good reference on the real hardware behavior. (Glad it is public.) For threat model, the unique part in virtual environment is temp RAM. The temp RAM in real platform is per CPU cache, while the temp RAM in virtual platform is global memory. That brings one more potential

[Qemu-devel] [PATCH v5 07/30] riscv: roms: Remove executable attribute of opensbi images

Like other binary files, the executable attribute of opensbi images should not be set. Signed-off-by: Bin Meng Reviewed-by: Alistair Francis --- Changes in v5: None Changes in v4: - new patch to remove executable attribute of opensbi images Changes in v3: None Changes in v2: None pc-bios/op

[Qemu-devel] [PATCH v5 02/30] riscv: hw: Use qemu_fdt_setprop_cell() for property with only 1 cell

Some of the properties only have 1 cell so we should use qemu_fdt_setprop_cell() instead of qemu_fdt_setprop_cells(). Signed-off-by: Bin Meng Reviewed-by: Alistair Francis --- Changes in v5: None Changes in v4: None Changes in v3: None Changes in v2: None hw/riscv/sifive_u.c | 18 +---

[Qemu-devel] [PATCH v5 01/30] riscv: hw: Remove superfluous "linux, phandle" property

"linux,phandle" property is optional. Remove all instances in the sifive_u, virt and spike machine device trees. Signed-off-by: Bin Meng Reviewed-by: Alistair Francis --- Changes in v5: None Changes in v4: - remove 2 more "linux,phandle" instances in sifive_u.c and spike.c after rebasing on

[Qemu-devel] [PATCH v5 03/30] riscv: hw: Remove not needed PLIC properties in device tree

This removes "reg-names" and "riscv,max-priority" properties of the PLIC node from device tree. Signed-off-by: Bin Meng Reviewed-by: Jonathan Behrens Reviewed-by: Alistair Francis --- Changes in v5: None Changes in v4: None Changes in v3: None Changes in v2: - keep the PLIC compatible string

[Qemu-devel] [PATCH v5 08/30] riscv: sifive_u: Remove the unnecessary include of prci header

sifive_u machine does not use PRCI as of today. Remove the prci header inclusion. Signed-off-by: Bin Meng Reviewed-by: Alistair Francis --- Changes in v5: None Changes in v4: None Changes in v3: None Changes in v2: None hw/riscv/sifive_u.c | 1 - 1 file changed, 1 deletion(-) diff --git a/hw

[Qemu-devel] [PATCH v5 17/30] riscv: sifive_u: Set the minimum number of cpus to 2

It is not useful if we only have one management CPU. Signed-off-by: Bin Meng Reviewed-by: Alistair Francis --- Changes in v5: None Changes in v4: None Changes in v3: - use management cpu count + 1 for the min_cpus Changes in v2: - update the file header to indicate at least 2 harts are create

[Qemu-devel] [PATCH v5 00/30] riscv: sifive_u: Improve the emulation fidelity of sifive_u machine

As of today, the QEMU 'sifive_u' machine is a special target that does not boot the upstream OpenSBI/U-Boot firmware images built for the real SiFive HiFive Unleashed board. Hence OpenSBI supports a special platform "qemu/sifive_u". For U-Boot, the sifive_fu540_defconfig is referenced in the OpenSB

<    1   2   3   4   >