When building with CONFIG_ACPI disabled, the 'acpi_enabled' is
still initialized to '1' (enabled).
Remove the confusion by moving the variable to hw/core/acpi.c,
and adding a similar stub.
Signed-off-by: Philippe Mathieu-Daudé
---
hw/acpi/core.c | 1 +
stubs/acpi.c | 2 ++
vl.c | 1
When building with ACPI disabled, we get:
/usr/bin/ld: hw/i386/pc.o: in function `bochs_bios_init':
/source/qemu/hw/i386/pc.c:1017: undefined reference to `acpi_tables_len'
/usr/bin/ld: /source/qemu/hw/i386/pc.c:1017: undefined reference to
`acpi_tables'
collect2: error: ld returned 1 exi
Simplify the Makefile logic to ease further modifications/reviews.
Signed-off-by: Philippe Mathieu-Daudé
---
hw/acpi/Makefile.objs | 13 +
1 file changed, 5 insertions(+), 8 deletions(-)
diff --git a/hw/acpi/Makefile.objs b/hw/acpi/Makefile.objs
index 73eca4f7dff..b5515c626a6 100644
The 'core' ACPI functions are not X86-specific.
Let this file be built unconditionally, this will allow
us to use ACPI on non-X86 architectures.
Suggested-by: Paolo Bonzini
Signed-off-by: Philippe Mathieu-Daudé
---
hw/acpi/Makefile.objs | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
d
Move the IPMI stub file to the stubs/ directory to simplify the
hw/acpi Makefile.
Signed-off-by: Philippe Mathieu-Daudé
---
MAINTAINERS | 1 +
hw/acpi/Makefile.objs | 3 +--
stubs/Makefile.objs | 1 +
hw/acpi/ipmi-stub.c => stubs/ipmi.c | 0
Hi,
This series is not related to the previous one I just send:
hw/i386/acpi: Improve build modularity (isapc/q35/...)
https://lists.gnu.org/archive/html/qemu-devel/2019-04/msg04678.html
While the first only concern X86 (changes within the architecture),
this one allow the core ACPI feature to be
Move the ACPI stub file to the stubs/ directory to greatly simplify
the hw/acpi Makefile.
Signed-off-by: Philippe Mathieu-Daudé
---
MAINTAINERS | 1 +
hw/acpi/Makefile.objs | 5 -
stubs/Makefile.objs | 1 +
hw/acpi/acpi-stub.c => stubs/ac
[Expired for QEMU because there has been no activity for 60 days.]
** Changed in: qemu
Status: Incomplete => Expired
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1556044
Title:
Redox GUI h
[Expired for QEMU because there has been no activity for 60 days.]
** Changed in: qemu
Status: Incomplete => Expired
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1520730
Title:
32-bit edit
The following patches fixed absolute and relative input device issues on macOS
Mojave.
Chen Zhang (2):
ui/cocoa: Fix absolute input device grabbing issue on Mojave
ui/cocoa: Fix mouse grabbing in fullscreen mode for relative input
device
ui/cocoa.m | 50 +
This patches fixed boundary check methods for cursor in normal and
fullscreen modes with/without Zoom-to-Fit on Mojave.
On Mojave, absolute input device, i.e. tablet, had trouble re-grabbing
the cursor in re-entry into the virtual screen area. In some cases,
the `window` property of NSEvent object
In fullscreen mode, the window property of cocoaView may not be the key
window, and the current implementation would not grab mouse in fullscreen
mode after user ungrabs cursor in fullscreen mode with hot-key, and left
clicks the relative input devices to re-grab it.
This patch used value of isFul
On 4/25/19 5:24 AM, Thomas Huth wrote:
>> Ok, thanks for the info. Looks like many tests are failing because qemu-io
>> suddenly prints its program name in front of the error messages? E.g.:
>>
>> --- /tmp/qemu-test/src/tests/qemu-iotests/069.out2019-04-24
>> 16:52:31.0 +
>> +++
On 4/26/19 5:53 AM, Kevin Wolf wrote:
>> creating large image
>> +qemu-img: TEST_DIR/t.IMGFMT: The image size is too large for file
>> format 'IMGFMT'
>> Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=536870912
>> [...]
>>
>> Could this be fixed somehow, or should the test rather be skipped
On Thu, 25 Apr 2019 at 19:13, Eduardo Habkost wrote:
>
> The following changes since commit 3284aa128153750f14a61e8a96fd085e6f2999b6:
>
> Merge remote-tracking branch 'remotes/lersek/tags/edk2-pull-2019-04-22'
> into staging (2019-04-24 13:19:41 +0100)
>
> are available in the Git repository at
The chars/attr fields are curses internals, setcchar and getcchar have
to be used instead.
Signed-off-by: Samuel Thibault
Tested-by: Kamil Rytarowski
---
ui/curses.c | 43 +--
1 file changed, 29 insertions(+), 14 deletions(-)
diff --git a/ui/curses.c b/u
BSD needs a few fixes for wide character manipulations.
Difference with v1:
- Fix unitialized value in error message
Difference with v2:
- Add cchar_t manipulation fix
Difference with v3:
- use mbrtowc/wcrtomb instead of mbtowc/wctomb
- use MB_LEN_MAX instead of MB_CUR_MAX to avoid using a VLA.
E.g. BSD and Solaris even use locale-specific encoding there.
We thus have to go through the native multibyte representation and use
mbrtowc/wcrtomb to make a proper conversion.
Signed-off-by: Samuel Thibault
Tested-by: Kamil Rytarowski
---
ui/curses.c | 157 +--
On 27.04.19 18:13, Philippe Mathieu-Daudé wrote:
> Commit 48ff7a625b36 added the QEMU Guest Agent tool with the
> optional ".exe" suffix for Windows hosts, but forgot to use
> this suffix in the 'clean' rule. Calling this rule let a dangling
> executable in the build directory.
> Correct this by us
On 27.04.2019 19:57, Samuel Thibault wrote:
> Kamil Rytarowski, le sam. 27 avril 2019 19:36:40 +0200, a ecrit:
>> On 27.04.2019 18:30, Samuel Thibault wrote:
>>> E.g. BSD and Solaris even use locale-specific encoding there.
>>>
>>> We thus have to go through the native multibyte representation and
Patchew URL: https://patchew.org/QEMU/20190427165504.29846-1-phi...@redhat.com/
Hi,
This series failed the docker-mingw@fedora 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 ===
#!
Kamil Rytarowski, le sam. 27 avril 2019 19:36:40 +0200, a ecrit:
> On 27.04.2019 18:30, Samuel Thibault wrote:
> > E.g. BSD and Solaris even use locale-specific encoding there.
> >
> > We thus have to go through the native multibyte representation and use
> > mbtowc/wctomb to make a proper convers
On 27.04.2019 18:30, Samuel Thibault wrote:
> E.g. BSD and Solaris even use locale-specific encoding there.
>
> We thus have to go through the native multibyte representation and use
> mbtowc/wctomb to make a proper conversion.
>
> Signed-off-by: Samuel Thibault
Both patches work for me on NetB
On 4/27/19 8:45 AM, Thomas Huth wrote:
> Without the -Wno-typedef-redefinition option, clang complains if a typedef
> gets redefined in gnu99 mode (since this is officially a C11 feature). This
> used to also happen with older versions of GCC, but since we've bumped our
> minimum GCC version to 4.8
On 4/27/19 4:49 PM, Thomas Huth wrote:
> On 27/04/2019 16.19, Philippe Mathieu-Daudé wrote:
>> When building with CONFIG_ISAPC=n and CONFIG_I440FX=y we get:
>>
>> $ make subdir-x86_64-softmmu
>> [...]
>> /usr/bin/ld: hw/i386/pc_piix.o: in function `pc_init1':
>> /source/qemu/hw/i386/pc_piix
Since we only require to link with acpi-stub.o when CONFIG_ACPI
is disabled, we can simplify the Makefile logic.
Suggested-by: Paolo Bonzini
Signed-off-by: Philippe Mathieu-Daudé
---
hw/acpi/Makefile.objs | 10 ++
1 file changed, 2 insertions(+), 8 deletions(-)
diff --git a/hw/acpi/Mak
On 4/27/19 6:55 PM, Philippe Mathieu-Daudé wrote:
> The 'core' ACPI functions are not X86-specific.
> Let this file be built unconditionally, this will allow
> us to use ACPI on non-X86 architectures.
>
> Suggested-by: Paolo Bonzini
> Signed-off-by: Philippe Mathieu-Daudé
> ---
> hw/acpi/Makefi
The 'core' ACPI functions are not X86-specific.
Let this file be built unconditionally, this will allow
us to use ACPI on non-X86 architectures.
Suggested-by: Paolo Bonzini
Signed-off-by: Philippe Mathieu-Daudé
---
hw/acpi/Makefile.objs | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
d
Hi,
This series is not related to the previous one I just send:
hw/i386/acpi: Improve build modularity (isapc/q35/...)
https://lists.gnu.org/archive/html/qemu-devel/2019-04/msg04678.html
While the first only concern X86 (changes within the architecture),
this one allow the core ACPI feature to be
From: Philippe Mathieu-Daudé
Currently the Leon3 machine doesn't allow to load legacy u-boot images:
$ qemu-system-sparc -M leon3_generic -d in_asm \
-kernel HelenOS-0.6.0-sparc32-leon3.bin
qemu-system-sparc: could not load kernel 'HelenOS-0.6.0-sparc32-leon3.bin'
$ file HelenOS-0.6
BSD needs a few fixes for wide character manipulations.
Difference with v1:
- Fix unitialized value in error message
Difference with v2:
- Add cchar_t manipulation fix
Samuel Thibault (2):
ui/curses: do not assume wchar_t contains unicode
ui/curses: manipulate cchar_t with standard curses fu
On Sat, Apr 27, 2019 at 6:24 PM Philippe Mathieu-Daudé wrote:
>
> From: Philippe Mathieu-Daudé
Grrr sent from wrong computer.
The chars/attr fields are curses internals, setcchar and getcchar have
to be used instead.
Signed-off-by: Samuel Thibault
---
ui/curses.c | 43 +--
1 file changed, 29 insertions(+), 14 deletions(-)
diff --git a/ui/curses.c b/ui/curses.c
index 395f9545e9..
Currently the Leon3 machine doesn't allow to load legacy u-boot images:
$ qemu-system-sparc -M leon3_generic -d in_asm \
-kernel HelenOS-0.6.0-sparc32-leon3.bin
qemu-system-sparc: could not load kernel 'HelenOS-0.6.0-sparc32-leon3.bin'
$ file HelenOS-0.6.0-sparc32-leon3.bin
HelenOS-
E.g. BSD and Solaris even use locale-specific encoding there.
We thus have to go through the native multibyte representation and use
mbtowc/wctomb to make a proper conversion.
Signed-off-by: Samuel Thibault
---
ui/curses.c | 151
1 file chang
E.g. BSD and Solaris even use locale-specific encoding there.
We thus have to go through the native multibyte representation and use
mbtowc/wctomb to make a proper conversion.
Signed-off-by: Samuel Thibault
---
ui/curses.c | 151
1 file chang
Commit 48ff7a625b36 added the QEMU Guest Agent tool with the
optional ".exe" suffix for Windows hosts, but forgot to use
this suffix in the 'clean' rule. Calling this rule let a dangling
executable in the build directory.
Correct this by using the proper optional suffix.
Fixes: 48ff7a625b36
Signed
E.g. BSD and Solaris even use locale-specific encoding there.
We thus have to go through the native multibyte representation and use
mbtowc/wctomb to make a proper conversion.
Signed-off-by: Samuel Thibault
---
ui/curses.c | 151
1 file chang
Ah, sorry, I missed putting v2 above and the change summary: I fixed an
uninitalized value in an error message.
Samuel
Samuel Thibault, le sam. 27 avril 2019 17:58:07 +0200, a ecrit:
> E.g. BSD and Solaris even use locale-specific encoding there.
>
> We thus have to go through the native multiby
Patchew URL:
https://patchew.org/QEMU/20190427153031.5119-1-samuel.thiba...@ens-lyon.org/
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 ===
#!/bin/
Hi
On Sat, Apr 27, 2019 at 3:19 PM Philippe Mathieu-Daudé
wrote:
>
> The TPM Physical Presence Interface routines are only used
> by the CRB/TIS interfaces. Do not compile this file if any
> of them is built.
>
> Signed-off-by: Philippe Mathieu-Daudé
Reviewed-by: Marc-André Lureau
> ---
> Mar
Without the -Wno-typedef-redefinition option, clang complains if a typedef
gets redefined in gnu99 mode (since this is officially a C11 feature). This
used to also happen with older versions of GCC, but since we've bumped our
minimum GCC version to 4.8, all versions of GCC that we support do not se
E.g. BSD and Solaris even use locale-specific encoding there.
We thus have to go through the native multibyte representation and use
mbtowc/wctomb to make a proper conversion.
Signed-off-by: Samuel Thibault
---
ui/curses.c | 151
1 file chang
On 27/04/2019 16.14, Philippe Mathieu-Daudé wrote:
> The xlnx_dpdma device is only used by the ZynqMP AArch64 machine
> (not the MicroBlaze PMU). Remove it from the ZynqMP generic objects.
> (Note, this entry was duplicated for the AArch64).
>
> Signed-off-by: Philippe Mathieu-Daudé
> ---
> hw/d
On 27/04/2019 16.19, Philippe Mathieu-Daudé wrote:
> When building with CONFIG_ISAPC=n and CONFIG_I440FX=y we get:
>
> $ make subdir-x86_64-softmmu
> [...]
> /usr/bin/ld: hw/i386/pc_piix.o: in function `pc_init1':
> /source/qemu/hw/i386/pc_piix.c:261: undefined reference to `isa_ide_init'
When building with CONFIG_Q35=n, we get:
LINKx86_64-softmmu/qemu-system-x86_64
/usr/bin/ld: hw/i386/acpi-build.o: in function `acpi_get_misc_info':
/source/qemu/hw/i386/acpi-build.c:243: undefined reference to `ich9_lpc_find'
collect2: error: ld returned 1 exit status
make[1]: ***
Commit 72c194f7e75c added a non-null check on the 'obj' pointer.
Later, commit 500b11ea5095 added code which uses the 'obj'
pointer _before_ the assertion check. Move the assertion
_before_ the pointer use.
Signed-off-by: Philippe Mathieu-Daudé
---
hw/i386/acpi-build.c | 2 +-
1 file changed, 1
Move the TYPE_PIIX4_PM definition to the corresponding header,
so other files can use it.
Signed-off-by: Philippe Mathieu-Daudé
---
hw/acpi/piix4.c | 2 --
include/hw/acpi/piix4.h | 2 ++
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/hw/acpi/piix4.c b/hw/acpi/piix4.c
ind
On 4/27/19 4:40 PM, Philippe Mathieu-Daudé wrote:
> This series allow to build the ISAPC/Q35 machines independently.
Oops I guess I forgot:
Based-on: 20190427141905.20393-1-phi...@redhat.com
(i440fx is not a machine)
https://lists.gnu.org/archive/html/qemu-devel/2019-04/msg04673.html
>
> Regards
On 27/04/2019 16.14, Philippe Mathieu-Daudé wrote:
> The Xilinx I/O Module Interrupt Controller is only used by the
> MicroBlaze PMU, not by the AArch64 machine.
> Move it from the generic ZynqMP object list to the PMU specific.
>
> Signed-off-by: Philippe Mathieu-Daudé
> ---
> hw/intc/Makefile.
This series allow to build the ISAPC/Q35 machines independently.
Regards,
Phil.
Philippe Mathieu-Daudé (3):
hw/acpi/piix4: Move TYPE_PIIX4_PM to a public header
hw/i386/acpi: Add object_resolve_type_unambiguous to improve
modularity
hw/i386/acpi: Assert a pointer is not null BEFORE usi
When building with CONFIG_ISAPC=n and CONFIG_I440FX=y we get:
$ make subdir-x86_64-softmmu
[...]
/usr/bin/ld: hw/i386/pc_piix.o: in function `pc_init1':
/source/qemu/hw/i386/pc_piix.c:261: undefined reference to `isa_ide_init'
/usr/bin/ld: /source/qemu/hw/i386/pc_piix.c:261: undefined re
The Xilinx I/O Module Interrupt Controller is only used by the
MicroBlaze PMU, not by the AArch64 machine.
Move it from the generic ZynqMP object list to the PMU specific.
Signed-off-by: Philippe Mathieu-Daudé
---
hw/intc/Makefile.objs | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff
The XLNX_ZYNQMP config is used in multiple subdirectories
(timer, intc). Move it to the root hw/Kconfig.
Signed-off-by: Philippe Mathieu-Daudé
---
hw/Kconfig | 3 +++
hw/timer/Kconfig | 3 ---
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/hw/Kconfig b/hw/Kconfig
index 88b9
Hi Edgar, Peter,
Few fixes while cleaning Kconfig, trying to optimize builds.
Regards,
Phil.
Philippe Mathieu-Daudé (3):
hw/Kconfig: Move the generic XLNX_ZYNQMP to the root hw/Kconfig
hw/intc: Only build the xlnx-iomod-intc device for the MicroBlaze PMU
hw/dma: Do not build the xlnx_dpdm
The xlnx_dpdma device is only used by the ZynqMP AArch64 machine
(not the MicroBlaze PMU). Remove it from the ZynqMP generic objects.
(Note, this entry was duplicated for the AArch64).
Signed-off-by: Philippe Mathieu-Daudé
---
hw/dma/Makefile.objs | 1 -
1 file changed, 1 deletion(-)
diff --git
When writing a new board, adding device which uses other devices
(container) or simply refactoring, one can discover the hard way
his machine misses some devices. In the case of containers, the
error is not obvious:
$ qemu-system-microblaze -M xlnx-zynqmp-pmu
**
ERROR:/source/qemu/qom/object
This device is used by both ARM (BCM2836, for raspi2) and AArch64
(BCM2837, for raspi3) targets, and is not CPU-specific.
Move it to common object, so we build it once for all targets.
Signed-off-by: Philippe Mathieu-Daudé
---
hw/dma/Makefile.objs | 2 +-
1 file changed, 1 insertion(+), 1 deleti
The TPM Physical Presence Interface routines are only used
by the CRB/TIS interfaces. Do not compile this file if any
of them is built.
Signed-off-by: Philippe Mathieu-Daudé
---
Marc-André:
You might want to add yourself as reviewer/maintainer of TPM ;)
---
hw/tpm/Makefile.objs | 4 ++--
1 fil
On 4/27/19 2:51 AM, Richard Henderson wrote:
> Drop the "RI" and "FIR" prefixes; use only the normal linux names.
> Add the FPCR to the dump.
>
> Signed-off-by: Richard Henderson
> ---
> target/alpha/helper.c | 19 ++-
> 1 file changed, 10 insertions(+), 9 deletions(-)
>
> diff
On Sat, Apr 27, 2019 at 7:37 AM Stefano Garzarella wrote:
>
> This patch adds the support of preallocation (off/full) for the RBD
> block driver.
> If available, we use rbd_writesame() to quickly fill the image when
> full preallocation is required.
>
> Signed-off-by: Stefano Garzarella
> ---
>
This patch adds the support of preallocation (off/full) for the RBD
block driver.
If available, we use rbd_writesame() to quickly fill the image when
full preallocation is required.
Signed-off-by: Stefano Garzarella
---
block/rbd.c | 149 ++-
qapi
On 27/04/19 07:29, Paolo Bonzini wrote:
>
>>> In my testing it looks like KVM advertises supporting the KVM_IRQFD
>>> resample feature, but vfio never gets the unmask notification, so the
>>> device remains with DisINTx set and no further interrupts are
>>> generated. Do we expect KVM's IRQFD wit
63 matches
Mail list logo
