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.
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
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
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
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
> >>
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
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,
> 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
---
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
** 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)
>
>
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
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
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
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
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 -
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
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
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
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
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 ++-
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
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
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
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,
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
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
>
> 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()
40 matches
Mail list logo
