On Wed, Jun 17, 2020 at 09:11:28AM +0200, Gerd Hoffmann wrote:
> First batch of microvm patches, some generic acpi stuff.
> Split the acpi-build.c monster, specifically split the
> pc and q35 and pci bits into a separate file which we
> can skip building at some point in the future.
Thanks for
On Wed, Jun 17, 2020 at 09:11:36AM +0200, Gerd Hoffmann wrote:
> The _STA methods for COM+LPT used to reference them,
> but that isn't the case any more.
>
> piix4 DSDT changes:
>
> Scope (_SB.PCI0)
> {
> Device (ISA)
> {
> Name (_ADR, 0x0001) //
On Wed, Jun 17, 2020 at 09:11:30AM +0200, Gerd Hoffmann wrote:
> DSDT change: isa device order changes in case MI1 (ipmi) is present.
>
> Signed-off-by: Gerd Hoffmann
> Reviewed-by: Igor Mammedov
> ---
Pls follow process outlined at the top of tests/qtest/bios-tables-test.c
Don't change
On Wed, Jun 17, 2020 at 09:11:33AM +0200, Gerd Hoffmann wrote:
> DSDT change: isa device order changes in case MI1 (ipmi) is present.
>
> Signed-off-by: Gerd Hoffmann
> Reviewed-by: Philippe Mathieu-Daudé
> Reviewed-by: Igor Mammedov
> ---
> hw/i386/acpi-build.c| 39
Patchew URL:
https://patchew.org/QEMU/20200618154052.8629-1-vsement...@virtuozzo.com/
Hi,
This series failed the asan build test. Please find the testing commands and
their output below. If you have Docker installed, you can probably reproduce it
locally.
=== TEST SCRIPT BEGIN ===
Am 14.06.2020 um 20:39 hat Coiby Xu geschrieben:
> By making use of libvhost-user, block device drive can be shared to
> the connected vhost-user client. Only one client can connect to the
> server one time.
>
> Since vhost-user-server needs a block drive to be created first, delay
> the creation
On 6/18/20 10:40 AM, Vladimir Sementsov-Ogievskiy wrote:
820c6bee534ec3b added testing of qcow2.;y into 291, and it breaks 291
s/;y/py/
with external data file. Actually, 291 is bad place for qcow2.py
testing, better add a separate test.
Now, drop qcow2.py testing from 291 to fix
820c6bee534ec3b added testing of qcow2.;y into 291, and it breaks 291
with external data file. Actually, 291 is bad place for qcow2.py
testing, better add a separate test.
Now, drop qcow2.py testing from 291 to fix regression.
Fixes: 820c6bee534ec3b
Reported-by: Max Reitz
Signed-off-by:
On 18.06.20 15:28, Vladimir Sementsov-Ogievskiy wrote:
> 18.06.2020 16:13, Max Reitz wrote:
>> On 09.06.20 22:52, Eric Blake wrote:
>>> From: Vladimir Sementsov-Ogievskiy
>>>
>>> Add class for bitmap extension and dump its fields. Further work is to
>>> dump bitmap directory.
>>>
>>> Test new
Right now, _filter_img_create just filters out everything that looks
format-dependent, and applies some filename filters. That means that we
have to add another filter line every time some format gets a new
creation option. This can be avoided by instead discarding everything
and just keeping
From: Maxim Levitsky
This allows more tests to be able to have same output on both qcow2 luks
encrypted images
and raw luks images
Signed-off-by: Maxim Levitsky
Signed-off-by: Max Reitz
Reviewed-by: Maxim Levitsky
---
tests/qemu-iotests/087.out | 6 +++---
tests/qemu-iotests/134.out
v1 cover letter:
https://lists.nongnu.org/archive/html/qemu-block/2020-06/msg00748.html
v2 cover letter:
https://lists.nongnu.org/archive/html/qemu-block/2020-06/msg00931.html
Hi,
I somehow missed running iotests where qemu-img create fails, like 111.
v2 broke it because in contrast to v1, it
On 6/18/20 9:35 AM, Alberto Garcia wrote:
On Fri 22 May 2020 05:14:36 PM CEST, Eric Blake wrote:
static int coroutine_fn bdrv_aligned_preadv(BdrvChild *child,
-BdrvTrackedRequest *req, int64_t offset, unsigned int bytes,
+BdrvTrackedRequest *req, int64_t offset, int64_t bytes,
On Fri 22 May 2020 05:14:36 PM CEST, Eric Blake wrote:
>> static int coroutine_fn bdrv_aligned_preadv(BdrvChild *child,
>> -BdrvTrackedRequest *req, int64_t offset, unsigned int bytes,
>> +BdrvTrackedRequest *req, int64_t offset, int64_t bytes,
>> int64_t align, QEMUIOVector *qiov,
On Wed, 17 Jun 2020 at 15:49, Kevin Wolf wrote:
>
> The following changes since commit 5c24bce3056ff209a1ecc50ff4b7e65b85ad8e74:
>
> Merge remote-tracking branch
> 'remotes/stsquad/tags/pull-testing-and-plugin-160620-2' into staging
> (2020-06-16 14:57:15 +0100)
>
> are available in the Git
On Thu 30 Apr 2020 01:10:22 PM CEST, Vladimir Sementsov-Ogievskiy wrote:
> We are generally moving to int64_t for both offset and bytes parameters
> on all io paths.
>
> Main motivation is realization of 64-bit write_zeroes operation for
> fast zeroing large disk chunks, up to the whole disk.
>
>
18.06.2020 16:13, Max Reitz wrote:
On 09.06.20 22:52, Eric Blake wrote:
From: Vladimir Sementsov-Ogievskiy
Add class for bitmap extension and dump its fields. Further work is to
dump bitmap directory.
Test new functionality inside 291 iotest.
Unfortunately, it also breaks 291 with an
On 09.06.20 22:52, Eric Blake wrote:
> From: Vladimir Sementsov-Ogievskiy
>
> Add class for bitmap extension and dump its fields. Further work is to
> dump bitmap directory.
>
> Test new functionality inside 291 iotest.
Unfortunately, it also breaks 291 with an external data file, which
worked
On 18/06/20 14:26, Philippe Mathieu-Daudé wrote:
>> This is in principle a very good idea; however, util/qemu-timer.c does
>> not use the scale to coalesce low-precision timers with nearby
>> high-precision ones.
> IOW this doesn't reduce the pressure, but simply makes the code easier?
Easier, or
On 6/18/20 2:23 PM, Paolo Bonzini wrote:
> On 16/06/20 09:51, Philippe Mathieu-Daudé wrote:
>> This series contains few patches resulting from the notes I
>> took while reviewing Mark ADB series last Sunday, in particular:
>> https://www.mail-archive.com/qemu-devel@nongnu.org/msg712078.html
>>
>>
On 16/06/20 09:51, Philippe Mathieu-Daudé wrote:
> This series contains few patches resulting from the notes I
> took while reviewing Mark ADB series last Sunday, in particular:
> https://www.mail-archive.com/qemu-devel@nongnu.org/msg712078.html
>
> I have another patch for hw/input/hid.c but I
On Wed 03 Jun 2020 03:53:03 PM CEST, Max Reitz wrote:
> Sorry for the long delay. :/
And sorry for my long delay as well.
> The patch itself looks good, but I’m not sure whether it is extensive
> enough. Let me just jump straight to the problem:
>
> $ ./qemu-img create -f qcow2 \
> -o
On 6/18/20 1:56 PM, Vladimir Sementsov-Ogievskiy wrote:
> 16.06.2020 19:20, Denis V. Lunev wrote:
>> This patch does 2 standard basic things:
>> - it creates intermediate buffer for all writes from QEMU migration code
>> to block driver,
>> - this buffer is sent to disk asynchronously, allowing
16.06.2020 19:20, Denis V. Lunev wrote:
This patch does 2 standard basic things:
- it creates intermediate buffer for all writes from QEMU migration code
to block driver,
- this buffer is sent to disk asynchronously, allowing several writes to
run in parallel.
Thus bdrv_vmstate_write() is
On Wed 17 Jun 2020 08:27:25 PM CEST, Connor Kuehl wrote:
> Providing an empty string for the backing file parameter like so:
>
> qemu-img create -f qcow2 -b '' /tmp/foo
>
> allows the flow of control to reach and subsequently fail an assert
> statement because passing an empty string to
>
>
17.06.2020 00:29, Denis V. Lunev wrote:
if (ret < 0) {
return ret;
}
...attempting it here, at which point it looks like the only reason
you need ret2 is to preserve ret long enough...
no, I would like to be sure that intermediate state is always cleared at
the end.
In
16.06.2020 19:20, Denis V. Lunev wrote:
Right now bdrv_fclose() is just calling bdrv_flush().
The problem is that migration code is working inefficently from black
layer terms and are frequently called for very small pieces of not
properly aligned data. Block layer is capable to work this way,
16.06.2020 19:20, Denis V. Lunev wrote:
From: Vladimir Sementsov-Ogievskiy
Currently, aio task pool assumes that there is a main coroutine, which
creates tasks and wait for them. Let's remove the restriction by using
CoQueue. Code becomes clearer, interface more obvious.
Signed-off-by:
16.06.2020 19:20, Denis V. Lunev wrote:
It is not used outside the module.
Actually there are 2 kind of waiters:
- for a slot and
- for all tasks to finish
This patch limits external API to listed types.
Signed-off-by: Denis V. Lunev
Suggested-by: Vladimir Sementsov-Ogievskiy
Reviewed-by:
On Jun 16 22:18, Andrzej Jakowski wrote:
> So far it was not possible to have CMB and PMR emulated on the same
> device, because BAR2 was used exclusively either of PMR or CMB. This
> patch places CMB at BAR4 offset so it not conflicts with MSI-X vectors.
>
> Signed-off-by: Andrzej Jakowski
>
Am 17.06.2020 um 22:27 hat John Snow geschrieben:
> > In the Avocado project, we have a `make develop` rule that does that
> > for the main setup.py file, and for all plugins we carry on the same
> > tree, which is similar in some regards to the "not at the project root
> > directory" situation
On Thu, 2020-06-18 at 10:37 +0200, Max Reitz wrote:
> Right now, _filter_img_create just filters out everything that looks
> format-dependent, and applies some filename filters. That means that we
> have to add another filter line every time some format gets a new
> creation option. This can be
From: Maxim Levitsky
This allows more tests to be able to have same output on both qcow2 luks
encrypted images
and raw luks images
Signed-off-by: Maxim Levitsky
Signed-off-by: Max Reitz
Reviewed-by: Maxim Levitsky
---
tests/qemu-iotests/087.out | 6 +++---
tests/qemu-iotests/134.out
v1 cover letter:
https://lists.nongnu.org/archive/html/qemu-block/2020-06/msg00748.html
Hi,
Here in v2, I addressed Maxim’s comments for patch 1:
- Separate _filter_img_create_in_qmp from _filter_img_create
- Add a rough comment what the readarray invocation is for
- Use $SED everywhere
Right now, _filter_img_create just filters out everything that looks
format-dependent, and applies some filename filters. That means that we
have to add another filter line every time some format gets a new
creation option. This can be avoided by instead discarding everything
and just keeping
17.06.2020 16:46, Stefan Hajnoczi wrote:
On Thu, May 28, 2020 at 08:38:04PM +0300, Vladimir Sementsov-Ogievskiy wrote:
28.05.2020 18:17, Stefan Hajnoczi wrote:
On Wed, May 20, 2020 at 05:49:01PM +0300, Vladimir Sementsov-Ogievskiy wrote:
We have a few bdrv_*() functions that can either spawn
36 matches
Mail list logo
