Alex Bennée writes:
> Markus Armbruster writes:
>
>> Machine "ref405ep" maps its flash memory at address 2^32 - image size.
>> Image size is rounded up to the next multiple of 64KiB. Useless,
>> because pflash_cfi02_realize() fails with "failed to read the initial
>> flash content" unless the r
Am 21.12.2018 um 11:16 hat Yaowei Bai geschrieben:
> This patch introduces a new utility, qemu-tcmu. Apart from the
> underlaying protocol it interacts with the world much like
> qemu-nbd. This patch bases on Fam's version.
>
> Qemu-tcmu handles SCSI commands which are passed through userspace
> f
On 3/6/19 9:26 AM, Vladimir Sementsov-Ogievskiy wrote:
> 01.03.2019 22:15, John Snow wrote:
>> Set the inconsistent bit on load instead of rejecting such bitmaps.
>> There is no way to un-set it; the only option is to delete it.
>
> I think, s/delete it/delete the bitmap/, as "it" is the bit af
On Fri, Mar 01, 2019 at 02:38:45PM +, Peter Maydell wrote:
> On Fri, 22 Feb 2019 at 19:41, Cleber Rosa wrote:
> >
> > The following changes since commit 8eb29f1bf5a974dc4c11d2d1f5e7c7f7a62be116:
> >
> > Merge remote-tracking branch
> > 'remotes/awilliam/tags/vfio-updates-20190221.0' into st
Our permission system is useful to define what operations are allowed
on a certain block node and includes things like BLK_PERM_WRITE or
BLK_PERM_RESIZE among others.
One of the permissions is BLK_PERM_GRAPH_MOD which allows "changing
the node that this BdrvChild points to". The exact meaning of t
Signed-off-by: Alberto Garcia
---
block/commit.c | 16
1 file changed, 16 insertions(+)
diff --git a/block/commit.c b/block/commit.c
index 3b46ca7f97..ba60fef58a 100644
--- a/block/commit.c
+++ b/block/commit.c
@@ -39,6 +39,7 @@ typedef struct CommitBlockJob {
BlockDriverSt
This patch adds several tests for the x-blockdev-reopen QMP command.
Signed-off-by: Alberto Garcia
---
tests/qemu-iotests/243 | 991 +
tests/qemu-iotests/243.out | 5 +
tests/qemu-iotests/group | 1 +
3 files changed, 997 insertions(+)
creat
Signed-off-by: Alberto Garcia
---
block/mirror.c | 8
1 file changed, 8 insertions(+)
diff --git a/block/mirror.c b/block/mirror.c
index 726d3c27fb..010fdafd79 100644
--- a/block/mirror.c
+++ b/block/mirror.c
@@ -630,6 +630,10 @@ static int mirror_exit_common(Job *job)
}
s->pr
Of all options of type BlockdevRef used to specify children in
BlockdevOptions, 'backing' is the only one that is optional.
For "x-blockdev-reopen" we want that if an option is omitted then it
must be reset to its default value. The default value of 'backing'
means that QEMU opens the backing file
If we reopen a BlockDriverState and there is an option that is present
in bs->options but missing from the new set of options then we have to
return an error unless the driver is able to reset it to its default
value.
This patch adds a new 'mutable_opts' field to BlockDriver. This is
a list of run
Hi,
here's a new version of the patches to add a new QMP command for
bdrv_reopen().
Refer to the cover letter of v1 for a complete description of the
feature:
https://lists.gnu.org/archive/html/qemu-block/2019-01/msg00623.html
Regards,
Berto
v2:
- Patch 1: Update documentation, fix check i
Signed-off-by: Alberto Garcia
---
block/stream.c | 21 +
1 file changed, 21 insertions(+)
diff --git a/block/stream.c b/block/stream.c
index e14579ff80..6253c86fae 100644
--- a/block/stream.c
+++ b/block/stream.c
@@ -35,6 +35,7 @@ typedef struct StreamBlockJob {
Blockdev
bdrv_reopen_prepare() receives a BDRVReopenState with (among other
things) a new set of options to be applied to that BlockDriverState.
If an option is missing then it means that we want to reset it to its
default value rather than keep the previous one. This way the state
of the block device afte
This command allows reopening an arbitrary BlockDriverState with a
new set of options. Some options (e.g node-name) cannot be changed
and some block drivers don't allow reopening, but otherwise this
command is modelled after 'blockdev-add' and the state of the reopened
BlockDriverState should gener
The bdrv_reopen_queue() function is used to create a queue with
the BDSs that are going to be reopened and their new options. Once
the queue is ready bdrv_reopen_multiple() is called to perform the
operation.
The original options from each one of the BDSs are kept, with the new
options passed to b
Children in QMP are specified with BlockdevRef / BlockdevRefOrNull,
which can contain a set of child options, a child reference, or
NULL. In optional attributes like "backing" it can also be missing.
Only the first case (set of child options) is being handled properly
by bdrv_reopen_queue(). This
This patch allows the user to change the backing file of an image that
is being reopened. Here's what it does:
- In bdrv_reopen_prepare(): check that the value of 'backing' points
to an existing node or is null. If it points to an existing node it
also needs to make sure that replacing the
This parameter has been unused since 1a63a907507fbbcfaee3f622907ec244b
Signed-off-by: Alberto Garcia
---
block.c | 4 ++--
block/replication.c | 3 +--
include/block/block.h | 2 +-
qemu-io-cmds.c| 2 +-
4 files changed, 5 insertions(+), 6 deletions(-)
diff --git a/block
Am 06.03.2019 um 18:59 hat Andrey Shinkevich geschrieben:
> On 06/03/2019 17:51, Kevin Wolf wrote:
> > This fixes it for me (the first hunk is actually a bonus which fixes a
> > preexisting bug, which somehow meant that the reason was not printed):
> >
> > diff --git a/tests/qemu-iotests/iotests.p
On 06/03/2019 17:31, Kevin Wolf wrote:
> Am 04.03.2019 um 11:08 hat Andrey Shinkevich geschrieben:
>> Supported formats listed by 'qemu' may differ from those listed by
>> 'qemu-img' due to whitelists. Some test cases require specific formats
>> that may be used with qemu. They can be inquired di
On 06/03/2019 17:51, Kevin Wolf wrote:
> Am 04.03.2019 um 11:08 hat Andrey Shinkevich geschrieben:
>> Supported formats listed by 'qemu' may differ from those listed by
>> 'qemu-img' due to whitelists. Some test cases require specific formats
>> that may be used with qemu. They can be inquired di
On 06/03/2019 17:52, Kevin Wolf wrote:
> Am 04.03.2019 um 11:08 hat Andrey Shinkevich geschrieben:
>> Some test cases require specific formats. The method decorator
>> skip_if_unsupported() checks if requested formats are whitelisted.
>> The test #139 was selected for a sample output:
>>
>> 137 3
06.03.2019 19:11, Eric Blake wrote:
> On 2/11/19 6:55 AM, Vladimir Sementsov-Ogievskiy wrote:
>> Hi all!
>>
>> Here is a try of moving to non-blocking negotiation in nbd
>> code, proposed by Deniel in
>> https://lists.gnu.org/archive/html/qemu-devel/2019-01/msg03817.html
>>
>> in thread "[PATCH v4
06.03.2019 18:59, John Snow wrote:
>
>
> On 3/6/19 7:58 AM, Eric Blake wrote:
>> On 3/5/19 5:43 PM, John Snow wrote:
>>> Usually, we only write out bitmaps when we're about to close out the file,
>>> so we always remove the bitmaps after to make it easier to determine the
>>> source of truth for
On 2/11/19 6:55 AM, Vladimir Sementsov-Ogievskiy wrote:
> Hi all!
>
> Here is a try of moving to non-blocking negotiation in nbd
> code, proposed by Deniel in
> https://lists.gnu.org/archive/html/qemu-devel/2019-01/msg03817.html
>
> in thread "[PATCH v4 00/10] NBD reconnect"
> https://lists.gnu.o
06.03.2019 2:43, John Snow wrote:
> If we were to allow resizes, the length check that happens when we load
> bitmap headers from disk when we read or store bitmaps would begin to
> fail:
>
> Imagine the circumstance where we've resized bitmaps in memory, but they still
> have the old values on-di
On 3/6/19 7:58 AM, Eric Blake wrote:
> On 3/5/19 5:43 PM, John Snow wrote:
>> Usually, we only write out bitmaps when we're about to close out the file,
>> so we always remove the bitmaps after to make it easier to determine the
>> source of truth for migration purposes.
>>
>> However, there may
06.03.2019 18:52, Vladimir Sementsov-Ogievskiy wrote:
> 06.03.2019 18:41, John Snow wrote:
>>
>>
>> On 3/6/19 10:33 AM, Vladimir Sementsov-Ogievskiy wrote:
>>> 06.03.2019 2:43, John Snow wrote:
Since we now load all bitmaps into memory anyway, we can just truncate them
in-memory and then
06.03.2019 18:41, John Snow wrote:
>
>
> On 3/6/19 10:33 AM, Vladimir Sementsov-Ogievskiy wrote:
>> 06.03.2019 2:43, John Snow wrote:
>>> Since we now load all bitmaps into memory anyway, we can just truncate them
>>> in-memory and then flush them back to disk. Just in case, we will still
>>> ch
06.03.2019 18:36, Eric Blake wrote:
> On 3/6/19 9:33 AM, Vladimir Sementsov-Ogievskiy wrote:
>
>>> +/* Flush bitmaps */
>>> +if (s->nb_bitmaps) {
>>> +Error *local_err = NULL;
>>> +
>>> +/* Usually, bitmaps get resized after this call.
>>> + * Force it earlier so we
On 3/6/19 10:33 AM, Vladimir Sementsov-Ogievskiy wrote:
> 06.03.2019 2:43, John Snow wrote:
>> Since we now load all bitmaps into memory anyway, we can just truncate them
>> in-memory and then flush them back to disk. Just in case, we will still check
>> and enforce that this shortcut is valid -
On 3/6/19 10:28 AM, Vladimir Sementsov-Ogievskiy wrote:
> 06.03.2019 2:43, John Snow wrote:
>> We tend to remove bitmaps when we flush them to disk, but it's not
>> appropriate
>> in all cases. let the reopen mechanism use the lighter weight flush instead
>> of
>> the heavier store.
>>
>> Sign
On 3/6/19 9:33 AM, Vladimir Sementsov-Ogievskiy wrote:
>> +/* Flush bitmaps */
>> +if (s->nb_bitmaps) {
>> +Error *local_err = NULL;
>> +
>> +/* Usually, bitmaps get resized after this call.
>> + * Force it earlier so we can make the metadata consistent. */
>> +
On 3/6/19 10:21 AM, Vladimir Sementsov-Ogievskiy wrote:
> 06.03.2019 2:43, John Snow wrote:
>> If we were to allow resizes, the length check that happens when we load
>> bitmap headers from disk when we read or store bitmaps would begin to
>> fail:
>>
>> Imagine the circumstance where we've resi
06.03.2019 2:43, John Snow wrote:
> Since we now load all bitmaps into memory anyway, we can just truncate them
> in-memory and then flush them back to disk. Just in case, we will still check
> and enforce that this shortcut is valid -- i.e. that any bitmap described
> on-disk is indeed in-memory a
On 3/6/19 9:24 AM, John Snow wrote:
>>>
>>> We could always split it back out later, but in basic terms for
>>> permissions and user perspective, "in use" seems robust enough of a
>>> resolution. (It might be safe to read, it might not be, who knows --
>>> it's in use.)
>>
>> I think, if we need s
06.03.2019 2:43, John Snow wrote:
> We tend to remove bitmaps when we flush them to disk, but it's not appropriate
> in all cases. let the reopen mechanism use the lighter weight flush instead of
> the heavier store.
>
> Signed-off-by: John Snow
> ---
> block/qcow2-bitmap.c | 2 +-
> 1 file ch
On 3/6/19 8:57 AM, Vladimir Sementsov-Ogievskiy wrote:
> 01.03.2019 23:04, John Snow wrote:
>>
>>
>> On 3/1/19 2:57 PM, Eric Blake wrote:
>>> On 3/1/19 1:48 PM, John Snow wrote:
>>>
> I understand forbidding inconsistent sources (because if the source is
> potentially missing bits, then
06.03.2019 2:43, John Snow wrote:
> If we were to allow resizes, the length check that happens when we load
> bitmap headers from disk when we read or store bitmaps would begin to
> fail:
>
> Imagine the circumstance where we've resized bitmaps in memory, but they still
> have the old values on-di
On 3/6/19 8:44 AM, Vladimir Sementsov-Ogievskiy wrote:
> 01.03.2019 22:15, John Snow wrote:
>> Instead of checking against busy, inconsistent, or read only directly,
>> use a check function with permissions bits that let us streamline the
>> checks without reproducing them in many places.
>>
>>
On 3/6/19 8:05 AM, Vladimir Sementsov-Ogievskiy wrote:
> 01.03.2019 22:15, John Snow wrote:
>> Even though the status field is deprecated, we still have to support
>> it for a few more releases. Since this is a very new kind of bitmap
>> state, it makes sense for it to have its own status field.
On 3/6/19 7:25 AM, Vladimir Sementsov-Ogievskiy wrote:
> 01.03.2019 22:15, John Snow wrote:
>> Add an inconsistent bit to dirty-bitmaps that allows us to report a bitmap as
>> persistent but potentially inconsistent, i.e. if we find bitmaps on a qcow2
>> that have been marked as "in use".
>>
>>
Am 06.03.2019 um 13:43 hat Eric Blake geschrieben:
> On 3/6/19 3:51 AM, Stefan Hajnoczi wrote:
> > On Fri, Mar 01, 2019 at 10:32:27AM -0600, Eric Blake wrote:
> >> On 3/1/19 10:17 AM, Stefan Hajnoczi wrote:
> >>> On Wed, Feb 27, 2019 at 06:22:39PM +0100, Kevin Wolf wrote:
> @@ -148,6 +170,7 @@
Philippe Mathieu-Daudé writes:
> On 2/26/19 8:34 PM, Markus Armbruster wrote:
>> pflash_cfi02_register() takes a size in bytes, a block size in bytes
>> and a number of blocks. r2d_init() passes FLASH_SIZE, 16 * KiB,
>> FLASH_SIZE >> 16. Does not compute: size doesn't match block size *
>> numb
Am 06.03.2019 um 14:04 hat Eric Blake geschrieben:
> On 3/6/19 7:03 AM, Alberto Garcia wrote:
> > On Tue 05 Mar 2019 07:29:08 PM CET, Eric Blake wrote:
> >> When iotest 223 was first written, it didn't matter if we waited for
> >> the qemu process to clean up. But with the introduction of a later
>
Am 04.03.2019 um 11:08 hat Andrey Shinkevich geschrieben:
> Some test cases require specific formats. The method decorator
> skip_if_unsupported() checks if requested formats are whitelisted.
> The test #139 was selected for a sample output:
>
> 137 3s ...
> 138 0s ...
> 139 2s ...
> [case not
Am 04.03.2019 um 11:08 hat Andrey Shinkevich geschrieben:
> Supported formats listed by 'qemu' may differ from those listed by
> 'qemu-img' due to whitelists. Some test cases require specific formats
> that may be used with qemu. They can be inquired directly by running
> 'qemu -drive format=help'.
On Wed, 6 Mar 2019 at 11:09, Laurent Vivier wrote:
>
> The following changes since commit a3e3b0a7bd5de211a62cdf2d6c12b96d3c403560:
>
> Merge remote-tracking branch 'remotes/armbru/tags/pull-qapi-2019-03-05'
> into staging (2019-03-05 19:23:45 +)
>
> are available in the Git repository at:
Am 04.03.2019 um 11:08 hat Andrey Shinkevich geschrieben:
> Supported formats listed by 'qemu' may differ from those listed by
> 'qemu-img' due to whitelists. Some test cases require specific formats
> that may be used with qemu. They can be inquired directly by running
> 'qemu -drive format=help'.
> On Mar 6, 2019, at 04:38, Laurent Vivier wrote:
>
> Applied to my trivial-patches branch.
Great, thanks!
Cheers,
Steve
01.03.2019 22:15, John Snow wrote:
> Set the inconsistent bit on load instead of rejecting such bitmaps.
> There is no way to un-set it; the only option is to delete it.
I think, s/delete it/delete the bitmap/, as "it" is the bit after "un-set it".
>
> Obvervations:
> - bitmap loading does not n
Philippe Mathieu-Daudé writes:
> While reviewing Markus' series [*] I splitted the last patch (6/6) to
> understand it better.
>
> [*] https://lists.gnu.org/archive/html/qemu-devel/2019-02/msg06798.html
>
> Based-on: <20190225183757.27378-6-arm...@redhat.com>
I'll work this split into my v2. Th
Laszlo Ersek writes:
> On 03/04/19 20:48, Philippe Mathieu-Daudé wrote:
>> Add an helper to access the opaque struct PFlashCFI01.
>>
>> Signed-off-by: Markus Armbruster
>> [PMD: Extracted from bigger patch]
>> Signed-off-by: Philippe Mathieu-Daudé
>> ---
>> hw/block/pflash_cfi01.c | 5 +
Philippe Mathieu-Daudé writes:
> On 3/4/19 4:33 PM, Markus Armbruster wrote:
>> Philippe Mathieu-Daudé writes:
>>> On 3/4/19 8:25 AM, Markus Armbruster wrote:
Magnus Damm writes:
> On Wed, Feb 20, 2019 at 2:31 AM Markus Armbruster
> wrote:
>> Perhaps Magnus, who maintains the
01.03.2019 22:15, John Snow wrote:
> We didn't do any state checking on source bitmaps at all,
> so this adds inconsistent and busy checks. readonly is
> allowed, so you can still copy a readonly bitmap to a new
> destination to use it for operations like drive-backup.
>
> Signed-off-by: John Snow
01.03.2019 23:04, John Snow wrote:
>
>
> On 3/1/19 2:57 PM, Eric Blake wrote:
>> On 3/1/19 1:48 PM, John Snow wrote:
>>
I understand forbidding inconsistent sources (because if the source is
potentially missing bits, then the merge destination will also be
missing bits and thus be
01.03.2019 22:15, John Snow wrote:
> Remove is an inherently RW operation, so this will fail anyway, but
> we can fail it very quickly instead of trying and failing, so do so.
>
> Signed-off-by: John Snow
Reviewed-by: Vladimir Sementsov-Ogievskiy
> ---
> blockdev.c | 3 ++-
> 1 file chang
01.03.2019 22:15, John Snow wrote:
> drive and blockdev backup cannot use readonly bitmaps, because the
> sync=incremental mechanism actually edits the bitmaps on success.
>
> If you really want to do this operation, use a copied bitmap.
>
> Signed-off-by: John Snow
Reviewed-by: Vladimir Semen
01.03.2019 22:15, John Snow wrote:
> Instead of checking against busy, inconsistent, or read only directly,
> use a check function with permissions bits that let us streamline the
> checks without reproducing them in many places.
>
> Included in this patch are permissions changes that simply add t
06.03.2019 16:06, Vladimir Sementsov-Ogievskiy wrote:
> 06.03.2019 15:25, Vladimir Sementsov-Ogievskiy wrote:
>> 01.03.2019 22:15, John Snow wrote:
>>> Add an inconsistent bit to dirty-bitmaps that allows us to report a bitmap
>>> as
>>> persistent but potentially inconsistent, i.e. if we find bit
06.03.2019 15:25, Vladimir Sementsov-Ogievskiy wrote:
> 01.03.2019 22:15, John Snow wrote:
>> Add an inconsistent bit to dirty-bitmaps that allows us to report a bitmap as
>> persistent but potentially inconsistent, i.e. if we find bitmaps on a qcow2
>> that have been marked as "in use".
>>
>> Sign
01.03.2019 22:15, John Snow wrote:
> Even though the status field is deprecated, we still have to support
> it for a few more releases. Since this is a very new kind of bitmap
> state, it makes sense for it to have its own status field.
>
> Reviewed-by: Eric Blake
> Signed-off-by: John Snow
> --
On 3/6/19 7:03 AM, Alberto Garcia wrote:
> On Tue 05 Mar 2019 07:29:08 PM CET, Eric Blake wrote:
>> When iotest 223 was first written, it didn't matter if we waited for
>> the qemu process to clean up. But with the introduction of a later
>> qemu-nbd process trying to reuse the same file, there is
On Tue 05 Mar 2019 07:29:08 PM CET, Eric Blake wrote:
> When iotest 223 was first written, it didn't matter if we waited for
> the qemu process to clean up. But with the introduction of a later
> qemu-nbd process trying to reuse the same file, there is a race where
> even though the asynchronous qe
On 3/5/19 5:43 PM, John Snow wrote:
> Usually, we only write out bitmaps when we're about to close out the file,
> so we always remove the bitmaps after to make it easier to determine the
> source of truth for migration purposes.
>
> However, there may be times we want to flush bitmap data more ag
Stefan Hajnoczi writes:
> On Fri, Mar 01, 2019 at 10:30:07AM -0600, Eric Blake wrote:
>> On 3/1/19 10:09 AM, Stefan Hajnoczi wrote:
>> > Commit dd577a26ff03b6829721b1ffbbf9e7c411b72378 ("block/file-posix:
>> > implement bdrv_co_invalidate_cache() on Linux") introduced page cache
>> > invalidation
Kevin Wolf writes:
> Am 01.03.2019 um 14:47 hat Sergio Lopez geschrieben:
>> >> Otherwise, we can simply add an extra condition at
>> >> child_job_drained_poll(), before the drv->drained_poll(), to return
>> >> true if the job isn't yet paused.
>> >
>> > Yes, I think something like this is this
On 3/6/19 4:18 AM, Stefan Hajnoczi wrote:
>> Question - if we used qapi's 'if':COND to only declare the field on
>> platforms where we know at compile time that we can support it, would
>> that be enough for libvirt to introspect that if the field exists then
>> migration is safe, without having t
On 3/6/19 3:51 AM, Stefan Hajnoczi wrote:
> On Fri, Mar 01, 2019 at 10:32:27AM -0600, Eric Blake wrote:
>> On 3/1/19 10:17 AM, Stefan Hajnoczi wrote:
>>> On Wed, Feb 27, 2019 at 06:22:39PM +0100, Kevin Wolf wrote:
@@ -148,6 +170,7 @@ be stored. Each extension has a structure like the
fol
On 3/5/19 5:43 PM, John Snow wrote:
> If we were to allow resizes, the length check that happens when we load
> bitmap headers from disk when we read or store bitmaps would begin to
> fail:
>
> Imagine the circumstance where we've resized bitmaps in memory, but they still
> have the old values on-
01.03.2019 22:15, John Snow wrote:
> Add an inconsistent bit to dirty-bitmaps that allows us to report a bitmap as
> persistent but potentially inconsistent, i.e. if we find bitmaps on a qcow2
> that have been marked as "in use".
>
> Signed-off-by: John Snow
> ---
> qapi/block-core.json
From: Thomas Huth
These checks at the beginning of some of the tests are mostly useless:
We only run the tests on x86 anyway, and g_test_message() does not
print anything unless you call g_test_init() first.
Signed-off-by: Thomas Huth
Acked-by: John Snow
Acked-by: Corey Minyard
Message-Id: <1
From: Like Xu
Signed-off-by: Like Xu
Reviewed-by: Eric Blake
Message-Id: <1550640446-18788-1-git-send-email-like...@linux.intel.com>
Signed-off-by: Laurent Vivier
---
docs/COLO-FT.txt | 2 +-
docs/amd-memory-encryption.txt | 2 +-
docs/can.txt | 2 +-
docs/colo
From: Wei Yang
Function pc_acpi_init() is not used anymore.
Remove the definition and declaration.
Signed-off-by: Wei Yang
Reviewed-by: Philippe Mathieu-Daudé
Tested-by: Philippe Mathieu-Daudé
Reviewed-by: Igor Mammedov
Reviewed-by: Thomas Huth
Message-Id: <20190214084939.20640-2-richardw.
From: Aarushi Mehta
Note that since thunking occurs throughout the lifetime of the QEMU
instance, there is no matching 'free' to correct.
Signed-off-by: Aarushi Mehta
Reviewed-by: Eric Blake
Reviewed-by: Stefan Hajnoczi
Message-Id: <5310bd5d152fa36c1828a7cbd19fc893739d1609.ca...@gmail.com>
Si
From: Igor Mammedov
cleanup file_backend_memory_alloc() by using one CONFIG_POSIX ifdef
instead of several ones within the function to make it simpler to follow.
Signed-off-by: Igor Mammedov
Suggested-by: Wei Yang
Reviewed-by: Wei Yang
Message-Id: <20190213123858.24620-1-imamm...@redhat.com>
The following changes since commit a3e3b0a7bd5de211a62cdf2d6c12b96d3c403560:
Merge remote-tracking branch 'remotes/armbru/tags/pull-qapi-2019-03-05' into
staging (2019-03-05 19:23:45 +)
are available in the Git repository at:
git://github.com/vivier/qemu.git tags/trivial-branch-pull-req
From: Stephen Checkoway
Don't dynamically allocate the pflash's timer. But do use timer_del in
an unrealize function to make sure that the timer can't fire after the
pflash_t has been freed.
Signed-off-by: Stephen Checkoway
Reviewed-by: Philippe Mathieu-Daudé
Reviewed-by: Wei Yang
Message-Id:
From: Wei Yang
Function acpi_table_add_builtin() is not used anymore.
Remove the definition and declaration.
Signed-off-by: Wei Yang
Reviewed-by: Philippe Mathieu-Daudé
Tested-by: Philippe Mathieu-Daudé
Reviewed-by: Igor Mammedov
Message-Id: <20190214084939.20640-3-richardw.y...@linux.intel
From: Markus Armbruster
Cc: Fam Zheng
Signed-off-by: Markus Armbruster
Message-Id: <20190213130240.15492-1-arm...@redhat.com>
Signed-off-by: Laurent Vivier
---
rules.mak | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/rules.mak b/rules.mak
index 86e033d81565..19f3d2c1261d
From: Greg Kurz
All accessors that have an endian infix DO have an underscore between
{size} and {endian}.
Signed-off-by: Greg Kurz
Reviewed-by: Richard Henderson
Reviewed-by: Philippe Mathieu-Daudé
Message-Id: <155119086741.1037569.12734854713022304642.st...@bahia.lan>
Signed-off-by: Laurent
From: Wei Yang
acpi_table_builtin is now always false, it is not necessary to check it
again.
This patch just removes it.
Signed-off-by: Wei Yang
Reviewed-by: Philippe Mathieu-Daudé
Tested-by: Philippe Mathieu-Daudé
Reviewed-by: Igor Mammedov
Message-Id: <20190214084939.20640-4-richardw.y..
Am 05.03.2019 um 19:29 hat Eric Blake geschrieben:
> When iotest 223 was first written, it didn't matter if we waited for
> the qemu process to clean up. But with the introduction of a later
> qemu-nbd process trying to reuse the same file, there is a race where
> even though the asynchronous qemu
Am 13.02.2019 um 17:48 hat Alberto Garcia geschrieben:
> QEMU 2.12 (commit 1221fe6f636754ab5f2c1c87caa77633e9123622) introduced
> a new setting called l2-cache-entry-size that allows making entries on
> the qcow2 L2 cache smaller than the cluster size.
>
> I have been performing several tests with
On Tue, Mar 05, 2019 at 04:46:34PM +0100, Niels de Vos wrote:
> The glfs_*_async() functions do a callback once finished. This callback
> has changed its arguments, pre- and post-stat structures have been
> added. This makes it possible to improve caching, which is useful for
> Samba and NFS-Ganesh
Hi Niels,
On Tue, Mar 05, 2019 at 04:46:33PM +0100, Niels de Vos wrote:
> From: Prasanna Kumar Kalever
>
> New versions of Glusters libgfapi.so have an updated glfs_ftruncate()
> function that returns additional 'struct stat' structures to enable
> advanced caching of attributes. This is useful
On Fri, Mar 01, 2019 at 10:30:07AM -0600, Eric Blake wrote:
> On 3/1/19 10:09 AM, Stefan Hajnoczi wrote:
> > Commit dd577a26ff03b6829721b1ffbbf9e7c411b72378 ("block/file-posix:
> > implement bdrv_co_invalidate_cache() on Linux") introduced page cache
> > invalidation so that cache.direct=off live m
On Fri, Mar 01, 2019 at 10:32:27AM -0600, Eric Blake wrote:
> On 3/1/19 10:17 AM, Stefan Hajnoczi wrote:
> > On Wed, Feb 27, 2019 at 06:22:39PM +0100, Kevin Wolf wrote:
> >> @@ -148,6 +170,7 @@ be stored. Each extension has a structure like the
> >> following:
> >> 0x6803f
On 19/02/2019 16:37, Stephen Checkoway wrote:
> Don't dynamically allocate the pflash's timer. But do use timer_del in
> an unrealize function to make sure that the timer can't fire after the
> pflash_t has been freed.
>
> Signed-off-by: Stephen Checkoway
> ---
> hw/block/pflash_cfi02.c | 15 +++
89 matches
Mail list logo
