On Wed, 22 May 2019 18:03:13 +0200
Christian Schoenebeck wrote:
> On Montag, 20. Mai 2019 16:05:09 CEST Greg Kurz wrote:
> > Hi Christian,
>
> Hi Greg,
>
> > On the other hand, I'm afraid that having a functional solution won't
> > motivate people to come up with a new spec... Anyway, I agree
Firstly detect the interface using KVM_CAP_MANUAL_DIRTY_LOG_PROTECT2
and mark it. When failed to enable the new feature we'll fall back to
the old sync.
Provide the log_clear() hook for the memory listeners for both address
spaces of KVM (normal system memory, and SMM) and deliever the clear
mess
Also we change the 2nd parameter of it to be the relative offset
within the memory region. This is to be used in follow up patches.
Signed-off-by: Peter Xu
---
exec.c | 3 ++-
include/exec/ram_addr.h | 2 +-
memory.c| 3 +--
3 files changed, 4 insertions(+), 4 de
When synchronizing dirty bitmap from kernel KVM we do it in a
per-kvmslot fashion and we allocate the userspace bitmap for each of
the ioctl. This patch instead make the bitmap cache be persistent
then we don't need to g_malloc0() every time.
More importantly, the cached per-kvmslot dirty bitmap
These helpers copy the source bitmap to destination bitmap with a
shift either on the src or dst bitmap.
Meanwhile, we never have bitmap tests but we should.
This patch also introduces the initial test cases for utils/bitmap.c
but it only tests the newly introduced functions.
Signed-off-by: Pete
It's obviously obsolete. Do some update.
Signed-off-by: Peter Xu
---
accel/kvm/kvm-all.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/accel/kvm/kvm-all.c b/accel/kvm/kvm-all.c
index 524c4ddfbd..b686531586 100644
--- a/accel/kvm/kvm-all.c
+++ b/accel/kvm/kvm-a
Similar to 9460dee4b2 ("memory: do not touch code dirty bitmap unless
TCG is enabled", 2015-06-05) but for the migration bitmap - we can
skip the MIGRATION bitmap update if migration not enabled.
Reviewed-by: Paolo Bonzini
Reviewed-by: Juan Quintela
Signed-off-by: Peter Xu
---
include/exec/mem
Introduce a new memory region listener hook log_clear() to allow the
listeners to hook onto the points where the dirty bitmap is cleared by
the bitmap users.
Previously log_sync() contains two operations:
- dirty bitmap collection, and,
- dirty bitmap clear on remote site.
Let's take KVM as
cpu_physical_memory_sync_dirty_bitmap() has one RAMBlock* as
parameter, which means that it must be with RCU read lock held
already. Taking it again inside seems redundant. Removing it.
Instead comment on the functions about the RCU read lock.
Reviewed-by: Paolo Bonzini
Reviewed-by: Juan Quinte
It's never used anywhere.
Reviewed-by: Paolo Bonzini
Reviewed-by: Juan Quintela
Signed-off-by: Peter Xu
---
include/exec/memory.h | 17 -
memory.c | 8
2 files changed, 25 deletions(-)
diff --git a/include/exec/memory.h b/include/exec/memory.h
index 9144
v4:
- add r-bs for Dave & Juan
- dropped patch 1 since queued
- fixup misc places in bitmap patch [Dave]
- indent and naming fixes in "pass mr into snapshot_and_clear_dirty"
[Dave]
- allocate kvmslot dirty_bmap on first usage [Dave]
- comment fixup in clear-log split patch [Dave]
v3:
- drop head
Kevin Wolf writes:
> Am 24.05.2019 um 15:29 hat Markus Armbruster geschrieben:
>> Let's add
>>
>>{ 'command': 'test-features',
>> 'data': { 'fs0': 'FeatureStruct0',
>>'fs1': 'FeatureStruct1',
>>'fs2': 'FeatureStruct2',
>>'fs3': 'FeatureStr
On Mon, Jun 03, 2019 at 02:10:34PM +0800, Wei Yang wrote:
> On Mon, Jun 03, 2019 at 02:05:47PM +0800, Wei Yang wrote:
> >On Mon, Jun 03, 2019 at 01:40:13PM +0800, Peter Xu wrote:
> >>
> >>Ah I see, thanks for the pointer. Then I would agree it's fine.
> >>
> >>I'm not an expert of TCG - I'm curiou
On 02.06.19 14:10, Peter Xu wrote:
On Sun, Jun 02, 2019 at 01:42:13PM +0200, Jan Kiszka wrote:
From: Jan Kiszka
Masked entries will not generate interrupt messages, thus do no need to
be routed by KVM. This is a cosmetic cleanup, just avoiding warnings of
the kind
qemu-system-x86_64: vtd_irte
On Mon, Jun 03, 2019 at 02:05:47PM +0800, Wei Yang wrote:
>On Mon, Jun 03, 2019 at 01:40:13PM +0800, Peter Xu wrote:
>>
>>Ah I see, thanks for the pointer. Then I would agree it's fine.
>>
>>I'm not an expert of TCG - I'm curious on why all those three dirty
>>bitmaps need to be set at the very be
Igor,
Do you have some spare time to take a look the general idea?
On Mon, May 13, 2019 at 02:19:04PM +0800, Wei Yang wrote:
>Now MADT is highly depend in architecture and machine type and leaves
>duplicated code in different architecture. The series here tries to generalize
>it.
>
>MADT contains
On Fri, May 31, 2019 at 02:56:21PM +0200, Juan Quintela wrote:
> Peter Xu wrote:
> > According to: https://spdx.org/ids-how, let's still allow QEMU to use
> > the SPDX license identifier:
> >
> > // SPDX-License-Identifier: ***
> >
> > Signed-off-by: Peter Xu
>
> Reviewed-by: Juan Quintela
>
>
On 31/05/2019 09:03, Alexey Kardashevskiy wrote:
>
>
> On 21/05/2019 18:24, Cédric Le Goater wrote:
>> This documents the overall XIVE architecture and the XIVE support for
>> sPAPR guest machines (pseries).
>>
>> It also provides documentation on the 'info pic' command.
>>
>> Signed-off-by: Cédr
On Mon, Jun 03, 2019 at 01:40:13PM +0800, Peter Xu wrote:
>
>Ah I see, thanks for the pointer. Then I would agree it's fine.
>
>I'm not an expert of TCG - I'm curious on why all those three dirty
>bitmaps need to be set at the very beginning. IIUC at least the VGA
>bitmap should not require that
On Mon, Jun 03, 2019 at 11:36:00AM +0800, Wei Yang wrote:
> On Mon, Jun 03, 2019 at 10:35:27AM +0800, Peter Xu wrote:
> >On Mon, Jun 03, 2019 at 09:33:05AM +0800, Wei Yang wrote:
> >> On Sat, Jun 01, 2019 at 11:34:41AM +0800, Peter Xu wrote:
> >> >On Fri, May 31, 2019 at 05:43:37PM +0100, Dr. David
On Mon, Jun 03, 2019 at 10:35:27AM +0800, Peter Xu wrote:
>On Mon, Jun 03, 2019 at 09:33:05AM +0800, Wei Yang wrote:
>> On Sat, Jun 01, 2019 at 11:34:41AM +0800, Peter Xu wrote:
>> >On Fri, May 31, 2019 at 05:43:37PM +0100, Dr. David Alan Gilbert wrote:
>> >> * Wei Yang (richardw.y...@linux.intel.c
On Mon, Jun 03, 2019 at 09:33:05AM +0800, Wei Yang wrote:
> On Sat, Jun 01, 2019 at 11:34:41AM +0800, Peter Xu wrote:
> >On Fri, May 31, 2019 at 05:43:37PM +0100, Dr. David Alan Gilbert wrote:
> >> * Wei Yang (richardw.y...@linux.intel.com) wrote:
> >> > During migration, we would sync bitmap from
how about do switch inside colo_compare_inconsistency_notify(), like:
colo_compare_inconsistency_notify(CompareState *s)
{
if (s->remote_notify)
remote_notify
else
local_notity
}
Thanks
Zhijian
On 6/2/19 11:42 AM, Zhang Chen wrote:
From: Zhang Ch
On Sat, Jun 01, 2019 at 11:34:41AM +0800, Peter Xu wrote:
>On Fri, May 31, 2019 at 05:43:37PM +0100, Dr. David Alan Gilbert wrote:
>> * Wei Yang (richardw.y...@linux.intel.com) wrote:
>> > During migration, we would sync bitmap from ram_list.dirty_memory to
>> > RAMBlock.bmap in cpu_physical_memory
On Sun, Jun 02, 2019 at 01:13:44PM +0100, Mark Cave-Ayland wrote:
> On 28/05/2019 02:09, David Gibson wrote:
>
> > On Fri, May 24, 2019 at 07:53:45AM +0100, Mark Cave-Ayland wrote:
> >> From: Anton Blanchard
> >>
> >> During the conversion these instructions were incorrectly treated as
> >> store
On Mon, Jun 03, 2019 at 02:40:04AM +0300, Liran Alon wrote:
> Any news on when this patch-series is expected to be merged to upstream QEMU?
> It was accepted 2 months ago.
>
> Thanks,
> -Liran
>
> > On 25 Apr 2019, at 20:53, Michael S. Tsirkin wrote:
> >
> > On Thu, Apr 25, 2019 at 09:38:19AM
On Sun, Jun 02, 2019 at 01:42:13PM +0200, Jan Kiszka wrote:
> From: Jan Kiszka
>
> Masked entries will not generate interrupt messages, thus do no need to
> be routed by KVM. This is a cosmetic cleanup, just avoiding warnings of
> the kind
>
> qemu-system-x86_64: vtd_irte_get: detected non-prese
Any news on when this patch-series is expected to be merged to upstream QEMU?
It was accepted 2 months ago.
Thanks,
-Liran
> On 25 Apr 2019, at 20:53, Michael S. Tsirkin wrote:
>
> On Thu, Apr 25, 2019 at 09:38:19AM +0100, Stefan Hajnoczi wrote:
>> On Wed, Apr 24, 2019 at 07:38:57PM +0300, Lir
> Could you run:
> make check-tcg
> And report which tests (if any) fail?
Unfortunately, test was SKIPped:
make check-tcg
make[1]: Вход в каталог `/dev/shm/qemu/slirp'
make[1]: Цель `all' не требует выполнения команд.
make[1]: Выход из каталога `/dev/shm/qemu/slirp'
CHK version_gen.h
Callback-based laio_submit() and laio_cancel() were left after
rewriting Linux AIO backend to coroutines in hope that they would be
used in other code that could bypass coroutines. They can be safely
removed because they have not been used since that time.
Signed-off-by: Julia Suvorova
---
block
Andrew Randrianasulu writes:
> Hello!
>
> I was compiling latest qemu git, and was surprized to find qemu-system-x86_64
> (compiled for 32-bit x86 machine) can't boot any 64-bit kernel anymore.
>
> 32-bit kernels and kvm were fine.
> So, I run git bisect
>
> ./configure --target-list=x86_64-sof
** Tags added: testcase
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1830872
Title:
AARCH64 to ARMv7 mistranslation in TCG
Status in QEMU:
New
Bug description:
The following guest code:
Laszlo Ersek (Red Hat) writes:
> Possibly related:
> [Qemu-devel] "accel/tcg: demacro cputlb" break qemu-system-x86_64
> https://lists.gnu.org/archive/html/qemu-devel/2019-05/msg07362.html
>
> (qemu-system-x86_64 fails to boot 64-bit kernel under TCG accel when
> QEMU is built for i686)
>
> Not
Mateja Marjanovic writes:
> From: Mateja Marjanovic
>
> Eliminate loops for better performance.
Have you done any measurements of the bellow loop unrolling? Because
this is something that maybe we can achieve and let the compiler make
the choice.
>
> Signed-off-by: Mateja Marjanovic
> ---
>
On 28/05/2019 02:09, David Gibson wrote:
> On Fri, May 24, 2019 at 07:53:45AM +0100, Mark Cave-Ayland wrote:
>> From: Anton Blanchard
>>
>> During the conversion these instructions were incorrectly treated as
>> stores. We need to use set_cpu_vsr* and not get_cpu_vsr*.
>>
>> Fixes: 8b3b2d75c7c0 (
On Sun, Jun 02, 2019 at 01:42:13PM +0200, Jan Kiszka wrote:
> From: Jan Kiszka
>
> Masked entries will not generate interrupt messages, thus do no need to
> be routed by KVM. This is a cosmetic cleanup, just avoiding warnings of
> the kind
>
> qemu-system-x86_64: vtd_irte_get: detected non-prese
Rather than perform the VSR register decoding within the helper itself,
introduce a new GEN_VSX_HELPER_R2_AB macro which performs the decode based
upon rA and rB at translation time.
Signed-off-by: Mark Cave-Ayland
Reviewed-by: Richard Henderson
---
target/ppc/fpu_helper.c | 10
Introduce a new GEN_VSX_HELPER_VSX_MADD macro for the generator function which
enables the source and destination registers to be decoded at translation time.
This enables the determination of a or m form to be made at translation time so
that a single helper function can now be used for both vari
Signed-off-by: Mark Cave-Ayland
Reviewed-by: Richard Henderson
---
target/ppc/helper.h | 8 +++
target/ppc/mem_helper.c | 6 ++---
target/ppc/translate/vsx-impl.inc.c | 47 +++--
3 files changed, 30 insertions(+), 31 deletions(-)
Signed-off-by: Mark Cave-Ayland
Reviewed-by: Richard Henderson
---
target/ppc/helper.h | 4 ++--
target/ppc/int_helper.c | 12
target/ppc/translate/vsx-impl.inc.c | 10 +-
3 files changed, 11 insertions(+), 15 deletions(-)
diff --git a/target/pp
From: Jan Kiszka
Masked entries will not generate interrupt messages, thus do no need to
be routed by KVM. This is a cosmetic cleanup, just avoiding warnings of
the kind
qemu-system-x86_64: vtd_irte_get: detected non-present IRTE (index=0,
high=0xff00, low=0x100)
if the masked entry happens to
Rather than perform the VSR register decoding within the helper itself,
introduce a new GEN_VSX_HELPER_R2 macro which performs the decode based
upon rD and rB at translation time.
Signed-off-by: Mark Cave-Ayland
---
target/ppc/fpu_helper.c | 30 -
target/p
Rather than perform the VSR register decoding within the helper itself,
introduce a new GEN_VSX_HELPER_R3 macro which performs the decode based
upon rD, rA and rB at translation time.
Signed-off-by: Mark Cave-Ayland
---
target/ppc/fpu_helper.c | 36 ---
Since commit 8a14d31b00 "target/ppc: switch fpr/vsrl registers so all VSX
registers are in host endian order" functions getVSR() and putVSR() which used
to convert the VSR registers into host endian order are no longer required.
Now that there are now no more users of getVSR()/putVSR() these funct
With the conversion of PPC VSX registers to host endian during the 4.0
development
cycle, the VSX helpers getVSR() and putVSR() which were used to convert between
big
endian and host endian (and are currently just a no-op) can now be removed. This
eliminates an extra copy for each VSX source regi
Rather than perform the VSR register decoding within the helper itself,
introduce a new GEN_VSX_HELPER_X3 macro which performs the decode based
upon xT, xA and xB at translation time.
With the previous changes to the VSX_CMP generator and helper macros the
opcode parameter is no longer required in
Since commit 8a14d31b00 "target/ppc: switch fpr/vsrl registers so all VSX
registers are in host endian order" functions getVSR() and putVSR() which used
to convert the VSR registers into host endian order are no longer required.
Signed-off-by: Mark Cave-Ayland
---
target/ppc/fpu_helper.c | 762 +
Rather than perform the VSR register decoding within the helper itself,
introduce a new VSX_CMP macro which performs the decode based upon xT, xA
and xB at translation time.
Subsequent commits will make the same changes for other instructions however
the xvcmp* instructions are different in that t
Rather than perform the VSR register decoding within the helper itself,
introduce a new GEN_VSX_HELPER_X1 macro which performs the decode based
upon xB at translation time.
Signed-off-by: Mark Cave-Ayland
---
target/ppc/fpu_helper.c | 6 ++
target/ppc/helper.h |
Rather than perform the VSR register decoding within the helper itself,
introduce a new GEN_VSX_HELPER_X2 macro which performs the decode based
upon xT and xB at translation time.
With the previous change to the xscvqpdp generator and helper functions the
opcode parameter is no longer required in
Rather than perform the VSR register decoding within the helper itself,
introduce a new GEN_VSX_HELPER_X2_AB macro which performs the decode based
upon xA and xB at translation time.
Signed-off-by: Mark Cave-Ayland
---
target/ppc/fpu_helper.c | 15 ++-
target/ppc/helper.h
Rather than perform the VSR register decoding within the helper itself,
introduce a new generator and helper function which perform the decode based
upon xT and xB at translation time.
The xscvqpdp helper is the only 2 parameter xT/xB implementation that requires
the opcode to be passed as an addi
Since commit 8a14d31b00 "target/ppc: switch fpr/vsrl registers so all VSX
registers are in host endian order" functions getVSR() and putVSR() which used
to convert the VSR registers into host endian order are no longer required.
Signed-off-by: Mark Cave-Ayland
---
target/ppc/mem_helper.c | 25 ++
Possibly related:
[Qemu-devel] "accel/tcg: demacro cputlb" break qemu-system-x86_64
https://lists.gnu.org/archive/html/qemu-devel/2019-05/msg07362.html
(qemu-system-x86_64 fails to boot 64-bit kernel under TCG accel when
QEMU is built for i686)
Note to self: try to reprodouce the present issue wi
On Mon, 2019-04-15 at 16:57 +0300, Maxim Levitsky wrote:
> CC: Fam Zheng
> CC: Kevin Wolf
> CC: Max Reitz
> CC: qemu-devel@nongnu.org
>
>
> Hi!
> These are few assorted fixes and features for the userspace
> nvme driver.
>
> Tested that on my laptop with my Samsung X5 thunderbolt drive, which
Public bug reported:
With a freshly compiled version of qemu 4.0.50 on Windows 10 (host)
I am using 3 different Belgian keyboards and I have the same behaviour
- 2 USB keyboards (Logitech and HP) and
- the keyboard of my laptop (HP)
3 characters on the same key cannot be used (the key seams to b
On Jun 1, 2019 4:16 PM, "Aleksandar Markovic"
wrote:
>
> > From: Mateja Marjanovic
> > Sent: Monday, March 4, 2019 5:51 PM
> > To: qemu-devel@nongnu.org
> > Cc: aurel...@aurel32.net; Aleksandar Markovic; Aleksandar Rikalo
> > Subject: [PATCH 1/2] target/mips: Improve performance for MSA binary
op
>
> hw/net/e1000e_core.h
> hw/net/e1000x_common.h
> hw/net/vmxnet3_defs.h
Unintentional.
Reviewed-by: Dmitry Fleytman
> On 28 May 2019, at 19:40, Philippe Mathieu-Daudé wrote:
>
> Since the BusState is accesible from the SCSIBus object,
> it is pointless to use qbus_reset_all_fn.
> Use qbus_reset_all() directly.
>
> Signed-off-by: Philippe Mathieu-Daudé
> ---
> v2: Use BUS() macr
59 matches
Mail list logo
