在 2021/3/18 下午12:11, Zhang Chen 写道:
Hi Jason, please merge this series to net queue.
Lukas Straub (2):
net/colo-compare.c: Fix memory leak for non-tcp packet
net/colo-compare.c: Optimize removal of secondary packet
net/colo-compare.c | 3 ++-
1 file changed, 2 insertions(+), 1 deleti
** Changed in: qemu
Status: Incomplete => New
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1880518
Title:
issue while installing docker inside s390x container
Status in QEMU:
New
Bug de
On 19/03/2021 03.25, huang...@chinatelecom.cn wrote:
From: Hyman Huang(黄勇)
Signed-off-by: Hyman Huang(黄勇)
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 25fc49d1dc..20e2387c66 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2525,6 +2525,7
On 18.03.21 21:09, Connor Kuehl wrote:
A patch was recently applied that touched up some error messages that
pertained to key names like 'node-name'. The trouble is it only updated
tests/qemu-iotests/051.pc.out and not tests/qemu-iotests/051.out as
well.
Do that now.
Fixes: 785ec4b1b9 ("bloc
Markus Armbruster writes:
> David Gibson writes:
>
>> On Thu, Mar 11, 2021 at 05:50:42PM -0300, Daniel Henrique Barboza wrote:
>>>
>>>
>>> On 3/9/21 3:22 AM, Markus Armbruster wrote:
>>> > Cc: Paolo and Julia in addition to Igor, because the thread is wandering
>>> > towards DeviceState member
From: Hyman Huang(黄勇)
when executing the following scripts, it throw error message:
$ ./scripts/get_maintainer.pl -f tests/migration/guestperf.py
get_maintainer.pl: No maintainers found, printing recent contributors.
get_maintainer.pl: Do not blindly cc: them on patches! Use common sense.
add t
On 3/18/21 2:10 PM, Eduardo Habkost wrote:
> On Thu, Mar 18, 2021 at 01:59:08PM +0100, Andrew Jones wrote:
>> On Thu, Mar 18, 2021 at 01:42:36PM +0100, Claudio Fontana wrote:
>>> On 3/18/21 1:08 PM, Andrew Jones wrote:
On Thu, Mar 18, 2021 at 12:32:30PM +0100, Claudio Fontana wrote:
> And
Hi Markus,
could you help me untangle the arm_cpu_post_init question?
I am trying to cleanup a bit the initialization path for ARM,
and it seems that arm_cpu_post_init is called numerous times for AArch64 in
particular,
while for "tcg cpus", 32bit it is called only once.
Any reason for the mul
On 18.03.2021 21:16, David Hildenbrand wrote:
On 18.03.21 18:46, Andrey Gruzdev wrote:
The same thing as for incoming postcopy - we cannot deal with concurrent
RAM discards when using background snapshot feature in outgoing
migration.
Signed-off-by: Andrey Gruzdev
---
hw/virtio/virtio-ball
On 3/19/21 9:23 AM, Claudio Fontana wrote:
> Hi Markus,
>
> could you help me untangle the arm_cpu_post_init question?
Nevermind, I think I figured it out. The arm_cpu_post_init are indeed called
only for the "leaf" class,
via the "instance_init" functions.
I think I can use it to do things rel
Clean up the writes to the configuration space and the PM region, and
rename the test to lpc-ich9-test.
Signed-off-by: Paolo Bonzini
---
tests/qtest/{fuzz-test.c => lpc-ich9-test.c} | 12 +++-
tests/qtest/meson.build | 2 +-
2 files changed, 8 insertions(+), 6 delet
Am 18.03.2021 um 20:55 hat Peter Maydell geschrieben:
> On Thu, 18 Mar 2021 at 09:48, Kevin Wolf wrote:
> >
> > The following changes since commit 571d413b5da6bc6f1c2aaca8484717642255ddb0:
> >
> > Merge remote-tracking branch
> > 'remotes/mcayland/tags/qemu-openbios-20210316' into staging (2021
The following changes since commit 8a40754bca14df63c6d2ffe473b68a270dc50679:
Merge remote-tracking branch 'remotes/nvme/tags/nvme-next-pull-request' into
staging (2021-03-18 19:55:37 +)
are available in the Git repository at:
git://repo.or.cz/qemu/kevin.git tags/for-upstream
for you to
On 19.03.21 07:32, Thomas Huth wrote:
On 18/03/2021 18.28, Max Reitz wrote:
[...]
From that it follows that I don’t see much use in testing specific
devices either. Say there’s a platform that provides both virtio-pci
and virtio-mmio, the default (say virtio-pci) is fine for the iotests.
I s
On Sun, Mar 14, 2021 at 09:03:00PM +0100, Laurent Vivier wrote:
Both functions don't check the personality of the interface (legacy or
modern) before accessing the configuration memory and always use
virtio_config_readX()/virtio_config_writeX().
With this patch, they now check the personality an
On 19/03/21 06:53, Markus Armbruster wrote:
I guess this is a reproducer. Please also describe actual and expected
result. Same for PATCH 2.
Isn't it in the patch itself?
Alexander, I think these reproducers are self-contained enough (no
writes to PCI configuration space to set up the devic
+/*
+ * ram_block_populate_pages: populate memory in the RAM block by reading
+ * an integer from the beginning of each page.
+ *
+ * Since it's solely used for userfault_fd WP feature, here we just
+ * hardcode page size to TARGET_PAGE_SIZE.
+ *
+ * @bs: RAM block to populate
+ */
+volatile i
On 19/03/21 10:20, Max Reitz wrote:
On 19.03.21 07:32, Thomas Huth wrote:
On 18/03/2021 18.28, Max Reitz wrote:
[...]
From that it follows that I don’t see much use in testing specific
devices either. Say there’s a platform that provides both virtio-pci
and virtio-mmio, the default (say virt
On 19.03.21 10:28, David Hildenbrand wrote:
+/*
+ * ram_block_populate_pages: populate memory in the RAM block by reading
+ * an integer from the beginning of each page.
+ *
+ * Since it's solely used for userfault_fd WP feature, here we just
+ * hardcode page size to TARGET_PAGE_SIZE.
+ *
+
On Thu, Mar 18, 2021 at 09:30:41PM +0100, Paolo Bonzini wrote:
> On 18/03/21 20:46, Stefan Hajnoczi wrote:
> > The QEMU Project has 50,000 minutes of GitLab CI quota. Let's enable
> > GitLab Merge Requests so that anyone can submit a merge request and get
> > CI coverage.
>
> Each merge request co
Peter Maydell writes:
> On Thu, 18 Mar 2021 at 12:53, Markus Armbruster wrote:
>>
>> I just ran into this failure:
>>
>> $ ../configure --disable-tools --disable-system --static
>>
>> ERROR: sizeof(size_t) doesn't match GLIB_SIZEOF_SIZE_T.
>>You probably need to set PKG_CONFI
On 19/03/21 10:33, Stefan Hajnoczi wrote:
On Thu, Mar 18, 2021 at 09:30:41PM +0100, Paolo Bonzini wrote:
On 18/03/21 20:46, Stefan Hajnoczi wrote:
The QEMU Project has 50,000 minutes of GitLab CI quota. Let's enable
GitLab Merge Requests so that anyone can submit a merge request and get
CI cove
Paolo Bonzini writes:
> On 18/03/21 17:38, Vitaly Kuznetsov wrote:
>>> Could we instead fail to load the reenlightenment section if
>>> user_tsc_khz was not set? This seems to be user (well, management)
>>> error really, since reenlightenment has to be enabled manually (or with
>>> hv-passthroug
Marcelo Tosatti writes:
> On Thu, Mar 18, 2021 at 05:38:00PM +0100, Vitaly Kuznetsov wrote:
>> Paolo Bonzini writes:
>>
>> > On 18/03/21 17:02, Vitaly Kuznetsov wrote:
>> >> KVM doesn't fully support Hyper-V reenlightenment notifications on
>> >> migration. In particular, it doesn't support emu
Paolo Bonzini writes:
> On 19/03/21 06:53, Markus Armbruster wrote:
>> I guess this is a reproducer. Please also describe actual and expected
>> result. Same for PATCH 2.
>
> Isn't it in the patch itself?
A commit message should tell me what the patch is trying to accomplish.
This commit mess
Our gitlab-ci got quite slow in the past weeks, due to the immense amount
of jobs that we have, so we should try to reduce the number of jobs.
There is no real good reason for having separate jobs just to test the
trace backends, we can do this just fine in other jobs, too.
Signed-off-by: Thomas H
On Thu, 18 Mar 2021 at 15:53, Philippe Mathieu-Daudé wrote:
>
> Since v1:
> - Fixed trace format string on 32-bit hosts (Peter)
>
> The following changes since commit 56b89f455894e4628ad7994fe5dd348145d1a9c5:
>
> Merge remote-tracking branch 'remotes/bonzini-gitlab/tags/for-upstream'
> into sta
On Thu, 18 Mar 2021 at 16:38, Markus Armbruster wrote:
>
> The following changes since commit 1db136a29ce8594b693938ab8e788d8bcef54770:
>
> Merge remote-tracking branch
> 'remotes/cleber-gitlab/tags/python-next-pull-request' into staging
> (2021-03-18 14:07:31 +)
>
> are available in the G
Look at 03 for the problem and fix. 01 is preparation and 02 is the
test.
Actually previous version of this thing is
[PATCH v2(RFC) 0/3] qcow2: fix parallel rewrite and discard
Still
[PATCH v3 0/6] qcow2: compressed write cache
includes another fix (more complicated) for the bug, so this i
Add aio_discard command like existing aio_write. It will be used in
further test.
Signed-off-by: Vladimir Sementsov-Ogievskiy
---
qemu-io-cmds.c | 117 +
1 file changed, 117 insertions(+)
diff --git a/qemu-io-cmds.c b/qemu-io-cmds.c
index 97611969
Simple test:
- start writing to allocated cluster A
- discard this cluster
- write to another unallocated cluster B (it's allocated in same place
where A was allocated)
- continue writing to A
For now last action pollutes cluster B which is a bug fixed by the
following commit.
For now, add
There is a bug in qcow2: host cluster can be discarded (refcount
becomes 0) and reused during data write. In this case data write may
pollute another data cluster (recently allocated) or even metadata.
To fix the issue introduce rw-lock: hold read-lock during data writing
take write-lock when refc
Some fixes for shared anonymous memory, cleanups previously sent in other
context (resizeable allocations), followed by RAM_NORESERVE, implementing
it under POSIX using MAP_NORESERVE, and letting users configure it for
memory backens using the "reserve" property (default: true).
MAP_NORESERVE unde
Let's drop the "shared" parameter from ram_block_add() and properly
store it in the flags of the ram block instead, such that
qemu_ram_is_shared() properly succeeds on all ram blocks that were mapped
MAP_SHARED.
We'll use this information next to fix some cases with shared anonymous
memory.
Revie
RAM_SHARED now also properly indicates shared anonymous memory. Let's check
that flag for anonymous memory as well, to restore the proper mapping.
Fixes: 06329ccecfa0 ("mem: add share parameter to memory-backend-ram")
Signed-off-by: David Hildenbrand
---
softmmu/physmem.c | 6 +++---
1 file chan
We can create shared anonymous memory via
"-object memory-backend-ram,share=on,..."
which is, for example, required by PVRDMA for mremap() to work.
Shared anonymous memory is weird, though. Instead of MADV_DONTNEED, we
have to use MADV_REMOVE: MADV_DONTNEED will only remove / zap all
relevant
We want to activate memory within a reserved memory region, to make it
accessible. Let's factor that out.
Reviewed-by: Richard Henderson
Acked-by: Murilo Opsfelder Araujo
Reviewed-by: Peter Xu
Signed-off-by: David Hildenbrand
---
util/mmap-alloc.c | 94 +---
Let's factor out calculating the size of the guard page and rename the
variable to make it clearer that this pagesize only applies to the
guard page.
Reviewed-by: Peter Xu
Acked-by: Murilo Opsfelder Araujo
Cc: Igor Kotrasinski
Signed-off-by: David Hildenbrand
---
util/mmap-alloc.c | 31 ++
We want to reserve a memory region without actually populating memory.
Let's factor that out.
Reviewed-by: Igor Kotrasinski
Acked-by: Murilo Opsfelder Araujo
Reviewed-by: Richard Henderson
Reviewed-by: Peter Xu
Signed-off-by: David Hildenbrand
---
util/mmap-alloc.c | 58 +
Let's include the new property.
Cc: Eric Blake
Cc: Markus Armbruster
Signed-off-by: David Hildenbrand
---
hw/core/machine-qmp-cmds.c | 1 +
qapi/machine.json | 6 ++
2 files changed, 7 insertions(+)
diff --git a/hw/core/machine-qmp-cmds.c b/hw/core/machine-qmp-cmds.c
index 68a942
Let's pass in ram flags just like we do with qemu_ram_alloc_from_file(),
to clean up and prepare for more flags.
Simplify the documentation of passed ram flags: Looking at our
documentation of RAM_SHARED and RAM_PMEM is sufficient, no need to be
repetitive.
Reviewed-by: Peter Xu
Signed-off-by: D
Let's provide a way to control the use of RAM_NORESERVE via memory
backends using the "reserve" property which defaults to true (old
behavior).
Only Linux currently supports setting the flag (and support is checked at
runtime, depending on the setting of "/proc/sys/vm/overcommit_memory").
Windows
FreeBSD version 12.1 is out of service now, and the task in the
Cirrus-CI is failing. Update to 12.2 to get it working again.
Unfortunately, there is a bug in libtasn1 that triggers with the
new version of Clang that is used there (see this thread for details:
https://lists.gnu.org/archive/html/qem
Let's forward ram_flags instead, renaming
memory_region_init_ram_shared_nomigrate() into
memory_region_init_ram_flags_nomigrate(). Forward flags to
qemu_ram_alloc() and qemu_ram_alloc_internal().
Reviewed-by: Peter Xu
Signed-off-by: David Hildenbrand
---
backends/hostmem-ram.c
On 24.02.21 10:48, David Hildenbrand wrote:
A virtio-mem device manages a memory region in guest physical address
space, represented as a single (currently large) memory region in QEMU,
mapped into system memory address space. Before the guest is allowed to use
memory blocks, it must coordinate w
Let's support RAM_NORESERVE via MAP_NORESERVE on Linux. The flag has no
effect on most shared mappings - except for hugetlbfs and anonymous memory.
Linux man page:
"MAP_NORESERVE: Do not reserve swap space for this mapping. When swap
space is reserved, one has the guarantee that it is possible
Let's pass flags instead of bools to prepare for passing other flags and
update the documentation of qemu_ram_mmap(). Introduce new QEMU_MAP_
flags that abstract the mmap() PROT_ and MAP_ flag handling and simplify
it.
We expose only flags that are currently supported by qemu_ram_mmap().
Maybe, we
On 19/03/21 10:54, Markus Armbruster wrote:
A commit message should tell me what the patch is trying to accomplish.
This commit message's title tells me it's a test for a CVE. Okay. The
body additionally gives me the reproducer. To be useful, a reproducer
needs to come with actual and expecte
Let's introduce RAM_NORESERVE, allowing mmap'ing with MAP_NORESERVE. The
new flag has the following semantics:
"
RAM is mmap-ed with MAP_NORESERVE. When set, reserving swap space (or huge
pages if applicable) is skipped: will bail out if not supported. When not
set, the OS might do the reservation
On Fri, Mar 19, 2021 at 09:33:43AM +, Stefan Hajnoczi wrote:
> On Thu, Mar 18, 2021 at 09:30:41PM +0100, Paolo Bonzini wrote:
> > On 18/03/21 20:46, Stefan Hajnoczi wrote:
> > > The QEMU Project has 50,000 minutes of GitLab CI quota. Let's enable
> > > GitLab Merge Requests so that anyone can s
Let's print the new property.
Cc: Markus Armbruster
Cc: Eric Blake
Signed-off-by: David Hildenbrand
---
hw/core/machine-hmp-cmds.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/hw/core/machine-hmp-cmds.c b/hw/core/machine-hmp-cmds.c
index 58248cffa3..fb717f69b9 100644
--- a/hw/core/mac
On 3/19/21 9:07 AM, huang...@chinatelecom.cn wrote:
> From: Hyman Huang(黄勇)
>
> when executing the following scripts, it throw error message:
> $ ./scripts/get_maintainer.pl -f tests/migration/guestperf.py
> get_maintainer.pl: No maintainers found, printing recent contributors.
> get_maintainer.p
Hi Pavel,
The "normal" test_mips_malta timeouted on acceptance-system-fedora job:
(23/36)
tests/acceptance/replay_kernel.py:ReplayKernelNormal.test_mips_malta:
INTERRUPTED: Test interrupted by SIGTERM\nRunner error occurred: Timeout
reached\nOriginal status: ERROR\n{'name':
'23-tests/acceptance/
On Sat, 13 Mar 2021 at 17:01, Philippe Mathieu-Daudé wrote:
>
> When QDev objects have their DeviceReset handler set, they
> shouldn't worry about calling it at realization stage (it
> is handled by hw/core/qdev.c::device_set_realized).
>
> Remove the pointless/confusing bcm2835_fb_reset() call.
>
On Thu, 18 Mar 2021 at 02:38, Gavin Shan wrote:
>
> A clock is added by commit aac63e0e6ea3 ("hw/char/pl011: add a clock
> input") since v5.2.0 which corresponds to virt-5.2 machine type. It
> causes backwards migration failure from upstream to downstream (v5.1.0)
> when the machine type is specif
On 3/18/21 11:39 PM, Laurent Vivier wrote:
> Commit f1d5516ab583 introduces a test in some iotests to check if
> the machine is a s390-ssw-virtio and to select virtio-*-ccw rather
> than virtio-*-pci.
>
> We don't need that because QEMU already provides aliases to use the correct
> virtio interfac
Ping for review, testing, opinions on whether this should go into 6.0 ?
I think I would overall prefer it to the just-bump-PMCR_NUM_COUNTERS
patch...
thanks
-- PMM
On Thu, 11 Mar 2021 at 16:59, Peter Maydell wrote:
>
> Currently we give all the v7-and-up CPUs a PMU with 4 counters. This
> means
Hi Daniel,
I'm getting this error sometimes in the check-dco job:
Using docker image
sha256:96fcfc3ceb2d65689c2918c1c501c45b2bd815d82e7fb3381048c9f252e7b046
for registry.gitlab.com/philmd/qemu2/qemu/centos8:latest with digest
registry.gitlab.com/philmd/qemu2/qemu/centos8@sha256:798eb3e5aa50eb04d6
> Hi,
> According to
> https://lore.kernel.org/dri-devel/20210212110140.gdpu7kapnr7ov...@sirius.home.kraxel.org/
> proposal, we made some progress on making a 'virtio-gpu (display) +
> pass-through GPU' prototype. We leverage the kmsro framework provided
> by mesa to let the virtio-gpu display wor
Le 19/03/2021 à 10:20, Max Reitz a écrit :
> On 19.03.21 07:32, Thomas Huth wrote:
>> On 18/03/2021 18.28, Max Reitz wrote:
>> [...]
>>> From that it follows that I don’t see much use in testing specific devices
>>> either. Say there’s
>>> a platform that provides both virtio-pci and virtio-mmio
Le 19/03/2021 à 10:29, Paolo Bonzini a écrit :
> On 19/03/21 10:20, Max Reitz wrote:
>> On 19.03.21 07:32, Thomas Huth wrote:
>>> On 18/03/2021 18.28, Max Reitz wrote:
>>> [...]
From that it follows that I don’t see much use in testing specific
devices either. Say there’s
a platfo
On 19.03.21 11:50, Laurent Vivier wrote:
Le 19/03/2021 à 10:20, Max Reitz a écrit :
On 19.03.21 07:32, Thomas Huth wrote:
On 18/03/2021 18.28, Max Reitz wrote:
[...]
From that it follows that I don’t see much use in testing specific devices
either. Say there’s
a platform that provides both
W dniu 11.03.2021 o 17:59, Peter Maydell pisze:
Currently we give all the v7-and-up CPUs a PMU with 4 counters. This
means that we don't provide the 6 counters that are required by the
Arm BSA (Base System Architecture) specification if the CPU supports
the Virtualization extensions.
Instead of
On 19/03/2021 11.50, Laurent Vivier wrote:
Le 19/03/2021 à 10:20, Max Reitz a écrit :
On 19.03.21 07:32, Thomas Huth wrote:
On 18/03/2021 18.28, Max Reitz wrote:
[...]
From that it follows that I don’t see much use in testing specific devices
either. Say there’s
a platform that provides bo
Hi,
With all the recent pull requests merged, I'm now seeing
the cross-i386-system reaching the timeout limit:
[5225/5228] Linking target tests/qtest/tpm-tis-device-swtpm-test
[5226/5228] Linking target tests/unit/test-util-sockets
[5227/5228] Compiling C object
tests/unit/test-timed-average.p/te
On 19.03.21 11:51, Max Reitz wrote:
On 19.03.21 11:50, Laurent Vivier wrote:
Le 19/03/2021 à 10:20, Max Reitz a écrit :
On 19.03.21 07:32, Thomas Huth wrote:
On 18/03/2021 18.28, Max Reitz wrote:
[...]
From that it follows that I don’t see much use in testing
specific devices either. Say t
On 19/03/21 11:18, Andrew Jones wrote:
Yikes, that is 41 hours per CI run. I wonder if GitLab's CI minutes are
on slow machines or if we'll hit the same issue with dedicated runners.
It seems like CI optimization will be necessary...
We need to reduce the amount of CI we do, not only because we
On 19/03/21 10:41, Vitaly Kuznetsov wrote:
What I want to achieve is to forbid migration of VMs with
reenlightenment, if they don't also specify tsc-khz to the frequency of
the TSC on the source host. We can't check it at the beginning of
migration, but at least we can check it at the end.
Mayb
On 18/03/21 23:39, Laurent Vivier wrote:
And ioeventfd are only available with virtio-scsi-pci, so don't use the alias
and add a rule to require virtio-scsi-pci for the tests that use iothreads.
Signed-off-by: Laurent Vivier
---
tests/qemu-iotests/127| 4 ++--
tests/qemu-iotests/256
On 19.03.2021 12:28, David Hildenbrand wrote:
+/*
+ * ram_block_populate_pages: populate memory in the RAM block by
reading
+ * an integer from the beginning of each page.
+ *
+ * Since it's solely used for userfault_fd WP feature, here we just
+ * hardcode page size to TARGET_PAGE_SIZE.
+
On 19/03/21 11:51, Laurent Vivier wrote:
It would also make the patches that Laurent sent this morning unnecessary, and
avoid the use of
aliases in the tests (so that it's clear what is tested).
We don't test the virtio frontend, but the blockdev backend, so we don't care
what we use here.
On 19.03.2021 12:32, David Hildenbrand wrote:
On 19.03.21 10:28, David Hildenbrand wrote:
+/*
+ * ram_block_populate_pages: populate memory in the RAM block by
reading
+ * an integer from the beginning of each page.
+ *
+ * Since it's solely used for userfault_fd WP feature, here we just
+ *
On 18/03/2021 18.44, Wainer dos Santos Moschetta wrote:
With the recent move of the unit tests to tests/unit directory some
instructions under the "Unit tests" section became imprecise, which
are fixed by this change.
Fixes: da668aa15b99 ("tests: Move unit tests into a separate directory")
Signe
On 19/03/2021 11.56, Philippe Mathieu-Daudé wrote:
Hi,
With all the recent pull requests merged, I'm now seeing
the cross-i386-system reaching the timeout limit:
I just took 53 minutes in the main repo:
https://gitlab.com/qemu-project/qemu/-/jobs/677521
I assume you were just temporarily
Add pci proxy for virtio-gpu-gl-device.
Signed-off-by: Gerd Hoffmann
---
hw/display/virtio-gpu-pci.c | 27 +++
util/module.c | 1 +
2 files changed, 28 insertions(+)
diff --git a/hw/display/virtio-gpu-pci.c b/hw/display/virtio-gpu-pci.c
index d742a30aecf7.
Currently we have one virtio-gpu device. Problem with this approach is
that if you compile a full-featured qemu you'll get a virtio-gpu device
which depends on opengl and virgl, so these dependencies must be
installed and the libraries will be loaded into memory even if you don't
use virgl. Also
Add pci proxy for virtio-gpu-gl-device, with vga compatibility.
Signed-off-by: Gerd Hoffmann
---
hw/display/virtio-vga.c | 30 ++
util/module.c | 1 +
2 files changed, 31 insertions(+)
diff --git a/hw/display/virtio-vga.c b/hw/display/virtio-vga.c
index d3
Signed-off-by: Gerd Hoffmann
---
include/hw/virtio/virtio-gpu.h | 2 ++
hw/display/virtio-gpu-gl.c | 11 +++
hw/display/virtio-gpu.c| 9 +
3 files changed, 18 insertions(+), 4 deletions(-)
diff --git a/include/hw/virtio/virtio-gpu.h b/include/hw/virtio/virtio-gpu.h
"3d" -> "virgl" as 3d is a rather broad term.
Hopefully a bit less confusing.
Signed-off-by: Gerd Hoffmann
---
hw/display/{virtio-gpu-3d.c => virtio-gpu-virgl.c} | 0
hw/display/meson.build | 2 +-
2 files changed, 1 insertion(+), 1 deletion(-)
rename hw/display/{vir
Signed-off-by: Gerd Hoffmann
---
include/hw/virtio/virtio-gpu.h | 8 +++-
hw/display/virtio-gpu.c| 12 +---
2 files changed, 16 insertions(+), 4 deletions(-)
diff --git a/include/hw/virtio/virtio-gpu.h b/include/hw/virtio/virtio-gpu.h
index a7b7d78310ea..380aa7dd6322 100644
Signed-off-by: Gerd Hoffmann
---
util/module.c | 4 +++-
hw/display/meson.build | 11 ---
2 files changed, 11 insertions(+), 4 deletions(-)
diff --git a/util/module.c b/util/module.c
index 0bbe2b25fbec..98a7e751 100644
--- a/util/module.c
+++ b/util/module.c
@@ -182,6 +182,
Just a skeleton for starters, following patches will add more code.
Signed-off-by: Gerd Hoffmann
---
include/hw/virtio/virtio-gpu.h | 7 ++
hw/display/virtio-gpu-gl.c | 41 ++
util/module.c | 1 +
hw/display/meson.build | 2 +-
Move device init (realize) and properties.
Drop the virgl property, the virtio-gpu-gl-device has virgl enabled no
matter what. Just use virtio-gpu-device instead if you don't want
enable virgl and opengl. This simplifies the logic and reduces the test
matrix.
Signed-off-by: Gerd Hoffmann
---
On Fri, 19 Mar 2021 at 06:45, Markus Armbruster wrote:
>
> The following changes since commit 8a40754bca14df63c6d2ffe473b68a270dc50679:
>
> Merge remote-tracking branch 'remotes/nvme/tags/nvme-next-pull-request'
> into staging (2021-03-18 19:55:37 +)
>
> are available in the Git repository
Drops last virgl/opengl dependency from virtio-gpu-device.
Signed-off-by: Gerd Hoffmann
---
hw/display/virtio-gpu.c | 17 -
1 file changed, 17 deletions(-)
diff --git a/hw/display/virtio-gpu.c b/hw/display/virtio-gpu.c
index 2c0065277ffd..34cf35127a3d 100644
--- a/hw/display/vir
Signed-off-by: Gerd Hoffmann
---
include/hw/virtio/virtio-gpu.h | 1 +
hw/display/virtio-gpu-gl.c | 17 +
hw/display/virtio-gpu.c| 19 +--
3 files changed, 19 insertions(+), 18 deletions(-)
diff --git a/include/hw/virtio/virtio-gpu.h b/include/hw/virt
On 19.03.21 12:05, Andrey Gruzdev wrote:
On 19.03.2021 12:28, David Hildenbrand wrote:
+/*
+ * ram_block_populate_pages: populate memory in the RAM block by
reading
+ * an integer from the beginning of each page.
+ *
+ * Since it's solely used for userfault_fd WP feature, here we just
+ * ha
Signed-off-by: Gerd Hoffmann
---
include/hw/virtio/virtio-gpu.h | 6 ++
hw/display/virtio-gpu-gl.c | 30 +++
hw/display/virtio-gpu.c| 38 ++
3 files changed, 42 insertions(+), 32 deletions(-)
diff --git a/include/hw/virtio/
Move two virglrenderer state variables to struct VirtIOGPUGL.
Signed-off-by: Gerd Hoffmann
---
include/hw/virtio/virtio-gpu.h | 5 +++--
hw/display/virtio-gpu-gl.c | 15 +--
2 files changed, 12 insertions(+), 8 deletions(-)
diff --git a/include/hw/virtio/virtio-gpu.h b/include/
Signed-off-by: Gerd Hoffmann
---
hw/display/virtio-gpu-gl.c | 13 +
hw/display/virtio-gpu.c| 15 ---
2 files changed, 13 insertions(+), 15 deletions(-)
diff --git a/hw/display/virtio-gpu-gl.c b/hw/display/virtio-gpu-gl.c
index 6d0ce5bcd6f1..e976fb8d04c4 100644
--- a/h
On Fri, 19 Mar 2021 12:06:43 +0100
Paolo Bonzini wrote:
> On 18/03/21 23:39, Laurent Vivier wrote:
> > And ioeventfd are only available with virtio-scsi-pci, so don't use the
> > alias
> > and add a rule to require virtio-scsi-pci for the tests that use iothreads.
> >
> > Signed-off-by: Laurent
Signed-off-by: Gerd Hoffmann
---
hw/display/virtio-gpu-gl.c | 33 +
hw/display/virtio-gpu.c| 13 -
2 files changed, 33 insertions(+), 13 deletions(-)
diff --git a/hw/display/virtio-gpu-gl.c b/hw/display/virtio-gpu-gl.c
index c3e562f835f7..6d0ce5bcd
On 3/19/21 11:59 AM, Paolo Bonzini wrote:
> On 19/03/21 11:18, Andrew Jones wrote:
>>> Yikes, that is 41 hours per CI run. I wonder if GitLab's CI minutes are
>>> on slow machines or if we'll hit the same issue with dedicated runners.
>>> It seems like CI optimization will be necessary...
>>>
>> We
Now that we have separated the gl and non-gl code flows to two different
devices there is little reason turn on and off virglrenderer usage at
runtime. The gl code can simply use virglrenderer unconditionally.
So drop use_virgl_renderer field and just do that.
Signed-off-by: Gerd Hoffmann
---
On Thu, 18 Mar 2021 23:39:04 +0100
Laurent Vivier wrote:
> Similarly to 5f629d943cb0 ("s390x: fix s390 virtio aliases"),
> define the virtio aliases.
>
> This allows to start machines with virtio devices without
> knowledge of the implementation type.
>
> For instance, we can use "-device virti
When building qemu with GCC 11, test-block-iothread produces the following
warning:
../tests/unit/test-block-iothread.c:148:11: error: ‘buf’ may be used
uninitialized [-Werror=maybe-uninitialized]
This is caused by buf[512] left uninitialized and passed to
bdrv_save_vmstate() that expects a const
On 19/03/21 12:22, Emanuele Giuseppe Esposito wrote:
When building qemu with GCC 11, test-block-iothread produces the following
warning:
../tests/unit/test-block-iothread.c:148:11: error: ‘buf’ may be used
uninitialized [-Werror=maybe-uninitialized]
This is caused by buf[512] left uninitialized
Patchew URL:
https://patchew.org/QEMU/20210319112147.4138943-1-kra...@redhat.com/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Type: series
Message-id: 20210319112147.4138943-1-kra...@redhat.com
Subject: [PATCH 00/15] virtio-gpu: split into
Le 19/03/2021 à 12:27, Cornelia Huck a écrit :
> On Fri, 19 Mar 2021 12:06:43 +0100
> Paolo Bonzini wrote:
>
>> On 18/03/21 23:39, Laurent Vivier wrote:
>>> And ioeventfd are only available with virtio-scsi-pci, so don't use the
>>> alias
>>> and add a rule to require virtio-scsi-pci for the tes
On 3/19/21 10:41 AM, Paolo Bonzini wrote:
> On 19/03/21 10:33, Stefan Hajnoczi wrote:
>> On Thu, Mar 18, 2021 at 09:30:41PM +0100, Paolo Bonzini wrote:
>>> On 18/03/21 20:46, Stefan Hajnoczi wrote:
The QEMU Project has 50,000 minutes of GitLab CI quota. Let's enable
GitLab Merge Requests
1 - 100 of 268 matches
Mail list logo
