On 7/24/20 7:43 AM, Philippe Mathieu-Daudé wrote:
> Hi,
>
> [cross list post]
>
> Using QEMU at commit 3cbc8970f5 I'm getting this error:
>
> Fetching assets from tests/acceptance/boot_linux_console.py.
> Fetching assets from tests/acceptance/boot_linux.py.
> Traceback (most recent call last):
Hi,
[cross list post]
Using QEMU at commit 3cbc8970f5 I'm getting this error:
Fetching assets from tests/acceptance/boot_linux_console.py.
Fetching assets from tests/acceptance/boot_linux.py.
Traceback (most recent call last):
File "/usr/lib64/python3.7/runpy.py", line 193, in
Hi:
It's not clear to me:
- Is the hang happen on the host or L1 guest?
- Is qemu 5.1-rc0 used on the host or L1 guest?
- When did you see the hung, just after launching the guest?
- Can you use gdb to get a calltrace of qemu when you see the hang?
- What's the version of kernel in L1 and L2
The SRST implementation did not keep up with the rest of IDE; it is
possible to perform a weak reset on an IDE device to remove the BSY/DRQ
bits, and then issue writes to the control/device registers which can
cause chaos with the state machine.
Fix that by actually performing a real reset.
The goal of this series is to fix the Software Reset (SRST) routine.
That said, the first six patches are almost entirely unrelated...
Patches 2, 3, and 6 fix extremely minor deviations from the spec I
noticed while researching SRST. (One of them gets rid of a FIXME from
2003.)
Patches 1, 4, and
I have been staring at this FIXME for years and I never knew what it
meant. I finally stumbled across it!
When writing to the command registers, the old value is shifted into a
HOB copy of the register and the new value is written into the primary
register. When reading registers, the value
(In QEMU, we call this the "select" register.)
My memory isn't good enough to memorize what these magic runes
do. Label them to prevent mixups from happening in the future.
Side note: I assume it's safe to always set 0xA0 even though ATA2 claims
these bits are reserved, because ATA3 immediately
Not known to fix any bug, but I couldn't help but notice that ATA
specifies that writing to this register should clear an interrupt.
ATA7: Section 5.3.3 (Command register - Effect)
ATA6: Section 7.4.4 (Command register - Effect)
ATA5: Section 7.4.4 (Command register - Effect)
ATA4: Section 7.4.4
Reorder these just a pinch to make them more obvious at a glance what
the addressing mode is.
Signed-off-by: John Snow
---
hw/ide/core.c | 26 +++---
1 file changed, 15 insertions(+), 11 deletions(-)
diff --git a/hw/ide/core.c b/hw/ide/core.c
index a880b91b47..f35864070b
In real ISA operation, register writes go out to an entire bus channel
and all listening devices receive the write. The devices do not toggle
the DEV bit based on their own configuration, nor does the HBA
intermediate or tamper with that value.
The reality of the matter is that DEV0/DEV1
It's the Control register, part of the Control block -- Command is
misleading here. Rename all related functions and constants.
Signed-off-by: John Snow
---
include/hw/ide/internal.h | 9 +
hw/ide/core.c | 12 ++--
hw/ide/ioport.c | 2 +-
hw/ide/macio.c
24.07.2020 00:30, Eric Blake wrote:
On 2/17/20 9:02 AM, Vladimir Sementsov-Ogievskiy wrote:
Keep bitmap state for disabled bitmaps too. Keep the state until the
end of the process. It's needed for the following commit to implement
bitmap postcopy canceling.
To clean-up the new list the
On Thu, Jul 23, 2020 at 04:12:20PM +0530, Ravi Bangoria wrote:
> As per the PAPR, bit 0 of byte 64 in pa-features property indicates
> availability of 2nd DAWR registers. i.e. If this bit is set, 2nd
> DAWR is present, otherwise not. Use KVM_CAP_PPC_DAWR1 capability to
> find whether kvm supports
vmulhsw: Vector Multiply High Signed Word
vmulhuw: Vector Multiply High Unsigned Word
Signed-off-by: Lijun Pan
---
v4/v5: no change
Reviewed-by: Richard Henderson
v3: inline the helper_vmulh{su}w multiply directly instead of using macro
v2: fix coding style
use Power ISA 3.1 flag
Group vmuluwm and vmulld. Make vmulld-specific
changes since it belongs to new ISA 3.1.
Signed-off-by: Lijun Pan
---
v5: no change
v4: add missing changes, and split to 5/11, 6/11, 7/11
v3: use tcg_gen_gvec_mul()
v2: fix coding style
use Power ISA 3.1 flag
tcg/ppc/tcg-target.h | 2 ++
vdivsw: Vector Divide Signed Word
vdivuw: Vector Divide Unsigned Word
vdivsd: Vector Divide Signed Doubleword
vdivud: Vector Divide Unsigned Doubleword
vmodsw: Vector Modulo Signed Word
vmoduw: Vector Modulo Unsigned Word
vmodsd: Vector Modulo Signed Doubleword
vmodud: Vector Modulo Unsigned
vmulhsd: Vector Multiply High Signed Doubleword
vmulhud: Vector Multiply High Unsigned Doubleword
Signed-off-by: Lijun Pan
---
v4/v5: no change
Reviewed-by: Richard Henderson
v3: simplify helper_vmulh{su}d
v2: fix coding style
use Power ISA 3.1 flag
target/ppc/helper.h |
vmsumudm (Power ISA 3.0) - Vector Multiply-Sum Unsigned Doubleword Modulo
VA-form.
vmsumcud (Power ISA 3.1) - Vector Multiply-Sum & write Carry-out Unsigned
Doubleword VA-form.
Signed-off-by: Lijun Pan
---
v5: update instruction flag for vmsumcud.
integrate into this isa3.1 patch series
v3:
Add PPC2_FEATURE2_ARCH_3_10 to the PowerPC AT_HWCAP2 definitions.
Signed-off-by: Lijun Pan
---
v5: match the definition with that in linux's
arch/powerpc/include/uapi/asm/cputable.h
v4: add missing changes, and split to 5/11, 6/11, 7/11
v3: use tcg_gen_gvec_mul()
v2: fix coding style
use
This patch series add several newly introduced 32/64-bit vector
instructions in Power ISA 3.1. Power ISA 3.1 flag is introduced in
this version. In v4 version, coding style issues are fixed, community
reviews/suggestions are taken into consideration. 1/11 - 5/11 of v4 were
accepted by David
Hmm, let's see ... the work-arounds for old Mac OS X versions have been
removed here:
https://git.qemu.org/?p=qemu.git;a=commitdiff;h=483644c25b932360018
It mentiones that this commit has broken compilation earlier:
https://git.qemu.org/?p=qemu.git;a=commitdiff;h=50290c002c045280f8d
... so the
I believe the VSI itself is QEMU based but don't know the version or
details but suspect it's 4.1 based. We compile our own QEMU version for
use with Kata and that's where we're now using 5.1.0-rc1 with the above
commit reverted.
Host Kernel is ... 4.15.0-101-generic if that helps
re: cpu --
On 23/07/2020 21.24, Peter Maydell wrote:
> virtio-input-hid.c undefines CONFIG_CURSES before including
> ui/console.h. However since commits e2f82e924d057935 and b0766612d16da18
> that header does not have behaviour dependent on CONFIG_CURSES.
> Remove the now-unneeded undef.
>
> Signed-off-by:
On 2020/7/23 下午6:36, Peter Maydell wrote:
On Wed, 22 Jul 2020 at 10:00, Jason Wang wrote:
In loopback mode, e1000e RX can DMA into TX doorbell which requires
TX to be reentrant. This patch make e1000e's TX routine reentrant by
introducing a per device boolean for recording whether or not a
On 7/23/20 7:47 PM, LIU Zhiwei wrote:
>
>
> On 2020/7/24 8:28, Richard Henderson wrote:
>> If a 32-bit input is not properly nanboxed, then the input is
>> replaced with the default qnan.
>>
>> Signed-off-by: Richard Henderson
>> ---
>> target/riscv/internals.h | 11 +++
>>
On 7/23/20 7:35 PM, LIU Zhiwei wrote:
>
>
> On 2020/7/24 8:28, Richard Henderson wrote:
>> Make sure that all results from single-precision scalar helpers
>> are properly nan-boxed to 64-bits.
>>
>> Signed-off-by: Richard Henderson
>> ---
>> target/riscv/internals.h | 5 +
>>
On Sat, Jul 25, 2020 at 10:53:03AM Hogan Wang wrote:
> * Michael S. Tsirkin (m...@redhat.com) wrote:
> > On Thu, Jul 23, 2020 at 02:12:54PM +0100, Dr. David Alan Gilbert wrote:
> > > * Michael S. Tsirkin (m...@redhat.com) wrote:
> > > > On Thu, Jul 23, 2020 at 08:53:03PM +0800, Hogan Wang wrote:
>
At least some s390 cpu models support "Protected Virtualization" (PV),
a mechanism to protect guests from eavesdropping by a compromised
hypervisor.
This is similar in function to other mechanisms like AMD's SEV and
POWER's PEF, which are controlled bythe "host-trust-limitation"
machine option.
We haven't yet implemented the fairly involved handshaking that will be
needed to migrate PEF protected guests. For now, just use a migration
blocker so we get a meaningful error if someone attempts this (this is the
same approach used by AMD SEV).
Signed-off-by: David Gibson
---
This allows failures to be reported richly and idiomatically.
Signed-off-by: David Gibson
Reviewed-by: Philippe Mathieu-Daudé
Reviewed-by: Richard Henderson
---
accel/kvm/kvm-all.c | 4 +++-
include/exec/host-trust-limitation.h | 2 +-
target/i386/sev.c|
Some upcoming POWER machines have a system called PEF (Protected
Execution Facility) which uses a small ultravisor to allow guests to
run in a way that they can't be eavesdropped by the hypervisor. The
effect is roughly similar to AMD SEV, although the mechanisms are
quite different.
Most of the
The default behaviour for virtio devices is not to use the platforms normal
DMA paths, but instead to use the fact that it's running in a hypervisor
to directly access guest memory. That doesn't work if the guest's memory
is protected from hypervisor access, such as with AMD's SEV or POWER's PEF.
Several architectures have mechanisms which are designed to protect guest
memory from interference or eavesdropping by a compromised hypervisor. AMD
SEV does this with in-chip memory encryption and Intel has a similar
mechanism. POWER's Protected Execution Framework (PEF) accomplishes a
similar
A number of hardware platforms are implementing mechanisms whereby the
hypervisor does not have unfettered access to guest memory, in order
to mitigate the security impact of a compromised hypervisor.
AMD's SEV implements this with in-cpu memory encryption, and Intel has
its own memory encryption
The kvm_memcrypt_enabled() and kvm_memcrypt_encrypt_data() helper functions
don't conceptually have any connection to KVM (although it's not possible
in practice to use them without it).
They also rely on looking at the global KVMState. But the same information
is available from the machine, and
Currently the "memory-encryption" property is only looked at once we get to
kvm_init(). Although protection of guest memory from the hypervisor isn't
something that could really ever work with TCG, it's not conceptually tied
to the KVM accelerator.
In addition, the way the string property is
At the moment AMD SEV sets a special function pointer, plus an opaque
handle in KVMState to let things know how to encrypt guest memory.
Now that we have a QOM interface for handling things related to host trust
limitation, use a QOM method on that interface, rather than a bare function
pointer
When the "memory-encryption" property is set, we also disable KSM
merging for the guest, since it won't accomplish anything.
We want that, but doing it in the property set function itself is
thereoretically incorrect, in the unlikely event of some configuration
environment that set the property
On 2020/7/24 8:28, Richard Henderson wrote:
If a 32-bit input is not properly nanboxed, then the input is
replaced with the default qnan.
Signed-off-by: Richard Henderson
---
target/riscv/internals.h | 11 +++
target/riscv/fpu_helper.c | 64 ---
On 2020/7/24 8:28, Richard Henderson wrote:
Make sure that all results from inline single-precision scalar
operations are properly nan-boxed to 64-bits.
Signed-off-by: Richard Henderson
---
target/riscv/insn_trans/trans_rvf.inc.c | 4
1 file changed, 4 insertions(+)
diff --git
On 2020/7/24 8:28, Richard Henderson wrote:
Do not depend on the RVD extension, take input and output via
TCGv_i64 instead of fpu regno. Move the function to translate.c
so that it can be used in multiple trans_*.inc.c files.
Signed-off-by: Richard Henderson
---
On 2020/7/24 8:28, Richard Henderson wrote:
Make sure that all results from single-precision scalar helpers
are properly nan-boxed to 64-bits.
Signed-off-by: Richard Henderson
---
target/riscv/internals.h | 5 +
target/riscv/fpu_helper.c | 42 +--
On 2020/7/24 8:28, Richard Henderson wrote:
This is my take on Liu Zhiwei's patch set:
https://patchew.org/QEMU/20200626205917.4545-1-zhiwei_...@c-sky.com
This differs from Zhiwei's v1 in:
* If a helper is involved, the helper does the boxing and unboxing.
* Which leaves only LDW and
On 200722 2339, Alexander Bulekov wrote:
> This is a generic fuzzer designed to fuzz a virtual device's
> MemoryRegions, as long as they exist within the Memory or Port IO (if it
> exists) AddressSpaces. The fuzzer's input is interpreted into a sequence
> of qtest commands (outb, readw, etc). The
On 7/23/20 7:58 AM, Markus Armbruster wrote:
Help is a bit awkward when no TPM types are built into QEMU:
$ upstream-qemu -tpmdev nonexistent,id=tpm0
I hope you don't mind me replacing 'upstream-qemu' with
'x86_64-softmmu/qemu-system-x86_64'?
upstream-qemu: -tpmdev
From: LIU Zhiwei
Signed-off-by: LIU Zhiwei
Message-Id: <20200626205917.4545-5-zhiwei_...@c-sky.com>
Signed-off-by: Richard Henderson
---
target/riscv/insn_trans/trans_rvd.inc.c | 8
target/riscv/insn_trans/trans_rvf.inc.c | 8
2 files changed, 8 insertions(+), 8 deletions(-)
If a 32-bit input is not properly nanboxed, then the input is replaced
with the default qnan. The only inline expansion is for the sign-changing
set of instructions: FSGNJ.S, FSGNJX.S, FSGNJN.S.
Signed-off-by: Richard Henderson
---
target/riscv/insn_trans/trans_rvf.inc.c | 71
Make sure that all results from inline single-precision scalar
operations are properly nan-boxed to 64-bits.
Signed-off-by: Richard Henderson
---
target/riscv/insn_trans/trans_rvf.inc.c | 4
1 file changed, 4 insertions(+)
diff --git a/target/riscv/insn_trans/trans_rvf.inc.c
Do not depend on the RVD extension, take input and output via
TCGv_i64 instead of fpu regno. Move the function to translate.c
so that it can be used in multiple trans_*.inc.c files.
Signed-off-by: Richard Henderson
---
target/riscv/insn_trans/trans_rvf.inc.c | 16 +---
From: LIU Zhiwei
Use tcg_gen_extu_tl_i64 to avoid the ifdef.
Signed-off-by: LIU Zhiwei
Message-Id: <20200626205917.4545-7-zhiwei_...@c-sky.com>
Signed-off-by: Richard Henderson
---
target/riscv/insn_trans/trans_rvf.inc.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git
Make sure that all results from single-precision scalar helpers
are properly nan-boxed to 64-bits.
Signed-off-by: Richard Henderson
---
target/riscv/internals.h | 5 +
target/riscv/fpu_helper.c | 42 +--
2 files changed, 28 insertions(+), 19
If a 32-bit input is not properly nanboxed, then the input is
replaced with the default qnan.
Signed-off-by: Richard Henderson
---
target/riscv/internals.h | 11 +++
target/riscv/fpu_helper.c | 64 ---
2 files changed, 57 insertions(+), 18 deletions(-)
This is my take on Liu Zhiwei's patch set:
https://patchew.org/QEMU/20200626205917.4545-1-zhiwei_...@c-sky.com
This differs from Zhiwei's v1 in:
* If a helper is involved, the helper does the boxing and unboxing.
* Which leaves only LDW and FSGN*.S as the only instructions that
are
On 2/17/20 9:02 AM, Vladimir Sementsov-Ogievskiy wrote:
iotest 40 works too long because of many discard opertion. On the same
I'm assuming you meant s/40/199/ here, as well as the typo fixes pointed
out by Andrey.
time, postcopy period is very short, in spite of all these efforts.
So,
On 2/17/20 9:02 AM, Vladimir Sementsov-Ogievskiy wrote:
Test wants force bitmap postcopy. Still, resulting postcopy period is
The test wants to force a bitmap postcopy. Still, the resulting postcopy
period is very small.
very small. Let's increase it by adding more bitmaps to migrate.
On Wed, Jul 22, 2020 at 11:11:32AM +0300, Denis Plotnikov wrote:
> +/**
> + * ram_copy_page: make a page copy
> + *
> + * Used in the background snapshot to make a copy of a memeory page.
> + * Ensures that the memeory page is copied only once.
> + * When a page copy is done, restores read/write
** Tags added: linux-user
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1888728
Title:
Bare chroot in linux-user fails with pgb_reserved_va: Assertion
`guest_base != 0' failed.
Status in QEMU:
The three options handling `struct sock_fprog` (TUNATTACHFILTER,
TUNDETACHFILTER, and TUNGETFILTER) are not implemented. Linux kernel
keeps a user space pointer in them which we cannot correctly handle.
Signed-off-by: Josh Kunz
Signed-off-by: Shu-Chun Weng
---
v2:
Title changed from
Stefan Hajnoczi writes:
> On Tue, Jul 21, 2020 at 07:14:38AM +, Alyssa Ross wrote:
>> Hi -- I hope it's okay me reaching out like this.
>>
>> I've been trying to test out the virtio-vhost-user implementation that's
>> been posted to this list a couple of times, but have been unable to get
On Wed, Jul 22, 2020 at 11:11:31AM +0300, Denis Plotnikov wrote:
> diff --git a/migration/migration.c b/migration/migration.c
> index 2ed9923227..2ec0451abe 100644
> --- a/migration/migration.c
> +++ b/migration/migration.c
> @@ -1086,6 +1086,32 @@ static bool migrate_caps_check(bool *cap_list,
>
On Wed, Jul 22, 2020 at 11:11:32AM +0300, Denis Plotnikov wrote:
> +static void *background_snapshot_thread(void *opaque)
> +{
> +MigrationState *m = opaque;
> +QIOChannelBuffer *bioc;
> +QEMUFile *fb;
> +int res = 0;
> +
> +rcu_register_thread();
> +
> +
On 2/17/20 9:02 AM, Vladimir Sementsov-Ogievskiy wrote:
Mostly, satisfy pep8 complains.
Signed-off-by: Vladimir Sementsov-Ogievskiy
---
tests/qemu-iotests/199 | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
With none of your series applied, I get:
$ ./check -qcow2 199
On 2/17/20 9:02 AM, Vladimir Sementsov-Ogievskiy wrote:
Keep bitmap state for disabled bitmaps too. Keep the state until the
end of the process. It's needed for the following commit to implement
bitmap postcopy canceling.
To clean-up the new list the following logic is used:
We need two events
On Thu, Jul 23, 2020 at 2:25 PM Max Filippov wrote:
>
> On Thu, Jul 23, 2020 at 2:04 PM Filip Bozuta wrote:
> >
> > This patch introduces missing target types ('target_flag_t', 'target_cc_t',
> > 'target_speed_t') in a few 'termibts.h' header files. Also, two missing
> > values ('TARGET_IUTF8'
On Thu, Jul 23, 2020 at 2:04 PM Filip Bozuta wrote:
>
> This patch introduces missing target types ('target_flag_t', 'target_cc_t',
> 'target_speed_t') in a few 'termibts.h' header files. Also, two missing
> values ('TARGET_IUTF8' and 'TARGET_EXTPROC') were also added. These values
> were also
This series introduces strace printing functionality for
contents of 'struct termios'.
The first patch in the series introduces a generic 'termbits.h'
file for some architectures which have same 'struct termios'
flag values and 'ioctl_tty' definitions.
The second patch introduces some missing
Functions "print_ioctl()" and "print_syscall_ret_ioctl()" are used
to print arguments of "ioctl()" with "-strace". These functions
use "thunk_print()", which is defined in "thunk.c", to print the
contents of ioctl's third arguments that are not basic types.
However, this function doesn't handle
On 2/17/20 9:02 AM, Vladimir Sementsov-Ogievskiy wrote:
If target is turned of prior to postcopy finished, target crashes
s/of/off/
because busy bitmaps are found at shutdown.
Canceling incoming migration helps, as it removes all unfinished (and
therefore busy) bitmaps.
Similarly on source
This patch introduces a generic 'termbits.h' file for following
archs: 'aarch64', 'arm', 'i386, 'm68k', 'microblaze', 'nios2',
'openrisc', 'riscv', 's390x', 'x86_64'.
Since all of these archs have the same termios flag values and
same ioctl_tty numbers, there is no need for a separate
This patch introduces missing target types ('target_flag_t', 'target_cc_t',
'target_speed_t') in a few 'termibts.h' header files. Also, two missing
values ('TARGET_IUTF8' and 'TARGET_EXTPROC') were also added. These values
were also added in file 'syscall.c' in bitmask tables 'iflag_tbl[]' and
On 2/19/20 8:20 AM, Vladimir Sementsov-Ogievskiy wrote:
18.02.2020 14:00, Andrey Shinkevich wrote:
On 17/02/2020 18:02, Vladimir Sementsov-Ogievskiy wrote:
Rename dirty_bitmap_mig_cleanup to dirty_bitmap_do_save_cleanup, to
stress that it is on save part.
Signed-off-by: Vladimir
Public bug reported:
Trying to run a bare chroot with no additional bind mounts fails on git
master (8ffa52c20d5693d454f65f2024a1494edfea65d4) with:
root@nofan:~/qemu> chroot /local_scratch/sid-m68k-sbuild/
qemu-m68k-static: /root/qemu/linux-user/elfload.c:2315: pgb_reserved_va:
Assertion
On 2/17/20 9:02 AM, Vladimir Sementsov-Ogievskiy wrote:
Rename types to be symmetrical for load/save part and shorter.
Signed-off-by: Vladimir Sementsov-Ogievskiy
---
migration/block-dirty-bitmap.c | 68 ++
1 file changed, 36 insertions(+), 32 deletions(-)
On 5/29/20 7:16 AM, Vladimir Sementsov-Ogievskiy wrote:
29.05.2020 14:58, Eric Blake wrote:
On 4/2/20 2:42 AM, Vladimir Sementsov-Ogievskiy wrote:
Ping!
It's a fix, but not a degradation and I'm afraid too big for 5.0.
Still, I think I should ping it anyway. John, I'm afraid, that this
all
On 6/11/20 11:26 AM, Vladimir Sementsov-Ogievskiy wrote:
The NBD spec was recently updated to clarify that max_block doesn't
relate to NBD_CMD_WRITE_ZEROES with NBD_CMD_FLAG_FAST_ZERO (which
mirrors Qemu flag BDRV_REQ_NO_FALLBACK).
bs->bl.max_write_zero_fast is zero by default which means using
On 6/11/20 11:26 AM, Vladimir Sementsov-Ogievskiy wrote:
The NBD spec was recently updated to clarify that max_block doesn't
relate to NBD_CMD_WRITE_ZEROES with NBD_CMD_FLAG_FAST_ZERO (which
mirrors Qemu flag BDRV_REQ_NO_FALLBACK). To drop the restriction we
need new max_pwrite_zeroes_fast.
On 7/23/20 2:42 PM, Eric Blake wrote:
On 7/17/20 3:14 AM, Andrey Shinkevich wrote:
Add dirty bitmap information to QCOW2 metadata dump in the
qcow2_format.py.
block/qcow2.c | 2 +-
docs/interop/qcow2.txt | 2 +-
tests/qemu-iotests/qcow2.py |
In commit 6957fd98dc ("gitlab: add avocado asset caching") we
tried to save the Avocado cache (as in commit c1073e44b4 with
Travis-CI) however it doesn't work as expected. For some reason
Avocado uses /root/avocado_cache/ which we can not select later.
Manually generate a Avocado config to force
On 7/17/20 3:14 AM, Andrey Shinkevich wrote:
Make the capitalization of the hexadecimal numbers consistent for the
QCOW2 header extension constants in docs/interop/qcow2.txt.
Suggested-by: Eric Blake
Signed-off-by: Andrey Shinkevich
Reviewed-by: Vladimir Sementsov-Ogievskiy
---
On 7/17/20 3:14 AM, Andrey Shinkevich wrote:
Add dirty bitmap information to QCOW2 metadata dump in the qcow2_format.py.
v10:
01: Fixing of issues in QCOW2 extension classes noted by Vladimir.
02: Reading bitmap tables was moved into Qcow2BitmapTable class.
03: Handling '-j' key was
On 7/20/20 1:07 PM, Vladimir Sementsov-Ogievskiy wrote:
Hi! This fixes real problem (see 04). On the other hand it may be too
much for 5.1, and it's not a degradation. So, up to you.
Given the concerns raised on 3, I think I'll wait for v2 of the series,
and defer it to 5.2.
It's based on
On 7/23/20 1:14 PM, Daniel P. Berrangé wrote:
This introduces the use of the OBJECT_DEFINE and OBJECT_DECLARE macro
families in the secret types, in order to eliminate boilerplate code.
Signed-off-by: Daniel P. Berrangé
---
Reviewed-by: Eric Blake
--
Eric Blake, Principal Software Engineer
On 7/23/20 1:14 PM, Daniel P. Berrangé wrote:
This introduces the use of the OBJECT_DEFINE and OBJECT_DECLARE macro
families in the TLS creds types, in order to eliminate boilerplate code.
Signed-off-by: Daniel P. Berrangé
---
Reviewed-by: Eric Blake
--
Eric Blake, Principal Software
virtio-input-hid.c undefines CONFIG_CURSES before including
ui/console.h. However since commits e2f82e924d057935 and b0766612d16da18
that header does not have behaviour dependent on CONFIG_CURSES.
Remove the now-unneeded undef.
Signed-off-by: Peter Maydell
---
NB: tested with 'make check' only.
On 7/23/20 1:14 PM, Daniel P. Berrangé wrote:
When creating new QOM types, there is a lot of boilerplate code that
must be repeated using a standard pattern. This is tedious to write
and liable to suffer from subtle inconsistencies. Thus it would
benefit from some simple automation.
QOM was
From: Vitaly Kuznetsov
HF2_GIF_MASK is set in env->hflags2 unconditionally on CPU reset
(see x86_cpu_reset()) but when calling KVM_SET_NESTED_STATE,
KVM_STATE_NESTED_GIF_SET is only valid for nSVM as e.g. nVMX code
looks like
if (kvm_state->hdr.vmx.vmxon_pa == -1ull) {
if (kvm_state->flags
The following changes since commit 8ffa52c20d5693d454f65f2024a1494edfea65d4:
Merge remote-tracking branch 'remotes/mst/tags/for_upstream' into staging
(2020-07-23 13:38:21 +0100)
are available in the Git repository at:
git://github.com/ehabkost/qemu.git tags/x86-next-for-5.1-pull-request
On 7/23/20 1:14 PM, Daniel P. Berrangé wrote:
The object_ref/unref methods are intended for use with any subclass of
the base Object. Using "Object *" in the signature is not adding any
meaningful level of type safety, since callers simply use "OBJECT(ptr)"
and this expands to an unchecked cast
On 7/23/20 6:09 PM, Dr. David Alan Gilbert (git) wrote:
> From: "Dr. David Alan Gilbert"
>
> Clean up the error handling in kvm_init_vcpu so we can see what went
> wrong more easily.
>
> Make it take an Error ** and fill it out with what failed, including
> the cpu id, so you can tell if it
On 7/20/20 4:00 AM, Vladimir Sementsov-Ogievskiy wrote:
We try to go to wakeable sleep, so that, if drain begins it will break
the sleep. But what if nbd_client_co_drain_begin() already called and
s->drained is already true? We'll go to sleep, and drain will have to
wait for the whole timeout.
On 7/20/20 4:00 AM, Vladimir Sementsov-Ogievskiy wrote:
On shutdown nbd driver may be in a connecting state. We should shutdown
it as well, otherwise we may hang in
nbd_teardown_connection, waiting for conneciton_co to finish in
BDRV_POLL_WHILE(bs, s->connection_co) loop if remote server is
On Thu, Jul 23, 2020 at 07:14:09PM +0100, Daniel P. Berrangé wrote:
> This introduces the use of the OBJECT_DEFINE and OBJECT_DECLARE macro
> families in the secret types, in order to eliminate boilerplate code.
>
> Signed-off-by: Daniel P. Berrangé
> ---
> crypto/secret.c |
On 7/20/20 4:00 AM, Vladimir Sementsov-Ogievskiy wrote:
It should be to reenter qio_channel_yield() on io/channel read/write
path, so it's safe to reduce in_flight and allow attaching new aio
context. And no problem to allow drain itself: connection attempt is
not a guest request. Moreover, if
When creating new QOM types, there is a lot of boilerplate code that
must be repeated using a standard pattern. This is tedious to write
and liable to suffer from subtle inconsistencies. Thus it would
benefit from some simple automation.
QOM was loosely inspired by GLib's GObject, and indeed
To just duplicate the patch 2 message
When creating new QOM types, there is a lot of boilerplate code that
must be repeated using a standard pattern. This is tedious to write
and liable to suffer from subtle inconsistencies. Thus it would
benefit from some simple automation.
QOM was loosely
The object_ref/unref methods are intended for use with any subclass of
the base Object. Using "Object *" in the signature is not adding any
meaningful level of type safety, since callers simply use "OBJECT(ptr)"
and this expands to an unchecked cast "(Object *)".
By using "void *" we enable the
This introduces the use of the OBJECT_DEFINE and OBJECT_DECLARE macro
families in the TLS creds types, in order to eliminate boilerplate code.
Signed-off-by: Daniel P. Berrangé
---
crypto/tlscreds.c | 25 +++--
crypto/tlscredsanon.c | 23
This introduces the use of the OBJECT_DEFINE and OBJECT_DECLARE macro
families in the secret types, in order to eliminate boilerplate code.
Signed-off-by: Daniel P. Berrangé
---
crypto/secret.c | 24
crypto/secret_common.c | 32
On 7/23/20 12:29 PM, Alex Williamson wrote:
On Thu, 23 Jul 2020 11:13:55 -0400
Matthew Rosato wrote:
I noticed that after kernel commit abafbc55 'vfio-pci: Invalidate mmaps
and block MMIO access on disabled memory' vfio-pci via qemu on s390x
fails spectacularly, with errors in qemu like:
On Wed, 22 Jul 2020 at 13:09, Michael S. Tsirkin wrote:
>
> The following changes since commit c8004fe6bbfc0d9c2e7b942c418a85efb3ac4b00:
>
> Update version for v5.1.0-rc1 release (2020-07-21 20:28:59 +0100)
>
> are available in the Git repository at:
>
>
1 - 100 of 311 matches
Mail list logo
