Am 01.01.20 um 12:22 schrieb Philippe Mathieu-Daudé:
> Noticed we could clean this while reviewing Richard patch last night:
> https://www.mail-archive.com/qemu-devel@nongnu.org/msg667606.html
>
> Since v1:
> - moved headers to include/tcg/ (Paolo)
> - include in .inc.c relative to parent (Stefan)
On Thu, Jan 02, 2020 at 07:13:25AM +, Sai Pavan Boddu wrote:
> Hi Gred,
>
> We are seeing of options to reuse the hcd-xhci model and use it over system
> bus interface rather than pci. (for Xilinx ZynqMP SOC, usb emulation)
> Are there any plans of implementing a sysbus device ? if none it wo
On Fri, Dec 20, 2019 at 06:36:41PM +0400, Marc-André Lureau wrote:
> Hi Gerd,
>
> On Wed, Nov 27, 2019 at 3:52 PM Marc-André Lureau
> wrote:
> >
> > Hi,
> >
> > The following patches have been extracted from the "[PATCH v6 00/25]
> > monitor: add asynchronous command type", as they are
> > review
On Fri, Dec 20, 2019 at 09:15:40AM -0800, John G Johnson wrote:
> > On Dec 19, 2019, at 5:36 AM, Stefan Hajnoczi wrote:
> > On Wed, Dec 18, 2019 at 01:00:55AM +0100, Paolo Bonzini wrote:
> >> On 17/12/19 23:57, Felipe Franciosi wrote:
> We don’t pin guest memory; we pass the QEMU file descriptors
On Fri, Dec 20, 2019 at 09:15:40AM -0800, John G Johnson wrote:
> > On Dec 19, 2019, at 5:36 AM, Stefan Hajnoczi wrote:
> > On Wed, Dec 18, 2019 at 01:00:55AM +0100, Paolo Bonzini wrote:
> >> On 17/12/19 23:57, Felipe Franciosi wrote:
> We don’t pin guest memory; we pass the QEMU file descriptors
On Linux, calling `reboot(RB_AUTOBOOT);` will result in
arch/m68k/mac/misc.c's mac_reset function being called. That in turn
looks at the rombase (or uses 0x4080 is there's no rombase), adds
0xa, and jumps to that address. At the moment, there's nothing there, so
the kernel just crashes when tr
Superseded by
https://lore.kernel.org/qemu-devel/20200102103644.233370-1-ja...@zx2c4.com
, thankfully.
Patchew URL: https://patchew.org/QEMU/20200102103644.233370-1-ja...@zx2c4.com/
Hi,
This series failed the docker-quick@centos7 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 ===
#!
Patchew URL: https://patchew.org/QEMU/20200102103644.233370-1-ja...@zx2c4.com/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Subject: [PATCH] q800: implement mac rom reset function for BIOS-less mode
Type: series
Message-id: 20200102103644.233
On Fri, Dec 20, 2019 at 10:22:37AM +, Daniel P. Berrangé wrote:
> On Fri, Dec 20, 2019 at 09:47:12AM +, Stefan Hajnoczi wrote:
> > On Thu, Dec 19, 2019 at 12:55:04PM +, Daniel P. Berrangé wrote:
> > > On Thu, Dec 19, 2019 at 12:33:15PM +, Felipe Franciosi wrote:
> > > > > On Dec 19,
Did anyone at QEMU get a chance to look at that patch?
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1849644
Title:
QEMU VNC websocket proxy requires non-standard 'binary' subprotocol
Status in QE
> On Jan 2, 2020, at 10:42 AM, Stefan Hajnoczi wrote:
>
> On Fri, Dec 20, 2019 at 10:22:37AM +, Daniel P. Berrangé wrote:
>> On Fri, Dec 20, 2019 at 09:47:12AM +, Stefan Hajnoczi wrote:
>>> On Thu, Dec 19, 2019 at 12:55:04PM +, Daniel P. Berrangé wrote:
On Thu, Dec 19, 2019 at
On Mon, Dec 30, 2019 at 01:10:15PM +0300, ASM wrote:
> > It could be a bug in QEMU's e1000 emulation - maybe it's not doing
> > things in the correct order and causes a race condition with the DPDK
> > polling driver - or it could be a bug in the DPDK e1000 driver regarding
> > the order in which t
Le 02/01/2020 à 11:36, Jason A. Donenfeld a écrit :
> On Linux, calling `reboot(RB_AUTOBOOT);` will result in
> arch/m68k/mac/misc.c's mac_reset function being called. That in turn
> looks at the rombase (or uses 0x4080 is there's no rombase), adds
> 0xa, and jumps to that address. At the momen
On Sat, Dec 21, 2019 at 02:07:19AM +, Wangyong wrote:
> > From: Stefan Hajnoczi [mailto:stefa...@gmail.com]
> > Sent: Friday, December 20, 2019 5:53 PM
> > To: wangyong (Cloud)
> > Cc: Stefan Hajnoczi ; pbonz...@redhat.com;
> > mark.ka...@oracle.com; h...@lst.de; qemu-devel@nongnu.org
> > Subj
On Fri, Dec 20, 2019 at 11:30:33AM +0100, Max Reitz wrote:
> On 20.12.19 11:08, Stefan Hajnoczi wrote:
> > On Thu, Dec 19, 2019 at 03:38:00PM +0100, Max Reitz wrote:
> > Please send a follow-up patch that adds a qemu(1) -blockdev
> > 'Driver-specific options for "fuse"' documentation section.
>
>
On Fri, Dec 20, 2019 at 09:07:50PM +, Richard W.M. Jones wrote:
> On Fri, Dec 20, 2019 at 04:13:59PM +, Stefan Hajnoczi wrote:
> > 6. A configuration file format is sorely needed so that guest
> > configuration can be persisted and easily launched.
>
> Actually qemu already has that, but
On 1/2/20 10:45 AM, kra...@redhat.com wrote:
On Thu, Jan 02, 2020 at 07:13:25AM +, Sai Pavan Boddu wrote:
Hi Gred,
We are seeing of options to reuse the hcd-xhci model and use it over system bus
interface rather than pci. (for Xilinx ZynqMP SOC, usb emulation)
Are there any plans of implem
On 31.12.19 16:44, Philippe Mathieu-Daudé wrote:
> On 12/31/19 2:03 PM, Igor Mammedov wrote:
>> If user provided non-sense RAM size, board will complain and
>> continue running with max RAM size supported.
>> Also RAM is going to be allocated by generic code, so it won't be
>> possible for board to
Le 02/01/2020 à 12:10, Laurent Vivier a écrit :
> Le 02/01/2020 à 11:36, Jason A. Donenfeld a écrit :
>> On Linux, calling `reboot(RB_AUTOBOOT);` will result in
>> arch/m68k/mac/misc.c's mac_reset function being called. That in turn
>> looks at the rombase (or uses 0x4080 is there's no rombase)
On Wed, 1 Jan 2020 12:54:37 +0100 (CET)
BALATON Zoltan wrote:
> On Tue, 31 Dec 2019, Igor Mammedov wrote:
> > If user provided non-sense RAM size, board will complain and
> > continue running with max RAM size supported.
> > Also RAM is going to be allocated by generic code, so it won't be
> > po
Signed-off-by: Marc-André Lureau
Reviewed-by: Daniel P. Berrangé
---
include/qom/object.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/include/qom/object.h b/include/qom/object.h
index 1d7b7e5a79..54a548868c 100644
--- a/include/qom/object.h
+++ b/include/qom/object.h
@@ -1766,4 +1766,
Signed-off-by: Marc-André Lureau
Reviewed-by: Daniel P. Berrangé
---
include/ui/qemu-pixman.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/ui/qemu-pixman.h b/include/ui/qemu-pixman.h
index 0668109305..3b7cf70157 100644
--- a/include/ui/qemu-pixman.h
+++ b/include/ui/qemu-pixman.
The following changes since commit dd5b0f95490883cd8bc7d070db8de70d5c979cbc:
Merge remote-tracking branch 'remotes/cohuck/tags/s390x-20191219' into
staging (2019-12-20 16:37:07 +)
are available in the Git repository at:
https://github.com/elmarco/qemu.git tags/screendump-pull-request
f
Add a function to be called when a graphic update is done.
Declare the QXL renderer as async: render_update_cookie_num counts the
number of outstanding updates, and graphic_hw_update_done() is called
when it reaches none.
(note: this is preliminary work for asynchronous screendump support)
Signe
Add a helper function to match qemu_open() which may return files
under the /dev/fdset prefix. Those shouldn't be removed, since it's
only a qemu namespace.
Signed-off-by: Marc-André Lureau
Reviewed-by: Daniel P. Berrangé
---
include/qemu/osdep.h | 1 +
util/osdep.c | 15 ++
The file opened for ppm_save() may be a /dev/fdset, in which case a
dup fd is added to the fdset. It should be removed by calling
qemu_close(), instead of the implicit close() on fclose().
I don't see a convenient way to solve that with stdio streams, so I
switched the code to QIOChannel which use
Don't attempt to remove /dev/fdset files.
Signed-off-by: Marc-André Lureau
Reviewed-by: Daniel P. Berrangé
---
ui/console.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/ui/console.c b/ui/console.c
index 587edf4ed4..e6ac462aa0 100644
--- a/ui/console.c
+++ b/ui/console.c
@
This will allow to pre-open the file before running the async finish
handler and avoid potential monitor fdset races.
(note: this is preliminary work for asynchronous screendump support)
Signed-off-by: Marc-André Lureau
Reviewed-by: Daniel P. Berrangé
---
ui/console.c| 45 +
On Linux, calling `reboot(RB_AUTOBOOT);` will result in
arch/m68k/mac/misc.c's mac_reset function being called. That in turn
looks at the rombase (or uses 0x4080 is there's no rombase), adds
0xa, and jumps to that address. At the moment, there's nothing there, so
the kernel just crashes when tr
Could you run qemu unimplemented error trace, by using "export
QEMU_LOG=unimp"?
You can also set the QEMU_STRACE="" to see which syscall fails.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1857811
On 1/2/20 12:31 PM, Helge Deller wrote:
On 31.12.19 16:44, Philippe Mathieu-Daudé wrote:
On 12/31/19 2:03 PM, Igor Mammedov wrote:
If user provided non-sense RAM size, board will complain and
continue running with max RAM size supported.
Also RAM is going to be allocated by generic code, so it
PID namespace prevents to execute some syscalls, even if you use --map-
root-user. This is managed at kernel level by the capabilities.
Could you try to do the exact same thing with the native architecture
binaries in the chroot to see if the problem really comes from qemu-
user?
Could you try to
On Thu, Jan 2, 2020 at 3:55 PM Marc-André Lureau
wrote:
>
> The following changes since commit dd5b0f95490883cd8bc7d070db8de70d5c979cbc:
>
> Merge remote-tracking branch 'remotes/cohuck/tags/s390x-20191219' into
> staging (2019-12-20 16:37:07 +)
>
> are available in the Git repository at:
>
On 02.01.20 13:06, Philippe Mathieu-Daudé wrote:
> On 1/2/20 12:31 PM, Helge Deller wrote:
>> On 31.12.19 16:44, Philippe Mathieu-Daudé wrote:
>>> On 12/31/19 2:03 PM, Igor Mammedov wrote:
If user provided non-sense RAM size, board will complain and
continue running with max RAM size supp
* Kevin Wolf (kw...@redhat.com) wrote:
> Am 19.12.2019 um 15:26 hat Max Reitz geschrieben:
> > On 17.12.19 15:59, Kevin Wolf wrote:
> > > This tests creating an external snapshot with VM state (which results in
> > > an active overlay over an inactive backing file, which is also the root
> > > node
According to `man unshare`, --keep-caps seems to apply only to user
namespace.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1829459
Title:
qemu seems to lack support for pid namespace.
Status in
In a native chroot, `sudo unshare --pid -- echo hello world` works
without a problem.
In a qemu-aarch64 chroot, `sudo unshare --keep-caps --pid -- echo hello
world` fails with the same error described in this issue.
`qemu: qemu_thread_create: Invalid argument`
--
You received this bug notificat
On Thu, Jan 2, 2020 at 12:41 PM Laurent Vivier wrote:
>
> Le 02/01/2020 à 12:10, Laurent Vivier a écrit :
> > Le 02/01/2020 à 11:36, Jason A. Donenfeld a écrit :
> >> On Linux, calling `reboot(RB_AUTOBOOT);` will result in
> >> arch/m68k/mac/misc.c's mac_reset function being called. That in turn
>
I executed "emerge" with QEMU_LOG=unimp and QEMU_STRACE="".
** Attachment added: "emerge.log"
https://bugs.launchpad.net/qemu/+bug/1857811/+attachment/5317106/+files/emerge.log
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
http
I think you should investigate
`qemu: qemu_thread_create: Invalid argument`
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1829459
Title:
qemu seems to lack support for pid namespace.
Status in QE
On Thu, 2 Jan 2020 13:06:33 +0100
Philippe Mathieu-Daudé wrote:
> On 1/2/20 12:31 PM, Helge Deller wrote:
> > On 31.12.19 16:44, Philippe Mathieu-Daudé wrote:
> >> On 12/31/19 2:03 PM, Igor Mammedov wrote:
> >>> If user provided non-sense RAM size, board will complain and
> >>> continue runni
Le 02/01/2020 à 13:01, Jason A. Donenfeld a écrit :
> On Linux, calling `reboot(RB_AUTOBOOT);` will result in
> arch/m68k/mac/misc.c's mac_reset function being called. That in turn
> looks at the rombase (or uses 0x4080 is there's no rombase), adds
> 0xa, and jumps to that address. At the momen
On 1/2/20 3:12 PM, Igor Mammedov wrote:
On Thu, 2 Jan 2020 13:06:33 +0100
Philippe Mathieu-Daudé wrote:
On 1/2/20 12:31 PM, Helge Deller wrote:
On 31.12.19 16:44, Philippe Mathieu-Daudé wrote:
On 12/31/19 2:03 PM, Igor Mammedov wrote:
If user provided non-sense RAM size, board will complain
On Tue, Dec 24, 2019 at 01:00:35PM +, Daniel P. Berrangé wrote:
> On Fri, Dec 20, 2019 at 04:13:59PM +, Stefan Hajnoczi wrote:
> > Hi,
> > QEMU presents a command-line interface and QMP monitor for
> > applications to interact with. Applications actually need API
> > bindings in their prog
On Thu, 2 Jan 2020 12:31:58 +0100
Helge Deller wrote:
> On 31.12.19 16:44, Philippe Mathieu-Daudé wrote:
> > On 12/31/19 2:03 PM, Igor Mammedov wrote:
> >> If user provided non-sense RAM size, board will complain and
> >> continue running with max RAM size supported.
> >> Also RAM is going to b
On 1/2/20 3:41 PM, Igor Mammedov wrote:
On Thu, 2 Jan 2020 12:31:58 +0100
Helge Deller wrote:
On 31.12.19 16:44, Philippe Mathieu-Daudé wrote:
On 12/31/19 2:03 PM, Igor Mammedov wrote:
If user provided non-sense RAM size, board will complain and
continue running with max RAM size supported.
On Sat, Dec 21, 2019 at 10:02:23AM +0100, Markus Armbruster wrote:
> Stefan Hajnoczi writes:
>
> > Hi,
> > QEMU presents a command-line interface and QMP monitor for
> > applications to interact with. Applications actually need API
> > bindings in their programming language. Bindings avoid reim
On Thu, 2 Jan 2020 14:02:01 +0100
Helge Deller wrote:
> On 02.01.20 13:06, Philippe Mathieu-Daudé wrote:
> > On 1/2/20 12:31 PM, Helge Deller wrote:
> >> On 31.12.19 16:44, Philippe Mathieu-Daudé wrote:
> >>> On 12/31/19 2:03 PM, Igor Mammedov wrote:
> If user provided non-sense RAM si
Hi,
Here's an interesting crash I've seen pop up since enabling CONFIG_JUMP_LABEL=y:
[4.716238] EIP: secure_tcp_seq+0x1e/0xa0^M
[4.716238] Code: c1 e8 46 90 fb ff eb a2 8d 74 26 00 55 89 e5 83
ec 18 89 75 f8 89 c6 0f b7 45 08 89 5d f4 0f b7 d9 89 7d fc 89 d7 89
45 ec 3e <8d> 74 26 00 8b 4
On Mon, Dec 23, 2019 at 04:18:20PM +0300, Denis Plotnikov wrote:
> 1. virtqueue_size is a power of 2
> 2. virtqueue_size > 2, since seg_max is virtqueue_size - 2
>
> Signed-off-by: Denis Plotnikov
> ---
> hw/virtio/virtio.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --gi
* Markus Armbruster (arm...@redhat.com) wrote:
> Stefan Hajnoczi writes:
> > 4. Go and Rust bindings would also be useful. There is
> > https://github.com/intel/govmm but I think it makes sense to keep it
> > in qemu.git and provide an interface similar to our Python modules.
>
> Mapping QAPI/QM
On Thu, Dec 26, 2019 at 05:40:22PM +0800, 张海斌 wrote:
> Stefan Hajnoczi 于2019年3月29日周五 上午1:08写道：
> >
> > On Thu, Mar 28, 2019 at 05:53:34PM +0800, 张海斌 wrote:
> > > hi, stefan
> > >
> > > I have faced the same problem you wrote in
> > > https://lists.gnu.org/archive/html/qemu-devel/2016-08/msg04025.h
On Thu, 2 Jan 2020 15:17:14 +0100
Philippe Mathieu-Daudé wrote:
> On 1/2/20 3:12 PM, Igor Mammedov wrote:
> > On Thu, 2 Jan 2020 13:06:33 +0100
> > Philippe Mathieu-Daudé wrote:
> >
> >> On 1/2/20 12:31 PM, Helge Deller wrote:
> >>> On 31.12.19 16:44, Philippe Mathieu-Daudé wrote:
>
On Thu, Dec 26, 2019 at 07:05:04PM +0100, Philippe Mathieu-Daudé wrote:
> I'm not sure who is responsible of this...
Jeff maintains the web server and wiki.
I can look into things when Jeff is too busy, but lets see if he has
time in January.
Stefan
signature.asc
Description: PGP signature
* Stefan Hajnoczi (stefa...@gmail.com) wrote:
> 5. A jailer is needed to isolate the QEMU process and vhost-user
> device backends using seccomp, Linux namespaces, and maybe
> SELinux/AppArmor. We used to be able to rely on libvirt for QEMU
> security, but it's becoming a common task for any devi
On Mon, Dec 30, 2019 at 06:21:27PM +, Eltahawy, Mahmoud wrote:
> I am new to QEMU and I am using qemu-3.0.1, I noticed a strange behavior for
> qemu_set_fd_handler that the callback for reading from a file descriptor is
> delayed then expected while the file descriptor(socket) has a data to r
> On Jan 2, 2020, at 3:07 PM, Stefan Hajnoczi wrote:
>
> On Thu, Dec 26, 2019 at 05:40:22PM +0800, 张海斌 wrote:
>> Stefan Hajnoczi 于2019年3月29日周五 上午1:08写道：
>>>
>>> On Thu, Mar 28, 2019 at 05:53:34PM +0800, 张海斌 wrote:
hi, stefan
I have faced the same problem you wrote in
http
On 1/2/20 4:09 PM, Stefan Hajnoczi wrote:
On Thu, Dec 26, 2019 at 07:05:04PM +0100, Philippe Mathieu-Daudé wrote:
I'm not sure who is responsible of this...
Jeff maintains the web server and wiki.
I can look into things when Jeff is too busy, but lets see if he has
time in January.
Sure no
On Thu, 2 Jan 2020 15:45:55 +0100
Philippe Mathieu-Daudé wrote:
> On 1/2/20 3:41 PM, Igor Mammedov wrote:
> > On Thu, 2 Jan 2020 12:31:58 +0100
> > Helge Deller wrote:
> >
> >> On 31.12.19 16:44, Philippe Mathieu-Daudé wrote:
> >>> On 12/31/19 2:03 PM, Igor Mammedov wrote:
> If user
On 1/2/20 4:35 PM, Igor Mammedov wrote:
On Thu, 2 Jan 2020 15:45:55 +0100
Philippe Mathieu-Daudé wrote:
On 1/2/20 3:41 PM, Igor Mammedov wrote:
On Thu, 2 Jan 2020 12:31:58 +0100
Helge Deller wrote:
On 31.12.19 16:44, Philippe Mathieu-Daudé wrote:
On 12/31/19 2:03 PM, Igor Mammedov wrot
On 1/2/20 4:08 PM, Igor Mammedov wrote:
On Thu, 2 Jan 2020 15:17:14 +0100
Philippe Mathieu-Daudé wrote:
On 1/2/20 3:12 PM, Igor Mammedov wrote:
On Thu, 2 Jan 2020 13:06:33 +0100
Philippe Mathieu-Daudé wrote:
On 1/2/20 12:31 PM, Helge Deller wrote:
On 31.12.19 16:44, Philippe Mathieu-Da
Update: compiling qemu upstream & using the latest version didn't change
anything.
I don't know if this is an instance of user emulation limitations due to
missing syscalls.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://b
On Thu, 2 Jan 2020, Igor Mammedov wrote:
On Wed, 1 Jan 2020 12:54:37 +0100 (CET)
BALATON Zoltan wrote:
On Tue, 31 Dec 2019, Igor Mammedov wrote:
If user provided non-sense RAM size, board will complain and
continue running with max RAM size supported.
Also RAM is going to be allocated by gener
On Tue, Dec 17, 2019 at 04:33:16PM +, Stefan Hajnoczi wrote:
> On Mon, Dec 16, 2019 at 07:57:32PM +, Felipe Franciosi wrote:
> > > On 16 Dec 2019, at 20:47, Elena Ufimtseva
> > > wrote:
> > > On Fri, Dec 13, 2019 at 10:41:16AM +, Stefan Hajnoczi wrote:
> > >> Is there a work-in-progr
On Thu, 2 Jan 2020 16:49:00 +0100
Philippe Mathieu-Daudé wrote:
> On 1/2/20 4:08 PM, Igor Mammedov wrote:
> > On Thu, 2 Jan 2020 15:17:14 +0100
> > Philippe Mathieu-Daudé wrote:
> >
> >> On 1/2/20 3:12 PM, Igor Mammedov wrote:
> >>> On Thu, 2 Jan 2020 13:06:33 +0100
> >>> Philippe Mathieu-D
Previous patch drops silent ram_size fixup and makes
QEMU error out with:
"RAM size more than 3840m is not supported"
when user specified -m X more than supported value.
User shouldn't be bothered with starting QEMU with valid CLI,
so for the sake of user convenience to allow using -m 4G vs -m
On 1/2/20 5:50 PM, Igor Mammedov wrote:
On Thu, 2 Jan 2020 16:49:00 +0100
Philippe Mathieu-Daudé wrote:
On 1/2/20 4:08 PM, Igor Mammedov wrote:
On Thu, 2 Jan 2020 15:17:14 +0100
Philippe Mathieu-Daudé wrote:
On 1/2/20 3:12 PM, Igor Mammedov wrote:
On Thu, 2 Jan 2020 13:06:33 +0100
Phil
On 1/2/20 6:08 PM, Igor Mammedov wrote:
Previous patch drops silent ram_size fixup and makes
QEMU error out with:
"RAM size more than 3840m is not supported"
when user specified -m X more than supported value.
User shouldn't be bothered with starting QEMU with valid CLI,
so for the sake of u
On Thu, 2 Jan 2020 16:52:50 +0100 (CET)
BALATON Zoltan wrote:
> On Thu, 2 Jan 2020, Igor Mammedov wrote:
> > On Wed, 1 Jan 2020 12:54:37 +0100 (CET)
> > BALATON Zoltan wrote:
> >> On Tue, 31 Dec 2019, Igor Mammedov wrote:
> >>> If user provided non-sense RAM size, board will complain and
> >
On Thu, 2 Jan 2020 18:14:32 +0100
Philippe Mathieu-Daudé wrote:
> On 1/2/20 5:50 PM, Igor Mammedov wrote:
> > On Thu, 2 Jan 2020 16:49:00 +0100
> > Philippe Mathieu-Daudé wrote:
> >
> >> On 1/2/20 4:08 PM, Igor Mammedov wrote:
> >>> On Thu, 2 Jan 2020 15:17:14 +0100
> >>> Philippe Mathieu-D
On Thu, 2 Jan 2020 18:15:02 +0100
Philippe Mathieu-Daudé wrote:
> On 1/2/20 6:08 PM, Igor Mammedov wrote:
> > Previous patch drops silent ram_size fixup and makes
> > QEMU error out with:
> >
> > "RAM size more than 3840m is not supported"
> >
> > when user specified -m X more than supported
Previous patch drops silent ram_size fixup and makes
QEMU error out with:
"RAM size more than 3840m is not supported"
when user specified -m X more than supported value.
User shouldn't be bothered with starting QEMU with valid CLI,
so for the sake of user convenience allow using -m 4G vs -m 384
On Mon, 09 Dec 2019 10:10:43 PST (-0800), Alistair Francis wrote:
The MIP CSR is a xlen CSR, it was only 32-bits to allow atomic access.
Now that we don't use atomics for MIP we can change this back to a xlen
CSR.
Signed-off-by: Alistair Francis
---
target/riscv/cpu.c | 2 +-
target/riscv/cpu.
* Alex Williamson (alex.william...@redhat.com) wrote:
> On Fri, 20 Dec 2019 01:40:35 +0530
> Kirti Wankhede wrote:
>
> > On 12/19/2019 10:57 PM, Alex Williamson wrote:
> >
> >
> >
> >
> > If device state it at pre-copy state (011b).
> > Transition, i.e., write to device state as stop-and-c
Hi
On Thu, Jan 2, 2020 at 3:03 PM Felipe Franciosi wrote:
> The reason I dislike yet another offloading protocol (ie. there is
> vhost, there is vfio, and then there would be qdev-over-socket) is
> that we keep reinventing the wheel. I very much prefer picking
> something solid (eg. VFIO) and kee
Hi Philippe,
I'm almost ready to send out v3 here.
Now for documentation I'm not sure yet what to do:
1) Where should I place board documentation?
For example, the information that I wrote on the cover letter with
instructions on how to get the board up and running,
some description of t
On 02.01.20 16:49, Philippe Mathieu-Daudé wrote:
> On 1/2/20 4:08 PM, Igor Mammedov wrote:
>> On Thu, 2 Jan 2020 15:17:14 +0100
>> Philippe Mathieu-Daudé wrote:
>>
>>> On 1/2/20 3:12 PM, Igor Mammedov wrote:
On Thu, 2 Jan 2020 13:06:33 +0100
Philippe Mathieu-Daudé wrote:
> O
On 02.01.20 18:46, Igor Mammedov wrote:
> Previous patch drops silent ram_size fixup and makes
> QEMU error out with:
>
> "RAM size more than 3840m is not supported"
>
> when user specified -m X more than supported value.
>
> User shouldn't be bothered with starting QEMU with valid CLI,
> so for t
When enlightened VMCS is enabled, certain VMX controls disappear, e.g.
posted interrupts for PINBASED_CTLS. With fine-grained VMX feature
enablement QEMU tries to do KVM_SET_MSRS with default (matching CPU
model) values and fails as KVM doesn't allow to set now-unsupported
controls.
The ideal solu
Check the host pointer is correctly aligned, otherwise we may fail
during migration in ram_block_discard_range().
Signed-off-by: Marc-André Lureau
---
migration/savevm.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/migration/savevm.c b/migration/savevm.c
index a71b930b91..ab6e02011f
post-copy migration fails on destination with error such as:
2019-12-26T10:22:44.714644Z qemu-kvm: ram_block_discard_range:
Unaligned start address: 0x559d2afae9a0
Use qemu_memalign() to constrain the PPI RAM memory alignment.
Cc: qemu-sta...@nongnu.org
Signed-off-by: Marc-André Lureau
---
hw/t
Hi,
The following series fixes a migration issue with the TPM PPI code due
to unaligned host RAM pointer.
Marc-André Lureau (2):
RFC: savevm: check RAM is page_size aligned
tpm-ppi: page-align PPI RAM
hw/tpm/tpm_ppi.c | 3 ++-
migration/savevm.c | 5 +
2 files changed, 7 insertions(+)
Hi Niek,
On 1/2/20 8:52 PM, Niek Linnenbank wrote:
Hi Philippe,
I'm almost ready to send out v3 here.
Now for documentation I'm not sure yet what to do:
1) Where should I place board documentation?
For example, the information that I wrote on the cover letter with
instructions on how to
Hey Philippe,
On Thu, Jan 2, 2020 at 10:11 PM Philippe Mathieu-Daudé
wrote:
> Hi Niek,
>
> On 1/2/20 8:52 PM, Niek Linnenbank wrote:
> > Hi Philippe,
> >
> > I'm almost ready to send out v3 here.
> >
> > Now for documentation I'm not sure yet what to do:
> >
> > 1) Where should I place board doc
On Thu, Dec 19, 2019 at 09:06:05AM -0500, Stefan Berger wrote:
> Add an example to the TPM docs for how to add a TPM SPAPR
> device model to a QEMU VM emulating a pSeries machine.
>
> Signed-off-by: Stefan Berger
I don't see any advantage to splitting this out - it can be merged
into 3/6.
> ---
On Thu, Dec 19, 2019 at 09:06:03AM -0500, Stefan Berger wrote:
> Extend the tpm_spapr frontend with VM suspend and resume support.
>
> Signed-off-by: Stefan Berger
> ---
> hw/tpm/tpm_spapr.c | 67 -
> hw/tpm/trace-events | 2 ++
> 2 files changed, 68
On Thu, Dec 12, 2019 at 02:22:56PM +0530, Shivaprasad G Bhat wrote:
>
>
> On 12/11/2019 01:35 PM, Igor Mammedov wrote:
> > On Wed, 11 Dec 2019 09:44:11 +0530
> > Shivaprasad G Bhat wrote:
> >
> > > On 12/06/2019 07:22 AM, David Gibson wrote:
> > > > On Wed, Nov 27, 2019 at 09:50:54AM +0530, Bha
On 1/1/20 10:22 PM, Philippe Mathieu-Daudé wrote:
> Noticed we could clean this while reviewing Richard patch last night:
> https://www.mail-archive.com/qemu-devel@nongnu.org/msg667606.html
>
> Since v1:
> - moved headers to include/tcg/ (Paolo)
> - include in .inc.c relative to parent (Stefan)
>
On Thu, Jan 2, 2020 at 10:18 AM Palmer Dabbelt wrote:
>
> On Mon, 09 Dec 2019 10:10:43 PST (-0800), Alistair Francis wrote:
> > The MIP CSR is a xlen CSR, it was only 32-bits to allow atomic access.
> > Now that we don't use atomics for MIP we can change this back to a xlen
> > CSR.
> >
> > Signed
On Thu, Jan 02, 2020 at 01:21:09PM +0530, Ganesh Goudar wrote:
> From: Aravinda Prasad
>
> This patch adds support in QEMU to handle "ibm,nmi-register"
> and "ibm,nmi-interlock" RTAS calls.
>
> The machine check notification address is saved when the
> OS issues "ibm,nmi-register" RTAS call.
>
On Tue, Dec 17, 2019 at 02:49:14AM -0600, Shivaprasad G Bhat wrote:
> Add support for NVDIMM devices for sPAPR. Piggyback on existing nvdimm
> device interface in QEMU to support virtual NVDIMM devices for Power.
> Create the required DT entries for the device (some entries have
> dummy values righ
On Tue, Dec 17, 2019 at 02:49:36AM -0600, Shivaprasad G Bhat wrote:
> This patch implements few of the necessary hcalls for the nvdimm support.
>
> PAPR semantics is such that each NVDIMM device is comprising of multiple
> SCM(Storage Class Memory) blocks. The guest requests the hypervisor to
> bi
On Thu, Jan 02, 2020 at 01:21:10PM +0530, Ganesh Goudar wrote:
> From: Aravinda Prasad
>
> This patch includes migration support for machine check
> handling. Especially this patch blocks VM migration
> requests until the machine check error handling is
> complete as these errors are specific to
On Wed, Jan 1, 2020 at 3:24 AM Philippe Mathieu-Daudé wrote:
>
> We currently search both the root and the tcg/ directories for tcg
> files:
>
> $ git grep '#include "tcg/' | wc -l
> 28
>
> $ git grep '#include "tcg[^/]' | wc -l
> 94
>
> To simplify the preprocessor search path, unify by e
On Wed, Jan 1, 2020 at 3:24 AM Philippe Mathieu-Daudé wrote:
>
> All the *.inc.c files included by tcg/$TARGET/tcg-target.inc.c
> are in tcg/, their parent directory. To simplify the preprocessor
> search path, include the relative parent path: '..'.
>
> Patch created mechanically by running:
>
>
On Wed, Jan 1, 2020 at 3:27 AM Philippe Mathieu-Daudé wrote:
>
> Signed-off-by: Philippe Mathieu-Daudé
Reviewed-by: Alistair Francis
Alistair
> ---
> {tcg => include/tcg}/tcg-gvec-desc.h | 0
> {tcg => include/tcg}/tcg-mo.h| 0
> {tcg => include/tcg}/tcg-op-gvec.h | 0
> {tcg => in
On Wed, Jan 1, 2020 at 3:25 AM Philippe Mathieu-Daudé wrote:
>
> All tcg includes are relative to the repository root directory,
> we can safely remove the tcg/ directory from the include search
> path list.
>
> Signed-off-by: Philippe Mathieu-Daudé
Reviewed-by: Alistair Francis
Alistair
> --
The 32 vector registers will be viewed as a continuous memory block.
It avoids the convension between element index and (regno,offset).
Thus elements can be directly accessed by offset from the first vector
base address.
Signed-off-by: LIU Zhiwei
---
target/riscv/cpu.h | 14 ++
1 fil
This is the first part of v3 patchset. The changelog of v3 is only coverd
the part1.
Features:
* support specification riscv-v-spec-0.7.1.
* support basic vector extension.
* support Zvlsseg.
1 - 100 of 127 matches
Mail list logo
