flight 156398 xen-4.12-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156398/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-cubietruck broken
test-armhf-arm
On Wed, 4 Nov 2020, Thomas Huth wrote:
> On 04/11/2020 03.27, Stefano Stabellini wrote:
> [...]
> > Actually I care about Xen and 9pfs support, it is one of the few
> > combinations that I use regularly and it is even enabled in the Xilinx
> > product I look after. But admittedly I don't test QEMU
flight 156397 xen-4.11-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156397/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 12 debian-hvm-install
fail like 156277
test-amd64-i386-x
On Wed, 4 Nov 2020, Paolo Bonzini wrote:
> Il mer 4 nov 2020, 03:27 Stefano Stabellini ha
> scritto:
> FYI I tried to build the latest QEMU on Alpine Linux 3.12 ARM64 and I
> get:
>
> ninja: unknown tool 'query'
>
> Even after rebuilding ninja master by hand. Any ideas
On Wed, 4 Nov 2020, Bertrand Marquis wrote:
> > On 4 Nov 2020, at 07:34, Jan Beulich wrote:
> > On 03.11.2020 20:37, Stefano Stabellini wrote:
> >> On Tue, 3 Nov 2020, Jan Beulich wrote:
> >>> On 02.11.2020 22:41, Stefano Stabellini wrote:
> On Mon, 2 Nov 2020, Jan Beulich wrote:
> > On 3
flight 156396 xen-4.10-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156396/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-thunderx 3 hosts-allocate fail like 156261
test-amd64-amd64-xl-qemuu-dmrest
On Thu, 5 Nov 2020 at 00:53, wrote:
>
>
> On 11/4/20 5:14 PM, Ard Biesheuvel wrote:
> > Now that we have a static inline helper to discover the platform's secure
> > boot mode that can be shared between the EFI stub and the kernel proper,
> > switch to it, and drop some comments about keeping them
On 11/4/20 5:14 PM, Ard Biesheuvel wrote:
> Now that we have a static inline helper to discover the platform's secure
> boot mode that can be shared between the EFI stub and the kernel proper,
> switch to it, and drop some comments about keeping them in sync manually.
>
> Signed-off-by: Ard Biesh
flight 156394 xen-4.14-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156394/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 156264
test-amd64-i386-xl-qemuu-win7-am
Now that we have a static inline helper to discover the platform's secure
boot mode that can be shared between the EFI stub and the kernel proper,
switch to it, and drop some comments about keeping them in sync manually.
Signed-off-by: Ard Biesheuvel
---
arch/x86/xen/efi.c
On 11/3/20 4:15 PM, Stefano Stabellini wrote:
> On Tue, 3 Nov 2020, Rich Persaud wrote:
>> On Nov 3, 2020, at 14:37, Stefano Stabellini wrote:
>>>
>>> On Tue, 3 Nov 2020, Jan Beulich wrote:
> On 02.11.2020 22:41, Stefano Stabellini wrote:
> On Mon, 2 Nov 2020, Jan Beulich wrote:
>> On
Hi Elliott,
On 04/11/2020 19:03, Elliott Mitchell wrote:
On Mon, Oct 26, 2020 at 09:19:49AM +, Julien Grall wrote:
On 23/10/2020 17:57, Stefano Stabellini wrote:
On Fri, 23 Oct 2020, Julien Grall wrote:
I am sort of okay to remove EXPERT.
OK. This would help (even without building it
flight 156393 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156393/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-libvirt-xsm 14 guest-start fail REGR. vs. 152631
test-armhf-armhf-
On Mon, Oct 26, 2020 at 09:19:49AM +, Julien Grall wrote:
> On 23/10/2020 17:57, Stefano Stabellini wrote:
> > On Fri, 23 Oct 2020, Julien Grall wrote:
> >> I am sort of okay to remove EXPERT.
> >
> > OK. This would help (even without building it by default) because as you
> > go and look at
On Wed, 04 Nov 2020 13:18:09 +0100
Christian Schoenebeck wrote:
> On Mittwoch, 4. November 2020 12:57:04 CET Philippe Mathieu-Daudé wrote:
> > Commit b2c00bce54c ("meson: convert hw/9pfs, cleanup") introduced
> > CONFIG_9PFS (probably a wrong conflict resolution). This config is
> > not used anyw
All field property getters and setters must interpret the fourth
argument as Property*. Change the function signature of field
property getters and setters to indicate that.
Signed-off-by: Eduardo Habkost
---
Cc: Stefan Berger
Cc: Stefano Stabellini
Cc: Anthony Perard
Cc: Paul Durrant
Cc: Ke
Introduce a FIELD_PTR macro that will ensure the size of the area
we are accessing has the correct size, and will return a pointer
of the correct type.
Signed-off-by: Eduardo Habkost
---
Cc: Stefan Berger
Cc: Stefano Stabellini
Cc: Anthony Perard
Cc: Paul Durrant
Cc: Kevin Wolf
Cc: Max Reitz
On Wed, Nov 04, 2020 at 03:57:49PM +0100, Jan Beulich wrote:
> With the split of libraries, I've observed a number of warnings from
> (old?) ld.
>
> Instead of duplicating the additions in two places, introduce a setup.py
> make variable holding all the common parts of the invocations.
>
> Signed
On Wed, Nov 04, 2020 at 03:57:49PM +0100, Jan Beulich wrote:
> --- a/tools/python/Makefile
> +++ b/tools/python/Makefile
> @@ -8,19 +8,21 @@ PY_CFLAGS = $(CFLAGS) $(PY_NOOPT_CFLAGS)
> PY_LDFLAGS = $(SHLIB_LDFLAGS) $(APPEND_LDFLAGS)
> INSTALL_LOG = build/installed_files.txt
>
> +setup.py = CC="$
flight 156390 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156390/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-qemut-rhel6hvm-intel 7 xen-install fail REGR. vs. 152332
test-amd64-i386-xl-
The function will be moved to common QOM code, as it is not
specific to TYPE_DEVICE anymore.
Signed-off-by: Eduardo Habkost
---
Changes v1 -> v2:
* Rename to object_field_prop_ptr() instead of object_static_prop_ptr()
---
Cc: Stefan Berger
Cc: Stefano Stabellini
Cc: Anthony Perard
Cc: Paul Dur
Every single qdev property setter function manually checks
dev->realized. We can just check dev->realized inside
qdev_property_set() instead.
The check is being added as a separate function
(qdev_prop_allow_set()) because it will become a callback later.
Signed-off-by: Eduardo Habkost
---
Chang
Make the code more generic and not specific to TYPE_DEVICE.
Reviewed-by: Marc-André Lureau
Signed-off-by: Eduardo Habkost
---
Changes v1 -> v2:
- Fix build error with CONFIG_XEN
I took the liberty of keeping the Reviewed-by line from
Marc-André as the build fix is a trivial one line change
-
On 04.11.20 16:29, Jan Beulich wrote:
@@ -738,7 +725,8 @@ int evtchn_send(struct domain *ld, unsigned int lport)
lchn = evtchn_from_port(ld, lport);
-spin_lock_irqsave(&lchn->lock, flags);
+if ( !evtchn_read_trylock(lchn) )
+return 0;
Isn't there a change in behavio
On 04.11.2020 16:43, Jan Beulich wrote:
> On 03.11.2020 16:59, Rahul Singh wrote:
>> --- a/xen/drivers/pci/Kconfig
>> +++ b/xen/drivers/pci/Kconfig
>> @@ -1,3 +1,12 @@
>>
>> config HAS_PCI
>> bool
>> +
>> +config PCI_ATS
>> +bool "PCI ATS support"
>> +default y
>> +depends on X8
On 03.11.2020 16:59, Rahul Singh wrote:
> --- a/xen/drivers/pci/Kconfig
> +++ b/xen/drivers/pci/Kconfig
> @@ -1,3 +1,12 @@
>
> config HAS_PCI
> bool
> +
> +config PCI_ATS
> + bool "PCI ATS support"
> + default y
> + depends on X86 && HAS_PCI
> + ---help---
> + Enable P
On 03.11.2020 16:59, Rahul Singh wrote:
> ARM platforms do not have PCI support available. When CONFIG_HAS_PCI
> is enabled for ARM a compilation error is observed for ns16550 driver.
I still don't really agree to the approach taken together with
the wording. If Arm was to select HAS_PCI, my expec
> @@ -738,7 +725,8 @@ int evtchn_send(struct domain *ld, unsigned int lport)
>
> lchn = evtchn_from_port(ld, lport);
>
> -spin_lock_irqsave(&lchn->lock, flags);
> +if ( !evtchn_read_trylock(lchn) )
> +return 0;
Isn't there a change in behavior here? While sends through
ECS
With the split of libraries, I've observed a number of warnings from
(old?) ld.
Instead of duplicating the additions in two places, introduce a setup.py
make variable holding all the common parts of the invocations.
Signed-off-by: Jan Beulich
---
v2: Pass on and use SHLIB_libxen*.
---
It's uncle
> On 3 Nov 2020, at 15:59, Rahul Singh wrote:
>
> PCI ATS functionality is not enabled and tested for ARM architecture
> but it is enabled for x86 and referenced in common passthrough/pci.c
> code.
>
> Therefore introducing the new flag to enable the ATS functionality for
> x86 only to avoid
> On 3 Nov 2020, at 15:59, Rahul Singh wrote:
>
> If mem-sharing, mem-paging and log-dirty functionality is not enabled
> for architecture when HAS_PCI is enabled, compiler will throw an error.
>
> Move code to x86 specific directory to fix compilation error.
>
> No functional change.
>
> S
> On 3 Nov 2020, at 15:59, Rahul Singh wrote:
>
> passthrough/pci.c file is common for all architecture, but there is x86
> sepcific code in this file.
>
> Move x86 specific code to the x86 directory to avoid compilation error
> for other architecture.
>
> No functional change.
>
> Signed-o
> On 3 Nov 2020, at 15:59, Rahul Singh wrote:
>
> ARM platforms do not have PCI support available. When CONFIG_HAS_PCI
> is enabled for ARM a compilation error is observed for ns16550 driver.
>
> Fixed compilation error after introducing new kconfig option
> CONFIG_HAS_NS16550_PCI to support
Hi Jan,
> On 4 Nov 2020, at 07:34, Jan Beulich wrote:
>
> On 03.11.2020 20:37, Stefano Stabellini wrote:
>> On Tue, 3 Nov 2020, Jan Beulich wrote:
>>> On 02.11.2020 22:41, Stefano Stabellini wrote:
On Mon, 2 Nov 2020, Jan Beulich wrote:
> On 31.10.2020 01:24, Stefano Stabellini wrote:
>
Hi Stefano,
> On 3 Nov 2020, at 21:15, Stefano Stabellini wrote:
>
> On Tue, 3 Nov 2020, Rich Persaud wrote:
>> On Nov 3, 2020, at 14:37, Stefano Stabellini wrote:
>>>
>>> On Tue, 3 Nov 2020, Jan Beulich wrote:
> On 02.11.2020 22:41, Stefano Stabellini wrote:
> On Mon, 2 Nov 2020, Jan
On Tue, Nov 03, 2020 at 10:46:43AM +0100, Christoph Hellwig wrote:
> ping?
Hopefully this goes through. I am in the process of testing it but ran
into testing issues that I believe are unrelated.
>
> On Fri, Oct 23, 2020 at 08:33:09AM +0200, Christoph Hellwig wrote:
> > The tbl_dma_addr argumen
Fix code style. Don't use '#' flag of printf format ('%#') in
format strings, use '0x' prefix instead
Signed-off-by: Xinhao Zhang
Signed-off-by: Kai Deng
---
hw/xen/xen_pt.c | 10 +-
hw/xen/xen_pt_config_init.c | 6 +++---
hw/xen/xen_pt_msi.c | 16
On Wed, Nov 04, 2020 at 09:06:06AM +, Lee Jones wrote:
> Fixes the following W=1 kernel build warning(s):
>
> drivers/net/xen-netfront.c: In function ‘store_rxbuf’:
> drivers/net/xen-netfront.c:2416:16: warning: variable ‘target’ set but not
> used [-Wunused-but-set-variable]
> drivers/net
On Wed, Nov 04, 2020 at 09:06:03AM +, Lee Jones wrote:
> Fixes the following W=1 kernel build warning(s):
>
> drivers/net/xen-netback/xenbus.c:419: warning: Function parameter or member
> 'dev' not described in 'frontend_changed'
> drivers/net/xen-netback/xenbus.c:419: warning: Function par
On Wed, Nov 4, 2020 at 5:13 AM Jan Beulich wrote:
>
> All,
>
> the release is due in a couple of weeks time. Please point out
> backports you find missing from the respective staging branch,
> but which you consider relevant. (Ian: Please double check
> there are indeed no tools side backports nee
On Mittwoch, 4. November 2020 12:57:04 CET Philippe Mathieu-Daudé wrote:
> Commit b2c00bce54c ("meson: convert hw/9pfs, cleanup") introduced
> CONFIG_9PFS (probably a wrong conflict resolution). This config is
> not used anywhere. Backends depend on CONFIG_FSDEV_9P which itself
> depends on CONFIG_
flight 156389 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156389/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-amd64-xl-rtds 18 guest-localmigrate fail in 156373 pass in 156389
test-amd64-i386-libvirt-qemuu-de
flight 156395 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156395/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
On Wed, Nov 04, 2020 at 09:06:03AM +, Lee Jones wrote:
> Fixes the following W=1 kernel build warning(s):
>
> drivers/net/xen-netback/xenbus.c:419: warning: Function parameter or member
> 'dev' not described in 'frontend_changed'
> drivers/net/xen-netback/xenbus.c:419: warning: Function par
Commit b2c00bce54c ("meson: convert hw/9pfs, cleanup") introduced
CONFIG_9PFS (probably a wrong conflict resolution). This config is
not used anywhere. Backends depend on CONFIG_FSDEV_9P which itself
depends on CONFIG_VIRTFS.
Remove the invalid CONFIG_9PFS and use CONFIG_FSDEV_9P instead, to
fix t
Currently the lock for a single event channel needs to be taken with
interrupts off, which causes deadlocks in some cases.
Rework the per event channel lock to be non-blocking for the case of
sending an event and removing the need for disabling interrupts for
taking the lock.
The lock is needed f
On 04/11/20 09:43, Philippe Mathieu-Daudé wrote:
Fixes './configure --without-default-devices --enable-xen' build:
/usr/bin/ld: libcommon.fa.p/hw_xen_xen-legacy-backend.c.o: in function
`xen_be_register_common':
hw/xen/xen-legacy-backend.c:754: undefined reference to `xen_9pfs_ops'
/us
On 03.11.2020 18:31, Andrew Cooper wrote:
> On 03/11/2020 17:06, Jan Beulich wrote:
>> Prior to 4.15 Linux, when running in PV mode, did not install a #GP
>> handler early enough to cover for example the rdmsrl_safe() of
>> MSR_K8_TSEG_ADDR in bsp_init_amd() (not to speak of the unguarded read
>> o
All,
the release is due in a couple of weeks time. Please point out
backports you find missing from the respective staging branch,
but which you consider relevant. (Ian: Please double check
there are indeed no tools side backports needed here.)
Julien, Stefano, on the Arm side I'd like to ask for
On 04/11/2020 09:56, Jürgen Groß wrote:
On 04.11.20 10:50, Julien Grall wrote:
Hi Juergen,
On 02/11/2020 15:26, Jürgen Groß wrote:
On 02.11.20 16:18, Jan Beulich wrote:
On 02.11.2020 14:59, Jürgen Groß wrote:
On 02.11.20 14:52, Jan Beulich wrote:
On 02.11.2020 14:41, Jürgen Groß wrote:
> -Original Message-
> From: Oleksandr
> Sent: 04 November 2020 09:06
> To: p...@xen.org; xen-devel@lists.xenproject.org
> Cc: 'Oleksandr Tyshchenko' ; 'Jan Beulich'
> ; 'Andrew
> Cooper' ; 'Roger Pau Monné'
> ; 'Julien Grall'
> ; 'Stefano Stabellini' ; 'Wei Liu'
> ; 'Julien
> Grall'
>
On 04.11.20 10:50, Julien Grall wrote:
Hi Juergen,
On 02/11/2020 15:26, Jürgen Groß wrote:
On 02.11.20 16:18, Jan Beulich wrote:
On 02.11.2020 14:59, Jürgen Groß wrote:
On 02.11.20 14:52, Jan Beulich wrote:
On 02.11.2020 14:41, Jürgen Groß wrote:
On 20.10.20 11:28, Jan Beulich wrote:
On 16
Hi Juergen,
On 02/11/2020 15:26, Jürgen Groß wrote:
On 02.11.20 16:18, Jan Beulich wrote:
On 02.11.2020 14:59, Jürgen Groß wrote:
On 02.11.20 14:52, Jan Beulich wrote:
On 02.11.2020 14:41, Jürgen Groß wrote:
On 20.10.20 11:28, Jan Beulich wrote:
On 16.10.2020 12:58, Juergen Gross wrote:
@@
Hi Juergen,
On 16/10/2020 11:58, Juergen Gross wrote:
The queue for a fifo event is depending on the vcpu_id and the
priority of the event. When sending an event it might happen the
event needs to change queues and the old queue needs to be kept for
keeping the links between queue elements intac
On Wed, 4 Nov 2020 09:43:25 +0100
Philippe Mathieu-Daudé wrote:
> Fixes './configure --without-default-devices --enable-xen' build:
>
> /usr/bin/ld: libcommon.fa.p/hw_xen_xen-legacy-backend.c.o: in function
> `xen_be_register_common':
> hw/xen/xen-legacy-backend.c:754: undefined reference
On 04.11.2020 09:15, Juergen Gross wrote:
> Checking whether a lock is consistently used regarding interrupts on
> or off is beneficial for rwlocks, too.
>
> So add check_lock() calls to rwlock functions. For this purpose make
> check_lock() globally accessible.
>
> Signed-off-by: Juergen Gross
Hi Juergen,
On 04/11/2020 08:15, Juergen Gross wrote:
Checking whether a lock is consistently used regarding interrupts on
or off is beneficial for rwlocks, too.
So add check_lock() calls to rwlock functions. For this purpose make
check_lock() globally accessible.
Signed-off-by: Juergen Gross
Hi Juergen,
On 04/11/2020 08:15, Juergen Gross wrote:
Spinlocks and rwlocks behave differently in the try variants regarding
preemption: rwlocks are switching preemption off before testing the
lock, while spinlocks do so only after the first check.
Modify _spin_trylock() to disable preemption b
Hi Juergen,
On 04/11/2020 08:15, Juergen Gross wrote:
Even if a spinlock was taken with interrupts on before calling
spin_trylock() with interrupts off is fine, as it can't block.
Add a bool parameter "try" to check_lock() for handling this case.
Remove the call of check_lock() from _spin_is_l
On 04.11.20 10:06, Lee Jones wrote:
Fixes the following W=1 kernel build warning(s):
drivers/net/xen-netfront.c: In function ‘store_rxbuf’:
drivers/net/xen-netfront.c:2416:16: warning: variable ‘target’ set but not
used [-Wunused-but-set-variable]
Those two warnings are not fixed by the p
Fixes the following W=1 kernel build warning(s):
drivers/net/xen-netfront.c: In function ‘store_rxbuf’:
drivers/net/xen-netfront.c:2416:16: warning: variable ‘target’ set but not
used [-Wunused-but-set-variable]
drivers/net/xen-netfront.c:1592: warning: Function parameter or member 'dev'
not
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
This set is part of a larger effort attempting to clean-up W=1
kernel builds, which are currently overwhelmingly riddled with
niggly little warnings.
This is the last set.
Lee Jones (12):
net: usb: lan78x
Fixes the following W=1 kernel build warning(s):
drivers/net/xen-netback/xenbus.c:419: warning: Function parameter or member
'dev' not described in 'frontend_changed'
drivers/net/xen-netback/xenbus.c:419: warning: Function parameter or member
'frontend_state' not described in 'frontend_changed
On 20.10.20 10:13, Paul Durrant wrote:
Hi Paul.
Sorry for the late response.
+
+/* Called when target domain is paused */
+static inline void arch_hvm_destroy_ioreq_server(struct hvm_ioreq_server *s)
+{
+p2m_set_ioreq_server(s->target, 0, s);
+}
+
+/*
+ * Map or unmap an ioreq server to
Fixes './configure --without-default-devices --enable-xen' build:
/usr/bin/ld: libcommon.fa.p/hw_xen_xen-legacy-backend.c.o: in function
`xen_be_register_common':
hw/xen/xen-legacy-backend.c:754: undefined reference to `xen_9pfs_ops'
/usr/bin/ld: libcommon.fa.p/fsdev_qemu-fsdev.c.o:(.data.r
flight 156388 qemu-mainline real [real]
flight 156392 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/156388/
http://logs.test-lab.xenproject.org/osstest/logs/156392/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be
> -Original Message-
> From: Juergen Gross
> Sent: 04 November 2020 08:22
> To: xen-devel@lists.xenproject.org
> Cc: Juergen Gross ; Jan Beulich ; Paul
> Durrant ;
> Andrew Cooper ; George Dunlap
> ; Ian Jackson
> ; Julien Grall ; Stefano Stabellini
> ; Wei
> Liu
> Subject: [PATCH] xen
pcidevs_trylock() is used nowhere, so remove it.
Signed-off-by: Juergen Gross
---
xen/drivers/passthrough/pci.c | 5 -
xen/include/xen/pci.h | 1 -
2 files changed, 6 deletions(-)
diff --git a/xen/drivers/passthrough/pci.c b/xen/drivers/passthrough/pci.c
index 2a3bce1462..51e584127e
flight 156391 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156391/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 151777
build-i386-libvirt
Even if a spinlock was taken with interrupts on before calling
spin_trylock() with interrupts off is fine, as it can't block.
Add a bool parameter "try" to check_lock() for handling this case.
Remove the call of check_lock() from _spin_is_locked(), as it really
serves no purpose and it can even l
Spinlocks and rwlocks behave differently in the try variants regarding
preemption: rwlocks are switching preemption off before testing the
lock, while spinlocks do so only after the first check.
Modify _spin_trylock() to disable preemption before testing the lock
to be held in order to be preempti
This small series fixes two issues with spinlock debug code and adds
lock debug code to rwlocks in order to catch IRQ violations.
Juergen Gross (3):
xen/spinlocks: spin_trylock with interrupts off is always fine
xen/locking: harmonize spinlocks and rwlocks regarding preemption
xen/rwlock: ad
Checking whether a lock is consistently used regarding interrupts on
or off is beneficial for rwlocks, too.
So add check_lock() calls to rwlock functions. For this purpose make
check_lock() globally accessible.
Signed-off-by: Juergen Gross
---
V2:
- call check_lock() unconditionally in try_lock
Il mer 4 nov 2020, 03:27 Stefano Stabellini ha
scritto:
> FYI I tried to build the latest QEMU on Alpine Linux 3.12 ARM64 and I
> get:
>
> ninja: unknown tool 'query'
>
> Even after rebuilding ninja master by hand. Any ideas? I don't know much
> about ninja.
>
Are you sure you have ninja insta
74 matches
Mail list logo
