Re: [PATCH v2 1/1] osdep: asynchronous teardown for shutdown on Linux

On Wed, 3 Aug 2022 18:34:45 +0100 Daniel P. Berrangé wrote: > On Wed, Aug 03, 2022 at 07:31:41PM +0200, Claudio Imbrenda wrote: > > This patch adds support for asynchronously tearing down a VM on Linux. > > > > When qemu terminates, either naturally or because of a fatal signal, > > the VM is

Re: [PATCH v5 02/10] vhost: use SVQ element ndescs instead of opaque data for desc validation

On Thu, Aug 4, 2022 at 5:01 AM Jason Wang wrote: > > > 在 2022/8/3 01:57, Eugenio Pérez 写道: > > Since we're going to allow SVQ to add elements without the guest's > > knowledge and without its own VirtQueueElement, it's easier to check if > > an element is a valid head checking a different thing

Re: [PATCH v2 19/20] ppc/ppc405: QOM'ify I2C

On 8/4/22 01:31, BALATON Zoltan wrote: On Wed, 3 Aug 2022, Cédric Le Goater wrote: Having an explicit I2C model object will help if one day we want to add I2C devices on the bus. Same here as with the UIC in previous patch, it's not QOMifying here either. As for why we may need I2C, on

Re: [PULL 9/9] hw/i386: pass RNG seed via setup_data entry

On 08/04/22 00:23, Michael S. Tsirkin wrote: > On Thu, Aug 04, 2022 at 12:08:07AM +0200, Jason A. Donenfeld wrote: >> Hi Michael, >> >> On Wed, Aug 03, 2022 at 06:03:20PM -0400, Michael S. Tsirkin wrote: >>> On Wed, Aug 03, 2022 at 07:07:52PM +0200, Jason A. Donenfeld wrote: On Wed, Aug 03,

Re: [PATCH v2 02/20] ppc/ppc405: Introduce a PPC405 generic machine

On 8/4/22 00:07, BALATON Zoltan wrote: On Wed, 3 Aug 2022, Cédric Le Goater wrote: We will use this machine as a base to define the ref405ep and possibly the PPC405 hotfoot board as found in the Linux kernel. Signed-off-by: Cédric Le Goater --- hw/ppc/ppc405_boards.c | 31

Re: [PATCH] hw/ppc: sam460ex.c: store all GPIO lines in mal_irqs[]

On 8/4/22 01:32, Daniel Henrique Barboza wrote: We're not storing all GPIO lines we're retrieving with qdev_get_gpio_in() in mal_irqs[]. We're storing just the last one in the first index: for (i = 0; i < ARRAY_SIZE(mal_irqs); i++) { mal_irqs[0] = qdev_get_gpio_in(uic[2], 3 + i);

Re: [PATCH v2 12/20] ppc/ppc405: QOM'ify EBC

On 8/4/22 01:36, Daniel Henrique Barboza wrote: Cedric, On 8/3/22 10:28, Cédric Le Goater wrote: Reviewed-by: Daniel Henrique Barboza Signed-off-by: Cédric Le Goater ---   hw/ppc/ppc405.h    | 16 +++   hw/ppc/ppc405_uc.c | 71 +++---   2 files

Re: [PATCH v2 07/20] ppc/ppc405: QOM'ify CPC

On 8/3/22 19:16, BALATON Zoltan wrote: On Wed, 3 Aug 2022, Cédric Le Goater wrote: Introduce a QOM property "cpu" to initialize the DCR handlers. This is a pattern that we will reuse for the all other 405 devices needing it. Now that all clock settings are handled at the CPC level, change the

Re: [PATCH] vdpa: do not save failed dma maps in SVQ iova tree

在 2022/8/3 16:12, Eugenio Perez Martin 写道: On Wed, Aug 3, 2022 at 10:09 AM Jason Wang wrote: On Tue, Aug 2, 2022 at 10:39 PM Eugenio Pérez wrote: If a map fails for whatever reason, it must not be saved in the tree. Otherwise, qemu will try to unmap it in cleanup, leaving to more errors.

Re: [PATCH v3 6/7] vhost_net: Add NetClientInfo prepare callback

在 2022/8/4 01:18, Eugenio Pérez 写道: This is used by the backend to perform actions before the device is started. In particular, vdpa will use it to isolate CVQ in its own ASID if possible, and start SVQ unconditionally only in CVQ. Signed-off-by: Eugenio Pérez --- include/net/net.h | 2

Re: [PATCH v3 7/7] vdpa: Always start CVQ in SVQ mode

在 2022/8/4 01:18, Eugenio Pérez 写道: Isolate control virtqueue in its own group, allowing to intercept control commands but letting dataplane run totally passthrough to the guest. Signed-off-by: Eugenio Pérez --- v3: * Make asid related queries print a warning instead of returning an error

Re: [PATCH v3 4/7] vdpa: Add asid parameter to vhost_vdpa_dma_map/unmap

在 2022/8/4 01:18, Eugenio Pérez 写道: So the caller can choose which ASID is destined. No need to update the batch functions as they will always be called from memory listener updates at the moment. Memory listener updates will always update ASID 0, as it's the passthrough ASID. All vhost

Re: [PATCH v5 00/10] NIC vhost-vdpa state restore via Shadow CVQ

在 2022/8/3 01:57, Eugenio Pérez 写道: CVQ of net vhost-vdpa devices can be intercepted since the work of [1]. The virtio-net device model is updated. The migration was blocked because although the state can be megrated between VMM it was not possible to restore on the destination NIC. This

Re: [PATCH v5 06/10] vdpa: Make vhost_vdpa_net_cvq_map_elem accept any out sg

在 2022/8/3 01:57, Eugenio Pérez 写道: So its generic enough to accept any out sg buffer and we can inject NIC state messages. Signed-off-by: Eugenio Pérez --- v5: Accept out sg instead of dev_buffers[] --- net/vhost-vdpa.c | 13 +++-- 1 file changed, 7 insertions(+), 6 deletions(-)

Re: [PATCH v5 04/10] vdpa: Get buffers from VhostVDPAState on vhost_vdpa_net_cvq_map_elem

在 2022/8/3 01:57, Eugenio Pérez 写道: There is no need to get them by parameter, since they're contained in VhostVDPAState. The only useful information was the written length in out. Simplify the function removing those. Signed-off-by: Eugenio Pérez --- net/vhost-vdpa.c | 17

Re: [PATCH v7 3/4] target/riscv: smstateen check for fcsr

On Wed, 2022-08-03 at 16:32 +0800, Weiwei Li wrote: > 在 2022/8/2 上午1:18, Mayuresh Chitale 写道: > > If smstateen is implemented and sstateen0.fcsr is clear then the > > floating point operations must return illegal instruction > > exception. > > I think this is not correct. The exception for float

Re: [PATCH] target/riscv: Fix priority of csr related check in riscv_csrrw_check

On Wed, Aug 3, 2022 at 6:16 PM Weiwei Li wrote: > > Normally, riscv_csrrw_check is called when executing Zicsr instructions. > And we can only do access control for existed CSRs. So the priority of > CSR related check, from highest to lowest, should be as follows: > 1) check whether Zicsr is

Re: [PATCH v7 2/4] target/riscv: smstateen check for h/senvcfg

On Wed, 2022-08-03 at 16:24 +0800, Weiwei Li wrote: > 在 2022/8/2 上午1:18, Mayuresh Chitale 写道: > > Accesses to henvcfg, henvcfgh and senvcfg are allowed only if > > corresponding bit in mstateen0/hstateen0 is enabled. Otherwise an > > illegal instruction trap is generated. > > > > Signed-off-by:

Re: [PATCH v7 1/4] target/riscv: Add smstateen support

On Wed, 2022-08-03 at 16:15 +0800, Weiwei Li wrote: > 在 2022/8/2 上午1:18, Mayuresh Chitale 写道: > > Smstateen extension specifies a mechanism to close > > the potential covert channels that could cause security issues. > > > > This patch adds the CSRs defined in the specification and > > the

Re: [PATCH v5 03/10] vhost: Do not depend on !NULL VirtQueueElement on vhost_svq_flush

在 2022/8/3 01:57, Eugenio Pérez 写道: Since QEMU will be able to inject new elements on CVQ to restore the state, we need not to depend on a VirtQueueElement to know if a new element has been used by the device or not. Instead of check that, check if there are new elements only using used idx on

Re: [PATCH v5 02/10] vhost: use SVQ element ndescs instead of opaque data for desc validation

在 2022/8/3 01:57, Eugenio Pérez 写道: Since we're going to allow SVQ to add elements without the guest's knowledge and without its own VirtQueueElement, it's easier to check if an element is a valid head checking a different thing than the VirtQueueElement. Signed-off-by: Eugenio Pérez ---

[PATCH v8 3/3] target/riscv: Add vstimecmp support

vstimecmp CSR allows the guest OS or to program the next guest timer interrupt directly. Thus, hypervisor no longer need to inject the timer interrupt to the guest if vstimecmp is used. This was ratified as a part of the Sstc extension. Signed-off-by: Atish Patra --- target/riscv/cpu.h

[PATCH v8 2/3] target/riscv: Add stimecmp support

stimecmp allows the supervisor mode to update stimecmp CSR directly to program the next timer interrupt. This CSR is part of the Sstc extension which was ratified recently. Signed-off-by: Atish Patra --- target/riscv/cpu.c | 9 target/riscv/cpu.h | 5 ++

[PATCH v8 1/3] hw/intc: Move mtimer/mtimecmp to aclint

Historically, The mtime/mtimecmp has been part of the CPU because they are per hart entities. However, they actually belong to aclint which is a MMIO device. Move them to the ACLINT device. This also emulates the real hardware more closely. Reviewed-by: Anup Patel Reviewed-by: Alistair Francis

[PATCH v8 0/3] Implement Sstc extension

This series implements Sstc extension[1] which was ratified recently. The first patch is a prepartory patches while PATCH 2 adds stimecmp support while PATCH 3 adds vstimecmp support. This series is based on on top of upstream commit (faee5441a038). The series can also be found at

Re: [PATCH v7 3/3] target/riscv: Add vstimecmp support

在 2022/8/4 上午5:05, Atish Kumar Patra 写道: On Wed, Aug 3, 2022 at 1:49 AM Weiwei Li > wrote: 在 2022/8/3 下午4:25, Atish Patra 写道: > vstimecmp CSR allows the guest OS or to program the next guest timer > interrupt directly. Thus, hypervisor no longer

Re: [PATCH v1 08/40] i386/tdx: Adjust the supported CPUID based on TDX restrictions

On 8/3/2022 3:33 PM, Chenyi Qiang wrote: On 8/2/2022 3:47 PM, Xiaoyao Li wrote: According to Chapter "CPUID Virtualization" in TDX module spec, CPUID bits of TD can be classified into 6 types: 1 | As configured |

Re: [PATCH 1/2] hw/arm/virt: Improve address assignment for highmem IO regions

Hi Eric, On 8/3/22 10:52 PM, Eric Auger wrote: On 8/3/22 15:02, Gavin Shan wrote: On 8/3/22 5:01 PM, Marc Zyngier wrote: On Wed, 03 Aug 2022 04:01:04 +0100, Gavin Shan wrote: On 8/2/22 7:41 PM, Eric Auger wrote: On 8/2/22 08:45, Gavin Shan wrote: There are 3 highmem IO regions as below.

[PATCH v2] hw/i386: place setup_data at fixed place in memory

The boot parameter header refers to setup_data at an absolute address, and each setup_data refers to the next setup_data at an absolute address too. Currently QEMU simply puts the setup_datas right after the kernel image, and since the kernel_image is loaded at prot_addr -- a fixed address

Re: [PATCH RFC v1] hw/i386: place setup_data at fixed place in memory

Hey again, On Thu, Aug 04, 2022 at 12:50:50AM +0200, Jason A. Donenfeld wrote: > Hi Michael, > > On Wed, Aug 03, 2022 at 06:25:39PM -0400, Michael S. Tsirkin wrote: > > > -/* Offset 0x250 is a pointer to the first setup_data link. */ > > > -stq_p(header + 0x250, first_setup_data); > > >

Re: [PATCH] hw/ppc: sam460ex.c: store all GPIO lines in mal_irqs[]

On Wed, 3 Aug 2022, Daniel Henrique Barboza wrote: We're not storing all GPIO lines we're retrieving with qdev_get_gpio_in() in mal_irqs[]. We're storing just the last one in the first index: for (i = 0; i < ARRAY_SIZE(mal_irqs); i++) { mal_irqs[0] = qdev_get_gpio_in(uic[2], 3 + i);

Re: [PATCH v2 16/20] ppc/ppc405: QOM'ify MAL

This patch really broke sam460ex boot, but not because of the QOMification. I managed to get it work by doing the following: On 8/3/22 10:28, Cédric Le Goater wrote: Reviewed-by: Daniel Henrique Barboza Signed-off-by: Cédric Le Goater --- hw/ppc/ppc405.h | 1 +

Re: [PATCH v2 15/20] ppc/ppc405: QOM'ify PLB

On 8/3/22 10:28, Cédric Le Goater wrote: Reviewed-by: Daniel Henrique Barboza Signed-off-by: Cédric Le Goater --- hw/ppc/ppc405.h| 14 ++ hw/ppc/ppc405_uc.c | 67 +- 2 files changed, 62 insertions(+), 19 deletions(-) diff --git

Re: [PATCH v2 12/20] ppc/ppc405: QOM'ify EBC

Cedric, On 8/3/22 10:28, Cédric Le Goater wrote: Reviewed-by: Daniel Henrique Barboza Signed-off-by: Cédric Le Goater --- hw/ppc/ppc405.h| 16 +++ hw/ppc/ppc405_uc.c | 71 +++--- 2 files changed, 64 insertions(+), 23 deletions(-) diff

[PATCH] hw/ppc: sam460ex.c: store all GPIO lines in mal_irqs[]

We're not storing all GPIO lines we're retrieving with qdev_get_gpio_in() in mal_irqs[]. We're storing just the last one in the first index: for (i = 0; i < ARRAY_SIZE(mal_irqs); i++) { mal_irqs[0] = qdev_get_gpio_in(uic[2], 3 + i); } ppc4xx_mal_init(env, 4, 16, mal_irqs);

Re: [PATCH v2 19/20] ppc/ppc405: QOM'ify I2C

On Wed, 3 Aug 2022, Cédric Le Goater wrote: Having an explicit I2C model object will help if one day we want to add I2C devices on the bus. Same here as with the UIC in previous patch, it's not QOMifying here either. As for why we may need I2C, on sam460ex the firmware detects RAM accessing

Re: [PATCH v2 18/20] ppc/ppc405: QOM'ify UIC

On Wed, 3 Aug 2022, Cédric Le Goater wrote: Reviewed-by: Daniel Henrique Barboza Signed-off-by: Cédric Le Goater --- hw/ppc/ppc405.h| 3 ++- hw/ppc/ppc405_uc.c | 26 +- 2 files changed, 15 insertions(+), 14 deletions(-) diff --git a/hw/ppc/ppc405.h b/hw/ppc/ppc405.h

Re: [PATCH RFC v1] hw/i386: place setup_data at fixed place in memory

On Wed, Aug 03, 2022 at 07:02:35PM +0200, Jason A. Donenfeld wrote: > The boot parameter header refers to setup_data at an absolute address, > and each setup_data refers to the next setup_data at an absolute address > too. Currently QEMU simply puts the setup_datas right after the kernel > image,

Re: [PATCH v2 12/20] ppc/ppc405: QOM'ify EBC

On Wed, 3 Aug 2022, Cédric Le Goater wrote: Reviewed-by: Daniel Henrique Barboza Signed-off-by: Cédric Le Goater --- hw/ppc/ppc405.h| 16 +++ hw/ppc/ppc405_uc.c | 71 +++--- 2 files changed, 64 insertions(+), 23 deletions(-) diff --git

Re: [PATCH RFC v1] hw/i386: place setup_data at fixed place in memory

Hi Michael, On Wed, Aug 03, 2022 at 06:25:39PM -0400, Michael S. Tsirkin wrote: > > -/* Offset 0x250 is a pointer to the first setup_data link. */ > > -stq_p(header + 0x250, first_setup_data); > > +if (first_setup_data) { > > +/* Offset 0x250 is a pointer to the first

Re: [PATCH v2 05/20] ppc/ppc405: Start QOMification of the SoC

On Wed, 3 Aug 2022, Cédric Le Goater wrote: This moves all the code previously done in the ppc405ep_init() routine under ppc405_soc_realize(). We can also adjust the number of banks now that we have control on ppc4xx_sdram_init(). Signed-off-by: Cédric Le Goater --- hw/ppc/ppc405.h|

Re: [PULL 9/9] hw/i386: pass RNG seed via setup_data entry

On Thu, Aug 04, 2022 at 12:08:07AM +0200, Jason A. Donenfeld wrote: > Hi Michael, > > On Wed, Aug 03, 2022 at 06:03:20PM -0400, Michael S. Tsirkin wrote: > > On Wed, Aug 03, 2022 at 07:07:52PM +0200, Jason A. Donenfeld wrote: > > > On Wed, Aug 03, 2022 at 03:34:04PM +0200, Jason A. Donenfeld

Re: [PATCH v2 04/20] ppc/ppc405: Introduce a PPC405 SoC

On Wed, 3 Aug 2022, Cédric Le Goater wrote: It is an initial model to start QOMification of the PPC405 board. QOM'ified devices will be reintroduced one by one. Start with the memory regions, which name prefix is changed to "ppc405". I'm not a native speaker but "which name prefix" sounds

Re: [PULL 9/9] hw/i386: pass RNG seed via setup_data entry

Hi Michael, On Wed, Aug 03, 2022 at 06:03:20PM -0400, Michael S. Tsirkin wrote: > On Wed, Aug 03, 2022 at 07:07:52PM +0200, Jason A. Donenfeld wrote: > > On Wed, Aug 03, 2022 at 03:34:04PM +0200, Jason A. Donenfeld wrote: > > > On Wed, Aug 03, 2022 at 03:11:48PM +0200, Jason A. Donenfeld wrote: >

Re: [PATCH v2 02/20] ppc/ppc405: Introduce a PPC405 generic machine

On Wed, 3 Aug 2022, Cédric Le Goater wrote: We will use this machine as a base to define the ref405ep and possibly the PPC405 hotfoot board as found in the Linux kernel. Signed-off-by: Cédric Le Goater --- hw/ppc/ppc405_boards.c | 31 --- 1 file changed, 28

Re: [PULL 9/9] hw/i386: pass RNG seed via setup_data entry

On Wed, Aug 03, 2022 at 07:07:52PM +0200, Jason A. Donenfeld wrote: > On Wed, Aug 03, 2022 at 03:34:04PM +0200, Jason A. Donenfeld wrote: > > On Wed, Aug 03, 2022 at 03:11:48PM +0200, Jason A. Donenfeld wrote: > > > Thanks for the info. Very helpful. Looking into it now. > > > > So interestingly,

Re: [PATCH for-7.1] hw/mips/malta: turn off x86 specific features of PIIX4_PM

On Thu, Jul 28, 2022 at 07:50:34AM -0400, Igor Mammedov wrote: > QEMU crashes trying to save VMSTATE when only MIPS target are compiled in > $ qemu-system-mips -monitor stdio > (qemu) migrate "exec:gzip -c > STATEFILE.gz" > Segmentation fault (core dumped) > > It happens due to PIIX4_PM

Re: [PATCH for-7.1] hw/misc/grlib_ahb_apb_pnp: Support 8 and 16 bit accesses

On Tue, Aug 2, 2022 at 4:33 PM Peter Maydell wrote: > > On Tue, 2 Aug 2022 at 15:20, Konrad, Frederic wrote: > > > > Hi Peter, > > > > CC'ing Philippe. > > > > > -Original Message- > > > From: Qemu-devel > > bounces+fkonrad=amd@nongnu.org> On Behalf Of Peter Maydell > > > Sent: 02

Re: [PATCH v7 2/3] target/riscv: Add stimecmp support

On Wed, Aug 3, 2022 at 3:26 AM Ben Dooks wrote: > On 03/08/2022 09:25, Atish Patra wrote: > > stimecmp allows the supervisor mode to update stimecmp CSR directly > > to program the next timer interrupt. This CSR is part of the Sstc > > extension which was ratified recently. > > > >

Re: [PATCH v7 2/3] target/riscv: Add stimecmp support

On Wed, Aug 3, 2022 at 1:42 AM Weiwei Li wrote: > > 在 2022/8/3 下午4:25, Atish Patra 写道: > > stimecmp allows the supervisor mode to update stimecmp CSR directly > > to program the next timer interrupt. This CSR is part of the Sstc > > extension which was ratified recently. > > > > Signed-off-by:

Re: [PATCH v7 3/3] target/riscv: Add vstimecmp support

On Wed, Aug 3, 2022 at 1:49 AM Weiwei Li wrote: > > 在 2022/8/3 下午4:25, Atish Patra 写道: > > vstimecmp CSR allows the guest OS or to program the next guest timer > > interrupt directly. Thus, hypervisor no longer need to inject the > > timer interrupt to the guest if vstimecmp is used. This was

Re: [RFC PATCH 1/3] target/ppc: Bugfix fadd/fsub result with OE/UE set

On 03/08/2022 15:16, Richard Henderson wrote: On 8/3/22 10:45, Lucas Mateus Martins Araujo e Castro wrote: On 03/08/2022 13:18, Richard Henderson wrote: On 8/3/22 05:22, Lucas Mateus Castro(alqotel) wrote: From: "Lucas Mateus Castro (alqotel)" As mentioned in the functions

Re: [RFC PATCH 1/3] target/ppc: Bugfix fadd/fsub result with OE/UE set

On 8/3/22 10:45, Lucas Mateus Martins Araujo e Castro wrote: On 03/08/2022 13:18, Richard Henderson wrote: On 8/3/22 05:22, Lucas Mateus Castro(alqotel) wrote: From: "Lucas Mateus Castro (alqotel)" As mentioned in the functions float_overflow_excp and float_underflow_excp, the result

Re: [PATCH v2 07/20] ppc/ppc405: QOM'ify CPC

On Wed, 3 Aug 2022, Cédric Le Goater wrote: Introduce a QOM property "cpu" to initialize the DCR handlers. This is a pattern that we will reuse for the all other 405 devices needing it. Now that all clock settings are handled at the CPC level, change the SoC "sys-clk" property to be an alias on

Re: [PATCH for-7.1] hw/mips/malta: turn off x86 specific features of PIIX4_PM

On Wed, 3 Aug 2022 at 18:26, Bernhard Beschow wrote: > > On Tue, Aug 2, 2022 at 8:37 AM Philippe Mathieu-Daudé via > wrote: >> >> On 28/7/22 15:16, Igor Mammedov wrote: >> > On Thu, 28 Jul 2022 13:29:07 +0100 >> > Peter Maydell wrote: >> > >> >> On Thu, 28 Jul 2022 at 12:50, Igor Mammedov

Re: [PATCH v1 00/40] TDX QEMU support

On Tue, Aug 02, 2022 at 06:55:48PM +0800, Xiaoyao Li wrote: > On 8/2/2022 5:49 PM, Daniel P. Berrangé wrote: > > On Tue, Aug 02, 2022 at 03:47:10PM +0800, Xiaoyao Li wrote: > > > > - CPU model > > > > > >We cannot create a TD with arbitrary CPU model like what for non-TDX > > > VMs, > > >

[PATCH v2 0/2] virtio: remove unnecessary host_features in ->get_features()

v2: - Document vdv->get_features() callback [Cornelia] The vdc->get_features() callbacks are a little inconsistent in how they use vdev->host_features. This is because the function's behavior changed over time. Clean things up. Stefan Hajnoczi (2): virtio: document vdc->get_features() callback

Re: [RFC PATCH 1/3] target/ppc: Bugfix fadd/fsub result with OE/UE set

On 03/08/2022 13:18, Richard Henderson wrote: On 8/3/22 05:22, Lucas Mateus Castro(alqotel) wrote: From: "Lucas Mateus Castro (alqotel)" As mentioned in the functions float_overflow_excp and float_underflow_excp, the result should be adjusted as mentioned in the ISA (subtracted 192/1536

Re: [PATCH v2 02/20] ppc/ppc405: Introduce a PPC405 generic machine

On 8/3/22 14:03, BALATON Zoltan wrote: On Wed, 3 Aug 2022, Cédric Le Goater wrote: We will use this machine as a base to define the ref405ep and possibly the PPC405 hotfoot board as found in the Linux kernel. Signed-off-by: Cédric Le Goater --- hw/ppc/ppc405_boards.c | 31

[PATCH v2 1/1] osdep: asynchronous teardown for shutdown on Linux

This patch adds support for asynchronously tearing down a VM on Linux. When qemu terminates, either naturally or because of a fatal signal, the VM is torn down. If the VM is huge, it can take a considerable amount of time for it to be cleaned up. In case of a protected VM, it might take even

Re: [PATCH for-7.1] hw/mips/malta: turn off x86 specific features of PIIX4_PM

On Tue, Aug 2, 2022 at 8:37 AM Philippe Mathieu-Daudé via < qemu-devel@nongnu.org> wrote: > On 28/7/22 15:16, Igor Mammedov wrote: > > On Thu, 28 Jul 2022 13:29:07 +0100 > > Peter Maydell wrote: > > > >> On Thu, 28 Jul 2022 at 12:50, Igor Mammedov > wrote: > >>> > >>> QEMU crashes trying to

[PATCH v2 2/2] virtio: remove unnecessary host_features in ->get_features()

Since at least commit 6b8f1020540c27246277377aa2c3331ad2bfb160 ("virtio: move host_features") the ->get_features() function has been called with host_features as an argument. Some devices manually add host_features in ->get_features() although the features argument already contains host_features.

Re: [RFC 1/1] hw: tpmtisspi: add SPI support to QEMU TPM implementation

On Wed, Aug 03, 2022 at 10:52:23AM +0200, Cédric Le Goater wrote: > On 8/3/22 04:32, Iris Chen wrote: > > From: Iris Chen > > A commit log telling us about this new device would be good to have. > > > > Signed-off-by: Iris Chen > > --- > > configs/devices/arm-softmmu/default.mak | 1 + > >

[PATCH v2 1/2] virtio: document vdc->get_features() callback

Suggested-by: Cornelia Huck Signed-off-by: Stefan Hajnoczi --- include/hw/virtio/virtio.h | 20 1 file changed, 20 insertions(+) diff --git a/include/hw/virtio/virtio.h b/include/hw/virtio/virtio.h index db1c0ddf6b..8d27fe1824 100644 --- a/include/hw/virtio/virtio.h +++

[PATCH v3 4/7] vdpa: Add asid parameter to vhost_vdpa_dma_map/unmap

So the caller can choose which ASID is destined. No need to update the batch functions as they will always be called from memory listener updates at the moment. Memory listener updates will always update ASID 0, as it's the passthrough ASID. All vhost devices's ASID are 0 at this moment.

Re: [PATCH v2 7/7] vdpa: Always start CVQ in SVQ mode

On Mon, Aug 1, 2022 at 9:50 AM Eugenio Perez Martin wrote: > > On Tue, Jul 26, 2022 at 5:04 AM Jason Wang wrote: > > > > > > 在 2022/7/22 21:43, Eugenio Pérez 写道: > > > Isolate control virtqueue in its own group, allowing to intercept control > > > commands but letting dataplane run totally

Re: [PATCH v2 1/1] osdep: asynchronous teardown for shutdown on Linux

On Wed, Aug 03, 2022 at 07:31:41PM +0200, Claudio Imbrenda wrote: > This patch adds support for asynchronously tearing down a VM on Linux. > > When qemu terminates, either naturally or because of a fatal signal, > the VM is torn down. If the VM is huge, it can take a considerable > amount of time

[PATCH v3 1/7] linux-headers: Update kernel headers

Main reason is for new vhost_vdpa address space ioctls to be available. Update kernel headers until 9de1f9c8ca51 ("Merge tag 'irq-core-2022-08-01' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip"). Signed-off-by: Eugenio Pérez --- include/standard-headers/asm-x86/bootparam.h | 7 +-

[PATCH v3 2/7] vdpa: Use v->shadow_vqs_enabled in vhost_vdpa_svqs_start & stop

This function used to trust in v->shadow_vqs != NULL to know if it must start svq or not. This is not going to be valid anymore, as qemu is going to allocate svq unconditionally (but it will only start them conditionally). Signed-off-by: Eugenio Pérez --- hw/virtio/vhost-vdpa.c | 4 ++-- 1

[PATCH v3 3/7] vdpa: Allocate SVQ unconditionally

SVQ may run or not in a device depending on runtime conditions (for example, if the device can move CVQ to its own group or not). Allocate the resources unconditionally, and decide later if to use them or not. Signed-off-by: Eugenio Pérez --- hw/virtio/vhost-vdpa.c | 33

[PATCH v6 2/2] target/s390x: support SHA-512 extensions

In order to fully support MSA_EXT_5, we have to also support the SHA-512 special instructions. So implement those. The implementation began as something TweetNacl-like, and then was adjusted to be useful here. It's not very beautiful, but it is quite short and compact, which is what we're going

[PATCH v3 5/7] vdpa: Store x-svq parameter in VhostVDPAState

CVQ can be shadowed two ways: - Device has x-svq=on parameter (current way) - The device can isolate CVQ in its own vq group QEMU needs to check for the second condition dynamically, because CVQ index is not known at initialization time. Since this is dynamic, the CVQ isolation could vary with

Re: [PATCH v2 01/20] ppc/ppc405: Remove taihu machine

On 8/3/22 10:28, Cédric Le Goater wrote: It has been deprecated since 7.0. Signed-off-by: Cédric Le Goater --- Reviewed-by: Daniel Henrique Barboza docs/about/deprecated.rst | 9 -- docs/about/removed-features.rst | 6 + docs/system/ppc/embedded.rst| 1 -

[PATCH v3 0/7] ASID support in vhost-vdpa net

Control VQ is the way net devices use to send changes to the device state, like the number of active queues or its mac address. QEMU needs to intercept this queue so it can track these changes and is able to migrate the device. It can do it from 1576dbb5bbc4 ("vdpa: Add x-svq to

[PATCH 2/2] target/s390x: support SHA-512 extensions

In order to fully support MSA_EXT_5, we have to also support the SHA-512 special instructions. So implement those. The implementation began as something TweetNacl-like, and then was adjusted to be useful here. It's not very beautiful, but it is quite short and compact, which is what we're going

[PATCH v3 6/7] vhost_net: Add NetClientInfo prepare callback

This is used by the backend to perform actions before the device is started. In particular, vdpa will use it to isolate CVQ in its own ASID if possible, and start SVQ unconditionally only in CVQ. Signed-off-by: Eugenio Pérez --- include/net/net.h | 2 ++ hw/net/vhost_net.c | 4 2 files

[PATCH v3 7/7] vdpa: Always start CVQ in SVQ mode

Isolate control virtqueue in its own group, allowing to intercept control commands but letting dataplane run totally passthrough to the guest. Signed-off-by: Eugenio Pérez --- v3: * Make asid related queries print a warning instead of returning an error and stop the start of qemu. ---

[PATCH v6 1/2] target/s390x: support PRNO_TRNG instruction

In order for hosts running inside of TCG to initialize the kernel's random number generator, we should support the PRNO_TRNG instruction, backed in the usual way with the qemu_guest_getrandom helper. This is confirmed working on Linux 5.19. Cc: Thomas Huth Cc: David Hildenbrand Cc: Christian

[PATCH 1/2] target/s390x: support PRNO_TRNG instruction

In order for hosts running inside of TCG to initialize the kernel's random number generator, we should support the PRNO_TRNG instruction, backed in the usual way with the qemu_guest_getrandom helper. This is confirmed working on Linux 5.19. Cc: Thomas Huth Cc: David Hildenbrand Cc: Christian

Re: [PULL 0/3] Linux user for 7.1 patches

linux-user 20220803 Applied, thanks. Please update https://wiki.qemu.org/ChangeLog/7.1 as appropriate. r~ Ilya Leoshkevich (1): linux-user: Do not treat madvise()'s advice as a bitmask Peter Maydell (1): linux-user

Re: [PULL 9/9] hw/i386: pass RNG seed via setup_data entry

On Wed, Aug 03, 2022 at 03:34:04PM +0200, Jason A. Donenfeld wrote: > On Wed, Aug 03, 2022 at 03:11:48PM +0200, Jason A. Donenfeld wrote: > > Thanks for the info. Very helpful. Looking into it now. > > So interestingly, this is not a new issue. If you pass any type of setup > data, OVMF appears

[PATCH RFC v1] hw/i386: place setup_data at fixed place in memory

The boot parameter header refers to setup_data at an absolute address, and each setup_data refers to the next setup_data at an absolute address too. Currently QEMU simply puts the setup_datas right after the kernel image, and since the kernel_image is loaded at prot_addr -- a fixed address

Re: [PATCH v2 02/20] ppc/ppc405: Introduce a PPC405 generic machine

On Wed, 3 Aug 2022, Cédric Le Goater wrote: We will use this machine as a base to define the ref405ep and possibly the PPC405 hotfoot board as found in the Linux kernel. Signed-off-by: Cédric Le Goater --- hw/ppc/ppc405_boards.c | 31 --- 1 file changed, 28

[PATCH] virtio-scsi: fix race in virtio_scsi_dataplane_start()

As soon as virtio_scsi_data_plane_start() attaches host notifiers the IOThread may start virtqueue processing. There is a race between IOThread virtqueue processing and virtio_scsi_data_plane_start() because it only assigns s->dataplane_started after attaching host notifiers. When a virtqueue

Re: [PATCH 0/2] vmgenid: add generation counter

On Wed, Aug 03, 2022 at 03:41:45PM +0200, bchal...@amazon.es wrote: > From: Babis Chalios > > VM generation ID exposes a GUID inside the VM which changes every time a > VM restore is happening. Typically, this GUID is used by the guest > kernel to re-seed its internal PRNG. As a result, this

Re: [PATCH for-7.2 03/10] ppc/pnv: set root port chassis and slot using Bus properties

On 8/3/22 15:44, Daniel Henrique Barboza wrote: For default root ports we have a way of accessing chassis and slot, before root_port_realize(), via pnv_phb_attach_root_port(). For the future user created root ports this won't be the case: we can't use this helper because we don't have access to

Re: [PATCH for-7.2 01/10] ppc/pnv: add phb-id/chip-id PnvPHB3RootBus properties

On 8/3/22 15:44, Daniel Henrique Barboza wrote: We rely on the phb-id and chip-id, which are PHB properties, to assign chassis and slot to the root port. For default devices this is no big deal: the root port is being created under pnv_phb_realize() and the values are being passed on via the

Re: [PATCH for-7.2 02/10] ppc/pnv: add phb-id/chip-id PnvPHB4RootBus properties

On 8/3/22 15:44, Daniel Henrique Barboza wrote: The same rationale provided in the PHB3 bus case applies here. Note: we could have merged both buses in a single object, like we did with the root ports, and spare some boilerplate. The reason we opted to preserve both buses objects is twofold: -

[PATCH v2 2/2] virtio: Add shared memory capability

From: "Dr. David Alan Gilbert" Define a new capability type 'VIRTIO_PCI_CAP_SHARED_MEMORY_CFG' and the data structure 'virtio_pci_shm_cap' to go with it. They allow defining shared memory regions with sizes and offsets of 2^32 and more. Multiple instances of the capability are allowed and

Re: [RFC PATCH 1/3] target/ppc: Bugfix fadd/fsub result with OE/UE set

On 8/3/22 05:22, Lucas Mateus Castro(alqotel) wrote: From: "Lucas Mateus Castro (alqotel)" As mentioned in the functions float_overflow_excp and float_underflow_excp, the result should be adjusted as mentioned in the ISA (subtracted 192/1536 from the exponent of the intermediate result if an

[PATCH v2 0/2] virtio-gpu: Shared memory capability

I guess RFC has been waiting long enough [0]. v2: Squash patch #3 into patch #2, and formatting fixes to patch #1. [0] https://www.mail-archive.com/qemu-devel@nongnu.org/msg840405.html Dr. David Alan Gilbert (1): virtio: Add shared memory capability Gerd Hoffmann (1): virtio-gpu: hostmem

[PATCH v2 1/2] virtio-gpu: hostmem

From: Gerd Hoffmann Use VIRTIO_GPU_SHM_ID_HOST_VISIBLE as id for virtio-gpu. v2: Formatting fixes Signed-off-by: Antonio Caggiano Acked-by: Michael S. Tsirkin --- hw/display/virtio-gpu-pci.c| 15 +++ hw/display/virtio-gpu.c| 1 + hw/display/virtio-vga.c| 33

Re: [PATCH 0/2] vmgenid: add generation counter

On 8/3/22 5:36 PM, "Michael S. Tsirkin" wrote: CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. On Wed, Aug 03, 2022 at 03:41:45PM +0200, bchal...@amazon.es wrote: >

Re: [PATCH v10 07/21] blockjob: introduce block_job _locked() APIs

Am 25.07.2022 um 09:38 hat Emanuele Giuseppe Esposito geschrieben: > Just as done with job.h, create _locked() functions in blockjob.h > > These functions will be later useful when caller has already taken > the lock. All blockjob _locked functions call job _locked functions. > > Note: at this

Re: [PATCH v7 11/14] KVM: Register/unregister the guest private memory regions

On Wed, Aug 03, 2022, Chao Peng wrote: > On Tue, Aug 02, 2022 at 04:38:55PM +, Sean Christopherson wrote: > > On Tue, Aug 02, 2022, Sean Christopherson wrote: > > > I think we should avoid UNMAPPABLE even on the KVM side of things for the > > > core > > > memslots functionality and instead be

[PATCH v3 0/2] virtio: Add shared memory capability

Previously part of [0], now a patch series on its own. This patch series cherry picks two commits from [1] and applies one fix according to [2], which should answer Gerd's comment [3] on previous patch. v2: Squash patch #3 into patch #2, and formatting fixes to patch #1. v3: Reverse commits

[PATCH v3 2/2] virtio-gpu: hostmem

From: Gerd Hoffmann Use VIRTIO_GPU_SHM_ID_HOST_VISIBLE as id for virtio-gpu. v2: Formatting fixes Signed-off-by: Antonio Caggiano Acked-by: Michael S. Tsirkin --- hw/display/virtio-gpu-pci.c| 15 +++ hw/display/virtio-gpu.c| 1 + hw/display/virtio-vga.c| 33

[PATCH v3 1/2] virtio: Add shared memory capability

From: "Dr. David Alan Gilbert" Define a new capability type 'VIRTIO_PCI_CAP_SHARED_MEMORY_CFG' and the data structure 'virtio_pci_shm_cap' to go with it. They allow defining shared memory regions with sizes and offsets of 2^32 and more. Multiple instances of the capability are allowed and

Re: [PATCH v10 06/21] job: move and update comments from blockjob.c

Am 25.07.2022 um 09:38 hat Emanuele Giuseppe Esposito geschrieben: > This comment applies more on job, it was left in blockjob as in the past > the whole job logic was implemented there. > > Note: at this stage, job_{lock/unlock} and job lock guard macros > are *nop*. > > No functional change

Re: [PATCH v2 2/2] virtio: Add shared memory capability

On Wed, Aug 03, 2022 at 05:21:35PM +0200, Antonio Caggiano wrote: > From: "Dr. David Alan Gilbert" > > Define a new capability type 'VIRTIO_PCI_CAP_SHARED_MEMORY_CFG' > and the data structure 'virtio_pci_shm_cap' to go with it. > They allow defining shared memory regions with sizes and offsets >

  1   2   3   >