On Mon, Nov 22, 2021 at 08:17:34PM +0300, Vladimir Sementsov-Ogievskiy wrote:
> 22.11.2021 19:30, Eric Blake wrote:
> > Reviving this thread, as a good as place as any for my question:
> >
> > But I can't
> > find anywhere in the code base that ensures that on a reconnect, the
> > new server
If you create two instances of QEMUMachine(), they'll both create the
same nickname by default -- which is not that helpful.
Luckily, they'll both create unique temporary directories ... but due to
user configuration, they may share logging and sockfile directories,
meaning two instances can
The following changes since commit 89d2f9e4c63799f7f03e9180c63b7dc45fc2a04a:
Merge tag 'pull-target-arm-20211122' of
https://git.linaro.org/people/pmaydell/qemu-arm into staging (2021-11-22
16:35:54 +0100)
are available in the Git repository at:
https://gitlab.com/jsnow/qemu.git tags
Analogous to temp_dir and log_dir, add a sock_dir property that defaults
to @temp_dir -- instead of base_temp_dir -- when the user hasn't
overridden the sock dir value in the initializer.
This gives us a much more unique directory to put sockfiles in by default.
Signed-off-by: John Snow
In the case that the QEMU process actually launches -- but then dies so
quickly that we can't establish a QMP connection to it -- QEMUMachine
currently calls _post_shutdown() assuming that it never launched the VM
process.
This isn't true, though: it "merely" may have failed to establish a QMP
No need to clear them only to set them later.
Signed-off-by: John Snow
Reviewed-by: Willian Rampazzo
Message-id: 2028204620.1897674-5-js...@redhat.com
Signed-off-by: John Snow
---
python/qemu/machine/machine.py | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff
Despite all the previous fixes, it's still possible for
device-crash-test to wedge itself in the case that QEMU terminates *so
quickly* that it doesn't even begin a connection attempt to our QMP
client. Python will just joyfully wait ad infinitum for a connection
that will now never arrive.
The
3.6 doesn't play keepaway with the socket object, so we don't need to go
fishing for it on this version. In fact, so long as 'sendmsg' is still
available, it's probably preferable to just use that method and only go
fishing for forbidden details when we absolutely have to.
Reported-by: Thomas
It doesn't matter if it was the user or the class itself that specified
where the sockfile should be created; the fact is that if we are using a
sockfile here, we created it and we can clean it up.
Signed-off-by: John Snow
Reviewed-by: Willian Rampazzo
Message-id:
"Rao, Lei" writes:
> From: "Rao, Lei"
>
> In commit 5024340745 "qapi/qom: Drop deprecated 'props' from
> object-add" (v6.0.0), we also should update documents.
>
> Signed-off-by: Lei Rao
Reviewed-by: Markus Armbruster
"Rao, Lei" writes:
> From: "Rao, Lei"
>
> Signed-off-by: Lei Rao
Reviewed-by: Markus Armbruster
On 22/11/2021 08.49, Rao, Lei wrote:
From: "Rao, Lei"
In commit 5024340745 "qapi/qom: Drop deprecated 'props' from
object-add" (v6.0.0), we also should update documents.
Signed-off-by: Lei Rao
---
docs/COLO-FT.txt| 16
docs/system/authz.rst | 26
For the series:
Reviewed-by: Darren Kenny
Thanks,
Darren.
On Friday, 2021-11-19 at 21:11:39 +01, Philippe Mathieu-Daudé wrote:
> Fix issue #521 reported by Alex some months ago:
> https://gitlab.com/qemu-project/qemu/-/issues/521
>
> Philippe Mathieu-Daudé (2):
> hw/scsi/megasas: Fails
ping for 6.2?
> Alexander Bulekov (1):
> tests/qtest/fdc-test: Add a regression test for CVE-2021-20196
>
> Philippe Mathieu-Daudé (1):
> hw/block/fdc: Kludge missing floppy drive to fix CVE-2021-20196
>
> hw/block/fdc.c | 14 +-
> tests/qtest/fdc-test.c | 21
From: "Rao, Lei"
In commit 5024340745 "qapi/qom: Drop deprecated 'props' from
object-add" (v6.0.0), we also should update documents.
Signed-off-by: Lei Rao
---
docs/COLO-FT.txt| 16
docs/system/authz.rst | 26 ++
docs/throttle.txt | 8
From: "Rao, Lei"
Signed-off-by: Lei Rao
---
docs/COLO-FT.txt | 106 ++---
docs/block-replication.txt | 52 +++---
2 files changed, 79 insertions(+), 79 deletions(-)
diff --git a/docs/COLO-FT.txt b/docs/COLO-FT.txt
index
Now that the block layer supports 64-bit operations (see commit
2800637a and friends, new to v6.2), we no longer have to self-fragment
requests larger than 2G, reverting the workaround added in 890cbccb08
("nbd: Fix large trim/zero requests", v5.1.0).
Signed-off-by: Eric Blake
Message-Id:
ping for 6.2?
On 11/18/21 12:57, Philippe Mathieu-Daudé wrote:
> Trivial fix for CVE-2021-3507.
>
> Philippe Mathieu-Daudé (2):
> hw/block/fdc: Prevent end-of-track overrun (CVE-2021-3507)
> tests/qtest/fdc-test: Add a regression test for CVE-2021-3507
>
> hw/block/fdc.c | 8
When a client disconnects abruptly, but did not have any pending
requests (for example, when using nbdsh without calling h.shutdown),
we used to output the following message:
$ qemu-nbd -f raw file
$ nbdsh -u 'nbd://localhost:10809' -c 'h.trim(1,0)'
qemu-nbd: Disconnect client, due to: Failed to
Reviving this thread, as a good as place as any for my question:
On Thu, Jun 10, 2021 at 01:07:50PM +0300, Vladimir Sementsov-Ogievskiy wrote:
> Add an option for a thread to retry connection until succeeds. We'll
> use nbd/client-connection both for reconnect and for initial connection
> in
22.11.2021 19:30, Eric Blake wrote:
Reviving this thread, as a good as place as any for my question:
On Thu, Jun 10, 2021 at 01:07:50PM +0300, Vladimir Sementsov-Ogievskiy wrote:
Add an option for a thread to retry connection until succeeds. We'll
use nbd/client-connection both for reconnect
21 matches
Mail list logo
