Re: [Qemu-devel] [qemu RFC] qapi: add "firmware.json"

On 04/10/18 11:34, Daniel P. Berrangé wrote: > On Tue, Apr 10, 2018 at 11:16:01AM +0200, Laszlo Ersek wrote: >> On 04/10/18 08:27, Gerd Hoffmann wrote: >>> Hi, >>> - I considered adding wildcards (say, blacklist "all" i440fx machtypes, present and future, for SMM-requiring OVMF

Re: [Qemu-devel] [qemu RFC] qapi: add "firmware.json"

On 04/10/18 11:26, Thomas Huth wrote: > On 10.04.2018 11:16, Laszlo Ersek wrote: >> On 04/10/18 08:27, Gerd Hoffmann wrote: >>> Hi, >>> - I considered adding wildcards (say, blacklist "all" i440fx machtypes, present and future, for SMM-requiring OVMF builds), but then you get into

Re: [Qemu-devel] [qemu RFC] qapi: add "firmware.json"

On Tue, Apr 10, 2018 at 12:48:28PM +0100, Peter Maydell wrote: > On 10 April 2018 at 12:34, Daniel P. Berrangé wrote: > > On Tue, Apr 10, 2018 at 01:27:18PM +0200, Laszlo Ersek wrote: > > > >> Please go through the rest of the emails in this thread, and advise: > >> - if the

Re: [Qemu-devel] [qemu RFC] qapi: add "firmware.json"

On 04/10/18 11:32, Thomas Huth wrote: > On 10.04.2018 11:22, Laszlo Ersek wrote: >> On 04/10/18 09:33, Thomas Huth wrote: > [...] >>> Alternatively, what about providing some kind of "alias" or "nickname" >>> setting here, too? So the EDK2 builds would get >>> SystemFirmwareType="edk2" and

Re: [Qemu-devel] [qemu RFC] qapi: add "firmware.json"

On Tue, Apr 10, 2018 at 01:44:13PM +0200, Laszlo Ersek wrote: > On 04/10/18 13:34, Daniel P. Berrangé wrote: > > On Tue, Apr 10, 2018 at 01:27:18PM +0200, Laszlo Ersek wrote: > > > >> Please go through the rest of the emails in this thread, and advise: > >> - if the firmware descriptor schema may

Re: [Qemu-devel] [qemu RFC] qapi: add "firmware.json"

On 10 April 2018 at 12:34, Daniel P. Berrangé wrote: > On Tue, Apr 10, 2018 at 01:27:18PM +0200, Laszlo Ersek wrote: > >> Please go through the rest of the emails in this thread, and advise: >> - if the firmware descriptor schema may perhaps live in the libvirt tree, >> -

Re: [Qemu-devel] [PULL 0/1] linux-user: fix file offset for preadv/pwritev

On 10 April 2018 at 03:17, Max Filippov wrote: > Hi Peter, > > please pull the following linux-user fix for QEMU-2.12. > > The following changes since commit 9abfc88af3ffd3b33c7fab4471da86462ee71d95: > > Merge remote-tracking branch 'remotes/xtensa/tags/20180402-xtensa' into

Re: [Qemu-devel] [qemu RFC] qapi: add "firmware.json"

On 04/10/18 12:09, Paolo Bonzini wrote: > On 10/04/2018 11:23, Daniel P. Berrangé wrote: >>> And, really, this seems to reinforce my point that the schema should >>> live in the libvirtd tree, not in the QEMU tree. In that case, perhaps >>> it would be a better fit to work with an XSD, and

Re: [Qemu-devel] [qemu RFC] qapi: add "firmware.json"

On 04/10/18 13:34, Daniel P. Berrangé wrote: > On Tue, Apr 10, 2018 at 01:27:18PM +0200, Laszlo Ersek wrote: > >> Please go through the rest of the emails in this thread, and advise: >> - if the firmware descriptor schema may perhaps live in the libvirt tree, >> - accordingly, if the schema could

Re: [Qemu-devel] [qemu RFC] qapi: add "firmware.json"

On 04/10/18 11:05, Daniel P. Berrangé wrote: > On Mon, Apr 09, 2018 at 06:34:41PM +0200, Laszlo Ersek wrote: >> On 04/09/18 09:26, Thomas Huth wrote: >>> Hi Laszlo, >>> >>> On 07.04.2018 02:01, Laszlo Ersek wrote: Add a schema that describes the properties of virtual machine firmware.

Re: [Qemu-devel] [qemu RFC] qapi: add "firmware.json"

Hi, > It occurs to me that we are actually over-thinking things, by making it > possible to list a choice of vars files per firmware. We could remove this > special case by just having separate tpo level firmware entries and a main > feature flag to say if it is enrolled or not - see below

Re: [Qemu-devel] [qemu RFC] qapi: add "firmware.json"

On Tue, Apr 10, 2018 at 01:27:18PM +0200, Laszlo Ersek wrote: > Please go through the rest of the emails in this thread, and advise: > - if the firmware descriptor schema may perhaps live in the libvirt tree, > - accordingly, if the schema could be expressed as an XSD (and firmware > packages

Re: [Qemu-devel] [qemu RFC] qapi: add "firmware.json"

On 04/10/18 11:18, Daniel P. Berrangé wrote: > On Mon, Apr 09, 2018 at 07:57:54PM +0200, Laszlo Ersek wrote: >> On 04/09/18 10:49, Daniel P. Berrangé wrote: >>> On Sat, Apr 07, 2018 at 02:01:17AM +0200, Laszlo Ersek wrote: Add a schema that describes the properties of virtual machine

Re: [Qemu-devel] [PATCH] configure: don't warn SDL abi if disabled

On Tue, Apr 10, 2018 at 04:49:50PM +0800, Fam Zheng wrote: [...] > We have had > > function_name() > { > ... > > and > > function_name() { > ... > > and > > function_name () { > ... > > finally you invent the last in the family: > > function_name () > {

Re: [Qemu-devel] [qemu RFC] qapi: add "firmware.json"

On Tue, Apr 10, 2018 at 11:20:33AM +0100, Daniel P. Berrangé wrote: > On Sat, Apr 07, 2018 at 02:01:17AM +0200, Laszlo Ersek wrote: > > Add a schema that describes the properties of virtual machine firmware. > > > > Each firmware executable installed on a host system should come with a > > JSON

Re: [Qemu-devel] [PULL 0/2] linux-user fixes for -rc3

Hi, This series seems to have some coding style problems. See output below for more information: Type: series Message-id: 20180410105606.16413-1-laur...@vivier.eu Subject: [Qemu-devel] [PULL 0/2] linux-user fixes for -rc3 === TEST SCRIPT BEGIN === #!/bin/bash BASE=base n=1 total=$(git log

[Qemu-devel] [PULL 2/2] linux-user: add microblaze/microblazeel magic numbers in qemu-binfmt-conf.sh

Signed-off-by: Laurent Vivier Message-Id: <20180409115212.875-2-laur...@vivier.eu> --- scripts/qemu-binfmt-conf.sh | 12 ++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff --git a/scripts/qemu-binfmt-conf.sh b/scripts/qemu-binfmt-conf.sh index

Re: [Qemu-devel] [PATCH for-2.12] fpu: Fix rounding mode for floatN_to_uintM_round_to_zero

On 10 April 2018 at 06:59, Richard Henderson wrote: > We incorrectly passed in the current rounding mode > instead of float_round_to_zero. > > Signed-off-by: Richard Henderson > --- > > Found while runnning SVE RISU tests; it should be

[Qemu-devel] [PULL 0/2] linux-user fixes for -rc3

The following changes since commit 1e7e92e2ef874aa3a235d59b2be1da7a29b6fd29: Merge remote-tracking branch 'remotes/cohuck/tags/s390x-20180409' into staging (2018-04-09 18:21:23 +0100) are available in the Git repository at: git://github.com/vivier/qemu.git

[Qemu-devel] [PULL 1/2] linux-user: fix microblaze get_sp_from_cpustate()

get_sigframe() uses regs[1] and this is actual SP. Signed-off-by: Laurent Vivier Message-Id: <20180409115212.875-1-laur...@vivier.eu> --- linux-user/microblaze/target_signal.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[Qemu-devel] [Bug 1762707] [NEW] VFIO device gets DMA failures when virtio-balloon leak from highmem to lowmem

Public bug reported: Is there any known conflict between VFIO passthrough device and virtio- balloon? The VM has: 1. 4GB system memory 2. one VFIO passthrough device which supports high address memory DMA and uses GFP_HIGHUSER pages. 3. Memory balloon device with 4GB target. When setting the

Re: [Qemu-devel] [PATCH] migration: calculate expected_downtime with ram_bytes_remaining()

On 2018-04-10 15:22, Balamuruhan S wrote: On Wed, Apr 04, 2018 at 11:04:59AM +0200, Juan Quintela wrote: Balamuruhan S wrote: > expected_downtime value is not accurate with dirty_pages_rate * page_size, > using ram_bytes_remaining would yeild it correct. > >

Re: [Qemu-devel] [PATCH for-2.12] tcg: Introduce tcg_set_insn_start_param

On 10 April 2018 at 01:35, Richard Henderson wrote: > The parameters for tcg_gen_insn_start are target_ulong, which may be split > into two TCGArg parameters for storage in the opcode on 32-bit hosts. > > Fixes the ARM target and its direct use of tcg_set_insn_param,

Re: [Qemu-devel] [PATCH v2 for-2.13 1/3] net: Remove the deprecated "vlan" parameter

On 06.04.2018 16:17, Paolo Bonzini wrote: > On 06/04/2018 15:37, Thomas Huth wrote: >> It's been marked as deprecated since QEMU v2.9.0, so that should have >> been enough time for everybody to switch to the modern -device + -netdev >> syntax for connecting guest NICs with host network backends,

Re: [Qemu-devel] [PATCH] migration: Don't activate block devices if using -S

* Kevin Wolf (kw...@redhat.com) wrote: > Am 10.04.2018 um 10:45 hat Dr. David Alan Gilbert geschrieben: > > * Kevin Wolf (kw...@redhat.com) wrote: > > > Am 10.04.2018 um 09:36 hat Jiri Denemark geschrieben: > > > > On Mon, Apr 09, 2018 at 15:40:03 +0200, Kevin Wolf wrote: > > > > > Am 09.04.2018

Re: [Qemu-devel] [qemu RFC] qapi: add "firmware.json"

On Sat, Apr 07, 2018 at 02:01:17AM +0200, Laszlo Ersek wrote: > Add a schema that describes the properties of virtual machine firmware. > > Each firmware executable installed on a host system should come with a > JSON file that conforms to this schema, and informs the management > applications

Re: [Qemu-devel] [PATCH v2 for-2.12] icount: fix cpu_restore_state_from_tb for non-tb-exit cases

On 10/04/2018 12:13, Richard Henderson wrote: > In most cases new parameter is true (icount should be recalculated). > But there are two cases in i386 and openrisc when the CPU state is only > queried without the need to break the TB. This patch fixes both of > these cases. > > Signed-off-by:

Re: [Qemu-devel] [Qemu-arm] Crash when running hello-world unikernel for ARM

Thanks Peter .. my sincere gratitude. You pin-pointed the real issue .. On Tue, Apr 10, 2018 at 2:50 PM, Peter Maydell wrote: > On 10 April 2018 at 09:16, Ajay Garg wrote: >> On Tue, Apr 10, 2018 at 1:08 PM, Peter Maydell

Re: [Qemu-devel] [PATCH for-2.12] fpu: Fix rounding mode for floatN_to_uintM_round_to_zero

On 04/10/2018 05:40 PM, Peter Maydell wrote: > Would this be likely the fix for > https://bugs.launchpad.net/qemu/+bug/1761401 > ? Yes indeed. r~

Re: [Qemu-devel] [qemu RFC] qapi: add "firmware.json"

On 10/04/2018 11:23, Daniel P. Berrangé wrote: >> And, really, this seems to reinforce my point that the schema should >> live in the libvirtd tree, not in the QEMU tree. In that case, perhaps >> it would be a better fit to work with an XSD, and firmware packages >> should install XML files?

[Qemu-devel] [PATCH v2 for-2.12] icount: fix cpu_restore_state_from_tb for non-tb-exit cases

From: Pavel Dovgalyuk In icount mode, instructions that access io memory spaces in the middle of the translation block invoke TB recompilation. After recompilation, such instructions become last in the TB and are allowed to access io memory spaces. When the code

Re: [Qemu-devel] [PATCH] migration: calculate expected_downtime with ram_bytes_remaining()

* David Gibson (dgib...@redhat.com) wrote: > On Mon, 9 Apr 2018 19:57:47 +0100 > "Dr. David Alan Gilbert" wrote: > > > * Balamuruhan S (bal...@linux.vnet.ibm.com) wrote: > > > On 2018-04-04 13:36, Peter Xu wrote: > > > > On Wed, Apr 04, 2018 at 11:55:14AM +0530,

Re: [Qemu-devel] [qemu RFC] qapi: add "firmware.json"

On Tue, Apr 10, 2018 at 11:51:31AM +0200, Gerd Hoffmann wrote: > > > Hmm, I'm wondering whenever it is useful to model things this way. It's > > > not like you can actually configure things for -bios seabios.rom or > > > -kernel uboot.elf. Only pflash allows to actually configure things, and > >

Re: [Qemu-devel] [PATCH] migration: calculate expected_downtime with ram_bytes_remaining()

On Wed, Apr 04, 2018 at 11:04:59AM +0200, Juan Quintela wrote: > Balamuruhan S wrote: > > expected_downtime value is not accurate with dirty_pages_rate * page_size, > > using ram_bytes_remaining would yeild it correct. > > > > Signed-off-by: Balamuruhan S

Re: [Qemu-devel] [qemu RFC] qapi: add "firmware.json"

> > Hmm, I'm wondering whenever it is useful to model things this way. It's > > not like you can actually configure things for -bios seabios.rom or > > -kernel uboot.elf. Only pflash allows to actually configure things, and > > there are not that many useful combinations. The code needs > >

Re: [Qemu-devel] [PATCH] i386/kvm: add support for KVM_CAP_X86_DISABLE_EXITS

Hi Paolo, 2018-03-27 3:43 GMT+08:00 Eduardo Habkost : > On Sun, Mar 25, 2018 at 11:33:01AM +0800, Wanpeng Li wrote: >> 2018-03-24 4:18 GMT+08:00 Eduardo Habkost : >> > On Fri, Mar 16, 2018 at 07:36:42AM -0700, Wanpeng Li wrote: >> >> From: Wanpeng Li

Re: [Qemu-devel] [PATCH] icount: fix cpu_restore_state_from_tb for non-tb-exit cases

On 04/10/2018 05:35 PM, Paolo Bonzini wrote: > This is incorrect, "cpu->can_do_io" is 1 when not in tcg_qemu_tb_exec. > In fact, in cpu_exec we have "cpu->can_do_io = 1;" immediately after > siglongjmp, so I propose adding the same "cpu->can_do_io = 1;" > assignment to cpu_exec_step_atomic. Ooo,

Re: [Qemu-devel] [qemu RFC] qapi: add "firmware.json"

On Tue, Apr 10, 2018 at 11:16:01AM +0200, Laszlo Ersek wrote: > On 04/10/18 08:27, Gerd Hoffmann wrote: > > Hi, > > > >> - I considered adding wildcards (say, blacklist "all" i440fx machtypes, > >> present and future, for SMM-requiring OVMF builds), but then you get > >> into version sorting

Re: [Qemu-devel] [qemu RFC] qapi: add "firmware.json"

On 10.04.2018 11:22, Laszlo Ersek wrote: > On 04/10/18 09:33, Thomas Huth wrote: [...] >> Alternatively, what about providing some kind of "alias" or "nickname" >> setting here, too? So the EDK2 builds would get >> SystemFirmwareType="edk2" and "SystemFirmwareAlias="uefi" for example. > > I hope

[Qemu-devel] [PULL 2/4] gtk: drop pointless code from gd_window_close

Unregistering the display change listener looks like a pointless excercise given we'll exit in a moment. When exiting qemu via menu/file/quit this will not happen either. Just drop the code. Also return TRUE unconditionally. This will tell gtk to ignore the close request, so gtk will not start

[Qemu-devel] [PULL 1/4] ui: fix keymap detection under Xwayland

From: Daniel P. Berrangé The X11 code currently detects the keymap by looking for the keycode name property. Unfortunately due to the way Xwayland handles keyboards, this property gets unset almost immediately after the first application starts using Xwayland resulting in

Re: [Qemu-devel] [qemu RFC] qapi: add "firmware.json"

On 10.04.2018 11:16, Laszlo Ersek wrote: > On 04/10/18 08:27, Gerd Hoffmann wrote: >> Hi, >> >>> - I considered adding wildcards (say, blacklist "all" i440fx machtypes, >>> present and future, for SMM-requiring OVMF builds), but then you get >>> into version sorting and similar mess. I

[Qemu-devel] [PULL 0/4] Ui 20180410 patches

The following changes since commit 915d34c5f99b0ab91517c69f54272bfdb6ca2b32: Merge remote-tracking branch 'remotes/bonzini/tags/for-upstream' into staging (2018-04-09 17:29:10 +0100) are available in the git repository at: git://git.kraxel.org/qemu tags/ui-20180410-pull-request for you

Re: [Qemu-devel] [qemu RFC] qapi: add "firmware.json"

On Tue, Apr 10, 2018 at 11:16:01AM +0200, Laszlo Ersek wrote: > On 04/10/18 08:27, Gerd Hoffmann wrote: > > Hi, > > > >> - I considered adding wildcards (say, blacklist "all" i440fx machtypes, > >> present and future, for SMM-requiring OVMF builds), but then you get > >> into version sorting

[Qemu-devel] [PULL 3/4] configure: don't warn GTK if disabled

From: Peter Xu We don't need to detect GTK ABI if GTK is disabled in general. Otherwise we could get this warning (when host is installed with GTK ABI version 2) even when configure with "--disable-gtk": WARNING: Use of GTK 2.0 is deprecated and will be removed in

[Qemu-devel] [PULL 4/4] configure: don't warn SDL abi if disabled

From: Peter Xu SDL has the same problem as GTK that we might get warnings on SDL ABI version even if SDL is disabled. Fix that by only probing SDL if SDL is enabled. Also this should let configure be a little bit faster since we don't really need to probe SDL stuff when it's

Re: [Qemu-devel] [PULL for-2.12 0/8] s390x fixes for -rc3

On 9 April 2018 at 16:15, Cornelia Huck wrote: > The following changes since commit 2a6bcfdebe4115993a032395d459f5e0cf27a01e: > > Merge remote-tracking branch 'remotes/famz/tags/testing-pull-request' into > staging (2018-04-09 10:21:14 +0100) > > are available in the Git

Re: [Qemu-devel] [qemu RFC] qapi: add "firmware.json"

On 04/10/18 09:33, Thomas Huth wrote: > On 09.04.2018 18:50, Laszlo Ersek wrote: >> On 04/09/18 10:19, Gerd Hoffmann wrote: > +{ 'enum' : 'SystemFirmwareType', > + 'data' : [ 'bios', 'slof', 'uboot', 'uefi' ] } The naming here is quite a bad mixture between firmware interface

Re: [Qemu-devel] [Qemu-arm] Crash when running hello-world unikernel for ARM

On 10 April 2018 at 09:16, Ajay Garg wrote: > On Tue, Apr 10, 2018 at 1:08 PM, Peter Maydell > wrote: >> What hardware (what CPU, board, etc) is this "rumprun" software >> expecting to run on? > > Yep, just to ensure that there are no

Re: [Qemu-devel] [PATCH v3 for-2.13] vfio-ccw: introduce vfio_ccw_get_device()

On Mon, 09 Apr 2018 12:15:10 +0200 Greg Kurz wrote: > A recent patch fixed leaks of the dynamically allocated vcdev->vdev.name > field in vfio_ccw_realize(), but we now have three freeing sites for it. > This is unfortunate and seems to indicate something is wrong with its > life

Re: [Qemu-devel] [qemu RFC] qapi: add "firmware.json"

On 10.04.2018 11:05, Daniel P. Berrangé wrote: > On Mon, Apr 09, 2018 at 06:34:41PM +0200, Laszlo Ersek wrote: >> On 04/09/18 09:26, Thomas Huth wrote: >>> Hi Laszlo, >>> >>> On 07.04.2018 02:01, Laszlo Ersek wrote: Add a schema that describes the properties of virtual machine firmware.

Re: [Qemu-devel] [qemu RFC] qapi: add "firmware.json"

On Mon, Apr 09, 2018 at 07:57:54PM +0200, Laszlo Ersek wrote: > On 04/09/18 10:49, Daniel P. Berrangé wrote: > > On Sat, Apr 07, 2018 at 02:01:17AM +0200, Laszlo Ersek wrote: > >> Add a schema that describes the properties of virtual machine firmware. > >> > >> Each firmware executable installed

Re: [Qemu-devel] [qemu RFC] qapi: add "firmware.json"

On 04/10/18 08:27, Gerd Hoffmann wrote: > Hi, > >> - I considered adding wildcards (say, blacklist "all" i440fx machtypes, >> present and future, for SMM-requiring OVMF builds), but then you get >> into version sorting and similar mess. I considered fnmatch() -- >> basically simple ? and *

Re: [Qemu-devel] [PATCH] migration: Don't activate block devices if using -S

Am 10.04.2018 um 10:45 hat Dr. David Alan Gilbert geschrieben: > * Kevin Wolf (kw...@redhat.com) wrote: > > Am 10.04.2018 um 09:36 hat Jiri Denemark geschrieben: > > > On Mon, Apr 09, 2018 at 15:40:03 +0200, Kevin Wolf wrote: > > > > Am 09.04.2018 um 12:27 hat Dr. David Alan Gilbert geschrieben: >

Re: [Qemu-devel] [qemu RFC] qapi: add "firmware.json"

On Mon, Apr 09, 2018 at 06:50:12PM +0200, Laszlo Ersek wrote: > On 04/09/18 10:19, Gerd Hoffmann wrote: > >>> +{ 'enum' : 'SystemFirmwareType', > >>> + 'data' : [ 'bios', 'slof', 'uboot', 'uefi' ] } > >> > >> The naming here is quite a bad mixture between firmware interface > >> ('bios', 'uefi')

Re: [Qemu-devel] [qemu RFC] qapi: add "firmware.json"

On 04/10/18 08:18, Gerd Hoffmann wrote: > Hi, > >>> uboot for example implements uefi unterfaces too (dunno how complete, >>> but reportly recent versions can run uefi shell and grub just fine). >> >> Indeed: when I was struggling with this enum type and tried to look for >> more firmware types

Re: [Qemu-devel] [qemu RFC] qapi: add "firmware.json"

On 04/10/18 07:59, Gerd Hoffmann wrote: > Hi, > >> I threw in "-kernel" because, although it also (usually?) means >> "memory", I expected people would want it separate. >> >> Regarding memory vs. pflash, I thought that these two, combined with the >> access permissions, could cover all of RAM,

[Qemu-devel] [Bug 657329] Re: APIC unusable on QEMU

Looking through old bug tickets... can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays? ** Changed in: qemu Status: New => Incomplete -- You received this bug notification because you are a member of qemu- devel-ml, which is

Re: [Qemu-devel] [qemu RFC] qapi: add "firmware.json"

On Mon, Apr 09, 2018 at 06:34:41PM +0200, Laszlo Ersek wrote: > On 04/09/18 09:26, Thomas Huth wrote: > > Hi Laszlo, > > > > On 07.04.2018 02:01, Laszlo Ersek wrote: > >> Add a schema that describes the properties of virtual machine firmware. > >> > >> Each firmware executable installed on a

[Qemu-devel] [PATCH for-2.12] commit/stream: Reset delay_ns

Streaming and the commit block job only want to apply throttling when they actually copied data instead of skipping it, so they made the calculation of delay_ns conditional. However, delay_ns isn't reset when skipping some sectors, so instead of not waiting, the old delay is applied again.

Re: [Qemu-devel] [qemu RFC] qapi: add "firmware.json"

On 04/10/18 09:44, Thomas Huth wrote: > On 09.04.2018 18:34, Laszlo Ersek wrote: >> On 04/09/18 09:26, Thomas Huth wrote: >>> Hi Laszlo, >>> >>> On 07.04.2018 02:01, Laszlo Ersek wrote: Add a schema that describes the properties of virtual machine firmware. Each firmware executable

Re: [Qemu-devel] [PATCH 1/1] mach-virt: Change default cpu and gic-version setting to "max"

On Tue, Apr 10, 2018 at 09:41:33AM +0200, Andrea Bolognani wrote: > On Mon, 2018-04-09 at 11:29 -0500, Wei Huang wrote: > > > > Running mach-virt machine types (i.e. "-M virt") on different systems > > > > can > > > > result in various misleading warnings if -cpu and/or gic-version not > > > >

Re: [Qemu-devel] [PATCH] configure: don't warn SDL abi if disabled

On Tue, 04/10 13:40, Peter Xu wrote: > SDL has the same problem as GTK that we might get warnings on SDL ABI > version even if SDL is disabled. Fix that by only probing SDL if SDL is > enabled. Also this should let configure be a little bit faster since we > don't really need to probe SDL stuff

Re: [Qemu-devel] [PATCH] configure: don't warn GTK if disabled

On Mon, Apr 09, 2018 at 04:23:23PM +0800, Peter Xu wrote: > We don't need to detect GTK ABI if GTK is disabled in general. > Otherwise we could get this warning (when host is installed with GTK ABI > version 2) even when configure with "--disable-gtk": > > WARNING: Use of GTK 2.0 is

Re: [Qemu-devel] [PATCH] configure: don't warn SDL abi if disabled

On Tue, Apr 10, 2018 at 01:40:34PM +0800, Peter Xu wrote: > SDL has the same problem as GTK that we might get warnings on SDL ABI > version even if SDL is disabled. Fix that by only probing SDL if SDL is > enabled. Also this should let configure be a little bit faster since we > don't really

Re: [Qemu-devel] [PATCH] migration: Don't activate block devices if using -S

* Kevin Wolf (kw...@redhat.com) wrote: > Am 10.04.2018 um 09:36 hat Jiri Denemark geschrieben: > > On Mon, Apr 09, 2018 at 15:40:03 +0200, Kevin Wolf wrote: > > > Am 09.04.2018 um 12:27 hat Dr. David Alan Gilbert geschrieben: > > > > It's a fairly hairy failure case they had; if I remember

[Qemu-devel] [PATCH] qemu-iotests: Remove _supported_fmt dmg

qemu-iotests doesn't support dmg, and the dmg block driver doesn't support image creation. Two test cases declare dmg as supported, but that's obviously wrong for both reasons. Remove the declaration. Signed-off-by: Kevin Wolf --- tests/qemu-iotests/183 | 2 +-

Re: [Qemu-devel] [PATCH v2 0/2] iotests: blacklist bochs and cloop for 205 and 208

Am 09.04.2018 um 13:44 hat Vladimir Sementsov-Ogievskiy geschrieben: > v2: move from unsupported_fmts to support "generic", like in bash tests. Thanks, applied to the block branch. Kevin

Re: [Qemu-devel] [PATCH] migration: Don't activate block devices if using -S

Am 10.04.2018 um 09:36 hat Jiri Denemark geschrieben: > On Mon, Apr 09, 2018 at 15:40:03 +0200, Kevin Wolf wrote: > > Am 09.04.2018 um 12:27 hat Dr. David Alan Gilbert geschrieben: > > > It's a fairly hairy failure case they had; if I remember correctly it's: > > > a) Start migration > > > b)

Re: [Qemu-devel] qom-test on netbsd can be very slow

On Mon, Apr 09, 2018 at 06:10:43PM +0100, Peter Maydell wrote: > My NetBSD build system recently seems to have taken a nosedive > in how long it takes to finish "make check". This seems to be > because qom-test (and probably other things where the test interacts > with the QEMU process) can run

Re: [Qemu-devel] [Qemu-arm] Crash when running hello-world unikernel for ARM

Hi Peter. Thanks for the reply. On Tue, Apr 10, 2018 at 1:08 PM, Peter Maydell wrote: > On 10 April 2018 at 05:14, Ajay Garg wrote: >> Thanks Alex for the reply .. >> >>> >>> Can you run under -s -S and gdb step the *guest* and see where it

Re: [Qemu-devel] [PATCH for-2.12 v2] qemu-iotests: update 185 output

On Wed, Apr 04, 2018 at 06:16:12PM +0200, Max Reitz wrote: > On 2018-04-04 17:01, Stefan Hajnoczi wrote: > === Start mirror job and exit qemu === > > This seems to be independent of whether there is actually data on > TEST_IMG (the commit source), so something doesn't seem quite right with > the

Re: [Qemu-devel] [PATCH v8 14/23] monitor: separate QMP parser and dispatcher

On Tue, Apr 10, 2018 at 03:15:57PM +0800, Peter Xu wrote: > On Mon, Apr 09, 2018 at 11:19:43AM +0200, Marc-André Lureau wrote: > > Hi > > > > On Sun, Apr 8, 2018 at 5:02 AM, Peter Xu wrote: > > > On Wed, Apr 04, 2018 at 03:58:56PM +0200, Marc-André Lureau wrote: > > >> Hi

Re: [Qemu-devel] [PATCH v8 19/23] SiFive RISC-V UART Device

On Tue, 10 Apr 2018 08:17:32 +0200 Thomas Huth wrote: > On 10.04.2018 05:21, Antony Pavlov wrote: > > On Sat, 3 Mar 2018 02:51:47 +1300 > > Michael Clark wrote: > > > >> QEMU model of the UART on the SiFive E300 and U500 series SOCs. > >> BBL supports the

Re: [Qemu-devel] [qemu RFC] qapi: add "firmware.json"

On 09.04.2018 18:34, Laszlo Ersek wrote: > On 04/09/18 09:26, Thomas Huth wrote: >> Hi Laszlo, >> >> On 07.04.2018 02:01, Laszlo Ersek wrote: >>> Add a schema that describes the properties of virtual machine firmware. >>> >>> Each firmware executable installed on a host system should come with a

Re: [Qemu-devel] [PATCH for-2.12] fpu: Fix rounding mode for floatN_to_uintM_round_to_zero

On 10 April 2018 at 06:59, Richard Henderson wrote: > We incorrectly passed in the current rounding mode > instead of float_round_to_zero. > > Signed-off-by: Richard Henderson > --- > > Found while runnning SVE RISU tests; it should be

Re: [Qemu-devel] [PATCH 1/1] mach-virt: Change default cpu and gic-version setting to "max"

On Mon, 2018-04-09 at 11:29 -0500, Wei Huang wrote: > > > Running mach-virt machine types (i.e. "-M virt") on different systems can > > > result in various misleading warnings if -cpu and/or gic-version not > > > specified. > > > For KVM, this can be solved mostly by using "host" type. But the

Re: [Qemu-devel] [Qemu-arm] Crash when running hello-world unikernel for ARM

On 10 April 2018 at 05:14, Ajay Garg wrote: > Thanks Alex for the reply .. > >> >> Can you run under -s -S and gdb step the *guest* and see where it ends >> up. The above error is usually indicative of the guest going off into >> the weeds somewhere because the hardware

Re: [Qemu-devel] [PATCH] icount: fix cpu_restore_state_from_tb for non-tb-exit cases

On 09/04/2018 11:13, Pavel Dovgalyuk wrote: > @@ -29,6 +29,7 @@ void cpu_loop_exit_noexc(CPUState *cpu) > { > /* XXX: restore cpu registers saved in host registers */ > > +cpu->can_do_io = !use_icount; > cpu->exception_index = -1; > siglongjmp(cpu->jmp_env, 1); > } > @@

Re: [Qemu-devel] [PATCH] migration: Don't activate block devices if using -S

On Mon, Apr 09, 2018 at 15:40:03 +0200, Kevin Wolf wrote: > Am 09.04.2018 um 12:27 hat Dr. David Alan Gilbert geschrieben: > > It's a fairly hairy failure case they had; if I remember correctly it's: > > a) Start migration > > b) Migration gets to completion point > > c) Destination is still

Re: [Qemu-devel] [qemu RFC] qapi: add "firmware.json"

On 09.04.2018 18:50, Laszlo Ersek wrote: > On 04/09/18 10:19, Gerd Hoffmann wrote: +{ 'enum' : 'SystemFirmwareType', + 'data' : [ 'bios', 'slof', 'uboot', 'uefi' ] } >>> >>> The naming here is quite a bad mixture between firmware interface >>> ('bios', 'uefi') and firmware

Re: [Qemu-devel] [PATCH 4/8] virtio: add detach element for packed ring(1.1)

On 2018年04月04日 20:54, w...@redhat.com wrote: From: Wei Xu helper for packed ring It's odd and hard to review if you put detach patch first. I think this patch needs to be reordered after the implementation of pop/map. Thanks Signed-off-by: Wei Xu ---

Re: [Qemu-devel] [PATCH for-2.12] make-release: add skiboot .version file

On 10 April 2018 at 01:57, Michael Roth wrote: > This is needed to build skiboot from tarball-distributed sources > since the git data the make_release.sh script relies on to generate > it is not available. > > Cc: qemu-sta...@nongnu.org > Reported-by: Michael Tokarev

Re: [Qemu-devel] [PATCH 3/8] virtio: add empty check for packed ring

On 2018年04月04日 20:53, w...@redhat.com wrote: From: Wei Xu helper for ring empty check. And descriptor read. Signed-off-by: Wei Xu --- hw/virtio/virtio.c | 62 +++--- 1 file changed, 59 insertions(+), 3

Re: [Qemu-devel] [PATCH v8 14/23] monitor: separate QMP parser and dispatcher

On Mon, Apr 09, 2018 at 11:19:43AM +0200, Marc-André Lureau wrote: > Hi > > On Sun, Apr 8, 2018 at 5:02 AM, Peter Xu wrote: > > On Wed, Apr 04, 2018 at 03:58:56PM +0200, Marc-André Lureau wrote: > >> Hi Peter > >> > >> On Wed, Mar 28, 2018 at 6:02 AM, Peter Xu

Re: [Qemu-devel] [PATCH 2/8] virtio: memory cache for packed ring

On 2018年04月04日 20:53, w...@redhat.com wrote: From: Wei Xu A new memory cache is introduced to for packed ring, the code looks pretty duplicated with split(1.0) ring, any refactor idea? I think you can reuse the exist code as I replied in patch 1. Thanks

Re: [Qemu-devel] [PATCH 1/8] virtio: feature bit, data structure for packed ring

On 2018年04月04日 20:53, w...@redhat.com wrote: From: Wei Xu Only minimum definitions from the spec are included for prototype. Signed-off-by: Wei Xu --- hw/virtio/virtio.c | 47 +++---

Re: [Qemu-devel] [RfC PATCH] Add udmabuf misc device

On 04/06/2018 09:57 PM, Dongwon Kim wrote: On Fri, Apr 06, 2018 at 03:36:03PM +0300, Oleksandr Andrushchenko wrote: On 04/06/2018 02:57 PM, Gerd Hoffmann wrote: Hi, I fail to see any common ground for xen-zcopy and udmabuf ... Does the above mean you can assume that xen-zcopy and udmabuf

Re: [Qemu-devel] [qemu RFC] qapi: add "firmware.json"

Hi, > - I considered adding wildcards (say, blacklist "all" i440fx machtypes, > present and future, for SMM-requiring OVMF builds), but then you get > into version sorting and similar mess. I considered fnmatch() -- > basically simple ? and * wildcards -- but that's not expressive enough. I'd

Re: [Qemu-devel] [PATCH v2] iotests: fix wait_until_completed()

On Mon, Apr 09, 2018 at 09:06:59AM -0500, Eric Blake wrote: > On 04/07/2018 10:05 PM, Peter Xu wrote: > > If there are more than one events, wait_until_completed() might return > > the 2nd event even if the 1st event is JOB_COMPLETED, since the for loop > > will continue to run even if completed

Re: [Qemu-devel] [qemu RFC] qapi: add "firmware.json"

Hi, > > uboot for example implements uefi unterfaces too (dunno how complete, > > but reportly recent versions can run uefi shell and grub just fine). > > Indeed: when I was struggling with this enum type and tried to look for > more firmware types to add, my googling turned up the "UEFI on

Re: [Qemu-devel] [PATCH v8 19/23] SiFive RISC-V UART Device

On 10.04.2018 05:21, Antony Pavlov wrote: > On Sat, 3 Mar 2018 02:51:47 +1300 > Michael Clark wrote: > >> QEMU model of the UART on the SiFive E300 and U500 series SOCs. >> BBL supports the SiFive UART for early console access via the SBI >> (Supervisor Binary Interface) and

[Qemu-devel] [Bug 1762558] Re: Many crashes with "memslot_get_virt: slot_id 170 too big"-type errors in 2.12.0 rc2

These error messages ("memslot_get_virt") do not come from QEMU, but from spice, so please report this problem to the Spice project first (see https://www.spice-space.org/support.html for how to file a bug there). -- You received this bug notification because you are a member of qemu- devel-ml,

[Qemu-devel] [PATCH for-2.12] fpu: Fix rounding mode for floatN_to_uintM_round_to_zero

We incorrectly passed in the current rounding mode instead of float_round_to_zero. Signed-off-by: Richard Henderson --- Found while runnning SVE RISU tests; it should be visible with the right set of inputs to AdvSIMD RISU tests. r~ --- fpu/softfloat.c | 4 ++--

[Qemu-devel] [RFC PATCH V4 4/4] vifo: introduce new VFIO ioctl VFIO_IOMMU_GET_DIRTY_BITMAP

New VFIO ioctl VFIO_IOMMU_GET_DIRTY_BITMAP is used to fetch the bitmap of pinned memory in iommu container, we need copy those memory to the target during the migration as they are dirtied by mdev devices. Signed-off-by: Yulei Zhang --- hw/vfio/common.c | 34

Re: [Qemu-devel] [qemu RFC] qapi: add "firmware.json"

Hi, > I threw in "-kernel" because, although it also (usually?) means > "memory", I expected people would want it separate. > > Regarding memory vs. pflash, I thought that these two, combined with the > access permissions, could cover all of RAM, ROM, and read-only and > read-write pflash too.

<    1   2   3