[Expired for QEMU because there has been no activity for 60 days.]
** Changed in: qemu
Status: Incomplete => Expired
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1824768
Title:
Qemu ARMv7
Patchew URL:
https://patchew.org/QEMU/20190621213712.16222-1-liran.a...@oracle.com/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Subject: [Qemu-devel] [PATCH 0/2] target/i386: kvm: Fix treatment of AMD SVM in
nested migration
Type: series
Hi,
Attached is a patch to let guest programs use SIGRTMIN + 1 by swapping with
SIGRTMAX - 1. Since QEMU links against glibc, it reserves the signal for
itself and returns EINVAL (as noted in the commit message). This means
various applications that use SIGRTMIN + 1 cannot run on QEMU, including
> On 22 Jun 2019, at 2:59, Paolo Bonzini wrote:
>
> On 21/06/19 23:37, Liran Alon wrote:
>> However, during discussion made after merge, it was realised that since QEMU
>> commit
>> 75d373ef9729 ("target-i386: Disable SVM by default in KVM mode"), an AMD
>> vCPU that
>> is virtualized by
On Thu, Jun 20, 2019 at 7:49 PM Palmer Dabbelt wrote:
>
> On Wed, 19 Jun 2019 07:19:38 PDT (-0700), alistai...@gmail.com wrote:
> > On Wed, Jun 19, 2019 at 3:58 AM Palmer Dabbelt wrote:
> >>
> >> On Mon, 17 Jun 2019 18:31:00 PDT (-0700), Alistair Francis wrote:
> >> > Based-on:
> >> >
> >> >
When emulating irqchip in qemu, such as following command:
x86_64-softmmu/qemu-system-x86_64 -m 1024 -smp 4 -hda /home/test/test.img
-machine kernel-irqchip=off --enable-kvm -vnc :0 -device edu -monitor stdio
We will get a crash with following asan output:
(qemu)
Li Qiang 于2019年6月22日周六 上午12:15写道：
> When emulating irqchip in qemu, such as following command:
>
> x86_64-softmmu/qemu-system-x86_64 -m 1024 -smp 4 -hda /home/test/test.img
> -machine kernel-irqchip=off --enable-kvm -vnc :0 -device edu -monitor stdio
>
> We will get a crash with following asan
Patchew URL: https://patchew.org/QEMU/20190621134338.8425-1-da...@redhat.com/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Subject: [Qemu-devel] [PULL SUBSYSTEM s390x 0/3] s390x/tcg: pending patches
Type: series
Message-id:
On 21/06/19 23:37, Liran Alon wrote:
> However, during discussion made after merge, it was realised that since QEMU
> commit
> 75d373ef9729 ("target-i386: Disable SVM by default in KVM mode"), an AMD vCPU
> that
> is virtualized by KVM doesn't expose SVM by default, even if you use "-cpu
>
The intention here is to discuss the validity of running the the
acceptance tests are not depedent on target specific functionality on
all built targets.
Subtle but important questions that this topic brings:
1) Should the QEMU binary target provide, as much as possible,
a similar
On 6/21/19 5:48 PM, Max Reitz wrote:
> On 21.06.19 22:58, John Snow wrote:
>>
>>
>> On 6/21/19 9:44 AM, Vladimir Sementsov-Ogievskiy wrote:
>
> [...]
>
> Just chiming in on this:
>
>>> "So on cancel and abort you synchronize bitmap too?"
>>
>> I will concede that this means that if you ask
On Thu, Jun 20, 2019 at 10:42 PM Bin Meng wrote:
>
> On Thu, Jun 20, 2019 at 2:30 AM Alistair Francis wrote:
> >
> > On Wed, Jun 19, 2019 at 8:18 AM Bin Meng wrote:
> > >
> > > On Wed, Jun 19, 2019 at 1:14 PM Anup Patel wrote:
> > > >
> > > > On Wed, Jun 19, 2019 at 6:24 AM Alistair Francis
>
On Sat, 22 Jun 2019 02:35:02 +0530
Kirti Wankhede wrote:
> On 6/22/2019 2:02 AM, Alex Williamson wrote:
> > On Sat, 22 Jun 2019 01:37:47 +0530
> > Kirti Wankhede wrote:
> >
> >> On 6/22/2019 1:32 AM, Alex Williamson wrote:
> >>> On Sat, 22 Jun 2019 01:08:40 +0530
> >>> Kirti Wankhede
On Fri, Jun 21, 2019 at 11:38:06AM -0400, Wainer dos Santos Moschetta wrote:
> Hi all,
>
> I'm still unsure this is the best solution. I tend to think that
> any arch-independent test case (i.e. not tagged 'arch') should
> be skipped on all arches except for x86_64. Opening up for
> discussion
This is a left-over from "f4ec5e26ed vfio: Add host side DMA window
capabilities", which added support to more than one DMA window.
Signed-off-by: Fabiano Rosas
---
include/hw/vfio/vfio-common.h | 5 -
1 file changed, 5 deletions(-)
diff --git a/include/hw/vfio/vfio-common.h
On Sat, 22 Jun 2019 02:00:08 +0530
Kirti Wankhede wrote:
> On 6/22/2019 1:30 AM, Alex Williamson wrote:
> > On Sat, 22 Jun 2019 01:05:48 +0530
> > Kirti Wankhede wrote:
> >
> >> On 6/21/2019 8:33 PM, Alex Williamson wrote:
> >>> On Fri, 21 Jun 2019 11:22:15 +0530
> >>> Kirti Wankhede
On 21.06.19 22:58, John Snow wrote:
>
>
> On 6/21/19 9:44 AM, Vladimir Sementsov-Ogievskiy wrote:
[...]
Just chiming in on this:
>> "So on cancel and abort you synchronize bitmap too?"
>
> I will concede that this means that if you ask for a bitmap backup with
> the 'always' policy and, for
Hi,
This patch series aims to fix the recent patch-series that was just merged to
upstream QEMU master branch which adds support for nested migration.
The already merged patch-series was modified during merge to allow migration of
vCPU
exposed with SVM even though kernel does not support
Even though current most upstream kernel does not support save/restore
of nested-state in case of AMD SVM, prepare QEMU code to init
relevant nested-state struct fields.
Reviewed-by: Mark Kanda
Reviewed-by: Karl Heubaum
Signed-off-by: Liran Alon
---
target/i386/kvm.c | 5 +++--
1 file
Commit 18ab37ba1cee ("target/i386: kvm: Block migration for vCPUs exposed with
nested virtualization")
was originally suppose to block migration for vCPUs exposed with nested
virtualization, either Intel VMX
or AMD SVM. However, during merge to upstream, commit was changed such that it
doesn't
On 6/21/19 7:58 AM, Vladimir Sementsov-Ogievskiy wrote:
> 20.06.2019 19:36, John Snow wrote:
>>
>>
>> On 6/20/19 12:02 PM, Max Reitz wrote:
>>> On 20.06.19 03:03, John Snow wrote:
This function can claim an hbitmap to replace its own current hbitmap.
In the case that the granularities
On Fri, Jun 21, 2019 at 10:11:31AM +0200, Igor Mammedov wrote:
>On Fri, 21 Jun 2019 08:56:44 +0800
>Wei Yang wrote:
>
>> On Thu, Jun 20, 2019 at 05:04:29PM +0200, Igor Mammedov wrote:
>> >On Thu, 20 Jun 2019 14:18:42 +
>> >Wei Yang wrote:
>> >
>> >> On Wed, Jun 19, 2019 at 11:04:40AM
On 6/22/2019 2:02 AM, Alex Williamson wrote:
> On Sat, 22 Jun 2019 01:37:47 +0530
> Kirti Wankhede wrote:
>
>> On 6/22/2019 1:32 AM, Alex Williamson wrote:
>>> On Sat, 22 Jun 2019 01:08:40 +0530
>>> Kirti Wankhede wrote:
>>>
On 6/21/2019 8:46 PM, Alex Williamson wrote:
> On
On 6/21/19 9:44 AM, Vladimir Sementsov-Ogievskiy wrote:
> 21.06.2019 16:08, Vladimir Sementsov-Ogievskiy wrote:
>> 21.06.2019 15:59, Vladimir Sementsov-Ogievskiy wrote:
>>> 21.06.2019 15:57, Vladimir Sementsov-Ogievskiy wrote:
^ Home Run!
I'm going to reply to all four of these mails at once
On Sat, 22 Jun 2019 01:37:47 +0530
Kirti Wankhede wrote:
> On 6/22/2019 1:32 AM, Alex Williamson wrote:
> > On Sat, 22 Jun 2019 01:08:40 +0530
> > Kirti Wankhede wrote:
> >
> >> On 6/21/2019 8:46 PM, Alex Williamson wrote:
> >>> On Fri, 21 Jun 2019 12:08:26 +0530
> >>> Kirti Wankhede
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nvidia.com; s=n1;
t=1561149027; bh=Vx3+8epE7Of2rlG84nWeSfu7DRT+uJEzppnOePdWLeI=;
h=X-PGP-Universal:Subject:To:CC:References:X-Nvconfidentiality:From:
Message-ID:Date:MIME-Version:In-Reply-To:X-Originating-IP:
On 6/22/2019 1:32 AM, Alex Williamson wrote:
> On Sat, 22 Jun 2019 01:08:40 +0530
> Kirti Wankhede wrote:
>
>> On 6/21/2019 8:46 PM, Alex Williamson wrote:
>>> On Fri, 21 Jun 2019 12:08:26 +0530
>>> Kirti Wankhede wrote:
>>>
On 6/21/2019 12:55 AM, Alex Williamson wrote:
> On
On Sat, 22 Jun 2019 01:08:40 +0530
Kirti Wankhede wrote:
> On 6/21/2019 8:46 PM, Alex Williamson wrote:
> > On Fri, 21 Jun 2019 12:08:26 +0530
> > Kirti Wankhede wrote:
> >
> >> On 6/21/2019 12:55 AM, Alex Williamson wrote:
> >>> On Thu, 20 Jun 2019 20:07:36 +0530
> >>> Kirti Wankhede
On Sat, 22 Jun 2019 01:05:48 +0530
Kirti Wankhede wrote:
> On 6/21/2019 8:33 PM, Alex Williamson wrote:
> > On Fri, 21 Jun 2019 11:22:15 +0530
> > Kirti Wankhede wrote:
> >
> >> On 6/20/2019 10:48 PM, Alex Williamson wrote:
> >>> On Thu, 20 Jun 2019 20:07:29 +0530
> >>> Kirti Wankhede
On 6/21/19 7:29 AM, Vladimir Sementsov-Ogievskiy wrote:
> 20.06.2019 4:03, John Snow wrote:
>> We don't need or want a new sync mode for simple differences in
>> semantics. Create a new mode simply named "BITMAP" that is designed to
>> make use of the new Bitmap Sync Mode field.
>>
>> Because
On 6/21/2019 8:46 PM, Alex Williamson wrote:
> On Fri, 21 Jun 2019 12:08:26 +0530
> Kirti Wankhede wrote:
>
>> On 6/21/2019 12:55 AM, Alex Williamson wrote:
>>> On Thu, 20 Jun 2019 20:07:36 +0530
>>> Kirti Wankhede wrote:
>>>
Added .save_live_pending, .save_live_iterate and
On 6/21/2019 8:33 PM, Alex Williamson wrote:
> On Fri, 21 Jun 2019 11:22:15 +0530
> Kirti Wankhede wrote:
>
>> On 6/20/2019 10:48 PM, Alex Williamson wrote:
>>> On Thu, 20 Jun 2019 20:07:29 +0530
>>> Kirti Wankhede wrote:
>>>
- Defined MIGRATION region type and sub-type.
- Used
On Fri, Jun 21, 2019 at 11:33:10AM +0100, Peter Maydell wrote:
> On Thu, 20 Jun 2019 at 23:23, Wainer dos Santos Moschetta
> wrote:
> > I came across this when running the acceptance tests in an aarch64 host.
> > The arch-independent tests fail because, in general, they don't set a
> > machine
On Fri, Jun 21, 2019 at 08:42:28PM +0300, Sam Eiderman wrote:
> Sounds reasonable, how do purpose to deal with:
>
> config BIOS_GEOMETRY
> config BOOTORDER
>
> precompiler optouts?
I think you can stick them both under BOOTORDER. That option is only
there in case someone wants to reduce the
Incremental patch to squash into last series
Signed-off-by: BALATON Zoltan
---
hw/display/ati_dbg.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/hw/display/ati_dbg.c b/hw/display/ati_dbg.c
index b045f81d06..88b3a11315 100644
--- a/hw/display/ati_dbg.c
+++ b/hw/display/ati_dbg.c
@@
Patchew URL:
https://patchew.org/QEMU/20190621144541.13770-1-skrtbht...@gmail.com/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Type: series
Subject: [Qemu-devel] [RFC 0/1] Add live migration support to the PVRDMA device
Message-id:
> On 21 Jun 2019, at 20:27, Paolo Bonzini wrote:
>
> On 21/06/19 17:07, Liran Alon wrote:
>>> So, overall I prefer not to block migration.
>> I’m not sure I agree.
>> It is quite likely that vCPU is currently in guest-mode while you are
>> migrating…
>> A good hypervisor tries to maximise
Sounds reasonable, how do purpose to deal with:
config BIOS_GEOMETRY
config BOOTORDER
precompiler optouts?
If we don’t need any of them we also don’t need to call “get_scsi_devpath",
“get_ata_devpath”, “get_pci_dev_path”.
I’ll see what can be done.
> On 20 Jun 2019, at 17:37, Kevin O'Connor
On Fri, Jun 21, 2019 at 1:21 AM Alex Bennée wrote:
> > * Register and memory read/write API
> >
> > It would be great to have register and memory read/write API i.e., ability
> > to read/write to registers/memory from within the callback. This gives the
> > plugin ability to do system
On 21/06/19 17:07, Liran Alon wrote:
>> So, overall I prefer not to block migration.
> I’m not sure I agree.
> It is quite likely that vCPU is currently in guest-mode while you are
> migrating…
> A good hypervisor tries to maximise CPU time to be in guest-mode rather than
> host-mode. :)
True,
On 6/21/19 3:05 PM, Laurent Vivier wrote:
> if softmmu is not enabled, we disable by default fdt and
> slirp as they are only used by -softmmu targets.
>
> A side effect is the git submodules are not cloned
> if they are not needed.
>
> Clone and build can be forced with --enable-fdt and
>
On Fri, Jun 21, 2019 at 06:55:02PM +0200, Philippe Mathieu-Daudé wrote:
> Hi Drew,
>
> On 6/21/19 6:34 PM, Andrew Jones wrote:
> > Since 97a28b0eeac14 ("target/arm: Allow VFP and Neon to be disabled via
> > a CPU property") we can disable the 'max' cpu model's VFP and neon
> > features, but
Hi Alistair,
On 6/19/19 6:54 AM, Alistair Francis wrote:
> Add M mode initial entry PC and SP properties.
>
> Signed-off-by: Alistair Francis
> ---
> target/arm/cpu.c | 47 +++
> target/arm/cpu.h | 3 +++
> 2 files changed, 50 insertions(+)
>
>
Allow cpu 'host' to enable SVE when it's available, unless the
user chooses to disable it with the added 'sve=off' cpu property.
Also give the user the ability to select vector lengths with the
sve properties. We don't adopt 'max' cpu's other sve
property, sve-max-vq, because that property is
kvm_arm_create_scratch_host_vcpu() takes a struct kvm_vcpu_init
parameter. Rather than just using it as an output parameter to
pass back the preferred target, use it also as an input parameter,
allowing a caller to pass a selected target if they wish and to
also pass cpu features. If the caller
Enable SVE in the KVM guest when the 'max' cpu type is configured
and KVM supports it. KVM SVE requires use of the new finalize
vcpu ioctl, so we add that now too. For starters SVE can only be
turned on or off, getting all vector lengths the host CPU supports
when on. We'll add the other SVE CPU
Hi Drew,
On 6/21/19 6:34 PM, Andrew Jones wrote:
> Since 97a28b0eeac14 ("target/arm: Allow VFP and Neon to be disabled via
> a CPU property") we can disable the 'max' cpu model's VFP and neon
> features, but there's no way to disable SVE. Add the 'sve=on|off'
> property to give it that
These are the SVE equivalents to kvm_arch_get/put_fpsimd. Note, the
swabbing is different than it is for fpsmid because the vector format
is a little-endian stream of words.
Signed-off-by: Andrew Jones
---
target/arm/kvm64.c | 135 +++--
1 file changed,
Patchew URL: https://patchew.org/QEMU/20190621134338.8425-1-da...@redhat.com/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Subject: [Qemu-devel] [PULL SUBSYSTEM s390x 0/3] s390x/tcg: pending patches
Message-id:
Introduce cpu properties to give fine control over SVE vector lengths.
We introduce a property for each valid length up to the current
maximum supported, which is 2048-bits. The properties are named, e.g.
sve128, sve256, sve512, ..., where the number is the number of bits.
It's now possible to do
Move the getting/putting of the fpsimd registers out of
kvm_arch_get/put_registers() into their own helper functions
to prepare for alternatively getting/putting SVE registers.
No functional change.
Signed-off-by: Andrew Jones
Reviewed-by: Eric Auger
---
target/arm/kvm64.c | 148
Extend the SVE vq map initialization and validation with KVM's
supported vector lengths when KVM is enabled. In order to determine
and select supported lengths we add two new KVM functions for getting
and setting the KVM_REG_ARM64_SVE_VLS pseudo-register.
Signed-off-by: Andrew Jones
---
A couple return -EINVAL's forgot their '-'s.
Signed-off-by: Andrew Jones
Reviewed-by: Eric Auger
---
target/arm/kvm64.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/target/arm/kvm64.c b/target/arm/kvm64.c
index 45ccda589903..9ca9a0ce821d 100644
---
Since 97a28b0eeac14 ("target/arm: Allow VFP and Neon to be disabled via
a CPU property") we can disable the 'max' cpu model's VFP and neon
features, but there's no way to disable SVE. Add the 'sve=on|off'
property to give it that flexibility. We also rename
cpu_max_get/set_sve_vq to
Add support for the query-cpu-model-expansion QMP command to Arm. We
do this selectively, only exposing CPU properties which represent
optional CPU features which the user may want to enable/disable. Also,
for simplicity, we restrict the list of queryable cpu models to 'max',
'host', or the
We first convert the pmu property from a static property to one with
its own accessors. Then we use the set accessor to check if the PMU is
supported when using KVM. Indeed a 32-bit KVM host does not support
the PMU, so this check will catch an attempt to use it at property-set
time.
Since Linux kernel v5.2-rc1 KVM has support for enabling SVE in guests.
This series provides the QEMU bits for that enablement. This is a v2
series, however it looks completely different than v1. Thank you to
all who reviewed v1. I've included all input still relevant to this
new approach. And the
Suggested-by: Dave Martin
Signed-off-by: Andrew Jones
---
target/arm/helper.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/target/arm/helper.c b/target/arm/helper.c
index df4276f5f6ca..edba94004e0b 100644
--- a/target/arm/helper.c
+++ b/target/arm/helper.c
@@ -5319,6 +5319,7 @@ static
Now that Arm CPUs have advertised features lets add tests to ensure
we maintain their expected availability with and without KVM.
Signed-off-by: Andrew Jones
---
tests/Makefile.include | 5 +-
tests/arm-cpu-features.c | 221 +++
2 files changed, 225
If -cpu ,aarch64=off is used then KVM must also be used, and it
and the host must support running the vcpu in 32-bit mode. Also, if
-cpu ,aarch64=on is used, then it doesn't matter if kvm is
enabled or not.
Signed-off-by: Andrew Jones
---
target/arm/cpu64.c | 12 ++--
On Fri, Jun 21, 2019 at 03:48:36PM +0200, Marc-André Lureau wrote:
> On Fri, Jun 21, 2019 at 11:40 AM Stefan Hajnoczi wrote:
> > diff --git a/contrib/vhost-user-blk/vhost-user-blk.c
> > b/contrib/vhost-user-blk/vhost-user-blk.c
> > index 86a3987744..ae61034656 100644
> > ---
On 6/19/19 6:53 AM, Alistair Francis wrote:
> Allow the kernel's entry point information to be returned when loading a
> kernel.
>
> Signed-off-by: Alistair Francis
Reviewed-by: Philippe Mathieu-Daudé
Tested-by: Philippe Mathieu-Daudé
> ---
> hw/arm/armv7m.c | 4 +++-
>
When emulating irqchip in qemu, such as following command:
x86_64-softmmu/qemu-system-x86_64 -m 1024 -smp 4 -hda /home/test/test.img
-machine kernel-irqchip=off --enable-kvm -vnc :0 -device edu -monitor stdio
We will get a crash with following asan output:
(qemu)
> On 21 Jun 2019, at 18:44, Liran Alon wrote:
>
>
>
>> On 21 Jun 2019, at 18:39, Paolo Bonzini wrote:
>>
>> On 21/06/19 17:00, Liran Alon wrote:
>>> Cool.
>>> Are you planning to make those changes when applying/merging or
>>> do you need me to submit a new patch-series version?
>>> Also
> On 21 Jun 2019, at 18:39, Paolo Bonzini wrote:
>
> On 21/06/19 17:00, Liran Alon wrote:
>> Cool.
>> Are you planning to make those changes when applying/merging or
>> do you need me to submit a new patch-series version?
>> Also note my comment on the other patch regarding block migration on
On 21/06/19 17:00, Liran Alon wrote:
> Cool.
> Are you planning to make those changes when applying/merging or
> do you need me to submit a new patch-series version?
> Also note my comment on the other patch regarding block migration on AMD vCPU
> which expose SVM.
It's already merged, but it's
Hi all,
I'm still unsure this is the best solution. I tend to think that
any arch-independent test case (i.e. not tagged 'arch') should
be skipped on all arches except for x86_64. Opening up for
discussion though.
Note: It was decided that ARM targets should not default to any
machine type:
21.06.2019 18:15, Vladimir Sementsov-Ogievskiy wrote:
> Instead of draining additional nodes in each job code, let's do it in
> common block_job_drain, draining just all job's children.
> BlockJobDriver.drain becomes unused, so, drop it at all.
>
> It's also a first step to finally get rid of
On Fri, 21 Jun 2019 12:08:26 +0530
Kirti Wankhede wrote:
> On 6/21/2019 12:55 AM, Alex Williamson wrote:
> > On Thu, 20 Jun 2019 20:07:36 +0530
> > Kirti Wankhede wrote:
> >
> >> Added .save_live_pending, .save_live_iterate and
> >> .save_live_complete_precopy
> >> functions. These
Instead of draining additional nodes in each job code, let's do it in
common block_job_drain, draining just all job's children.
BlockJobDriver.drain becomes unused, so, drop it at all.
It's also a first step to finally get rid of blockjob->blk.
Signed-off-by: Vladimir Sementsov-Ogievskiy
---
Instead of draining additional nodes in each job code, let's do it in
common block_job_drain, draining just all job's children.
It's also a first step to finally get rid of blockjob->blk.
Signed-off-by: Vladimir Sementsov-Ogievskiy
---
Hi all!
As a follow-up for "block: drop bs->job" recently
> On 21 Jun 2019, at 18:02, Paolo Bonzini wrote:
>
> On 21/06/19 14:39, Liran Alon wrote:
>>> On 21 Jun 2019, at 14:30, Paolo Bonzini wrote:
>>>
>>> From: Liran Alon
>>>
>>> Previous commits have added support for migration of nested virtualization
>>> workloads. This was done by
On 21/06/2019 16:52, Greg Kurz wrote:
> As indicated in the function header, this "hcall is only supported for
> LISNs that have the ESB hcall flag set to 1 when returned from hcall()
> H_INT_GET_SOURCE_INFO". We only set that flag for LSIs actually.
>
> Check that in h_int_esb().
Indeed.
On 21/06/19 14:48, Liran Alon wrote:
>
>
>> On 21 Jun 2019, at 15:45, Paolo Bonzini wrote:
>>
>> On 21/06/19 14:29, Liran Alon wrote:
+max_nested_state_len = kvm_max_nested_state_length();
+if (max_nested_state_len > 0) {
+assert(max_nested_state_len >=
On Fri, 21 Jun 2019 11:22:15 +0530
Kirti Wankhede wrote:
> On 6/20/2019 10:48 PM, Alex Williamson wrote:
> > On Thu, 20 Jun 2019 20:07:29 +0530
> > Kirti Wankhede wrote:
> >
> >> - Defined MIGRATION region type and sub-type.
> >> - Used 3 bits to define VFIO device states.
> >> Bit 0 =>
On 21/06/19 14:39, Liran Alon wrote:
>> On 21 Jun 2019, at 14:30, Paolo Bonzini wrote:
>>
>> From: Liran Alon
>>
>> Previous commits have added support for migration of nested virtualization
>> workloads. This was done by utilising two new KVM capabilities:
>> KVM_CAP_NESTED_STATE and
> On 21 Jun 2019, at 17:55, Paolo Bonzini wrote:
>
> On 21/06/19 14:48, Liran Alon wrote:
>>
>>
>>> On 21 Jun 2019, at 15:45, Paolo Bonzini wrote:
>>>
>>> On 21/06/19 14:29, Liran Alon wrote:
> +max_nested_state_len = kvm_max_nested_state_length();
> +if
As indicated in the function header, this "hcall is only supported for
LISNs that have the ESB hcall flag set to 1 when returned from hcall()
H_INT_GET_SOURCE_INFO". We only set that flag for LSIs actually.
Check that in h_int_esb().
Signed-off-by: Greg Kurz
---
hw/intc/spapr_xive.c |6
On 6/20/19 5:31 PM, Michael S. Tsirkin wrote:
> On Thu, Jun 13, 2019 at 04:34:30PM +0200, Philippe Mathieu-Daudé wrote:
>> This ensure we won't use an incorrect value.
>>
>> Signed-off-by: Philippe Mathieu-Daudé
>
> It doesn't actually ensure anything: compiler does not check IIUC.
>
> And OTOH
Hi,
I am a GSoC participant, trying to implement live migration for the
pvrdma device with help from my mentors Marcel and Yuval.
My current task is to save and load the various addresses that the
device uses for DMA mapping. We will be adding the device state into
live migration, incrementally.
On Fri, Jun 21, 2019 at 09:03:33AM +0200, Philippe Mathieu-Daudé wrote:
> On 6/21/19 8:09 AM, Cleber Rosa wrote:
> > It's a fact that some tests may not be 100% reliable in all
> > environments. While it's a tough call to remove a useful test that
> > from the tree because it may fail every
On 6/20/19 5:28 PM, Michael S. Tsirkin wrote:
> On Thu, Jun 13, 2019 at 04:34:28PM +0200, Philippe Mathieu-Daudé wrote:
>> Reviewed-by: Li Qiang
>> Signed-off-by: Philippe Mathieu-Daudé
>
> Motivation? do you expect more than 2^31 entries?
Building with -Wsign-compare:
hw/i386/pc.c:973:36:
Define and register SaveVMHandlers pvrdma_save and
pvrdma_load for saving and loading the device state,
which currently includes only the dma, command slot
and response slot addresses.
Remap the DSR, command slot and response slot upon
loading the addresses in the pvrdma_load function.
Cc:
On 6/20/19 5:27 PM, Michael S. Tsirkin wrote:
> On Thu, Jun 13, 2019 at 04:34:27PM +0200, Philippe Mathieu-Daudé wrote:
>> Reviewed-by: Li Qiang
>> Signed-off-by: Philippe Mathieu-Daudé
>
> Motivation? Is this a bugfix?
Apparently I started to work on this series after "chardev: Convert
On Fri, 21 Jun 2019 at 12:34, Paolo Bonzini wrote:
>
> The following changes since commit 33d609990621dea6c7d056c86f707b8811320ac1:
>
> Merge remote-tracking branch 'remotes/kevin/tags/for-upstream' into staging
> (2019-06-18 17:00:52 +0100)
>
> are available in the git repository at:
>
>
>
No functional change. Add default case to fix warning.
Signed-off-by: Wei Yang
---
migration/migration.c | 8 +++-
migration/migration.h | 6 +++---
2 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/migration/migration.c b/migration/migration.c
index 2865ae3fa9..0fd2364961
On 6/20/19 12:19 AM, Laurent Vivier wrote:
> On Sparc and PowerMac, the bit 0 of the address
> selects the register type (control or data) and
> bit 1 selects the channel (B or A).
>
> On m68k Macintosh, the bit 0 selects the channel and
> bit 1 the register type.
>
> This patch introduces a new
Hi
On Fri, Jun 21, 2019 at 11:40 AM Stefan Hajnoczi wrote:
>
> Currently libvhost-user is hardcoded to at most 8 virtqueues. The
> device backend should decide the number of virtqueues, not
> libvhost-user. This is important for multiqueue device backends where
> the guest driver needs an
Let's handle it just like for other crypto features.
Reviewed-by: Janosch Frank
Acked-by: Cornelia Huck
Signed-off-by: David Hildenbrand
---
target/s390x/cpu_features_def.inc.h | 30 ++---
target/s390x/gen-features.c | 30 ++---
2 files
This pull request is not for master.
Hi Conny,
The following changes since commit 33d609990621dea6c7d056c86f707b8811320ac1:
Merge remote-tracking branch 'remotes/kevin/tags/for-upstream' into staging
(2019-06-18 17:00:52 +0100)
are available in the Git repository at:
On Fri, Jun 21, 2019 at 11:41 AM Stefan Hajnoczi wrote:
>
> The "Multiple queue support" section makes references to vhost-user-net
> "queue pairs". This is confusing for two reasons:
> 1. This actually applies to all device types, not just vhost-user-net.
> 2. VHOST_USER_GET_QUEUE_NUM returns
Patchew URL:
https://patchew.org/QEMU/1561116620-22245-1-git-send-email-pbonz...@redhat.com/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Type: series
Subject: [Qemu-devel] [PULL v2 00/25] Misc (mostly x86) patches for 2019-06-21
An update on our further research. We tried bumping the hypervisor
kernel form 4.19.43 to 4.19.50 which included the following patch, which
we hoped to be related to our issue:
https://lore.kernel.org/lkml/20190520115253.743557...@linuxfoundation.org/#t
Sadly after a few thousand migrations we
On Fri, Jun 21, 2019 at 11:40 AM Stefan Hajnoczi wrote:
>
> The VhostUserMsg request is reused as the reply by message processing
> functions. This is risky since request fields may corrupt the reply if
> the vhost-user message handler function forgets to re-initialize them.
>
> Changing this
On Fri, Jun 21, 2019 at 11:40 AM Stefan Hajnoczi wrote:
>
> Existing vhost-user device backends, including vhost-user-scsi and
> vhost-user-blk, support multiqueue but libvhost-user currently does not
> advertise this.
>
> VHOST_USER_PROTOCOL_F_MQ enables the VHOST_USER_GET_QUEUE_NUM request
>
Dont support 'MAP_SYNC' with non-DAX files and DAX files
with asynchronous dax_device. Virtio pmem provides
asynchronous host page cache flush mechanism. We don't
support 'MAP_SYNC' with virtio pmem and ext4.
Signed-off-by: Pankaj Gupta
Reviewed-by: Jan Kara
---
fs/ext4/file.c | 10 ++
On 6/21/19 6:28 AM, Paolo Bonzini wrote:
> While indeed we do not want to have
>
> return (a);
>
> it is less clear that this applies to
>
> return (a &&
> b);
>
> Some editors indent more nicely if you have parentheses, and some people's
> eyes may appreciate that as well.
Let's define features at a single spot and make it less error prone to
define new features.
Acked-by: Janosch Frank
Acked-by: Cornelia Huck
Signed-off-by: David Hildenbrand
---
target/s390x/cpu_features.c | 352 +-
target/s390x/cpu_features_def.h | 352
21.06.2019 16:08, Vladimir Sementsov-Ogievskiy wrote:
> 21.06.2019 15:59, Vladimir Sementsov-Ogievskiy wrote:
>> 21.06.2019 15:57, Vladimir Sementsov-Ogievskiy wrote:
>>> 20.06.2019 4:03, John Snow wrote:
This adds an "always" policy for bitmap synchronization. Regardless of if
the job
13.06.2019 1:09, Max Reitz wrote:
> With bdrv_filtered_rw_bs(), we can easily handle this default filter
> behavior in bdrv_co_block_status().
>
> blkdebug wants to have an additional assertion, so it keeps its own
> implementation, except bdrv_co_block_status_from_file() needs to be
> inlined
1 - 100 of 279 matches
Mail list logo
