Re: [Qemu-devel] [PATCH v10 5/6] s390x/vfio: ap: Introduce VFIO AP device

On 10/09/2018 03:51 PM, David Hildenbrand wrote: +static void vfio_ap_realize(DeviceState *dev, Error **errp) +{ +int ret; +char *mdevid; +Error *local_err = NULL; +VFIOGroup *vfio_group; +APDevice *apdev = AP_DEVICE(dev); +VFIOAPDevice *vapdev = VFIO_AP_DEVICE(apdev); +

Re: [Qemu-devel] [PATCH] util: aio-posix: fix a typo

On Sun, Oct 07, 2018 at 07:16:12PM -0700, Li Qiang wrote: > Cc: qemu-triv...@nongnu.org > Signed-off-by: Li Qiang > --- > util/aio-posix.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Thanks, applied to my block tree: https://github.com/stefanha/qemu/commits/block Stefan signature.

Re: [Qemu-devel] [qemu-s390x] [PATCH v10 5/6] s390x/vfio: ap: Introduce VFIO AP device

On 10/10/2018 04:25 AM, Thomas Huth wrote: On 2018-10-09 19:52, Tony Krowiak wrote: Introduces a VFIO based AP device. The device is defined via the QEMU command line by specifying: -device vfio-ap,sysfsdev= There may be only one vfio-ap device configured for a guest. The mediated matrix

Re: [Qemu-devel] [qemu-s390x] [PATCH v10 5/6] s390x/vfio: ap: Introduce VFIO AP device

On 10/10/2018 04:52 AM, Cornelia Huck wrote: On Wed, 10 Oct 2018 10:25:22 +0200 Thomas Huth wrote: On 2018-10-09 19:52, Tony Krowiak wrote: [...] +static VFIOGroup *vfio_ap_get_group(VFIOAPDevice *vapdev, Error **errp) +{ +GError *gerror; +char *symlink, *group_path; +int group

Re: [Qemu-devel] [PATCH v10 4/6] s390x/ap: base Adjunct Processor (AP) object model

On Wed, 10 Oct 2018 09:59:55 -0400 Tony Krowiak wrote: > On 10/10/2018 04:14 AM, Cornelia Huck wrote: > > On Tue, 9 Oct 2018 13:52:24 -0400 > > Tony Krowiak wrote: > > > >> diff --git a/hw/s390x/ap-device.c b/hw/s390x/ap-device.c > >> new file mode 100644 > >> index ..fb6e35024c8

Re: [Qemu-devel] [PATCH v2 4/7] scripts/qemu.py: set predefined machine type based on arch

On 10/10/18 9:59 AM, Cleber Rosa wrote: > > > On 10/10/18 9:46 AM, Eduardo Habkost wrote: >> On Wed, Oct 10, 2018 at 08:35:38AM -0400, Cleber Rosa wrote: >>> >>> >>> On 10/10/18 7:00 AM, Philippe Mathieu-Daudé wrote: On 10/10/2018 01:26, Cleber Rosa wrote: > Some targets require a mac

Re: [Qemu-devel] [PATCH v10 5/6] s390x/vfio: ap: Introduce VFIO AP device

On 10/10/2018 08:49 AM, Christian Borntraeger wrote: On 10/10/2018 02:37 PM, Pierre Morel wrote: On 09/10/2018 19:52, Tony Krowiak wrote: +static VFIOGroup *vfio_ap_get_group(VFIOAPDevice *vapdev, Error **errp) +{ +GError *gerror; +char *symlink, *group_path; +int groupid; + +

Re: [Qemu-devel] [PATCH] target/i386: Remove #ifdeffed-out icebp debugging hack

On 10/9/18 11:33 AM, Peter Maydell wrote: > Remove a debugging hack which could be used to cause the > undocumented 'icebp' instruction to enable QEMU internal > debug logging. This code has always been #ifdeffed out > since it was introduced in commit aba9d61e34b9 in 2005; > judging by the rest of

Re: [Qemu-devel] [qemu-s390x] [PATCH v10 6/6] s390: doc: detailed specifications for AP virtualization

On 10/10/2018 04:14 AM, Thomas Huth wrote: On 2018-10-09 19:52, Tony Krowiak wrote: This patch provides documentation describing the AP architecture and design concepts behind the virtualization of AP devices. It also includes an example of how to configure AP devices for exclusive use of KVM gu

Re: [Qemu-devel] [PATCH] coccinelle: new inplace-byteswaps.cocci to remove inplace-byteswapping calls

On 10/9/18 11:16 AM, Peter Maydell wrote: > Add a new Coccinelle script which replaces uses of the inplace > byteswapping functions *_to_cpus() and cpu_to_*s() with their > not-in-place equivalents. This is useful for where the swapping > is done on members of a packed struct -- taking the address

Re: [Qemu-devel] [PATCH v2 4/7] scripts/qemu.py: set predefined machine type based on arch

On Wed, Oct 10, 2018 at 10:15:15AM -0400, Cleber Rosa wrote: > > > On 10/10/18 9:59 AM, Cleber Rosa wrote: > > > > > > On 10/10/18 9:46 AM, Eduardo Habkost wrote: > >> On Wed, Oct 10, 2018 at 08:35:38AM -0400, Cleber Rosa wrote: > >>> > >>> > >>> On 10/10/18 7:00 AM, Philippe Mathieu-Daudé wrot

[Qemu-devel] [Bug 1793119] Re: Wrong floating-point emulation on AArch64 with FPCR set to zero

** Changed in: qemu Status: Confirmed => Fix Committed -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1793119 Title: Wrong floating-point emulation on AArch64 with FPCR set to zero Status in

[Qemu-devel] [PATCH 0/4] some TCG fixes

The first patch we've seen before -- I'm taking it from the atomic interrupt_request series. The other three patches are related to TCG profiling. One of them is a build fix that I suspect has gone unnoticed due to its dependence on CONFIG_PROFILER. The series is checkpatch-clean. You can fetch i

[Qemu-devel] [PATCH 2/4] tcg: fix use of uninitialized variable under CONFIG_PROFILER

We forgot to initialize n in commit 15fa08f845 ("tcg: Dynamically allocate TCGOps", 2017-12-29). Signed-off-by: Emilio G. Cota --- tcg/tcg.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tcg/tcg.c b/tcg/tcg.c index f27b22bd3c..8f26916b99 100644 --- a/tcg/tcg.c +++ b/tcg/tcg

[Qemu-devel] [PATCH 4/4] tcg: distribute tcg_time into TCG contexts

When we implemented per-vCPU TCG contexts, we forgot to also distribute the tcg_time counter, which has remained as a global accessed without any serialization, leading to potentially missed counts. Fix it by distributing the field over the TCG contexts, embedding it into TCGProfile with a field c

[Qemu-devel] [PATCH 1/4] tcg: access cpu->icount_decr.u16.high with atomics

Consistently access u16.high with atomics to avoid undefined behaviour in MTTCG. Note that icount_decr.u16.low is only used in icount mode, so regular accesses to it are OK. Reviewed-by: Richard Henderson Signed-off-by: Emilio G. Cota --- accel/tcg/tcg-all.c | 2 +- accel/tcg/translate-a

[Qemu-devel] [Bug 1481272] Re: main-loop: WARNING: I/O thread spun for 1000 iterations

I see the same issue with qemu version 2.5.0 (Debian 1:2.5+dfsg- 5ubuntu10.31). -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1481272 Title: main-loop: WARNING: I/O thread spun for 1000 iterations

[Qemu-devel] [Bug 1793119] Re: Wrong floating-point emulation on AArch64 with FPCR set to zero

Thanks a lot :-) -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1793119 Title: Wrong floating-point emulation on AArch64 with FPCR set to zero Status in QEMU: Fix Committed Bug description: On

[Qemu-devel] [PATCH 3/4] tcg: plug holes in struct TCGProfile

This plugs two 4-byte holes in 64-bit. Signed-off-by: Emilio G. Cota --- tcg/tcg.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tcg/tcg.h b/tcg/tcg.h index f9f12378e9..d80ef2a883 100644 --- a/tcg/tcg.h +++ b/tcg/tcg.h @@ -633,8 +633,8 @@ typedef struct TCGProfile { in

Re: [Qemu-devel] [PATCH v4 09/11] qga-win: handle multi-disk volumes

On Sun, 7 Oct 2018 15:13:26 +0300 Sameeh Jubran wrote: > I did a quick scan for the documentation and the code and it seems that the > name format that you're looking for is provided by the "QueryDosDeviceW" > function. The function returns multiple names and in the current code we > only check t

Re: [Qemu-devel] [Qemu-arm] [RFC PATCH] hw: arm: Add basic support for cprman (clock subsystem)

On Wed, Oct 10, 2018 at 03:25:22PM +0200, Philippe Mathieu-Daudé wrote: > Hi Guenter, > > On Tue, Jul 17, 2018 at 6:08 AM Guenter Roeck wrote: > > > > On 07/16/2018 06:53 PM, Philippe Mathieu-Daudé wrote: > > > Hi Guenter, > > > > > > On 07/15/2018 07:06 PM, Guenter Roeck wrote: > > >> Add basic

Re: [Qemu-devel] [PATCH v5 02/11] qom: don't require user creatable objects to be registered

On 09/10/2018 15:04, Daniel P. Berrangé wrote: > When an object is in turn owned by another user object, it is not > desirable to expose this in the QOM object hierarchy, as it is > just an internal implementation detail, we should be free to change > without exposure. > > Signed-off-by: Daniel P.

Re: [Qemu-devel] [PATCH v5 04/11] hw/usb: fix const-ness for string params in MTP driver

On 09/10/2018 15:04, Daniel P. Berrangé wrote: > Various functions accepting 'char *' string parameters were missing > 'const' qualifiers. > > Signed-off-by: Daniel P. Berrangé Reviewed-by: Philippe Mathieu-Daudé > --- > hw/usb/dev-mtp.c | 8 > 1 file changed, 4 insertions(+), 4 dele

Re: [Qemu-devel] [PATCH 2/4] tcg: fix use of uninitialized variable under CONFIG_PROFILER

On 10/10/2018 16:48, Emilio G. Cota wrote: > We forgot to initialize n in commit 15fa08f845 ("tcg: Dynamically > allocate TCGOps", 2017-12-29). > > Signed-off-by: Emilio G. Cota Reviewed-by: Philippe Mathieu-Daudé > --- > tcg/tcg.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > >

Re: [Qemu-devel] [PATCH v2 4/7] scripts/qemu.py: set predefined machine type based on arch

On 10/10/2018 16:28, Eduardo Habkost wrote: > On Wed, Oct 10, 2018 at 10:15:15AM -0400, Cleber Rosa wrote: >> >> >> On 10/10/18 9:59 AM, Cleber Rosa wrote: >>> >>> >>> On 10/10/18 9:46 AM, Eduardo Habkost wrote: On Wed, Oct 10, 2018 at 08:35:38AM -0400, Cleber Rosa wrote: > > > On

Re: [Qemu-devel] [PATCH v2 4/7] scripts/qemu.py: set predefined machine type based on arch

On Wed, Oct 10, 2018 at 11:28:40AM -0300, Eduardo Habkost wrote: > On Wed, Oct 10, 2018 at 10:15:15AM -0400, Cleber Rosa wrote: > > > > > > On 10/10/18 9:59 AM, Cleber Rosa wrote: > > > > > > > > > On 10/10/18 9:46 AM, Eduardo Habkost wrote: > > >> On Wed, Oct 10, 2018 at 08:35:38AM -0400, Cleb

Re: [Qemu-devel] OpenBSD with VirtIO networking causes QEMU to crash

On 10/10/2018 8:29 AM, viq wrote: On Wed, Oct 10, 2018 at 1:54 PM Brad Smith > wrote: On 10/9/2018 2:42 PM, viq wrote: > (please CC me as I'm not subscribed to the list) > I verified the behaviour on two different machines, both running archlinux >

Re: [Qemu-devel] OpenBSD with VirtIO networking causes QEMU to crash

On Wed, Oct 10, 2018 at 5:35 PM Brad Smith wrote: > On 10/10/2018 8:29 AM, viq wrote: > > On Wed, Oct 10, 2018 at 1:54 PM Brad Smith wrote: > >> On 10/9/2018 2:42 PM, viq wrote: >> >> > (please CC me as I'm not subscribed to the list) >> > I verified the behaviour on two different machines, both

Re: [Qemu-devel] [PATCH v2 4/7] scripts/qemu.py: set predefined machine type based on arch

On 10/10/18 10:28 AM, Eduardo Habkost wrote: > On Wed, Oct 10, 2018 at 10:15:15AM -0400, Cleber Rosa wrote: >> >> >> On 10/10/18 9:59 AM, Cleber Rosa wrote: >>> >>> >>> On 10/10/18 9:46 AM, Eduardo Habkost wrote: On Wed, Oct 10, 2018 at 08:35:38AM -0400, Cleber Rosa wrote: > > >

Re: [Qemu-devel] [PATCH v10 5/6] s390x/vfio: ap: Introduce VFIO AP device

On 10/10/2018 05:21 AM, Cornelia Huck wrote: On Tue, 9 Oct 2018 13:52:25 -0400 Tony Krowiak wrote: diff --git a/MAINTAINERS b/MAINTAINERS index 97e8ed808bc0..29041da69237 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1209,6 +1209,7 @@ F: hw/s390x/ap-device.c F: hw/s390x/ap-bridge.c F: i

Re: [Qemu-devel] [PATCH v2 4/7] scripts/qemu.py: set predefined machine type based on arch

On 10/10/18 11:26 AM, Philippe Mathieu-Daudé wrote: > On 10/10/2018 16:28, Eduardo Habkost wrote: >> On Wed, Oct 10, 2018 at 10:15:15AM -0400, Cleber Rosa wrote: >>> >>> >>> On 10/10/18 9:59 AM, Cleber Rosa wrote: On 10/10/18 9:46 AM, Eduardo Habkost wrote: > On Wed, Oct 10, 2

Re: [Qemu-devel] [PATCH v7 00/19] Fixing record/replay and adding reverse debugging

Hi Pavel, Please do not CC me in this series, this isn’t anyhow relevant for me anymore. Regards, Alex ср, 10 окт. 2018 г. в 16:30, Pavel Dovgalyuk : > GDB remote protocol supports reverse debugging of the targets. > It includes 'reverse step' and 'reverse continue' operations. > The first one

Re: [Qemu-devel] [PATCH v2 4/7] scripts/qemu.py: set predefined machine type based on arch

On 10/10/18 11:31 AM, Daniel P. Berrangé wrote: > On Wed, Oct 10, 2018 at 11:28:40AM -0300, Eduardo Habkost wrote: >> On Wed, Oct 10, 2018 at 10:15:15AM -0400, Cleber Rosa wrote: >>> >>> >>> On 10/10/18 9:59 AM, Cleber Rosa wrote: On 10/10/18 9:46 AM, Eduardo Habkost wrote: >

Re: [Qemu-devel] [PATCH v2 4/7] scripts/qemu.py: set predefined machine type based on arch

On 10/10/2018 17:58, Cleber Rosa wrote: > > > On 10/10/18 11:26 AM, Philippe Mathieu-Daudé wrote: >> On 10/10/2018 16:28, Eduardo Habkost wrote: >>> On Wed, Oct 10, 2018 at 10:15:15AM -0400, Cleber Rosa wrote: On 10/10/18 9:59 AM, Cleber Rosa wrote: > > > On 10/10/18 9:

[Qemu-devel] [PATCH] machine: fix a typo

Cc: qemu-triv...@nongnu.org Signed-off-by: Li Qiang --- hw/core/machine.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/hw/core/machine.c b/hw/core/machine.c index 1987557833..da50ad6de7 100644 --- a/hw/core/machine.c +++ b/hw/core/machine.c @@ -636,7 +636,7 @@ static void m

Re: [Qemu-devel] [PATCH v2 4/7] scripts/qemu.py: set predefined machine type based on arch

On 10 October 2018 at 16:47, Cleber Rosa wrote: > To make sure we're on the same page, we're still going to have default > machine types, based on the arch, for those targets that don't provide > one (aarch64 is one example). Right? Does it make sense to define a default? The reason arm doesn't

Re: [Qemu-devel] [PATCH v9 0/6] monitor: enable OOB by default

On 10/9/18 1:27 AM, Peter Xu wrote: Based-on: <20180828191048.29806-1-arm...@redhat.com> Based-on: <2018090716.1675-1-arm...@redhat.com> (this series is based on Markus's monitor-next tree) v9: - add r-bs - release the qmp queue lock before resume [Marc-Andre] I haven't reviewed closely,

Re: [Qemu-devel] [Spice-devel] [RFC PATCH spice 1/2] QXL interface: add functions to identify monitors in the guest

On Tue, 2018-10-09 at 14:33 -0500, Jonathon Jongsma wrote: > On Tue, 2018-10-09 at 15:10 +0200, Lukáš Hrázký wrote: > > Adds two functions to let QEMU provide information to identify > > graphics > > devices and their monitors in the guest: > > > > * device path - The path identifying the device o

Re: [Qemu-devel] [PATCH v2 7/7] block/qcow2-refcount: fix out-of-file L2 entries to be read-as-zero

17.08.2018 15:22, Vladimir Sementsov-Ogievskiy wrote: > Rewrite corrupted L2 table entry, which reference space out of > underlying file. > > Make this L2 table entry read-as-all-zeros without any allocation. > > Signed-off-by: Vladimir Sementsov-Ogievskiy > --- > block/qcow2-refcount.c | 32 +++

Re: [Qemu-devel] [PATCH] ide: piix: convert constant device name to MACRO

On 10/10/2018 12:29 AM, Li Qiang wrote: > Signed-off-by: Li Qiang > --- > hw/ide/piix.c | 16 ++-- > 1 file changed, 10 insertions(+), 6 deletions(-) > > diff --git a/hw/ide/piix.c b/hw/ide/piix.c > index a3afe1f..5f29cce 100644 > --- a/hw/ide/piix.c > +++ b/hw/ide/piix.c > @@ -35

Re: [Qemu-devel] [PATCH] machine: fix a typo

Reviewed-by: Stefano Garzarella Il giorno mer 10 ott 2018 alle ore 18:11 Li Qiang ha scritto: > Cc: qemu-triv...@nongnu.org > Signed-off-by: Li Qiang > --- > hw/core/machine.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/hw/core/machine.c b/hw/core/machine.c > inde

Re: [Qemu-devel] [PULL 3/5] tests: Restore check-qdict unit test

On 10/10/18 1:11 AM, Markus Armbruster wrote: Commit 0bcc8e5bd8d accidentally dropped check-qdict from the list of unit tests (again, see commit 4429532b48a). Put it back, and fix up the test. Since this seems to be a recurring problem... +++ b/tests/Makefile.include @@ -40,7 +40,7 @@ SYSEMU

Re: [Qemu-devel] [PATCH v2 7/7] block/qcow2-refcount: fix out-of-file L2 entries to be read-as-zero

10.10.2018 19:39, Vladimir Sementsov-Ogievskiy wrote: > 17.08.2018 15:22, Vladimir Sementsov-Ogievskiy wrote: >> Rewrite corrupted L2 table entry, which reference space out of >> underlying file. >> >> Make this L2 table entry read-as-all-zeros without any allocation. >> >> Signed-off-by: Vladimir

Re: [Qemu-devel] [PULL 3/5] tests: Restore check-qdict unit test

On 10/10/2018 18:43, Eric Blake wrote: > On 10/10/18 1:11 AM, Markus Armbruster wrote: >> Commit 0bcc8e5bd8d accidentally dropped check-qdict from the list of >> unit tests (again, see commit 4429532b48a).  Put it back, and fix up >> the test. > > Since this seems to be a recurring problem... > >

Re: [Qemu-devel] [PATCH v2 7/7] block/qcow2-refcount: fix out-of-file L2 entries to be read-as-zero

10.10.2018 19:55, Vladimir Sementsov-Ogievskiy wrote: > 10.10.2018 19:39, Vladimir Sementsov-Ogievskiy wrote: >> 17.08.2018 15:22, Vladimir Sementsov-Ogievskiy wrote: >>> Rewrite corrupted L2 table entry, which reference space out of >>> underlying file. >>> >>> Make this L2 table entry read-as-all

Re: [Qemu-devel] [PATCH v5 03/11] hw/usb: don't set IN_ISDIR for inotify watch in MTP driver

On 09/10/2018 15:04, Daniel P. Berrangé wrote: > IN_ISDIR is not a bit that one can request when registering a > watch with inotify_add_watch. Rather it is a bit that is set > automatically when reading events from the kernel. > > Signed-off-by: Daniel P. Berrangé Reviewed-by: Philippe Mathieu-D

[Qemu-devel] [PATCH v11 2/6] s390x/cpumodel: Set up CPU model for AP device support

A new CPU model feature and two new CPU model facilities are introduced to support AP devices for a KVM guest. CPU model features: 1. The S390_FEAT_AP CPU model feature indicates whether AP instructions are available to the guest. This feature will be enabled only if the AP instructions are

[Qemu-devel] [PATCH v11 0/6] s390x: vfio-ap: guest dedicated crypto adapters

This patch series is the QEMU counterpart to the KVM/kernel support for guest dedicated crypto adapters. The KVM/kernel model is built on the VFIO mediated device framework and provides the infrastructure for granting exclusive guest access to crypto devices installed on the linux host. This pa

[Qemu-devel] [PATCH v11 3/6] s390x/kvm: enable AP instruction interpretation for guest

Let's use the KVM_SET_DEVICE_ATTR ioctl to enable hardware interpretation of AP instructions executed on the guest. If the S390_FEAT_AP feature is switched on for the guest, AP instructions must be interpreted by default; otherwise, they will be intercepted. This attribute setting may be overridde

[Qemu-devel] [PATCH v11 1/6] linux-headers: linux header updates for AP support

Updates the linux header files in preparation for introduction of the VFIO AP device: * Added device attributes to the KVM_S390_VM_CRYPTO group to indicate whether AP instructions are to be interpreted * Added VFIO device information for AP devices Signed-off-by: Tony Krowiak --- linux-heade

[Qemu-devel] [PATCH v11 6/6] s390: doc: detailed specifications for AP virtualization

This patch provides documentation describing the AP architecture and design concepts behind the virtualization of AP devices. It also includes an example of how to configure AP devices for exclusive use of KVM guests. Signed-off-by: Tony Krowiak Reviewed-by: Pierre Morel Tested-by: Pierre Morel -

[Qemu-devel] [PATCH v11 4/6] s390x/ap: base Adjunct Processor (AP) object model

Introduces the base object model for virtualizing AP devices. Signed-off-by: Tony Krowiak Tested-by: Pierre Morel Acked-by: David Hildenbrand Reviewed-by: Thomas Huth Reviewed-by: Halil Pasic --- MAINTAINERS | 12 ++ hw/s390x/Makefile.objs | 2 + hw/s390x/ap-bridge

[Qemu-devel] [PATCH v11 5/6] s390x/vfio: ap: Introduce VFIO AP device

Introduces a VFIO based AP device. The device is defined via the QEMU command line by specifying: -device vfio-ap,sysfsdev= There may be only one vfio-ap device configured for a guest. The mediated matrix device is created by the VFIO AP device driver by writing a UUID to a sysfs attribute f

Re: [Qemu-devel] [PATCH v4 11/11] qga-win: demystify namespace striping

On 10/4/18 8:20 AM, Marc-André Lureau wrote: Hi On Thu, Oct 4, 2018 at 3:22 PM Tomáš Golembiovský wrote: It was not obvious what exactly the cryptic string copying does to the GUID. This change makes the intent clearer. In the subject line, s/striping/stripping/ (this is about performing a

Re: [Qemu-devel] [PATCH v5 0/5] Connect a PCIe host and graphics support to RISC-V

>So it looks like you at least got to the point where the guest OS >would find PCIe devices... Yes and in fact NVMe IO against those devices do succeed (I can write and read the NVMe namespaces). It is just slow because the interrupts are not getting to the OS and hence NVMe timeouts are

Re: [Qemu-devel] [PATCH v5 0/5] Connect a PCIe host and graphics support to RISC-V

>> I plan to also try with a e1000 network interface model tomorrow and see how >> that behaves > >Please do :) I added e1000 and e1000e support to my kernel and changed the QEMU command to: $QEMU -nographic \ -machine virt \ -smp 1 -m 8G \ -append "console=hvc0

Re: [Qemu-devel] [PATCH] sdl2: Support all virtio-gpu formats

On 10.10.18 12:10, Gerd Hoffmann wrote: > On Mon, Oct 08, 2018 at 08:50:13PM +0200, Max Reitz wrote: >> There are some 2D resource formats that can be used through virtio-gpu, > > Ahem, not really. XRGB is the only one which works in practice, and > virtio-gpu kms driver will stop advertising any

Re: [Qemu-devel] [PATCH v1 0/5] Misc RISC-V patches

On Mon, 08 Oct 2018 11:25:07 PDT (-0700), alistair.fran...@wdc.com wrote: These are some patches that I have cherry picked from Michael's RISC-V tree that are ready to be applied. Unless anyone has any comments against these I'll send a PR later this week. Michael Clark (5): RISC-V: Allow sett

Re: [Qemu-devel] [PATCH v2 4/7] scripts/qemu.py: set predefined machine type based on arch

On 10/10/18 12:23 PM, Peter Maydell wrote: > On 10 October 2018 at 16:47, Cleber Rosa wrote: >> To make sure we're on the same page, we're still going to have default >> machine types, based on the arch, for those targets that don't provide >> one (aarch64 is one example). Right? > > Does it

Re: [Qemu-devel] [PATCH] sdl2: Support all virtio-gpu formats

On 10.10.18 19:35, Max Reitz wrote: > On 10.10.18 12:10, Gerd Hoffmann wrote: >> On Mon, Oct 08, 2018 at 08:50:13PM +0200, Max Reitz wrote: >>> There are some 2D resource formats that can be used through virtio-gpu, >> >> Ahem, not really. XRGB is the only one which works in practice, and >> virti

Re: [Qemu-devel] [PATCH v5 0/5] Connect a PCIe host and graphics support to RISC-V

On 10/10/2018 05:26 AM, Andrea Bolognani wrote: On Thu, 2018-10-04 at 20:06 +, Alistair Francis wrote: Alistair Francis (5): hw/riscv/virt: Increase the number of interrupts hw/riscv/virt: Connect the gpex PCIe riscv: Enable VGA and PCIE_VGA hw/riscv/sifive_u: Connect the Xilinx

Re: [Qemu-devel] [PATCH v5 0/5] Connect a PCIe host and graphics support to RISC-V

On 10/10/2018 10:32 AM, Stephen Bates wrote: I plan to also try with a e1000 network interface model tomorrow and see how that behaves Please do :) I added e1000 and e1000e support to my kernel and changed the QEMU command to: $QEMU -nographic \ -machine virt \

[Qemu-devel] [Bug 1795527] Re: Malformed audio and video output stuttering after upgrade to QEMU 3.0

OK, so in that case you'll need to do a git bisect to figure out what the first change was that broke it. If 3.0 is at one end and is bad, pick the last known good version (on the problem that you can reliably repeat) and do the bisect between them - if we're lucky we'll land on something obviou

Re: [Qemu-devel] [PATCH v2 4/7] scripts/qemu.py: set predefined machine type based on arch

On 10 October 2018 at 18:52, Cleber Rosa wrote: > > > On 10/10/18 12:23 PM, Peter Maydell wrote: >> On 10 October 2018 at 16:47, Cleber Rosa wrote: >>> To make sure we're on the same page, we're still going to have default >>> machine types, based on the arch, for those targets that don't provide

Re: [Qemu-devel] [PATCH v2 4/7] scripts/qemu.py: set predefined machine type based on arch

On 10/10/18 12:08 PM, Philippe Mathieu-Daudé wrote: > On 10/10/2018 17:58, Cleber Rosa wrote: >> >> >> On 10/10/18 11:26 AM, Philippe Mathieu-Daudé wrote: >>> On 10/10/2018 16:28, Eduardo Habkost wrote: On Wed, Oct 10, 2018 at 10:15:15AM -0400, Cleber Rosa wrote: > > > On 10/10/

Re: [Qemu-devel] [PATCH v1 0/5] Misc RISC-V patches

On 10 October 2018 at 18:49, Palmer Dabbelt wrote: > we should really > get the ball rolling on our big patch backlog. Yes, please do. Softfreeze is not all that far away and I would strongly prefer not to get an enormous sized pull request at the last minute. The ideal pattern is that code chang

Re: [Qemu-devel] [PATCH v1 0/5] Misc RISC-V patches

On 10/10/2018 11:10 AM, Peter Maydell wrote: On 10 October 2018 at 18:49, Palmer Dabbelt wrote: we should really get the ball rolling on our big patch backlog. Yes, please do. Softfreeze is not all that far away and I would strongly prefer not to get an enormous sized pull request at the l

Re: [Qemu-devel] [PATCH v11 0/6] s390x: vfio-ap: guest dedicated crypto adapters

On 10/10/2018 07:03 PM, Tony Krowiak wrote: > This patch series is the QEMU counterpart to the KVM/kernel support for > guest dedicated crypto adapters. The KVM/kernel model is built on the > VFIO mediated device framework and provides the infrastructure for > granting exclusive guest access t

Re: [Qemu-devel] [PATCH v1 0/5] Misc RISC-V patches

On Wed, 10 Oct 2018 11:10:07 PDT (-0700), peter.mayd...@linaro.org wrote: On 10 October 2018 at 18:49, Palmer Dabbelt wrote: we should really get the ball rolling on our big patch backlog. Yes, please do. Softfreeze is not all that far away and I would strongly prefer not to get an enormous s

Re: [Qemu-devel] [PATCH v5 0/5] Connect a PCIe host and graphics support to RISC-V

>Why do you need two networking options? I don't need the e1000 for networking. The e1000 option is there to test the PCIe since it implements a PCIe model of the e1000 NIC. Basically it's another test path for your PCIe patches and was used for testing when PCIe support to the arm virt mod

[Qemu-devel] [PATCH 1/1] hw/arm/virt: provide a model property in the fdt

Device trees in the Linux kernel generally provide a model property. Some software like the Debian flash-kernel package rely on this property to identify boards. The patch sets the model property for the virt boards to 'QEMU virt'. Signed-off-by: Heinrich Schuchardt --- hw/arm/virt.c | 1 + 1 f

Re: [Qemu-devel] [PATCH] memory: move MemoryRegion::size cleanup to memory_region_finalize()

On 09/10/2018 19:09, Laszlo Ersek wrote: >>memory_region_size() != 0 >> and therefore it's ok to access it in >>file_backend_unparent() >> if (memory_region_size() != 0) >> memory_region_get_ram_ptr() >> >> which happens when object_add fails and unparents failed backend mak

Re: [Qemu-devel] [PATCH v5 0/5] Connect a PCIe host and graphics support to RISC-V

> I added e1000 and e1000e support to my kernel and changed the QEMU command to: So using -device e1000e rather than -device e1000 seems to work. I am not sure why -device e1000 causes a kernel panic. The MSI-X message is interesting and may be related to why NVMe interrupts are not reaching the

Re: [Qemu-devel] [RFC 1/2] migration: Stop postcopy fault thread before notifying

* Ilya Maximets (i.maxim...@samsung.com) wrote: > POSTCOPY_NOTIFY_INBOUND_END handlers will remove userfault fds > from the postcopy_remote_fds array which could be still in > use by the fault thread. Let's stop the thread before > notification to avoid possible accessing wrong memory. OK I think;

Re: [Qemu-devel] [PATCH] memory: move MemoryRegion::size cleanup to memory_region_finalize()

On 10/10/18 20:56, Paolo Bonzini wrote: > On 09/10/2018 19:09, Laszlo Ersek wrote: >>>memory_region_size() != 0 >>> and therefore it's ok to access it in >>>file_backend_unparent() >>> if (memory_region_size() != 0) >>> memory_region_get_ram_ptr() >>> >>> which happens when

Re: [Qemu-devel] [RFC 2/2] vhost-user: Fix userfaultfd leak

* Ilya Maximets (i.maxim...@samsung.com) wrote: > 'fd' received from the vhost side is never freed. > Also, everything (including 'postcopy_listen' state) should be > cleaned up on vhost cleanup. > > Fixes: 46343570c06e ("vhost+postcopy: Wire up POSTCOPY_END notify") > Fixes: f82c11165ffa ("vhost+

Re: [Qemu-devel] [PATCH v1 5/5] RISC-V: Don't add NULL bootargs to device-tree

On 08/10/2018 20:25, Alistair Francis wrote: > From: Michael Clark > > Cc: Palmer Dabbelt > Cc: Alistair Francis > Signed-off-by: Michael Clark > Reviewed-by: Alistair Francis Reviewed-by: Philippe Mathieu-Daudé > --- > hw/riscv/sifive_u.c | 4 +++- > hw/riscv/spike.c| 6 -- > hw/

Re: [Qemu-devel] [PATCH v1 2/5] RISC-V: Move non-ops from op_helper to cpu_helper

On 08/10/2018 20:25, Alistair Francis wrote: > From: Michael Clark > > This patch makes op_helper.c contain only instruction > operation helpers used by translate.c and moves any > unrelated cpu helpers into cpu_helper.c. No logic is > changed by this patch. > > Cc: Sagar Karandikar > Cc: Basti

Re: [Qemu-devel] [PATCH v1 4/5] RISC-V: Add missing free for plic_hart_config

On 08/10/2018 20:25, Alistair Francis wrote: > From: Michael Clark > > Cc: Palmer Dabbelt > Cc: Sagar Karandikar > Cc: Bastian Koppelmann > Cc: Alistair Francis > Signed-off-by: Michael Clark > Reviewed-by: Alistair Francis Reviewed-by: Philippe Mathieu-Daudé > --- > hw/riscv/virt.c | 2

Re: [Qemu-devel] [PATCH v9 0/6] monitor: enable OOB by default

On 10/10/18 11:26 AM, Eric Blake wrote: On 10/9/18 1:27 AM, Peter Xu wrote: Based-on: <20180828191048.29806-1-arm...@redhat.com> Based-on: <2018090716.1675-1-arm...@redhat.com> (this series is based on Markus's monitor-next tree) v9: - add r-bs - release the qmp queue lock before resume [M

Re: [Qemu-devel] [PATCH v5 0/5] Connect a PCIe host and graphics support to RISC-V

On 10/10/2018 11:47 AM, Stephen Bates wrote: Why do you need two networking options? I don't need the e1000 for networking. The e1000 option is there to test the PCIe since it implements a PCIe model of the e1000 NIC. Basically it's another test path for your PCIe patches and was used

Re: [Qemu-devel] [PATCH v2 4/7] scripts/qemu.py: set predefined machine type based on arch

On 10/10/18 2:07 PM, Peter Maydell wrote: > On 10 October 2018 at 18:52, Cleber Rosa wrote: >> >> >> On 10/10/18 12:23 PM, Peter Maydell wrote: >>> On 10 October 2018 at 16:47, Cleber Rosa wrote: To make sure we're on the same page, we're still going to have default machine types, ba

Re: [Qemu-devel] [PATCH v5 0/5] Connect a PCIe host and graphics support to RISC-V

On 10/10/2018 12:01 PM, Stephen Bates wrote: I added e1000 and e1000e support to my kernel and changed the QEMU command to: So using -device e1000e rather than -device e1000 seems to work. I am not sure why -device e1000 causes a kernel panic. The MSI-X message is interesting and may be rela

Re: [Qemu-devel] [PATCH v1 1/5] RISC-V: Allow setting and clearing multiple irqs

On Mon, 08 Oct 2018 11:25:17 PDT (-0700), alistair.fran...@wdc.com wrote: From: Michael Clark Change the API of riscv_set_local_interrupt to take a write mask and value to allow setting and clearing of multiple local interrupts atomically in a single call. Rename the new function to riscv_cpu_u

Re: [Qemu-devel] [PATCH v1 3/5] RISC-V: Update CSR and interrupt definitions

On Mon, 08 Oct 2018 11:25:36 PDT (-0700), alistair.fran...@wdc.com wrote: From: Michael Clark * Add user-mode CSR defininitions. * Reorder CSR definitions to match the specification. * Change H mode interrupt comment to 'reserved'. * Remove unused X_COP interrupt. * Add user-mode interrupts. *

Re: [Qemu-devel] [PATCH v1 5/5] RISC-V: Don't add NULL bootargs to device-tree

On Mon, 08 Oct 2018 11:25:56 PDT (-0700), alistair.fran...@wdc.com wrote: From: Michael Clark Cc: Palmer Dabbelt Cc: Alistair Francis Signed-off-by: Michael Clark Reviewed-by: Alistair Francis --- hw/riscv/sifive_u.c | 4 +++- hw/riscv/spike.c| 6 -- hw/riscv/virt.c | 4 +++- 3

Re: [Qemu-devel] [PATCH v1 2/5] RISC-V: Move non-ops from op_helper to cpu_helper

On Mon, 08 Oct 2018 11:25:27 PDT (-0700), alistair.fran...@wdc.com wrote: From: Michael Clark This patch makes op_helper.c contain only instruction operation helpers used by translate.c and moves any unrelated cpu helpers into cpu_helper.c. No logic is changed by this patch. Cc: Sagar Karandik

Re: [Qemu-devel] [PATCH v1 4/5] RISC-V: Add missing free for plic_hart_config

On Mon, 08 Oct 2018 11:25:45 PDT (-0700), alistair.fran...@wdc.com wrote: From: Michael Clark Cc: Palmer Dabbelt Cc: Sagar Karandikar Cc: Bastian Koppelmann Cc: Alistair Francis Signed-off-by: Michael Clark Reviewed-by: Alistair Francis --- hw/riscv/virt.c | 2 ++ 1 file changed, 2 inser

Re: [Qemu-devel] [PATCH v9 0/6] monitor: enable OOB by default

On 10/10/18 2:26 PM, Eric Blake wrote: On the other hand, when I'm trying to use a qemu binary with these patches applied, libvirt is hanging when trying to probe the capabilities of the binary, waiting for a response to "qmp_capabilities". I'll try and bisect which patch is causing the pro

Re: [Qemu-devel] [PATCH 26/31] tpm: Clean up error reporting in tpm_init_tpmdev()

On 10/8/18 1:31 PM, Markus Armbruster wrote: Calling error_report() in a function that takes an Error ** argument is suspicious. tpm_init_tpmdev() does that, and then fails without setting an error. Its caller main(), via tpm_init() and qemu_opts_foreach(), is fine with it, but clean it up anyw

Re: [Qemu-devel] [PATCH 1/1] i386: Add new model of Cascadelake-Server

On Wed, Oct 10, 2018 at 01:49:56AM +, Liu, Jingqi wrote: > Hi Eduardo/Paolo, > > Do you have any comments about this patch ? Thanks for the reminder and sorry for the delay. I was waiting for MSR features to be merged before including this CPU model. But considering that it's taking a while

[Qemu-devel] [PATCH v6 04/14] target/arm: Swap PMU values before/after migrations

Because of the PMU's design, many register accesses have side effects which are inter-related, meaning that the normal method of saving CP registers can result in inconsistent state. These side-effects are largely handled in *op_start and *op_finish functions which can be called globally once befor

[Qemu-devel] [PATCH v6 00/14] More fully implement ARM PMUv3

The ARM PMU implementation currently contains a basic cycle counter, but it is often useful to gather counts of other events, filter them based on execution mode, and/or be notified on counter overflow. These patches flesh out the implementations of various PMU registers including PM[X]EVCNTR and P

[Qemu-devel] [PATCH v6 08/14] target/arm: Implement PMOVSSET

Add an array for PMOVSSET so we only define it for v7ve+ platforms Signed-off-by: Aaron Lindsay --- target/arm/helper.c | 28 1 file changed, 28 insertions(+) diff --git a/target/arm/helper.c b/target/arm/helper.c index e804caaced..f3c00c3db0 100644 --- a/target/arm

[Qemu-devel] [PATCH v6 01/14] target/arm: Mark PMINTENCLR and PMINTENCLR_EL1 accesses as possibly doing IO

I previously fixed this for PMINTENSET_EL1, but missed these. Signed-off-by: Aaron Lindsay Signed-off-by: Aaron Lindsay --- target/arm/helper.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/target/arm/helper.c b/target/arm/helper.c index c83f7c1109..52c76b7444 100644

[Qemu-devel] [PATCH v6 07/14] target/arm: Allow AArch32 access for PMCCFILTR

Signed-off-by: Aaron Lindsay Reviewed-by: Peter Maydell --- target/arm/helper.c | 27 ++- 1 file changed, 26 insertions(+), 1 deletion(-) diff --git a/target/arm/helper.c b/target/arm/helper.c index 52bd13fdde..e804caaced 100644 --- a/target/arm/helper.c +++ b/target/arm

[Qemu-devel] [PATCH v6 11/14] target/arm: PMU: Add instruction and cycle events

The instruction event is only enabled when icount is used, cycles are always supported. Always defining get_cycle_count (but altering its behavior depending on CONFIG_USER_ONLY) allows us to remove some CONFIG_USER_ONLY #defines throughout the rest of the code. Signed-off-by: Aaron Lindsay Review

[Qemu-devel] [PATCH v6 09/14] target/arm: Add array for supported PMU events, generate PMCEID[01]

This commit doesn't add any supported events, but provides the framework for adding them. We store the pm_event structs in a simple array, and provide the mapping from the event numbers to array indexes in the supported_event_map array. Because the value of PMCEID[01] depends upon which events are

[Qemu-devel] [PATCH v6 02/14] target/arm: Mask PMOVSR writes based on supported counters

This is an amendment to my earlier patch: commit 7ece99b17e832065236c07a158dfac62619ef99b Author: Aaron Lindsay Date: Thu Apr 26 11:04:39 2018 +0100 target/arm: Mask PMU register writes based on PMCR_EL0.N Signed-off-by: Aaron Lindsay --- target/arm/helper.c | 1 + 1 file

[Qemu-devel] [PATCH v6 05/14] target/arm: Reorganize PMCCNTR accesses

pmccntr_read and pmccntr_write contained duplicate code that was already being handled by pmccntr_sync. Consolidate the duplicated code into two functions: pmccntr_op_start and pmccntr_op_finish. Add a companion to c15_ccnt in CPUARMState so that we can simultaneously save both the architectural re

<    1   2   3   >