Max Reitz writes:
> Albeit absolutely impossible right now, bdrv_find_format("qcow2") may
> fail. bdrv_append_temp_snapshot() should heed that case.
Impossible because we always compile in bdrv_qcow2.
> Cc: qemu-sta...@nongnu.org
> Signed-off-by: Max Reitz
> ---
> block.c | 6 ++
> 1 file
Quoting Bharata B Rao (2014-11-25 22:54:12)
> On Wed, Oct 1, 2014 at 8:00 PM, Alexander Graf wrote:
> >
> >
> > On 01.10.14 00:08, Michael Roth wrote:
> >> Quoting Alexander Graf (2014-08-26 06:36:57)
> >>> On 19.08.14 02:21, Michael Roth wrote:
> From: Mike Day
>
> Signed-off-by:
On Tue, Nov 25, 2014 at 09:35:26AM -0700, Eric Blake wrote:
> On 11/25/2014 04:58 AM, Markus Armbruster wrote:
> > Amos Kong writes:
> >
> >> On Tue, Nov 25, 2014 at 09:06:34AM +0100, Markus Armbruster wrote:
> >>> Gerd Hoffmann writes:
> >>>
> Ongoing discussions on how we are going to spe
On Mon, 11/24 10:43, Max Reitz wrote:
> Sometimes, qemu does not have a filename to work with, so it does not
> know which directory to use for a backing file specified by a relative
> filename. Add a test which tests that qemu exits with an appropriate
> error message.
>
> Additionally, add a tes
On Mon, 11/24 10:43, Max Reitz wrote:
> Relative backing filenames are always relative to the backed image's
> directory; the same applies to image creation. Therefore, if the backing
> file has to be opened for determining its size (in case the size has not
> been explicitly specified) its filenam
On Mon, 11/24 10:43, Max Reitz wrote:
> Introduce bdrv_get_full_backing_filename_from_filename(), a function
> which takes the name of the backed file and a potentially relative
> backing filename to produce the full (absolute) backing filename.
>
> Use this function from bdrv_get_full_backing_fil
On Mon, 11/24 10:43, Max Reitz wrote:
> When a vmdk image is created with a backing file, it is opened to check
> whether it is indeed a vmdk file by letting qemu probe it. When doing
> so, the backing filename is relative to the image's base directory so it
> should be interpreted accordingly.
>
On Mon, 11/24 10:43, Max Reitz wrote:
> @@ -1209,7 +1218,13 @@ int bdrv_open_backing_file(BlockDriverState *bs, QDict
> *options, Error **errp)
> QDECREF(options);
> goto free_exit;
> } else {
> -bdrv_get_full_backing_filename(bs, backing_filename, PATH_MAX);
> +
On Tue, 11/25 13:52, Stefan Hajnoczi wrote:
> On Tue, Nov 25, 2014 at 04:07:54PM +0800, Fam Zheng wrote:
> > ppoll(2) doesn't scale as well as epoll: The elapsed time of the syscall is
> > linear to the number of fd's we poll, which hurts performance a bit when the
> > number of devices are many, o
On 11/25/2014 09:53 PM, Stefano Stabellini wrote:
> On Tue, 25 Nov 2014, Jason Wang wrote:
>> On 11/25/2014 02:44 AM, Stefano Stabellini wrote:
>>> On Mon, 24 Nov 2014, Stefano Stabellini wrote:
On Mon, 24 Nov 2014, Stefano Stabellini wrote:
> CC'ing Paolo.
>
>
> Wen,
> tha
On Wed, Oct 1, 2014 at 8:00 PM, Alexander Graf wrote:
>
>
> On 01.10.14 00:08, Michael Roth wrote:
>> Quoting Alexander Graf (2014-08-26 06:36:57)
>>> On 19.08.14 02:21, Michael Roth wrote:
From: Mike Day
Signed-off-by: Mike Day
Signed-off-by: Michael Roth
---
hw/
On Wed, Oct 1, 2014 at 8:00 PM, Alexander Graf wrote:
>
>
> On 01.10.14 00:08, Michael Roth wrote:
>> Quoting Alexander Graf (2014-08-26 06:36:57)
>>> On 19.08.14 02:21, Michael Roth wrote:
From: Mike Day
Signed-off-by: Mike Day
Signed-off-by: Michael Roth
---
hw/
On Tue, 11/25 18:21, Peter Maydell wrote:
> In qemu_poll_ns(), when we convert an int64_t nanosecond timeout into
> a struct timespec, we may accidentally run into overflow problems if
> the timeout is very long. This happens because the tv_sec field is a
> time_t, which is signed, so we might end
> -Original Message-
> From: Eric Blake [mailto:ebl...@redhat.com]
> Sent: Wednesday, November 26, 2014 12:31 AM
> To: Xu, Quan; qemu-devel@nongnu.org
> Cc: xen-de...@lists.xen.org; arm...@redhat.com; lcapitul...@redhat.com
> Subject: Re: [Xen-devel] [Qemu-devel] [v2 1/4] Qemu-Xen-vTPM: S
On 2014/11/26 7:30, grhookatw...@gmail.com wrote:
> From: Gary R Hook
>
> Modify block_save_iterate() to return positive/zero/negative
> (success/not done/failure) return status. The computation of
> the blocks transferred (an int64_t) exceeds the size of an
> int return value.
>
> Signed-off-b
On Tue, 11/25 13:38, Stefan Hajnoczi wrote:
> On Tue, Nov 25, 2014 at 04:07:57PM +0800, Fam Zheng wrote:
> > +QEMUPoll *qemu_poll_new(void)
> > +{
> > +int epollfd;
> > +QEMUPoll *qpoll = g_new0(QEMUPoll, 1);
> > +epollfd = epoll_create1(EPOLL_CLOEXEC);
> > +if (epollfd < 0) {
> > +
On Tue, 2014-11-25 at 16:23 +0200, Marcel Apfelbaum wrote:
> On Tue, 2014-11-25 at 09:12 -0500, Luiz Capitulino wrote:
> > On Tue, 25 Nov 2014 16:04:19 +0200
> > Marcel Apfelbaum wrote:
> >
> > > Hi,
> > >
> > > The commits:
> > > - 6a1fa9f5 (monitor: add del completion for peripheral device)
From: Gary R Hook
Modify block_save_iterate() to return positive/zero/negative
(success/not done/failure) return status. The computation of
the blocks transferred (an int64_t) exceeds the size of an
int return value.
Signed-off-by: Gary R Hook
---
block-migration.c | 10 +-
1 file cha
On 25 November 2014 at 20:29, Christoffer Dall
wrote:
> I'm wondering if the timespec struct field is an unsigned long and
> that's why we werent' seeing the overflow on arm64?
It's a time_t, and they're signed, but I imagine on arm64
time_t is 64 bits.
-- PMM
On behalf of the QEMU Team, I'd like to announce the availability of the
fourth release candidate for the QEMU 2.2 release. This release is meant
for testing purposes and should not be used in a production environment.
http://wiki.qemu.org/download/qemu-2.2.0-rc3.tar.bz2
We're currently aware
On 11/24/2014 02:43 AM, Max Reitz wrote:
> Sometimes, qemu does not have a filename to work with, so it does not
> know which directory to use for a backing file specified by a relative
> filename. Add a test which tests that qemu exits with an appropriate
> error message.
>
> Additionally, add a
On 11/24/2014 02:43 AM, Max Reitz wrote:
> When a vmdk image is created with a backing file, it is opened to check
> whether it is indeed a vmdk file by letting qemu probe it. When doing
> so, the backing filename is relative to the image's base directory so it
> should be interpreted accordingly.
On 25 Nov 2014, at 22:37, Peter Maydell wrote:
> I'd also strongly prefer not to implement three dozen
> boards unless we really need them all. Again, start
> with one and implement a decent subset of the devices
> it has on it.
we probably have different goals.
I don't need three dozen boar
* David Gibson (da...@gibson.dropbear.id.au) wrote:
> On Wed, Nov 19, 2014 at 05:53:54PM +, Dr. David Alan Gilbert wrote:
> > * David Gibson (da...@gibson.dropbear.id.au) wrote:
> > > On Fri, Oct 03, 2014 at 06:47:30PM +0100, Dr. David Alan Gilbert (git)
> > > wrote:
> > > > From: "Dr. David A
On 25 November 2014 at 19:58, Liviu Ionescu wrote:
> As mentioned in a previous message, I started work on a more detailed
> implementation for the M profile.
>
> At first I defined in target-arm/cpu.c the cpu-s for all variants
> (M0/M0+/M1/M3/M4/M7).
>
> /* Cortex-M cores. Currently only M
On Tue, Nov 25, 2014 at 06:21:45PM +, Peter Maydell wrote:
> In qemu_poll_ns(), when we convert an int64_t nanosecond timeout into
> a struct timespec, we may accidentally run into overflow problems if
> the timeout is very long. This happens because the tv_sec field is a
> time_t, which is sig
On 11/24/2014 02:43 AM, Max Reitz wrote:
> Relative backing filenames are always relative to the backed image's
> directory; the same applies to image creation. Therefore, if the backing
> file has to be opened for determining its size (in case the size has not
> been explicitly specified) its file
On 25/11/2014 19:45, Eduardo Habkost wrote:
>> > +static const char *cpuid_xsave_feature_name[] = {
>> > +"xsaveopt", "xsavec", "xgetbv1", "xsaves",
> None of the above features introduce any new state that might need to be
> migrated, or will require other changes in QEMU to work, right?
>
As mentioned in a previous message, I started work on a more detailed
implementation for the M profile.
At first I defined in target-arm/cpu.c the cpu-s for all variants
(M0/M0+/M1/M3/M4/M7).
/* Cortex-M cores. Currently only M3 is tested and fully functional. */
{ .name = "cortex-m0"
On 11/24/2014 02:43 AM, Max Reitz wrote:
> When using a relative backing file name, qemu needs to know the
> directory of the top image file. For JSON filenames, such a directory
> cannot be easily determined (e.g. how do you determine the directory of
> a qcow2 BDS directly on top of a quorum BDS?
On 25/11/2014 19:21, Peter Maydell wrote:
> In qemu_poll_ns(), when we convert an int64_t nanosecond timeout into
> a struct timespec, we may accidentally run into overflow problems if
> the timeout is very long. This happens because the tv_sec field is a
> time_t, which is signed, so we might en
On 11/25/2014 02:46 PM, John Snow wrote:
This is the in memory part of the incremental backup feature.
With the added commands, we can create a bitmap on a block backend, from which
point of time all the writes are tracked by the bitmap, marking sectors as
dirty. Later, we call drive-backup and
On 11/24/2014 02:43 AM, Max Reitz wrote:
> Introduce bdrv_get_full_backing_filename_from_filename(), a function
> which takes the name of the backed file and a potentially relative
> backing filename to produce the full (absolute) backing filename.
>
> Use this function from bdrv_get_full_backing_
From: Fam Zheng
Signed-off-by: Fam Zheng
Signed-off-by: John Snow
---
block.c | 1 +
qapi/block-core.json | 5 -
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/block.c b/block.c
index cf93148..3acf289 100644
--- a/block.c
+++ b/block.c
@@ -5404,6 +5404,7 @@ Bloc
From: Fam Zheng
For "dirty-bitmap" sync mode, the block job will iterate through the
given dirty bitmap to decide if a sector needs backup (backup all the
dirty clusters and skip clean ones), just as allocation conditions of
"top" sync mode.
There are two bitmap use modes for sync=dirty-bitmap:
From: Fam Zheng
This makes a deep copy of an HBitmap.
Signed-off-by: Fam Zheng
Signed-off-by: John Snow
---
include/qemu/hbitmap.h | 8
util/hbitmap.c | 16
2 files changed, 24 insertions(+)
diff --git a/include/qemu/hbitmap.h b/include/qemu/hbitmap.h
index
From: Fam Zheng
The new command pair is added to manage user created dirty bitmap. The
dirty bitmap's name is mandatory and must be unique for the same device,
but different devices can have bitmaps with the same names.
The types added to block-core.json will be re-used in future patches
in this
From: Fam Zheng
This allows to put the dirty bitmap into a disabled state where no more
writes will be tracked.
It will be used before backup or writing to persistent file.
Signed-off-by: Fam Zheng
Signed-off-by: John Snow
---
block.c | 15 +
blockdev.c|
From: Fam Zheng
This field will be set for user created dirty bitmap. Also pass in an
error pointer to bdrv_create_dirty_bitmap, so when a name is already
taken on this BDS, it can report an error message. This is not global
check, two BDSes can have dirty bitmap with a common name.
Implemented
From: Fam Zheng
This adds three qmp commands to transactions.
Users can stop a dirty bitmap, start backup of it, and start another
dirty bitmap atomically, so that the dirty bitmap is tracked
incrementally and we don't miss any write.
Signed-off-by: Fam Zheng
Signed-off-by: John Snow
---
blo
From: Fam Zheng
This returns the granularity (in bytes) of dirty bitmap,
which matches the QMP interface and the existing query
interface.
Signed-off-by: Fam Zheng
Reviewed-by: Benoit Canet
Signed-off-by: John Snow
---
block.c | 9 +++--
include/block/block.h | 2 ++
2 file
This is the in memory part of the incremental backup feature.
With the added commands, we can create a bitmap on a block backend, from which
point of time all the writes are tracked by the bitmap, marking sectors as
dirty. Later, we call drive-backup and pass the bitmap to it, to do an
incrementa
From: Fam Zheng
Signed-off-by: Fam Zheng
Signed-off-by: John Snow
---
block.c | 35 +++
include/block/block.h | 4
2 files changed, 35 insertions(+), 4 deletions(-)
diff --git a/block.c b/block.c
index ea4c8d8..9582550 100644
--- a/block.c
+
From: Fam Zheng
Signed-off-by: Fam Zheng
Signed-off-by: John Snow
---
tests/qemu-iotests/056| 33 ++---
tests/qemu-iotests/056.out| 4 ++--
tests/qemu-iotests/iotests.py | 8
3 files changed, 40 insertions(+), 5 deletions(-)
diff --git a/test
On Fri, Nov 21, 2014 at 11:05:45PM +, Peter Maydell wrote:
> If it's mapped and readable-but-not-writable then it should still
> fault on write accesses, though? These are cases we currently get
> SEGV for, anyway.
Yes then it'll work just fine.
> Ah, I guess we have a terminology difference.
* David Gibson (da...@gibson.dropbear.id.au) wrote:
> On Fri, Oct 03, 2014 at 06:47:47PM +0100, Dr. David Alan Gilbert (git) wrote:
> > From: "Dr. David Alan Gilbert"
> >
> > Postcopy sends RAMBlock names and offsets over the wire (since it can't
> > rely on the order of ramaddr being the same),
On Tue, Nov 25, 2014 at 06:35:42PM +0100, Paolo Bonzini wrote:
> These represent xsave-related capabilities of the processor, and KVM may
> or may not support them.
>
> Add feature bits so that they are considered by "-cpu ...,enforce", and use
> the new feature work instead of calling kvm_arch_ge
On 25/11/14 17:45, Stefano Stabellini wrote:
> Increase maxmem before calling xc_domain_populate_physmap_exact to avoid
> the risk of running out of guest memory. This way we can also avoid
> complex memory calculations in libxl at domain construction time.
>
> This patch fixes an abort() when assi
On 25 November 2014 at 16:58, Eric Blake wrote:
> On 11/25/2014 06:54 AM, Markus Armbruster wrote:
>> From: Gerd Hoffmann
>>
>> Ongoing discussions on how we are going to specify the console,
>> so tag the command as experiental so we can refine things in
>> the 2.3 development cycle.
>>
>> Signe
In qemu_poll_ns(), when we convert an int64_t nanosecond timeout into
a struct timespec, we may accidentally run into overflow problems if
the timeout is very long. This happens because the tv_sec field is a
time_t, which is signed, so we might end up setting it to a negative
value by mistake. This
* David Gibson (da...@gibson.dropbear.id.au) wrote:
> On Fri, Oct 03, 2014 at 06:47:46PM +0100, Dr. David Alan Gilbert (git) wrote:
> > From: "Dr. David Alan Gilbert"
> >
> > In postcopy, the destination guest is running at the same time
> > as it's receiving pages; as we receive new pages we mus
On Thu, 13 Nov 2014 18:36:56 +0800
Mao Chuan Li wrote:
> For successful execution of case 039, core dump need be
> disabled. Just running "ulimit -c 0" command is not enough when the
> /proc/sys/kernel/core_pattern indicates to pipe the dump to another
> application. So we must erase the pattern
Increase maxmem before calling xc_domain_populate_physmap_exact to avoid
the risk of running out of guest memory. This way we can also avoid
complex memory calculations in libxl at domain construction time.
This patch fixes an abort() when assigning more than 4 NICs to a VM.
Signed-off-by: Stefan
On Tue, 25 Nov 2014 18:55:56 +0100
Greg Kurz wrote:
> On Tue, 25 Nov 2014 14:24:18 +0100
> Cornelia Huck wrote:
>
> > Handle endianness conversion for virtio-1 virtqueues correctly.
> >
> > Note that dataplane now needs to be built per-target.
> >
> > Signed-off-by: Cornelia Huck
> > ---
>
I'm thinking now that the
appropriate thing is to add live migration of dirty bitmaps to QEMU
(regardless of whether they are active or not).
Digging the code around, I've found this:
in mig_save_device_dirty which is actually an iteration of live block
migration, after sending a sector we need
On Tue, 25 Nov 2014 14:24:18 +0100
Cornelia Huck wrote:
> Handle endianness conversion for virtio-1 virtqueues correctly.
>
> Note that dataplane now needs to be built per-target.
>
> Signed-off-by: Cornelia Huck
> ---
We still have the same error as in your previous post...
In file included
These represent xsave-related capabilities of the processor, and KVM may
or may not support them.
Add feature bits so that they are considered by "-cpu ...,enforce", and use
the new feature work instead of calling kvm_arch_get_supported_cpuid.
Signed-off-by: Paolo Bonzini
---
target-i386/cpu.c
* David Gibson (da...@gibson.dropbear.id.au) wrote:
> On Fri, Oct 03, 2014 at 06:47:31PM +0100, Dr. David Alan Gilbert (git) wrote:
> > From: "Dr. David Alan Gilbert"
> >
> > Provide a check to see if the OS we're running on has all the bits
> > needed for postcopy.
> >
> > Creates postcopy-ram.
Hello Michael, or anyone else affected,
Accepted qemu into utopic-proposed. The package will build now and be
available at http://launchpad.net/ubuntu/+source/qemu/2.1+dfsg-
4ubuntu6.2 in a few hours, and then in the -proposed repository.
Please help us by testing this new package. See
https://w
Hello Michael, or anyone else affected,
Accepted qemu into trusty-proposed. The package will build now and be
available at http://launchpad.net/ubuntu/+source/qemu/2.0.0+dfsg-
2ubuntu1.8 in a few hours, and then in the -proposed repository.
Please help us by testing this new package. See
https:/
On 2014-11-25 at 18:12, Kevin Wolf wrote:
If a qcow2 image specifies a backing file format that doesn't correspond
to any format driver that qemu knows, we shouldn't fall back to probing,
but simply error out.
Not looking up the backing file driver in bdrv_open_backing_file(), but
just filling i
On 2014-11-25 at 18:12, Kevin Wolf wrote:
The qcow2 specification requires that the header extension data be
padded to round up the extension size to the next multiple of 8 bytes.
Signed-off-by: Kevin Wolf
---
tests/qemu-iotests/qcow2.py | 4
1 file changed, 4 insertions(+)
diff --git
On 2014-11-25 at 18:12, Kevin Wolf wrote:
After reading the extension header, offset is incremented, but not
checked against end_offset any more. This way an integer overflow could
happen when checking whether the extension end is within the allowed
range, effectively disabling the check.
This p
On Tue, Nov 25, 2014 at 03:19:24PM +0100, Kevin Wolf wrote:
> If a qcow2 image specifies a backing file format that doesn't correspond
> to any format driver that qemu knows, we shouldn't fall back to probing,
> but simply error out.
>
> Not looking up the backing file driver in bdrv_open_backing_
On Tue, 25 Nov 2014 18:44:10 +0200
"Michael S. Tsirkin" wrote:
> On Tue, Nov 25, 2014 at 02:24:11PM +0100, Cornelia Huck wrote:
> > Hi,
> >
> > here's the next version of my virtio-1 qemu patchset. Using virtio-1
> > virtio-blk and virtio-net devices with a guest kernel built from
> > <141682978
If a qcow2 image specifies a backing file format that doesn't correspond
to any format driver that qemu knows, we shouldn't fall back to probing,
but simply error out.
Not looking up the backing file driver in bdrv_open_backing_file(), but
just filling in the "driver" option if it isn't there move
On Tue, Nov 25, 2014 at 04:28:32PM +0100, Fabio Fantoni wrote:
> Il 25/11/2014 15:42, Stefano Stabellini ha scritto:
> >Hi all,
> >this patch series fixes a cpu mapping leak in virtio-net.
> >
> >The bug is caused by virtio_net_handle_ctrl: it maps the entire out_sg
> >iov, but then modifies it and
After reading the extension header, offset is incremented, but not
checked against end_offset any more. This way an integer overflow could
happen when checking whether the extension end is within the allowed
range, effectively disabling the check.
This patch adds the missing check and a test case
The qcow2 specification requires that the header extension data be
padded to round up the extension size to the next multiple of 8 bytes.
Signed-off-by: Kevin Wolf
---
tests/qemu-iotests/qcow2.py | 4
1 file changed, 4 insertions(+)
diff --git a/tests/qemu-iotests/qcow2.py b/tests/qemu-iot
v2:
- Added two patches to make the test case actually work properly and not
just by accident on my laptop. [Max]
- Fixed comment in test case [Max]
Kevin Wolf (3):
qcow2: Fix header extension size check
qcow2.py: Add required padding for header extensions
block: Don't probe for unknown ba
On 11/25/2014 04:58 AM, Markus Armbruster wrote:
> Amos Kong writes:
>
>> On Tue, Nov 25, 2014 at 09:06:34AM +0100, Markus Armbruster wrote:
>>> Gerd Hoffmann writes:
>>>
Ongoing discussions on how we are going to specify the console,
so tag the command as experiemntal so we can refine
On 11/25/2014 06:54 AM, Markus Armbruster wrote:
> From: Gerd Hoffmann
>
> Ongoing discussions on how we are going to specify the console,
> so tag the command as experiental so we can refine things in
> the 2.3 development cycle.
>
> Signed-off-by: Gerd Hoffmann
> [Spell out "not a stable API"
On Thu, Nov 20, 2014 at 05:07:06PM +0800, arei.gong...@huawei.com wrote:
> From: Gonglei
>
> Arguments in wrong order (SWAPPED_ARGUMENTS)
> The positions of arguments in the call to
> tight_fill_palette do not match the ordering of the parameters:
> &fg is passed to bg
> &bg is passed to fg
>
On Tue, 25 Nov 2014 15:04:38 +0100
Markus Armbruster wrote:
> Max Reitz writes:
>
> > On 2014-11-25 at 14:48, Markus Armbruster wrote:
> >> Max Reitz writes:
> >>
> >>> On 2014-11-25 at 14:20, Markus Armbruster wrote:
> Max Reitz writes:
>
> > On 2014-11-25 at 13:21, Markus Armb
On Thu, Nov 20, 2014 at 04:27:12PM +0100, Kevin Wolf wrote:
> If the user neglects to specify the image format, QEMU probes the
> image to guess it automatically, for convenience.
>
> Relying on format probing is insecure for raw images (CVE-2008-2004).
> If the guest writes a suitable header to t
On Tue, 25 Nov 2014 11:09:35 +0100
Max Reitz wrote:
> Test 039 used to fail because qemu-io -c abort may generate core dumps
> even with ulimit -c 0 (and the output then contains "(core dumped)").
> Fix this by adding an option to the "abort" command which allows
> specifying a signal number to r
On 11/23/2014 09:49 PM, li wrote:
Hi all,
Thank you for your time to read this email, is there anyone can tell me
the options qemu was configured when it was released?
I configured it by myself and found that there was a audio latency
problem, but the qemu in the repository doesn't have this pr
On Tue, Nov 25, 2014 at 02:24:11PM +0100, Cornelia Huck wrote:
> Hi,
>
> here's the next version of my virtio-1 qemu patchset. Using virtio-1
> virtio-blk and virtio-net devices with a guest kernel built from
> <1416829787-14252-1-git-send-email-...@redhat.com> still seems to
> work for the virtio
On Fri, Nov 21, 2014 at 11:26:23AM -0800, Pawan Uberoy wrote:
> Hello,
>
> We are running a couple of VMs using the qemu command on ubuntu 14.04. It
> seems like there is a corruption on the socket. It crashes on its on after a
> day or so of light activity.
>
> Is this a known issue?
>
> Ple
On 11/25/2014 06:51 AM, Xu, Quan wrote:
>>
>> Also, this message was not threaded properly; it appeared as a top-level
>> thread along with three other threads for its siblings, instead of all four
>> patches being in-reply-to the 0/4 cover letter.
>>
> Thanks Eric.
>
> Should I:
>
> V2 is versi
* David Gibson (da...@gibson.dropbear.id.au) wrote:
> On Fri, Oct 03, 2014 at 06:47:48PM +0100, Dr. David Alan Gilbert (git) wrote:
> > From: "Dr. David Alan Gilbert"
> >
> > Once we're in postcopy the source processors are stopped and memory
> > shouldn't change any more, so there's no need to l
On Tue, Nov 25, 2014 at 10:45:05PM +0800, Ming Lei wrote:
> On Tue, Nov 25, 2014 at 9:08 PM, Stefan Hajnoczi wrote:
> > On Tue, Nov 25, 2014 at 03:23:11PM +0800, Ming Lei wrote:
> >> @@ -296,12 +370,14 @@ void laio_detach_aio_context(void *s_, AioContext
> >> *old_context)
> >>
> >> aio_set_
* David Gibson (da...@gibson.dropbear.id.au) wrote:
> On Fri, Oct 03, 2014 at 06:47:12PM +0100, Dr. David Alan Gilbert (git) wrote:
> > From: "Dr. David Alan Gilbert"
> >
> > and use it in loadvm_state.
> >
> > Signed-off-by: Dr. David Alan Gilbert
> > ---
> > include/migration/qemu-file.h |
On Tue, 25 Nov 2014, Peter Maydell wrote:
> On 25 November 2014 at 14:43, Stefano Stabellini
> wrote:
> > Introduce a function to unmap an sg previously mapped with
> > virtqueue_map_sg.
> >
> > Signed-off-by: Stefano Stabellini
> > CC: jasow...@redhat.com
> > CC: we...@cn.fujitsu.com
> > CC: m..
* David Gibson (da...@gibson.dropbear.id.au) wrote:
> On Thu, Oct 16, 2014 at 04:26:55PM +0800, zhanghailiang wrote:
> > On 2014/10/4 1:47, Dr. David Alan Gilbert (git) wrote:
> > >From: "Dr. David Alan Gilbert"
> [snip]
>
> > >+case MIG_RPCOMM_ACK:
> > >+tmp32 = be32_to_cpup(
On Tue, Nov 25, 2014 at 02:54:17PM +0100, Markus Armbruster wrote:
> From: Gerd Hoffmann
>
> Ongoing discussions on how we are going to specify the console,
> so tag the command as experiental so we can refine things in
> the 2.3 development cycle.
>
> Signed-off-by: Gerd Hoffmann
> [Spell out
Il 25/11/2014 15:42, Stefano Stabellini ha scritto:
Hi all,
this patch series fixes a cpu mapping leak in virtio-net.
The bug is caused by virtio_net_handle_ctrl: it maps the entire out_sg
iov, but then modifies it and reduces it (iov_discard_front), and only
unmap the reduced version of the iov
On 25 November 2014 at 14:43, Stefano Stabellini
wrote:
> Introduce a function to unmap an sg previously mapped with
> virtqueue_map_sg.
>
> Signed-off-by: Stefano Stabellini
> CC: jasow...@redhat.com
> CC: we...@cn.fujitsu.com
> CC: m...@redhat.com
> CC: pbonz...@redhat.com
> ---
> hw/virtio/vi
Hi,
> I checked windows 7, and I see a problem with it, as well:
> with -vga cirrus, hybernate is enabled, with new default,
> it is disabled :(
No difference here. sleep is grayed, hibernate is available, for both
cirrus+stdvga.
Noticed that hibernate was grayed on the first vm boot with cir
On 17 November 2014 at 16:47, Greg Bellows wrote:
> Version 11 of the ARM processor security extension (TrustZone) support. This
> patchset includes changes to support the processor security extensions
> on ARMv7 aarch32 with hooks for later enabling v8 aarch64/32.
>
> This update includes minor
On 2014-11-25 at 15:41, Kevin Wolf wrote:
Am 25.11.2014 um 15:07 hat Max Reitz geschrieben:
The nfs protocol driver is capable of creating images, but did not
specify any creation options. Fix it.
Cc: qemu-sta...@nongnu.org
Signed-off-by: Max Reitz
As you'll respin anyway: Can you mention how
On 24 November 2014 at 10:50, zhanghailiang
wrote:
> Coverity reports the 'size' may be used uninitialized, but that can't happen,
> because the caller has checked "if (binfo->dtb_filename || binfo->get_dtb)"
> before call 'load_dtb'.
>
> Here we simply remove the 'if (binfo->get_dtb)' to satisfy
On 2014-11-25 at 15:19, Kevin Wolf wrote:
If a qcow2 image specifies a backing file format that doesn't correspond
to any format driver that qemu knows, we shouldn't fall back to probing,
but simply error out.
Not looking up the backing file driver in bdrv_open_backing_file(), but
just filling i
Hi
In today call ony one announcement in the agenda:
- Greesocs announces that they are starting ultithreading TCG.
- They would start with usermode (it looks easier). Althought they are
more interested in system mode.
- would start with a minimal wiki page, and ask for colaboration about
i
Move the two virtqueue_unmap_sg calls from virtqueue_fill to
virtqueue_push: most virtio drivers simply call virtqueue_push so they
are unaffected. virtio-net calls virtqueue_fill directly, so we need to
make the two virtqueue_unmap_sg calls explicitely there.
Also replace the virtqueue_push call
On 2014-11-25 at 15:48, Max Reitz wrote:
On 2014-11-25 at 15:19, Kevin Wolf wrote:
If a qcow2 image specifies a backing file format that doesn't correspond
to any format driver that qemu knows, we shouldn't fall back to probing,
but simply error out.
Not looking up the backing file driver in bd
Revert the remaining portions of commits 75d62a5856 and 3430b0be36f
which are under a SoftFloat-2b license, ie the functions
uint64_to_float32() and uint64_to_float64(). (The float64_to_uint64()
and float64_to_uint64_round_to_zero() functions were completely
rewritten in commits fb3ea83aa and 0a87a
24.11.2014 05:47, zhanghailiang write:
> Array index starts at 0, so the valid index of ext_queue array,
> io_queue array, mchk_queue array should be MAX_EXT_QUEUE - 1,
> MAX_IO_QUEUE - 1, MAX_MCHK_QUEUE - 1.
>
> The original checks missed the invalid bound value, which will lead
> possible out of
Reimplement support for architectures where the most significant bit
in the mantissa is 1 for a signaling NaN rather than a quiet NaN,
by adding handling for SNAN_BIT_IS_ONE being set to the functions
which test values for NaN-ness.
This includes restoring the bugfixes lost in the reversion where
25.11.2014 11:05, Amos Kong wrote:
> Lack of two closed bracket in json commands.
Applied to -trivial, thank you!
/mjt
1 - 100 of 221 matches
Mail list logo
