On Tue, Mar 20, 2018 at 03:50:02PM +0200, Michael S. Tsirkin wrote:
> On Tue, Mar 20, 2018 at 01:41:17PM +, Daniel P. Berrangé wrote:
> > On Tue, Mar 20, 2018 at 02:32:16PM +0100, Gerd Hoffmann wrote:
> > > Hi,
> > >
> > > > > So for these, we should use "". None of these are generated file
On Tue, Mar 20, 2018 at 02:32:16PM +0100, Gerd Hoffmann wrote:
> Hi,
>
> > > So for these, we should use "". None of these are generated files though.
> >
> > That leads to crazy inconsistent message for developers where 50% of QEMU
> > header files must use <> and the other 50% of header file
On 2018-03-20 14:41, Daniel P. Berrangé wrote:
> On Tue, Mar 20, 2018 at 02:32:16PM +0100, Gerd Hoffmann wrote:
>> Hi,
>>
So for these, we should use "". None of these are generated files though.
>>>
>>> That leads to crazy inconsistent message for developers where 50% of QEMU
>>> header fi
** Tags added: arm
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1756927
Title:
ARMv7 LPAE: IFSR doesn't have the LPAE bit in case of BKPT
Status in QEMU:
In Progress
Bug description:
When a
I've just sent this patchset:
http://patchew.org/QEMU/20180320134114.30418-1-peter.mayd...@linaro.org/
which should fix this bug and a couple of others that I noticed with our debug
exception handling while I was doing that.
** Changed in: qemu
Status: New => In Progress
--
You received
On Tue, Mar 20, 2018 at 01:58:32PM +, Daniel P. Berrangé wrote:
> > That's the C language for you though. For better or worse, these are
> > the rules that K&R came up with.
>
> No one seriously tries to keep compliance with original K&R C these days,
> things have moved on massively since th
On 20 March 2018 at 03:16, Michael S. Tsirkin wrote:
> Changes from v1:
> - dropped include change for one generated file - proposed a tree-wide
> refactoring
> - dropped vhost used slot refactoring due to alignment issues found by clang
> - added vhost-user post-copy support
>
> The following ch
When doing a build with builddir != srcdir, if any generated files are
accidentally present in srcdir from a previous build, these can cause
unexpected failures.
Currently there is a rule that checks for existance of config-host.mak,
but there have been cases where config-host.mak is absent, while
On Tue, Mar 20, 2018 at 11:11:01AM +0100, Kevin Wolf wrote:
> Am 19.03.2018 um 18:53 hat Christian Borntraeger geschrieben:
> >
> >
> > On 03/19/2018 05:10 PM, Stefan Hajnoczi wrote:
> > > On Mon, Mar 19, 2018 at 9:35 AM, QingFeng Hao
> > > wrote:
> > >> Test case 185 failed since commit 4486e8
On 20 March 2018 at 14:23, Daniel P. Berrangé wrote:
> When doing a build with builddir != srcdir, if any generated files are
> accidentally present in srcdir from a previous build, these can cause
> unexpected failures.
>
> Currently there is a rule that checks for existance of config-host.mak,
>
On Tue, Mar 20, 2018 at 02:18:33PM +, Peter Maydell wrote:
> On 20 March 2018 at 03:16, Michael S. Tsirkin wrote:
> > Changes from v1:
> > - dropped include change for one generated file - proposed a tree-wide
> > refactoring
> > - dropped vhost used slot refactoring due to alignment issues f
This fixes the build on systems without userfaultfd.
Signed-off-by: Michael S. Tsirkin
---
migration/postcopy-ram.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/migration/postcopy-ram.c b/migration/postcopy-ram.c
index 146bc09..bf78d5c 100644
--- a/migration/postcop
This fixes the build on systems without userfaultfd.
Signed-off-by: Michael S. Tsirkin
---
migration/postcopy-ram.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/migration/postcopy-ram.c b/migration/postcopy-ram.c
index 146bc09..8e08ff9 100644
--- a/migration/postcopy-ram.c
+++ b/mi
Note: only patch 39/51 is attached.
The rest are unchanged from v2.
The following changes since commit 026aaf47c02b79036feb830206cfebb2a726510d:
Merge remote-tracking branch 'remotes/ehabkost/tags/python-next-pull-request'
into staging (2018-03-13 16:26:44 +)
are available in the git repo
Hi!
Recently, I have started working on the real multi-queue implementation
for the VirtIOBlock device and came to conclusion
that for the time being it may work only with RAW images. The reason is
obviously lack of the true thread-safe multi-queue block
layer, but recently I have seen the fol
> -Original Message-
> From: Michael S. Tsirkin [mailto:m...@redhat.com]
> Sent: Tuesday, March 20, 2018 8:36 PM
> To: Zhoujian (jay)
> Cc: qemu-devel@nongnu.org; imamm...@redhat.com; Huangweidong (C)
> ; wangxin (U) ; Gonglei
> (Arei) ; Liuzhe (Ahriy, Euler)
> Subject: Re: [PATCH v9] v
On Tue, Mar 20, 2018 at 07:35:18AM -0400, Artemis Tosini wrote:
> This patch ensures that the client OS does not cause the host to read invalid
> memory from the NVDIMM DSM. It is not tested, since the Linux NVDIMM driver
> will not cause an invalid memory read.
Thanks for the patch!
Please mov
On 03/20/2018 04:31 AM, Florian Larysch wrote:
qemu_create_pidfile does not truncate the pidfile when it creates it,
but rather overwrites its contents with the new pid. This works fine as
long as the length of the pid doesn't decrease, but this might happen in
case of wraparounds, causing pidfil
Hi
On Mon, Mar 19, 2018 at 5:21 PM, Stefan Berger
wrote:
> Fix the initialization of the tpmRegValidSts flag and set it to '1'
> during device reset without expecting a write to another register.
> This seems to also be the default behavior of real hardware.
>
> Signed-off-by: Stefan Berger
> --
On Mon, Mar 12, 2018 at 05:21:12PM +, Dr. David Alan Gilbert (git) wrote:
> From: "Dr. David Alan Gilbert"
>
> Provide a helper to be used by shared waker functions to request
> shared pages from the source.
> The last_rb pointer is moved into the incoming state since this
> helper can update
Hi,
I just tried to add luks support to qemu-iotests 025, a basic resize
test, which made me realise that luks doesn't read zeros in unwritten
blocks (which makes the test fail).
The reason for this is that we get zeros on the protocol layer (i.e. in
the encrpyted data as it is on the disk), but
On Tue, Mar 20, 2018 at 02:18:33PM +, Peter Maydell wrote:
> On 20 March 2018 at 03:16, Michael S. Tsirkin wrote:
> > Changes from v1:
> > - dropped include change for one generated file - proposed a tree-wide
> > refactoring
> > - dropped vhost used slot refactoring due to alignment issues f
I could imagine something like this, see attachment.
Michael
On 20.03.18 14:17, Christian Borntraeger wrote:
David, Jason, Michael,
the cpumodel code is somewhat fragile as we have to add maintain things
in multiple places. I would like to have more robust code, e.g. by either
generating more
We have our own copy of unistd so there is no
need to check for symbols present there.
Signed-off-by: Michael S. Tsirkin
---
migration/postcopy-ram.c | 4 +---
tests/migration-test.c | 2 +-
2 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/migration/postcopy-ram.c b/migration/pos
Detected by Coverity (CID 1386072, 1386073, 1386076, 1386077). local_err
was unused, and this made the static analyzer unhappy.
Signed-off-by: Paolo Bonzini
---
hw/sd/sdhci.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/hw/sd/sdhci.c b/hw/sd/sdhci.c
index 1b828b104d..
On Tue, Mar 20, 2018 at 02:36:01PM +, Peter Maydell wrote:
> On 20 March 2018 at 14:23, Daniel P. Berrangé wrote:
> > When doing a build with builddir != srcdir, if any generated files are
> > accidentally present in srcdir from a previous build, these can cause
> > unexpected failures.
> >
>
This trips Coverity, which believes the subsequent qio_channel_create_watch
can dereference a NULL pointer. In reality, tcp_chr_connect's callers
all have s->ioc properly initialized, since they are all rooted at
tcp_chr_new_client.
Signed-off-by: Paolo Bonzini
---
chardev/char-socket.c | 10 ++
On 03/20/2018 04:06 PM, Michael Mueller wrote:
> I could imagine something like this, see attachment.
Unless Conny is willing to take that also for 2.12, this looks like
a good thing to do after 2.12. (I suggest to go with my mininal
patch for 2.12)
>
> Michael
>
> On 20.03.18 14:17, Christian
Le 02/03/2018 à 15:13, Peter Maydell a écrit :
> On 28 December 2017 at 18:08, Luke Shumaker wrote:
>> From: Luke Shumaker
>>
>> At a fixed distance after the usable memory that init_guest_space maps, for
>> 32-bit ARM targets we also need to map a commpage. The normal
>> init_guest_space logic
Hi,
This series failed build test on s390x host. Please find the details below.
Type: series
Message-id: 1521545718.1125216.1309456936.3f023...@webmail.messagingengine.com
Subject: [Qemu-devel] [PATCH] nvdimm: ensure that dsm memory is read in
nvdimm_dsm_write
=== TEST SCRIPT BEGIN ===
#!/bin/b
On Tue, Mar 20, 2018 at 04:04:21PM +0100, Kevin Wolf wrote:
> Hi,
>
> I just tried to add luks support to qemu-iotests 025, a basic resize
> test, which made me realise that luks doesn't read zeros in unwritten
> blocks (which makes the test fail).
>
> The reason for this is that we get zeros on
On 20/03/2018 15:45, Edgar Kaziakhmedov wrote:
> Hi!
>
> Recently, I have started working on the real multi-queue implementation
> for the VirtIOBlock device and came to conclusion
> that for the time being it may work only with RAW images. The reason is
> obviously lack of the true thread-safe mu
From: "Dr. David Alan Gilbert"
On systems without userfault/eventfd/etc we need a stub
for it to link.
Signed-off-by: Dr. David Alan Gilbert
---
migration/postcopy-ram.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/migration/postcopy-ram.c b/migration/postcopy-ram.c
index 146bc09c
On 20 March 2018 at 15:05, Michael S. Tsirkin wrote:
> I'm curious why does it take that path though.
> Here's the rule
>
> #if defined(__linux__) && defined(__NR_userfaultfd) && defined(CONFIG_EVENTFD)
>
> If it's Linux we'll pick our own copy of the header
> and so __NR_userfaultfd is defined.
>
On 20 March 2018 at 09:08, Laurent Vivier wrote:
> The following changes since commit 55901900ec69d6fd6f332003d8ab81b2f8a38529:
>
> Merge remote-tracking branch
> 'remotes/vivier2/tags/linux-user-for-2.12-pull-request' into staging
> (2018-03-15 17:58:28 +)
>
> are available in the Git rep
On Tue, Mar 20, 2018 at 09:50:19AM -0500, Eric Blake wrote:
> However, I have to wonder if we have the opposite problem - when the
> file exists (truncated) but has not yet been written, how often do
> we have a race where someone can see the empty file?
>
> Should we be going even further and wri
On Tue, Mar 20, 2018 at 03:41:54PM +, Peter Maydell wrote:
> On 20 March 2018 at 15:05, Michael S. Tsirkin wrote:
> > I'm curious why does it take that path though.
> > Here's the rule
> >
> > #if defined(__linux__) && defined(__NR_userfaultfd) &&
> > defined(CONFIG_EVENTFD)
> >
> > If it's L
On 20 March 2018 at 15:23, Laurent Vivier wrote:
> Le 02/03/2018 à 15:13, Peter Maydell a écrit :
>> On 28 December 2017 at 18:08, Luke Shumaker wrote:
>>> +#if defined(TARGET_ARM) && !defined(TARGET_AARCH64)
>>> +/* On 32-bit ARM, we need to map not just the usable memory, but
>>> + * al
On 20 March 2018 at 15:51, Michael S. Tsirkin wrote:
> On Tue, Mar 20, 2018 at 03:41:54PM +, Peter Maydell wrote:
>> CONFIG_EVENTFD is set. __NR_userfaultfd is not. It isn't
>> defined in the system headers, and it's not defined in
>> our linux-headers/asm-arm64/. Only x86, s390, powerpc
>> an
On Tue, Mar 20, 2018 at 09:50:19AM -0500, Eric Blake wrote:
> On 03/20/2018 04:31 AM, Florian Larysch wrote:
> > qemu_create_pidfile does not truncate the pidfile when it creates it,
> > but rather overwrites its contents with the new pid. This works fine as
> > long as the length of the pid doesn'
On Tue, Mar 20, 2018 at 03:54:47PM +, Peter Maydell wrote:
> On 20 March 2018 at 15:51, Michael S. Tsirkin wrote:
> > On Tue, Mar 20, 2018 at 03:41:54PM +, Peter Maydell wrote:
> >> CONFIG_EVENTFD is set. __NR_userfaultfd is not. It isn't
> >> defined in the system headers, and it's not de
On 03/20/2018 11:02 AM, Daniel P. Berrangé wrote:
On Tue, Mar 20, 2018 at 09:50:19AM -0500, Eric Blake wrote:
On 03/20/2018 04:31 AM, Florian Larysch wrote:
qemu_create_pidfile does not truncate the pidfile when it creates it,
but rather overwrites its contents with the new pid. This works fine
* Michael S. Tsirkin (m...@redhat.com) wrote:
> This fixes the build on systems without userfaultfd.
>
> Signed-off-by: Michael S. Tsirkin
Reviewed-by: Dr. David Alan Gilbert
> ---
> migration/postcopy-ram.c | 8 +++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/migr
On 03/19/2018 08:54 PM, Michael S. Tsirkin wrote:
QEMU coding style at the moment asks for all non-system
include files to be used with #include "foo.h".
[I'm replying without having read the rest of the thread, so bear with
me if I repeat some of the other comments that have already been made
On Tue, Mar 20, 2018 at 4:18 PM, Paolo Bonzini wrote:
> This trips Coverity, which believes the subsequent qio_channel_create_watch
> can dereference a NULL pointer. In reality, tcp_chr_connect's callers
> all have s->ioc properly initialized, since they are all rooted at
> tcp_chr_new_client.
>
The value for "rom-size" is used as a divisor, so it must not be 0 or it
will segfault. A size of 0 wouldn't make sense anyhow.
Reviewed-by: Philippe Mathieu-Daudé
Signed-off-by: Wolfram Sang
---
hw/nvram/eeprom_at24c.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/hw/nvram/eeprom_at
I used this driver as a template for a custom one. While hacking on my own, I
noticed some problems in this driver, too. This series fixes the first set of
them, related to the "rom-size" parameter. It fixes a segfault.
I think the first patch is clearly suitable for stable. I think the second one
0 as "rom-size" will lead to an error message. Let's use the size of a
small 24c01 which has 128 byte.
Reviewed-by: Philippe Mathieu-Daudé
Signed-off-by: Wolfram Sang
---
hw/nvram/eeprom_at24c.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/hw/nvram/eeprom_at24c.c b/hw
On Tue, Mar 20, 2018 at 04:02:44PM +, Daniel P. Berrangé wrote:
> No, it is unsafe - we rely on lockf() to get the mutual exclusion.
> If a QEMU is running with pidfile locked, and its pid written into
> it, then a 2nd QEMU comes along it will truncate the pidfile owned
> by the original QEMU b
Replace the ERR macro with error_report() because fprintf is deprecated.
This also fixes the prefix printed out twice.
Reviewed-by: Philippe Mathieu-Daudé
Signed-off-by: Wolfram Sang
---
hw/nvram/eeprom_at24c.c | 17 ++---
1 file changed, 6 insertions(+), 11 deletions(-)
diff --git
On 03/20/2018 10:52 AM, Marc-André Lureau wrote:
Hi
On Mon, Mar 19, 2018 at 5:21 PM, Stefan Berger
wrote:
Fix the initialization of the tpmRegValidSts flag and set it to '1'
during device reset without expecting a write to another register.
This seems to also be the default behavior of real ha
On 3/20/18 6:34 PM, Paolo Bonzini wrote:
On 20/03/2018 15:45, Edgar Kaziakhmedov wrote:
As I understood from
Stefan description, it is expected to change significantly
the approach we use to interact with BlockDriverState.
I don't think the change is very large actually, at least for on-disk
On Tue, Mar 20, 2018 at 05:21:16PM +0100, Florian Larysch wrote:
> On Tue, Mar 20, 2018 at 04:02:44PM +, Daniel P. Berrangé wrote:
> > No, it is unsafe - we rely on lockf() to get the mutual exclusion.
> > If a QEMU is running with pidfile locked, and its pid written into
> > it, then a 2nd QEM
20.03.2018 16:44, Max Reitz wrote:
On 2018-03-19 10:02, Vladimir Sementsov-Ogievskiy wrote:
Consider migration with shared storage. Persistent bitmaps are stored
on bdrv_inactivate. Then, on destination
process_incoming_migration_bh() calls bdrv_invalidate_cache_all() which
leads to qcow2_load_a
20.03.2018 17:01, Max Reitz wrote:
On 2018-03-19 10:02, Vladimir Sementsov-Ogievskiy wrote:
Shared migration for dirty bitmaps is fixed by previous patches,
so we can enable the test.
Signed-off-by: Vladimir Sementsov-Ogievskiy
---
tests/qemu-iotests/169 | 8 +++-
1 file changed, 3 inse
Am 20.03.2018 um 02:54 schrieb Michael S. Tsirkin:
> QEMU coding style at the moment asks for all non-system
> include files to be used with #include "foo.h".
> However this rule actually does not make sense and
> creates issues for when the included file is generated.
>
> In C, include "file" mea
On Tue, Mar 20, 2018 at 11:12:00AM -0500, Eric Blake wrote:
> On 03/19/2018 08:54 PM, Michael S. Tsirkin wrote:
> > QEMU coding style at the moment asks for all non-system
> > include files to be used with #include "foo.h".
>
> [I'm replying without having read the rest of the thread, so bear with
On Tue, Mar 20, 2018 at 11:12:00AM -0500, Eric Blake wrote:
>
> Why can't we fix Makefile to include BOTH the build and the source
> directories (to pick up generated files first, and then version-controlled
> files), and possibly include logic to simplify to a single -I instead of two
> when doin
qemu_create_pidfile does not truncate the pidfile when it creates it,
but rather overwrites its contents with the new pid. This works fine as
long as the length of the pid doesn't decrease, but this might happen in
case of wraparounds, causing pidfiles to contain trailing garbage which
breaks opera
Now fixed in git master, should be in 2.12.
** Changed in: qemu
Status: New => Fix Committed
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1753314
Title:
UART in sabrelite machine simulati
This is now fixed in git master by commit 6461d7e2678fe4, which updates
the defines and also has a workaround for older guest kernels (which we
can remove if/when we model the IOMUX).
** Changed in: qemu
Status: New => Fix Committed
--
You received this bug notification because you are a
On 20 March 2018 at 15:13, Paolo Bonzini wrote:
> Detected by Coverity (CID 1386072, 1386073, 1386076, 1386077). local_err
> was unused, and this made the static analyzer unhappy.
>
> Signed-off-by: Paolo Bonzini
> ---
> hw/sd/sdhci.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
Hi all.
This fixes bitmaps migration through shared storage. Look at 02 for
details.
The bug introduced in 2.10 with the whole qcow2 bitmaps feature, so
qemu-stable in CC. However I doubt that someone really suffered from this.
Do we need dirty bitmaps at all in inactive case? - that was a quest
On reopen with existing bitmaps, instead of loading bitmaps, lets
reopen them if needed. This also fixes bitmaps migration through
shared storage.
Consider the case. Persistent bitmaps are stored on bdrv_inactivate.
Then, on destination process_incoming_migration_bh() calls
bdrv_invalidate_cache_al
On 20 March 2018 at 14:42, Michael S. Tsirkin wrote:
> Note: only patch 39/51 is attached.
> The rest are unchanged from v2.
>
> The following changes since commit 026aaf47c02b79036feb830206cfebb2a726510d:
>
> Merge remote-tracking branch
> 'remotes/ehabkost/tags/python-next-pull-request' into
Add version of qcow2_reopen_bitmaps_rw, which do the same work but
also return a hint about was header updated or not. This will be
used in the following fix for bitmaps reloading after migration.
Signed-off-by: Vladimir Sementsov-Ogievskiy
Reviewed-by: John Snow
Reviewed-by: Max Reitz
---
blo
Shared migration for dirty bitmaps is fixed by previous patches,
so we can enable the test.
Signed-off-by: Vladimir Sementsov-Ogievskiy
---
tests/qemu-iotests/169 | 8 +++-
tests/qemu-iotests/169.out | 4 ++--
2 files changed, 5 insertions(+), 7 deletions(-)
diff --git a/tests/qemu-iote
On reopen with existing bitmaps, instead of loading bitmaps, lets
reopen them if needed. This also fixes bitmaps migration through
shared storage.
Consider the case. Persistent bitmaps are stored on bdrv_inactivate.
Then, on destination process_incoming_migration_bh() calls
bdrv_invalidate_cache_al
Oh, sorry, just drop it.
(the only difference is commit message subject)
20.03.2018 20:05, Vladimir Sementsov-Ogievskiy wrote:
On reopen with existing bitmaps, instead of loading bitmaps, lets
reopen them if needed. This also fixes bitmaps migration through
shared storage.
Consider the case. Per
On Tue, Mar 20, 2018 at 05:33:42PM +0100, Stefan Weil wrote:
> Using <> for system include files and "" for local include files is a
> convention, and as far as I know most projects adhere to that
> convention. So does QEMU currently. Such conventions are not only
> important for humans, but also f
On Tue, Mar 20, 2018 at 02:54:37PM +0100, Max Reitz wrote:
> But I guess the main advantage with using this rule I see is that it's
> better for people reading the code. It's just nice to know whether a
> file belongs to qemu or not by just looking at the #include statement.
> (Note that this impl
Hi,
I just built qemu-system-ppc.exe for windows using a fully up-to-date Fedora 27.
Command line for build:
./configure --cross-prefix=x86_64-w64-mingw32-
--target-list="ppc-softmmu ppc64-softmmu" --enable-gtk
--with-gtkabi=3.0 --enable-sdl --with-sdlabi=2.0
Command line to invoke Qemu:
C:\qemu
Add the header and its dependencies.
Signed-off-by: Michael S. Tsirkin
---
scripts/update-linux-headers.sh | 17 ++---
1 file changed, 10 insertions(+), 7 deletions(-)
diff --git a/scripts/update-linux-headers.sh b/scripts/update-linux-headers.sh
index d18e2f1..e528bda 100755
--- a/
We have our own copy of unistd so there is no
need to check for symbols present there.
Signed-off-by: Michael S. Tsirkin
---
migration/postcopy-ram.c | 4 +---
tests/migration-test.c | 2 +-
2 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/migration/postcopy-ram.c b/migration/pos
We normally do not need to bother with ifdefs around
specific system-calls. userfaultfd turns out to be
different because our unistd import into linux-headers
is incomplete: it's missing asm-generic bits,
some arm and mips headers.
Fix it up, and drop ifdefs for usefaultfd.
Tested on x86 only.
P
ARM64 and MIPS depend on asm-generic/unistd.h for syscall numbers.
This adds asm-generic/unistd.h and it's dependencies.
Signed-off-by: Michael S. Tsirkin
---
linux-headers/asm-arm/bitsperlong.h | 1 +
linux-headers/asm-arm64/bitsperlong.h | 24 +
linux-headers/asm-generic/bitsperlong.h
On 20 March 2018 at 16:02, Michael S. Tsirkin wrote:
> On Tue, Mar 20, 2018 at 03:54:47PM +, Peter Maydell wrote:
>> > Let's update headers for arm and mips then?
>>
>> Shouldn't that happen automatically?
> And apparently it does for arm:
> linux-headers/asm-arm/unistd-common.h has __NR_user
On Tue, Mar 20, 2018 at 05:18:22PM +, Peter Maydell wrote:
> On 20 March 2018 at 16:02, Michael S. Tsirkin wrote:
> > On Tue, Mar 20, 2018 at 03:54:47PM +, Peter Maydell wrote:
> >> > Let's update headers for arm and mips then?
> >>
> >> Shouldn't that happen automatically?
>
> > And appa
On 20 March 2018 at 17:17, Michael S. Tsirkin wrote:
> We have our own copy of unistd so there is no
> need to check for symbols present there.
>
> Signed-off-by: Michael S. Tsirkin
I just sent a mail in the other thread about this, but we
only have our own copy of unistd if the host architectur
On 20 March 2018 at 17:17, Michael S. Tsirkin wrote:
> Add the header and its dependencies.
>
> Signed-off-by: Michael S. Tsirkin
> ---
> scripts/update-linux-headers.sh | 17 ++---
> 1 file changed, 10 insertions(+), 7 deletions(-)
>
> diff --git a/scripts/update-linux-headers.sh b/
Hi Eduardo, Thanks for the comments. Please see the response inline.
> -Original Message-
> From: Eduardo Habkost
> Sent: Friday, March 16, 2018 1:00 PM
> To: Moger, Babu
> Cc: pbonz...@redhat.com; r...@twiddle.net; rkrc...@redhat.com;
> Lendacky, Thomas ; Singh, Brijesh
> ; k...@vger.ke
On 03/20/2018 11:58 AM, Florian Larysch wrote:
qemu_create_pidfile does not truncate the pidfile when it creates it,
but rather overwrites its contents with the new pid. This works fine as
long as the length of the pid doesn't decrease, but this might happen in
case of wraparounds, causing pidfil
On Tue, Mar 20, 2018 at 05:20:04PM +, Peter Maydell wrote:
> On 20 March 2018 at 17:17, Michael S. Tsirkin wrote:
> > We have our own copy of unistd so there is no
> > need to check for symbols present there.
> >
> > Signed-off-by: Michael S. Tsirkin
>
> I just sent a mail in the other threa
On Tue, Mar 20, 2018 at 05:24:20PM +, Peter Maydell wrote:
> On 20 March 2018 at 17:17, Michael S. Tsirkin wrote:
> > Add the header and its dependencies.
> >
> > Signed-off-by: Michael S. Tsirkin
> > ---
> > scripts/update-linux-headers.sh | 17 ++---
> > 1 file changed, 10 inse
qemu_create_pidfile does not truncate the pidfile when it creates it,
but rather overwrites its contents with the new pid. This works fine as
long as the length of the pid doesn't decrease, but this might happen in
case of wraparounds, causing pidfiles to contain trailing garbage which
breaks opera
Changes since v2:
- add hv-reenlightenment CPU property [Roman Kagan, Paolo Bonzini]
- add a comment to feature_word_info [Roman Kagan]
Previously, Ladi was working on enabling TSC page clocksource for nested
Hyper-V-on-KVM workloads. He found out that if Hyper-V frequency MSRs are
exposed to L1 a
On 02/28/2018 12:05 PM, Max Reitz wrote:
This patch allows the user to specify whether to use active or only
background mode for mirror block jobs. Currently, this setting will
remain constant for the duration of the entire block job.
Signed-off-by: Max Reitz
---
qapi/block-core.json |
KVM recently gained support for Hyper-V Reenlightenment MSRs which are
required to make KVM-on-Hyper-V enable TSC page clocksource to its guests
when INVTSC is not passed to it (and it is not passed by default in Qemu
as it effectively blocks migration).
Signed-off-by: Vitaly Kuznetsov
---
Change
Use qemu_uuid_unparse() instead of uuid_unparse() to make vdi.c compile
again when CONFIG_VDI_DEBUG is set. In order to prevent future bitrot,
replace '#ifdef CONFIG_VDI_DEBUG' by 'if (VDI_DEBUG)' so that the
compiler always sees the code.
Signed-off-by: Kevin Wolf
---
block/vdi.c | 22 +
On Tue, Mar 20, 2018 at 07:10:42PM +0200, Michael S. Tsirkin wrote:
> On Tue, Mar 20, 2018 at 05:33:42PM +0100, Stefan Weil wrote:
> > Using <> for system include files and "" for local include files is a
> > convention, and as far as I know most projects adhere to that
> > convention. So does QEMU
What static=on really does is what we call metadata preallocation for
other block drivers. While we can still change the QMP interface, make
it more consistent by using 'preallocation' for VDI, too.
This doesn't implement any new functionality, so the only supported
preallocation modes are 'off' a
Commit e39e959e fixed an invalid assertion in the .bdrv_length
implementation, but left a similar assertion in place for
.bdrv_truncate. Instead of crashing when the user requests a too large
image size, fail gracefully.
A file size of exactly INT64_MAX caused failure before, but is actually
legal
It's unclear what the real maximum is, but we use an uint32_t to store
the log size in vhdx_co_create(), so we should check that the given
value fits in 32 bits.
Signed-off-by: Kevin Wolf
---
block/vhdx.c | 4
1 file changed, 4 insertions(+)
diff --git a/block/vhdx.c b/block/vhdx.c
index 0
We want to test resizing even for luks. The only change that is needed
is to explicitly zero out new space for luks because it's undefined.
Signed-off-by: Kevin Wolf
---
tests/qemu-iotests/025 | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/tests/qemu-iotests/025 b/te
Requiring tsc_is_stable_and_known() is too restrictive: even without INVTCS
nested Hyper-V-on-KVM enables TSC pages for its guests e.g. when
Reenlightenment MSRs are present. Presence of frequency MSRs doesn't mean
these frequencies are stable, it just means they're available for reading.
Signed-o
It's unclear what the real maximum cluster size is for the Parallels
format, but let's at least make sure that we don't get integer
overflows in our .bdrv_co_create implementation.
Signed-off-by: Kevin Wolf
---
block/parallels.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/block/para
This series adds qemu-iotests for a few more block drivers (yet more to
come in another series) and fixes a few things that previous review and
these tests brought up.
The only major design change is that I converted the vdi block driver
from a boolean 'static' create option to the standard 'preal
Signed-off-by: Kevin Wolf
---
tests/qemu-iotests/213 | 349 +
tests/qemu-iotests/213.out | 121
tests/qemu-iotests/group | 1 +
3 files changed, 471 insertions(+)
create mode 100755 tests/qemu-iotests/213
create mode 100644 te
error_setg_errno() is meant for cases where we got an errno from the OS
that can add useful extra information to an error message. It's
pointless if we pass a constant errno, these cases should use plain
error_setg().
Signed-off-by: Kevin Wolf
---
block/vhdx.c | 9 -
1 file changed, 4 in
On Tue, Mar 20, 2018 at 05:33:42PM +0100, Stefan Weil wrote:
>
> Very large projects often split in sub projects, maybe one of them
> describing the API. Then that API headers are similar to system headers
> and can be included using <>, although they still belong to the same
> larger project. Do
101 - 200 of 301 matches
Mail list logo
