On Tue, 14 May 2019 02:12:35 -0400
Yan Zhao wrote:
> On Mon, May 13, 2019 at 09:28:04PM +0800, Erik Skultety wrote:
> > In case of libvirt checking the compatibility, it won't matter how good the
> > error message in the kernel log is and regardless of how many error states
> > you
> > want to
On 13.05.19 13:46, Cornelia Huck wrote:
> On Mon, 13 May 2019 13:34:35 +0200
> David Hildenbrand wrote:
>
>> On 13.05.19 12:55, Christian Borntraeger wrote:
>>>
>>>
>>> On 13.05.19 11:57, David Hildenbrand wrote:
On 13.05.19 11:51, Christian Borntraeger wrote:
>
>
> On 13.
Replace the single opcode in .opc with a null-terminated
array in .opt_opc. We still require that all opcodes be
used with the same .vece.
Validate the contents of this list with CONFIG_DEBUG_TCG.
All tcg_gen_*_vec functions will check any list active
during .fniv expansion. Swap the active list
On Tue, May 14, 2019 at 02:12:35AM -0400, Yan Zhao wrote:
> On Mon, May 13, 2019 at 09:28:04PM +0800, Erik Skultety wrote:
> > On Fri, May 10, 2019 at 11:48:38AM +0200, Cornelia Huck wrote:
> > > On Fri, 10 May 2019 10:36:09 +0100
> > > "Dr. David Alan Gilbert" wrote:
> > >
> > > > * Cornelia Huck
>>> But that can be tested using the runability information if I am not wrong.
>>
>> You mean the cpu level information, right?
Yes, query-cpu-definition includes for each model runability information
via "unavailable-features" (valid under the started QEMU machine).
>>
>>>
and others that w
On Tue, May 14, 2019 at 08:46:27AM +0200, Cédric Le Goater wrote:
> This documents the overall XIVE architecture and gives an overview of
> the QEMU models. It also provides documentation on the 'info pic'
> command.
>
> Signed-off-by: Cédric Le Goater
> ---
> docs/index.rst | 1 +
> docs/
On Tue, May 14, 2019 at 03:20:40PM +0800, Erik Skultety wrote:
> On Tue, May 14, 2019 at 02:12:35AM -0400, Yan Zhao wrote:
> > On Mon, May 13, 2019 at 09:28:04PM +0800, Erik Skultety wrote:
> > > On Fri, May 10, 2019 at 11:48:38AM +0200, Cornelia Huck wrote:
> > > > On Fri, 10 May 2019 10:36:09 +01
On Tue, May 14, 2019 at 03:32:19AM -0400, Yan Zhao wrote:
> On Tue, May 14, 2019 at 03:20:40PM +0800, Erik Skultety wrote:
> > On Tue, May 14, 2019 at 02:12:35AM -0400, Yan Zhao wrote:
> > > On Mon, May 13, 2019 at 09:28:04PM +0800, Erik Skultety wrote:
> > > > On Fri, May 10, 2019 at 11:48:38AM +0
On Tue, May 14, 2019 at 03:43:44PM +0800, Erik Skultety wrote:
> On Tue, May 14, 2019 at 03:32:19AM -0400, Yan Zhao wrote:
> > On Tue, May 14, 2019 at 03:20:40PM +0800, Erik Skultety wrote:
> > > On Tue, May 14, 2019 at 02:12:35AM -0400, Yan Zhao wrote:
> > > > On Mon, May 13, 2019 at 09:28:04PM +0
Add a new RNG backend using QEMU builtin getrandom function.
This patch applies on top of
"[PATCH v6 00/24] Add qemu_getrandom and ARMv8.5-RNG etc"
Based-on: 20190510173049.28171-1-richard.hender...@linaro.org
v4: update PATCH 1 commit message
v3: Include Kashyap's patch in the series
Ad
From: Kashyap Chamarthy
When QEMU exposes a VirtIO-RNG device to the guest, that device needs a
source of entropy, and that source needs to be "non-blocking", like
`/dev/urandom`. However, currently QEMU defaults to the problematic
`/dev/random`, which on linux is "blocking" (as in, it waits unt
Add a new RNG backend using QEMU builtin getrandom function.
It can be created and used with something like:
... -object rng-builtin,id=rng0 -device virtio-rng,rng=rng0 ...
Reviewed-by: Richard Henderson
Signed-off-by: Laurent Vivier
---
backends/Makefile.objs | 2 +-
backends/rng-builti
Signed-off-by: Laurent Vivier
---
backends/rng-builtin.c | 8 +++-
hw/virtio/virtio-rng.c | 2 +-
include/hw/virtio/virtio-rng.h | 4 ++--
include/sysemu/rng-builtin.h | 17 +
qemu-options.hx| 5 ++---
5 files changed, 25 insertions(+), 11
On Mon, May 06, 2019 at 05:40:05PM -, Waldemar Kozaczuk wrote:
> The last bios indeed helped. It knows runs under 200ms.
>
> Do you anticipate doing minor release of 3.1.0 with updated bios to address
> this issue? Or users are expected to upgrade to QEMU 4.0.0?
CCing Gerd
I'm not sure we wi
On Tue, May 14, 2019 at 09:56:00AM +0200, Laurent Vivier wrote:
> From: Kashyap Chamarthy
>
> When QEMU exposes a VirtIO-RNG device to the guest, that device needs a
> source of entropy, and that source needs to be "non-blocking", like
> `/dev/urandom`. However, currently QEMU defaults to the pr
On 14/05/2019 10:08, Kashyap Chamarthy wrote:
On Tue, May 14, 2019 at 09:56:00AM +0200, Laurent Vivier wrote:
From: Kashyap Chamarthy
When QEMU exposes a VirtIO-RNG device to the guest, that device needs a
source of entropy, and that source needs to be "non-blocking", like
`/dev/urandom`. How
On 10.05.19 17:51, Pankaj Gupta wrote:
> This patch adds virtio-pmem driver for KVM guest.
>
> Guest reads the persistent memory range information from
> Qemu over VIRTIO and registers it on nvdimm_bus. It also
> creates a nd_region object with the persistent memory
> range information so that exi
On 14.05.19 09:28, David Hildenbrand wrote:
But that can be tested using the runability information if I am not wrong.
>>>
>>> You mean the cpu level information, right?
>
> Yes, query-cpu-definition includes for each model runability information
> via "unavailable-features" (valid under t
On Tue, 14 May 2019 10:37:32 +0200
Christian Borntraeger wrote:
> On 14.05.19 09:28, David Hildenbrand wrote:
> But that can be tested using the runability information if I am not
> wrong.
> >>>
> >>> You mean the cpu level information, right?
> >
> > Yes, query-cpu-definition inc
On 14.05.19 10:37, Christian Borntraeger wrote:
>
>
> On 14.05.19 09:28, David Hildenbrand wrote:
> But that can be tested using the runability information if I am not wrong.
You mean the cpu level information, right?
>>
>> Yes, query-cpu-definition includes for each model runabilit
On Tue, May 14, 2019 at 10:04:14AM +0200, Stefano Garzarella wrote:
> On Mon, May 06, 2019 at 05:40:05PM -, Waldemar Kozaczuk wrote:
> > The last bios indeed helped. It knows runs under 200ms.
> >
> > Do you anticipate doing minor release of 3.1.0 with updated bios to address
> > this issue? O
On 14.05.19 10:49, Cornelia Huck wrote:
> On Tue, 14 May 2019 10:37:32 +0200
> Christian Borntraeger wrote:
>
>> On 14.05.19 09:28, David Hildenbrand wrote:
>> But that can be tested using the runability information if I am not
>> wrong.
>
> You mean the cpu level informatio
On 14.05.19 10:50, David Hildenbrand wrote:
> On 14.05.19 10:37, Christian Borntraeger wrote:
>>
>>
>> On 14.05.19 09:28, David Hildenbrand wrote:
>> But that can be tested using the runability information if I am not
>> wrong.
>
> You mean the cpu level information, right?
>>>
On 14.05.19 10:49, Cornelia Huck wrote:
> On Tue, 14 May 2019 10:37:32 +0200
> Christian Borntraeger wrote:
>
>> On 14.05.19 09:28, David Hildenbrand wrote:
>> But that can be tested using the runability information if I am not
>> wrong.
>
> You mean the cpu level information,
On Tue, 14 May 2019 10:56:43 +0200
Christian Borntraeger wrote:
> On 14.05.19 10:50, David Hildenbrand wrote:
> > Another idea for temporary handling: Simply only indicate 240 CPUs to
> > the guest if the response does not fit into a page. Once we have that
> > SCLP thingy, this will be fixed. G
On 14.05.19 10:56, Christian Borntraeger wrote:
>
>
> On 14.05.19 10:50, David Hildenbrand wrote:
>> On 14.05.19 10:37, Christian Borntraeger wrote:
>>>
>>>
>>> On 14.05.19 09:28, David Hildenbrand wrote:
>>> But that can be tested using the runability information if I am not
>>> wrong.
On Tue, May 14, 2019 at 06:54:03AM +0200, Markus Armbruster wrote:
> Andrew Jones writes:
>
> > On Thu, Apr 18, 2019 at 07:48:09PM +0200, Markus Armbruster wrote:
> >> Daniel P. Berrangé writes:
> >>
> >> > On Thu, Apr 18, 2019 at 11:28:41AM +0200, Andrew Jones wrote:
> >> >> Hi all,
> >> >>
>
On 14.05.19 11:00, David Hildenbrand wrote:
> On 14.05.19 10:56, Christian Borntraeger wrote:
>>
>>
>> On 14.05.19 10:50, David Hildenbrand wrote:
>>> On 14.05.19 10:37, Christian Borntraeger wrote:
On 14.05.19 09:28, David Hildenbrand wrote:
But that can be tested using
On 5/13/19 9:43 PM, Jonathan Behrens wrote:
> Signed-off-by: Jonathan Behrens
> ---
> hw/net/cadence_gem.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/hw/net/cadence_gem.c b/hw/net/cadence_gem.c
> index 7f63411430..37cb8a4e5c 100644
> --- a/hw/net/cadence_gem.c
> +++ b/hw/net/cadence
On 14.05.19 10:59, David Hildenbrand wrote:
> On 14.05.19 10:49, Cornelia Huck wrote:
>> On Tue, 14 May 2019 10:37:32 +0200
>> Christian Borntraeger wrote:
>>
>>> On 14.05.19 09:28, David Hildenbrand wrote:
>>> But that can be tested using the runability information if I am not
>>> wro
On Mon, 13 May 2019 at 19:46, Richard Henderson
wrote:
>
> On 5/12/19 1:36 AM, Andrew Jones wrote:
> >CPU type | accel | sve-max-vq | sve-vls-map
> >---
> > 1) max | tcg | $MAX_VQ | $VLS_MAP
> > 2) max | kvm | $MAX_VQ | $VLS_MAP
On 14.05.19 11:00, Cornelia Huck wrote:
> On Tue, 14 May 2019 10:56:43 +0200
> Christian Borntraeger wrote:
>
>> On 14.05.19 10:50, David Hildenbrand wrote:
>
>>> Another idea for temporary handling: Simply only indicate 240 CPUs to
>>> the guest if the response does not fit into a page. Once we
On 14.05.19 11:03, David Hildenbrand wrote:
> On 14.05.19 11:00, Cornelia Huck wrote:
>> On Tue, 14 May 2019 10:56:43 +0200
>> Christian Borntraeger wrote:
>>
>>> On 14.05.19 10:50, David Hildenbrand wrote:
>>
Another idea for temporary handling: Simply only indicate 240 CPUs to
the gues
On 14.05.19 10:59, David Hildenbrand wrote:
> On 14.05.19 10:49, Cornelia Huck wrote:
>> On Tue, 14 May 2019 10:37:32 +0200
>> Christian Borntraeger wrote:
>>
>>> On 14.05.19 09:28, David Hildenbrand wrote:
>>> But that can be tested using the runability information if I am not
>>> wro
On Mon, May 13, 2019 at 05:58:59PM +0100, Richard Henderson wrote:
> On 5/13/19 7:39 AM, Dave Martin wrote:
> > On that point, could TCG easily be made to expose a larger vector length
> > to the kernel? I'd be interested to see what happened.
>
> It would be easy enough to extend the maximum vec
On Tue, 14 May 2019 11:07:41 +0200
Christian Borntraeger wrote:
> On 14.05.19 10:59, David Hildenbrand wrote:
> > We can
> >
> > 1. Fail to start with #cpus > 240 when diag318=on
> > 2. Remove the error once we support more than one SCLP response page
> >
> > Or
> >
> > 1. Allow to start with
Hi Kenneth,
On 4/5/19 11:41 PM, Kenneth Heitke wrote:
> Signed-off-by: Kenneth Heitke
> ---
> hw/block/nvme.c | 120 +-
> hw/block/nvme.h | 3 ++
> hw/block/trace-events | 2 +
> include/block/nvme.h | 2 +
> 4 files changed, 125 inserti
On Tue, 14 May 2019 at 07:46, Cédric Le Goater wrote:
>
> This documents the overall XIVE architecture and gives an overview of
> the QEMU models. It also provides documentation on the 'info pic'
> command.
>
> Signed-off-by: Cédric Le Goater
> ---
> docs/index.rst | 1 +
> docs/ppc/index.
On 5/13/19 5:47 PM, Thomas Huth wrote:
> These functions are convenience wrappers of qtest_init() and not of
> qtest_start().
Maybe "The qtest_vinitf() and qtest_initf() functions are convenience
wrappers of qtest_init() and not of qtest_start()." as it is easier to
read the commit description in
On 14.05.19 11:10, Christian Borntraeger wrote:
>
>
> On 14.05.19 10:59, David Hildenbrand wrote:
>> On 14.05.19 10:49, Cornelia Huck wrote:
>>> On Tue, 14 May 2019 10:37:32 +0200
>>> Christian Borntraeger wrote:
>>>
On 14.05.19 09:28, David Hildenbrand wrote:
But that can be teste
On 14.05.19 11:20, David Hildenbrand wrote:
> On 14.05.19 11:10, Christian Borntraeger wrote:
>>
>>
>> On 14.05.19 10:59, David Hildenbrand wrote:
>>> On 14.05.19 10:49, Cornelia Huck wrote:
On Tue, 14 May 2019 10:37:32 +0200
Christian Borntraeger wrote:
> On 14.05.19 09:28,
On 14.05.19 11:23, Christian Borntraeger wrote:
>
>
> On 14.05.19 11:20, David Hildenbrand wrote:
>> On 14.05.19 11:10, Christian Borntraeger wrote:
>>>
>>>
>>> On 14.05.19 10:59, David Hildenbrand wrote:
On 14.05.19 10:49, Cornelia Huck wrote:
> On Tue, 14 May 2019 10:37:32 +0200
>>>
On Tue, May 14, 2019 at 08:02:49AM +0200, Markus Armbruster wrote:
> Eric Blake writes:
>
> > On 5/13/19 8:53 AM, Markus Armbruster wrote:
> >
> >>> We have a few options
> >>>
> >>> 1. Use string format for values > 2^53-1, int format below that
> >>> 2. Use string format for all fields which
On 14.05.19 11:25, Christian Borntraeger wrote:
>
>
> On 14.05.19 11:23, Christian Borntraeger wrote:
>>
>>
>> On 14.05.19 11:20, David Hildenbrand wrote:
>>> On 14.05.19 11:10, Christian Borntraeger wrote:
On 14.05.19 10:59, David Hildenbrand wrote:
> On 14.05.19 10:49, Cornel
Hi David,
Thank you for the review.
> On 10.05.19 17:51, Pankaj Gupta wrote:
> > This patch adds virtio-pmem driver for KVM guest.
> >
> > Guest reads the persistent memory range information from
> > Qemu over VIRTIO and registers it on nvdimm_bus. It also
> > creates a nd_region object with t
Hi Alex,
On 5/10/19 9:10 PM, Alex Bennée wrote:
> This is a clean-up of the semihosting calls after reading ver 2.0 of
> the specification. There are a number of small fixes that seemed too
> insignificant to split into smaller patches:
>
Can you split at least this one of:
> - fixup block co
On Tue, 14 May 2019 11:27:32 +0200
David Hildenbrand wrote:
> On 14.05.19 11:25, Christian Borntraeger wrote:
> >
> >
> > On 14.05.19 11:23, Christian Borntraeger wrote:
> >>
> >>
> >> On 14.05.19 11:20, David Hildenbrand wrote:
> >>> On 14.05.19 11:10, Christian Borntraeger wrote:
>
>>
>>> + }
>>> +
>>> + /* When host has read buffer, this completes via host_ack */
>>
>> "A host repsonse results in "host_ack" getting called" ... ?
>>
>>> + wait_event(req->host_acked, req->done);
>>> + err = req->ret;
>>> +ret:
>>> + kfree(req);
>>> + return err;
>>> +};
>>> +
>>> +
Ping
18.04.2019, 20:46, "Yury Kotov" :
> 18.04.2019, 20:01, "Dr. David Alan Gilbert" :
>> * Yury Kotov (yury-ko...@yandex-team.ru) wrote:
>>> 18.04.2019, 19:03, "Dr. David Alan Gilbert" :
>>> > * Yury Kotov (yury-ko...@yandex-team.ru) wrote:
>>> >> 18.04.2019, 17:20, "Dr. David Alan Gilber
* Daniel P. Berrangé (berra...@redhat.com) wrote:
> On Tue, May 14, 2019 at 08:02:49AM +0200, Markus Armbruster wrote:
> > Eric Blake writes:
> >
> > > On 5/13/19 8:53 AM, Markus Armbruster wrote:
> > >
> > >>> We have a few options
> > >>>
> > >>> 1. Use string format for values > 2^53-1, int f
On Tue, 14 May 2019 03:47:36 -0400
Yan Zhao wrote:
> On Tue, May 14, 2019 at 03:43:44PM +0800, Erik Skultety wrote:
> > On Tue, May 14, 2019 at 03:32:19AM -0400, Yan Zhao wrote:
> > > On Tue, May 14, 2019 at 03:20:40PM +0800, Erik Skultety wrote:
> > > > That said, from libvirt POV as a cons
On Tue, May 14, 2019 at 10:43:31 +0100, Daniel Berrange wrote:
> On Tue, May 14, 2019 at 10:37:55AM +0100, Dr. David Alan Gilbert wrote:
> > * Daniel P. Berrangé (berra...@redhat.com) wrote:
> > > On Tue, May 14, 2019 at 08:02:49AM +0200, Markus Armbruster wrote:
> > > > Eric Blake writes:
[...]
>
> >>
> >>> + }
> >>> +
> >>> + /* When host has read buffer, this completes via host_ack */
> >>
> >> "A host repsonse results in "host_ack" getting called" ... ?
> >>
> >>> + wait_event(req->host_acked, req->done);
> >>> + err = req->ret;
> >>> +ret:
> >>> + kfree(req);
> >>> + return err;
>
On Tue, May 14, 2019 at 10:37:55AM +0100, Dr. David Alan Gilbert wrote:
> * Daniel P. Berrangé (berra...@redhat.com) wrote:
> > On Tue, May 14, 2019 at 08:02:49AM +0200, Markus Armbruster wrote:
> > > Eric Blake writes:
> > >
> > > > On 5/13/19 8:53 AM, Markus Armbruster wrote:
> > > >
> > > >>>
Ping ping
17.04.2019, 15:44, "Yury Kotov" :
> Ping
>
> 08.04.2019, 14:34, "Yury Kotov" :
>> It fixes heap-use-after-free which was found by clang's ASAN.
>>
>> Control flow of this use-after-free:
>> main_thread:
>> * Got SIGTERM and completes main loop
>> * Calls migration_shutdown
>
Ping ping
17.04.2019, 15:46, "Yury Kotov" :
> Ping
>
> 04.04.2019, 13:01, "Yury Kotov" :
>> I saw Catherine Ho's patch series and it seems ok to me, but in this RFC I
>> asked
>> about a way how to detect other writes which may not be covered by
>> particular
>> fixes.
>> Perhaps this is exc
>>
>> I think you should do the same here, vdev->priv is allocated in
>> virtio_pmem_probe.
>>
>> But maybe I am missing something important here :)
>
> Because virtio_balloon use "kzalloc" for allocation and needs to be freed.
> But virtio pmem uses "devm_kzalloc" which takes care of automatical
Here are some more Kconfig patches that introduce proper config
switches for some devices in the hw/core and hw/misc directories.
Thomas Huth (4):
hw/core: Add a config switch for the "register" device
hw/core: Add a config switch for the "or-irq" device
hw/core: Add a config switch for the
The "or-irq" device is only used by certain machines. Let's add
a proper config switch for it so that it only gets compiled when we
really need it.
Signed-off-by: Thomas Huth
---
hw/arm/Kconfig| 2 ++
hw/core/Kconfig | 3 +++
hw/core/Makefile.objs | 2 +-
hw/pci-host/Kconfig | 3
The "register" device is only used by certain machines. Let's add
a proper config switch for it so that it only gets compiled when we
really need it.
Signed-off-by: Thomas Huth
---
hw/core/Kconfig | 3 +++
hw/core/Makefile.objs | 2 +-
hw/dma/Kconfig| 1 +
hw/timer/Kconfig | 1
The device is only used by certain Arm boards. Now that we have
fine-grained Kconfig for these machines, too, we can enable the
"unimplemented" devices only for the machines that really need it.
Signed-off-by: Thomas Huth
---
hw/arm/Kconfig| 9 +
hw/microblaze/Kconfig | 1 +
hw/m
On 13/05/2019 12.34, Greg Kurz wrote:
> The synth fsdriver never got used for anything else but the QTest
> testcase for VirtIO 9P. And even there, QTest uses -fsdev synth and
> -device virtio-9p-... directly.
>
> Signed-off-by: Greg Kurz
> ---
> v2: - change "no replacement" to "use '-fsdev synt
The "split-irq" device is currently only used by machines that use
CONFIG_ARMSSE. Let's add a proper CONFIG_SPLIT_IRQ switch for this
so that it only gets compiled when we really need it.
Signed-off-by: Thomas Huth
---
hw/arm/Kconfig| 1 +
hw/core/Kconfig | 3 +++
hw/core/Makefile.
On Tue, 14 May 2019 at 11:02, Thomas Huth wrote:
>
> The device is only used by certain Arm boards. Now that we have
> fine-grained Kconfig for these machines, too, we can enable the
> "unimplemented" devices only for the machines that really need it.
>
> Signed-off-by: Thomas Huth
> ---
> hw/ar
> >>
> >> I think you should do the same here, vdev->priv is allocated in
> >> virtio_pmem_probe.
> >>
> >> But maybe I am missing something important here :)
> >
> > Because virtio_balloon use "kzalloc" for allocation and needs to be freed.
> > But virtio pmem uses "devm_kzalloc" which takes ca
On Tue, 14 May 2019 at 11:00, Thomas Huth wrote:
>
> The "or-irq" device is only used by certain machines. Let's add
> a proper config switch for it so that it only gets compiled when we
> really need it.
>
> Signed-off-by: Thomas Huth
> ---
> hw/arm/Kconfig| 2 ++
> hw/core/Kconfig
On 14/05/19 12:00, Thomas Huth wrote:
> Here are some more Kconfig patches that introduce proper config
> switches for some devices in the hw/core and hw/misc directories.
>
> Thomas Huth (4):
> hw/core: Add a config switch for the "register" device
> hw/core: Add a config switch for the "or-i
Hi
On Tue, May 14, 2019 at 8:51 AM Gerd Hoffmann wrote:
>
> On Mon, May 13, 2019 at 08:33:25PM +0200, Marc-André Lureau wrote:
> > Add a vhost-user input backend example, based on virtio-input-host
> > device. It takes an evdev path as argument, and can be associated with
> > a vhost-user-input d
On 5/14/19 12:00 PM, Thomas Huth wrote:
> The "or-irq" device is only used by certain machines. Let's add
> a proper config switch for it so that it only gets compiled when we
> really need it.
>
> Signed-off-by: Thomas Huth
> ---
> hw/arm/Kconfig| 2 ++
> hw/core/Kconfig | 3 +++
>
On 14/05/2019 12.31, Philippe Mathieu-Daudé wrote:
> On 5/14/19 12:00 PM, Thomas Huth wrote:
>> The "register" device is only used by certain machines. Let's add
>> a proper config switch for it so that it only gets compiled when we
>> really need it.
>>
>> Signed-off-by: Thomas Huth
>> ---
>> hw
Add a vhost-user input backend example, based on virtio-input-host
device. It takes an evdev path as argument, and can be associated with
a vhost-user-input device via a UNIX socket:
$ vhost-user-input -p /dev/input/eventX -s /tmp/vui.sock
$ qemu ... -chardev socket,id=vuic,path=/tmp/vui.sock
-
On 5/14/19 12:00 PM, Thomas Huth wrote:
> The "register" device is only used by certain machines. Let's add
> a proper config switch for it so that it only gets compiled when we
> really need it.
>
> Signed-off-by: Thomas Huth
> ---
> hw/core/Kconfig | 3 +++
> hw/core/Makefile.objs | 2 +-
Hi,
v4:
- update "libvhost-user: fix -Werror=format= on ppc64"
v3:
- rebased, fixing some warnings found during merge
v2:
- build fixes
v1: (changes since original v6 series)
- add "libvhost-user: fix -Waddress-of-packed-member" & "util: simplify
unix_listen()"
- use unix_listen()
- build vhos
On 5/14/19 12:06 PM, Peter Maydell wrote:
> On Tue, 14 May 2019 at 11:00, Thomas Huth wrote:
>>
>> The "or-irq" device is only used by certain machines. Let's add
>> a proper config switch for it so that it only gets compiled when we
>> really need it.
>>
>> Signed-off-by: Thomas Huth
>> ---
>>
On 5/14/19 12:25 PM, Philippe Mathieu-Daudé wrote:
> On 5/14/19 12:06 PM, Peter Maydell wrote:
>> On Tue, 14 May 2019 at 11:00, Thomas Huth wrote:
>>>
>>> The "or-irq" device is only used by certain machines. Let's add
>>> a proper config switch for it so that it only gets compiled when we
>>> rea
Fixes warnings:
warning: cast to pointer from integer of different size
[-Wint-to-pointer-cast]
Signed-off-by: Marc-André Lureau
---
contrib/libvhost-user/libvhost-user.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/contrib/libvhost-user/libvhost-user.c
b/contrib/
On 14/05/2019 12.25, Philippe Mathieu-Daudé wrote:
> On 5/14/19 12:06 PM, Peter Maydell wrote:
>> On Tue, 14 May 2019 at 11:00, Thomas Huth wrote:
>>>
>>> The "or-irq" device is only used by certain machines. Let's add
>>> a proper config switch for it so that it only gets compiled when we
>>> rea
On 14/05/2019 12.35, Philippe Mathieu-Daudé wrote:
> On 5/14/19 12:00 PM, Thomas Huth wrote:
>> The "or-irq" device is only used by certain machines. Let's add
>> a proper config switch for it so that it only gets compiled when we
>> really need it.
>>
>> Signed-off-by: Thomas Huth
>> ---
>> hw/a
That should fix the following warning:
/home/pm215/qemu/contrib/libvhost-user/libvhost-user.c: In function
‘vu_set_mem_table_exec_postcopy’:
/home/pm215/qemu/contrib/libvhost-user/libvhost-user.c:666:9: error:
format ‘%llx’ expects argument of type ‘long long unsigned int’, but
argument 5 has type
On 14/05/2019 12.08, Peter Maydell wrote:
> On Tue, 14 May 2019 at 11:02, Thomas Huth wrote:
>>
>> The device is only used by certain Arm boards. Now that we have
>> fine-grained Kconfig for these machines, too, we can enable the
>> "unimplemented" devices only for the machines that really need it
On Tue, May 14, 2019 at 11:51:35AM +0200, Cornelia Huck wrote:
> On Tue, 14 May 2019 03:47:36 -0400
> Yan Zhao wrote:
>
> > On Tue, May 14, 2019 at 03:43:44PM +0800, Erik Skultety wrote:
> > > On Tue, May 14, 2019 at 03:32:19AM -0400, Yan Zhao wrote:
> > > > On Tue, May 14, 2019 at 03:20:40PM +080
* Cornelia Huck (coh...@redhat.com) wrote:
> On Tue, 14 May 2019 03:47:36 -0400
> Yan Zhao wrote:
>
> > On Tue, May 14, 2019 at 03:43:44PM +0800, Erik Skultety wrote:
> > > On Tue, May 14, 2019 at 03:32:19AM -0400, Yan Zhao wrote:
> > > > On Tue, May 14, 2019 at 03:20:40PM +0800, Erik Skultety
* Zhang, Chen (chen.zh...@intel.com) wrote:
> Hi Dave,
>
> I noticed that you have reviewed all the patches in this series, can you
> queue it?
Yes, I'm about to start a migration pull now.
Dave
> Thanks
> Zhang Chen
>
>
> > -Original Message-
> > From: Zhang, Chen
> > Sent: Friday,
On Mon, Mar 12, 2018 at 04:02:14PM +0100, Kevin Wolf wrote:
> Everything that refers to the protocol layer or QemuOpts is moved out of
> block_crypto_create_generic(), so that the remaining function is
> suitable to be called by a .bdrv_co_create implementation.
>
> LUKS is the only driver that ac
Hi
On Tue, May 14, 2019 at 7:38 AM Gerd Hoffmann wrote:
>
> Hi,
>
> > +VhostUserGpuCursorUpdate
> > +
> > +
> > ++-+---+---++
> > +| pos | hot_x | hot_y | cursor |
> > ++-+---+---++
> > +
> > +:pos: a ``VhostUserGpuCursorPos``, the
It will help to add Generic Error Data Entry to ACPI tables
without using packed C structures and avoid endianness
issues as API doesn't need explicit conversion.
Signed-off-by: Dongjiu Geng
---
hw/acpi/aml-build.c | 32
include/hw/acpi/aml-build.h | 6 +
Support this feature since version 4.1, disable it by
default in the old version.
Signed-off-by: Dongjiu Geng
---
hw/arm/virt.c | 6 ++
include/hw/arm/virt.h | 1 +
2 files changed, 7 insertions(+)
diff --git a/hw/arm/virt.c b/hw/arm/virt.c
index 5331ab7..7bdd41b 100644
--- a/hw/arm
It will help to add Hardware Error Notification to ACPI tables
without using packed C structures and avoid endianness
issues as API doesn't need explicit conversion.
Signed-off-by: Dongjiu Geng
---
hw/acpi/aml-build.c | 22 ++
include/hw/acpi/aml-build.h | 8
Add APEI/GHES detailed design document
Signed-off-by: Dongjiu Geng
---
docs/specs/acpi_hest_ghes.txt | 97 +++
1 file changed, 97 insertions(+)
create mode 100644 docs/specs/acpi_hest_ghes.txt
diff --git a/docs/specs/acpi_hest_ghes.txt b/docs/specs/acpi_
In the ARMv8 platform, the CPU error type are synchronous external
abort(SEA) and SError Interrupt (SEI). If exception happens to guest,
sometimes guest itself do the recovery is better, because host
does not know guest's detailed information. For example, if a guest
user-space application happen
Add Generic Error Status Block structures and some macros
definitions, which is referred to the ACPI 4.0 or ACPI 6.2. The
HEST table generation and CPER record will use them.
Signed-off-by: Dongjiu Geng
---
include/hw/acpi/acpi-defs.h | 52 +
1 file ch
This implements APEI GHES Table generation via fw_cfg blobs.
Now it only support GPIO-Signal and ARMv8 SEA two types of GHESv2 error
source. Afterwards, we can extend the supported types if needed. For the
CPER section type, currently it is memory section because kernel
mainly wants userspace to ha
It will help to add Generic Error Status Block to ACPI tables
without using packed C structures and avoid endianness
issues as API doesn't need explicit conversion.
Signed-off-by: Dongjiu Geng
---
hw/acpi/aml-build.c | 14 ++
include/hw/acpi/aml-build.h | 6 ++
2 files c
>
>> +void kvm_arch_on_sigbus_vcpu(CPUState *c, int code, void *addr)
>> +{
>> +ARMCPU *cpu = ARM_CPU(c);
>> +CPUARMState *env = &cpu->env;
>> +ram_addr_t ram_addr;
>> +hwaddr paddr;
>> +
>> +assert(code == BUS_MCEERR_AR || code == BUS_MCEERR_AO);
>> +
>> +if (addr) {
>>
* Peter Xu (pet...@redhat.com) wrote:
> It is error prone to use VMSTATE_UNUSED*() sometimes especially when
> the size of the migration stream of the field is not the same as the
> size of the structure (boolean is one example). Comment it well so
> people will be aware of this when people want t
Add synchronous external abort injection logic, setup
exception type and syndrome value. When switch to guest,
it will jump to the synchronous external abort vector
table entry.
The ESR_ELx.DFSC is set to synchronous external abort(0x10),
and ESR_ELx.FnV is set to not valid(0x1), which will tell
g
On Tue, 14 May 2019 12:01:45 +0100
"Dr. David Alan Gilbert" wrote:
> * Cornelia Huck (coh...@redhat.com) wrote:
> > On Tue, 14 May 2019 03:47:36 -0400
> > Yan Zhao wrote:
> > > hi Cornelia and Dave,
> > > do you also agree on:
> > > 1. "not to define the specific errno returned for a specific s
Add SIGBUS signal handler. In this handler, it checks the SIGBUS type,
translates the host VA delivered by host to guest PA, then fill this PA
to guest APEI GHES memory, then notify guest according to the SIGBUS type.
If guest accesses the poisoned memory, it generates Synchronous External
Abort(S
> From: Markus Armbruster [mailto:arm...@redhat.com]
> "Pavel Dovgalyuk" writes:
>
> > Ping.
> > Can anyone PULL these patches?
>
> Paolo?
Is there anything new?
Pavel Dovgalyuk
kvm_hwpoison_page_add() and kvm_unpoison_all() will be used both
by X86 and ARM platforms, so move these functions to a common
accel/kvm/ folder to avoid duplicate code.
Signed-off-by: Dongjiu Geng
---
accel/kvm/kvm-all.c | 33 +
include/exec/ram_addr.h | 24 +
1 - 100 of 337 matches
Mail list logo
