On 19/07/2019 15.26, Philippe Mathieu-Daudé wrote:
> On 7/19/19 10:26 AM, Michael Rolnik wrote:
[...]
>> diff --git a/tests/boot-serial-test.c b/tests/boot-serial-test.c
>> index 24852d4c7d..73d273b73f 100644
>> --- a/tests/boot-serial-test.c
>> +++ b/tests/boot-serial-test.c
>> @@ -16,6 +16,17 @@
commit a6f230c move blockbackend back to main AioContext on unplug. It set the
AioContext of
SCSIDevice to the main AioContex, but s->ctx is still the iothread AioContex（if
the scsi controller
is configure with iothread）. So if there are having in-flight requests during
unplug, a failing asserti
On 20/07/2019 11.42, Philippe Mathieu-Daudé wrote:
> On 7/20/19 8:39 AM, Markus Armbruster wrote:
>> Consider hw/tpm/trace-events
>>
>> # tpm_crb.c
>> tpm_crb_mmio_read(uint64_t addr, unsigned size, uint32_t val) "CRB read
>> 0x" TARGET_FMT_plx " len:%u val: 0x%" PRIx32
>> tpm_crb_mmio
Patchew URL:
https://patchew.org/QEMU/1563693178-23328-1-git-send-email-lizhen...@huawei.com/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Message-id: 1563693178-23328-1-git-send-email-lizhen...@huawei.com
Type: series
Subject: [Qemu-devel]
commit a6f230c move blockbackend back to main AioContext on unplug. It set the
AioContext of
SCSIDevice to the main AioContex, but s->ctx is still the iothread AioContex（if
the scsi controller
is configure with iothread）. So if there are having in-flight requests during
unplug, a failing asserti
On Fri, 2019-07-19 at 11:51 +0200, Max Reitz wrote:
> On 16.07.19 18:30, Maxim Levitsky wrote:
> > This is reduced version of patch series for userspace nvme driver,
> > that only includes the bugfixes I made.
> >
> > Best regards,
> > Maxim Levitsky
> >
> > Maxim Levitsky (3):
> > block/nv
On Fri, 2019-07-19 at 12:28 +0200, Max Reitz wrote:
> On 16.07.19 18:19, Maxim Levitsky wrote:
> > preallocation=off and preallocation=metadata
> > both allocate luks header only, and preallocation=falloc/full
> > is passed to underlying file.
> >
> > Fixes: https://bugzilla.redhat.com/show_bug.cg
On 03.06.19 02:36, Michael S. Tsirkin 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
>>
>>
From: Jan Kiszka
nb_queue was not zeroed so that we no longer delivered events if a
previous guest left the device in an overflow state.
The state of absolute does not matter as the next vmmouse_update_handler
call will align it again.
Signed-off-by: Jan Kiszka
---
hw/i386/vmmouse.c | 1 +
1
From: Zhang Chen
This patch to fix the origin "char *data" memory leak, code style issue
and add necessary check here.
Reported-by: Coverity (CID 1402785)
Signed-off-by: Zhang Chen
---
net/colo-compare.c | 28 +---
1 file changed, 21 insertions(+), 7 deletions(-)
diff
Sorry, I re-sent the old version.
Please redirect to V4 patch.
Thanks
Zhang Chen
> -Original Message-
> From: Zhang, Chen
> Sent: Thursday, July 18, 2019 5:22 PM
> To: Li Zhijian ; Peter Maydell
> ; Jason Wang ; qemu-dev
>
> Cc: Zhang Chen ; Zhang, Chen
> Subject: [PATCH V3] net/colo-co
On Sun, Jul 21, 2019 at 10:58:42AM +0200, Jan Kiszka wrote:
> On 03.06.19 02:36, Michael S. Tsirkin 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.
On 2019-07-16 08:23, Markus Armbruster wrote:
"Kővágó, Zoltán" writes:
Signed-off-by: Kővágó, Zoltán
---
ui/vnc.h| 2 ++
monitor/misc.c | 12 +++-
ui/vnc.c| 15 ++-
hmp-commands.hx | 13 -
qemu-options.hx | 6 ++
5 files changed, 4
Am 09.07.2019 um 10:25 schrieb Peter Maydell:
> On Mon, 8 Jul 2019 at 20:39, Aleksandar Markovic
> wrote:
>> They are all real issues. Two of them are cases of missing
>> '/* fall through */' (I plan to send fixes for them in 4.2 timeframe)
>> and five of them are cases of missing 'break' (I plan
On 21/07/19 12:04, Michael S. Tsirkin wrote:
> On Sun, Jul 21, 2019 at 10:58:42AM +0200, Jan Kiszka wrote:
>> On 03.06.19 02:36, Michael S. Tsirkin wrote:
>>> On Sun, Jun 02, 2019 at 01:42:13PM +0200, Jan Kiszka wrote:
From: Jan Kiszka
Masked entries will not generate interrupt mess
On 21/07/19 02:33, Wei Yang wrote:
> On Thu, Jul 18, 2019 at 09:04:55AM +0800, Wei Yang wrote:
>> The value left in nr is the number of bits for the last word, which
>> could be calculate the last word mask directly.
>>
>> Remove the unnecessary size.
>>
>
> May I ask why Patch 2 is picked up, but
These are attempts to improve a bit error message
based on bunch of luks related bugzillas assigned to me.
Feel free to reject these if you think that it doesn't
make the messages better.
Best regards,
Maxim Levitsky
Maxim Levitsky (2):
LUKS: better error message when creating too large
Currently we print message like that:
"
new_file.qcow2 : error message
"
However the error could have come from opening the backing file (e.g when it
missing encryption keys),
thus try to clarify this by using this format:
"
qemu-img: error creating new_file.qcow2: base_file.qcow2: error messag
Currently if you attampt to create too large file with luks you
get the following error message:
Formatting 'test.luks', fmt=luks size=17592186044416 key-secret=sec0
qemu-img: test.luks: Could not resize file: File too large
While for raw format the error message is
qemu-img: test.img: The image
On 17/07/2019 07:10, tony.ngu...@bt.com wrote:
> This bit configures endianness of PCI MMIO devices. It is used by
> Solaris and OpenBSD sunhme drivers.
>
> Tested working on OpenBSD.
>
> Unfortunately Solaris 10 had a unrelated keyboard issue blocking
> testing... another inch towards Solaris 1
We can reproduce this problem with Linux guests as well (running 4.15
Ubuntu Xenial and 4.14 Android kernels). Mac models with integrated GPU
seem to be more affected according to our testing, and the crash does
not always occur, needs multiple tries to be triggered. We would be
happy to assist in
On Sun, Jul 21, 2019 at 07:27:14PM +0200, Paolo Bonzini wrote:
>On 21/07/19 02:33, Wei Yang wrote:
>> On Thu, Jul 18, 2019 at 09:04:55AM +0800, Wei Yang wrote:
>>> The value left in nr is the number of bits for the last word, which
>>> could be calculate the last word mask directly.
>>>
>>> Remove
> -Original Message-
> From: Xu, Tao3
> Sent: Tuesday, July 16, 2019 10:51 PM
> To: imamm...@redhat.com; ebl...@redhat.com; ehabk...@redhat.com
> Cc: Xu, Tao3 ; Liu, Jingqi ;
> Williams, Dan J ;
> jonathan.came...@huawei.com; Du, Fan ; qemu-devel@nongnu.org
> Subject: [PATCH v7 05/11] numa
> -Original Message-
> From: Xu, Tao3
> Sent: Tuesday, July 16, 2019 10:51 PM
> To: imamm...@redhat.com; ebl...@redhat.com; ehabk...@redhat.com
> Cc: Xu, Tao3 ; Liu, Jingqi ;
> Williams, Dan J ;
> jonathan.came...@huawei.com; Du, Fan ; qemu-devel@nongnu.org
> Subject: [PATCH v7 11/11] test
On 7/19/2019 4:10 PM, Paolo Bonzini wrote:
On 19/07/19 09:20, Jing Liu wrote:
Then CPUID[7,0].EAX is set automatically to 0 or 1 depending on whether
BF16 is enabled or not.
Could I ask why don't we directly check BF16 enabling when
cpu_x86_cpuid(env, 7, 0, ...) during kvm_arch_init_vcpu ?
On Fri, Jul 19, 2019 at 06:01:19PM +0200, David Hildenbrand wrote:
> "host_page_base" is really confusing, let's make this clearer, also
> rename the other offsets to indicate to which base they apply.
>
> offset -> mr_offset
> ram_offset -> rb_offset
> host_page_base -> rb_aligned_offset
>
> Whi
On Fri, Jul 19, 2019 at 06:01:18PM +0200, David Hildenbrand wrote:
> Let's simplify this - the case we are optimizing for is very hard to
> trigger and not worth the effort. If we're switching from inflation to
> deflation, let's reset the pbp.
>
> Signed-off-by: David Hildenbrand
Acked-by: Davi
On Fri, Jul 19, 2019 at 06:01:20PM +0200, David Hildenbrand wrote:
> Using the address of a RAMBlock to test for a matching pbp is not really
> safe. Instead, let's use the guest physical address of the base page
> along with the page size (via the number of subpages).
>
> While at it, move "struc
Move the define of target access alignment earlier from
target/foo/cpu.h to configure.
Suggested in Richard Henderson's reply to "[PATCH 1/4] tcg: TCGMemOp
is now accelerator independent MemOp"
Analysed target/foo/cpu.h for more candidates to define earlier but
did not s
On Fri, Jul 19, 2019 at 03:00:13AM +0800, Kirti Wankhede wrote:
>
>
> On 7/12/2019 8:22 AM, Yan Zhao wrote:
> > On Tue, Jul 09, 2019 at 05:49:17PM +0800, Kirti Wankhede wrote:
> >> Flow during _RESUMING device state:
> >> - If Vendor driver defines mappable region, mmap migration region.
> >> - L
Move the define of target access alignment earlier from
target/foo/cpu.h to configure.
Signed-off-by: Tony Nguyen
---
configure | 10 +-
include/exec/poison.h | 1 +
include/qom/cpu.h | 2 +-
target/alpha/cpu.h| 2 --
target/hppa/cpu.h | 1 -
target/mips/cpu.h
Signed-off-by: Tony Nguyen
---
configure | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/configure b/configure
index 8316a16..c07687c 100755
--- a/configure
+++ b/configure
@@ -7433,7 +7433,7 @@ esac
target_bigendian="no"
case "$target_name" in
armeb|aarch64_be|hppa|lm32
Writing the nested state e.g. after a vmport access can invalidate
important parts of the kernel-internal state, and it is not needed as
well. So leave this out from KVM_PUT_RUNTIME_STATE.
Suggested-by: Paolo Bonzini
Signed-off-by: Jan Kiszka
---
target/i386/kvm.c | 10 +-
1 file change
[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/1829964
Title:
HOST VRAM L
Public bug reported:
Host info:
==
x86-64, Ubuntu 18.04, QEMU 4.0.0 (downloaded tarball from main site)
Guest info:
===
ARM7l, Raspbian OS off the main raspberry pi site
QEMU command:
=
qemu-system-arm -M raspi2 -kernel bootpart/kernel7.img -dtb
bootpart/bcm2709-rpi-
On 16/07/2019 15:35, Alexey Kardashevskiy wrote:
SLOF implements one itself so let's remove it from QEMU. It is one less
image and simpler setup as the RTAS blob never stays in its initial place
anyway as the guest OS always decides where to put it.
This totally depends on https://patchwork.o
Waking from suspend is not logically a machine reset on all machines,
particularly in the paravirtualized case rather than hardware
emulated. The ppc spapr machine for example just invokes hypervisor
to suspend, and expects that call to return with the machine in the
same state (modulo some possibl
Hi, this series is rebased on top of the qmp event fix, and takes
Paolo's suggestion to implement ->wakeup for i386 before adding
ppc, which makes it much nicer.
If the first two patches can be agreed on initially and merged, I
can take the third patch through the ppc list after that.
Thanks,
Nic
Hi, this series is rebased on top of the qmp event fix, and takes
Paolo's suggestion to implement ->wakeup for i386 before adding
ppc, which makes it much nicer.
If the first two patches can be agreed on initially and merged, I
can take the third patch through the ppc list after that.
Thanks,
Nic
Waking from suspend is not logically a machine reset on all machines,
particularly in the paravirtualized case rather than hardware
emulated. The ppc spapr machine for example just invokes hypervisor
to suspend, and expects that call to return with the machine in the
same state (modulo some possibl
Move the i386 suspend_wakeup logic out of the fallback path, and into
the new ->wakeup method.
Signed-off-by: Nicholas Piggin
---
hw/i386/pc.c | 8
vl.c | 2 --
2 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index 549c437050..78c03d7f9
This has been useful to modify and test the Linux pseries suspend
code but it requires modification to the guest to call it (due to
being gated by other unimplemented features). It is not otherwise
used by Linux yet, but work is slowly progressing there.
This allows a (lightly modified) guest kern
multifd_load_cleanup() always return 0 and never use the errp, just
cleanup a little.
Signed-off-by: Wei Yang
---
migration/migration.c | 9 ++---
migration/ram.c | 7 +++
migration/ram.h | 2 +-
3 files changed, 6 insertions(+), 12 deletions(-)
diff --git a/migration/migrat
On Fri, Jul 19, 2019 at 06:41:28PM +0100, Dr. David Alan Gilbert wrote:
>* Wei Yang (richardw.y...@linux.intel.com) wrote:
>> Even we need to do discard for each RAMBlock, we still can leverage the
>> same memory space to store the information.
>>
>> By doing so, we avoid memory allocation and dea
44 matches
Mail list logo
