From: Pan Nengyuan
ivq/dvq/svq/free_page_vq is forgot to cleanup in
virtio_balloon_device_unrealize, the memory leak stack is as follow:
Direct leak of 14336 byte(s) in 2 object(s) allocated from:
#0 0x7f99fd9d8560 in calloc (/usr/lib64/libasan.so.3+0xc7560)
#1 0x7f99fcb20015 in g_malloc
From: Pan Nengyuan
Devices tend to maintain vq pointers, allow deleting them trough a vq pointer.
Signed-off-by: Michael S. Tsirkin
Signed-off-by: Pan Nengyuan
---
Changes v2 to v1:
- add a new function virtio_delete_queue to cleanup vq through a vq pointer
---
hw/virtio/virtio.c | 16
On 2019/12/4 15:19, Vladimir Sementsov-Ogievskiy wrote:
> 04.12.2019 6:12, pannengyuan wrote:
>>
>>
>> On 2019/12/4 1:38, Vladimir Sementsov-Ogievskiy wrote:
>>> Hi!
>>>
>>> First, please, when sending more than one patch, create a cover-letter.
>>> Also,
>>> summarize (in cover letter) what wa
From: Pan Nengyuan
ivqs/ovqs/c_ivq/c_ovq is forgot to cleanup in
virtio_serial_device_unrealize, the memory leak stack is as bellow:
Direct leak of 1290240 byte(s) in 180 object(s) allocated from:
#0 0x7fc9bfc27560 in calloc (/usr/lib64/libasan.so.3+0xc7560)
#1 0x7fc9bed6f015 in g_malloc
Halil Pasic writes:
> On Mon, 2 Dec 2019 17:40:07 +0100
> Cornelia Huck wrote:
>
>> On Sat, 30 Nov 2019 20:42:39 +0100
>> Markus Armbruster wrote:
>>
>> > Cc: Halil Pasic
>> > Cc: Cornelia Huck
>> > Cc: Christian Borntraeger
>> > Signed-off-by: Markus Armbruster
>> > ---
>> > hw/intc/s390
04.12.2019 6:12, pannengyuan wrote:
>
>
> On 2019/12/4 1:38, Vladimir Sementsov-Ogievskiy wrote:
>> Hi!
>>
>> First, please, when sending more than one patch, create a cover-letter. Also,
>> summarize (in cover letter) what was changed since previous version.
> In previous version, I only send on
Eric Blake writes:
> On 11/29/19 3:59 AM, Markus Armbruster wrote:
>> Generated .h need to be generated before compiling any .c using them.
>> To know which .h a .c uses, we need to compile it.
>>
>> Since commit 4115852bb0 "build: do not sprinkle around
>> GENERATED_HEADERS dependencies", we bre
Anyone help to review it?
On Tue, Nov 26, 2019 at 1:54 PM Han Han wrote:
> ping
>
> On Wed, Nov 13, 2019 at 9:17 PM Han Han wrote:
>
>> In python3, 'file' is no longer a keyword for file type object. So it
>> will can error when run the scripts by python3:
>>
>> $ python3 ./scripts/vmstate-stat
On 2019/12/3 21:01, Thomas Huth wrote:
> On 03/12/2019 13.27, Xiang Zheng wrote:
>> There are quite a few tests disabled on AArch64 such as fw_cfg-tests.
>> This patch series fix some problems in test code and adapt it to
>> virt machine.
>>
>> Xiang Zheng (5):
>> tests: fw_cfg: Rename pc_fw_c
On 2019/12/3 20:34, Peter Maydell wrote:
> On Tue, 3 Dec 2019 at 12:29, Xiang Zheng wrote:
>>
>> Rename pc_fw_cfg_* to fw_cfg_* to make them common for other
>> architectures so that we can run fw_cfg tests on aarch64.
>>
>> Signed-off-by: Xiang Zheng
>
>> -static inline QFWCFG *pc_fw_cfg_ini
On 2019/12/3 20:32, Peter Maydell wrote:
> On Tue, 3 Dec 2019 at 12:29, Xiang Zheng wrote:
>>
>> I'm not sure whether it's neccesary to add FW_CFG_RAM_SIZE and
>> FW_CFG_MAX_CPUS into fw_cfg on virt machine. This patch just makes
>> the fw_cfg-test happy.
>>
>> Signed-off-by: Xiang Zheng
>> --
On Tue, Dec 03, 2019 at 03:00:43PM +0200, Sam Eiderman wrote:
> Hi,
>
> Maybe we should add:
>
> CONFIG_HOST_BIOS_GEOMETRY=n
>
> to rom/config.seabios-128k and recreate the 128k image?
Can do that when updating to 1.13-final (which is not yet tagged).
cheers,
Gerd
On 04/12/2019 15:23, Alexey Kardashevskiy wrote:
>
>
> On 04/12/2019 03:09, Laurent Vivier wrote:
>>
>> Bad reply, the problem is with
>>
>> "spapr: Render full FDT on ibm,client-architecture-support"
>
>
> https://git.qemu.org/?p=SLOF.git;a=blob;f=board-qemu/slof/fdt.fs;h=3e4c1b34b8af2dcebd
On 04/12/2019 03:09, Laurent Vivier wrote:
>
> Bad reply, the problem is with
>
> "spapr: Render full FDT on ibm,client-architecture-support"
https://git.qemu.org/?p=SLOF.git;a=blob;f=board-qemu/slof/fdt.fs;h=3e4c1b34b8af2dcebde57e548c94417e5e20e1cc;hb=HEAD#l265
A "bit ugly" became really u
On 2019/12/4 2:54, Eric Blake wrote:
> On 12/3/19 11:52 AM, Vladimir Sementsov-Ogievskiy wrote:
>> It's just a memory leak, but it's a regression in 4.2.
>>
>> Should we take it into 4.2?
>
> Sorry, I was on holiday and then jury service, so I missed any chance at
> getting this into -rc3. The
On 2019/12/4 3:00, Eric Blake wrote:
> On 11/29/19 1:25 AM, pannengy...@huawei.com wrote:
>> From: PanNengyuan
>>
>> The BDRVNBDState cleanup code is common in two places, add
>> nbd_free_bdrvstate_prop() function to do these cleanups (suggested by
>> Stefano Garzarella).
>>
>> Signed-off-by: P
On 2019/12/4 1:38, Vladimir Sementsov-Ogievskiy wrote:
> Hi!
>
> First, please, when sending more than one patch, create a cover-letter. Also,
> summarize (in cover letter) what was changed since previous version.
In previous version, I only send one patch(2/2 in this version), so I
only add a
On 2019/12/3 16:32, Laurent Vivier wrote:
> On 03/12/2019 01:53, pannengyuan wrote:
>>
>>
>> On 2019/12/2 21:58, Laurent Vivier wrote:
>>> On 02/12/2019 12:15, pannengy...@huawei.com wrote:
From: PanNengyuan
ivqs/ovqs/c_ivq/c_ovq is forgot to cleanup in
virtio_serial_device_
On 2019/11/30 上午12:04, Philippe Mathieu-Daudé wrote:
On Fri, Nov 29, 2019 at 4:59 PM Wasim, Bilal wrote:
Thanks for the pointers philippe.. Is the patch okay to be merged without it or
do I need to do a re-submission with the updated username ?
If there are no review comments on your patch,
Rename few data structures related to X86 topology. X86CPUTopoIDs will
have individual arch ids. Next patch introduces X86CPUTopoInfo which will
have all topology information(like cores, threads etc..).
Signed-off-by: Babu Moger
Reviewed-by: Eduardo Habkost
---
hw/i386/pc.c | 6
This series fixes APIC ID encoding problems on AMD EPYC CPUs.
https://bugzilla.redhat.com/show_bug.cgi?id=1728166
Currently, the APIC ID is decoded based on the sequence
sockets->dies->cores->threads. This works for most standard AMD and other
vendors' configurations, but this decoding sequence do
Store the smp sockets in CpuTopology. The socket information required to
build the apic id in EPYC mode. Right now socket information is not passed
to down when decoding the apic id. Add the socket information here.
Signed-off-by: Babu Moger
Reviewed-by: Eduardo Habkost
---
hw/core/machine.c
This is an effort to re-arrange few data structure for better readability.
Add X86CPUTopoInfo which will have all the topology informations required
to build the cpu topology. There is no functional changes.
Signed-off-by: Babu Moger
---
hw/i386/pc.c | 40
Now that we have all the parameters in X86CPUTopoInfo, we can just pass the
structure to calculate the offsets and width.
Signed-off-by: Babu Moger
---
include/hw/i386/topology.h | 64 ++--
target/i386/cpu.c | 23
2 files chan
Update structures X86CPUTopoIDs and CPUX86State to hold the nodes_per_pkg. This
is required to build EPYC mode topology.
Signed-off-by: Babu Moger
---
hw/i386/pc.c |4
include/hw/i386/topology.h |1 +
target/i386/cpu.c |1 +
target/i386/cpu.h |
Introduce last level cache id(llc_id) in x86CPU topology. This information is
required to build the topology in EPIC mode.
Signed-off-by: Babu Moger
---
hw/core/machine-hmp-cmds.c |3 +++
hw/core/machine.c | 13 +
hw/i386/pc.c | 10 ++
include/
To generate the apic id for EPYC cpu models correctly, we need to know the
number of numa nodes in advance. At present numa node initialization and cpu
initialization happens at the same time. Apic id generation happens during the
cpu initialization. At this point it is not known how many numa node
Add function pointers in PCMachineState to handle apic id specific
functionalities. This will be used to initialize with correct handlers based on
the cpu model selected.
x86_apicid_from_cpu_idx will be default handler.
Signed-off-by: Babu Moger
---
hw/i386/pc.c |5 -
include/hw
Add CPUX86Family type in CPUX86State. This will be used to differentiate
generic x86 and x86 EPYC based cpu models.
Signed-off-by: Babu Moger
---
hw/i386/pc.c |4
target/i386/cpu.c |1 +
target/i386/cpu.h |7 +++
3 files changed, 12 insertions(+)
diff --git a/hw/i386/p
Initialize all the parameters in one function initialize_topo_info.
Signed-off-by: Babu Moger
Reviewed-by: Eduardo Habkost
---
hw/i386/pc.c | 28 +++-
1 file changed, 15 insertions(+), 13 deletions(-)
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index 8c23b1e8c9..cafbdafa
Add function pointer apic_id_from_topo_ids in PCMachineState.
Initialize with correct handler based on the mode selected.
Also rename the handler apicid_from_topo_ids to x86_apicid_from_topo_ids
for consistency. x86_apicid_from_topo_ids will be the default handler.
Signed-off-by: Babu Moger llc_id
Since the topology routines have changed, update
the unit tests to use the new APIs.
Signed-off-by: Babu Moger
---
tests/test-x86-cpuid.c | 115
1 file changed, 68 insertions(+), 47 deletions(-)
diff --git a/tests/test-x86-cpuid.c b/tests/test-x
Add a new function init_apicid_fn in MachineClass to initialize the mode
specific handlers to decode the apic ids.
Signed-off-by: Babu Moger
---
include/hw/boards.h |1 +
vl.c|3 +++
2 files changed, 4 insertions(+)
diff --git a/include/hw/boards.h b/include/hw/boards.h
Introduce following handlers for new epyc mode.
x86_apicid_from_cpu_idx_epyc: Generate apicid from cpu index.
x86_topo_ids_from_apicid_epyc: Generate topo ids from apic id.
x86_apicid_from_topo_ids_epyc: Generate apicid from topo ids.
Signed-off-by: Babu Moger
---
hw/i386/pc.c |
Add function pointer topo_ids_from_apicid in PCMachineState.
Initialize with correct handler based on mode selected.
x86_apicid_from_cpu_idx will be the default handler.
Signed-off-by: Babu Moger
---
hw/i386/pc.c | 13 +++--
include/hw/i386/pc.h |2 ++
2 files changed, 9 in
Use the new functions from topology.h and delete the unused code. Given the
sockets, nodes, cores and threads, the new functions generate apic id for EPYC
mode. Removes all the hardcoded values.
Signed-off-by: Babu Moger
---
target/i386/cpu.c | 162 +++---
These functions add support for building EPYC mode topology given the smp
details like numa nodes, cores, threads and sockets.
The new apic id decoding is mostly similar to current apic id decoding
except that it adds a new field llc_id when numa configured. Removes all
the hardcoded values. Subse
Signed-off-by: Babu Moger
---
target/i386/cpu.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index e87487bae3..0eaedeb848 100644
--- a/target/i386/cpu.c
+++ b/target/i386/cpu.c
@@ -4456,7 +4456,7 @@ void cpu_x86_cpuid(CPUX
Signed-off-by: Richard Henderson
---
target/arm/cpu.h | 6 ++
target/arm/helper.c| 21 +
target/arm/translate-a64.c | 14 ++
3 files changed, 41 insertions(+)
diff --git a/target/arm/cpu.h b/target/arm/cpu.h
index cdf6caf869..dd284ba5c7 1006
Based-on: <20191203225333.17055-1-richard.hender...@linaro.org>
("target/arm: Implement ARMv8.1-PAN + ARMv8.2-ATS1E1")
This was relatively easy to do, and related to the VHE
and PAN patch sets. It's also already supported by the
Linux kernel and thus easily tested.
r~
Richard Henderson (4):
Signed-off-by: Richard Henderson
---
target/arm/cpu64.c | 4
1 file changed, 4 insertions(+)
diff --git a/target/arm/cpu64.c b/target/arm/cpu64.c
index 9399253b4c..03377084e3 100644
--- a/target/arm/cpu64.c
+++ b/target/arm/cpu64.c
@@ -674,6 +674,10 @@ static void aarch64_max_initfn(Object
We need only override the current condition under which
TBFLAG_A64.UNPRIV is set.
Signed-off-by: Richard Henderson
---
target/arm/helper.c | 41 +
1 file changed, 21 insertions(+), 20 deletions(-)
diff --git a/target/arm/helper.c b/target/arm/helper.c
ind
Add definitions for all of the fields, up to ARMv8.5.
Convert the existing RESERVED register to a full register.
Query KVM for the value of the register for the host.
Signed-off-by: Richard Henderson
---
target/arm/cpu.h| 17 +
target/arm/helper.c | 4 ++--
target/arm/kvm64.
This is a minor enhancement over ARMv8.1-PAN.
The *_PAN mmu_idx are used with the existing do_ats_write.
Signed-off-by: Richard Henderson
---
target/arm/helper.c | 50 +++--
1 file changed, 44 insertions(+), 6 deletions(-)
diff --git a/target/arm/helper.c
The PAN bit is preserved, or set as per SCTLR_ELx.SPAN,
plus several other conditions listed in the ARM ARM.
Signed-off-by: Richard Henderson
---
target/arm/helper.c | 42 +++---
1 file changed, 39 insertions(+), 3 deletions(-)
diff --git a/target/arm/helper.
For aarch64, there's a dedicated msr (imm, reg) insn.
For aarch32, this is done via msr to cpsr; and writes
from el0 are ignored.
Signed-off-by: Richard Henderson
---
target/arm/cpu.h | 2 ++
target/arm/helper.c| 22 ++
target/arm/translate-a64.c | 14 +
To implement PAN, we will want to swap, for short periods
of time, to a different privileged mmu_idx. In addition,
we cannot do this with flushing alone, because the AT*
instructions have both PAN and PAN-less versions.
Add the ARMMMUIdx*_PAN constants where necessary next to
the corresponding AR
This includes enablement of ARMv8.1-PAN.
Signed-off-by: Richard Henderson
---
target/arm/cpu.c | 4
target/arm/cpu64.c | 5 +
2 files changed, 9 insertions(+)
diff --git a/target/arm/cpu.c b/target/arm/cpu.c
index f3360dbb98..3b0c466137 100644
--- a/target/arm/cpu.c
+++ b/target/arm/
In target/arm we will shortly have "too many" mmu_idx.
The current minimum barrier is caused by the way in which
tlb_flush_page_by_mmuidx is coded.
We can remove this limitation by allocating memory for
consumption by the worker. Let us assume that this is
the unlikely case, as will be the case f
Examine the PAN bit for EL1, EL2, and Secure EL1 to
determine if it applies.
Signed-off-by: Richard Henderson
---
target/arm/helper.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/target/arm/helper.c b/target/arm/helper.c
index 512be5c644..6c65dd799e 100644
--- a/target/arm/helper
Use a common predicate for querying stage1-ness.
Signed-off-by: Richard Henderson
---
target/arm/internals.h | 11 +++
target/arm/helper.c| 8 +++-
2 files changed, 14 insertions(+), 5 deletions(-)
diff --git a/target/arm/internals.h b/target/arm/internals.h
index 49dac2a677..8
If we have a PAN-enforcing mmu_idx, set prot == 0 if user_rw != 0.
Signed-off-by: Richard Henderson
---
target/arm/internals.h | 13 +
target/arm/helper.c| 3 +++
2 files changed, 16 insertions(+)
diff --git a/target/arm/internals.h b/target/arm/internals.h
index 2408953031..ab
Include definitions for all of the bits in ID_MMFR3.
We already have a definition for ID_AA64MMFR1.PAN.
Signed-off-by: Richard Henderson
---
target/arm/cpu.h | 29 +
1 file changed, 29 insertions(+)
diff --git a/target/arm/cpu.h b/target/arm/cpu.h
index 49dc436e5e..1
Based-on: <20191203022937.1474-1-richard.hender...@linaro.org>
("target/arm: Implement ARMv8.1-VHE")
At least the PAN portion is supported in the Linux kernel,
and thus easily tested. The ats1e1 extension is closely
related, reusing the same mmu_idx to implement.
r~
Richard Henderson (11):
Since v8.0, the CPSR_RESERVED bits have been allocated.
We are not yet implementing ARMv8.4-DIT; retain CPSR_RESERVED,
since that overlaps with our current hack for AA32 single step.
Signed-off-by: Richard Henderson
---
target/arm/cpu.h | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(
On 03/12/2019 08:25, Thomas Huth wrote:
> On 03/12/2019 08.45, Philippe Mathieu-Daudé wrote:
>> On 12/3/19 8:29 AM, Thomas Huth wrote:
>>> It's been deprecated since QEMU v3.1. The 40p machine should be
>>> used nowadays instead.
>>>
>>> Signed-off-by: Thomas Huth
>>> ---
>>> .gitmodules
On 11/29/19 3:59 AM, Markus Armbruster wrote:
Generated .h need to be generated before compiling any .c using them.
To know which .h a .c uses, we need to compile it.
Since commit 4115852bb0 "build: do not sprinkle around
GENERATED_HEADERS dependencies", we break this circular dependency the
sim
On 12/3/19 12:54 PM, Eric Blake wrote:
On 12/3/19 11:52 AM, Vladimir Sementsov-Ogievskiy wrote:
It's just a memory leak, but it's a regression in 4.2.
Should we take it into 4.2?
Sorry, I was on holiday and then jury service, so I missed any chance at
getting this into -rc3. The memory leak
Any insight as to why OS vendors (RHEL and Ubuntu in particular)
aren't supporting blockdev-snapshot?
- RHEL claims no support for Qemu-based snapshots in any flavor
- Ubuntu hasn't enabled blockdev-snapshot in it's 19.10 release
-craig
On 11/30/19 1:42 PM, Markus Armbruster wrote:
Signed-off-by: Markus Armbruster
---
tests/test-blockjob.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
Reviewed-by: Eric Blake
diff --git a/tests/test-blockjob.c b/tests/test-blockjob.c
index e670a20617..4eeb184caf 100644
--- a/t
On 12/2/19 10:25 PM, Philippe Mathieu-Daudé wrote:
> On 12/3/19 3:29 AM, Richard Henderson wrote:
>> No functional change, but unify code sequences.
>>
>> Reviewed-by: Alex Bennée
>> Signed-off-by: Richard Henderson
>
> Easier to review in 2 patches: vae1_tlbmask first, then vmalle1_tlbmask.
Ok
Public bug reported:
While running the acceptance tests on s390x, the arm tests under
qemu/tests/acceptance/boot_linux_console.py will timeout, except the
test using u-boot. All the arm tests run without problems on x86 and
ppc.
This test boots the kernel and wait for a kernel panic to make sure
+jfreimann, +mst
On Sat, Nov 30, 2019 at 11:10:19AM +, Peter Maydell wrote:
> On Fri, 29 Nov 2019 at 20:05, Eduardo Habkost wrote:
> > So, to summarize the current issues:
> >
> > 1) realize triggers a plug operation implicitly.
> > 2) unplug triggers unrealize implicitly.
> >
> > Do you expe
On Tue, Dec 03, 2019 at 09:56:15AM +0100, Thomas Huth wrote:
> On 02/12/2019 22.00, Eduardo Habkost wrote:
> > On Mon, Dec 02, 2019 at 08:39:48AM +0100, Igor Mammedov wrote:
> >> On Fri, 29 Nov 2019 18:46:12 +0100
> >> Paolo Bonzini wrote:
> >>
> >>> On 29/11/19 13:16, Igor Mammedov wrote:
>
On 12/1/19 11:07 PM, Markus Armbruster wrote:
{
+Error *err = NULL;
I remember that some time ago, the best practice was to use "local_err",
what is the latest state of that?
Hundreds of local Error * variables are named @local_err, and hundreds
more are named @err.
For what it's wor
To the best of my knowledge, -blockdev can fully replace -drive if=none.
Replacing other interface types takes more than just -blockdev, because
they additionally instruct the board code to create a block frontend.
-blockdev is *only* about backends, so something else needs to replace
the frontend
On Mon, 2 Dec 2019 17:40:07 +0100
Cornelia Huck wrote:
> On Sat, 30 Nov 2019 20:42:39 +0100
> Markus Armbruster wrote:
>
> > Cc: Halil Pasic
> > Cc: Cornelia Huck
> > Cc: Christian Borntraeger
> > Signed-off-by: Markus Armbruster
> > ---
> > hw/intc/s390_flic_kvm.c | 10 --
> > 1 f
Hello,
On behalf of the QEMU Team, I'd like to announce the availability of the
fifth release candidate for the QEMU 4.2 release. This release is meant
for testing purposes and should not be used in a production environment.
http://download.qemu-project.org/qemu-4.2.0-rc4.tar.xz
http://downl
On 03/12/2019 20.24, Alex Bennée wrote:
>
> Thomas Huth writes:
>
>> It's much easier if we simply add the folder prefix and the exe suffix
>> later via a substitution instead.
>
> I guess it took too long for me to get around to this as I'm hit with a
> merge conflict. Is there likely to be a
Hello Philippe,
Thanks for your quick review comments!
I'll start working on a v2 of the patches and include the changes you
suggested.
Regards,
Niek
On Tue, Dec 3, 2019 at 10:18 AM Philippe Mathieu-Daudé
wrote:
> On 12/2/19 10:09 PM, Niek Linnenbank wrote:
> > The Xunlong Orange Pi PC is an A
On 11/20/19 7:39 AM, Cornelia Huck wrote:
> On Fri, 15 Nov 2019 04:34:36 +0100
> Eric Farman wrote:
>
>> Make it easier to add new ones in the future.
>>
>> Signed-off-by: Eric Farman
>> ---
>> hw/vfio/ccw.c | 55 ---
>> 1 file changed, 39 inse
Hi Philippe,
Thanks for your very quick response!
I remember I have seen this error before while working on the patches, in
particular
on the SMP part. I'll try to reproduce this error with the 4.20 sunxi
kernel you used and debug it.
Could it be related to the change I made in patch 0006 for the
Hello Frederic,
Thank you for your quick review comments!
I'll start working on v2 of the patches and include the changes you
suggested.
On Tue, Dec 3, 2019 at 10:33 AM KONRAD Frederic
wrote:
>
>
> Le 12/2/19 à 10:09 PM, Niek Linnenbank a écrit :
> > The Allwinner H3 System on Chip includes an
Thomas Huth writes:
> It's much easier if we simply add the folder prefix and the exe suffix
> later via a substitution instead.
I guess it took too long for me to get around to this as I'm hit with a
merge conflict. Is there likely to be a re-base soon?
>
> Signed-off-by: Thomas Huth
> ---
Cleber Rosa writes:
> This acceptance test, validates that a full blown Linux guest can
> successfully boot in QEMU. In this specific case, the guest chosen is
> Fedora version 31.
>
> * x86_64, pc and q35 machine types, with and without kvm as an
>accellerator
>
> * aarch64 and virt mac
Hello Philippe,
On Tue, Dec 3, 2019 at 10:02 AM Philippe Mathieu-Daudé
wrote:
> On 12/2/19 10:09 PM, Niek Linnenbank wrote:
> > Dear QEMU developers,
> >
> > Hereby I would like to contribute the following set of patches to QEMU
> > which add support for the Allwinner H3 System on Chip and the
>
If the redirected device has this capability, Windows guest may
place the device into D2 and expect it to wake when the device
becomes active, but this will never happen. For example, when
internal Bluetooth adapter is redirected, keyboards and mice
connected to it do not work. Current commit remov
This series of patches addresses possible functional problem of USB
devices with 'remote wakeup' capability, redirected to Windows VM
(local redirection using libusb or spice redirection using usbredir).
Changes from v1: minor fixes per v1 review and checkpatch
Yuri Benditovich (2):
usb-host: r
If the redirected device has this capability, Windows guest may
place the device into D2 and expect it to wake when the device
becomes active, but this will never happen. For example, when
internal Bluetooth adapter is redirected, keyboards and mice
connected to it do not work. Current commit remov
On 12/3/19 11:52 AM, Vladimir Sementsov-Ogievskiy wrote:
It's just a memory leak, but it's a regression in 4.2.
Should we take it into 4.2?
Sorry, I was on holiday and then jury service, so I missed any chance at
getting this into -rc3. The memory leak only happens on failure, and
you'd hav
On 11/29/19 1:25 AM, pannengy...@huawei.com wrote:
From: PanNengyuan
The BDRVNBDState cleanup code is common in two places, add
nbd_free_bdrvstate_prop() function to do these cleanups (suggested by
Stefano Garzarella).
Signed-off-by: PanNengyuan
---
block/nbd.c | 23 +--
On 03.12.19 14:28, Janosch Frank wrote:
> We need to set the short psw indication bit in the reset psw, as it is
> a short psw.
>
> fixes: 9629823290 ("pc-bios/s390-ccw: do a subsystem reset before running the
> guest")
> Signed-off-by: Janosch Frank
Acked-by: Christian Borntraeger
> ---
>
On Mon, 25 Nov 2019 19:57:39 -0500
Yan Zhao wrote:
> On Fri, Nov 15, 2019 at 05:06:25AM +0800, Alex Williamson wrote:
> > On Fri, 15 Nov 2019 00:26:07 +0530
> > Kirti Wankhede wrote:
> >
> > > On 11/14/2019 1:37 AM, Alex Williamson wrote:
> > > > On Thu, 14 Nov 2019 01:07:21 +0530
> > > > K
On Tue, 3 Dec 2019 08:28:11 -0500
Janosch Frank wrote:
> Up to now we only had an ioctl to reset vcpu data QEMU couldn't reach
> for the initial reset, and that was also called for the clear
> reset. To be architecture compliant, we also need to clear local
> interrupts on a normal reset.
>
> B
It's just a memory leak, but it's a regression in 4.2.
Should we take it into 4.2?
29.11.2019 10:25, pannengy...@huawei.com wrote:
> From: PanNengyuan
>
> In currently implementation there will be a memory leak when
> nbd_client_connect() returns error status. Here is an easy way to
> reproduc
Hi!
First, please, when sending more than one patch, create a cover-letter. Also,
summarize (in cover letter) what was changed since previous version.
29.11.2019 10:25, pannengy...@huawei.com wrote:
> From: PanNengyuan
Strange line. Check you git preferences. Such line appears (and make sense)
On 12/3/19 1:48 PM, Andrew Jeffery wrote:
On Tue, 3 Dec 2019, at 16:39, Philippe Mathieu-Daudé wrote:
On 12/3/19 5:14 AM, Andrew Jeffery wrote:
Prepare for SoCs such as the ASPEED AST2600 whose firmware configures
CNTFRQ to values significantly larger than the static 62.5MHz value
currently der
On Tue, 3 Dec 2019 08:28:13 -0500
Janosch Frank wrote:
> We need to set the short psw indication bit in the reset psw, as it is
> a short psw.
>
> fixes: 9629823290 ("pc-bios/s390-ccw: do a subsystem reset before running the
> guest")
s/fixes: 9629823290/Fixes: 962982329029/
> Signed-off-by:
On 11/15/19 7:08 PM, Wainer dos Santos Moschetta wrote:
On commit abf0bf998dcb John Snow moved some code out of __init__.py
to machine.py. kvm_available() remained in though. So on patch 01
I continue his work by creating a home for that method (the new
'accel' module). Honestly I was unsure abou
On Mon, 2 Dec 2019 at 14:06, Cleber Rosa wrote:
>
> RFC: QEMU Gating CI
> ===
>
> This RFC attempts to address most of the issues described in
> "Requirements/GatinCI"[1]. An also relevant write up is the "State of
> QEMU CI as we enter 4.0"[2].
>
> The general approach is one to
11.11.2019 19:02, Max Reitz wrote:
> Signed-off-by: Max Reitz
> ---
> tests/qemu-iotests/041 | 235 +
> tests/qemu-iotests/041.out | 4 +-
> 2 files changed, 237 insertions(+), 2 deletions(-)
>
> diff --git a/tests/qemu-iotests/041 b/tests/qemu-iotest
Wainer dos Santos Moschetta writes:
> This adds a method to check if the tcg accelerator is enabled
> in the QEMU binary.
>
> Signed-off-by: Wainer dos Santos Moschetta
Reviewed-by: Alex Bennée
So is this series going to be combined with another avocado series?
> ---
> python/qemu/accel.p
Wainer dos Santos Moschetta writes:
> Currently kvm_available() checks for the presence of kvm module
> and, if target and host arches don't mismatch. This patch adds
> an 3rd checking: if QEMU binary was compiled with kvm
> support.
>
> Signed-off-by: Wainer dos Santos Moschetta
Reviewed-by:
Wainer dos Santos Moschetta writes:
> Since commit cbe6d6365a48 the command `qemu -accel help` returns
> the list of accelerators enabled in the QEMU binary. This adds
> the list_accel() method which return that same list.
>
> Signed-off-by: Wainer dos Santos Moschetta
> ---
> python/qemu/acc
Oh, to finish up on the replies...
On 12/3/19 1:42 PM, Peter Maydell wrote:
>> +ptr_tag = allocation_tag_from_addr(dirty_ptr);
>> +if (ptr_tag == 0) {
>> +ARMVAParameters p = aa64_va_parameters(env, dirty_ptr, stage1,
>> true);
>> +if (p.tcma) {
>> +return clea
On Tue, 3 Dec 2019 14:33:25 +0100
Christian Borntraeger wrote:
> On 03.12.19 14:28, Janosch Frank wrote:
> > We need to set the short psw indication bit in the reset psw, as it is
> > a short psw.
> >
> > fixes: 9629823290 ("pc-bios/s390-ccw: do a subsystem reset before running
> > the guest")
On Tue, 3 Dec 2019 at 16:06, Richard Henderson
wrote:
> On 12/3/19 1:42 PM, Peter Maydell wrote:
> > This reads a bit oddly, because (in the final version of the spec)
> > physical and logical tags are identical (AArch64.PhysicalTag()
> > just returns bits [59:56] of the vaddr).
>
> I missed that
Wainer dos Santos Moschetta writes:
> This creates the 'accel' Python module to be the home for
> utilities that deal with accelerators. Also moved kvm_available()
> from __init__.py to this new module.
>
> Signed-off-by: Wainer dos Santos Moschetta
> ---
> python/qemu/__init__.py | 20 +-
On 04/10/2019 11:37, David Gibson wrote:
> From: Alexey Kardashevskiy
>
> The ibm,client-architecture-support call is a way for the guest to
> negotiate capabilities with a hypervisor. It is implemented as:
> - the guest calls SLOF via client interface;
> - SLOF calls QEMU (H_CAS hypercall) with
Bad reply, the problem is with
"spapr: Render full FDT on ibm,client-architecture-support"
Sorry,
Laurent
On 03/12/2019 16:57, Laurent Vivier wrote:
> On 18/11/2019 11:53, Laurent Vivier wrote:
>> From: Alexey Kardashevskiy
>>
>> Since "spapr: Render full FDT on ibm,client-architecture-suppor
1 - 100 of 218 matches
Mail list logo
