On 2019/4/15 17:25, Daniel P. Berrangé wrote:
On Sat, Apr 13, 2019 at 10:54:40AM +0800, Pu Wen wrote:
...
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index f2c15bf..551bec9 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -128,6 +128,8 @@ GlobalProperty pc_compat_3_1[] = {
{ "EPYC" "-" TYPE_X
13.04.2019 19:53, Max Reitz wrote:
> This adds a salvaging mode (--salvage) to qemu-img convert which ignores
> read errors and treats the respective areas as containing only zeroes.
> This can be used for instance to at least partially recover the data
> from terminally corrupted qcow2 images.
>
16.04.2019 9:34, Markus Armbruster wrote:
> Vladimir Sementsov-Ogievskiy writes:
>
>> 15.04.2019 16:08, Markus Armbruster wrote:
>>> Vladimir Sementsov-Ogievskiy writes:
>>>
15.04.2019 8:51, Markus Armbruster wrote:
> Vladimir Sementsov-Ogievskiy writes:
>
>> It would be nice t
Vladimir Sementsov-Ogievskiy writes:
> 15.04.2019 16:08, Markus Armbruster wrote:
>> Vladimir Sementsov-Ogievskiy writes:
>>
>>> 15.04.2019 8:51, Markus Armbruster wrote:
Vladimir Sementsov-Ogievskiy writes:
> It would be nice to have Error object not freed away when debugging a
"Dr. David Alan Gilbert" writes:
> * Markus Armbruster (arm...@redhat.com) wrote:
>> CPUClass method dump_statistics() takes an fprintf()-like callback and
>> a FILE * to pass to it. Most callers pass fprintf() and stderr.
>> log_cpu_state() passes fprintf() and qemu_log_file.
>> hmp_info_regist
"Dr. David Alan Gilbert" writes:
> * Markus Armbruster (arm...@redhat.com) wrote:
>> The various dump_mmu() take an fprintf()-like callback and a FILE * to
>> pass to it, and so do their helper functions. Passing around callback
>> and argument is rather tiresome.
>>
>> Most dump_mmu() are call
"Dr. David Alan Gilbert" writes:
> * Markus Armbruster (arm...@redhat.com) wrote:
>> The various TARGET_cpu_list() take an fprintf()-like callback and a
>> FILE * to pass to it. Their callers (vl.c's main() via list_cpus(),
>> bsd-user/main.c's main(), linux-user/main.c's main()) all pass
>> fpr
Can you please provide the complete QEMU command line when reporting
QEMU bugs? Just dumping a log of Nova is not very useful for debugging
QEMU problems. Thanks.
** Changed in: qemu
Status: New => Incomplete
--
You received this bug notification because you are a member of qemu-
devel-ml
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 subscribe
Seems like this has been fixed in recent versions of QEMU again:
$ qemu-system-x86_64 -serial telnet::0,server,nowait -nographic
QEMU 3.1.93 monitor - type 'help' for more information
(qemu) info chardev
parallel0: filename=null
serial0: filename=disconnected:telnet:0.0.0.0:41346,server
compat_mon
Feel free to send some patches to implement this! Alternatively, you
could also try to write a mail to the virtio-rng maintainer (see the
MAINTAINER file in the top directory of the sources), maybe he can help.
** Changed in: qemu
Importance: Undecided => Wishlist
--
You received this bug not
Marking this bug as fixed according to comment 2.
** Changed in: qemu
Status: New => Fix Released
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1824053
Title:
Qemu-img convert appears to be
Ok, so marking this bug as "fixed" according to Marc's comment.
** Changed in: qemu
Status: New => Fix Released
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1788582
Title:
Race condition d
These implementations have a few deficiencies that are noted, but are
good enough for Linux to use.
Signed-off-by: Nicholas Piggin
---
v3: Removed wrong comment about GPR3, drop H_JOIN for now (at least until
it is tested some more in Linux/KVM), and expand the comment about not
prod bit.
hw/p
Returning -1 does not help because all that signals that the buffer is full.
We then flush the buffer and try again, assuming the at the buffer will not
fill.
Given that the buffer is usually many megabytes, this is reasonable.
We need something different to signal that the buffer is not full, bu
On Mon, Apr 08, 2019 at 04:42:13AM -0400, Catherine Ho wrote:
> Commit 18269069c310 ("migration: Introduce ignore-shared capability")
> addes ignore-shared capability to bypass the shared ramblock (e,g,
> membackend + numa node). It does good to live migration.
>
> As told by Yury,this commit expe
any word on this? If this is not considered for adoption, i would like
to know the reason, so that we can have better predictions about what to
do for entropy in a QEMU system.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://
On Tue, Mar 12, 2019 at 10:36 AM Markus Armbruster wrote:
>
> Dear board code maintainers,
>
> This is a (rather late) follow-up to the last QEMU summit. Minutes[*]:
>
> * Deprecating unmaintained features (devices, targets, backends) in QEMU
>
>QEMU has a mechanism to deprecate features but
Ping, thanks
B.R.
Catherine
On Mon, 8 Apr 2019 at 16:43, Catherine Ho wrote:
> Commit 18269069c310 ("migration: Introduce ignore-shared capability")
> addes ignore-shared capability to bypass the shared ramblock (e,g,
> membackend + numa node). It does good to live migration.
>
> As told by Yur
MSI mapping needs to be update when MSI address changes, so add the
code to do so.
Signed-off-by: Andrey Smirnov
Cc: Peter Maydell
Cc: Michael S. Tsirkin
Cc: qemu-devel@nongnu.org
Cc: qemu-...@nongnu.org
---
hw/pci-host/designware.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/hw/pci-
Expression to calculate update_msi_mapping in code handling writes to
DESIGNWARE_PCIE_MSI_INTR0_ENABLE is missing an ! operator and should
be:
!!root->msi.intr[0].enable ^ !!val;
so that MSI mapping is updated when enabled transitions from either
"none" -> "any" or "any" -> "none". Since that
Add no-op/unimplemented PCIE PHY IP block. Needed by new kernels to
use PCIE.
Signed-off-by: Andrey Smirnov
Cc: Peter Maydell
Cc: Michael S. Tsirkin
Cc: qemu-devel@nongnu.org
Cc: qemu-...@nongnu.org
---
include/hw/arm/fsl-imx7.h | 3 +++
hw/arm/fsl-imx7.c | 5 +
2 files changed, 8
Instantiate no-op APBH DMA module. Needed to boot latest Linux kernel.
Signed-off-by: Andrey Smirnov
Cc: Peter Maydell
Cc: Michael S. Tsirkin
Cc: qemu-devel@nongnu.org
Cc: qemu-...@nongnu.org
---
include/hw/arm/fsl-imx7.h | 3 +++
hw/arm/fsl-imx7.c | 6 ++
2 files changed, 9 insert
Datasheet for i.MX7 is incorrect and i.MX7's PCI IRQ mapping matches
that of i.MX6:
* INTD/MSI122
* INTC123
* INTB124
* INTA125
Fix all of the relevant code to reflect that fact. Needed by latest
Linux kernels.
Signed-off-by: Andrey Smirnov
Cc: Peter
Everyone:
I recently revisited my i.MX7 work and this series contains all of the
fixes I had to make to get it to work with latest (5.1-rc1) Linux
kernel again as well as fixes for genuine bugs that I somehow missed
during original submission ("pci: designware" patches). Hopefully each
patch is se
On 4/11/19 4:01 AM, Yuval Shaia wrote:
> +++ b/drivers/infiniband/hw/virtio/Kconfig
> @@ -0,0 +1,6 @@
> +config INFINIBAND_VIRTIO_RDMA
> + tristate "VirtIO Paravirtualized RDMA Driver"
> + depends on NETDEVICES && ETHERNET && PCI && INET
> + ---help---
> + This driver provides low
For any chip that has a CLINT, we want the frequency of the time register
and the frequency of the CLINT to match. That frequency,
SIFIVE_CLINT_TIMEBASE_FREQ
(=10MHz) is currently defined in hw/riscv/sifive_clint.h and so isn't
visible to target/riscv/cpu.c where the CPURISCVState is first created.
On Fri, Apr 12, 2019 at 12:04 PM Jonathan Behrens wrote:
>
> Currently mcounteren.TM acts as though it is hardwired to zero, even though
> QEMU
> allows it to be set. This change resolves the issue by allowing reads to the
> time and timeh control registers when running in a privileged mode where
On Mon, Apr 15, 2019 at 1:38 AM Igor Mammedov wrote:
>
> On Fri, 12 Apr 2019 14:19:16 -0700
> Alistair Francis wrote:
>
...
> > >
> > > if it's programming error it should be assert
> > > but in general instance_init() should never fail.
> >
> > We are checking for a user specified CPU string,
No, sorry - this bugs still persists w/ latest upstream (@ afccfc0). I
found a report of similar symptoms:
https://patchwork.kernel.org/patch/10047341/
https://bugzilla.redhat.com/show_bug.cgi?id=1524770#c13
To be clear, ^ is already fixed upstream, so it is not the *same* issue
- but perhaps
On 4/16/19 1:34 AM, Wei Li wrote:
> Hi @Paolo Bonzini & @Stefan Hajnoczi,
>
> Would you please help confirm whether @Paolo Bonzini's multiqueue feature
> change will benefit virtio-scsi or not? Thanks!
>
> @Stefan Hajnoczi,
> I also spent some time on exploring the virtio-scsi multi-queue fea
** Changed in: qemu
Status: New => Confirmed
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1805256
Title:
qemu-img hangs on high core count ARM system
Status in QEMU:
Confirmed
Bug descr
On Mon, Apr 15, 2019 at 3:20 PM Max Filippov wrote:
> recent qemu-system-i386 for w64 (e.g. one installed from
> https://qemu.weilnetz.de/w64/qemu-w64-setup-20190218.exe )
> refuses to load multiboot kernel by default:
>
> "C:\Program Files\qemu\qemu-system-i386.exe" -kernel p:\tmp\kernel
> C:
Hello,
recent qemu-system-i386 for w64 (e.g. one installed from
https://qemu.weilnetz.de/w64/qemu-w64-setup-20190218.exe )
refuses to load multiboot kernel by default:
"C:\Program Files\qemu\qemu-system-i386.exe" -kernel p:\tmp\kernel
C:\Program Files\qemu\qemu-system-i386.exe: Error loading
On Sat, Apr 13, 2019 at 10:54:40AM +0800, Pu Wen wrote:
> Add a new base CPU model called 'Dhyana' to model processors from Hygon
> Dhyana(family 18h), which derived from AMD EPYC(family 17h).
>
> The following features bits have been removed compare to AMD EPYC:
> aes, pclmulqdq, sha_ni
>
> The
** Description changed:
[impact]
on shutdown of a guest, there is a race condition that results in qemu
crashing instead of normally shutting down. The bt looks similar to
this (depending on the specific version of qemu, of course; this is
taken from 2.5 version of qemu):
(gdb)
Hi, unfortunately a lot has changed from 2.8 and it might be hard to
identify a single individual fix that may be responsible for this; there
are aio_context fixes that go in nearly every version.
It may be quickest (unfortunately) to start git-bisecting the problem to
see if you can identify whic
On 4/13/19 5:02 AM, Joachim Durchholz wrote:
> Hi all,
>
> what's the reasoning behind "We need a terminal output" in curses.c?
>
> I don't really see a scenario where it's problematic if qemu emits
> escape sequences to a pipe.
> I have experienced one scenario where it is problematic: It does
On 4/15/19 6:23 AM, Programmingkid wrote:
>
>> On Apr 15, 2019, at 5:54 AM, Stefan Hajnoczi wrote:
>>
>> On Sun, Apr 14, 2019 at 07:33:17PM -0400, Programmingkid wrote:
>>> Hi I was wondering if anyone has been able to boot from a bootcamp
>>> partition inside of QEMU. I know this partition c
Patchew URL:
https://patchew.org/QEMU/20190415180618.1450-1-samuel.thiba...@ens-lyon.org/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Message-id: 20190415180618.1450-1-samuel.thiba...@ens-lyon.org
Subject: [Qemu-devel] [PULL 0/1] slirp gcc9
From: "Dr. David Alan Gilbert"
Gcc 9 needs some convincing that sopreprbuf really is going to fill
in iov in the call from soreadbuf, even though the failure case
shouldn't happen.
Signed-off-by: Dr. David Alan Gilbert
Message-Id: <20190415121740.9881-1-dgilb...@redhat.com>
Signed-off-by: Samue
Dr. David Alan Gilbert (git), le lun. 15 avril 2019 13:17:40 +0100, a ecrit:
> From: "Dr. David Alan Gilbert"
>
> Gcc 9 needs some convincing that sopreprbuf really is going to fill
> in iov in the call from soreadbuf, even though the failure case
> shouldn't happen.
>
> Signed-off-by: Dr. David
The following changes since commit afccfc0c4c6134a7bc9da6375996b3b91d291de4:
Merge remote-tracking branch 'remotes/kevin/tags/for-upstream' into staging
(2019-04-12 17:06:49 +0100)
are available in the Git repository at:
https://people.debian.org/~sthibault/qemu.git tags/samuel-thibault
fo
Hi @Paolo Bonzini & @Stefan Hajnoczi,
Would you please help confirm whether @Paolo Bonzini's multiqueue feature
change will benefit virtio-scsi or not? Thanks!
@Stefan Hajnoczi,
I also spent some time on exploring the virtio-scsi multi-queue features via
num_queues parameter as below, here are
Also attaching static-compiled executable "s2.exe".
** Attachment added: "s2.exe"
https://bugs.launchpad.net/qemu/+bug/1824853/+attachment/5256000/+files/s2.exe
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchp
Public bug reported:
I tried to bootstrap and regtested gcc trunk (gcc svn rev 270278,
datestamp 20190411) inside my arm64-gentoo installation under qemu-
system-aarch64.
Qemu version was 4.0.0-rc3 and -cpu cortex-a57. Qemu configured with
only --target-list=aarch64-softmmu,aarch64-linux-user and
On Mon, 15 Apr 2019 at 18:10, Eric Blake wrote:
> On 4/15/19 10:45 AM, Daniel P. Berrangé wrote:
> > The 2nd patch in this series is a security flaw fix since the
> > code was not correctly validating guest provided data length.
>
> Given that this is a security flaw, I've added this series to
> h
On 4/15/19 10:45 AM, Daniel P. Berrangé wrote:
> Two previous attempts to fix this due to GCC 9 highlighting
> unaligned data access. My attempt:
>
> https://lists.gnu.org/archive/html/qemu-devel/2019-03/msg07763.html
>
> And a previous one:
>
> https://lists.gnu.org/archive/html/qemu-devel/
Daniel P. Berrangé writes:
> The ObjectInfo 'length' field provides the length of the
> wide character string filename. This is then converted to
> a multi-byte character string. This may have a different
> byte count to the wide character string. We should use the
> C string length of the multi-
On Mon, Apr 15, 2019 at 12:52:41PM -0400, Bandan Das wrote:
> Daniel P. Berrangé writes:
>
> > Two previous attempts to fix this due to GCC 9 highlighting
> > unaligned data access. My attempt:
> >
> > https://lists.gnu.org/archive/html/qemu-devel/2019-03/msg07763.html
> >
> > And a previous on
Daniel P. Berrangé writes:
> Two previous attempts to fix this due to GCC 9 highlighting
> unaligned data access. My attempt:
>
> https://lists.gnu.org/archive/html/qemu-devel/2019-03/msg07763.html
>
> And a previous one:
>
> https://lists.gnu.org/archive/html/qemu-devel/2019-02/msg07923.html
Forgot to cc people ...
Bandan Das writes:
> Commit c5ead51f90cf (usb-mtp: return incomplete transfer on a lstat
> failure) checks if lstat succeeded when updating attributes of a
> file. However, it also changed behavior to return an error by
> default. This is incorrect because for smaller fil
* Markus Armbruster (arm...@redhat.com) wrote:
> CPUClass method dump_statistics() takes an fprintf()-like callback and
> a FILE * to pass to it. Most callers pass fprintf() and stderr.
> log_cpu_state() passes fprintf() and qemu_log_file.
> hmp_info_registers() passes monitor_fprintf() and the cu
Commit c5ead51f90cf (usb-mtp: return incomplete transfer on a lstat
failure) checks if lstat succeeded when updating attributes of a
file. However, it also changed behavior to return an error by
default. This is incorrect because for smaller file sizes, Qemu
will attempt to write the file in one
On Fri, 1 Mar 2019 10:38:56 +0100
Cornelia Huck wrote:
> [This is the Linux kernel part, git tree is available at
> https://git.kernel.org/pub/scm/linux/kernel/git/kvms390/vfio-ccw.git
> vfio-ccw-eagain-caps-v3
>
> The companion QEMU patches are available at
> https://github.com/cohuck/qemu vf
On Mon, Apr 15, 2019 at 06:33:36PM +0200, Marc-André Lureau wrote:
> Commit 767abe7 ("chardev: forbid 'wait' option with client sockets")
> is a bit too strict. Current libvirt always set wait=false, and will
> thus fail to add client chardev.
>
> Make the code more permissive, allowing wait=false
On 4/15/19 10:54 AM, Kevin Wolf wrote:
> preallocate_co() already gave the data file the full size without
> forwarding the requested preallocation mode to the protocol. When
> bdrv_co_truncate() was called later with the preallocation mode, the
> file didn't actually grow any more, so the data fil
Commit 767abe7 ("chardev: forbid 'wait' option with client sockets")
is a bit too strict. Current libvirt always set wait=false, and will
thus fail to add client chardev.
Make the code more permissive, allowing wait=false with client socket
chardevs. Deprecate usage of 'wait' with client sockets.
On Mon, Apr 15, 2019 at 6:27 PM Daniel P. Berrangé wrote:
>
> On Mon, Apr 15, 2019 at 06:21:29PM +0200, Marc-André Lureau wrote:
> > Commit 767abe7 ("chardev: forbid 'wait' option with client sockets")
> > is a bit too strict. Current libvirt always set wait=false, and will
> > thus fail to add cl
On Mon, Apr 15, 2019 at 06:21:29PM +0200, Marc-André Lureau wrote:
> Commit 767abe7 ("chardev: forbid 'wait' option with client sockets")
> is a bit too strict. Current libvirt always set wait=false, and will
> thus fail to add client chardev.
>
> Make the code more permissive, allowing wait=false
Commit 767abe7 ("chardev: forbid 'wait' option with client sockets")
is a bit too strict. Current libvirt always set wait=false, and will
thus fail to add client chardev.
Make the code more permissive, allowing wait=false with client socket
chardevs. Deprecate usage of 'wait' with client sockets.
On 4/15/19 10:54 AM, Kevin Wolf wrote:
> We'll add a bdrv_co_truncate() call in the next patch which can return
> an Error that we don't want to discard. So add an errp parameter to
> preallocate_co().
>
> Cc: qemu-sta...@nongnu.org
> Signed-off-by: Kevin Wolf
> ---
> block/qcow2.c | 11 ++--
On 4/15/19 10:49 AM, Marc-André Lureau wrote:
> Commit 767abe7 ("chardev: forbid 'wait' option with client sockets")
> is a bit too strict. Current libvirt always set wait=false, and will
> thus fail to add client chardev.
>
> Make the code more permissive, allowing wait=false with client socket
>
On Mon, Apr 15, 2019 at 06:16:33PM +0200, Marc-André Lureau wrote:
> On Mon, Apr 15, 2019 at 6:08 PM Daniel P. Berrangé
> wrote:
> >
> > On Mon, Apr 15, 2019 at 06:06:09PM +0200, Marc-André Lureau wrote:
> > > Commit 767abe7 ("chardev: forbid 'wait' option with client sockets")
> > > is a bit too
On 4/15/19 10:54 AM, Kevin Wolf wrote:
> With an external data file, preallocate_co() must write the final byte
> to the external data file, not to the qcow2 image file.
>
> This is harmless for preallocation of newly created images (only the
> qcow2 file size is increased to the virtual disk size
On Mon, Apr 15, 2019 at 6:08 PM Daniel P. Berrangé wrote:
>
> On Mon, Apr 15, 2019 at 06:06:09PM +0200, Marc-André Lureau wrote:
> > Commit 767abe7 ("chardev: forbid 'wait' option with client sockets")
> > is a bit too strict. Current libvirt always set wait=false, and will
> > thus fail to add cl
On 4/15/19 10:54 AM, Kevin Wolf wrote:
> Limiting the allocation to INT_MAX bytes isn't particularly clever
> because it means that the final cluster will be a partial cluster which
> will be completed through a COW operation. This results in unnecessary
> data read and write requests which lead to
On Mon, Apr 15, 2019 at 06:06:09PM +0200, Marc-André Lureau wrote:
> Commit 767abe7 ("chardev: forbid 'wait' option with client sockets")
> is a bit too strict. Current libvirt always set wait=false, and will
> thus fail to add client chardev.
>
> Make the code more permissive, allowing wait=false
Commit 767abe7 ("chardev: forbid 'wait' option with client sockets")
is a bit too strict. Current libvirt always set wait=false, and will
thus fail to add client chardev.
Make the code more permissive, allowing wait=false with client socket
chardevs.
Fixes: 767abe7f49e8be14d29da5db3527817b5d696a5
It was fixed with commit 4cf077b59fc73eec29f8b7 (see patch series
https://lists.gnu.org/archive/html/qemu-block/2018-09/msg00504.html).
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1788582
Title:
On Mon, Apr 15, 2019 at 05:49:06PM +0200, Marc-André Lureau wrote:
> Commit 767abe7 ("chardev: forbid 'wait' option with client sockets")
> is a bit too strict. Current libvirt always set wait=false, and will
> thus fail to add client chardev.
>
> Make the code more permissive, allowing wait=false
We'll add a bdrv_co_truncate() call in the next patch which can return
an Error that we don't want to discard. So add an errp parameter to
preallocate_co().
Cc: qemu-sta...@nongnu.org
Signed-off-by: Kevin Wolf
---
block/qcow2.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
d
preallocate_co() already gave the data file the full size without
forwarding the requested preallocation mode to the protocol. When
bdrv_co_truncate() was called later with the preallocation mode, the
file didn't actually grow any more, so the data file stayed unallocated
even if full preallocation
Limiting the allocation to INT_MAX bytes isn't particularly clever
because it means that the final cluster will be a partial cluster which
will be completed through a COW operation. This results in unnecessary
data read and write requests which lead to an unwanted non-sparse
filesystem block for me
With an external data file, preallocate_co() must write the final byte
to the external data file, not to the qcow2 image file.
This is harmless for preallocation of newly created images (only the
qcow2 file size is increased to the virtual disk size while it should be
much smaller), but with preal
Kevin Wolf (4):
qcow2: Avoid COW during metadata preallocation
qcow2: Fix preallocation bdrv_pwrite to wrong file
qcow2: Add errp to preallocate_co()
qcow2: Fix full preallocation with external data file
block/qcow2.c | 47 +++
1 file changed, 2
* Markus Armbruster (arm...@redhat.com) wrote:
> The various dump_mmu() take an fprintf()-like callback and a FILE * to
> pass to it, and so do their helper functions. Passing around callback
> and argument is rather tiresome.
>
> Most dump_mmu() are called only by the target's hmp_info_tlb(). T
On Mon, Apr 15, 2019 at 10:25:03AM -0500, Eric Blake wrote:
> On 4/15/19 9:25 AM, Peter Maydell wrote:
> > On Mon, 15 Apr 2019 at 15:17, Daniel P. Berrangé
> > wrote:
> >>
>
> > A few typo nits below...
>
> Also:
>
> >
> >>
> >> +/*
> >> + * Ideally we would set LC_ALL, but QEMU curre
On Mon, 15 Apr 2019 at 16:25, Eric Blake wrote:
> "two known problems" but...
>
> ...three bullet points.
Nobody expects the Spanish Inquisition to be code reviewed :-)
thanks
-- PMM
Commit 767abe7 ("chardev: forbid 'wait' option with client sockets")
is a bit too strict. Current libvirt always set wait=false, and will
thus fail to add client chardev.
Make the code more permissive, allowing wait=false with client socket
chardevs.
Fixes: 767abe7f49e8be14d29da5db3527817b5d696a5
The ObjectInfo 'length' field provides the length of the
wide character string filename. This is then converted to
a multi-byte character string. This may have a different
byte count to the wide character string. We should use the
C string length of the multi-byte string instead.
Signed-off-by: Da
The ObjectInfo struct has a variable length array containing the UTF-16
encoded filename. The number of characters of trailing data is given by
the 'length' field in the struct and this must be validated against the
size of the data packet received from the guest.
Since the data is UTF-16, we must
The ObjectInfo struct's "filename" field is following a uint8_t
field in a packed struct and thus has bad alignment for a 16-bit
field. Switch the field to to uint8_t and use the helper function
for accessing unaligned 16-bit data.
Note that although the MTP spec specifies big endian, when transpo
Two previous attempts to fix this due to GCC 9 highlighting
unaligned data access. My attempt:
https://lists.gnu.org/archive/html/qemu-devel/2019-03/msg07763.html
And a previous one:
https://lists.gnu.org/archive/html/qemu-devel/2019-02/msg07923.html
https://lists.gnu.org/archive/html/qemu
* Markus Armbruster (arm...@redhat.com) wrote:
> The various TARGET_cpu_list() take an fprintf()-like callback and a
> FILE * to pass to it. Their callers (vl.c's main() via list_cpus(),
> bsd-user/main.c's main(), linux-user/main.c's main()) all pass
> fprintf() and stdout. Thus, the flexibility
A recent patch results in qemu-img reporting the backing file format of
vmdk images as vmdk. This broke iotests 110 and 126.
Fixes: "vmdk: Set vmdk parent backing_format to vmdk"
Signed-off-by: Max Reitz
---
RFC because:
(1) I'd prefer for this patch to be squashed into the patch mentioned
a
On 03/01/2019 04:39 AM, Cornelia Huck wrote:
Allow to extend the regions used by vfio-ccw. The first user will be
handling of halt and clear subchannel.
Signed-off-by: Cornelia Huck
---
drivers/s390/cio/vfio_ccw_ops.c | 186
drivers/s390/cio/vfio_ccw_privat
On 4/15/19 9:25 AM, Peter Maydell wrote:
> On Mon, 15 Apr 2019 at 15:17, Daniel P. Berrangé wrote:
>>
> A few typo nits below...
Also:
>
>>
>> +/*
>> + * Ideally we would set LC_ALL, but QEMU currently isn't able to cope
>> + * with arbitrary localization settings. In particular th
On 03/01/2019 04:39 AM, Cornelia Huck wrote:
Add a region to the vfio-ccw device that can be used to submit
asynchronous I/O instructions. ssch continues to be handled by the
existing I/O region; the new region handles hsch and csch.
Interrupt status continues to be reported through the same
On 4/15/19 3:27 PM, Igor Mammedov wrote:
> machine_hppa_init() violates memory_region_allocate_system_memory() contract
> by calling it multiple times which could break with -mem-path. Replace
> the second usage (for 'rom') with memory_region_init_ram() instead.
>
> Signed-off-by: Igor Mammedov
>
Do you find the cause of the bug and fix it?
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1788582
Title:
Race condition during shutdown
Status in QEMU:
New
Bug description:
I ran into a bug
On 4/15/19 3:27 PM, Igor Mammedov wrote:
> memory_region_allocate_system_memory() was designed to be called for
> allocating inital RAM. Using it mutiple times within one board is not
> supported and could fail if -mem-path with non hugepage path is used.
>
> Keep using memory_region_allocate_syst
On 3/1/19 4:39 AM, Cornelia Huck wrote:
Add a region to the vfio-ccw device that can be used to submit
asynchronous I/O instructions. ssch continues to be handled by the
existing I/O region; the new region handles hsch and csch.
Interrupt status continues to be reported through the same chann
* fengyd (fengy...@gmail.com) wrote:
> Hi,
>
> During live migration, the folloing log can see in nova-compute.log in my
> environment:
> ERROR nova.virt.libvirt.driver [req-039a85e1-e7a1-4a63-bc6d-c4b9a044aab6
> 0cdab20dc79f4bc6ae5790e7b4a898ac 3363c319773549178acc67f32c78310e - default
> defau
sorry, I make a spelling mistake here（"Hi, I also found a problem that
qemu-img convert hands in ARM."）.The right is "I also found a problem
that qemu-img convert hangs in ARM".
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://
We are going to share this bitmap between backup and backup-top filter
driver, so let's share something more meaningful. It also simplifies
some calculations.
Signed-off-by: Vladimir Sementsov-Ogievskiy
Reviewed-by: Max Reitz
---
block/backup.c | 48 +++--
Split allocation checking to separate function and reduce nesting.
Consider bdrv_is_allocated() fail as allocated area, as copying more
than needed is not wrong (and we do it anyway) and seems better than
fail the whole job. And, most probably we will fail on the next read,
if there are real proble
Simplify backup_incremental_init_copy_bitmap using the function
bdrv_dirty_bitmap_next_dirty_area.
Note: move to job->len instead of bitmap size: it should not matter but
less code.
Signed-off-by: Vladimir Sementsov-Ogievskiy
---
block/backup.c | 40
1 f
Hi all!
Here some refactoring patches, as a first step for backup-top filter
introduction.
v6:
01: - use end_cluster instead of last_cluster and fix bug in
calculation [Max]
02: only rebased on 01, keep r-b
03, 04: new
05: it's rewritten
"[PATCH v5 10/11] block/backup: tiny refactor bac
Split out cluster_size calculation. Move copy-bitmap creation above
block-job creation, as we are going to share it with upcoming
backup-top filter, which also should be created before actual block job
creation.
Also, while being here, drop unnecessary "goto error" from
bdrv_getlength error path.
1 - 100 of 189 matches
Mail list logo
