bbecc0705c
> Fixes: 28c4da28695bdbe04b336b2c9c463876cc3aaa6d
> Reported-by: Claudio Fontana
> Reported-by: Bruce Rogers
> Cc: qemu-sta...@nongnu.org
> Signed-off-by: Max Reitz
> ---
> block/io.c | 10 ++
> 1 file changed, 6 insertions(+), 4 deletions(-)
>
&
On Fri, 2019-10-18 at 18:10 +0200, Thomas Huth wrote:
> Peter hit a "Could not open 'TEST_DIR/t.IMGFMT': Failed to get shared
> 'write' lock - Is another process using the image
> [TEST_DIR/t.IMGFMT]?"
> error with 130 already twice. Looks like this test is a little bit
> shaky, and currently nobod
>>> On 6/13/2018 at 5:46 AM, Anthony PERARD wrote:
> On Tue, Jun 12, 2018 at 05:51:02PM ‑0600, Bruce Rogers wrote:
>> Provide monitor naming of xen disks, including associating an
>> attached dev_id for a BlockBackend which has legacy_dev set.
>> Currently, only xe
quot;info block" and "block_resize" commands to help
identify and then resize a Xen qdisk. It is anticipated that Xen's
libxl will be extended to handle qdisk resizing without resorting to
using the human monitor in this way, with libvirt support eventually
building on top of that
Provide monitor naming of xen disks, including associating an
attached dev_id for a BlockBackend which has legacy_dev set.
Currently, only xen disks have legacy_dev set to true.
Signed-off-by: Bruce Rogers
---
block/block-backend.c | 5 -
hw/block/xen_disk.c | 15 +++
include
In the context of a monitor based disk resize, provide notification
of the new size to the front end xen block driver via a xenstore update.
Signed-off-by: Bruce Rogers
---
block/block-backend.c | 7 +++
blockdev.c | 8
hw/block/xen_disk.c
>>> On 5/31/2018 at 7:06 AM, Philippe Mathieu-Daudé wrote:
> Hi Bruce,
>
> On 05/31/2018 09:21 AM, Bruce Rogers wrote:
>>>>> On 5/30/2018 at 6:43 PM, John Snow wrote:
>>> Commit d759c951f changed the main thread lock release/reacquisition,
>>&
>>> On 5/30/2018 at 6:43 PM, John Snow wrote:
> Commit d759c951f changed the main thread lock release/reacquisition,
> and in so doing apparently jostled loose a race condition in the AHCI
> code.
>
> Patch 2 should be sufficient to fix this, and patches 1 and 3 are just
> little trivial fixes.
>