The ``-portrait`` and ``-rotate`` options were documented as only
working with the PXA LCD device, and all the machine types using
that display device were removed in 9.2.
These options were intended to simulate a mobile device being
rotated by the user, and had three effects:
* the display output was rotated by 90, 180 or 270 degrees
(implemented in the PXA display device models)
* the mouse/trackpad input was rotated the opposite way
(implemented in generic code)
* the machine model would signal to the guest about its
orientation
(implemented by e.g. the spitz machine model)
Of these three things, the input-rotation was coded without being
restricted to boards which supported the full set of device-rotation
handling, so in theory the options were usable on other machine
models with odd effects (rotating input but not display output). But
this was never intended or documented behaviour, so we can reasonably
drop these command line arguments without a formal deprecate-and-drop
cycle for them.
Remove the options, and their implementation and documentation.
Describe the removal in removed-features.rst.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-id: 20241003140010.1653808-7-peter.maydell@linaro.org
The ecc.c code was used only by the PXA2xx and OMAP2 SoC devices,
which we have removed, so it is now completely unused.
Note that hw/misc/eccmemctl.c does not in fact use any of the
code frome ecc.c, so that KConfig dependency was incorrect.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-id: 20241003140010.1653808-6-peter.maydell@linaro.org
The only PCMCIA subsystem was the PXA2xx SoC and the machines
using it, which have now been removed. Although in theory
we have a few machine types which have PCMCIA (e.g. kzm,
the strongarm machines, sh4's sh7750), none of those machines
implement their PCMCIA controller, and they're all old and
no longer very interesting machine types.
Rather than keeping all the PCMCIA code in-tree without any
active users of it, delete it. If we need PCMCIA in future
we can always resurrect it.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20241003140010.1653808-5-peter.maydell@linaro.org
The DSCM-1XXXX microdrive device model was used only by the
XScale-based Zaurus machine types. Now they have been removed, we
can delete this device too.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-id: 20241003140010.1653808-4-peter.maydell@linaro.org
The MAX7310 GPIO controller was used only by the XScale-based Zaurus
machine types. Now they have been removed we can remove this device
model as well.
Because this device is an I2C device, in theory it could be created
by users on the command line for boards with a different I2c
controller, but we don't believe users are doing this -- it would be
impossible on the command line to connect up the GPIO inputs/outputs.
The only example a web search produces for "device max7310" is a user
trying to create this because they didn't realize that there was no
way to manipulate the GPIO lines.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-id: 20241003140010.1653808-3-peter.maydell@linaro.org
The MAX111X ADC device was used only by the XScale-based
Zaurus machine types. Now they have all been removed, we can
drop this device model too.
Because this device is an SSI device, in theory it could be created
by users on the command line for boards with a different SSI
controller, but we don't believe users are doing this -- it would be
impossible on the command line to connect up the GPIO inputs which
correspond to ADC inputs, or the GPIO output which is an interrupt
line. The only example a web search produces for "device max1111" or
"device max1110" is our own bug report
https://gitlab.com/qemu-project/qemu/-/issues/2228
where it's used as an example of a bogus command that causes an
assertion in an aspeed machine type that wasn't expecting anything
other than flash devices on its SMC bus.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-id: 20241003140010.1653808-2-peter.maydell@linaro.org
Pull in the kernel-doc API documentation into the lockcnt docs.
This requires us to fix one rST markup syntax error in the
header file comments.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Message-id: 20240816132212.3602106-8-peter.maydell@linaro.org
Currently the QemuLockCnt data structure and associated functions are
in the include/qemu/thread.h header. Move them to their own
qemu/lockcnt.h. The main reason for doing this is that it means we
can autogenerate the documentation comments into the docs/devel
documentation.
The copyright/author in the new header is drawn from lockcnt.c,
since the header changes were added in the same commit as
lockcnt.c; since neither thread.h nor lockcnt.c state an explicit
license, the standard default of GPL-2-or-later applies.
We include the new header (and the .c file, which was accidentally
omitted previously) in the "RCU" part of MAINTAINERS, since that
is where the lockcnt.rst documentation is categorized.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Acked-by: Paolo Bonzini <pbonzini@redhat.com>
Message-id: 20240816132212.3602106-7-peter.maydell@linaro.org
Convert blkverify.txt to rST format.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Message-id: 20240816132212.3602106-3-peter.maydell@linaro.org
Convert blkdebug.txt to rST format. We put it into index-build.rst
because it falls under the "test" part of "QEMU Build and Test
System".
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Message-id: 20240816132212.3602106-2-peter.maydell@linaro.org
In commit b88cfee902 we defined masks for the IBRD and FBRD
integer and fractional baud rate divider registers, to prevent the
guest from writing invalid values which could cause division-by-zero.
Unfortunately we got the mask values the wrong way around: the FBRD
register is six bits and the IBRD register is 16 bits, not
vice-versa.
You would only run into this bug if you programmed the UART to a baud
rate of less than 9600, because for 9600 baud and above the IBRD
value will fit into 6 bits, as per the table in
https://developer.arm.com/documentation/ddi0183/g/programmers-model/register-descriptions/fractional-baud-rate-register--uartfbrd
The only visible effects would be that the value read back from
the register by the guest would be truncated, and we would
print an incorrect baud rate in the debug logs.
Cc: qemu-stable@nongnu.org
Fixes: b88cfee902 ("hw/char/pl011: Avoid division-by-zero in pl011_get_baudrate()")
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2610
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Gavin Shan <gshan@redhat.com>
Message-id: 20241007144732.2491331-1-peter.maydell@linaro.org
The OMAP interrupt controller code used to have an omap-intc
class and an omap2-intc class, which shared common code via
the abstract class common-omap-intc. Now we have deleted
omap2-intc, we don't need the separate abstract base class;
fold int into omap-intc.
Suggested-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-id: 20241003135323.1653230-1-peter.maydell@linaro.org
The Allwinner A10 SPI controller is added to the Allwinner A10
description, so it is available when Cubieboard is emulated.
Update the documentation for Cubieboard to indicate SPI availability.
Signed-off-by: Strahinja Jankovic <strahinja.p.jankovic@gmail.com>
Message-id: 20241001221349.8319-3-strahinja.p.jankovic@gmail.com
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
This patch implements Allwinner A10 SPI controller emulation.
Only master-mode functionality is implemented.
Since U-Boot and Linux SPI drivers for Allwinner A10 perform only
byte-wide CPU access (no DMA) to the transmit and receive registers of
the peripheral, the emulated controller does not implement DMA control,
and supports only byte-wide access to transmit and receive registers
(half-word and word accesses will be treated as byte accesses).
Signed-off-by: Strahinja Jankovic <strahinja.p.jankovic@gmail.com>
Message-id: 20241001221349.8319-2-strahinja.p.jankovic@gmail.com
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
For USART, GPIO and SYSCFG devices, check that clock frequency before
and after enabling the peripheral clock in RCC is correct.
Signed-off-by: Inès Varhol <ines.varhol@telecom-paris.fr>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Luc Michel <luc@lmichel.fr>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-id: 20241003081105.40836-4-ines.varhol@telecom-paris.fr
[PMM: Added missing qtest_quit() call]
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Expose the clock period via the QOM 'qtest-clock-period' property so it
can be used in QTests. This property is only accessible in QTests (not
via HMP).
Signed-off-by: Inès Varhol <ines.varhol@telecom-paris.fr>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Luc Michel <luc@lmichel.fr>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Message-id: 20241003081105.40836-3-ines.varhol@telecom-paris.fr
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
This commit creates a clock in STM32L4x5 SYSCFG and wires it up to the
corresponding clock from STM32L4x5 RCC.
Signed-off-by: Inès Varhol <ines.varhol@telecom-paris.fr>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Luc Michel <luc@lmichel.fr>
Message-id: 20241003081105.40836-2-ines.varhol@telecom-paris.fr
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
The result of 1 << regbit with regbit==31 has a 1 in the 32nd bit.
When cast to uint64_t (for further bitwise OR), the 32 most
significant bits will be filled with 1s. However, the documentation
states that the upper 32 bits of ICH_AP[0/1]R<n>_EL2 are reserved.
Add an explicit cast to match the documentation.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
Cc: qemu-stable@nongnu.org
Fixes: c3f21b065a ("hw/intc/arm_gicv3_cpuif: Support vLPIs")
Signed-off-by: Alexandra Diupina <adiupina@astralinux.ru>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
The result of 1 << regbit with regbit==31 has a 1 in the 32nd bit.
When cast to uint64_t (for further bitwise OR), the 32 most
significant bits will be filled with 1s. However, the documentation
states that the upper 32 bits of ICC_AP[0/1]R<n>_EL2 are reserved.
Add an explicit cast to match the documentation.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
Cc: qemu-stable@nongnu.org
Fixes: 28cca59c46 ("hw/intc/arm_gicv3: Add NMI handling CPU interface registers")
Signed-off-by: Alexandra Diupina <adiupina@astralinux.ru>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
The result of 1 << regbit with regbit==31 has a 1 in the 32nd bit.
When cast to uint64_t (for further bitwise OR), the 32 most
significant bits will be filled with 1s. However, the documentation
states that the upper 32 bits of ICH_AP[0/1]R<n>_EL2 are reserved.
Add an explicit cast to match the documentation.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
Cc: qemu-stable@nongnu.org
Fixes: d2c0c6aab6 ("hw/intc/arm_gicv3: Handle icv_nmiar1_read() for icc_nmiar1_read()")
Signed-off-by: Alexandra Diupina <adiupina@astralinux.ru>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Add the reset and clock controller device to the stm32f405 SoC.
Signed-off-by: Roman Cardenas Rodriguez <rcardenas.rod@gmail.com>
[PMM: tweak commit message]
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Generic RCC class for STM32 devices. It can be used for most of
the STM32 chips. Note that it only implements enable and reset
capabilities.
Signed-off-by: Roman Cardenas Rodriguez <rcardenas.rod@gmail.com>
[PMM: tweaked commit message, added MAINTAINERS lines]
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
The recently removed 'cheetah' machine was the single user
of the omap_uwire_attach() method. Remove it altogether with
the uWireSlave structure. Replace the send/receive callbacks
by Unimplemented logging.
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
This patch tests:
1. feasibility of removing mux which does not have frontends attached
or frontends were prior detached.
2. inability to remove mux which has frontends attached (mux is "busy")
Signed-off-by: Roman Penyaev <r.peniaev@gmail.com>
Cc: "Marc-André Lureau" <marcandre.lureau@redhat.com>
Cc: qemu-devel@nongnu.org
[ fixed *error leak ]
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-ID: <20241014152408.427700-9-r.peniaev@gmail.com>
With bitset management now it becomes feasible to implement
the logic of detaching frontends from multiplexer.
Signed-off-by: Roman Penyaev <r.peniaev@gmail.com>
Cc: "Marc-André Lureau" <marcandre.lureau@redhat.com>
Cc: qemu-devel@nongnu.org
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-ID: <20241014152408.427700-8-r.peniaev@gmail.com>
Frontends can be attached and detached during run-time (although detach
is not implemented, but will follow). Counter variable of muxes is not
enough for proper attach/detach management, so this patch implements
bitset: if bit is set for the `mux_bitset` variable, then frontend
device can be found in the `backend` array (yes, huge confusion with
backend and frontends names).
Signed-off-by: Roman Penyaev <r.peniaev@gmail.com>
Cc: "Marc-André Lureau" <marcandre.lureau@redhat.com>
Cc: qemu-devel@nongnu.org
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-ID: <20241014152408.427700-7-r.peniaev@gmail.com>
Move away logic which attaches frontend device to a mux
from `char-fe.c` to actual `char-mux.c` implementation
and make it a separate function.
No logic changes are made.
Signed-off-by: Roman Penyaev <r.peniaev@gmail.com>
Cc: "Marc-André Lureau" <marcandre.lureau@redhat.com>
Cc: qemu-devel@nongnu.org
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-ID: <20241014152408.427700-6-r.peniaev@gmail.com>
There is no sense to keep `focus`, `mux_cnt`, `prod`, `cons`
and `tag` variables as signed, those represent either size,
either position in array, which both are unsigned.
`focus` member of `MuxChardev` is kept signed, because initially
set to -1.
Signed-off-by: Roman Penyaev <r.peniaev@gmail.com>
Cc: "Marc-André Lureau" <marcandre.lureau@redhat.com>
Cc: qemu-devel@nongnu.org
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-ID: <20241014152408.427700-5-r.peniaev@gmail.com>
Those are boolean variables, not signed integers.
Signed-off-by: Roman Penyaev <r.peniaev@gmail.com>
Cc: "Marc-André Lureau" <marcandre.lureau@redhat.com>
Cc: qemu-devel@nongnu.org
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-ID: <20241014152408.427700-4-r.peniaev@gmail.com>
`mux_cnt` struct member never goes negative or decrements,
so mux chardev can be !busy only when there are no
frontends attached. This patch fixes the always-true
check.
Fixes: a4afa548fc ("char: move front end handlers in CharBackend")
Signed-off-by: Roman Penyaev <r.peniaev@gmail.com>
Cc: "Marc-André Lureau" <marcandre.lureau@redhat.com>
Cc: qemu-devel@nongnu.org
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-ID: <20241014152408.427700-2-r.peniaev@gmail.com>
This addresses the py311-yaml -> py311-pyyaml rename in FreeBSD.
The change to the OpenSUSE dockerfile is something that will allow
QEMU to access rust bindgen in future.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Message-id: 20241014130255.10119-1-berrange@redhat.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
If the defaults for --enable-rust ($rust in configure) and Meson's rust
option are out of sync, incremental builds will pick Meson's default.
This happens because, on an incremental build, configure does not run
Meson, Make does instead. Meson then gets the command line options
from either coredata.dat (which has everything cached in Python's pickle
format) or cmd_line.txt (slow path when Meson version is upgraded), but
neither knows about the rust option, and the meson_options.txt default
is used.
This will cause have_rust to be true if rustc is available; and the build
to fail because configure did not put a RUST_TARGET_TRIPLE in config-host.mak.
When in the Rust pull request I changed the $rust default from auto
to disabled, I should have made the same change to meson_options.txt;
do it now.
Cc: Manos Pitsidianakis <manos.pitsidianakis@linaro.org>
Reported-by: Peter Maydell <peter.maydell@linaro.org>
Reported-by: Daniel P. Berrangé <berrange@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Tested-by: Peter Maydell <peter.maydell@linaro.org>
Message-id: 20241014110113.173946-1-pbonzini@redhat.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
A working native Rust compiler is always needed in order to compile Rust
code, even when cross compiling, in order to build the procedural macros
that QEMU uses.
Right now, the check is done in rust/qemu-api-macros/meson.build, but this
has two disadvantages. First, it makes the build fail when the Meson "rust"
option is set to "auto" (instead, Rust support should be disabled). Second,
add_languages() is one of the few functions that are executed even by
"meson introspect", except that "meson introspect" executes both branches
of "if" statements! Therefore, "meson introspect" tries to look for a
Rust compiler even if the option is disabled---and then fails because
the compiler is required by rust/qemu-api-macros/meson.build. This is
visible for example if the compilation host has a stale
scripts/meson-buildoptions.sh and no rustc installed.
Both issues can be fixed by moving the check to the main meson.build,
together with the check for the cross compiler.
Reported-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
According to its man page [1], pw_context_connect() sets errno on
failure:
Returns a Core on success or NULL with errno set on error.
It may be handy to see errno when figuring out why PipeWire
failed to connect. That leaves us with just one possible path to
reach 'fail_error' label which is then moved to that path and
also its error message is adjusted slightly.
1: https://docs.pipewire.org/group__pw__core.html#ga5994e3a54e4ec718094ca02a1234815b
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Manos Pitsidianakis <manos.pitsidianakis@linaro.org>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-ID: <3a78811ad5b0e87816b7616ab21d2eeef00b9c52.1726647033.git.mprivozn@redhat.com>
Only check we eventually get a shared memory scanout.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Akihiko Odaki <akihiko.odaki@daynix.com>
Message-ID: <20241008125028.1177932-20-marcandre.lureau@redhat.com>
Use a common shareable type for win32 & unix, and helper functions.
This simplify the code as it avoids a lot of #ifdef'ery.
Note: if it helps review, commits could be reordered to introduce the
common type before introducing shareable memory for unix.
Suggested-by: Akihiko Odaki <akihiko.odaki@daynix.com>
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Akihiko Odaki <akihiko.odaki@daynix.com>
Message-ID: <20241008125028.1177932-19-marcandre.lureau@redhat.com>
Similar to what was done in commit 9462ff46 ("virtio-gpu/win32: allocate
shareable 2d resources/images") for win32, allocate resource memory with
memfd, so the associated display surface memory can be shared with a
different process.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Akihiko Odaki <akihiko.odaki@daynix.com>
Message-ID: <20241008125028.1177932-18-marcandre.lureau@redhat.com>
There are no types specific to Windows, so the code compiles on other
platforms, but its useless on !Windows.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Akihiko Odaki <akihiko.odaki@daynix.com>
Message-ID: <20241008125028.1177932-15-marcandre.lureau@redhat.com>
gio.pc variable is a bit bogus in context of cross-compilation, since it
contains an absolute path, relative to the sysroot directory. On Fedora, it ends
up as:
/usr/x86_64-w64-mingw32/sys-root/mingw/lib/pkgconfig/usr/bin/gdbus-codegen
path which does not exist because it is not shipped by Fedora mingw
packages.
Instead, we can rely on meson find_program() behaviour to do a better
job based on its search order and capabilities.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Akihiko Odaki <akihiko.odaki@daynix.com>
Message-ID: <20241008125028.1177932-14-marcandre.lureau@redhat.com>
Use qemu_memfd_alloc() to allocate the display surface memory, which
will fallback on tmpfile/mmap() on systems without memfd, and allow to
share the display with other processes.
This is similar to how display memory is allocated on win32 since commit
09b4c198 ("console/win32: allocate shareable display surface").
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Akihiko Odaki <akihiko.odaki@daynix.com>
Message-ID: <20241008125028.1177932-13-marcandre.lureau@redhat.com>
This is an arbitrary limitation that doesn't concern QEMU directly and
may make some use cases unnecessarily more complicated.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Akihiko Odaki <akihiko.odaki@daynix.com>
Message-ID: <20241008125028.1177932-11-marcandre.lureau@redhat.com>
