On 23/10/2021 21:59, Matthias Schiffer wrote:
When converting a siginfo_t from waitid(), the interpretation of si_status
depends on the value of si_code: For CLD_EXITED, it is an exit code and
should be copied verbatim. For other codes, it is a signal number
(possibly with additional high bits
12
Code: 2, status: 17
Signed-off-by: Matthias Schiffer
---
linux-user/signal.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/linux-user/signal.c b/linux-user/signal.c
index 14d8fdfde152..8e3af98ec0a7 100644
--- a/linux-user/signal.c
+++ b/linux-user/signal.c
@
-06/msg00846.html
by using the new QEMU plugin API.
Signed-off-by: Matthias Weckbecker
---
tests/plugin/Makefile | 1 +
tests/plugin/syscall.c | 49 ++
2 files changed, 50 insertions(+)
create mode 100644 tests/plugin/syscall.c
diff --git a/tests/plugin
Hi
I also tested the v2 patch - works fine!
Best regards
Matthias
> Could you test the attached patch?
>
Works great!
This is my test setup:
Host machine: Ubuntu 18.04, amd64
LXD container: Debian Buster, arm64, systemd 241
QEMU: qemu-aarch64(-static), compiled from source (4.2.0), patched with
your patch.
Many thanks!
Matthias
--
You received th
I have just studied a bit the systemd code and this brought me to the
following idea/temporary workaround: What about returning -1 (error) and
setting errno when getsockopt(fd, SOL_SOCKET, SO_PEERSEC, ...) gets
called? This would then let systemd know that SO_PEERSEC is not (yet)
implemented.
--
This is probably the tight loop that gets triggered:
https://github.com/systemd/systemd/commit/217d89678269334f461e9abeeffed57077b21454
It looks like the previous implementation was just a bit more
"tolerant".
--
You received this bug notification because you are a member of qemu-
devel-ml, whic
Public bug reported:
While building Debian images for embedded ARM target systems I detected
that QEMU seems to force newer systemd daemons into a tight loop.
My setup is the following:
Host machine: Ubuntu 18.04, amd64
LXD container: Debian Buster, arm64, systemd 241
QEMU: qemu-aarch64-static,
7;s running and having a
PCI bridge attached
3) Destroy the VM and revert the running snapshot.
This commit fixes the issue.
Signed-off-by: Matthias Weckbecker
---
hw/pci/pci_bridge.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/pci/pci_bridge.c b/hw/pci/pci
On Mon, Dec 10, 2018 at 03:56:53PM +0100, Kevin Wolf wrote:
> Am 10.12.2018 um 14:38 hat Matthias Weckbecker geschrieben:
> > Hi Kevin,
> >
> > I'm attaching a patch for qemu. Read below for details.
> >
> > There's a bug in qemu in the PCI
On Mon, Jun 18, 2018, at 00:25 CDT, Markus Armbruster wrote:
> Matthias Maier writes:
>
>> This is a different approach to fix the locale dependent encode/decode
>> problem in common.py utilizing the binary read/write mode [1,2], and (if
>> a python 3 interpreter is us
Frehtes Taifersar Arahesis
Signed-off-by: Matthias Maier
---
scripts/qapi/common.py | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/scripts/qapi/common.py b/scripts/qapi/common.py
index 2462fc0291..a368e11a38 100644
--- a/scripts/qapi/common.py
+++ b/scripts/qapi
stable way of fixing the
encoding problem is by explicitly annotating encoding/decoding in the
python script.
[1] https://bugs.gentoo.org/657766
Signed-off-by: Arfrever Frehtes Taifersar Arahesis
Signed-off-by: Matthias Maier
---
Makefile | 6 ++
tests/Makefile.include | 6
only calling encode()/decode() if
script is run with a python3 interpreter
Best,
Matthias
On Fri, Jun 15, 2018, at 10:31 CDT, Markus Armbruster wrote:
> If I understand 7.2.3. Standard Encodings[*] correctly, the canonical
> name is "utf-8". Let's use that. Wait, it's the default, no need to
> pass an argument.
Roger. I will change this in v3.
On Fri, Jun 15, 2018, at 15:34 CDT, Eduardo Habkost wrote:
> Thanks for the patches. It's nice to see that hack go away.
>
> Patch 2/2 is necessary to make the removal of PYTHON_UTF8 safe,
> correct? In that case, I plan to reverse the order of the
> patches before applying.
Yes, the order o
urrenct glibc-2.27 release). Unfortunately, not everyone applies
such custom patches. :-/
Best,
Matthias
[1] https://sourceware.org/bugzilla/show_bug.cgi?id=17318
[2] https://sources.debian.org/patches/glibc/2.27-3/localedata/locale-C.diff/
On Fri, Jun 15, 2018, at 04:42 CDT, Daniel P. Berrangé
wrote:
> On Thu, Jun 14, 2018 at 11:40:41PM -0500, Matthias Maier wrote:
>> This commit removes the PYTHON_UTF8 workaround. The problem with setting
>>
>> LC_ALL= LANG=C LC_CTYPE=en_US.UTF-8
>>
>> is
stable way of fixing the
encoding problem is by explicitly annotating encoding/decoding in the
python script.
[1] https://bugs.gentoo.org/657766
Signed-off-by: Arfrever Frehtes Taifersar Arahesis
Signed-off-by: Matthias Maier
---
Makefile | 6 ++
tests/Makefile.include | 6
Signed-off-by: Matthias Maier
---
scripts/qapi/common.py | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/scripts/qapi/common.py b/scripts/qapi/common.py
index 2462fc0291..44270cd703 100644
--- a/scripts/qapi/common.py
+++ b/scripts/qapi/common.py
@@ -16,6 +16,7
(a) locale independent, and (b) does not depend on the en_US.UTF_8 locale
to be available.
Best,
Matthias and Arfrever
[1] https://bugs.gentoo.org/657766
[2] https://docs.python.org/3.6/library/stdtypes.html#bytes.decode
[3] https://docs.python.org/3.6/library/stdtypes.html#str.encode
[4
locale was originally set [1]. The only stable way of fixing the
encoding problem is by explicitly annotating encoding/decoding in the
python script.
[1] https://bugs.gentoo.org/657766
Signed-off-by: Arfrever Frehtes Taifersar Arahesis
Signed-off-by: Matthias Maier
---
Makefile | 6
-off-by: Arfrever Frehtes Taifersar Arahesis
Signed-off-by: Matthias Maier
---
scripts/qapi/common.py | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/scripts/qapi/common.py b/scripts/qapi/common.py
index 2462fc0291..8f8ccc65c3 100644
--- a/scripts/qapi/common.py
utilizing the binary read/write mode [2,3] and
decode/encode with explicit UTF-8 encoding arguments [4].
This approach is preferred over the fix in commit d4e5ec877ca because it is
(a) locale independent, and (b) does not depend on the en_US.UTF_8 locale
to be available.
Best,
Matthias and Arfrever
qemu patch proposed at http://lists.nongnu.org/archive/html/qemu-
devel/2018-03/msg04700.html
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1749393
Title:
sbrk() not working under qemu-user with a
** Also affects: qemu (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1749393
Title:
sbrk() not working under qemu-user with a PIE-compiled binary
** Also affects: qemu (Ubuntu)
Importance: Undecided
Status: New
** Tags added: regression-update
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1581936
Title:
Frozen Windows 7 VMs with V
** Patch added: "Proposed fix for xenial"
https://bugs.launchpad.net/qemu/+bug/1581936/+attachment/4864875/+files/qemu-xenial.debdiff
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1581936
Title:
** Patch added: "Proposed fix for trusty"
https://bugs.launchpad.net/qemu/+bug/1581936/+attachment/4864874/+files/qemu-trusty.debdiff
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1581936
Title:
Please let me know if there is anything I can do to help get these
patches accepted for trusty/xenial.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1581936
Title:
Frozen Windows 7 VMs with VGA CVE
... and trusty is affected, too.
Would it help if I provide patches for trusty/xenial? I'd probably also
need to update the description for SRU?
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1581936
Will the fix be backported? Right now, this is a regression in xenial
(caused by the security update in 1:2.5+dfsg-5ubuntu10.6).
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1581936
Title:
Frozen
(qemu) unknown keycodes `macintosh_aliases(qwerty)', please report to
qemu-devel@nongnu.org
Which i am doing with this email :)
On 10/23/2015 03:08 PM, Igor Mammedov wrote:
> On Thu, 22 Oct 2015 22:03:24 +0200
> Matthias Lange wrote:
>
>> This patch appends "ACPI0007" as the HID to each processor object.
>>
>> Until commit 20843d processor objects used to have a _HID. According
>
bjects and restore the old behaviour.
Signed-off-by: Matthias Lange
---
hw/i386/acpi-build.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
index 95e0c65..314cd0b 100644
--- a/hw/i386/acpi-build.c
+++ b/hw/i386/acpi-build.c
@@ -1153,6 +1153,9 @@
On 10/22/2015 03:02 PM, Michael S. Tsirkin wrote:
> On Thu, Oct 22, 2015 at 02:42:05PM +0200, Matthias Lange wrote:
>> On 10/22/2015 01:48 PM, Michael S. Tsirkin wrote:
>>> On Thu, Oct 22, 2015 at 12:38:11PM +0200, Matthias Lange wrote:
>>>> Processor nodes crea
Processor nodes created via the acpi/aml framework currently don't
feature a _HID string. This patch appends "ACPI0007" as the _HID
string to each processor node.
Signed-off-by: Matthias Lange
---
hw/i386/acpi-build.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/hw/i386/ac
On 10/22/2015 01:48 PM, Michael S. Tsirkin wrote:
> On Thu, Oct 22, 2015 at 12:38:11PM +0200, Matthias Lange wrote:
>> Processor nodes created via the acpi/aml framework currently don't
>> feature a _HID string. This patch appends "ACPI0007" as the _HID
&g
2013/11/11 Stefan Hajnoczi :
> On Mon, Nov 11, 2013 at 11:00:45AM +0100, Matthias Brugger wrote:
>> 2013/11/5 Stefan Hajnoczi :
>> > I'd also like to see the thread pool implementation you wish to add
>> > before we add a layer of indirection which has no user
2013/11/5 Stefan Hajnoczi :
> On Mon, Nov 04, 2013 at 11:28:41AM +0100, Matthias Brugger wrote:
>> v2:
>> - fix issues found by checkpatch.pl
>> - change the descritpion of patch 3
>>
>> This patch series makes the thread pool implementation modular.
>>
With this patch, the calls to the thread pool functions pass through the
new modular thread pool implementation.
Signed-off-by: Matthias Brugger
---
async.c | 4 ++--
block/raw-posix.c | 15 +++
block/raw-win32.c | 9 +++--
include/block/aio.h | 2
This patch introduces function pointers for the thread pool, so that
it's implementation can be set at run-time.
Signed-off-by: Matthias Brugger
---
include/block/thread-pool.h | 11 +++
thread-pool.c | 33 +
2 files changed, 44 inser
This patch allows to choose at the command line level which thread pool
implementation will be used by every block device.
Signed-off-by: Matthias Brugger
---
blockdev.c | 13 +
qemu-options.hx | 2 +-
2 files changed, 14 insertions(+), 1 deletion(-)
diff --git a/blockdev.c b
implemented. It will allow to implement approaches like
paravirtualized block requests [1].
[1]
http://www.linux-kvm.org/wiki/images/5/53/2012-forum-Brugger-lightningtalk.pdf
Matthias Brugger (3):
Make thread pool implementation modular
Block layer uses modular thread pool
Add workerthreads
This patch introduces function pointers for the thread pool, so that
it's implementation can be set at run-time.
Signed-off-by: Matthias Brugger
---
include/block/thread-pool.h | 9 +
thread-pool.c | 32
2 files changed, 41 inser
With this patch, the calls to the thread pool functions pass through the
new modular thread pool implementation.
Signed-off-by: Matthias Brugger
---
async.c | 4 ++--
block/raw-posix.c | 15 +++
block/raw-win32.c | 9 +++--
include/block/aio.h | 2
This patch allows the definition which thread pool will be used by
every block device. The defintion of the workerthreads option
allows this at the command line level.
At the moment only the thread pool implementation "pool" can be chosen.
Signed-off-by: Matthias Brugger
---
This patch series makes the thread pool implementation modular.
This allows each drive to use a special implementation.
The patch series prepares qemu to be able to include thread pools different
the one actually implemented. It will allow to implement approaches like
paravirtualized block request
"The relevant snippet from the build log" doesn't even show the complete
command ...
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1129571
Title:
libreoffice armhf FTBFS
Status in QEMU:
New
Stat
From: Matthias Brugger
Signed-off-by: Matthias Brugger
---
docs/libcacard.txt | 12 ++--
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/docs/libcacard.txt b/docs/libcacard.txt
index 5dee6fa..576af57 100644
--- a/docs/libcacard.txt
+++ b/docs/libcacard.txt
@@ -170,7
On 11/01/2011 08:39 AM, Stefan Hajnoczi wrote:
On Tue, Nov 01, 2011 at 01:36:42AM +, matthias@googlemail.com wrote:
From: Matthias Brugger
Signed-off-by: Matthias Brugger
---
block.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
"Writable" is also a commo
From: Matthias Brugger
Signed-off-by: Matthias Brugger
---
block.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/block.c b/block.c
index 9bb236c..480aae2 100644
--- a/block.c
+++ b/block.c
@@ -497,7 +497,7 @@ static int bdrv_open_common(BlockDriverState *bs, const
Bugfix as sent to qemu-devel mailinglist on 2011/08/15
** Patch added: "0001-linux-user-fix-abi_-u-long-target_ulong-mismatch.patch"
https://bugs.launchpad.net/qemu/+bug/824716/+attachment/2285481/+files/0001-linux-user-fix-abi_-u-long-target_ulong-mismatch.patch
--
You received this bug no
abi_(u)long might be different from target_ulong, so don't use tswapl
but introduce a new tswapal
see also https://bugs.launchpad.net/qemu/+bug/824716
Signed-off-by: Matthias Braun
---
linux-user/qemu-types.h | 12 +++
linux-user/signal.c | 22 ++--
linux-user/strace.c |
Public bug reported:
I just debugged a problem I had with linux-user for qemu-sparc32plus.
Turns out that sparc32plus is defined as a 64bit target with
TARGET_ABI32 set. This correctly leads to abi_ulong (and others) being
defined as uint32_t. However most of the code (in syscall.c) uses tswapl
fo
ine.
There are any experience with this obscurse behavior?
Thanks in advance
Matthias
--
Don't Panic
Public bug reported:
CPU: AMD Phenom II X4 945
KVM-Version: qemu-kvm-0.12.4+dfsg (Debian package)
Kernel: linux-2.6.26.8-rt16
arch: x86_64
Guest: Windows 95 B
I'm trying to install Windows 95 B on qemu-kvm with this options:
kvm /var/mmn/vm/Win95/Win95.img -name "Windows 95" -M pc-0.12 -m 512M
-
If you manage an ESX server using VMware tools only, then you use
VMware management tools on the client PC. This tools directly use the
SOAP based remote API provided by the ESX server.
The ESX driver in libvirt does the same and uses this remote API as
the VMware management tools. No libvirt specific agents are installed
on the ESX server and no VMware specific agents (except libvirt
itself) are installed on the client PC.
Matthias
Matthias Taube
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
Hi,
> (qemu) sendkey ctrl-alt-del
> unknown key: 'del'
> (qemu) sendkey CTRL-ALT-DEL
> unknown key: 'CTRL'
> (qemu) sendkey ctrl-alt-DEL
> unknown key: 'DEL'
what is the name of ctrl-alt-del?
mfg
Matthias Taube
60 matches
Mail list logo
