This patch fixes the checking of boundary crossing instructions.
In icount mode only first instruction of the block may cross
the page boundary to keep the translation deterministic.
These conditions already existed, but compared the wrong variable.
Signed-off-by: Pavel Dovgalyuk
---
target/i386
On Wed, 09/19 23:51, Fam Zheng wrote:
> > diff --git a/hw/rdma/rdma_backend.c b/hw/rdma/rdma_backend.c
> > index d7a4bbd91f..e7cbb0c368 100644
> > --- a/hw/rdma/rdma_backend.c
> > +++ b/hw/rdma/rdma_backend.c
> > @@ -165,7 +165,8 @@ static void start_comp_thread(RdmaBackendDev
> > *backend_dev)
>
On Thu, 2018-09-20 at 00:07 -0300, Eduardo Habkost wrote:
> Hi,
>
> Thanks for the patch and sorry for taking so long to review it.
Never mind. I understand you're really busy. :-)
>
> On Sun, Sep 02, 2018 at 07:46:06PM +0800, Robert Hoo wrote:
> > Add kvm_get_supported_feature_msrs() to get sup
On 2018-09-20 08:07, Markus Armbruster wrote:
> Thomas Huth writes:
>
>> In early times, network backends were specified by a "vlan" and "name"
>> tuple. With the introduction of netdevs, the "name" was replaced by an
>> "id" (which is supposed to be unique), but the "name" parameter stayed
>> as
On Thu, Sep 20, 2018 at 10:59:56AM +0800, Peter Xu wrote:
> On Wed, Sep 19, 2018 at 04:58:06PM +0200, Wolfgang Bumiller wrote:
> > On Wed, Sep 19, 2018 at 03:36:02PM +0200, Markus Armbruster wrote:
> > > Peter Xu writes:
> > > > Indeed. So we have these ordering constraints:
> > > >
> > > > ini
On Thu, Sep 20, 2018 at 10:02:22AM +0200, Wolfgang Bumiller wrote:
> On Thu, Sep 20, 2018 at 10:59:56AM +0800, Peter Xu wrote:
> > On Wed, Sep 19, 2018 at 04:58:06PM +0200, Wolfgang Bumiller wrote:
> > > On Wed, Sep 19, 2018 at 03:36:02PM +0200, Markus Armbruster wrote:
> > > > Peter Xu writes:
>
On Thu, Sep 20, 2018 at 04:10:00PM +0800, Peter Xu wrote:
> On Thu, Sep 20, 2018 at 10:02:22AM +0200, Wolfgang Bumiller wrote:
> > On Thu, Sep 20, 2018 at 10:59:56AM +0800, Peter Xu wrote:
> > > On Wed, Sep 19, 2018 at 04:58:06PM +0200, Wolfgang Bumiller wrote:
> > > > On Wed, Sep 19, 2018 at 03:36
Make sure that the docs get correctly regenerated when the
file qemu-deprecated.texi has been changed.
Fixes: 44c67847e32c91a6071fb0440c357b9489f08bc6
Signed-off-by: Thomas Huth
---
Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Makefile b/Makefile
index fe623e4..f4
Commit 16f7244842b5135543ef068a1adafd94c6965953 added this parameter
to the documentation, including a note that it is deprecated. But it
has never been added to the "Deprecated features" appendix, which is
our official way to deprecate legacy parameters. So let's do this now.
Signed-off-by: Thoma
In early times, network backends were specified by a "vlan" and "name"
tuple. With the introduction of netdevs, the "name" was replaced by an
"id" (which is supposed to be unique), but the "name" parameter stayed
as an alias which could be used instead of "id". Unfortunately, we miss
the duplicati
The "name" in the [hub_id name] parameter tuple is the same as a
"netdev_id" (which should be unique), so specifying the hub_id here
is just redundant (it was likely just necessary in the past when
the network subsystem was still using "vlans" only and when it did
not use unique "id"s yet).
Signed
Deprecate the "name" parameter for -net, and "enforce-config-section" of
-machine.
v2:
- Split the single net patch into multiple smaller patches
- Add patch to deprecate enforce-config-section
Thomas Huth (4):
Makefile: Add missing dependency for qemu-deprecated.texi
net: Deprecate the "na
On Thu, Sep 20, 2018 at 04:10:00PM +0800, Peter Xu wrote:
> On Thu, Sep 20, 2018 at 10:02:22AM +0200, Wolfgang Bumiller wrote:
>
> > Either way, spawning the iothread on demand can still make sense, as
> > does updating the check in resume()/suspend().
>
> Yep.
Running into an issue with that ap
* Eduardo Habkost (ehabk...@redhat.com) wrote:
> On Wed, Sep 19, 2018 at 08:15:25PM +0100, Dr. David Alan Gilbert wrote:
> > * Igor Mammedov (imamm...@redhat.com) wrote:
> > > On Wed, 19 Sep 2018 13:14:05 +0100
> > > "Dr. David Alan Gilbert" wrote:
> > >
> > > > * Igor Mammedov (imamm...@redhat.c
dcbz was broken with the refactoring introduced in the External PID patch. The
GETPC() call is moved directly to the helper in this patch, to report correct PC
address. The issue did not always manifest: if the compiler decided to inline
the call, the PC wound up being correct. So in order to repro
ping http://patchwork.ozlabs.org/patch/961849/
On 08/24/2018 03:17 PM, Roman Kapl wrote:
The TCG backend uses LOWREGMASK to get the low 7 bits of register numbers. This
was defined as no-op for 32-bit x86, with the assumption that we have eight
registers anyway. This assumption is not true once
On Thu, 2018-09-20 at 00:13 -0300, Eduardo Habkost wrote:
> On Sun, Sep 02, 2018 at 07:46:07PM +0800, Robert Hoo wrote:
> > Note RSBA is specially treated -- no matter host support it or not,
> > qemu
> > pretends it is supported.
> >
> > Signed-off-by: Robert Hoo
> > ---
> > target/i386/cpu.c |
On Tue, 4 Sep 2018 17:15:49 +0800
Yi Min Zhao wrote:
> Common function measurement block is used to report counters of
> successfully issued pcilg/stg/stb and rpcit instructions. This patch
> introduces a new struct ZpciFmb and schedules a timer callback to
> copy fmb to the guest memory at a in
On 9/20/18 10:50 AM, Thomas Huth wrote:
> Make sure that the docs get correctly regenerated when the
> file qemu-deprecated.texi has been changed.
>
> Fixes: 44c67847e32c91a6071fb0440c357b9489f08bc6
> Signed-off-by: Thomas Huth
Reviewed-by: Philippe Mathieu-Daudé
> ---
> Makefile | 2 +-
> 1
Hi Roman,
On 9/20/18 11:34 AM, Roman Kapl wrote:
> dcbz was broken with the refactoring introduced in the External PID patch. The
> GETPC() call is moved directly to the helper in this patch, to report correct
> PC
> address. The issue did not always manifest: if the compiler decided to inline
>
On 9/20/18 10:50 AM, Thomas Huth wrote:
> In early times, network backends were specified by a "vlan" and "name"
> tuple. With the introduction of netdevs, the "name" was replaced by an
> "id" (which is supposed to be unique), but the "name" parameter stayed
> as an alias which could be used inste
On 9/20/18 10:50 AM, Thomas Huth wrote:
> The "name" in the [hub_id name] parameter tuple is the same as a
> "netdev_id" (which should be unique), so specifying the hub_id here
> is just redundant (it was likely just necessary in the past when
> the network subsystem was still using "vlans" only an
On 09/19/2018 11:51 PM, Fam Zheng wrote:
On Wed, 09/19 21:35, Fei Li wrote:
Make qemu_thread_create() return a Boolean to indicate if it succeeds
rather than failing with an error. And add an Error parameter to hold
the error message and let the callers handle it.
Signed-off-by: Fei Li
---
On 20/09/2018 10:34, Roman Kapl wrote:
> dcbz was broken with the refactoring introduced in the External PID patch. The
> GETPC() call is moved directly to the helper in this patch, to report correct
> PC
> address. The issue did not always manifest: if the compiler decided to inline
> the call,
On 09/20/2018 03:32 PM, Fam Zheng wrote:
On Wed, 09/19 23:51, Fam Zheng wrote:
diff --git a/hw/rdma/rdma_backend.c b/hw/rdma/rdma_backend.c
index d7a4bbd91f..e7cbb0c368 100644
--- a/hw/rdma/rdma_backend.c
+++ b/hw/rdma/rdma_backend.c
@@ -165,7 +165,8 @@ static void start_comp_thread(RdmaBacke
Hi,
Given that the previous (broken) version of this patch is already queued in
ppc-for-3.1, would it be better to send a v2 whereby these changes are squashed
into
the original?
I don't know if David Gibson will want to modify history in his branch
-- maybe other people depend on it?
An
This series completes refactoring of pre_plug, plug and unplug logic of
memory devices. With this as a basis, one can easily have e.g. virtio
based memory devices (virtio-mem, virtio-pmem, virtio-fs?) with minor
modifications on e.g. x86.
Patch 1-16 are the "real" patches of this series. Patch 17-
The "at" should actually be a "before".
if (new_addr < address_space_start)
-> "can't add memory ... before... $address_space_start"
So it looks similar to the other check
} else if ((new_addr + size) > address_space_end)
-> "can't add memory ... beyond..."
Reviewed-by: Dr. Davi
While we rephrased most error messages, we missed these.
Reviewed-by: Dr. David Alan Gilbert
Reviewed-by: Igor Mammedov
Signed-off-by: David Hildenbrand
---
hw/mem/memory-device.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/hw/mem/memory-device.c b/hw/mem/memory-d
We will factor out get_memory_region() from pc-dimm to memory device code
soon. Once that is done, get_region_size() can be implemented
generically and essentially be replaced by
memory_device_get_region_size (and work only on get_memory_region()).
We have some users of get_memory_region() (spapr
Some architectures might support memory devices, while they don't
support DIMM/NVDIMM. So let's
- Rename CONFIG_MEM_HOTPLUG to CONFIG_MEM_DEVICE
- Introduce CONFIG_DIMM and use it similarly to CONFIG NVDIMM
CONFIG_DIMM and CONFIG_NVDIMM require CONFIG_MEM_DEVICE.
Reviewed-by: Igor Mammedov
Signe
Although unlikely in practice, we could have integer overflows on some
calculations based on addresses and sizes, leading to error checks not
triggering.
Let's properly handle this whenever we do an addition. Make
address_space_end point at the real end, instead of end + 1, so we don't
have to han
To be able to factor out address asignment of memory devices, we will
have to read (get_addr()) and write (set_addr()) the address.
We can't use properties for this purpose, as properties are device
specific. E.g. while the address property for a DIMM is called "addr", it
might be called different
Let's properly forward the errors, so errors from get_region_size() /
get_plugged_size() can be handled.
Users right now call both functions after the device has been realized,
which is will never fail, so it is fine to continue using error_abort.
While at it, remove a leftover error check (sugge
The memory region is necessary for plugging/unplugging a memory device.
The region size (via get_region_size()) is no longer sufficient, as
besides the alignment, also the region itself is required in order to
add it to the device memory region of the machine via
- memory_region_add_subregion
- mem
Document the functions and when to not expect errors.
Signed-off-by: David Hildenbrand
---
include/hw/mem/memory-device.h | 13 +
1 file changed, 13 insertions(+)
diff --git a/include/hw/mem/memory-device.h b/include/hw/mem/memory-device.h
index f02b229837..d6853156ff 100644
--- a/i
Account the memory to node 0 for now. Once (if ever) virtio-pmem
supports NUMA, we can account it to the right node.
Signed-off-by: David Hildenbrand
---
numa.c | 25 +
1 file changed, 13 insertions(+), 12 deletions(-)
diff --git a/numa.c b/numa.c
index 81542d4ebb..8aa9b
On Wed, 19 Sep 2018 10:18:39 +0200
David Hildenbrand wrote:
> My suggestion, either
> a) Only use KVM_S390_VM_CPU_FEAT_AP to indicate/enable APIE statically
>for the guest.
> b) Only use KVM_S390_VM_CRYPTO_ENABLE_APIE to indicate/enable APIE
>dynamically.
>
> Both things will be simple t
We now have get_memory_region(), which can be used generically to detect
the region size. Use memory_device_get_region_size() where
get_region_size() was used and use memory_device_get_region_size() as
callback for get_plugged_size() (pc-dimm only for now).
Signed-off-by: David Hildenbrand
---
h
Let's trace the address when pre_pluggin/plugging/unplugging a memory device.
Trace it when pre_plugging as well as when plugging, so we really know
when a specific address is actually used.
Signed-off-by: David Hildenbrand
---
hw/mem/memory-device.c | 6 ++
hw/mem/pc-dimm.c | 8 -
With all required memory device class functions in place, we can factor
out pre_plug handling of memory devices. Take proper care of errors. We
still have to carry along legacy_align required for pc compatibility
handling.
We will factor out tracing of the address separately in a follow-up
patch.
When reporting the id of virtio-based memory devices, we always have to
take the one of the proxy device (parent), not the one of the memory
device directly.
Let's generalize this by allowing memory devices to specify an optional
"get_device_id" function. This id can then be used to report errors
With the new memory device functions in place, we can factor out
unplugging of memory devices completely.
Signed-off-by: David Hildenbrand
---
hw/mem/memory-device.c | 8 ++--
hw/mem/pc-dimm.c | 4 +---
include/hw/mem/memory-device.h | 2 +-
3 files changed, 8 insertion
With the new memory device functions in place, we can factor out
plugging of memory devices completely.
Signed-off-by: David Hildenbrand
---
hw/mem/memory-device.c | 10 +++---
hw/mem/pc-dimm.c | 8 +---
include/hw/mem/memory-device.h | 3 +--
3 files changed, 9 i
Print the memory device info just like for PCDIMM/NVDIMM.
Signed-off-by: David Hildenbrand
---
hmp.c | 29 +
1 file changed, 17 insertions(+), 12 deletions(-)
diff --git a/hmp.c b/hmp.c
index 4975fa56b0..a592a4af9d 100644
--- a/hmp.c
+++ b/hmp.c
@@ -2529,27 +2529,21
Once we have other memory devices that are not ACPI devices (e.g.
virtio based), we cannot indicate them via ACPI. So let's skip these
devices.
Signed-off-by: David Hildenbrand
---
hw/i386/acpi-build.c | 15 +--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/hw/i386/a
virtio-pmem devices will have to be hotplugged using the machine hotplug
handler just like other memory devices. Therefore, all machines that
want to support virtio-pmem will have to modify their machine hotplug
handler.
virtio-pmem devices are realized when their parent proxy device
(virtio-pmem-
From: Pankaj Gupta
This is the current protoype of virtio-pmem. Support will require
machine changes for the architectures that will support it, so it will
not yet be compiled.
Signed-off-by: Pankaj Gupta
[ MemoryDevice/MemoryRegion changes, cleanups, addr property "memaddr",
split up patches
From: Pankaj Gupta
We need a proxy device for virtio-pmem.
Signed-off-by: Pankaj Gupta
[ split up patches ]
Signed-off-by: David Hildenbrand
---
hw/virtio/virtio-pci.c | 41 +
hw/virtio/virtio-pci.h | 14 ++
include/hw/pci/pci.h | 1 +
3
Compile virtio-pmem for x86 and properly hotplug virtio-pmem devices
(memory-device part) from our pc machine hotplug handler.
Signed-off-by: David Hildenbrand
---
default-configs/i386-softmmu.mak | 1 +
hw/i386/pc.c | 10 +-
2 files changed, 10 insertions(+), 1 dele
On 2018-09-19 at 14:29:57 +0400, Marc-André Lureau wrote:
> Hi
>
> On Tue, Sep 18, 2018 at 7:49 PM Dr. David Alan Gilbert
> wrote:
> >
> > * Marc-André Lureau (marcandre.lur...@gmail.com) wrote:
> > > Hi
> > >
> > > On Tue, Sep 11, 2018 at 6:19 PM Laszlo Ersek wrote:
> > > >
> > > > +Alex, due t
On Wed, Sep 19, 2018 at 01:46:37PM -0300, Eduardo Habkost wrote:
> On Wed, Sep 19, 2018 at 12:22:19PM +0200, Kashyap Chamarthy wrote:
> > On Tue, Sep 18, 2018 at 11:19:38AM -0300, Eduardo Habkost wrote:
[...]
> > Noted; shall I send a reworded patch to say: "This command will be
> > deprecated in
Am 2018-09-17 18:30, schrieb Emilio G. Cota:
From: Paolo Bonzini
Cc: Michael Walle
Signed-off-by: Paolo Bonzini
Signed-off-by: Emilio G. Cota
---
target/lm32/cpu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/target/lm32/cpu.c b/target/lm32/cpu.c
index b7499cb627..6c0
On Wed, 12 Sep 2018 16:08:17 -0400
Tony Krowiak wrote:
> From: Tony Krowiak
>
> Let's use the KVM_SET_DEVICE_ATTR ioctl to enable or disable
> hardware interpretation of AP instructions executed on the guest.
> If the S390_FEAT_AP feature is installed, AP instructions will
> be interpreted by d
On 9/20/18 12:31 PM, Roman Kapl wrote:
>> Given that the previous (broken) version of this patch is already
>> queued in
>> ppc-for-3.1, would it be better to send a v2 whereby these changes are
>> squashed into
>> the original?
>>
>
> I don't know if David Gibson will want to modify history in hi
On 09/20/2018 01:13 PM, Philippe Mathieu-Daudé wrote:
Fixes: ea8073c10d ("target/ppc: add external PID support")
Your previous patch is now d12a22c5c7 in David Gibson's tree, so I think
here squashing your fixes (once this patch got reviewed) is the best option.
You are right -- I've refere
> @@ -0,0 +1,241 @@
> +/*
> + * Virtio pmem device
> + *
> + * Copyright (C) 2018 Red Hat, Inc.
> + * Copyright (C) 2018 Pankaj Gupta
> + *
> + * This work is licensed under the terms of the GNU GPL, version 2.
> + * See the COPYING file in the top-level directory.
> + *
> + */
> +
> +#include "qe
On Wed, 12 Sep 2018 16:08:19 -0400
Tony Krowiak wrote:
> Introduces a VFIO based AP device. The device is defined via
> the QEMU command line by specifying:
>
> -device vfio-ap,sysfsdev=
>
> There may be only one vfio-ap device configured for a guest.
>
> The mediated matrix device is crea
On Wed, 12 Sep 2018 16:08:14 -0400
Tony Krowiak wrote:
> From: Tony Krowiak
>
> This patch series is the QEMU counterpart to the KVM/kernel support for
> guest dedicated crypto adapters. The KVM/kernel model is built on the
> VFIO mediated device framework and provides the infrastructure for
The intended functionality of QMP command `cpu-add` is replaced by
`device_add` (and `query-hotpluggable-cpus`). So let's deprecate
`cpu-add`.
A complete example of vCPU hotplug with the recommended way, using
`device_add`:
(1) Launch QEMU as follows (note that the "maxcpus" is mandatory to
Am 19.09.2018 um 01:48 hat Max Reitz geschrieben:
> On 18.09.18 17:04, Kevin Wolf wrote:
> > Am 18.09.2018 um 16:11 hat Max Reitz geschrieben:
> >> The user cannot do any graph manipulation then because the monitor is
> >> blocked by starting the job. So the only issue would be other
> >> operatio
>
> > @@ -0,0 +1,241 @@
> > +/*
> > + * Virtio pmem device
> > + *
> > + * Copyright (C) 2018 Red Hat, Inc.
> > + * Copyright (C) 2018 Pankaj Gupta
> > + *
> > + * This work is licensed under the terms of the GNU GPL, version 2.
> > + * See the COPYING file in the top-level directory.
> > + *
>
Andrew,
On 07/14/2017 08:20 AM, Andrew Jeffery wrote:
> Hi Paolo,
>
> Thanks for taking a look!
>
> On Thu, 2017-07-13 at 14:05 +0200, Paolo Bonzini wrote:
>> On 30/06/2017 05:00, Andrew Jeffery wrote:
>>> This RFC patch stems from a discussion on a patch for an ADC model[1] where
>>> it
>>> wa
On 8/24/18 3:17 PM, Roman Kapl wrote:
> The TCG backend uses LOWREGMASK to get the low 7 bits of register numbers.
> This
7 = 0b111: the low 3 bits?
> was defined as no-op for 32-bit x86, with the assumption that we have eight
> registers anyway. This assumption is not true once we have xmm regs
Hi,
On 09/20/2018 02:19 PM, Philippe Mathieu-Daudé wrote:
On 8/24/18 3:17 PM, Roman Kapl wrote:
The TCG backend uses LOWREGMASK to get the low 7 bits of register numbers. This
7 = 0b111: the low 3 bits?
Yes, low 3 bits, 8 registers, the commit message is wrong.
Thanks, Roman Kapl
Kashyap Chamarthy writes:
> The intended functionality of QMP command `cpu-add` is replaced by
> `device_add` (and `query-hotpluggable-cpus`). So let's deprecate
> `cpu-add`.
>
> A complete example of vCPU hotplug with the recommended way, using
> `device_add`:
>
> (1) Launch QEMU as follows (no
error_report and friends already add a "qemu-system-xxx" prefix
to the string, so a "qemu:" prefix is redundant in the string.
Just drop it.
Reported-by: Thomas Huth
Signed-off-by: Mao Zhongyi
---
hw/i386/multiboot.c | 8
hw/ppc/e500.c | 4 ++--
hw/ppc/sam460ex.c | 8
On Thu, Sep 20, 2018 at 02:27:02PM +0200, Markus Armbruster wrote:
> Kashyap Chamarthy writes:
[...]
> When I try this, JSON gets formatted slightly differently:
>
> {
> "execute": "query-hotpluggable-cpus",
> "arguments": {}
> }
> {
> "return": [
>
On Thu, 20 Sep 2018 10:20:49 +0100
"Dr. David Alan Gilbert" wrote:
> * Eduardo Habkost (ehabk...@redhat.com) wrote:
> > On Wed, Sep 19, 2018 at 08:15:25PM +0100, Dr. David Alan Gilbert wrote:
> > > * Igor Mammedov (imamm...@redhat.com) wrote:
> > > > On Wed, 19 Sep 2018 13:14:05 +0100
> > > >
On 09/20/18 15:20, Igor Mammedov wrote:
> On Thu, 20 Sep 2018 10:20:49 +0100
> "Dr. David Alan Gilbert" wrote:
>
>> * Eduardo Habkost (ehabk...@redhat.com) wrote:
>>> On Wed, Sep 19, 2018 at 08:15:25PM +0100, Dr. David Alan Gilbert wrote:
* Igor Mammedov (imamm...@redhat.com) wrote:
On Thu, 20 Sep 2018, at 21:43, Cédric Le Goater wrote:
> Andrew,
>
> On 07/14/2017 08:20 AM, Andrew Jeffery wrote:
> > Hi Paolo,
> >
> > Thanks for taking a look!
> >
> > On Thu, 2017-07-13 at 14:05 +0200, Paolo Bonzini wrote:
> >> On 30/06/2017 05:00, Andrew Jeffery wrote:
> >>> This RFC patch
On Wed, 5 Sep 2018 12:38:00 +0300
Yoni Bettan wrote:
> The main goal is to add 2 example devices to be used as templates or guideline
> for contributors when they wish to create a new device, the first is a PCI
> device and the second will be a VirtIO device.
>
> Those devices may be compiled b
On 20/09/2018 09:17, Pavel Dovgalyuk wrote:
> This patch fixes the checking of boundary crossing instructions.
> In icount mode only first instruction of the block may cross
> the page boundary to keep the translation deterministic.
> These conditions already existed, but compared the wrong variabl
On Fri, 31 Aug 2018 07:57:24 +0200
Markus Armbruster wrote:
> Cornelia Huck writes:
>
> > Add two functions to print an error/warning report once depending
> > on a passed-in condition variable and flip it if printed. This is
> > useful if you want to print a message not once-globally, but e.g.
On 06/05/2018 09:08 PM, w...@redhat.com wrote:
From: Wei Xu
Signed-off-by: Wei Xu
Signed-off-by: Wei Xu
---
hw/virtio/virtio.c | 109 ++---
1 file changed, 96 insertions(+), 13 deletions(-)
diff --git a/hw/virtio/virtio.c b/hw/virtio/virt
I have added more logging code and it seems that there is a hang that
happens with 4096 MB RAM on Mac in virtio_blk_handle_vq:
#define VIRTIO_BLK_UNUSUAL_ITER_COUNT 1024
bool virtio_blk_handle_vq(VirtIOBlock *s, VirtQueue *vq)
{
VirtIOBlockReq *req;
MultiReqBuffer mrb = {};
bool progr
(Not reproducible locally)
On Thu, Sep 20, 2018 at 7:16 AM Frank Yang wrote:
> I have added more logging code and it seems that there is a hang that
> happens with 4096 MB RAM on Mac in virtio_blk_handle_vq:
>
> #define VIRTIO_BLK_UNUSUAL_ITER_COUNT 1024
>
> bool virtio_blk_handle_vq(VirtIOBlock
On Fri, 31 Aug 2018 08:01:39 +0200
Markus Armbruster wrote:
> Cornelia Huck writes:
>
> > {error,warn}_report_once() are a special case of the new functions
> > and can simply switch to them.
> >
> > Signed-off-by: Cornelia Huck
> > ---
> > include/qemu/error-report.h | 34 ++-
On 06/05/2018 09:07 PM, w...@redhat.com wrote:
From: Wei Xu
Mostly reuse memory cache with 1.0 except for the offset calculation.
Signed-off-by: Wei Xu
---
hw/virtio/virtio.c | 29 -
1 file changed, 20 insertions(+), 9 deletions(-)
diff --git a/hw/virtio/vir
Public bug reported:
During the build of gedit for RISC-V this error occurs:
$ qemu-riscv64 -E LD_LIBRARY_PATH=gedit/.libs ./gedit/.libs/gedit
qemu:handle_cpu_signal received signal outside vCPU context @ pc=0x6003ddc5
qemu:handle_cpu_signal received signal outside vCPU context @ pc=0x69e4
h
* Igor Mammedov (imamm...@redhat.com) wrote:
> On Thu, 20 Sep 2018 10:20:49 +0100
> "Dr. David Alan Gilbert" wrote:
>
> > * Eduardo Habkost (ehabk...@redhat.com) wrote:
> > > On Wed, Sep 19, 2018 at 08:15:25PM +0100, Dr. David Alan Gilbert wrote:
> > > > * Igor Mammedov (imamm...@redhat.com) wr
Hi Marcel,
this email should actually be an RFC patch. But RFC patches tend to turn
into real PATCHes (if the submitter is lucky, that is), and I can't
really promise sending multiple versions of a PATCH at this time. So
please consider this a "maybe bug report".
In commit 9fa99d2519cb ("hw/pci-h
This is RFC patch to show how NVDIMM could set a flag on the
MemoryRegion that would be propagated down to the flat view.
This way, guest_phys_blocks_region_add() can skip the NV memory
regions for dumps and TCG memory clear.
qemu-system-x86_64 -machine pc,nvdimm -m 2G,slots=4,maxmem=16G -enable-
TL;DR
=
Allow acceptance tests to be run with `make check-acceptance`.
Details
===
This introduces a Python virtual environment that will be setup within
the QEMU build directory, that will contain the exact environment that
tests may require.
There's one current caveat: it requires Pyt
The acceptance (aka functional, aka Avocado-based) tests are
Python files located in "tests/acceptance" that need to be run
with the Avocado libs and test runner.
Let's provide a convenient way for QEMU developers to run them,
by making use of the tests-venv with the required setup.
Also, while t
A number of QEMU tests are written in Python, and may benefit
from an untainted Python venv.
By using make rules, tests that depend on specific Python libs
can set that rule as a requiment, along with rules that require
the presence or installation of specific libraries.
The tests/venv-requiremen
Wolfgang Bumiller writes:
> On Thu, Sep 20, 2018 at 04:10:00PM +0800, Peter Xu wrote:
>> On Thu, Sep 20, 2018 at 10:02:22AM +0200, Wolfgang Bumiller wrote:
>> > On Thu, Sep 20, 2018 at 10:59:56AM +0800, Peter Xu wrote:
>> > > On Wed, Sep 19, 2018 at 04:58:06PM +0200, Wolfgang Bumiller wrote:
>> >
Wolfgang Bumiller writes:
> On Thu, Sep 20, 2018 at 04:10:00PM +0800, Peter Xu wrote:
>> On Thu, Sep 20, 2018 at 10:02:22AM +0200, Wolfgang Bumiller wrote:
>>
>> > Either way, spawning the iothread on demand can still make sense, as
>> > does updating the check in resume()/suspend().
>>
>> Yep.
job_completed() had a problem with double locking that was recently
fixed independently by two different commits:
"job: Fix nested aio_poll() hanging in job_txn_apply"
"jobs: add exit shim"
One fix removed the first aio_context_acquire(), the other fix removed
the other one. Now we have a bug aga
All callers in QEMU proper hold the AioContext lock when calling
job_finish_sync(). test-blockjob should do the same when it calls the
function indirectly through job_cancel_sync().
Signed-off-by: Kevin Wolf
Reviewed-by: Fam Zheng
---
include/qemu/job.h| 6 ++
tests/test-blockjob.c | 6
Especially the combination of iothreads, block jobs and drain tends to
lead to hangs currently. This series fixes a few of these bugs, although
there are more of them, to be addressed in separate patches.
The primary goal of this series is to fix the scenario from:
https://bugzilla.redhat.com/show
In the context of draining a BDS, the .drained_poll callback of block
jobs is called. If this returns true (i.e. there is still some activity
pending), the drain operation may call aio_poll() with blocking=true to
wait for completion.
As soon as the pending activity is completed and the job finall
Even if AIO_WAIT_WHILE() is called in the home context of the
AioContext, we still want to allow the condition to change depending on
other threads as long as they kick the AioWait. Specfically block jobs
can be running in an I/O thread and should then be able to kick a drain
in the main loop conte
bdrv_do_drained_begin/end() assume that they are called with the
AioContext lock of bs held. If we call drain functions from a coroutine
with the AioContext lock held, we yield and schedule a BH to move out of
coroutine context. This means that the lock for the home context of the
coroutine is rele
Request callbacks can do pretty much anything, including operations that
will yield from the coroutine (such as draining the backend). In that
case, a decreased in_flight would be visible to other code and could
lead to a drain completing while the callback hasn't actually completed
yet.
Signed-of
This extends the existing drain test with a block job to include
variants where the block job runs in a different AioContext.
Signed-off-by: Kevin Wolf
Reviewed-by: Fam Zheng
---
tests/test-bdrv-drain.c | 92 +
1 file changed, 86 insertions(+), 6
A bdrv_drain operation must ensure that all parents are quiesced, this
includes BlockBackends. Otherwise, callbacks called by requests that are
completed on the BDS layer, but not quite yet on the BlockBackend layer
could still create new requests.
Signed-off-by: Kevin Wolf
Reviewed-by: Fam Zheng
This is a regression test for a deadlock that could occur in callbacks
called from the aio_poll() in bdrv_drain_poll_top_level(). The
AioContext lock wasn't released and therefore would be taken a second
time in the callback. This would cause a possible AIO_WAIT_WHILE() in
the callback to hang.
Si
job_finish_sync() needs to release the AioContext lock of the job before
calling aio_poll(). Otherwise, callbacks called by aio_poll() would
possibly take the lock a second time and run into a deadlock with a
nested AIO_WAIT_WHILE() call.
Also, job_drain() without aio_poll() isn't necessarily enou
bdrv_drain_poll_top_level() was buggy because it didn't release the
AioContext lock of the node to be drained before calling aio_poll().
This way, callbacks called by aio_poll() would possibly take the lock a
second time and run into a deadlock with a nested AIO_WAIT_WHILE() call.
However, it turn
1 - 100 of 175 matches
Mail list logo
