Hi
On Tue, Feb 2, 2021 at 11:33 AM Pavel Dovgalyuk
wrote:
> On 02.02.2021 10:27, Marc-André Lureau wrote:
> > Hi
> >
> > On Tue, Feb 2, 2021 at 11:18 AM Pavel Dovgalyuk
> > mailto:pavel.dovgal...@ispras.ru>> wrote:
> >
> > This patch checks that ioc is not null before
> > using it in tcp
Cc'ing migration team and qemu-arm@ list.
On 2/3/21 5:01 AM, Aaron Lindsay wrote:
> Hello,
>
> I'm attempting to restore an AArch64 snapshot taken on QEMU 4.1.0 on
> QEMU 5.2.0, using system mode. My previous impression, possibly from
> https://wiki.qemu.org/Features/Migration/Troubleshooting#Bas
On 03.02.2021 11:13, Marc-André Lureau wrote:
Hi
On Tue, Feb 2, 2021 at 11:33 AM Pavel Dovgalyuk
mailto:pavel.dovgal...@ispras.ru>> wrote:
On 02.02.2021 10:27, Marc-André Lureau wrote:
> Hi
>
> On Tue, Feb 2, 2021 at 11:18 AM Pavel Dovgalyuk
> mailto:pavel.dovgal...@is
01.02.2021 19:20, Vladimir Sementsov-Ogievskiy wrote:
01.02.2021 17:50, Kevin Wolf wrote:
Am 01.02.2021 um 12:03 hat Vladimir Sementsov-Ogievskiy geschrieben:
28.01.2021 18:28, John Snow wrote:
On 1/28/21 10:09 AM, Markus Armbruster wrote:
Vladimir Sementsov-Ogievskiy writes:
I'm developin
Hi
On Wed, Feb 3, 2021 at 12:22 PM Pavel Dovgalyuk
wrote:
> On 03.02.2021 11:13, Marc-André Lureau wrote:
>
> > Can you provide a reproducer?
>
>
> That was a record/replay scenario. I've used Fedora cloudinit images,
> that are used in acceptance tests:
>
> qemu-system-x86_64 \
> -display non
On 02.02.21 05:13, David Gibson wrote:
> At least some s390 cpu models support "Protected Virtualization" (PV),
> a mechanism to protect guests from eavesdropping by a compromised
> hypervisor.
>
> This is similar in function to other mechanisms like AMD's SEV and
> POWER's PEF, which are contr
* James Bottomley (j...@linux.ibm.com) wrote:
> On Tue, 2021-01-26 at 12:32 +, Dr. David Alan Gilbert wrote:
> > * James Bottomley (j...@linux.ibm.com) wrote:
> > > If the gpa isn't specified, it's value is extracted from the OVMF
> > > properties table located below the reset vector (and if th
* Philippe Mathieu-Daudé (phi...@redhat.com) wrote:
> Follow the inclusive terminology from the "Conscious Language in your
> Open Source Projects" guidelines [*] and replace the words "whitelist"
> appropriately.
>
> [*] https://github.com/conscious-lang/conscious-lang-docs/blob/main/faq.md
>
>
On 2/2/21 9:58 PM, Philippe Mathieu-Daudé wrote:
> Follow the inclusive terminology from the "Conscious Language in your
> Open Source Projects" guidelines [*] and replace the word "whitelist"
> appropriately.
>
> [*] https://github.com/conscious-lang/conscious-lang-docs/blob/main/faq.md
>
> Sign
* James Bottomley (j...@linux.ibm.com) wrote:
> On Tue, 2021-01-26 at 12:22 +, Dr. David Alan Gilbert wrote:
> > * James Bottomley (j...@linux.ibm.com) wrote:
> > > OVMF is developing a mechanism for depositing a GUIDed table just
> > > below the known location of the reset vector. The table g
Philippe Mathieu-Daudé writes:
> Follow the inclusive terminology from the "Conscious Language in your
> Open Source Projects" guidelines [*] and replace the word "blacklist"
> appropriately.
>
> [*] https://github.com/conscious-lang/conscious-lang-docs/blob/main/faq.md
>
> Signed-off-by: Phili
Hi Peter,
On 2/2/21 6:54 PM, Peter Maydell wrote:
> Mostly just bug fixes. The important one here is
> hw/intc/arm_gic: Fix interrupt ID in GICD_SGIR register
> which fixes a buffer overrun that's a security issue if you're running
> KVM on Arm with kernel-irqchip=off (which hopefully nobody is
Hi,
> > Well, spice isn't that much better. Has a short, fixed list too:
> >
> > VD_AGENT_CLIPBOARD_UTF8_TEXT
> There has been some attempts to support generic mime types in Spice clipboard:
> https://lists.freedesktop.org/archives/spice-devel/2018-May/043782.html
>
> (If I am not mistaken, I
On Tue, Feb 02, 2021 at 09:58:13PM +0100, Philippe Mathieu-Daudé wrote:
> Follow the inclusive terminology from the "Conscious Language in your
> Open Source Projects" guidelines [*] and replace the words "whitelist"
> appropriately.
>
> [*] https://github.com/conscious-lang/conscious-lang-docs/bl
According to the "ELF-64 Object File Format" specification:
"The first word in the entry, namesz, identifies the length, in
bytes, of a name identifying the entry’s owner or originator. The name field
contains a null-terminated string, with padding as necessary to ensure 8-
byte alignment for t
On Tue, Feb 02, 2021 at 09:50:39PM +0100, Stefan Weil wrote:
> Am 02.02.21 um 21:31 schrieb Stefan Weil:
>
> > The code uses NULL + offset constructs, so requires a fix.
> >
> > https://gitlab.com/gnutls/libtasn1/-/merge_requests/71 fixes the unit
> > tests of libtasn1 for me, maybe also the test
On Wed, 3 Feb 2021 at 04:01, Aaron Lindsay wrote:
>
> Hello,
>
> I'm attempting to restore an AArch64 snapshot taken on QEMU 4.1.0 on
> QEMU 5.2.0, using system mode. My previous impression, possibly from
> https://wiki.qemu.org/Features/Migration/Troubleshooting#Basics was that
> this ought to wo
On Tue, Feb 02, 2021 at 09:58:13PM +0100, Philippe Mathieu-Daudé wrote:
> Follow the inclusive terminology from the "Conscious Language in your
> Open Source Projects" guidelines [*] and replace the words "whitelist"
> appropriately.
>
> [*] https://github.com/conscious-lang/conscious-lang-docs/bl
On Tue, Feb 02, 2021 at 09:58:15PM +0100, Philippe Mathieu-Daudé wrote:
> Follow the inclusive terminology from the "Conscious Language in your
> Open Source Projects" guidelines [*] and replace the word "blacklist"
> appropriately.
>
> Keep the --blacklist available for backward compatibility.
>
'CVE-2021-20221' assigned by Red Hat Inc.
** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2021-20221
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1914353
Title:
QEMU: aarch64: :GIC:
On Tue, Feb 02, 2021 at 09:58:16PM +0100, Philippe Mathieu-Daudé wrote:
> Follow the inclusive terminology from the "Conscious Language in your
> Open Source Projects" guidelines [*] and replace the word "blacklist"
> appropriately.
>
> [*] https://github.com/conscious-lang/conscious-lang-docs/blo
+-- On Wed, 3 Feb 2021, Philippe Mathieu-Daudé wrote --+
| FYI Prasad mentioned a CVE was requested:
| https://www.mail-archive.com/qemu-devel@nongnu.org/msg778659.html
|
| As you said it is an odd configuration, I am not sure it is worth
| to wait for the CVE number to add it to the commit (which
On Tue, Feb 02, 2021 at 09:58:18PM +0100, Philippe Mathieu-Daudé wrote:
> Follow the inclusive terminology from the "Conscious Language in your
> Open Source Projects" guidelines [*] and replace the words "whitelist"
> appropriately.
>
> [*] https://github.com/conscious-lang/conscious-lang-docs/bl
Hi,
As I said on IRC, I’m not sure this additional block_status argument
would be good, because the hole offset needs to be reset when the file
is written to (at least on zero writes; if we additionally stored a data
offset, then that would need to be reset on all writes). Technically,
mirror can
On Tue, Feb 02, 2021 at 09:58:19PM +0100, Philippe Mathieu-Daudé wrote:
> Follow the inclusive terminology from the "Conscious Language in your
> Open Source Projects" guidelines [*] and replace the word "whitelist"
> appropriately.
>
> [*] https://github.com/conscious-lang/conscious-lang-docs/blo
On Tuesday, 2 February, 2021, 08:45:19 pm IST, Peter Maydell
wrote:
>On the CVE:
>
>Since this can affect systems using KVM, this is a security bug for
>us. However, it only affects an uncommon configuration:
>you are only vulnerable if you are using "kernel-irqchip=off"
>(the default is 'on', a
Claudio Fontana writes:
> From: Eduardo Habkost
>
> Signed-off-by: Eduardo Habkost
>
> [claudio: wrapped target code in CONFIG_TCG]
> Signed-off-by: Claudio Fontana
> ---
> include/hw/core/cpu.h | 20 +++-
> accel/tcg/cpu-exec.c | 4 ++--
> target/arm/cpu.c
On Tue, Feb 02, 2021 at 09:58:17PM +0100, Philippe Mathieu-Daudé wrote:
> Follow the inclusive terminology from the "Conscious Language in your
> Open Source Projects" guidelines [*] and replace the words "whitelist"
> appropriately.
>
> [*] https://github.com/conscious-lang/conscious-lang-docs/bl
Claudio Fontana writes:
> commit 40612000599e ("arm: Correctly handle watchpoints for BE32 CPUs")
>
> introduced this ARM-specific, TCG-specific hack to adjust the address,
> before checking it with cpu_check_watchpoint.
>
> Make adjust_watchpoint_address optional and move it to tcg_ops.
>
> Si
8:00 +)
are available in the Git repository at:
https://git.linaro.org/people/pmaydell/qemu-arm.git
tags/pull-target-arm-20210203
for you to fetch changes up to fd8f71b95da86f530aae3d02a14b0ccd9e024772:
hw/arm: Display CPU type in machine description (2021-02-03 10:1
On Tue, Feb 02, 2021 at 09:58:14PM +0100, Philippe Mathieu-Daudé wrote:
> Follow the inclusive terminology from the "Conscious Language in your
> Open Source Projects" guidelines [*] and replace the word "blacklist"
> appropriately.
>
> [*] https://github.com/conscious-lang/conscious-lang-docs/blo
On Tue, Feb 02, 2021 at 09:58:20PM +0100, Philippe Mathieu-Daudé wrote:
> Follow the inclusive terminology from the "Conscious Language in your
> Open Source Projects" guidelines [*] and replace the word "blacklist"
> appropriately.
>
> [*] https://github.com/conscious-lang/conscious-lang-docs/blo
On Tue, Feb 02, 2021 at 09:58:21PM +0100, Philippe Mathieu-Daudé wrote:
> Follow the inclusive terminology from the "Conscious Language in your
> Open Source Projects" guidelines [*] and replace the word "blacklist"
> appropriately.
>
> [*] https://github.com/conscious-lang/conscious-lang-docs/blo
* Philippe Mathieu-Daudé (phi...@redhat.com) wrote:
> Cc'ing migration team and qemu-arm@ list.
I'll have to leave the detail of that to the ARM peole; but from a
migration point of view I think we do want the 64 bit ARM migrations to
be stable now. Please tie incompatible changes to machine type
On 2/3/21 2:08 AM, Eric Blake wrote:
> On 2/2/21 4:50 PM, Denis V. Lunev wrote:
>> On 2/3/21 1:15 AM, Eric Blake wrote:
>>> On 1/28/21 11:21 AM, Vladimir Sementsov-Ogievskiy wrote:
28.01.2021 20:13, Denis V. Lunev wrote:
> Original specification says that l1 table size if 64 * l1_size, whi
On Tue, Feb 02, 2021 at 09:58:22PM +0100, Philippe Mathieu-Daudé wrote:
> Follow the inclusive terminology from the "Conscious Language in your
> Open Source Projects" guidelines [*] and replace the words "blacklist"
> and "whitelist" appropriately.
>
> [*] https://github.com/conscious-lang/consci
On Tue, Feb 02, 2021 at 09:58:23PM +0100, Philippe Mathieu-Daudé wrote:
> Follow the inclusive terminology from the "Conscious Language in your
> Open Source Projects" guidelines [*] and replace the word "blacklist"
> appropriately.
>
> [*] https://github.com/conscious-lang/conscious-lang-docs/blo
On Tue, Feb 02, 2021 at 09:58:24PM +0100, Philippe Mathieu-Daudé wrote:
> Follow the inclusive terminology from the "Conscious Language in your
> Open Source Projects" guidelines [*] and replace the word "blacklist"
> appropriately.
>
> [*] https://github.com/conscious-lang/conscious-lang-docs/blo
On Wed, 3 Feb 2021 at 10:28, Dr. David Alan Gilbert wrote:
>
> * Philippe Mathieu-Daudé (phi...@redhat.com) wrote:
> > Cc'ing migration team and qemu-arm@ list.
>
> I'll have to leave the detail of that to the ARM peole; but from a
> migration point of view I think we do want the 64 bit ARM migrat
On 03/02/2021 - 10:15:55, Daniel P. Berrange wrote:
> On Tue, Feb 02, 2021 at 09:58:20PM +0100, Philippe Mathieu-Daudé wrote:
> > Follow the inclusive terminology from the "Conscious Language in your
> > Open Source Projects" guidelines [*] and replace the word "blacklist"
> > appropriately.
> >
>
* David Gibson (da...@gibson.dropbear.id.au) wrote:
> The platform specific details of mechanisms for implementing
> confidential guest support may require setup at various points during
> initialization. Thus, it's not really feasible to have a single cgs
> initialization hook, but instead each m
On Tue, 2 Feb 2021 at 22:47, Peter Maydell wrote:
>
> On Tue, 2 Feb 2021 at 17:09, Vladimir Sementsov-Ogievskiy
> wrote:
> > Note that 30 is known to crash sometimes. Look at
> >
> > "[PATCH RFC 0/5] Fix accidental crash in iotest 30"
> >
> > https://patchew.org/QEMU/20201120161622.1537-1-vsement
* Peter Maydell (peter.mayd...@linaro.org) wrote:
> On Wed, 3 Feb 2021 at 10:28, Dr. David Alan Gilbert
> wrote:
> >
> > * Philippe Mathieu-Daudé (phi...@redhat.com) wrote:
> > > Cc'ing migration team and qemu-arm@ list.
> >
> > I'll have to leave the detail of that to the ARM peole; but from a
>
On Wed, 3 Feb 2021 at 10:49, Dr. David Alan Gilbert wrote:
>
> * Peter Maydell (peter.mayd...@linaro.org) wrote:
> > On Wed, 3 Feb 2021 at 10:28, Dr. David Alan Gilbert
> > wrote:
> > >
> > > * Philippe Mathieu-Daudé (phi...@redhat.com) wrote:
> > > > Cc'ing migration team and qemu-arm@ list.
>
On Thu, Sep 03, 2020 at 10:02:58PM +0300, Vladimir Sementsov-Ogievskiy wrote:
> We pause reconnect process during drained section. So, if we have some
> requests, waiting for reconnect we should cancel them, otherwise they
> deadlock the drained section.
>
> How to reproduce:
>
> 1. Create an ima
* Peter Maydell (peter.mayd...@linaro.org) wrote:
> On Wed, 3 Feb 2021 at 10:49, Dr. David Alan Gilbert
> wrote:
> >
> > * Peter Maydell (peter.mayd...@linaro.org) wrote:
> > > On Wed, 3 Feb 2021 at 10:28, Dr. David Alan Gilbert
> > > wrote:
> > > >
> > > > * Philippe Mathieu-Daudé (phi...@redh
gt;
> Merge remote-tracking branch
> 'remotes/stefanha-gitlab/tags/tracing-pull-request' into staging (2021-02-01
> 16:28:00 +)
>
> are available in the Git repository at:
>
> https://git.linaro.org/people/pmaydell/qemu-arm.git
> tags/pull-
* Wainer dos Santos Moschetta (waine...@redhat.com) wrote:
>
> On 2/2/21 2:55 AM, misono.tomoh...@fujitsu.com wrote:
> > > Subject: [PATCH 1/1] virtiofsd: Allow to build it without the tools
> > >
> > > This changed the Meson build script to allow virtiofsd be built even
> > > though the tools bu
Since Travis changed their policies, travis-ci.org will soon become
completely useless for the QEMU project. We should now really make sure
that we move the remaining tests as good as possible to the gitlab-CI
instead. Since the gitlab-CI has already quite a lot of jobs, I tried
to squeeze the miss
From: Philippe Mathieu-Daudé
Similarly to commit 8cdb2cef3f1, move the gprof/gcov test to GitLab.
The coverage-summary.sh script is not Travis-CI specific, make it
generic.
Signed-off-by: Philippe Mathieu-Daudé
Message-Id: <20201108204535.2319870-10-phi...@redhat.com>
[thuth: Add gcovr and bsd
Simply add the flag to an existing job, no need for yet another
job here.
Signed-off-by: Thomas Huth
---
.gitlab-ci.yml | 1 +
.travis.yml| 6 --
2 files changed, 1 insertion(+), 6 deletions(-)
diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index 41e11b41e4..4654798523 100644
--- a/.gitla
According to the "ELF-64 Object File Format" specification:
"The first word in the entry, namesz, identifies the length, in
bytes, of a name identifying the entry’s owner or originator. The name field
contains a null-terminated string, with padding as necessary to ensure 8-
byte alignment for t
Add it to the existing Clang job and also add a job that covers the
linux-user code with this compiler flag. To make sure that the detected
problems are not simply ignored, let's also use "-fno-sanitize-recover=..."
now instead.
Signed-off-by: Thomas Huth
---
.gitlab-ci.yml | 13 +++--
.
We already have such jobs in the gitlab-CI ("build-some-softmmu" and
"build-user-plugins"), so we can simply drop these from the Travis-CI.
Signed-off-by: Thomas Huth
---
.travis.yml | 12
1 file changed, 12 deletions(-)
diff --git a/.travis.yml b/.travis.yml
index 45dd017420..b3fc
Both lo_open() and lo_create() have similar code to open a file. Extract
a common lo_do_open() function from lo_open() that will be used by
lo_create() in a later commit.
Since lo_do_open() does not otherwise need fuse_req_t req, convert
lo_add_fd_mapping() to use struct lo_data *lo instead.
Sign
v3:
* Restructure lo_create() to handle externally-created files (we need
to allocate an inode for them) [Greg]
* Patch 1 & 2 refactor the code so that Patch 3 can implement the CVE fix
v3:
* Protect lo_create() [Greg]
v2:
* Add doc comment clarifying that symlinks are traversed client-side
It's only about compile-testing (there is too much noise when running
the tests), so let's simply add the -fsanitize=thread flag to a job that
only compiles the sources. The "build-gprof-gcov" seems to be a good
candidate.
Signed-off-by: Thomas Huth
---
.gitlab-ci.yml | 1 +
.travis.yml| 51
On Tue, Feb 02, 2021 at 10:31:16 +, Peter Maydell wrote:
> On Sun, 24 Jan 2021 at 02:53, Leif Lindholm wrote:
> >
> > Make gicv3_idreg() able to return either gicv3 or gicv4 data.
> > Add a parameter to specify gic version.
> >
> > Signed-off-by: Leif Lindholm
> > ---
> > hw/intc/arm_gicv3_d
lo_do_lookup() finds an existing inode or allocates a new one. It
increments nlookup so that the inode stays alive until the client
releases it.
Existing callers don't need the struct lo_inode so the function doesn't
return it. Extend the function to optionally return the inode. The next
commit wi
A well-behaved FUSE client does not attempt to open special files with
FUSE_OPEN because they are handled on the client side (e.g. device nodes
are handled by client-side device drivers).
The check to prevent virtiofsd from opening special files is missing in
a few cases, most notably FUSE_OPEN. A
On Tue, Feb 02, 2021 at 06:26:25PM +0400, marcandre.lur...@redhat.com wrote:
> From: Marc-André Lureau
>
> This will check virtio/vhost-user-vga & virgl are correctly initialized
> by the Linux kernel on an egl-headless display.
>
> There are many other things that could be checked, but that's a
Patchew URL:
https://patchew.org/QEMU/20210203113719.83633-1-stefa...@redhat.com/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Type: series
Message-id: 20210203113719.83633-1-stefa...@redhat.com
Subject: [PATCH v4 0/3] virtiofsd: prevent ope
On Tue, Feb 02, 2021 at 10:39:22 +, Peter Maydell wrote:
> On Sun, 24 Jan 2021 at 02:53, Leif Lindholm wrote:
> >
> > GICv4 sets aside 256K per redistributor configuration block, whereas GICv3
> > only uses 128K. However, some codebases (like TF-A, EDK2) will happily use
> > the GICv3 function
On 2/3/21 11:11 AM, Alex Bennée wrote:
>
> Claudio Fontana writes:
>
>> From: Eduardo Habkost
>>
>> Signed-off-by: Eduardo Habkost
>>
>> [claudio: wrapped target code in CONFIG_TCG]
>> Signed-off-by: Claudio Fontana
>> ---
>> include/hw/core/cpu.h | 20 +++-
>> accel/tcg/
By the way, as a side note: I see you’re using raw, but qcow2 tries to
avoid deferring the block-status call to file-posix (i.e., it tries to
avoid SEEK_HOLE/DATA calls), because in most cases it knows from its own
metadata which block are zero. So I would guess that with qcow2, the
problem would n
** Changed in: qemu
Status: New => Opinion
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1912777
Title:
KVM_EXIT_MMIO has increased in Qemu4.0.0 when compared to Qemu 2.11.0
Status in QEMU:
On Wed, Feb 03, 2021 at 10:52:59AM +, Peter Maydell wrote:
> On Wed, 3 Feb 2021 at 10:49, Dr. David Alan Gilbert
> wrote:
> >
> > * Peter Maydell (peter.mayd...@linaro.org) wrote:
> > > On Wed, 3 Feb 2021 at 10:28, Dr. David Alan Gilbert
> > > wrote:
> > > >
> > > > * Philippe Mathieu-Daudé
On Wed, 3 Feb 2021, Daniel P. Berrangé wrote:
On Tue, Feb 02, 2021 at 09:58:15PM +0100, Philippe Mathieu-Daudé wrote:
Follow the inclusive terminology from the "Conscious Language in your
Open Source Projects" guidelines [*] and replace the word "blacklist"
appropriately.
Keep the --blacklist a
On Tue, 2 Feb 2021 at 19:31, Eduardo Habkost wrote:
>
> I still have a huge list of patches to review, but I don't keep
> this series stuck in the queue while I try to catch up.
>
> The following changes since commit 74208cd252c5da9d867270a178799abd802b9338:
>
> Merge remote-tracking branch
> '
Currently the alias mapping hash stores just strings of the target
objects internally. In further patches we'll be adding another member
which will need to be stored in the map so convert the members to a
struct.
Signed-off-by: Peter Krempa
---
migration/block-dirty-bitmap.c | 37 +++
See 2/2 for explanation.
Please let me know if I need to add any tests for this.
Peter Krempa (2):
migration: dirty-bitmap: Convert alias map inner members to a struct
migration: dirty-bitmap: Allow control of bitmap persistence on
destination
migration/block-dirty-bitmap.c | 67 +++
Bitmap's source persistence is transported over the migration stream and
the destination mirrors it. In some cases the destination might want to
persist bitmaps which are not persistent on the source (e.g. the result
of merge of bitmaps from a number of layers on the source when migrating
into a sq
03.02.2021 13:53, Roman Kagan wrote:
On Thu, Sep 03, 2020 at 10:02:58PM +0300, Vladimir Sementsov-Ogievskiy wrote:
We pause reconnect process during drained section. So, if we have some
requests, waiting for reconnect we should cancel them, otherwise they
deadlock the drained section.
How to re
Claudio Fontana writes:
> commit 568496c0c0f1 ("cpu: Add callback to check architectural") and
> commit 3826121d9298 ("target-arm: Implement checking of fired")
> introduced an ARM-specific hack for cpu_check_watchpoint.
>
> Make debug_check_watchpoint optional, and move it to tcg_ops.
>
> Sign
This property can be useful for distros to set up known-good ROM sizes for
migration purposes. The VM will fail to start if the ROM is too large,
and migration compatibility will not be broken if the ROM is too small.
v1->v2: fix overflow issues in nearby code [Laszlo]
v2->v3: consistently use %
This property can be useful for distros to set up known-good ROM sizes for
migration purposes. The VM will fail to start if the ROM is too large,
and migration compatibility will not be broken if the ROM is too small.
Note that even though romsize is a uint32_t, it has to be between 1
(because em
get_image_size() returns an int64_t, which pci_add_option_rom() assigns
to an "int" without any range checking. A 32-bit BAR could be up to
2 GiB in size, so reject anything above it. In order to accomodate
a rounded-up size of 2 GiB, change pci_patch_ids's size argument
to unsigned.
Reviewed-by
03.02.2021 16:00, Peter Krempa wrote:
Bitmap's source persistence is transported over the migration stream and
the destination mirrors it. In some cases the destination might want to
persist bitmaps which are not persistent on the source (e.g. the result
of merge of bitmaps from a number of layer
The following changes since commit cf7ca7d5b9faca13f1f8e3ea92cfb2f741eb0c0e:
Merge remote-tracking branch
'remotes/stefanha-gitlab/tags/tracing-pull-request' into staging (2021-02-01
16:28:00 +)
are available in the Git repository at:
https://gitlab.com/bonzini/qemu.git tags/for-upstre
On 2/2/21 5:12 PM, no-re...@patchew.org wrote:
> Patchew URL:
> https://patchew.org/QEMU/20210202224529.642055-1-ebl...@redhat.com/
>
>
>
> Hi,
>
> This series seems to have some coding style problems. See output below for
> more information:
>
> WARNING: added, moved or deleted file(s), doe
On Wed, Feb 03, 2021 at 16:23:21 +0300, Vladimir Sementsov-Ogievskiy wrote:
> 03.02.2021 16:00, Peter Krempa wrote:
> > Bitmap's source persistence is transported over the migration stream and
> > the destination mirrors it. In some cases the destination might want to
> > persist bitmaps which are
On 2/2/21 4:45 PM, Eric Blake wrote:
> The following changes since commit 77f3804ab7ed94b471a14acb260e5aeacf26193f:
>
> Merge remote-tracking branch 'remotes/kevin/tags/for-upstream' into staging
> (2021-02-02 16:47:51 +)
>
> are available in the Git repository at:
>
> https://repo.or.c
Hi
On Wed, Feb 3, 2021 at 3:44 PM Gerd Hoffmann wrote:
>
> On Tue, Feb 02, 2021 at 06:26:25PM +0400, marcandre.lur...@redhat.com wrote:
> > From: Marc-André Lureau
> >
> > This will check virtio/vhost-user-vga & virgl are correctly initialized
> > by the Linux kernel on an egl-headless display.
On 2/1/21 11:09 AM, Claudio Fontana wrote:
> overall, all devices' realize functions take an Error **errp, but return void.
>
> hw/core/qdev.c code, which realizes devices, therefore does:
>
> local_err = NULL;
> dc->realize(dev, &local_err);
> if (local_err != NULL) {
> goto fail;
> }
>
> H
I've spent some more time on this.
I've tcpdump'ed the connection whilst doing the download (via both HTTP & FTP).
In the last data packet, the last byte that is missing on the filesystem
is in the packet, but the packet has the urgent bit set with the urgent
pointer the same as the length of the
On Wed, Feb 03, 2021 at 14:27:49 +0100, Peter Krempa wrote:
> On Wed, Feb 03, 2021 at 16:23:21 +0300, Vladimir Sementsov-Ogievskiy wrote:
> > 03.02.2021 16:00, Peter Krempa wrote:
> > > Bitmap's source persistence is transported over the migration stream and
> > > the destination mirrors it. In som
John Snow writes:
> At present, we open-code this in _make_tree itself; but if the structure
> of the tree changes, this is brittle. Use an explicit recursive call to
> _make_tree when appropriate to help keep the interior node typing
> consistent.
>
> Signed-off-by: John Snow
> ---
> scripts/q
From: Bin Meng
At present the platform clock frequency is using a magic number.
Convert it to a macro and use it everywhere.
Signed-off-by: Bin Meng
---
hw/ppc/e500.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/hw/ppc/e500.c b/hw/ppc/e500.c
index c64b5d0..672cc
The QEMU project is currently considering to move its bug tracking to another
system. For this we need to know which bugs are still valid and which could be
closed already. Thus we are setting older bugs to "Incomplete" now.
If you still think this bug report here is valid, then please switch the
From: Bin Meng
At present the property of the serial node is
populated with value zero. U-Boot's ns16550 driver is not happy
about this, so let's fill in a meaningful value.
Signed-off-by: Bin Meng
---
hw/ppc/e500.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/ppc/e
That patch has been included here:
https://git.qemu.org/?p=qemu.git;a=commitdiff;h=4f8260248c68e4599a5
Thus closing this ticket now.
** Changed in: qemu
Status: Confirmed => Fix Released
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed
On Wednesday, 2021-02-03 at 14:18:27 +01, Paolo Bonzini wrote:
> get_image_size() returns an int64_t, which pci_add_option_rom() assigns
> to an "int" without any range checking. A 32-bit BAR could be up to
> 2 GiB in size, so reject anything above it. In order to accomodate
> a rounded-up size
'remotes/stefanha-gitlab/tags/tracing-pull-request' into staging (2021-02-01
> 16:28:00 +)
>
> are available in the Git repository at:
>
> https://git.linaro.org/people/pmaydell/qemu-arm.git
> tags/pull-target-arm-20210203
>
> for you to fetch changes up to
John Snow writes:
> _tree_to_qlit is called recursively on dict values alone; at such a
> point in generating output it is too late to apply an ifcond. Similarly,
> comments do not necessarily have a "tidy" place they can be printed in
> such a circumstance.
>
> Forbid this usage.
>
> Signed-off-
On 2/3/21 3:01 PM, Bin Meng wrote:
> From: Bin Meng
>
> At present the property of the serial node is
> populated with value zero. U-Boot's ns16550 driver is not happy
> about this, so let's fill in a meaningful value.
>
> Signed-off-by: Bin Meng
> ---
>
> hw/ppc/e500.c | 2 +-
> 1 file chan
On Wednesday, 2021-02-03 at 14:18:28 +01, Paolo Bonzini wrote:
> This property can be useful for distros to set up known-good ROM sizes for
> migration purposes. The VM will fail to start if the ROM is too large,
> and migration compatibility will not be broken if the ROM is too small.
>
> Note t
On 2/3/21 3:01 PM, Bin Meng wrote:
> From: Bin Meng
>
> At present the platform clock frequency is using a magic number.
> Convert it to a macro and use it everywhere.
>
> Signed-off-by: Bin Meng
> ---
>
> hw/ppc/e500.c | 8 +---
> 1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff
The QEMU project is currently considering to move its bug tracking to another
system. For this we need to know which bugs are still valid and which could be
closed already. Thus we are setting older bugs to "Incomplete" now.
If you still think this bug report here is valid, then please switch the
03.02.2021 16:39, Peter Krempa wrote:
On Wed, Feb 03, 2021 at 14:27:49 +0100, Peter Krempa wrote:
On Wed, Feb 03, 2021 at 16:23:21 +0300, Vladimir Sementsov-Ogievskiy wrote:
03.02.2021 16:00, Peter Krempa wrote:
Bitmap's source persistence is transported over the migration stream and
the desti
On Tue, 2 Feb 2021 at 22:57, Michael S. Tsirkin wrote:
> I added a fixup on top, and pushed.
Can you squash fixes into the correct patches in the pullreq, please?
Otherwise it breaks bisection.
thanks
-- PMM
1 - 100 of 509 matches
Mail list logo
