Le ven. 29 mars 2019 10:20, Peter Maydell a
écrit :
> On Thu, 28 Mar 2019 at 21:29, Wainer dos Santos Moschetta
> wrote:
> >
> >
> > On 03/28/2019 12:29 PM, Peter Maydell wrote:
> > > The Raspberry Pi boards have a physical memory map which does
> > > not allow for more than 1GB of RAM.
Hi Shameer,
[ + Laszlo, Ard, Leif ]
On 3/21/19 11:47 AM, Shameer Kolothum wrote:
> This is to disable/enable populating DT nodes in case
> any conflict with acpi tables. The default is "off".
The name of the option sounds misleading to me. Also we don't really
know the scope of the disablement.
On Fri, 29 Mar 2019, David Gibson wrote:
From: Greg Kurz
Signed-off-by: Greg Kurz
Message-Id: <155359567174.1794128.3183997593369465355.st...@bahia.lan>
Signed-off-by: David Gibson
---
target/ppc/translate.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git
Hi Eric,
> -Original Message-
> From: Auger Eric [mailto:eric.au...@redhat.com]
> Sent: 29 March 2019 09:32
> To: Shameerali Kolothum Thodi ;
> qemu-devel@nongnu.org; qemu-...@nongnu.org; imamm...@redhat.com;
> peter.mayd...@linaro.org; shannon.zha...@gmail.com;
> sa...@linux.intel.com;
Pavel Hrdina writes:
> On Fri, Mar 29, 2019 at 08:19:55AM +0100, Markus Armbruster wrote:
>> Eric Blake writes:
>>
>> > On 3/28/19 3:06 PM, Eric Blake wrote:
>> >> On 3/28/19 2:32 PM, Markus Armbruster wrote:
>> >>> Markus Armbruster writes:
>> Pavel Hrdina writes:
>> >>
>> > I'm
Am 29.03.2019 um 10:53 hat Vladimir Sementsov-Ogievskiy geschrieben:
> 28.03.2019 21:40, Kevin Wolf wrote:
> > Am 28.03.2019 um 08:21 hat Vladimir Sementsov-Ogievskiy geschrieben:
> >> bdrv_replace_child() calls bdrv_check_perm() with error_abort on
> >> loosening permissions. However file-locking
Hi Eric,
> -Original Message-
> From: Auger Eric [mailto:eric.au...@redhat.com]
> Sent: 29 March 2019 09:31
> To: Shameerali Kolothum Thodi ;
> qemu-devel@nongnu.org; qemu-...@nongnu.org; imamm...@redhat.com;
> peter.mayd...@linaro.org; shannon.zha...@gmail.com;
> sa...@linux.intel.com;
29.03.2019 13:12, Kevin Wolf wrote:
> Am 29.03.2019 um 10:53 hat Vladimir Sementsov-Ogievskiy geschrieben:
>> 28.03.2019 21:40, Kevin Wolf wrote:
>>> Am 28.03.2019 um 08:21 hat Vladimir Sementsov-Ogievskiy geschrieben:
bdrv_replace_child() calls bdrv_check_perm() with error_abort on
29.03.2019 13:55, Vladimir Sementsov-Ogievskiy wrote:
> 29.03.2019 13:12, Kevin Wolf wrote:
>> Am 29.03.2019 um 10:53 hat Vladimir Sementsov-Ogievskiy geschrieben:
>>> 28.03.2019 21:40, Kevin Wolf wrote:
Am 28.03.2019 um 08:21 hat Vladimir Sementsov-Ogievskiy geschrieben:
>
From: Max Filippov
Don't announce that exit simcall has been invoked: this is just noise.
Reviewed-by: Richard Henderson
Signed-off-by: Max Filippov
---
target/xtensa/xtensa-semi.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/target/xtensa/xtensa-semi.c b/target/xtensa/xtensa-semi.c
hw/usb/hcd-xhci.c: In function ‘usb_xhci_realize’:
hw/usb/hcd-xhci.c:3339:66: warning: ‘%d’ directive output may be truncated
writing between 1 and 10 bytes into a region of size 5 [-Wformat-trunca\
tion=]
3339 | snprintf(port->name, sizeof(port->name), "usb2 port #%d",
i+1);
From: Max Filippov
Drop test_fail: we know that exit simcall works. Now that it's not run
automatically there's no point in keeping it.
Drop test_pipeline: we're not modeling pipeline, we don't control ccount
and there's no plan to do so.
Enable test_boolean: it won't break on cores without
In file included from /usr/include/string.h:494,
from include/qemu/osdep.h:101,
from linux-user/uname.c:20:
In function ‘strncpy’,
inlined from ‘sys_uname’ at linux-user/uname.c:94:3:
/usr/include/bits/string_fortified.h:106:10: warning: ‘__builtin_strncpy’
Compiling with GCC 9 complains
hw/s390x/3270-ccw.c: In function ‘emulated_ccw_3270_cb’:
hw/s390x/3270-ccw.c:81:19: error: taking address of packed member of ‘struct
SCHIB’ may result in an unaligned pointer value
[-Werror=address-of-packed-member]
81 | SCSW *s = >curr_status.scsw;
The 'filename' field in ObjectInfo struct is declared as a
zero length array of uint16_t. Accessing it is equivalent
to taking the address of the field, and taking the address
of fields in a packed struct causes unaligned pointer
warnings:
hw/usb/dev-mtp.c: In function ‘usb_mtp_write_metadata’:
Compiling with GCC 9 complains
hw/s390x/ipl.c: In function ‘s390_ipl_set_boot_menu’:
hw/s390x/ipl.c:256:25: warning: taking address of packed member of ‘struct
QemuIplParameters’ may result in an unaligned pointer value
[-Waddress-of-packed-member]
256 | uint32_t *timeout =
On Fri, Mar 29, 2019 at 10:57:55 +0100, Markus Armbruster wrote:
> Kevin Wolf writes:
>
> > auto-read-only=on changed its behaviour in file-posix for the 4.0
> > release.
>
> Commit hash, please.
>
> > This change cannot be detected through the usual mechanisms
> > like schema
> -Original Message-
> From: Auger Eric [mailto:eric.au...@redhat.com]
> Sent: 28 March 2019 14:15
> To: Shameerali Kolothum Thodi ;
> qemu-devel@nongnu.org; qemu-...@nongnu.org; imamm...@redhat.com;
> peter.mayd...@linaro.org; shannon.zha...@gmail.com;
> sa...@linux.intel.com;
On 29/03/2019 12.11, Daniel P. Berrangé wrote:
> The 'filename' field in ObjectInfo struct is declared as a
> zero length array of uint16_t. Accessing it is equivalent
> to taking the address of the field, and taking the address
> of fields in a packed struct causes unaligned pointer
> warnings:
>
On Fri, 29 Mar 2019 at 11:22, Daniel P. Berrangé wrote:
>
> The 'filename' field in ObjectInfo struct is declared as a
> zero length array of uint16_t. Accessing it is equivalent
> to taking the address of the field, and taking the address
> of fields in a packed struct causes unaligned pointer
>
On 15/02/2019 14:52, David Hildenbrand wrote:
On 14.02.19 13:14, Pierre Morel wrote:
A new CPU model facilities is introduced to support AP devices
interruption interception for a KVM guest.
This sentence is confusing. At first I thought you would introduce a new
_fake_ facility.
"Let's add
bdrv_replace_child() calls bdrv_check_perm() with error_abort on
loosening permissions. However file-locking operations may fail even
in this case, for example on NFS. And this leads to Qemu crash.
Let's avoid such errors. Note, that we ignore such things anyway on
permission update commit and
Am 29.03.2019 um 11:55 hat Vladimir Sementsov-Ogievskiy geschrieben:
> 29.03.2019 13:12, Kevin Wolf wrote:
> > Am 29.03.2019 um 10:53 hat Vladimir Sementsov-Ogievskiy geschrieben:
> >> 28.03.2019 21:40, Kevin Wolf wrote:
> >>> Am 28.03.2019 um 08:21 hat Vladimir Sementsov-Ogievskiy geschrieben:
>
This series addresses all the warnings I see when building on Fedora 30
x86_64 with GCC 9 (gcc-9.0.1-0.10.fc30.x86_64).
Ideally QEMU 4.0.0 would be warning-free with GCC 9, but depends whether
maintainers like my approaches to fixing each set of warnings here ...
Daniel P. Berrangé (11):
From: Max Filippov
break_dependency incorrectly handles the case of dependency on an opcode
that references the same register multiple times. E.g. the following
instruction is translated incorrectly:
{ or a2, a3, a3 ; or a3, a2, a2 }
This happens because resource indices of both dependency
The ObjectInfo 'length' field provides the length of the
wide character string filename. This is then converted to
a multi-byte character string. This may have a different
byte count to the wide character string. We should use the
C string length of the multi-byte string instead.
Signed-off-by:
In file included from /usr/include/string.h:494,
from include/qemu/osdep.h:101,
from linux-user/elfload.c:2:
In function ‘strncpy’,
inlined from ‘fill_psinfo’ at linux-user/elfload.c:3208:12,
inlined from ‘fill_note_info’ at linux-user/elfload.c:3390:5,
In file included from /usr/include/string.h:494,
from include/qemu/osdep.h:101,
from util/qemu-sockets.c:18:
In function ‘strncpy’,
inlined from ‘unix_connect_saddr.isra.0’ at util/qemu-sockets.c:925:5:
/usr/include/bits/string_fortified.h:106:10: warning:
The SPICE_RING_PROD_ITEM() macro is initializing a local
'uint64_t *' variable to point to the 'el' field inside
the QXLReleaseRing struct. This uint64_t field is not
guaranteed aligned as the struct is packed.
Code should not take the address of fields within a
packed struct. Changing the
The GCC 9 compiler complains about many places in s390 code
that take the address of members of the 'struct SCHIB' which
is marked packed:
hw/vfio/ccw.c: In function ‘vfio_ccw_io_notifier_handler’:
hw/vfio/ccw.c:133:15: warning: taking address of packed member of ‘struct
SCHIB’ may result in an
The GCC 9 compiler complains about many places in s390 code
that take the address of members of the 'struct SCHIB' which
is marked packed:
hw/s390x/css.c: In function ‘sch_handle_clear_func’:
hw/s390x/css.c:698:15: warning: taking address of packed member of ‘struct
SCHIB’ may result in an
29.03.2019 14:08, Kevin Wolf wrote:
> Am 29.03.2019 um 11:55 hat Vladimir Sementsov-Ogievskiy geschrieben:
>> 29.03.2019 13:12, Kevin Wolf wrote:
>>> Am 29.03.2019 um 10:53 hat Vladimir Sementsov-Ogievskiy geschrieben:
28.03.2019 21:40, Kevin Wolf wrote:
> Am 28.03.2019 um 08:21 hat
On Fri, Mar 29, 2019 at 11:12:55AM +0100, Markus Armbruster wrote:
> Pavel Hrdina writes:
>
> > On Fri, Mar 29, 2019 at 08:19:55AM +0100, Markus Armbruster wrote:
> >> Eric Blake writes:
> >>
> >> > On 3/28/19 3:06 PM, Eric Blake wrote:
> >> >> On 3/28/19 2:32 PM, Markus Armbruster wrote:
> >>
Le ven. 29 mars 2019 10:27, Alex Bennée a écrit :
>
> Like Xu writes:
>
> > Signed-off-by: Like Xu
> > ---
> > hw/arm/fsl-imx6.c | 5 +
> > hw/arm/fsl-imx6ul.c| 5 +
> > hw/arm/fsl-imx7.c | 5 +
> > hw/arm/highbank.c | 1 +
> > hw/arm/mcimx6ul-evk.c | 1 +
> >
On 29.03.19 12:11, Daniel P. Berrangé wrote:
> Compiling with GCC 9 complains
>
> hw/s390x/3270-ccw.c: In function ‘emulated_ccw_3270_cb’:
> hw/s390x/3270-ccw.c:81:19: error: taking address of packed member of ‘struct
> SCHIB’ may result in an unaligned pointer value
>
On 29.03.19 12:11, Daniel P. Berrangé wrote:
> Compiling with GCC 9 complains
>
> hw/s390x/ipl.c: In function ‘s390_ipl_set_boot_menu’:
> hw/s390x/ipl.c:256:25: warning: taking address of packed member of ‘struct
> QemuIplParameters’ may result in an unaligned pointer value
>
On Fri, 29 Mar 2019 at 11:13, Daniel P. Berrangé wrote:
>
> This series addresses all the warnings I see when building on Fedora 30
> x86_64 with GCC 9 (gcc-9.0.1-0.10.fc30.x86_64).
>
> Ideally QEMU 4.0.0 would be warning-free with GCC 9, but depends whether
> maintainers like my approaches to
are available in the Git repository at:
>
> git://github.com/dgibson/qemu.git tags/ppc-for-4.0-20190329
>
> for you to fetch changes up to 7d5489e6d15e2922e45a41e4808d03a48457a5ee:
>
> exec: Only count mapped memory backends for qemu_getr
On 29/03/2019 12.11, Daniel P. Berrangé wrote:
> Compiling with GCC 9 complains
>
> hw/s390x/3270-ccw.c: In function ‘emulated_ccw_3270_cb’:
> hw/s390x/3270-ccw.c:81:19: error: taking address of packed member of ‘struct
> SCHIB’ may result in an unaligned pointer value
>
On Fri, Mar 29, 2019 at 12:25:54PM +0100, Thomas Huth wrote:
> On 29/03/2019 12.11, Daniel P. Berrangé wrote:
> > The 'filename' field in ObjectInfo struct is declared as a
> > zero length array of uint16_t. Accessing it is equivalent
> > to taking the address of the field, and taking the address
On Fri, Mar 29, 2019 at 11:50:48AM +, Peter Maydell wrote:
> On Fri, 29 Mar 2019 at 11:13, Daniel P. Berrangé wrote:
> >
> > This series addresses all the warnings I see when building on Fedora 30
> > x86_64 with GCC 9 (gcc-9.0.1-0.10.fc30.x86_64).
> >
> > Ideally QEMU 4.0.0 would be
29.03.2019 14:08, Kevin Wolf wrote:
> Am 29.03.2019 um 11:55 hat Vladimir Sementsov-Ogievskiy geschrieben:
>> 29.03.2019 13:12, Kevin Wolf wrote:
>>> Am 29.03.2019 um 10:53 hat Vladimir Sementsov-Ogievskiy geschrieben:
28.03.2019 21:40, Kevin Wolf wrote:
> Am 28.03.2019 um 08:21 hat
> -Original Message-
> From: Auger Eric [mailto:eric.au...@redhat.com]
> Sent: 28 March 2019 15:38
> To: Shameerali Kolothum Thodi ;
> qemu-devel@nongnu.org; qemu-...@nongnu.org; imamm...@redhat.com;
> peter.mayd...@linaro.org; shannon.zha...@gmail.com;
> sa...@linux.intel.com;
On Fri, 29 Mar 2019 at 07:35, Jason Wang wrote:
>
> The following changes since commit a04d91c701251a9b32b7364ddb48029ba024cb75:
>
> Merge remote-tracking branch
> 'remotes/alistair/tags/pull-device-tree-20190327' into staging (2019-03-28
> 12:39:43 +)
>
> are available in the git
201 - 244 of 244 matches
Mail list logo
