Has anyone at least tried this, or everybody is busy KVMforuming? :)
On 13/10/2020 13:19, Alexey Kardashevskiy wrote:
The PAPR platform which describes an OS environment that's presented by
a combination of a hypervisor and firmware. The features it specifies
require collaboration between the
On Fri, Oct 30, 2020 at 08:40:46AM +0800, Chen Qun wrote:
> When using -Wimplicit-fallthrough in our CFLAGS, the compiler showed warning:
> target/ppc/mmu_helper.c: In function ‘dump_mmu’:
> target/ppc/mmu_helper.c:1351:12: warning: this statement may fall through
> [-Wimplicit-fallthrough=]
> 13
On Fri, Oct 30, 2020 at 08:40:45AM +0800, Chen Qun wrote:
> When using -Wimplicit-fallthrough in our CFLAGS, the compiler showed warning:
> hw/ppc/ppc.c: In function ‘ppc6xx_set_irq’:
> hw/ppc/ppc.c:118:16: warning: this statement may fall through
> [-Wimplicit-fallthrough=]
> 118 |
In omap_lcd_interrupts(), the pointer omap_lcd is dereferinced before
being check if it is valid, which may lead to NULL pointer dereference.
So move the assignment to surface after checking that the omap_lcd is valid
and move surface_bits_per_pixel(surface) to after the surface assignment.
Report
On 2020/10/30 22:35, Peter Maydell wrote:
> On Fri, 30 Oct 2020 at 14:29, Peter Maydell wrote:
>>
>> On Fri, 30 Oct 2020 at 10:23, AlexChen wrote:
>>>
>>> In omap_lcd_interrupts(), the pointer omap_lcd is dereferenced before
>>> being check if it is valid, which may lead to NULL pointer dereferen
On 2020/10/30 22:28, Peter Maydell wrote:
> On Fri, 30 Oct 2020 at 10:23, AlexChen wrote:
>>
>> In exynos4210_fimd_update(), the pointer s is dereferenced before
>> being check if it is valid, which may lead to NULL pointer dereference.
>> So move the assignment to global_width after checking that
On 2020-10-30 16:02, Dr. David Alan Gilbert wrote:
* Tobin Feldman-Fitzthum (to...@linux.ibm.com) wrote:
Hello,
Dov Murik, James Bottomley, Hubertus Franke, and I have been working
on a
plan for fast live migration with SEV and SEV-ES. We just posted an
RFC
about it to the edk2 list. It inclu
On Fri, Oct 30, 2020 at 09:41:46PM +0100, Paolo Bonzini wrote:
> Il ven 30 ott 2020, 21:03 Eduardo Habkost ha scritto:
>
> > > OBJECT_CLASS_PROPERTY_ADD_STR(oc, MachineState, kernel_filename,
> > > "kernel", prop_allow_set_always);
> >
> > I like the idea of
Il ven 30 ott 2020, 21:03 Eduardo Habkost ha scritto:
> > OBJECT_CLASS_PROPERTY_ADD_STR(oc, MachineState, kernel_filename,
> > "kernel", prop_allow_set_always);
>
> I like the idea of having an interface like this, but I would
> like to avoid having to write
object_property_parse() will add a
"Property '.' can't take value ''"
prefix automatically for us.
Signed-off-by: Eduardo Habkost
---
Cc: Jason Wang
Cc: qemu-devel@nongnu.org
---
net/filter-buffer.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/net/filter-buffer.c b/ne
object_property_parse() will add a
"Property '.' can't take value ''"
prefix automatically for us.
Signed-off-by: Eduardo Habkost
---
Cc: Zhang Chen
Cc: Li Zhijian
Cc: Jason Wang
Cc: qemu-devel@nongnu.org
---
net/colo-compare.c | 9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
object_property_parse() will add a
"Property '.' can't take value ''"
prefix automatically for us.
Signed-off-by: Eduardo Habkost
---
Cc: Paolo Bonzini
Cc: Richard Henderson
Cc: Eduardo Habkost
Cc: qemu-devel@nongnu.org
---
target/i386/cpu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletio
object_property_parse() will add a
"Property '.' can't take value ''"
prefix automatically for us.
Signed-off-by: Eduardo Habkost
---
Cc: Stefan Berger
Cc: qemu-devel@nongnu.org
---
backends/tpm/tpm_util.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/backends/tpm/tpm_
When checking for allocation across a chain, it's already easy to
count the depth within the chain at which the allocation is found.
Instead of throwing that information away, return it to the caller.
Existing callers only cared about allocated/non-allocated, but having
a depth available will be us
object_property_parse() will add a
"Property '.' can't take value ''"
prefix automatically for us.
Signed-off-by: Eduardo Habkost
---
Cc: "Gonglei (Arei)"
Cc: qemu-devel@nongnu.org
---
backends/cryptodev.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/backends/cryptode
The following changes since commit 9a2ea4f4a7230fe224dee91d9adf2ef872c3d226:
Merge remote-tracking branch
'remotes/vivier2/tags/trivial-branch-for-5.2-pull-request' into staging
(2020-10-30 15:49:35 +)
are available in the Git repository at:
https://repo.or.cz/qemu/ericb.git tags/pull-
Just setting a reasonable error string using error_setg() is
simpler and makes error messages clearer.
Before:
$ qemu-system-s390x -device x-terminal3270,devno=x
qemu-system-s390x: -device x-terminal3270,devno=x: Property
'x-terminal3270.devno' doesn't take value 'x'
After:
$ qemu-system
Signed-off-by: Eduardo Habkost
---
Cc: Paolo Bonzini
Cc: "Daniel P. Berrangé"
Cc: Eduardo Habkost
Cc: qemu-devel@nongnu.org
---
include/hw/qdev-properties.h | 2 --
hw/core/qdev-properties.c| 22 --
2 files changed, 24 deletions(-)
diff --git a/include/hw/qdev-propert
All existing "Property '.' ..." error messages were
rewritten, we can now add the error message prefix unconditionally.
Signed-off-by: Eduardo Habkost
---
Cc: Paolo Bonzini
Cc: "Daniel P. Berrangé"
Cc: Eduardo Habkost
Cc: qemu-devel@nongnu.org
---
qom/object.c | 10 ++
1 file changed,
object_property_parse() will add a
"Property '.' can't take value ''"
prefix automatically for us.
Signed-off-by: Eduardo Habkost
---
Cc: Xiao Guangrong
Cc: "Michael S. Tsirkin"
Cc: Igor Mammedov
Cc: qemu-devel@nongnu.org
---
hw/mem/nvdimm.c | 6 ++
1 file changed, 2 insertions(+), 4 de
Just setting a reasonable error string using error_setg() is
simpler and makes error messages clearer.
Before:
$ qemu-system-x86_64 -device vfio-pci,host=x
qemu-system-x86_64: -device vfio-pci,host=x: Property 'vfio-pci.host' doesn't
take value 'x'
After:
$ qemu-system-x86_64 -device vfi
Signed-off-by: Eduardo Habkost
---
Cc: Markus Armbruster
Cc: qemu-devel@nongnu.org
---
include/qapi/qmp/qerror.h | 3 ---
1 file changed, 3 deletions(-)
diff --git a/include/qapi/qmp/qerror.h b/include/qapi/qmp/qerror.h
index 7c76e24aa7..646a42c4b4 100644
--- a/include/qapi/qmp/qerror.h
+++ b/i
object_property_parse() will add a
"Property '.' can't take value ''"
prefix automatically for us.
Signed-off-by: Eduardo Habkost
---
Cc: Paolo Bonzini
Cc: "Daniel P. Berrangé"
Cc: Eduardo Habkost
Cc: qemu-devel@nongnu.org
---
hw/core/qdev-properties-system.c | 8 +++-
1 file changed, 3
object_property_parse() will add a
"Property '.' can't take value ''"
prefix automatically for us.
Signed-off-by: Eduardo Habkost
---
Cc: Jason Wang
Cc: qemu-devel@nongnu.org
---
net/dump.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/net/dump.c b/net/dump.c
index 7fd
object_property_parse() will add a
"Property '.' can't take value ''"
prefix automatically for us.
Signed-off-by: Eduardo Habkost
---
Cc: Paolo Bonzini
Cc: "Daniel P. Berrangé"
Cc: Eduardo Habkost
Cc: qemu-devel@nongnu.org
---
hw/core/qdev-properties-system.c | 3 +--
1 file changed, 1 inse
Just setting a reasonable error string using error_setg() is
simpler and makes error messages clearer.
Before:
$ qemu-system-x86_64 -device e1000,addr=x
qemu-system-x86_64: -device e1000,addr=x: Property 'e1000.addr' doesn't take
value 'x'
After:
$ qemu-system-x86_64 -device e1000,addr=x
object_property_parse() will add a
"Property '.' can't take value ''"
prefix automatically for us.
Signed-off-by: Eduardo Habkost
---
Cc: Eduardo Habkost
Cc: Igor Mammedov
Cc: qemu-devel@nongnu.org
---
backends/hostmem-memfd.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --g
Just setting a reasonable error string using error_setg() is
simpler and makes error messages clearer.
Before:
$ qemu-system-x86_64 -device e1000,netdev=n0
qemu-system-x86_64: -device e1000,netdev=n0: Property 'e1000.netdev' can't
find value 'n0'
$ qemu-system-x86_64 -netdev id=n0,type=use
Make object_property_parse() automatically add a error message
prefix mentioning the QOM type and property name when
encountering errors.
As we have a large number of functions that add their own
"Property '...'" to the error messages, add a temporary check for
existing prefixes before prepending
Just setting a reasonable error string using error_setg() is
simpler and makes error messages clearer.
Before:
$ qemu-system-x86_64 -device e1000,mac=x
qemu-system-x86_64: -device e1000,mac=x: Property 'e1000.mac' doesn't take
value 'x'
After:
$ qemu-system-x86_64 -device e1000,mac=x
q
Just setting a reasonable error string using error_setg() is
simpler and makes error messages clearer.
Before:
$ qemu-system-x86_64 -device AC97,audiodev=a0
qemu-system-x86_64: -device AC97,audiodev=a0: Property 'AC97.audiodev' can't
find value 'a0'
After:
$ ./qemu-system-x86_64 -device
Based-on: 20201029220246.472693-1-ehabk...@redhat.com
Git branch: https://gitlab.com/ehabkost/qemu/-/commits/work/prop-error-reporting
One of the obstacles when refactoring the QOM property parsing
code are the references to the object itself in the error code,
to generate "Property '.' can't take
On 10/27/20 4:59 PM, Eric Blake wrote:
> The following changes since commit 725ca3313a5b9cbef89eaa1c728567684f37990a:
>
> Merge remote-tracking branch
> 'remotes/dgilbert-gitlab/tags/pull-virtiofs-20201026' into staging
> (2020-10-27 14:29:52 +)
>
> are available in the Git repository at:
On Fri, Oct 30, 2020 at 06:10:34PM +0100, Paolo Bonzini wrote:
> On 29/10/20 23:02, Eduardo Habkost wrote:
> > +static Property machine_props[] = {
> > +DEFINE_PROP_STRING("kernel", MachineState, kernel_filename),
> > +DEFINE_PROP_STRING("initrd", MachineState, initrd_filename),
> > +DE
On Fri, 30 Oct 2020 at 19:12, Peter Maydell wrote:
>
> On Fri, 30 Oct 2020 at 18:20, Paolo Bonzini wrote:
> >
> > On 30/10/20 18:46, Peter Maydell wrote:
> > >
> > > This does mean our kernel-doc gets another patch that makes
> > > it diverge a little from the kernel's version, but we already
> >
* Tobin Feldman-Fitzthum (to...@linux.ibm.com) wrote:
> Hello,
>
> Dov Murik, James Bottomley, Hubertus Franke, and I have been working on a
> plan for fast live migration with SEV and SEV-ES. We just posted an RFC
> about it to the edk2 list. It includes a proof-of-concept for what we feel
> to b
Public bug reported:
Some stubborn software requires certain VID/PID/Serial to authenticate
and refuses to start in emulation. This poses a problem with unsupported
programs which often require keeping an ancient hardware praying that
the USB stick will not die before the (often defunct) company m
On Tue, 27 Oct 2020 at 16:33, Laurent Vivier wrote:
>
> The following changes since commit 4c5b97bfd0dd54dc27717ae8d1cd10e14eef1430:
>
> Merge remote-tracking branch 'remotes/kraxel/tags/modules-20201022-pull-req=
> uest' into staging (2020-10-22 12:33:21 +0100)
>
> are available in the Git repo
On 10/22/20 9:44 AM, Peter Maydell wrote:
> In arm_v7m_mmu_idx_for_secstate() we get the 'priv' level to pass to
> armv7m_mmu_idx_for_secstate_and_priv() by calling arm_current_el().
> This is incorrect when the security state being queried is not the
> current one, because arm_current_el() uses th
On Thu, Oct 15, 2020 at 2:39 PM Felipe Franciosi wrote:
> > On Oct 13, 2020, at 10:30 AM, Stefan Hajnoczi wrote:>
> > >
> > On Fri, Oct 02, 2020 at 10:14:23AM +, Felipe Franciosi wrote:
> >>> On Sep 30, 2020, at 3:24 PM, Stefan Hajnoczi wrote:
> >>> On Tue, Sep 29, 2020 at 09:21:54AM -0700,
On Fri, 30 Oct 2020 at 18:20, Paolo Bonzini wrote:
>
> On 30/10/20 18:46, Peter Maydell wrote:
> >
> > This does mean our kernel-doc gets another patch that makes
> > it diverge a little from the kernel's version, but we already
> > have one of those (commit 152d1967f650f67b7e). I do want to
> > t
On 10/30/20 11:26 AM, Paolo Bonzini wrote:
> On 30/10/20 01:49, Richard Henderson wrote:
>> Fourth, I have renamed the command-line parameter to "split-rwx".
>
> Stupid observation, but wouldn't it be "split-wx"?
Um, yes. ;-)
r~
On 10/30/20 8:15 AM, r...@remlab.net wrote:
> From: Rémi Denis-Courmont
>
> When booting a CPU with EL3 using the -kernel flag, set up CPTR_EL3 so
> that SVE will not trap to EL3.
>
> Signed-off-by: Rémi Denis-Courmont
> ---
> hw/arm/boot.c | 3 +++
> 1 file changed, 3 insertions(+)
Reviewed-
On 10/30/20 6:49 AM, Philippe Mathieu-Daudé wrote:
> As load_device_tree() returns allocated memory,
> we need to free it.
>
> Cc: Yoshinori Sato
> Fixes: bda19d7bb56 ("hw/rx: Add RX GDB simulator")
> Reported-by: Coverity (CID 1432307: RESOURCE_LEAK)
> Signed-off-by: Philippe Mathieu-Daudé
> --
On 10/30/20 2:31 AM, Thomas Huth wrote:
> Looking at the way the code is formatted here (there is an empty
> line after break statements, but none where the break is missing),
> the fallthrough is very likely intended here. So add a fallthrough
> comment to make the it compilable with -Werror=impli
On 30/10/20 01:49, Richard Henderson wrote:
> Fourth, I have renamed the command-line parameter to "split-rwx".
Stupid observation, but wouldn't it be "split-wx"?
Thanks,
Paolo
> I don't think this is perfect, and I'm not even sure if it's better
> than "mirror-jit". What this has done, though
On 30/10/20 18:46, Peter Maydell wrote:
>
> This does mean our kernel-doc gets another patch that makes
> it diverge a little from the kernel's version, but we already
> have one of those (commit 152d1967f650f67b7e). I do want to
> try to upstream these to the kernel, but that will require
> more
On 30/10/20 18:26, Alex Williamson wrote:
>>
>> if (try_unmap) {
>> +if (llsize == int128_2_64()) {
>> +/* The unmap ioctl doesn't accept a full 64-bit span. */
>> +llsize = int128_rshift(llsize, 1);
>> +ret = vfio_dma_unmap(container, iova, int128
IOMMUs may declare memory regions spanning from 0 to UINT64_MAX. When
attempting to deal with such region, vfio_listener_region_del() passes a
size of 2^64 to int128_get64() which throws an assertion failure. Even
ignoring this, the VFIO_IOMMU_DMA_MAP ioctl cannot handle this size
since the size f
From: Bharat Bhushan
Extend VIRTIO_IOMMU_T_MAP/UNMAP request to notify memory listeners. It
will call VFIO notifier to map/unmap regions in the physical IOMMU.
Signed-off-by: Bharat Bhushan
Signed-off-by: Eric Auger
Signed-off-by: Jean-Philippe Brucker
---
v11:
* Forward permissions from the
From: Bharat Bhushan
The virtio-iommu device can deal with arbitrary page sizes for virtual
endpoints, but for endpoints assigned with VFIO it must follow the page
granule used by the host IOMMU driver.
Implement the interface to set the vIOMMU page size mask, called by VFIO
for each endpoint. W
From: Bharat Bhushan
Allow to set the page size mask supported by an iommu memory region.
This enables a vIOMMU to communicate the page size granule supported by
an assigned device, on hosts that use page sizes greater than 4kB.
Acked-by: Peter Xu
Reviewed-by: Eric Auger
Signed-off-by: Bharat
Due to an invalid mask, virtio_iommu_mr() may return the wrong memory
region. It hasn't been too problematic so far because the function was
only used to test existence of an endpoint, but that is about to change.
Fixes: cfb42188b24d ("virtio-iommu: Implement attach/detach command")
Cc: QEMU Stabl
Store the memory region associated to each endpoint into the endpoint
structure, to allow efficient memory notification on map/unmap.
Acked-by: Eric Auger
Signed-off-by: Jean-Philippe Brucker
---
hw/virtio/virtio-iommu.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --
From: Bharat Bhushan
Set IOMMU supported page size mask same as host Linux supported page
size mask.
Acked-by: Alex Williamson
Reviewed-by: Eric Auger
Signed-off-by: Bharat Bhushan
Signed-off-by: Jean-Philippe Brucker
---
---
hw/vfio/common.c | 8
1 file changed, 8 insertions(+)
d
This series adds support for VFIO endpoints to virtio-iommu.
Since [v10] I addressed the review comments, and changed the logic of
patch 9 for setting the page mask, as discussed. Please see individual
changelogs for details.
[v10]
https://lore.kernel.org/qemu-devel/20201008171558.410886-1-jean-p
From: Bharat Bhushan
Call the memory notifiers when attaching an endpoint to a domain, to
replay existing mappings, and when detaching the endpoint, to remove all
mappings.
Signed-off-by: Bharat Bhushan
Signed-off-by: Jean-Philippe Brucker
---
v11: Pass mapping permissions to the notifiers
---
From: Bharat Bhushan
Add notify_flag_changed() to notice when memory listeners are added and
removed.
Acked-by: Eric Auger
Signed-off-by: Bharat Bhushan
Signed-off-by: Jean-Philippe Brucker
---
v11: improve tracepoint string
---
hw/virtio/virtio-iommu.c | 14 ++
hw/virtio/trace-e
From: Bharat Bhushan
Implement the replay callback to setup all mappings for a new memory
region.
Signed-off-by: Bharat Bhushan
Signed-off-by: Jean-Philippe Brucker
---
v11: Don't notify unmap before map, add permission flags
---
hw/virtio/virtio-iommu.c | 40 +
Hello,
Dov Murik, James Bottomley, Hubertus Franke, and I have been working on
a plan for fast live migration with SEV and SEV-ES. We just posted an
RFC about it to the edk2 list. It includes a proof-of-concept for what
we feel to be the most difficult part of fast live migration with SEV-ES.
On Fri, Oct 30, 2020 at 05:46:59PM +, Peter Maydell wrote:
> The kerneldoc script currently emits Sphinx markup for a macro with
> arguments that uses the c:function directive. This is correct for
> Sphinx versions earlier than Sphinx 3, where c:macro doesn't allow
> documentation of macros wit
On Fri, Oct 30, 2020 at 05:47:00PM +, Peter Maydell wrote:
> Sphinx 3.2 is pickier than earlier versions about the option:: markup,
> and complains about our usage in qemu-option-trace.rst:
>
> ../../docs/qemu-option-trace.rst.inc:4:Malformed option description
> '[enable=]PATTERN', should l
Sphinx 3.2 is pickier than earlier versions about the option:: markup,
and complains about our usage in qemu-option-trace.rst:
../../docs/qemu-option-trace.rst.inc:4:Malformed option description
'[enable=]PATTERN', should look like "opt", "-opt args", "--opt args",
"/opt args" or "+opt args"
This patchseries fixes some issues with building our docs
with Sphinx 3.2:
* kerneldoc was using the 'c:function' directive for both
functions and macros, but Sphinx 3.2 wants 'c:macro' for
macros and complains if the argument to 'c:function' isn't
parseable as a function declaration
* q
The kerneldoc script currently emits Sphinx markup for a macro with
arguments that uses the c:function directive. This is correct for
Sphinx versions earlier than Sphinx 3, where c:macro doesn't allow
documentation of macros with arguments and c:function is not picky
about the syntax of what it is
On Fri, 30 Oct 2020 06:25:34 -0400
"Michael S. Tsirkin" wrote:
> On Thu, Oct 08, 2020 at 03:22:14PM -0600, Alex Williamson wrote:
> > On Thu, 8 Oct 2020 19:15:58 +0200
> > Jean-Philippe Brucker wrote:
> >
> > > IOMMUs may declare memory regions spanning from 0 to UINT64_MAX. When
> > > attem
On Fri, Oct 30, 2020 at 11:32:38AM +0900, Dmitry Fomichev wrote:
> The emulation code has been changed to advertise NVM Command Set when
> "zoned" device property is not set (default) and Zoned Namespace
> Command Set otherwise.
>
> Define values and structures that are needed to support Zoned
> N
On 30/10/20 12:35, Eduardo Habkost wrote:
>
> What is necessary to make sure we have a CONFIG_XEN=y job in
> gitlab CI? Maybe just including xen-devel in some of the
> container images is enough?
Fedora already has it, but build-system-fedora does not include
x86_64-softmmu.
Paolo
On 29/10/20 23:02, Eduardo Habkost wrote:
> +static Property machine_props[] = {
> +DEFINE_PROP_STRING("kernel", MachineState, kernel_filename),
> +DEFINE_PROP_STRING("initrd", MachineState, initrd_filename),
> +DEFINE_PROP_STRING("append", MachineState, kernel_cmdline),
> +DEFINE_P
On Fri, Oct 30, 2020 at 2:22 AM Eduardo Habkost wrote:
> Just setting a reasonable error string using error_setg() is
> simpler and makes error messages clearer.
>
> Before:
>
> $ qemu-system-x86_64 -device vmgenid,guid=x
> qemu-system-x86_64: -device vmgenid,guid=x: Property 'vmgenid.guid'
>
On Wed, Oct 28, 2020 at 04:41:31PM +, Thanos Makatos wrote:
> FYI here's v5 of the vfio-user protocol, my --cc in git send-email got messed
> up somehow
Hi Thanos, this looks great, I just had some minor questions below.
> Command Concurrency
> ---
> A client may pipeline mu
On Fri, Oct 30, 2020 at 2:19 AM Eduardo Habkost wrote:
> The basic property types in qdev-properties.c are not going to be
> qdev-specific anymore. Rename the variables to prop_info_*.
>
> Signed-off-by: Eduardo Habkost
>
Reviewed-by: Marc-André Lureau
> ---
> Cc: Paolo Bonzini
> Cc: "Dani
On Fri, Oct 30, 2020 at 2:24 AM Eduardo Habkost wrote:
> Move the variable declaration close to the macro that uses it.
>
> Signed-off-by: Eduardo Habkost
>
Reviewed-by: Marc-André Lureau
> ---
> Cc: Stefan Berger
> Cc: Paolo Bonzini
> Cc: "Daniel P. Berrangé"
> Cc: Eduardo Habkost
> Cc:
On Fri, Oct 30, 2020 at 2:17 AM Eduardo Habkost wrote:
> Move the core of the static property code to qom/static-property.c.
>
> The actual property type implementations are still in
> qdev-properties.c, they will be moved later.
>
> Signed-off-by: Eduardo Habkost
>
>
Reviewed-by: Marc-André Lur
On Fri, Oct 30, 2020 at 2:23 AM Eduardo Habkost wrote:
> Instead of duplicating the code that sets name, info, offset,
> and does type checking, make DEFINE_PROP accept a variable number
> of arguments and reuse it in all DEFINE_PROP_* macros.
>
> Signed-off-by: Eduardo Habkost
>
neat! and clev
On Fri, Oct 30, 2020 at 2:17 AM Eduardo Habkost wrote:
> Move the property types and property macros implemented in
> qdev-properties-system.c to a new qdev-properties-system.h
> header.
>
> Signed-off-by: Eduardo Habkost
>
Reviewed-by: Marc-André Lureau
> ---
> audio/audio.h
On Fri, Oct 30, 2020 at 2:20 AM Eduardo Habkost wrote:
> There are no users of the function outside qdev-properties.c.
> Make function static and rename it to get_uint16().
>
> Signed-off-by: Eduardo Habkost
>
Reviewed-by: Marc-André Lureau
> ---
> Cc: Paolo Bonzini
> Cc: "Daniel P. Berrang
On Fri, Oct 30, 2020 at 2:14 AM Eduardo Habkost wrote:
> Signed-off-by: Eduardo Habkost
>
Reviewed-by: Marc-André Lureau
> ---
> Cc: Paolo Bonzini
> Cc: "Daniel P. Berrangé"
> Cc: Eduardo Habkost
> Cc: qemu-devel@nongnu.org
> ---
> include/hw/qdev-properties.h | 2 +-
> hw/core/qdev-pr
On Fri, Oct 30, 2020 at 2:13 AM Eduardo Habkost wrote:
> These functions will be moved to be part of QOM, so rename them.
>
> Signed-off-by: Eduardo Habkost
>
Reviewed-by: Marc-André Lureau
> ---
> Cc: Paolo Bonzini
> Cc: "Daniel P. Berrangé"
> Cc: Eduardo Habkost
> Cc: qemu-devel@nongnu
On Fri, Oct 30, 2020 at 2:12 AM Eduardo Habkost wrote:
> Note that this doesn't replace the check callback at
> object*_property_add_link() (yet), because currently the link
> property check callback needs to get the property value as
> argument (despite this not being necessary in most cases).
>
On Fri, Oct 30, 2020 at 2:15 AM Eduardo Habkost wrote:
> This removes the last remaining DeviceState-specific line of code
> inside qdev property registration code, and will allow us to make
> static properties a core QOM feature.
>
> Signed-off-by: Eduardo Habkost
>
Reviewed-by: Marc-André Lu
A connecting chardev object has an additional reference by the connecting
thread, so if the chardev is still connecting by the end of the test,
then the chardev object won't be freed. This in turn means that the yank
instance won't be unregistered and when running the next test-case
yank_register_i
Migration and yank code assume that qio_channel_shutdown is thread
-safe and can be called from qmp oob handler. Document this after
checking the code.
Signed-off-by: Lukas Straub
Acked-by: Stefan Hajnoczi
Reviewed-by: Daniel P. Berrangé
---
include/io/channel.h | 5 -
1 file changed, 4 in
I'll maintain this for now as the colo usecase is the first user
of this functionality.
Signed-off-by: Lukas Straub
Acked-by: Stefan Hajnoczi
---
MAINTAINERS | 7 +++
1 file changed, 7 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 8c744a9bdf..81288fd219 100644
--- a/MAINTAINER
Register a yank function to shutdown the socket on yank.
Signed-off-by: Lukas Straub
Acked-by: Stefan Hajnoczi
---
chardev/char-socket.c | 35 +++
1 file changed, 35 insertions(+)
diff --git a/chardev/char-socket.c b/chardev/char-socket.c
index 95e45812d5..5947c
Register yank functions on sockets to shut them down.
Signed-off-by: Lukas Straub
Acked-by: Stefan Hajnoczi
Acked-by: Dr. David Alan Gilbert
---
migration/channel.c | 13 +
migration/migration.c | 25 +
migration/multifd.c | 10 ++
Make qio_channel_tls_shutdown thread-safe by using atomics when
accessing tioc->shutdown.
Signed-off-by: Lukas Straub
Acked-by: Stefan Hajnoczi
Reviewed-by: Daniel P. Berrangé
---
io/channel-tls.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/io/channel-tls.c b/io/c
The yank feature allows to recover from hanging qemu by "yanking"
at various parts. Other qemu systems can register themselves and
multiple yank functions. Then all yank functions for selected
instances can be called by the 'yank' out-of-band qmp command.
Available instances can be queried by a 'qu
Register a yank function which shuts down the socket and sets
s->state = NBD_CLIENT_QUIT. This is the same behaviour as if an
error occured.
Signed-off-by: Lukas Straub
Acked-by: Stefan Hajnoczi
---
block/nbd.c | 154 +++-
1 file changed, 93 inser
Hello Everyone,
So here is v10.
We still need ACKs from NBD and chardev maintainers.
Changes:
v10:
-moved from qapi/misc.json to qapi/yank.json
-rename 'blockdev' -> 'block-node'
-document difference betwen migration yank instance and migrate_cancel
-better document return values of yank comm
** Attachment removed: "my operating system"
https://bugs.launchpad.net/qemu/+bug/1902267/+attachment/5429520/+files/FLATDOS.IMG
** Attachment added: "my operating system"
https://bugs.launchpad.net/qemu/+bug/1902267/+attachment/5429530/+files/FLATDOS.IMG
--
You received this bug notific
On 10/30/20 1:36 AM, Pavel Dovgalyuk wrote:
> This patch adds some gen_io_start() calls to allow execution
> of s390x targets in icount mode with -smp 1.
> It enables deterministic timers and record/replay features.
Thanks for pointing this out.
There are enough of these that I think it would be
Public bug reported:
QEMU version 5.0.0 supports 32-bit and 16-bit unreal mode. Great!
Unfortunately, QEMU does not support 32-bit stack in unreal 32-bit mode.
After the INT instruction, the stack is switched to 16-bit, which should not be
the case.
At BOCHS, my code works 100%. At QEMU not work
* Philippe Mathieu-Daudé (phi...@redhat.com) wrote:
> Since commit 6f5fd837889, vu_init() can fail if malloc() returns NULL.
>
> This fixes the following Coverity warning:
>
> CID 1435958 (#1 of 1): Unchecked return value (CHECKED_RETURN)
>
> Fixes: 6f5fd837889 ("libvhost-user: support many v
Public bug reported:
Qemu version 4.2.1
In the function of virtio_load, the vmstate_load_state will return error
in the following case.
The virtio is legacy mode(disable-modern=on,disable-legacy=off),
virtio_device is in reset state.
In the the function of "vmstate_load_state", it will load all
On 10/30/20 3:33 PM, Peter Maydell wrote:
> On Mon, 19 Oct 2020 at 09:23, Philippe Mathieu-Daudé wrote:
>>
>> Since commit aa35ec2213b ("hw/arm/raspi: Use more
>> specific machine names") the raspi2/raspi3 machines
>> have been renamed as raspi2b/raspi3b.
>>
>> As more Raspberry Pi 2/3 models are
On Tue, 27 Oct 2020 at 15:15, Kevin Wolf wrote:
>
> The following changes since commit d55450df995d6223486db11c66491cbf6c131523:
>
> Merge remote-tracking branch
> 'remotes/dgilbert/tags/pull-migration-20201026a' into staging (2020-10-27
> 10:25:42 +)
>
> are available in the Git repositor
On Fri, Oct 30, 2020 at 6:34 AM Peter Maydell wrote:
>
> On Fri, 23 Oct 2020 at 22:06, Havard Skinnemoen
> wrote:
> >
> > The RNG module returns a byte of randomness when the Data Valid bit is
> > set.
> >
> > This implementation ignores the prescaler setting, and loads a new value
> > into RNGD
On 30/10/2020 01.40, Chen Qun wrote:
> When using -Wimplicit-fallthrough in our CFLAGS, the compiler showed warning:
> target/ppc/mmu_helper.c: In function ‘dump_mmu’:
> target/ppc/mmu_helper.c:1351:12: warning: this statement may fall through
> [-Wimplicit-fallthrough=]
> 1351 | if (ppc6
On 30/10/2020 01.40, Chen Qun wrote:
> When using -Wimplicit-fallthrough in our CFLAGS, the compiler showed warning:
> hw/ppc/ppc.c: In function ‘ppc6xx_set_irq’:
> hw/ppc/ppc.c:118:16: warning: this statement may fall through
> [-Wimplicit-fallthrough=]
> 118 | if (level) {
>
1 - 100 of 312 matches
Mail list logo
