Re: [PATCH] travis.yml: Run tcg tests with tci

On 27/11/2019 19.38, Alex Bennée wrote: Thomas Huth writes: So far we only have compile coverage for tci. But since commit 2f160e0f9797c7522bfd0d09218d0c9340a5137c ("tci: Add implementation for INDEX_op_ld16u_i64") has been included, we can also run the x86 TCG tests with tci, so let's enable

[PATCH v19 3/8] numa: Extend CLI to provide memory side cache information

From: Liu Jingqi Add -numa hmat-cache option to provide Memory Side Cache Information. These memory attributes help to build Memory Side Cache Information Structure(s) in ACPI Heterogeneous Memory Attribute Table (HMAT). Before using hmat-cache option, enable HMAT with -machine hmat=on. Signed-o

[PATCH v19 1/8] numa: Extend CLI to provide initiator information for numa nodes

In ACPI 6.3 chapter 5.2.27 Heterogeneous Memory Attribute Table (HMAT), The initiator represents processor which access to memory. And in 5.2.27.3 Memory Proximity Domain Attributes Structure, the attached initiator is defined as where the memory controller responsible for a memory proximity domain

[PATCH v19 7/8] tests/numa: Add case for QMP build HMAT

Check configuring HMAT usecase Reviewed-by: Igor Mammedov Suggested-by: Igor Mammedov Signed-off-by: Tao Xu --- Changes in v19: - Add some fail cases for hmat-cache when level=0 Changes in v18: - Rewrite the lines over 80 characters Chenges in v17: - Add some fail test cases (Igo

[PATCH v19 0/8] Build ACPI Heterogeneous Memory Attribute Table (HMAT)

This series of patches will build Heterogeneous Memory Attribute Table (HMAT) according to the command line. The ACPI HMAT describes the memory attributes, such as memory side cache attributes and bandwidth and latency details, related to the Memory Proximity Domain. The software is expected to use

[PATCH v19 6/8] hmat acpi: Build Memory Side Cache Information Structure(s)

From: Liu Jingqi This structure describes memory side cache information for memory proximity domains if the memory side cache is present and the physical device forms the memory side cache. The software could use this information to effectively place the data in memory to maximize the performance

[PATCH v19 2/8] numa: Extend CLI to provide memory latency and bandwidth information

From: Liu Jingqi Add -numa hmat-lb option to provide System Locality Latency and Bandwidth Information. These memory attributes help to build System Locality Latency and Bandwidth Information Structure(s) in ACPI Heterogeneous Memory Attribute Table (HMAT). Before using hmat-lb option, enable HMA

[PATCH v19 8/8] tests/bios-tables-test: add test cases for ACPI HMAT

ACPI table HMAT has been introduced, QEMU now builds HMAT tables for Heterogeneous Memory with boot option '-numa node'. Add test cases on PC and Q35 machines with 2 numa nodes. Because HMAT is generated when system enable numa, the following tables need to be added for this test: tests/data/a

[PATCH v19 4/8] hmat acpi: Build Memory Proximity Domain Attributes Structure(s)

From: Liu Jingqi HMAT is defined in ACPI 6.3: 5.2.27 Heterogeneous Memory Attribute Table (HMAT). The specification references below link: http://www.uefi.org/sites/default/files/resources/ACPI_6_3_final_Jan30.pdf It describes the memory attributes, such as memory side cache attributes and bandw

[PATCH v19 5/8] hmat acpi: Build System Locality Latency and Bandwidth Information Structure(s)

From: Liu Jingqi This structure describes the memory access latency and bandwidth information from various memory access initiator proximity domains. The latency and bandwidth numbers represented in this structure correspond to rated latency and bandwidth for the platform. The software could use

Re: [PATCH v6] block/snapshot: rename Error ** parameter to more common errp

On 27.11.19 20:25, Vladimir Sementsov-Ogievskiy wrote: > Signed-off-by: Vladimir Sementsov-Ogievskiy > Reviewed-by: Eric Blake > --- > > v6: merge corresponding header change here, so, v6 is merge of > [RFC v5 011/126] block/snapshot: rename Error ** parameter to more common > errp > and >

Re: [PATCH v4 4/6] s390x: Move clear reset

On 11/28/19 8:09 AM, Thomas Huth wrote: > On 27/11/2019 18.50, Janosch Frank wrote: >> Let's also move the clear reset function into the reset handler. >> >> Signed-off-by: Janosch Frank >> --- >> target/s390x/cpu-qom.h | 1 + >> target/s390x/cpu.c | 58 +---

[PATCH v5] s390x: Move initial reset

Let's move the intial reset into the reset handler and cleanup afterwards. Signed-off-by: Janosch Frank Reviewed-by: David Hildenbrand --- Fixed the kvm vcpu reset. --- target/s390x/cpu-qom.h | 2 +- target/s390x/cpu.c | 46 +- target/s390x/cpu.h

Re: [PATCH v4 4/6] s390x: Move clear reset

On 28.11.19 09:35, Janosch Frank wrote: > On 11/28/19 8:09 AM, Thomas Huth wrote: >> On 27/11/2019 18.50, Janosch Frank wrote: >>> Let's also move the clear reset function into the reset handler. >>> >>> Signed-off-by: Janosch Frank >>> --- >>> target/s390x/cpu-qom.h | 1 + >>> target/s390x/cp

[PATCH] block/nbd: fix memory leak in nbd_open()

From: PanNengyuan In currently implementation there will be a memory leak when nbd_client_connect() returns error status. Here is an easy way to reproduce: 1. run qemu-iotests as follow and check the result with asan: ./check -raw 143 Following is the asan output backtrack: Direct leak of 4

Re: [PATCH 2/4] target/arm: Abstract the generic timer frequency

On 28/11/2019 06:45, Andrew Jeffery wrote: > Prepare for SoCs such as the ASPEED AST2600 whose firmware configures > CNTFRQ to values significantly larger than the static 62.5MHz value > currently derived from GTIMER_SCALE. As the OS potentially derives its > timer periods from the CNTFRQ value the

Re: [PATCH 4/4] ast2600: Configure CNTFRQ at 1125MHz

On 28/11/2019 06:45, Andrew Jeffery wrote: > This matches the configuration set by u-boot on the AST2600. > > Signed-off-by: Andrew Jeffery Reviewed-by: Cédric Le Goater > --- > hw/arm/aspeed_ast2600.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/hw/arm/aspeed_ast2600.c b/hw/a

Re: [PATCH 1/4] target/arm: Remove redundant scaling of nexttick

On 28/11/2019 06:45, Andrew Jeffery wrote: > The corner-case codepath was adjusting nexttick such that overflow > wouldn't occur when timer_mod() scaled the value back up. Remove a use > of GTIMER_SCALE and avoid unnecessary operations by calling > timer_mod_ns() directly. > > Signed-off-by: Andre

Re: [RFC v5 000/126] error: auto propagated local_err

Please accept my sincere apologies for taking so long to reply. A few thoughts before I dig deeper. Vladimir Sementsov-Ogievskiy writes: > Hi all! > > At the request of Markus: full version of errp propagation. Let's look > at it. Cover as much as possible, except inserting macro invocation > w

Re: [PATCH] block/nbd: fix memory leak in nbd_open()

On Thu, Nov 28, 2019 at 04:40:10PM +0800, pannengy...@huawei.com wrote: Hi, I don't know nbd code very well, the patch LGTM, but just a comment below: > From: PanNengyuan > > In currently implementation there will be a memory leak when > nbd_client_connect() returns error status. Here is an eas

[Bug 1846427] Re: 4.1.0: qcow2 corruption on savevm/quit/loadvm cycle

All my images are still fine after some heavy use with qemu-4.1.0 and fix patches applied. Just upgraded to 4.1.1 and will report back. But it's certainly looks like this bug is fixed for good. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed t

Re: [PATCH v5] s390x: Move initial reset

On 28/11/2019 09.37, Janosch Frank wrote: Let's move the intial reset into the reset handler and cleanup afterwards. Signed-off-by: Janosch Frank Reviewed-by: David Hildenbrand --- Fixed the kvm vcpu reset. --- target/s390x/cpu-qom.h | 2 +- target/s390x/cpu.c | 46 +-

Re: [RFC v5 000/126] error: auto propagated local_err

28.11.2019 11:54, Markus Armbruster wrote: > Please accept my sincere apologies for taking so long to reply. A few > thoughts before I dig deeper. > > Vladimir Sementsov-Ogievskiy writes: > >> Hi all! >> >> At the request of Markus: full version of errp propagation. Let's look >> at it. Cover a

[PATCH v10 1/3] block: introduce compress filter driver

Allow writing all the data compressed through the filter driver. The written data will be aligned by the cluster size. Based on the QEMU current implementation, that data can be written to unallocated clusters only. May be used for a backup job. Suggested-by: Max Reitz Signed-off-by: Andrey Shink

[PATCH v10 3/3] tests/qemu-iotests: add case to write compressed data of multiple clusters

Add the case to the iotest #214 that checks possibility of writing compressed data of more than one cluster size. The test case involves the compress filter driver showing a sample usage of that. Signed-off-by: Andrey Shinkevich Reviewed-by: Vladimir Sementsov-Ogievskiy Reviewed-by: Max Reitz -

[PATCH v10 0/3] qcow2: advanced compression options

The compression filter driver is introduced as suggested by Max. A sample usage of the filter can be found in the test #214. Now, multiple clusters can be written compressed. It is useful for the backup job. v10: 01: The option 'compress' moved up in the QAPI BlockdevDriver list to fit its

[PATCH v10 2/3] qcow2: Allow writing compressed data of multiple clusters

QEMU currently supports writing compressed data of the size equal to one cluster. This patch allows writing QCOW2 compressed data that exceed one cluster. Now, we split buffered data into separate clusters and write them compressed using the block/aio_task API. Suggested-by: Pavel Butsykin Sugges

Re: [PATCH for-5.0 02/31] block: Add BdrvChildRole

27.11.2019 16:15, Max Reitz wrote: > This enum will supplement BdrvChildClass when it comes to what role (or > combination of roles) a child takes for its parent. > > Because empty enums are not allowed, let us just start with it filled. > > Signed-off-by: Max Reitz > --- > include/block/block

Re: [RFC PATCH 06/10] hw/avr: Add ATmega microcontrollers

On Thursday, November 28, 2019, Philippe Mathieu-Daudé wrote: > Add famous ATmega MCUs: > > - middle range: ATmega168 and ATmega328 > - high range: ATmega1280 and ATmega2560 > > Signed-off-by: Philippe Mathieu-Daudé > --- Philippe, hi. Thank you for the impetus you give us all. However, is t

Re: [PATCH v35 10/13] target/avr: Add limited support for USART and 16 bit timer peripherals

Hi Aleksandar, > Sarah, thanks for taking your tome to respond! No problem! :) > do we fully support what is said in: > * 22.6.2 Sending Frames with 9 Data Bit > * 22.7.2 Receiving Frames with 9 Data Bits No, QEMU's character device system only supports 8 bit characters. Shorter characters can be

Re: [PATCH v36 17/17] target/avr: Update MAINTAINERS file

Yes, I don't have time to do maintenance, but I can manage reviewing. Kind regards, Sarah Harris On Tue, 26 Nov 2019 22:41:32 +0200 Michael Rolnik wrote: > Ah. I think Sarah was ok with reviewer role. > > On Tue, Nov 26, 2019 at 9:39 PM Aleksandar Markovic < > aleksandar.m.m...@gmail.com> wro

Re: [RFC PATCH 06/10] hw/avr: Add ATmega microcontrollers

Aleksandar Markovic писал 2019-11-28 12:28: On Thursday, November 28, 2019, Philippe Mathieu-Daudé wrote: Add famous ATmega MCUs: - middle range: ATmega168 and ATmega328 - high range: ATmega1280 and ATmega2560 Signed-off-by: Philippe Mathieu-Daudé --- Philippe, hi. Thank you for the impe

[PATCH v1 0/1] s390x: protvirt: SCLP interpretation

A new proposition: I think it would be wise to fork directly from handle_instruction instead to accept per default all instructions with with secure instruction interception code. Just in case future firmware with older QEMU. How ever I let three dors open. 1) This patch accepts the all B2 instru

[PATCH v1 1/1] s390x: protvirt: SCLP interpretation

The SCLP protection handle some of the exceptions due to mis-constructions of the SCLP Control Block (SCCB) by the guest and provides notifications to the host when something gets wrong. We currently do not handle these exceptions, letting all the work to the firmware therefor, we only need to inje

Re: [PATCH] travis.yml: Run tcg tests with tci

Thomas Huth writes: > On 27/11/2019 19.38, Alex Bennée wrote: >> Thomas Huth writes: >> >>> So far we only have compile coverage for tci. But since commit >>> 2f160e0f9797c7522bfd0d09218d0c9340a5137c ("tci: Add implementation >>> for INDEX_op_ld16u_i64") has been included, we can also run the

Re: [RFC PATCH 06/10] hw/avr: Add ATmega microcontrollers

On Thursday, November 28, 2019, dovgaluk wrote: > Aleksandar Markovic писал 2019-11-28 12:28: > >> On Thursday, November 28, 2019, Philippe Mathieu-Daudé >> wrote: >> >> Add famous ATmega MCUs: >>> >>> - middle range: ATmega168 and ATmega328 >>> - high range: ATmega1280 and ATmega2560 >>> >>> Si

Re: [RFC PATCH 00/10] hw/avr: Introduce the Arduino board

Hi Philippe. This is really good news. Should I do anything or this will be merged after my stuff goes through? On Thu, Nov 28, 2019 at 3:50 AM Philippe Mathieu-Daudé wrote: > Hi Michael, > > I complained I'd rather have QEMU model real hardware, with > documentation (schematics). > Since your

Re: [PATCH] block/nbd: fix memory leak in nbd_open()

Hi, I think it's a better way, you can implement this new function before this patch. Thanks. On 2019/11/28 17:01, Stefano Garzarella wrote: > On Thu, Nov 28, 2019 at 04:40:10PM +0800, pannengy...@huawei.com wrote: > > Hi, > I don't know nbd code very well, the patch LGTM, but just a comment > b

[PATCH v5 0/4] blockdev: avoid acquiring AioContext lock twice at do_drive_backup and do_blockdev_backup

do_drive_backup() acquires the AioContext lock of the corresponding BlockDriverState. This is not a problem when it's called from qmp_drive_backup(), but drive_backup_prepare() also acquires the lock before calling it. The same things happens with do_blockdev_backup() and blockdev_backup_prepare().

[PATCH v5 4/4] blockdev: honor bdrv_try_set_aio_context() context requirements

bdrv_try_set_aio_context() requires that the old context is held, and the new context is not held. Fix all the occurrences where it's not done this way. Suggested-by: Max Reitz Signed-off-by: Sergio Lopez --- blockdev.c | 72 ++ 1 file changed

[PATCH v5 2/4] blockdev: unify qmp_drive_backup and drive-backup transaction paths

Issuing a drive-backup from qmp_drive_backup takes a slightly different path than when it's issued from a transaction. In the code, this is manifested as some redundancy between do_drive_backup() and drive_backup_prepare(). This change unifies both paths, merging do_drive_backup() and drive_backup

[PATCH v5 1/4] blockdev: fix coding style issues in drive_backup_prepare

Fix a couple of minor coding style issues in drive_backup_prepare. Signed-off-by: Sergio Lopez Reviewed-by: Max Reitz --- blockdev.c | 8 +--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/blockdev.c b/blockdev.c index 8e029e9c01..553e315972 100644 --- a/blockdev.c +++ b/blo

Re: [PATCH] block/nbd: fix memory leak in nbd_open()

On Thu, Nov 28, 2019 at 06:32:49PM +0800, pannengyuan wrote: > Hi, > I think it's a better way, you can implement this new function before > this patch. If you want to do it, so you can send everything together, for me there's no problem, it was just a suggestion. If you don't have time, I can do

[PATCH v5 3/4] blockdev: unify qmp_blockdev_backup and blockdev-backup transaction paths

Issuing a blockdev-backup from qmp_blockdev_backup takes a slightly different path than when it's issued from a transaction. In the code, this is manifested as some redundancy between do_blockdev_backup() and blockdev_backup_prepare(). This change unifies both paths, merging do_blockdev_backup() a

Re: [PATCH v35 10/13] target/avr: Add limited support for USART and 16 bit timer peripherals

On Thursday, November 28, 2019, Sarah Harris wrote: > Hi Aleksandar, > > > Sarah, thanks for taking your tome to respond! > No problem! :) > > > do we fully support what is said in: > > * 22.6.2 Sending Frames with 9 Data Bit > > * 22.7.2 Receiving Frames with 9 Data Bits > No, QEMU's character d

Re: [PATCH] block/nbd: fix memory leak in nbd_open()

Thanks for you suggestion, I'd be glad to do it, I will send a new version later. Cheers. On 2019/11/28 18:41, Stefano Garzarella wrote: > On Thu, Nov 28, 2019 at 06:32:49PM +0800, pannengyuan wrote: >> Hi, >> I think it's a better way, you can implement this new function before >> this patch. >

Re: [PATCH for-5.0 02/31] block: Add BdrvChildRole

On 28.11.19 10:31, Vladimir Sementsov-Ogievskiy wrote: > 27.11.2019 16:15, Max Reitz wrote: >> This enum will supplement BdrvChildClass when it comes to what role (or >> combination of roles) a child takes for its parent. >> >> Because empty enums are not allowed, let us just start with it filled.

Re: [RFC PATCH 06/10] hw/avr: Add ATmega microcontrollers

Aleksandar Markovic писал 2019-11-28 13:20: On Thursday, November 28, 2019, dovgaluk wrote: Aleksandar Markovic писал 2019-11-28 12:28: On Thursday, November 28, 2019, Philippe Mathieu-Daudé wrote: Add famous ATmega MCUs: - middle range: ATmega168 and ATmega328 - high range: ATmega1280 and

[PATCH v2 0/1] s390x: css: pong, channel subsystem test device

This patch series presents a device to test the channel subsystem. Currently it only does the following: - answer to WRITE requests by incrementing an integer stored as string in the data of a PONG_WRITE CCW command. - send back the same buffer, with the incremented integer when receiving a PO

Re: [RFC PATCH 06/10] hw/avr: Add ATmega microcontrollers

On 11/28/19 11:20 AM, Aleksandar Markovic wrote: On Thursday, November 28, 2019, dovgaluk > wrote: Aleksandar Markovic писал 2019-11-28 12:28: On Thursday, November 28, 2019, Philippe Mathieu-Daudé mailto:f4...@amsat.org>> wrote: Add f

Re: [PATCH v35 10/13] target/avr: Add limited support for USART and 16 bit timer peripherals

On Thursday, November 28, 2019, Aleksandar Markovic < aleksandar.m.m...@gmail.com> wrote: > > > On Thursday, November 28, 2019, Sarah Harris wrote: > >> Hi Aleksandar, >> >> > Sarah, thanks for taking your tome to respond! >> No problem! :) >> >> > do we fully support what is said in: >> > * 22.6

Re: [PATCH for-5.0 02/31] block: Add BdrvChildRole

28.11.2019 13:52, Max Reitz wrote: > On 28.11.19 10:31, Vladimir Sementsov-Ogievskiy wrote: >> 27.11.2019 16:15, Max Reitz wrote: >>> This enum will supplement BdrvChildClass when it comes to what role (or >>> combination of roles) a child takes for its parent. >>> >>> Because empty enums are not a

[Bug 1853826] Re: ELF loader fails to load shared object on ThunderX2 running RHEL7

This was on Aarch64 Ubuntu 18.04 - I don't have any RHEL machines around but if you send the ld.so along with the other libraries that won't matter in replicating the fault on my x86 host. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEM

[PATCH v2 1/1] s390x: css: pong, channel subsystem test device

This is a test device for channel subsystem. Most of the CSS instructions are handled by the common code. The PONG_READ and PONG_WRITE CCW commands allow to test the SSCH instruction with both read and write commands. It is also possible to define the Control Unit type with the cu_type property.

Re:[Qemu-devel] [PATCH v2] vhost-vsock: report QMP event when setrunning

Let me describe the issue with an example via `nc-vsock`: Let's assume the Guest cid is 3. execute 'rmmod vmw_vsock_virtio_transport' in Guest, then execute 'while true; do nc-vsock 3 1234' in Host. Host Guest # rmmod vmw_vsock_virtio_t

[Bug 1853826] Re: ELF loader fails to load shared object on ThunderX2 running RHEL7

IIRC RHEL uses 64k pages but Ubuntu does not -- maybe that is relevant ? Is the guest binary built for 4K or 64K pages? -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1853826 Title: ELF loader fails

Re: [RFC PATCH 06/10] hw/avr: Add ATmega microcontrollers

On Thursday, November 28, 2019, dovgaluk wrote: > Aleksandar Markovic писал 2019-11-28 13:20: > >> On Thursday, November 28, 2019, dovgaluk wrote: >> >> Aleksandar Markovic писал 2019-11-28 12:28: >>> On Thursday, November 28, 2019, Philippe Mathieu-Daudé >>> wrote: >>> >>> Add famous ATmega MC

Re: [PATCH v19 7/8] tests/numa: Add case for QMP build HMAT

Tao Xu writes: > Check configuring HMAT usecase > > Reviewed-by: Igor Mammedov > Suggested-by: Igor Mammedov > Signed-off-by: Tao Xu > --- > > Changes in v19: > - Add some fail cases for hmat-cache when level=0 > > Changes in v18: > - Rewrite the lines over 80 characters > > Chenges in

Re: [PATCH v19 2/8] numa: Extend CLI to provide memory latency and bandwidth information

Tao Xu writes: > From: Liu Jingqi > > Add -numa hmat-lb option to provide System Locality Latency and > Bandwidth Information. These memory attributes help to build > System Locality Latency and Bandwidth Information Structure(s) > in ACPI Heterogeneous Memory Attribute Table (HMAT). Before usin

Re: [RFC 0/1] ATI R300 emulated grpahics card V2

On Thu, Nov 28, 2019 at 12:13:49PM +0530, aaron.zakh...@gmail.com wrote: > From: Aaron Dominick > > This is the cleaned up patchset to my previous RFC patch set. > I could not reliably clean up my previous commits so I deleted my fork and > started from scratch. > The patch looks like a lot of c

Re: [PATCH v19 7/8] tests/numa: Add case for QMP build HMAT

On 28/11/2019 12.49, Markus Armbruster wrote: Tao Xu writes: Check configuring HMAT usecase Reviewed-by: Igor Mammedov Suggested-by: Igor Mammedov Signed-off-by: Tao Xu --- Changes in v19: - Add some fail cases for hmat-cache when level=0 Changes in v18: - Rewrite the lines ove

Re: [PATCH v19 0/8] Build ACPI Heterogeneous Memory Attribute Table (HMAT)

Tao Xu writes: > This series of patches will build Heterogeneous Memory Attribute Table (HMAT) > according to the command line. The ACPI HMAT describes the memory attributes, > such as memory side cache attributes and bandwidth and latency details, > related to the Memory Proximity Domain. > The

Re: [RFC PATCH 06/10] hw/avr: Add ATmega microcontrollers

Hi Aleksandar, Richard. On 11/28/19 10:28 AM, Aleksandar Markovic wrote: On Thursday, November 28, 2019, Philippe Mathieu-Daudé > wrote: Add famous ATmega MCUs: - middle range: ATmega168 and ATmega328 - high range: ATmega1280 and ATmega2560 Signed-off-b

Re: [PATCH v37 01/17] target/avr: Add outward facing interfaces and core CPU logic

On Thu, Nov 28, 2019 at 12:26 AM Philippe Mathieu-Daudé wrote: > Hi Michael, > > On 11/27/19 6:52 PM, Michael Rolnik wrote: > > This includes: > > - CPU data structures > > - object model classes and functions > > - migration functions > > - GDB hooks > > > > Co-developed-by: Michael Rolnik > >

[Bug 1853826] Re: ELF loader fails to load shared object on ThunderX2 running RHEL7

Alex, Do you have the licence to run the compiler library? -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1853826 Title: ELF loader fails to load shared object on ThunderX2 running RHEL7 Status in

Re: [PATCH v1 1/1] s390x: protvirt: SCLP interpretation

On 28/11/2019 11.13, Pierre Morel wrote: The SCLP protection handle some of the exceptions due to mis-constructions of the SCLP Control Block (SCCB) by the guest and provides notifications to the host when something gets wrong. We currently do not handle these exceptions, letting all the work to

Re: [PATCH v19 3/8] numa: Extend CLI to provide memory side cache information

Tao Xu writes: > From: Liu Jingqi > > Add -numa hmat-cache option to provide Memory Side Cache Information. > These memory attributes help to build Memory Side Cache Information > Structure(s) in ACPI Heterogeneous Memory Attribute Table (HMAT). > Before using hmat-cache option, enable HMAT with

[PATCH V2] block/nbd: fix memory leak in nbd_open()

From: PanNengyuan In currently implementation there will be a memory leak when nbd_client_connect() returns error status. Here is an easy way to reproduce: 1. run qemu-iotests as follow and check the result with asan: ./check -raw 143 Following is the asan output backtrack: Direct leak of 4

Re: [RFC v5 000/126] error: auto propagated local_err

Vladimir Sementsov-Ogievskiy writes: > 28.11.2019 11:54, Markus Armbruster wrote: >> Please accept my sincere apologies for taking so long to reply. A few >> thoughts before I dig deeper. >> >> Vladimir Sementsov-Ogievskiy writes: >> >>> Hi all! >>> >>> At the request of Markus: full version

Re: [PATCH v1 0/1] s390x: protvirt: SCLP interpretation

On 11/28/19 11:13 AM, Pierre Morel wrote: > A new proposition: > I think it would be wise to fork directly from handle_instruction > instead to accept per default all instructions with with secure > instruction interception code. > Just in case future firmware with older QEMU. > > How ever I let t

[PATCH v1 1/1] pc-bios/s390-ccw: fix sclp_get_loadparm_ascii

The existing s390 bios gets the LOADPARM information from the system using an SCLP call that specifies a buffer length too small to contain all the output. The recent fixes in the SCLP code have exposed this bug, since now the SCLP call will return an error (as per architecture) instead of writing

Re: [PATCH v37 00/17] QEMU AVR 8 bit cores

On Wed, Nov 27, 2019 at 11:06 PM Aleksandar Markovic < aleksandar.m.m...@gmail.com> wrote: > On Wed, Nov 27, 2019 at 6:53 PM Michael Rolnik wrote: > > > > This series of patches adds 8bit AVR cores to QEMU. > > All instruction, except BREAK/DES/SPM/SPMX, are implemented. Not fully > tested yet. >

[PATCH RFC] qga: fence guest-set-time if hwclock not available

The Posix implementation of guest-set-time invokes hwclock to set/retrieve the time to/from the hardware clock. If hwclock is not available, the user is currently informed that "hwclock failed to set hardware clock to system time", which is quite misleading. This may happen e.g. on s390x, which has

Re: [PATCH v1 1/1] pc-bios/s390-ccw: fix sclp_get_loadparm_ascii

Ack. Conny, I think this would be really nice to have for 4.2 (together with a bios rebuild) as this fixes a regression. Opinions? On 28.11.19 13:33, Claudio Imbrenda wrote: > The existing s390 bios gets the LOADPARM information from the system using > an SCLP call that specifies a buffer leng

RE: [PATCH 0/5] ARM virt: Add NVDIMM support

> -Original Message- > From: Qemu-devel > [mailto:qemu-devel-bounces+shameerali.kolothum.thodi=huawei.com@nongn > u.org] On Behalf Of Igor Mammedov > Sent: 26 November 2019 08:57 > To: Shameerali Kolothum Thodi > Cc: peter.mayd...@linaro.org; drjo...@redhat.com; > xiaoguangrong.e...@gmai

Re: [PATCH RFC] qga: fence guest-set-time if hwclock not available

On Thu, Nov 28, 2019 at 01:36:58PM +0100, Cornelia Huck wrote: > The Posix implementation of guest-set-time invokes hwclock to > set/retrieve the time to/from the hardware clock. If hwclock > is not available, the user is currently informed that "hwclock > failed to set hardware clock to system tim

[PATCH v5] qga: add command guest-get-devices for reporting VirtIO devices

Add command for reporting devices on Windows guest. The intent is not so much to report the devices but more importantly the driver (and its version) that is assigned to the device. This gives caller the information whether VirtIO drivers are installed and/or whether inadequate driver is used on a

Re: [PATCH v1 1/1] pc-bios/s390-ccw: fix sclp_get_loadparm_ascii

On 11/28/19 1:33 PM, Claudio Imbrenda wrote: > The existing s390 bios gets the LOADPARM information from the system using > an SCLP call that specifies a buffer length too small to contain all the > output. > > The recent fixes in the SCLP code have exposed this bug, since now the > SCLP call will

Re: [PATCH v1 1/1] pc-bios/s390-ccw: fix sclp_get_loadparm_ascii

On Thu, 28 Nov 2019 13:33:57 +0100 Claudio Imbrenda wrote: [...] > Signed-off-by: Claudio Imbrenda I forgot this: Reported-by: Marc Hartmayer [...] please add the reported-by when merging :)

[PATCH] Adding support for MAC filtering in the FEC IP implementation

Adding support for MAC filtering in the FEC IP implementation. This addition ensures that the IP does NOT boot up in promiscuous mode by default, and so the software only receives the desired packets(Unicast, Broadcast, Unicast / Multicast hashed) by default. The software running on-top of QEM

Re: [PATCH v1 1/1] pc-bios/s390-ccw: fix sclp_get_loadparm_ascii

On 28.11.19 13:45, Cornelia Huck wrote: > On Thu, 28 Nov 2019 13:35:29 +0100 > Christian Borntraeger wrote: > >> Ack. >> >> Conny, I think this would be really nice to have for 4.2 (together with a >> bios rebuild) >> as this fixes a regression. Opinions? > > I fear that this is a bit late f

Re: [PATCH v1 1/1] pc-bios/s390-ccw: fix sclp_get_loadparm_ascii

On Thu, 28 Nov 2019 13:35:29 +0100 Christian Borntraeger wrote: > Ack. > > Conny, I think this would be really nice to have for 4.2 (together with a > bios rebuild) > as this fixes a regression. Opinions? I fear that this is a bit late for 4.2... but this should get a cc:stable. > > > > On

Re: [PATCH RFC] qga: fence guest-set-time if hwclock not available

On Thu, 28 Nov 2019 12:45:32 + Daniel P. Berrangé wrote: > On Thu, Nov 28, 2019 at 01:36:58PM +0100, Cornelia Huck wrote: > > The Posix implementation of guest-set-time invokes hwclock to > > set/retrieve the time to/from the hardware clock. If hwclock > > is not available, the user is curren

Re: [PATCH v1 1/1] s390x: protvirt: SCLP interpretation

On 2019-11-28 13:10, Thomas Huth wrote: On 28/11/2019 11.13, Pierre Morel wrote: The SCLP protection handle some of the exceptions due to mis-constructions of the SCLP Control Block (SCCB) by the guest and provides notifications to the host when something gets wrong. We currently do not handle

Re: [PATCH v5] qga: add command guest-get-devices for reporting VirtIO devices

Hi On Thu, Nov 28, 2019 at 4:49 PM Tomáš Golembiovský wrote: > > Add command for reporting devices on Windows guest. The intent is not so > much to report the devices but more importantly the driver (and its > version) that is assigned to the device. This gives caller the > information whether Vi

Re: [PATCH v5] qga: add command guest-get-devices for reporting VirtIO devices

On Thu, Nov 28, 2019 at 01:45:13PM +0100, Tomáš Golembiovský wrote: > Add command for reporting devices on Windows guest. The intent is not so > much to report the devices but more importantly the driver (and its > version) that is assigned to the device. This gives caller the > information whether

Re: [PATCH v1 1/1] pc-bios/s390-ccw: fix sclp_get_loadparm_ascii

On 28/11/2019 13.35, Christian Borntraeger wrote: Ack. Conny, I think this would be really nice to have for 4.2 (together with a bios rebuild) as this fixes a regression. Opinions? If we do another rc of 4.2, I think we definitely want this to be included, otherwise quite a bunch of things d

Re: [PATCH v1 1/1] pc-bios/s390-ccw: fix sclp_get_loadparm_ascii

On Thu, 28 Nov 2019 14:11:38 +0100 Thomas Huth wrote: > On 28/11/2019 13.35, Christian Borntraeger wrote: > > Ack. > > > > Conny, I think this would be really nice to have for 4.2 (together with a > > bios rebuild) > > as this fixes a regression. Opinions? > > If we do another rc of 4.2, I t

Re: [PATCH v1 0/1] s390x: protvirt: SCLP interpretation

On 2019-11-28 13:28, Janosch Frank wrote: On 11/28/19 11:13 AM, Pierre Morel wrote: A new proposition: I think it would be wise to fork directly from handle_instruction instead to accept per default all instructions with with secure instruction interception code. Just in case future firmware w

Re: [PATCH] travis.yml: Run tcg tests with tci

On 28/11/2019 11.16, Alex Bennée wrote: Thomas Huth writes: On 27/11/2019 19.38, Alex Bennée wrote: Thomas Huth writes: So far we only have compile coverage for tci. But since commit 2f160e0f9797c7522bfd0d09218d0c9340a5137c ("tci: Add implementation for INDEX_op_ld16u_i64") has been inclu

Re: [PATCH v37 00/17] QEMU AVR 8 bit cores

I don't see why you say that the peripherals are inside the chip, there is CPU within target/avr directory and then there are some peripherals in hw directory, CPU does not depend on them. what am I missing? On Thu, Nov 28, 2019 at 3:22 PM Aleksandar Markovic < aleksandar.m.m...@gmail.com> wrote:

Re: [PATCH v37 00/17] QEMU AVR 8 bit cores

On 11/28/19 2:25 PM, Michael Rolnik wrote: I don't see why you say that the peripherals are inside the chip, there is CPU within target/avr directory and then there are some peripherals in hw directory, CPU does not depend on them. what am I missing? On Thu, Nov 28, 2019 at 3:22 PM Aleksandar

Re: [PATCH v1 1/1] pc-bios/s390-ccw: fix sclp_get_loadparm_ascii

On Thu, 28 Nov 2019 13:33:57 +0100 Claudio Imbrenda wrote: > The existing s390 bios gets the LOADPARM information from the system using > an SCLP call that specifies a buffer length too small to contain all the > output. > > The recent fixes in the SCLP code have exposed this bug, since now the

Re: [PATCH v37 00/17] QEMU AVR 8 bit cores

On Thursday, November 28, 2019, Michael Rolnik wrote: > I don't see why you say that the peripherals are inside the chip, there is > CPU within target/avr directory and then there are some peripherals in hw > directory, CPU does not depend on them. what am I missing? > >> >> I meant these periphe

Re: [PATCH v37 00/17] QEMU AVR 8 bit cores

On Thursday, November 28, 2019, Michael Rolnik wrote: > > > On Wed, Nov 27, 2019 at 11:06 PM Aleksandar Markovic < > aleksandar.m.m...@gmail.com> wrote: > >> On Wed, Nov 27, 2019 at 6:53 PM Michael Rolnik wrote: >> > >> > This series of patches adds 8bit AVR cores to QEMU. >> > All instruction,

[PATCH 1/7] target/ppc: Implement the VTB for HV access

From: Suraj Jitindar Singh The virtual timebase register (VTB) is a 64-bit register which increments at the same rate as the timebase register, present on POWER8 and later processors. The register is able to be read/written by the hypervisor and read by the supervisor. All other accesses are ill

Re: [PATCH V2] block/nbd: fix memory leak in nbd_open()

On Thu, Nov 28, 2019 at 08:09:31PM +0800, pannengy...@huawei.com wrote: > From: PanNengyuan > > In currently implementation there will be a memory leak when > nbd_client_connect() returns error status. Here is an easy way to > reproduce: > > 1. run qemu-iotests as follow and check the result wit

[PATCH 3/7] target/ppc: Add SPR ASDR

From: Suraj Jitindar Singh The Access Segment Descriptor Register (ASDR) provides information about the storage element when taking a hypervisor storage interrupt. When performing nested radix address translation, this is normally the guest real address. This register is present on POWER9 process

Re: [PATCH v37 00/17] QEMU AVR 8 bit cores

On Thursday, November 28, 2019, Philippe Mathieu-Daudé wrote: > On 11/28/19 2:25 PM, Michael Rolnik wrote: > >> I don't see why you say that the peripherals are inside the chip, there >> is CPU within target/avr directory and then there are some peripherals in >> hw directory, CPU does not depend

[PATCH 2/7] target/ppc: Work [S]PURR implementation and add HV support

From: Suraj Jitindar Singh The Processor Utilisation of Resources Register (PURR) and Scaled Processor Utilisation of Resources Register (SPURR) provide an estimate of the resources used by the thread, present on POWER7 and later processors. Currently the [S]PURR registers simply count at the ra

  1   2   3   >