Re: [Qemu-devel] [RFC PATCH qemu] qapi: Add query-memory-checksum

Daniel P. Berrangé writes: > On Thu, Aug 22, 2019 at 04:16:53PM +0200, Markus Armbruster wrote: >> Alexey Kardashevskiy writes: >> >> > This returns MD5 checksum of all RAM blocks for migration debugging >> > as this is way faster than saving the entire RAM to a file and checking >> > that. >>

[Qemu-devel] [PATCH v5 30/30] riscv: sifive_u: Update model and compatible strings in device tree

This updates model and compatible strings to use the same strings as used in the Linux kernel device tree (hifive-unleashed-a00.dts). 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

[Qemu-devel] [PATCH v5 26/30] riscv: sifive: Implement a model for SiFive FU540 OTP

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-off-by: Bin Meng --- Changes in v5: - change to use defines

[Qemu-devel] [PATCH v5 20/30] riscv: sifive_u: Generate hfclk and rtcclk nodes

To keep in sync with Linux kernel device tree, generate hfclk and rtcclk nodes in the device tree, to be referenced by PRCI node. 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

[Qemu-devel] [PATCH v5 29/30] riscv: sifive_u: Remove handcrafted clock nodes for UART and ethernet

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, we don't need them any more. Signed-off-by: Bin Meng

[Qemu-devel] [PATCH v5 22/30] riscv: sifive_u: Reference PRCI clocks in UART and ethernet nodes

Now that we have added a PRCI node, update existing UART and ethernet nodes to reference PRCI as their clock sources, to keep in sync with the Linux kernel device tree. Signed-off-by: Bin Meng Reviewed-by: Alistair Francis --- Changes in v5: None Changes in v4: None Changes in v3: None Changes

[Qemu-devel] [PATCH v5 14/30] riscv: hart: Extract hart realize to a separate routine

Currently riscv_harts_realize() creates all harts based on the same cpu type given in the hart array property. With current implementation it can only create homogeneous harts. Exact the hart realize to a separate routine in preparation for supporting multiple hart arrays. Note the file header

[Qemu-devel] [PATCH v5 24/30] riscv: sifive_u: Change UART node name in device tree

OpenSBI for fu540 does DT fix up (see fu540_modify_dt()) by updating chosen "stdout-path" to point to "/soc/serial@...", and U-Boot will use this information to locate the serial node and probe its driver. However currently we generate the UART node name as "/soc/uart@...", causing U-Boot fail to

[Qemu-devel] [PATCH v5 25/30] riscv: roms: Update default bios for sifive_u machine

With the support of heterogeneous harts and PRCI model, it's now possible to use the OpenSBI image (PLATFORM=sifive/fu540) built for the real hardware. 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

[Qemu-devel] [PATCH v5 21/30] riscv: sifive_u: Add PRCI block to the SoC

Add PRCI mmio base address and size mappings to sifive_u machine, and generate the corresponding device tree node. Signed-off-by: Bin Meng --- Changes in v5: - create sifive_u_prci block directly in the machine codes, instead of calling sifive_u_prci_create() Changes in v4: None Changes in

[Qemu-devel] [PATCH v5 28/30] riscv: sifive_u: Fix broken GEM support

At present the GEM support in sifive_u machine is seriously broken. The GEM block register base was set to a weird number (0x100900FC), which for no way could work with the cadence_gem model in QEMU. Not like other GEM variants, the FU540-specific GEM has a management block to control

[Qemu-devel] [PATCH v5 13/30] riscv: Add a sifive_cpu.h to include both E and U cpu type defines

Group SiFive E and U cpu type defines into one header file. Signed-off-by: Bin Meng Reviewed-by: Alistair Francis Reviewed-by: Philippe Mathieu-Daudé --- Changes in v5: None Changes in v4: None Changes in v3: None Changes in v2: None include/hw/riscv/sifive_cpu.h | 31

[Qemu-devel] [PATCH v5 15/30] riscv: hart: Add a "hartid-base" property to RISC-V hart array

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 hartid number can be assigned based on the property value.

[Qemu-devel] [PATCH v5 16/30] riscv: sifive_u: Update hart configuration to reflect the real FU540 SoC

The FU540-C000 includes a 64-bit E51 RISC-V core and four 64-bit U54 RISC-V cores. Currently the sifive_u machine only populates 4 U54 cores. Update the max cpu number to 5 to reflect the real hardware, by creating 2 CPU clusters as containers for RISC-V hart arrays to populate heterogeneous

[Qemu-devel] [PATCH v5 11/30] riscv: sifive_e: prci: Update the PRCI register block size

Currently the PRCI register block size is set to 0x8000, but in fact 0x1000 is enough, which is also what the manual says. Signed-off-by: Bin Meng Reviewed-by: Chih-Min Chao Reviewed-by: Alistair Francis --- Changes in v5: None Changes in v4: None Changes in v3: None Changes in v2: None

[Qemu-devel] [PATCH v5 18/30] riscv: sifive_u: Update PLIC hart topology configuration string

With heterogeneous harts config, the PLIC hart topology configuration string are "M,MS,.." because of the monitor hart #0. Suggested-by: Fabien Chouteau 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

[Qemu-devel] [PATCH v5 23/30] riscv: sifive_u: Update UART base addresses and IRQs

This updates the UART base address and IRQs to match the hardware. Signed-off-by: Bin Meng Reviewed-by: Jonathan Behrens Acked-by: Alistair Francis Reviewed-by: Chih-Min Chao --- Changes in v5: None Changes in v4: None Changes in v3: - update IRQ numbers of both UARTs to match hardware as

[Qemu-devel] [PATCH v5 10/30] riscv: sifive_e: prci: Fix a typo of hfxosccfg register programming

For hfxosccfg register programming, SIFIVE_E_PRCI_HFXOSCCFG_RDY and SIFIVE_E_PRCI_HFXOSCCFG_EN should be used. Signed-off-by: Bin Meng Acked-by: Alistair Francis Reviewed-by: Chih-Min Chao Reviewed-by: Philippe Mathieu-Daudé --- Changes in v5: None Changes in v4: None Changes in v3: None

[Qemu-devel] [PATCH v5 05/30] riscv: hw: Change to use qemu_log_mask(LOG_GUEST_ERROR, ...) instead

Replace the call to hw_error() with qemu_log_mask(LOG_GUEST_ERROR,...) in various sifive models. Signed-off-by: Bin Meng --- Changes in v5: - new patch to change to use qemu_log_mask(LOG_GUEST_ERROR,...) instead in various sifive models Changes in v4: None Changes in v3: None Changes in v2:

[Qemu-devel] [PATCH v5 09/30] riscv: sifive: Rename sifive_prci.{c, h} to sifive_e_prci.{c, h}

Current SiFive PRCI model only works with sifive_e machine, as it only emulates registers or PRCI block in the FE310 SoC. Rename the file name to make it clear that it is for sifive_e. This also prefix "sifive_e"/"SIFIVE_E" for all macros, variables and functions. Signed-off-by: Bin Meng

[Qemu-devel] [PATCH v5 19/30] riscv: sifive: Implement PRCI model for FU540

This adds a simple PRCI model for FU540 (sifive_u). It has different register layout from the existing PRCI model for FE310 (sifive_e). Signed-off-by: Bin Meng --- Changes in v5: - change to use defines instead of enums - change to use qemu_log_mask(LOG_GUEST_ERROR,...) in sifive_u_prci -

[Qemu-devel] [PATCH v5 06/30] riscv: hw: Remove the unnecessary include of target/riscv/cpu.h

The inclusion of "target/riscv/cpu.h" is unnecessary in various sifive model drivers. Signed-off-by: Bin Meng --- Changes in v5: - new patch to remove the unnecessary include of target/riscv/cpu.h Changes in v4: None Changes in v3: None Changes in v2: None hw/riscv/sifive_prci.c | 1 -

[Qemu-devel] [PATCH v5 04/30] riscv: hw: Change create_fdt() to return void

There is no need to return fdt at the end of create_fdt() because it's already saved in s->fdt. Signed-off-by: Bin Meng Reviewed-by: Chih-Min Chao Reviewed-by: Philippe Mathieu-Daudé Reviewed-by: Alistair Francis --- Changes in v5: None Changes in v4: - change create_fdt() to return void in

[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

[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

[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

[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 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

[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

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

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:

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

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

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 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

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

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.

[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

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,

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

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

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

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:

[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

[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 ---

[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 ---

[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

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

[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

[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 @@

[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 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

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

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

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

[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

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. > >

[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

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

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

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 >> >> >> >>

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] [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] [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

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): >>>

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:

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

[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

[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

[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

[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

[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':

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

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,

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

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] [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

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. > >

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

[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] [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.

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 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

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,

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

[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

[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(-)

[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

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

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

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

[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,

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 >

[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

[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

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

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

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.

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

  1   2   3   4   >