Re: [PATCH RFC 02/14] migration: judge whether or not the RDMA is used for migration
Zhimin Feng wrote: > Signed-off-by: Zhimin Feng > --- > migration/migration.c | 10 ++ > migration/migration.h | 1 + > 2 files changed, 11 insertions(+) > > diff --git a/migration/migration.c b/migration/migration.c > index 10a13e0c79..819089a7ea 100644 > --- a/migration/migration.c > +++ b/migration/migration.c > @@ -107,6 +107,7 @@ static NotifierList migration_state_notifiers = > NOTIFIER_LIST_INITIALIZER(migration_state_notifiers); > > static bool deferred_incoming; > +static bool enabled_rdma_migration; Please no. Use a field in migration state. No problem with the rest ofthe patch. Later, Juan.
Re: [RFC 2/2] pci-expender-bus:Add pcie-root-port to pxb-pcie under arm.
On Thu, Feb 13, 2020 at 03:49:52PM +0800, Yubo Miao wrote:
> From: miaoyubo
>
> Since devices could not directly plugged into pxb-pcie,
Hmm is this different from the root port? intergrated devices
do exist for that actually.
> under arm,
how is arm special?
> one
> pcie-root port is plugged into pxb-pcie. Due to the bus for each pxb-pcie
> is defined as 2 in acpi dsdt tables(one for pxb-pcie, one for pcie-root-port),
> only one device could be plugged into one pxb-pcie.
So why can't we have users specify any number of root ports using
-device? then make acpi tables match the # of ports created?
>
> Signed-off-by: miaoyubo
> ---
> hw/pci-bridge/pci_expander_bridge.c | 9 +
> include/hw/pci/pcie_port.h | 1 +
> 2 files changed, 10 insertions(+)
>
> diff --git a/hw/pci-bridge/pci_expander_bridge.c
> b/hw/pci-bridge/pci_expander_bridge.c
> index 47aaaf8fd1..3d896dd452 100644
> --- a/hw/pci-bridge/pci_expander_bridge.c
> +++ b/hw/pci-bridge/pci_expander_bridge.c
> @@ -15,6 +15,7 @@
> #include "hw/pci/pci.h"
> #include "hw/pci/pci_bus.h"
> #include "hw/pci/pci_host.h"
> +#include "hw/pci/pcie_port.h"
> #include "hw/qdev-properties.h"
> #include "hw/pci/pci_bridge.h"
> #include "qemu/range.h"
> @@ -233,7 +234,15 @@ static void pxb_dev_realize_common(PCIDevice *dev, bool
> pcie, Error **errp)
>
> ds = qdev_create(NULL, TYPE_PXB_HOST);
> if (pcie) {
> +#ifdef __aarch64__
> +bus = pci_root_bus_new(ds, "pxb-pcie-internal",
> + NULL, NULL, 0, TYPE_PXB_PCIE_BUS);
> +bds = qdev_create(BUS(bus), "pcie-root-port");
> +bds->id = dev_name;
> +qdev_prop_set_uint8(bds, PCIE_ROOT_PORT_PROP_CHASSIS, pxb->bus_nr);
> +#else
> bus = pci_root_bus_new(ds, dev_name, NULL, NULL, 0,
> TYPE_PXB_PCIE_BUS);
> +#endif
What does all this have to do with building on aarch64?
> } else {
> bus = pci_root_bus_new(ds, "pxb-internal", NULL, NULL, 0,
> TYPE_PXB_BUS);
> bds = qdev_create(BUS(bus), "pci-bridge");
> diff --git a/include/hw/pci/pcie_port.h b/include/hw/pci/pcie_port.h
> index 4b3d254b08..b41d473220 100644
> --- a/include/hw/pci/pcie_port.h
> +++ b/include/hw/pci/pcie_port.h
> @@ -64,6 +64,7 @@ int pcie_chassis_add_slot(struct PCIESlot *slot);
> void pcie_chassis_del_slot(PCIESlot *s);
>
> #define TYPE_PCIE_ROOT_PORT "pcie-root-port-base"
> +#define PCIE_ROOT_PORT_PROP_CHASSIS "chassis"
If you are going to do this, replace other instances of "chassis"
with the macro.
> #define PCIE_ROOT_PORT_CLASS(klass) \
> OBJECT_CLASS_CHECK(PCIERootPortClass, (klass), TYPE_PCIE_ROOT_PORT)
> #define PCIE_ROOT_PORT_GET_CLASS(obj) \
> --
> 2.19.1
>
Re: [PATCH] migration/postcopy: not necessary to discard all RAM at the beginning
* Wei Yang (richardw.y...@linux.intel.com) wrote:
> ram_discard_range() unmap page for specific range. To be specific, this
> clears related page table entries so that userfault would be triggered.
> But this step is not necessary at the very beginning.
>
> ram_postcopy_incoming_init() is called when destination gets ADVISE
> command. ADVISE command is sent when migration thread just starts, which
> implies destination is not running yet. This means no page fault
> happened and memory region's page tables entries are empty.
>
> This patch removes the discard at the beginning.
>
> Signed-off-by: Wei Yang
> ---
> migration/postcopy-ram.c | 46
> migration/postcopy-ram.h | 7 --
> migration/ram.c | 16 --
> migration/ram.h | 1 -
> migration/savevm.c | 4
> 5 files changed, 74 deletions(-)
>
> diff --git a/migration/postcopy-ram.c b/migration/postcopy-ram.c
> index 5da6de8c8b..459be8e780 100644
> --- a/migration/postcopy-ram.c
> +++ b/migration/postcopy-ram.c
> @@ -443,32 +443,6 @@ out:
> return ret;
> }
>
> -/*
> - * Setup an area of RAM so that it *can* be used for postcopy later; this
> - * must be done right at the start prior to pre-copy.
> - * opaque should be the MIS.
> - */
> -static int init_range(RAMBlock *rb, void *opaque)
> -{
> -const char *block_name = qemu_ram_get_idstr(rb);
> -void *host_addr = qemu_ram_get_host_addr(rb);
> -ram_addr_t offset = qemu_ram_get_offset(rb);
> -ram_addr_t length = qemu_ram_get_used_length(rb);
> -trace_postcopy_init_range(block_name, host_addr, offset, length);
> -
> -/*
> - * We need the whole of RAM to be truly empty for postcopy, so things
> - * like ROMs and any data tables built during init must be zero'd
> - * - we're going to get the copy from the source anyway.
> - * (Precopy will just overwrite this data, so doesn't need the discard)
> - */
But this comment explains why we want to do the discard; we want to make
sure that any memory that's been populated by the destination during the
init process is discarded and replaced by content from the source.
Dave
> -if (ram_discard_range(block_name, 0, length)) {
> -return -1;
> -}
> -
> -return 0;
> -}
> -
> /*
> * At the end of migration, undo the effects of init_range
> * opaque should be the MIS.
> @@ -506,20 +480,6 @@ static int cleanup_range(RAMBlock *rb, void *opaque)
> return 0;
> }
>
> -/*
> - * Initialise postcopy-ram, setting the RAM to a state where we can go into
> - * postcopy later; must be called prior to any precopy.
> - * called from arch_init's similarly named ram_postcopy_incoming_init
> - */
> -int postcopy_ram_incoming_init(MigrationIncomingState *mis)
> -{
> -if (foreach_not_ignored_block(init_range, NULL)) {
> -return -1;
> -}
> -
> -return 0;
> -}
> -
> /*
> * Manage a single vote to the QEMU balloon inhibitor for all postcopy usage,
> * last caller wins.
> @@ -1282,12 +1242,6 @@ bool
> postcopy_ram_supported_by_host(MigrationIncomingState *mis)
> return false;
> }
>
> -int postcopy_ram_incoming_init(MigrationIncomingState *mis)
> -{
> -error_report("postcopy_ram_incoming_init: No OS support");
> -return -1;
> -}
> -
> int postcopy_ram_incoming_cleanup(MigrationIncomingState *mis)
> {
> assert(0);
> diff --git a/migration/postcopy-ram.h b/migration/postcopy-ram.h
> index c0ccf64a96..1c79c6e51f 100644
> --- a/migration/postcopy-ram.h
> +++ b/migration/postcopy-ram.h
> @@ -22,13 +22,6 @@ bool postcopy_ram_supported_by_host(MigrationIncomingState
> *mis);
> */
> int postcopy_ram_incoming_setup(MigrationIncomingState *mis);
>
> -/*
> - * Initialise postcopy-ram, setting the RAM to a state where we can go into
> - * postcopy later; must be called prior to any precopy.
> - * called from ram.c's similarly named ram_postcopy_incoming_init
> - */
> -int postcopy_ram_incoming_init(MigrationIncomingState *mis);
> -
> /*
> * At the end of a migration where postcopy_ram_incoming_init was called.
> */
> diff --git a/migration/ram.c b/migration/ram.c
> index dfc50d57d5..9a853703d8 100644
> --- a/migration/ram.c
> +++ b/migration/ram.c
> @@ -4015,22 +4015,6 @@ static int ram_load_cleanup(void *opaque)
> return 0;
> }
>
> -/**
> - * ram_postcopy_incoming_init: allocate postcopy data structures
> - *
> - * Returns 0 for success and negative if there was one error
> - *
> - * @mis: current migration incoming state
> - *
> - * Allocate data structures etc needed by incoming migration with
> - * postcopy-ram. postcopy-ram's similarly names
> - * postcopy_ram_incoming_init does the work.
> - */
> -int ram_postcopy_incoming_init(MigrationIncomingState *mis)
> -{
> -return postcopy_ram_incoming_init(mis);
> -}
> -
> /**
> * ram_load_postcopy: load a page in postcopy case
> *
> diff --git a/migration/ram.h b/migration/ram.h
> index 44fe4753ad..66cbff1d52
Re: VW ELF loader
On 13/02/20 02:43, Alexey Kardashevskiy wrote: > > Ok. So, I have made a small firmware which does OF CI, loads GRUB and > instantiates RTAS: > https://github.com/aik/of1275 > Quite raw but gives the idea. > > It does not contain drivers and still relies on QEMU to hook an OF path > to a backend. Is this a showstopper and without drivers it is no go? Thanks, Yes, it's really the drivers. Something like netboot wouldn't work for example. I don't have a problem with relying on QEMU for opening and closing OF paths, but I really believe that read/write on ihandles should be done within the firmware and not QEMU. Paolo
[PATCH v3 5/9] linux-user: mips: Update syscall numbers to kernel 5.5 level
From: Aleksandar Markovic Update mips syscall numbers based on Linux kernel tag v5.5. CC: Aurelien Jarno CC: Aleksandar Rikalo Signed-off-by: Aleksandar Markovic Reviewed-by: Laurent Vivier --- linux-user/mips/syscall_nr.h | 45 +++ linux-user/mips64/syscall_nr.h | 50 - linux-user/mips/cpu_loop.c | 83 +- 3 files changed, 175 insertions(+), 3 deletions(-) diff --git a/linux-user/mips/syscall_nr.h b/linux-user/mips/syscall_nr.h index 7fa7fa5..0be3af1 100644 --- a/linux-user/mips/syscall_nr.h +++ b/linux-user/mips/syscall_nr.h @@ -376,5 +376,50 @@ #define TARGET_NR_statx (TARGET_NR_Linux + 366) #define TARGET_NR_rseq (TARGET_NR_Linux + 367) #define TARGET_NR_io_pgetevents (TARGET_NR_Linux + 368) +/* room for arch specific calls */ +#define TARGET_NR_semget(TARGET_NR_Linux + 393) +#define TARGET_NR_semctl(TARGET_NR_Linux + 394) +#define TARGET_NR_shmget(TARGET_NR_Linux + 395) +#define TARGET_NR_shmctl(TARGET_NR_Linux + 396) +#define TARGET_NR_shmat (TARGET_NR_Linux + 397) +#define TARGET_NR_shmdt (TARGET_NR_Linux + 398) +#define TARGET_NR_msgget(TARGET_NR_Linux + 399) +#define TARGET_NR_msgsnd(TARGET_NR_Linux + 400) +#define TARGET_NR_msgrcv(TARGET_NR_Linux + 401) +#define TARGET_NR_msgctl(TARGET_NR_Linux + 402) +/* 403-423 common for 32-bit archs */ +#define TARGET_NR_clock_gettime64 (TARGET_NR_Linux + 403) +#define TARGET_NR_clock_settime64 (TARGET_NR_Linux + 404) +#define TARGET_NR_clock_adjtime64 (TARGET_NR_Linux + 405) +#define TARGET_NR_clock_getres_time64 (TARGET_NR_Linux + 406) +#define TARGET_NR_clock_nanosleep_time64 (TARGET_NR_Linux + 407) +#define TARGET_NR_timer_gettime64 (TARGET_NR_Linux + 408) +#define TARGET_NR_timer_settime64 (TARGET_NR_Linux + 409) +#define TARGET_NR_timerfd_gettime64(TARGET_NR_Linux + 410) +#define TARGET_NR_timerfd_settime64(TARGET_NR_Linux + 411) +#define TARGET_NR_utimensat_time64 (TARGET_NR_Linux + 412) +#define TARGET_NR_pselect6_time64 (TARGET_NR_Linux + 413) +#define TARGET_NR_ppoll_time64 (TARGET_NR_Linux + 414) +#define TARGET_NR_io_pgetevents_time64 (TARGET_NR_Linux + 416) +#define TARGET_NR_recvmmsg_time64 (TARGET_NR_Linux + 417) +#define TARGET_NR_mq_timedsend_time64 (TARGET_NR_Linux + 418) +#define TARGET_NR_mq_timedreceive_time64 (TARGET_NR_Linux + 419) +#define TARGET_NR_semtimedop_time64(TARGET_NR_Linux + 420) +#define TARGET_NR_rt_sigtimedwait_time64 (TARGET_NR_Linux + 421) +#define TARGET_NR_futex_time64 (TARGET_NR_Linux + 422) +#define TARGET_NR_sched_rr_get_interval_time64 (TARGET_NR_Linux + 423) +/* 424 onwards common for all archs */ +#define TARGET_NR_pidfd_send_signal(TARGET_NR_Linux + 424) +#define TARGET_NR_io_uring_setup (TARGET_NR_Linux + 425) +#define TARGET_NR_io_uring_enter (TARGET_NR_Linux + 426) +#define TARGET_NR_io_uring_register(TARGET_NR_Linux + 427) +#define TARGET_NR_open_tree(TARGET_NR_Linux + 428) +#define TARGET_NR_move_mount (TARGET_NR_Linux + 429) +#define TARGET_NR_fsopen (TARGET_NR_Linux + 430) +#define TARGET_NR_fsconfig (TARGET_NR_Linux + 431) +#define TARGET_NR_fsmount (TARGET_NR_Linux + 432) +#define TARGET_NR_fspick (TARGET_NR_Linux + 433) +#define TARGET_NR_pidfd_open (TARGET_NR_Linux + 434) +#define TARGET_NR_clone3 (TARGET_NR_Linux + 435) #endif diff --git a/linux-user/mips64/syscall_nr.h b/linux-user/mips64/syscall_nr.h index db40f69..6e23e9f 100644 --- a/linux-user/mips64/syscall_nr.h +++ b/linux-user/mips64/syscall_nr.h @@ -339,6 +339,39 @@ #define TARGET_NR_statx (TARGET_NR_Linux + 330) #define TARGET_NR_rseq (TARGET_NR_Linux + 331) #define TARGET_NR_io_pgetevents (TARGET_NR_Linux + 332) +/* 333 through 402 are unassigned to sync up with generic numbers */ +#define TARGET_NR_clock_gettime64 (TARGET_NR_Linux + 403) +#define TARGET_NR_clock_settime64 (TARGET_NR_Linux + 404) +#define TARGET_NR_clock_adjtime64 (TARGET_NR_Linux + 405) +#define TARGET_NR_clock_getres_time64 (TARGET_NR_Linux + 406) +#define TARGET_NR_clock_nanosleep_time64 (TARGET_NR_Linux + 407) +#define TARGET_NR_timer_gettime64 (TARGET_NR_Linux + 408) +#define TARGET_NR_timer_settime64 (TARGET_NR_Linux + 409) +#define TARGET_NR_timerfd_gettime64 (TARGET_NR_Linux + 410) +#define TARGET_NR_timerfd_settime64 (TARGET_NR_Linux + 411) +#define
[PATCH v3 6/9] linux-user: sh4: Update syscall numbers to kernel 5.5 level
From: Aleksandar Markovic Update sh4 syscall numbers based on Linux kernel v5.5. CC: Aurelien Jarno Signed-off-by: Aleksandar Markovic Reviewed-by: Laurent Vivier --- linux-user/sh4/syscall_nr.h | 48 + 1 file changed, 48 insertions(+) diff --git a/linux-user/sh4/syscall_nr.h b/linux-user/sh4/syscall_nr.h index d53a2a0..8c21fcf 100644 --- a/linux-user/sh4/syscall_nr.h +++ b/linux-user/sh4/syscall_nr.h @@ -389,5 +389,53 @@ #define TARGET_NR_copy_file_range 380 #define TARGET_NR_preadv2 381 #define TARGET_NR_pwritev2 382 +#define TARGET_NR_statx 383 +#define TARGET_NR_pkey_mprotect 384 +#define TARGET_NR_pkey_alloc385 +#define TARGET_NR_pkey_free 386 +#define TARGET_NR_rseq 387 +/* room for arch specific syscalls */ +#define TARGET_NR_semget 393 +#define TARGET_NR_semctl 394 +#define TARGET_NR_shmget 395 +#define TARGET_NR_shmctl 396 +#define TARGET_NR_shmat 397 +#define TARGET_NR_shmdt 398 +#define TARGET_NR_msgget 399 +#define TARGET_NR_msgsnd 400 +#define TARGET_NR_msgrcv 401 +#define TARGET_NR_msgctl 402 +#define TARGET_NR_clock_gettime64403 +#define TARGET_NR_clock_settime64404 +#define TARGET_NR_clock_adjtime64405 +#define TARGET_NR_clock_getres_time64406 +#define TARGET_NR_clock_nanosleep_time64 407 +#define TARGET_NR_timer_gettime64408 +#define TARGET_NR_timer_settime64409 +#define TARGET_NR_timerfd_gettime64 410 +#define TARGET_NR_timerfd_settime64 411 +#define TARGET_NR_utimensat_time64 412 +#define TARGET_NR_pselect6_time64413 +#define TARGET_NR_ppoll_time64 414 +#define TARGET_NR_io_pgetevents_time64 416 +#define TARGET_NR_recvmmsg_time64417 +#define TARGET_NR_mq_timedsend_time64418 +#define TARGET_NR_mq_timedreceive_time64 419 +#define TARGET_NR_semtimedop_time64 420 +#define TARGET_NR_rt_sigtimedwait_time64 421 +#define TARGET_NR_futex_time64 422 +#define TARGET_NR_sched_rr_get_interval_time64 423 +#define TARGET_NR_pidfd_send_signal 424 +#define TARGET_NR_io_uring_setup 425 +#define TARGET_NR_io_uring_enter 426 +#define TARGET_NR_io_uring_register 427 +#define TARGET_NR_open_tree 428 +#define TARGET_NR_move_mount 429 +#define TARGET_NR_fsopen 430 +#define TARGET_NR_fsconfig 431 +#define TARGET_NR_fsmount432 +#define TARGET_NR_fspick 433 +#define TARGET_NR_pidfd_open 434 +/* 435 reserved for clone3 */ #endif -- 2.7.4
[PATCH v3 2/9] linux-user: arm: Update syscall numbers to kernel 5.5 level
From: Aleksandar Markovic Update arm syscall numbers based on Linux kernel v5.5. CC: Peter Maydell Signed-off-by: Aleksandar Markovic Reviewed-by: Laurent Vivier --- linux-user/arm/syscall_nr.h | 44 1 file changed, 44 insertions(+) diff --git a/linux-user/arm/syscall_nr.h b/linux-user/arm/syscall_nr.h index e7eda0d..6db9235 100644 --- a/linux-user/arm/syscall_nr.h +++ b/linux-user/arm/syscall_nr.h @@ -399,5 +399,49 @@ #define TARGET_NR_userfaultfd (388) #define TARGET_NR_membarrier (389) #define TARGET_NR_mlock2 (390) +#define TARGET_NR_copy_file_range (391) +#define TARGET_NR_preadv2 (392) +#define TARGET_NR_pwritev2 (393) +#define TARGET_NR_pkey_mprotect(394) +#define TARGET_NR_pkey_alloc (395) +#define TARGET_NR_pkey_free(396) +#define TARGET_NR_statx(397) +#define TARGET_NR_rseq (398) +#define TARGET_NR_io_pgetevents(399) +#define TARGET_NR_migrate_pages(400) +#define TARGET_NR_kexec_file_load (401) +/* 402 is unused */ +#define TARGET_NR_clock_gettime64 (403) +#define TARGET_NR_clock_settime64 (404) +#define TARGET_NR_clock_adjtime64 (405) +#define TARGET_NR_clock_getres_time64 (406) +#define TARGET_NR_clock_nanosleep_time64 (407) +#define TARGET_NR_timer_gettime64 (408) +#define TARGET_NR_timer_settime64 (409) +#define TARGET_NR_timerfd_gettime64(410) +#define TARGET_NR_timerfd_settime64(411) +#define TARGET_NR_utimensat_time64 (412) +#define TARGET_NR_pselect6_time64 (413) +#define TARGET_NR_ppoll_time64 (414) +#define TARGET_NR_io_pgetevents_time64 (416) +#define TARGET_NR_recvmmsg_time64 (417) +#define TARGET_NR_mq_timedsend_time64 (418) +#define TARGET_NR_mq_timedreceive_time64 (419) +#define TARGET_NR_semtimedop_time64(420) +#define TARGET_NR_rt_sigtimedwait_time64 (421) +#define TARGET_NR_futex_time64 (422) +#define TARGET_NR_sched_rr_get_interval_time64 (423) +#define TARGET_NR_pidfd_send_signal(424) +#define TARGET_NR_io_uring_setup (425) +#define TARGET_NR_io_uring_enter (426) +#define TARGET_NR_io_uring_register(427) +#define TARGET_NR_open_tree(428) +#define TARGET_NR_move_mount (429) +#define TARGET_NR_fsopen (430) +#define TARGET_NR_fsconfig (431) +#define TARGET_NR_fsmount (432) +#define TARGET_NR_fspick (433) +#define TARGET_NR_pidfd_open (434) +#define TARGET_NR_clone3 (435) #endif -- 2.7.4
Re: [PATCH v2] hw/char/exynos4210_uart: Fix memleaks in exynos4210_uart_init
On 2/13/20 3:56 AM, kuhn.chen...@huawei.com wrote:
From: Chen Qun
It's easy to reproduce as follow:
virsh qemu-monitor-command vm1 --pretty '{"execute": "device-list-properties",
"arguments":{"typename":"exynos4210.uart"}}'
ASAN shows memory leak stack:
#1 0xfffd896d71cb in g_malloc0 (/lib64/libglib-2.0.so.0+0x571cb)
#2 0xaaad270beee3 in timer_new_full /qemu/include/qemu/timer.h:530
#3 0xaaad270beee3 in timer_new /qemu/include/qemu/timer.h:551
#4 0xaaad270beee3 in timer_new_ns /qemu/include/qemu/timer.h:569
#5 0xaaad270beee3 in exynos4210_uart_init /qemu/hw/char/exynos4210_uart.c:677
#6 0xaaad275c8f4f in object_initialize_with_type /qemu/qom/object.c:516
#7 0xaaad275c91bb in object_new_with_type /qemu/qom/object.c:684
#8 0xaaad2755df2f in qmp_device_list_properties /qemu/qom/qom-qmp-cmds.c:152
Reported-by: Euler Robot
Signed-off-by: Chen Qun
---
Changes V2 to V1:
-Keep s->wordtime in exynos4210_uart_init (Base on Eduardo and Philippe's
comments).
Thanks.
Reviewed-by: Philippe Mathieu-Daudé
---
hw/char/exynos4210_uart.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/hw/char/exynos4210_uart.c b/hw/char/exynos4210_uart.c
index 25d6588e41..96d5180e3e 100644
--- a/hw/char/exynos4210_uart.c
+++ b/hw/char/exynos4210_uart.c
@@ -674,8 +674,6 @@ static void exynos4210_uart_init(Object *obj)
SysBusDevice *dev = SYS_BUS_DEVICE(obj);
Exynos4210UartState *s = EXYNOS4210_UART(dev);
-s->fifo_timeout_timer = timer_new_ns(QEMU_CLOCK_VIRTUAL,
- exynos4210_uart_timeout_int, s);
s->wordtime = NANOSECONDS_PER_SECOND * 10 / 9600;
/* memory mapping */
@@ -691,6 +689,9 @@ static void exynos4210_uart_realize(DeviceState *dev, Error
**errp)
{
Exynos4210UartState *s = EXYNOS4210_UART(dev);
+s->fifo_timeout_timer = timer_new_ns(QEMU_CLOCK_VIRTUAL,
+ exynos4210_uart_timeout_int, s);
+
qemu_chr_fe_set_handlers(>chr, exynos4210_uart_can_receive,
exynos4210_uart_receive, exynos4210_uart_event,
NULL, s, NULL, true);
Re: [RFC 1/2] arm: acpi: pci-expender-bus: Make arm to support PXB-PCIE
On Thu, Feb 13, 2020 at 03:49:51PM +0800, Yubo Miao wrote:
> From: miaoyubo
>
> Currently virt machine is not supported by pxb-pcie,
> and only one main host bridge described in ACPI tables.
> Under this circumstance, different io numas for differnt devices
> is not possible, in order to present io numas to the guest,
> especially for host pssthrough devices. PXB-PCIE is supproted
> by arm and certain resource is allocated for each pxb-pcie
> in acpi table.
>
> Signed-off-by: miaoyubo
> ---
> hw/arm/virt-acpi-build.c | 234 +--
> hw/pci-host/gpex.c | 4 +
> include/hw/arm/virt.h| 1 +
> 3 files changed, 228 insertions(+), 11 deletions(-)
>
> diff --git a/hw/arm/virt-acpi-build.c b/hw/arm/virt-acpi-build.c
> index bd5f771e9b..2e449d0098 100644
> --- a/hw/arm/virt-acpi-build.c
> +++ b/hw/arm/virt-acpi-build.c
> @@ -49,6 +49,8 @@
> #include "kvm_arm.h"
> #include "migration/vmstate.h"
>
> +#include "hw/arm/virt.h"
> +#include "hw/pci/pci_bus.h"
> #define ARM_SPI_BASE 32
>
> static void acpi_dsdt_add_cpus(Aml *scope, int smp_cpus)
> @@ -152,20 +154,227 @@ static void acpi_dsdt_add_virtio(Aml *scope,
> }
>
> static void acpi_dsdt_add_pci(Aml *scope, const MemMapEntry *memmap,
> - uint32_t irq, bool use_highmem, bool
> highmem_ecam)
> + uint32_t irq, bool use_highmem, bool
> highmem_ecam,
> + VirtMachineState *vms)
> {
> int ecam_id = VIRT_ECAM_ID(highmem_ecam);
> -Aml *method, *crs, *ifctx, *UUID, *ifctx1, *elsectx, *buf;
> +Aml *method, *crs, *ifctx, *UUID, *ifctx1, *elsectx, *buf, *dev;
> int i, bus_no;
> +int count = 0;
> hwaddr base_mmio = memmap[VIRT_PCIE_MMIO].base;
> hwaddr size_mmio = memmap[VIRT_PCIE_MMIO].size;
> hwaddr base_pio = memmap[VIRT_PCIE_PIO].base;
> hwaddr size_pio = memmap[VIRT_PCIE_PIO].size;
> hwaddr base_ecam = memmap[ecam_id].base;
> hwaddr size_ecam = memmap[ecam_id].size;
> +/*
> + * 0x60 would be enough for pxb device
> + * if it is too small, there is no enough space
> + * for a pcie device plugged in a pcie-root port
> + */
> +hwaddr size_addr = 0x60;
> +hwaddr size_io = 0x4000;
> int nr_pcie_buses = size_ecam / PCIE_MMCFG_SIZE_MIN;
> +int root_bus_limit = 0xFF;
> +PCIBus *bus = NULL;
> +bus = VIRT_MACHINE(vms)->bus;
> +
> +if (bus) {
> +QLIST_FOREACH(bus, >child, sibling) {
> +uint8_t bus_num = pci_bus_num(bus);
> +uint8_t numa_node = pci_bus_numa_node(bus);
> +
> +if (!pci_bus_is_root(bus)) {
> +continue;
> +}
> +if (bus_num < root_bus_limit) {
> +root_bus_limit = bus_num - 1;
> +}
> +count++;
> +dev = aml_device("PC%.02X", bus_num);
> +aml_append(dev, aml_name_decl("_HID", aml_string("PNP0A08")));
> +aml_append(dev, aml_name_decl("_CID", aml_string("PNP0A03")));
> +aml_append(dev, aml_name_decl("_ADR", aml_int(0)));
> +aml_append(dev, aml_name_decl("_CCA", aml_int(1)));
> +aml_append(dev, aml_name_decl("_SEG", aml_int(0)));
> +aml_append(dev, aml_name_decl("_BBN", aml_int(bus_num)));
> +aml_append(dev, aml_name_decl("_UID", aml_int(bus_num)));
> +aml_append(dev, aml_name_decl("_STR", aml_unicode("pxb
> Device")));
> +if (numa_node != NUMA_NODE_UNASSIGNED) {
> +method = aml_method("_PXM", 0, AML_NOTSERIALIZED);
> +aml_append(method, aml_return(aml_int(numa_node)));
> +aml_append(dev, method);
> +}
> +/* Declare the PCI Routing Table. */
> +Aml *rt_pkg = aml_varpackage(nr_pcie_buses * PCI_NUM_PINS);
> +for (bus_no = 0; bus_no < nr_pcie_buses; bus_no++) {
> +for (i = 0; i < PCI_NUM_PINS; i++) {
> +int gsi = (i + bus_no) % (PCI_NUM_PINS);
> +Aml *pkg = aml_package(4);
> +aml_append(pkg, aml_int((bus_no << 16) | 0x));
> +aml_append(pkg, aml_int(i));
> +aml_append(pkg, aml_name("GSI%d", gsi));
> +aml_append(pkg, aml_int(0));
> +aml_append(rt_pkg, pkg);
> +}
> +}
> +aml_append(dev, aml_name_decl("_PRT", rt_pkg));
> +
> +for (i = 0; i < PCI_NUM_PINS; i++) {
> +uint32_t irqs = irq + i;
> +Aml *dev_gsi = aml_device("GSI%d", i);
> +aml_append(dev_gsi, aml_name_decl("_HID",
> + aml_string("PNP0C0F")));
> +aml_append(dev_gsi, aml_name_decl("_UID", aml_int(0)));
> +crs = aml_resource_template();
> +aml_append(crs,
> +
[PULL 3/6] migration/rdma: rdma_accept_incoming_migration fix error handling
From: "Dr. David Alan Gilbert"
rdma_accept_incoming_migration is called from an fd handler and
can't return an Error * anywhere.
Currently it's leaking Error's in errp/local_err - there's
no point putting them in there unless we can report them.
Turn most into fprintf's, and the last into an error_reportf_err
where it's coming up from another function.
Signed-off-by: Dr. David Alan Gilbert
Reviewed-by: Juan Quintela
Signed-off-by: Juan Quintela
---
migration/rdma.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/migration/rdma.c b/migration/rdma.c
index 2379b8345b..f61587891b 100644
--- a/migration/rdma.c
+++ b/migration/rdma.c
@@ -3980,13 +3980,13 @@ static void rdma_accept_incoming_migration(void *opaque)
RDMAContext *rdma = opaque;
int ret;
QEMUFile *f;
-Error *local_err = NULL, **errp = _err;
+Error *local_err = NULL;
trace_qemu_rdma_accept_incoming_migration();
ret = qemu_rdma_accept(rdma);
if (ret) {
-ERROR(errp, "RDMA Migration initialization failed!");
+fprintf(stderr, "RDMA ERROR: Migration initialization failed\n");
return;
}
@@ -3998,13 +3998,16 @@ static void rdma_accept_incoming_migration(void *opaque)
f = qemu_fopen_rdma(rdma, "rb");
if (f == NULL) {
-ERROR(errp, "could not qemu_fopen_rdma!");
+fprintf(stderr, "RDMA ERROR: could not qemu_fopen_rdma\n");
qemu_rdma_cleanup(rdma);
return;
}
rdma->migration_started_on_destination = 1;
-migration_fd_process_incoming(f, errp);
+migration_fd_process_incoming(f, _err);
+if (local_err) {
+error_reportf_err(local_err, "RDMA ERROR:");
+}
}
void rdma_start_incoming_migration(const char *host_port, Error **errp)
--
2.24.1
[PULL 2/6] migration: Optimization about wait-unplug migration state
From: Keqian Zhu
qemu_savevm_nr_failover_devices() is originally designed to
get the number of failover devices, but it actually returns
the number of "unplug-pending" failover devices now. Moreover,
what drives migration state to wait-unplug should be the number
of "unplug-pending" failover devices, not all failover devices.
We can also notice that qemu_savevm_state_guest_unplug_pending()
and qemu_savevm_nr_failover_devices() is equivalent almost (from
the code view). So the latter is incorrect semantically and
useless, just delete it.
In the qemu_savevm_state_guest_unplug_pending(), once hit a
unplug-pending failover device, then it can return true right
now to save cpu time.
Signed-off-by: Keqian Zhu
Reviewed-by: Juan Quintela
Tested-by: Jens Freimann
Reviewed-by: Jens Freimann
Signed-off-by: Juan Quintela
---
migration/migration.c | 2 +-
migration/savevm.c| 24 +++-
migration/savevm.h| 1 -
3 files changed, 4 insertions(+), 23 deletions(-)
diff --git a/migration/migration.c b/migration/migration.c
index 1ca6be2323..8fb68795dc 100644
--- a/migration/migration.c
+++ b/migration/migration.c
@@ -3341,7 +3341,7 @@ static void *migration_thread(void *opaque)
qemu_savevm_state_setup(s->to_dst_file);
-if (qemu_savevm_nr_failover_devices()) {
+if (qemu_savevm_state_guest_unplug_pending()) {
migrate_set_state(>state, MIGRATION_STATUS_SETUP,
MIGRATION_STATUS_WAIT_UNPLUG);
diff --git a/migration/savevm.c b/migration/savevm.c
index f19cb9ec7a..1d4220ece8 100644
--- a/migration/savevm.c
+++ b/migration/savevm.c
@@ -1140,36 +1140,18 @@ void qemu_savevm_state_header(QEMUFile *f)
}
}
-int qemu_savevm_nr_failover_devices(void)
+bool qemu_savevm_state_guest_unplug_pending(void)
{
SaveStateEntry *se;
-int n = 0;
QTAILQ_FOREACH(se, _state.handlers, entry) {
if (se->vmsd && se->vmsd->dev_unplug_pending &&
se->vmsd->dev_unplug_pending(se->opaque)) {
-n++;
-}
-}
-
-return n;
-}
-
-bool qemu_savevm_state_guest_unplug_pending(void)
-{
-SaveStateEntry *se;
-int n = 0;
-
-QTAILQ_FOREACH(se, _state.handlers, entry) {
-if (!se->vmsd || !se->vmsd->dev_unplug_pending) {
-continue;
-}
-if (se->vmsd->dev_unplug_pending(se->opaque)) {
-n++;
+return true;
}
}
-return n > 0;
+return false;
}
void qemu_savevm_state_setup(QEMUFile *f)
diff --git a/migration/savevm.h b/migration/savevm.h
index c42b9c80ee..ba64a7e271 100644
--- a/migration/savevm.h
+++ b/migration/savevm.h
@@ -31,7 +31,6 @@
bool qemu_savevm_state_blocked(Error **errp);
void qemu_savevm_state_setup(QEMUFile *f);
-int qemu_savevm_nr_failover_devices(void);
bool qemu_savevm_state_guest_unplug_pending(void);
int qemu_savevm_state_resume_prepare(MigrationState *s);
void qemu_savevm_state_header(QEMUFile *f);
--
2.24.1
[PULL 0/6] Pull migration patches
The following changes since commit e18e5501d8ac692d32657a3e1ef545b14e72b730: Merge remote-tracking branch 'remotes/dgilbert-gitlab/tags/pull-virtiofs-20200210' into staging (2020-02-10 18:09:14 +) are available in the Git repository at: https://github.com/juanquintela/qemu.git tags/pull-migration-pull-request for you to fetch changes up to 1a920d2b633e13df8961328b3b3e128989a34570: git: Make submodule check only needed modules (2020-02-13 11:31:58 +0100) Migration pull request - don't pause when migration has been cancelled (Zhimin) - fix memleaks in tests (pan)( - optimize wait-unplug (keqian) - improve rdma error handling/messages (dave) - add some flexibility in autoconverge test (dave) - git-submodule: allow compiliation from same tree with different number of git-submodules (juan) Please, Apply. Dr. David Alan Gilbert (2): migration/rdma: rdma_accept_incoming_migration fix error handling tests/migration: Add some slack to auto converge Juan Quintela (1): git: Make submodule check only needed modules Keqian Zhu (1): migration: Optimization about wait-unplug migration state Pan Nengyuan (1): migration-test: fix some memleaks in migration-test Zhimin Feng (1): migration: Maybe VM is paused when migration is cancelled migration/migration.c| 26 +- migration/rdma.c | 11 +++ migration/savevm.c | 24 +++- migration/savevm.h | 1 - scripts/git-submodule.sh | 12 tests/qtest/migration-test.c | 17 ++--- 6 files changed, 49 insertions(+), 42 deletions(-) -- 2.24.1
[PULL 4/6] tests/migration: Add some slack to auto converge
From: "Dr. David Alan Gilbert" There's an assert in autoconverge that checks that we quit the iteration when we go below the expected threshold. Philippe saw a case where this assert fired with the measured value slightly over the threshold. (about 3k out of a few million). I can think of two reasons: a) Rounding errors b) That after we make the decision to quit iteration we do one more sync and that sees a few more dirty pages. So add 1% slack to the assertion, that should cover a and most cases of b, probably all we'll see for the test. Signed-off-by: Dr. David Alan Gilbert Reviewed-by: Juan Quintela Reviewed-by: Peter Xu Signed-off-by: Juan Quintela --- tests/qtest/migration-test.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/tests/qtest/migration-test.c b/tests/qtest/migration-test.c index cf27ebbc9d..a78ac0c7da 100644 --- a/tests/qtest/migration-test.c +++ b/tests/qtest/migration-test.c @@ -1237,7 +1237,8 @@ static void test_migrate_auto_converge(void) g_assert_cmpint(percentage, <=, max_pct); remaining = read_ram_property_int(from, "remaining"); -g_assert_cmpint(remaining, <, expected_threshold); +g_assert_cmpint(remaining, <, +(expected_threshold + expected_threshold / 100)); migrate_continue(from, "pre-switchover"); -- 2.24.1
Re: [PATCH v2 fixed 00/16] Ram blocks with resizable anonymous allocations under POSIX
On 12.02.20 19:03, David Hildenbrand wrote: > On 12.02.20 14:42, David Hildenbrand wrote: >> We already allow resizable ram blocks for anonymous memory, however, they >> are not actually resized. All memory is mmaped() R/W, including the memory >> exceeding the used_length, up to the max_length. >> >> When resizing, effectively only the boundary is moved. Implement actually >> resizable anonymous allocations and make use of them in resizable ram >> blocks when possible. Memory exceeding the used_length will be >> inaccessible. Especially ram block notifiers require care. >> >> Having actually resizable anonymous allocations (via mmap-hackery) allows >> to reserve a big region in virtual address space and grow the >> accessible/usable part on demand. Even if "/proc/sys/vm/overcommit_memory" >> is set to "never" under Linux, huge reservations will succeed. If there is >> not enough memory when resizing (to populate parts of the reserved region), >> trying to resize will fail. Only the actually used size is reserved in the >> OS. >> >> E.g., virtio-mem [1] wants to reserve big resizable memory regions and >> grow the usable part on demand. I think this change is worth sending out >> individually. Accompanied by a bunch of minor fixes and cleanups. >> >> Especially, memory notifiers already handle resizing by first removing >> the old region, and then re-adding the resized region. prealloc is >> currently not possible with resizable ram blocks. mlock() should continue >> to work as is. Resizing is currently rare and must only happen on the >> start of an incoming migration, or during resets. No code path (except >> HAX and SEV ram block notifiers) should access memory outside of the usable >> range - and if we ever find one, that one has to be fixed (I did not >> identify any). >> >> v1 -> v2: >> - Add "util: vfio-helpers: Fix qemu_vfio_close()" >> - Add "util: vfio-helpers: Remove Error parameter from >>qemu_vfio_undo_mapping()" >> - Add "util: vfio-helpers: Factor out removal from >>qemu_vfio_undo_mapping()" >> - "util/mmap-alloc: ..." >> -- Minor changes due to review feedback (e.g., assert alignment, return >> bool when resizing) >> - "util: vfio-helpers: Implement ram_block_resized()" >> -- Reserve max_size in the IOVA address space. >> -- On resize, undo old mapping and do new mapping. We can later implement >> a new ioctl to resize the mapping directly. >> - "numa: Teach ram block notifiers about resizable ram blocks" >> -- Pass size/max_size to ram block notifiers, which makes things easier an >> cleaner >> - "exec: Ram blocks with resizable anonymous allocations under POSIX" >> -- Adapt to new ram block notifiers >> -- Shrink after notifying. Always trigger ram block notifiers on resizes >> -- Add a safety net that all ram block notifiers registered at runtime >> support resizes. >> >> [1] https://lore.kernel.org/kvm/20191212171137.13872-1-da...@redhat.com/ >> >> David Hildenbrand (16): >> util: vfio-helpers: Factor out and fix processing of existing ram >> blocks >> util: vfio-helpers: Fix qemu_vfio_close() >> util: vfio-helpers: Remove Error parameter from >> qemu_vfio_undo_mapping() >> util: vfio-helpers: Factor out removal from qemu_vfio_undo_mapping() >> exec: Factor out setting ram settings (madvise ...) into >> qemu_ram_apply_settings() >> exec: Reuse qemu_ram_apply_settings() in qemu_ram_remap() >> exec: Drop "shared" parameter from ram_block_add() >> util/mmap-alloc: Factor out calculation of pagesize to mmap_pagesize() >> util/mmap-alloc: Factor out reserving of a memory region to >> mmap_reserve() >> util/mmap-alloc: Factor out populating of memory to mmap_populate() >> util/mmap-alloc: Prepare for resizable mmaps >> util/mmap-alloc: Implement resizable mmaps >> numa: Teach ram block notifiers about resizable ram blocks >> util: vfio-helpers: Implement ram_block_resized() >> util: oslib: Resizable anonymous allocations under POSIX >> exec: Ram blocks with resizable anonymous allocations under POSIX >> >> exec.c | 104 +++ >> hw/core/numa.c | 53 +++- >> hw/i386/xen/xen-mapcache.c | 7 +- >> include/exec/cpu-common.h | 3 + >> include/exec/memory.h | 8 ++ >> include/exec/ramlist.h | 14 +++- >> include/qemu/mmap-alloc.h | 21 +++-- >> include/qemu/osdep.h | 6 +- >> stubs/ram-block.c | 20 - >> target/i386/hax-mem.c | 5 +- >> target/i386/sev.c | 18 ++-- >> util/mmap-alloc.c | 165 +++-- >> util/oslib-posix.c | 37 - >> util/oslib-win32.c | 14 >> util/trace-events | 9 +- >> util/vfio-helpers.c| 145 +--- >> 16 files changed, 450 insertions(+), 179 deletions(-) >> > > 1. I will do resizable -> resizeable > 2. I think migration might indeed need some care regarding >
Re: [PATCH v2 1/2] spapr: Disable legacy virtio devices for pseries-5.0 and later
On Thu, 13 Feb 2020 11:58:36 +1100
David Gibson wrote:
> PAPR specifies a kind of odd, paravirtualized PCI bus, which looks to
> the guess mostly like classic PCI, even if some of the individual
> devices on the bus are PCI Express. One consequence of that is that
> virtio-pci devices still default to being in transitional mode, though
> legacy mode is now disabled by default on current q35 x86 machine
> types.
>
> Legacy mode virtio devices aren't really necessary any more, and are
> causing some problems for future changes. Therefore, for the
> pseries-5.0 machine type (and onwards), switch to modern-only
> virtio-pci devices by default.
>
> This does mean we no longer support guest kernels prior to 4.0, unless
> they have modern virtio support backported (which some distro kernels
> like that in RHEL7 do).
>
> Signed-off-by: David Gibson
> ---
> hw/ppc/spapr.c | 14 +-
> 1 file changed, 13 insertions(+), 1 deletion(-)
>
> diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
> index cb220fde45..6e1e467cc6 100644
> --- a/hw/ppc/spapr.c
> +++ b/hw/ppc/spapr.c
> @@ -65,6 +65,7 @@
>
> #include "hw/pci/pci.h"
> #include "hw/scsi/scsi.h"
> +#include "hw/virtio/virtio-pci.h"
> #include "hw/virtio/virtio-scsi.h"
> #include "hw/virtio/vhost-scsi-common.h"
>
> @@ -4567,7 +4568,14 @@ static void
> spapr_machine_latest_class_options(MachineClass *mc)
> */
> static void spapr_machine_5_0_class_options(MachineClass *mc)
> {
> -/* Defaults for the latest behaviour inherited from the base class */
Hmm... and so it seems we still have to carry this around when we
add a new machine version. At least, that's what I had to do when
adding a dummy 5.1 machine. This is because it is the old machine
type that calls the class_options() function of the new one, not
the other way around.
I was thinking about adapting Michael's patch. Instead of having
a class_options() function that we only call for the latest
machine type, we need a function that sets the default behaviour
and call it for all machine types (which can still change the
behaviour in their own class_options() function).
Something like the following:
-
diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
index 828e2cc1359a..27e6f79ddc40 100644
--- a/hw/ppc/spapr.c
+++ b/hw/ppc/spapr.c
@@ -4559,10 +4559,9 @@ static const TypeInfo spapr_machine_info = {
},
};
-static void spapr_machine_latest_class_options(MachineClass *mc)
+static void spapr_machine_default_class_options(MachineClass *mc)
{
-mc->alias = "pseries";
-mc->is_default = 1;
+/* Override non ppc specific default behaviour here. */
}
#define DEFINE_SPAPR_MACHINE(suffix, verstr, latest) \
@@ -4570,9 +4569,11 @@ static void
spapr_machine_latest_class_options(MachineClass *mc)
void *data) \
{\
MachineClass *mc = MACHINE_CLASS(oc);\
+spapr_machine_default_class_options(mc); \
spapr_machine_##suffix##_class_options(mc); \
if (latest) {\
-spapr_machine_latest_class_options(mc); \
+mc->alias = "pseries"; \
+mc->is_default = 1; \
}\
}\
static const TypeInfo spapr_machine_##suffix##_info = { \
@@ -4591,7 +4592,11 @@ static void
spapr_machine_latest_class_options(MachineClass *mc)
*/
static void spapr_machine_5_0_class_options(MachineClass *mc)
{
-/* Defaults for the latest behaviour inherited from the base class */
+/*
+ * Most defaults for the latest behaviour are inherited from the
+ * base class. If a non ppc specific default behaviour needs to
+ * be overriden, do it in spapr_machine_latest_class_options().
+ */
}
DEFINE_SPAPR_MACHINE(5_0, "5.0", true);
-
With the above applied...
> +/* Most defaults for the latest behaviour are inherited from the
> + * base class, but we need to override the (non ppc specific)
> + * default behaviour for virtio */
> +static GlobalProperty compat[] = {
> +{ TYPE_VIRTIO_PCI, "disable-legacy", "on", },
> +};
> +
> +compat_props_add(mc->compat_props, compat, G_N_ELEMENTS(compat));
... this change would just need to move to spapr_machine_default_class_options()
and any need machine type would have it automatically.
Makes sense ?
> }
>
> DEFINE_SPAPR_MACHINE(5_0, "5.0", true);
> @@ -4578,12 +4586,16 @@ DEFINE_SPAPR_MACHINE(5_0, "5.0", true);
> static void
Re: The issues about architecture of the COLO checkpoint
* Daniel Cho (daniel...@qnap.com) wrote: > Hi Hailiang, > > 1. > OK, we will try the patch > “0001-COLO-Optimize-memory-back-up-process.patch”, > and thanks for your help. > > 2. > We understand the reason to compare PVM and SVM's packet. However, the > empty of SVM's packet queue might happened on setting COLO feature and SVM > broken. > > On situation 1 ( setting COLO feature ): > We could force do checkpoint after setting COLO feature finish, then it > will protect the state of PVM and SVM . As the Zhang Chen said. > > On situation 2 ( SVM broken ): > COLO will do failover for PVM, so it might not cause any wrong on PVM. > > However, those situations are our views, so there might be a big difference > between reality and our views. > If we have any wrong views and opinions, please let us know, and correct > us. It does need a timeout; the SVM being broken or being in a state where it never sends the corresponding packet (because of a state difference) can happen and COLO needs to timeout when the packet hasn't arrived after a while and trigger the checkpoint. Dave > Thanks. > > Best regards, > Daniel Cho > > Zhang, Chen 於 2020年2月13日 週四 上午10:17寫道： > > > Add cc Jason Wang, he is a network expert. > > > > In case some network things goes wrong. > > > > > > > > Thanks > > > > Zhang Chen > > > > > > > > *From:* Zhang, Chen > > *Sent:* Thursday, February 13, 2020 10:10 AM > > *To:* 'Zhanghailiang' ; Daniel Cho < > > daniel...@qnap.com> > > *Cc:* Dr. David Alan Gilbert ; qemu-devel@nongnu.org > > *Subject:* RE: The issues about architecture of the COLO checkpoint > > > > > > > > For the issue 2: > > > > > > > > COLO need use the network packets to confirm PVM and SVM in the same state, > > > > Generally speaking, we can’t send PVM packets without compared with SVM > > packets. > > > > But to prevent jamming, I think COLO can do force checkpoint and send the > > PVM packets in this case. > > > > > > > > Thanks > > > > Zhang Chen > > > > > > > > *From:* Zhanghailiang > > *Sent:* Thursday, February 13, 2020 9:45 AM > > *To:* Daniel Cho > > *Cc:* Dr. David Alan Gilbert ; qemu-devel@nongnu.org; > > Zhang, Chen > > *Subject:* RE: The issues about architecture of the COLO checkpoint > > > > > > > > Hi, > > > > > > > > 1. After re-walked through the codes, yes, you are right, actually, > > after the first migration, we will keep dirty log on in primary side, > > > > And only send the dirty pages in PVM to SVM. The ram cache in secondary > > side is always a backup of PVM, so we don’t have to > > > > Re-send the none-dirtied pages. > > > > The reason why the first checkpoint takes longer time is we have to backup > > the whole VM’s ram into ram cache, that is colo_init_ram_cache(). > > > > It is time consuming, but I have optimized in the second patch > > “0001-COLO-Optimize-memory-back-up-process.patch” which you can find in my > > previous reply. > > > > > > > > Besides, I found that, In my previous reply “We can only copy the pages > > that dirtied by PVM and SVM in last checkpoint.”, > > > > We have done this optimization in current upstream codes. > > > > > > > > 2．I don’t quite understand this question. For COLO, we always need both > > network packets of PVM’s and SVM’s to compare before send this packets to > > client. > > > > It depends on this to decide whether or not PVM and SVM are in same state. > > > > > > > > Thanks, > > > > hailiang > > > > > > > > *From:* Daniel Cho [mailto:daniel...@qnap.com ] > > *Sent:* Wednesday, February 12, 2020 4:37 PM > > *To:* Zhang, Chen > > *Cc:* Zhanghailiang ; Dr. David Alan > > Gilbert ; qemu-devel@nongnu.org > > *Subject:* Re: The issues about architecture of the COLO checkpoint > > > > > > > > Hi Hailiang, > > > > > > > > Thanks for your replaying and explain in detail. > > > > We will try to use the attachments to enhance memory copy. > > > > > > > > However, we have some questions for your replying. > > > > > > > > 1. As you said, "for each checkpoint, we have to send the whole PVM's > > pages To SVM", why the only first checkpoint will takes more pause time? > > > > In our observing, the first checkpoint will take more time for pausing, > > then other checkpoints will takes a few time for pausing. Does it means > > only the first checkpoint will send the whole pages to SVM, and the other > > checkpoints send the dirty pages to SVM for reloading? > > > > > > > > 2. We notice the COLO-COMPARE component will stuck the packet until > > receive packets from PVM and SVM, as this rule, when we add the > > COLO-COMPARE to PVM, its network will stuck until SVM start. So it is an > > other issue to make PVM stuck while setting COLO feature. With this issue, > > could we let colo-compare to pass the PVM's packet when the SVM's packet > > queue is empty? Then, the PVM's network won't stock, and "if PVM runs > > firstly, it still need to wait for The network packets from SVM to > > compare before send it to client side" won't happened
Re: [PATCH v2 0/2] spapr: Use vIOMMU translation for virtio by default
On Thu, 13 Feb 2020 11:58:35 +1100 David Gibson wrote: > Upcoming Secure VM support for pSeries machines introduces some > complications for virtio, since the transfer buffers need to be > explicitly shared so that the hypervisor can access them. > > While it's not strictly speaking dependent on it, the fact that virtio > devices bypass normal platform IOMMU translation complicates the issue > on the guest side. Since there are some significan downsides to > bypassing the vIOMMU anyway, let's just disable that. > > There's already a flag to do this in virtio, just turn it on by > default for forthcoming pseries machine types. > > Any opinions on whether dropping support for the older guest kernels > is acceptable at this point? > As expected, this breaks compatibility with existing RHEL 6.10 guests. Each patch in this series requires an extra -global option to be specified on the command line in order to boot successfully. Patch 1: -global virtio-pci.disable-legacy=auto Patch 2: -global virtio-pci.iommu_platform=off As seen on the RH site [1], RHEL6 will reach "End of Maintenance Support or Maintenance Support 2 (Product retirement)" on November 30, 2020 and "End of Extended Life-cycle Support" on June 30, 2024. Not sure if it's okay to drop support for RHEL6 this soon. RHEL 7.7 guests seem to be unaffected. [1] https://access.redhat.com/support/policy/updates/errata/#Life_Cycle_Dates > Changes since v1: > * Added information on which guest kernel versions will no longer >work with these changes > * Use Michael Tsirkin's suggested better way of handling the machine >type change > > David Gibson (2): > spapr: Disable legacy virtio devices for pseries-5.0 and later > spapr: Enable virtio iommu_platform=on by default > > hw/ppc/spapr.c | 16 +++- > 1 file changed, 15 insertions(+), 1 deletion(-) >
Re: [PATCH v2 5/9] linux-user: mips: Update syscall numbers to kernel 5.5 level
> > + MIPS_SYS(sys_clock_gettime64, 2)
> > + MIPS_SYS(sys_clock_settime64, 4)
> > + MIPS_SYS(sys_clock_adjtime64, 2) /* 405 */
> > + MIPS_SYS(sys_clock_getres_time64, 4)
>
> According to
> https://github.com/strace/strace/blob/master/linux/syscallent-common-32.h:
>
> [BASE_NR + 406] = { 2, 0, SEN(clock_getres_time64),
> "clock_getres_time64" },
>
404 also has the same problem, I am going to fix both.
Thanks,
Aleksandar
>
> once fixed you can add my
>
> Reviewed-by: Laurent Vivier
[PATCH v3 4/9] linux-user: microblaze: Update syscall numbers to kernel 5.5 level
From: Aleksandar Markovic Update microblaze syscall numbers based on Linux kernel v5.5. CC: Edgar E. Iglesias Signed-off-by: Aleksandar Markovic Reviewed-by: Laurent Vivier --- linux-user/microblaze/syscall_nr.h | 45 ++ 1 file changed, 45 insertions(+) diff --git a/linux-user/microblaze/syscall_nr.h b/linux-user/microblaze/syscall_nr.h index aa2eb93..ec1758e 100644 --- a/linux-user/microblaze/syscall_nr.h +++ b/linux-user/microblaze/syscall_nr.h @@ -393,5 +393,50 @@ #define TARGET_NR_memfd_create 386 #define TARGET_NR_bpf 387 #define TARGET_NR_execveat 388 +#define TARGET_NR_userfaultfd 389 +#define TARGET_NR_membarrier390 +#define TARGET_NR_mlock2391 +#define TARGET_NR_copy_file_range 392 +#define TARGET_NR_preadv2 393 +#define TARGET_NR_pwritev2 394 +#define TARGET_NR_pkey_mprotect 395 +#define TARGET_NR_pkey_alloc396 +#define TARGET_NR_pkey_free 397 +#define TARGET_NR_statx 398 +#define TARGET_NR_io_pgetevents 399 +#define TARGET_NR_rseq 400 +/* 401 and 402 are unused */ +#define TARGET_NR_clock_gettime64 403 +#define TARGET_NR_clock_settime64 404 +#define TARGET_NR_clock_adjtime64 405 +#define TARGET_NR_clock_getres_time64 406 +#define TARGET_NR_clock_nanosleep_time64 407 +#define TARGET_NR_timer_gettime64 408 +#define TARGET_NR_timer_settime64 409 +#define TARGET_NR_timerfd_gettime64 410 +#define TARGET_NR_timerfd_settime64 411 +#define TARGET_NR_utimensat_time64 412 +#define TARGET_NR_pselect6_time64 413 +#define TARGET_NR_ppoll_time64 414 +#define TARGET_NR_io_pgetevents_time64 416 +#define TARGET_NR_recvmmsg_time64 417 +#define TARGET_NR_mq_timedsend_time64 418 +#define TARGET_NR_mq_timedreceive_time64 419 +#define TARGET_NR_semtimedop_time64 420 +#define TARGET_NR_rt_sigtimedwait_time64 421 +#define TARGET_NR_futex_time64 422 +#define TARGET_NR_sched_rr_get_interval_time64 423 +#define TARGET_NR_pidfd_send_signal 424 +#define TARGET_NR_io_uring_setup425 +#define TARGET_NR_io_uring_enter426 +#define TARGET_NR_io_uring_register 427 +#define TARGET_NR_open_tree 428 +#define TARGET_NR_move_mount429 +#define TARGET_NR_fsopen430 +#define TARGET_NR_fsconfig 431 +#define TARGET_NR_fsmount 432 +#define TARGET_NR_fspick433 +#define TARGET_NR_pidfd_open434 +#define TARGET_NR_clone3435 #endif -- 2.7.4
Re: [PATCH v5 4/8] multifd: Add multifd-zlib-level parameter
Daniel P. Berrangé writes:
> On Thu, Jan 30, 2020 at 09:03:00AM +0100, Markus Armbruster wrote:
>> Juan Quintela writes:
>>
>> > It will indicate which level use for compression.
>> >
>> > Signed-off-by: Juan Quintela
>>
>> This is slightly confusing (there is no zlib compression), unless you
>> peek at the next patch (which adds zlib compression).
>>
>> Three ways to make it less confusing:
>>
>> * Squash the two commits
>>
>> * Swap them: first add zlib compression with level hardcoded to 1, then
>> make the level configurable.
>>
>> * Have the first commit explain itself better. Something like
>>
>> multifd: Add multifd-zlib-level parameter
>>
>> This parameter specifies zlib compression level. The next patch
>> will put it to use.
>
> Wouldn't the "normal" best practice for QAPI design be to use a
> enum and discriminated union. eg
>
> { 'enum': 'MigrationCompression',
> 'data': ['none', 'zlib'] }
>
> { 'struct': 'MigrationCompressionParamsZLib',
> 'data': { 'compression-level' } }
>
> { 'union': 'MigrationCompressionParams',
> 'base': { 'mode': 'MigrationCompression' },
> 'discriminator': 'mode',
> 'data': {
> 'zlib': 'MigrationCompressionParamsZLib',
> }
This expresses the connection between compression mode and level. In
general, we prefer that to a bunch of optional members where the
comments say things like "member A can be present only when member B has
value V", or worse "member A is silently ignored unless member B has
value V". However:
> Of course this is quite different from how migration parameters are
> done today. Maybe it makes sense to stick with the flat list of
> migration parameters for consistency & ignore normal QAPI design
> practice ?
Unsure. It's certainly ugly now. Each parameter is defined in three
places: enum MigrationParameter (for HMP), struct MigrateSetParameters
(for QMP migrate-set-parameters), and struct MigrationParameters (for
QMP query-migrate-parameters).
I don't know how to make this better other than by starting over.
I don't know whether starting over would result in enough of an
improvement to make it worthwhile.
Re: [PATCH v2 1/2] target/arm: Fix select for aa64_va_parameters_both
On Thu, 13 Feb 2020 at 13:12, Peter Maydell wrote:
>
> On Tue, 11 Feb 2020 at 19:42, Richard Henderson
> wrote:
> >
> > Select should always be 0 for a regime with one range.
> >
> > Signed-off-by: Richard Henderson
>
> This change makes sense, and matches what aa32_va_parameters() does,
> but I think we need to update some of the callsites.
>
> (1) In get_phys_addr_lpae() we have the check:
>
> if (-top_bits != param.select || (param.select && !ttbr1_valid)) {
>
> where ttbr1_valid is the return value of (effectively)
> aarch64 ? regime_has_2_ranges() : (el != 2);
> but I think it's no longer possible to get here with param.select == 1
> and !ttbr1_valid, so this becomes a dead check.
...or should the code instead be checking literal pointer bit 55
against ttbr1_valid now ?
thanks
-- PMM
Re: [PATCH v9 22/23] fuzz: add virtio-scsi fuzz target
On Tue, Feb 11, 2020 at 03:35:09PM -0500, Alexander Bulekov wrote:
> diff --git a/tests/qtest/fuzz/virtio_scsi_fuzz.c
> b/tests/qtest/fuzz/virtio_scsi_fuzz.c
> new file mode 100644
> index 00..f62f512a26
> --- /dev/null
> +++ b/tests/qtest/fuzz/virtio_scsi_fuzz.c
> @@ -0,0 +1,214 @@
> +/*
> + * virtio-serial Fuzzing Target
> + *
> + * Copyright Red Hat Inc., 2019
> + *
> + * Authors:
> + * Alexander Bulekov
> + *
> + * This work is licensed under the terms of the GNU GPL, version 2 or later.
> + * See the COPYING file in the top-level directory.
> + */
> +
> +#include "qemu/osdep.h"
> +
> +#include "tests/qtest/libqtest.h"
> +#include "tests/qtest/libqos/virtio-net.h"
virtio-net?
> +static void register_virtio_scsi_fuzz_targets(void)
> +{
> +fuzz_add_qos_target(&(FuzzTarget){
> +.name = "virtio-scsi-fuzz",
> +.description = "Fuzz the virtio-net virtual queues, forking"
s/net/scsi/
> +"for each fuzz run",
> +.pre_vm_init = _shm_init,
> +.pre_fuzz = _scsi_pre_fuzz,
> +.fuzz = virtio_scsi_fork_fuzz,},
> +"virtio-scsi",
> +&(QOSGraphTestOptions){.before = virtio_scsi_test_setup}
> +);
> +
> +fuzz_add_qos_target(&(FuzzTarget){
> +.name = "virtio-scsi-flags-fuzz",
> +.description = "Fuzz the virtio-net virtual queues, forking"
s/net/scsi/
signature.asc
Description: PGP signature
Re: [PATCH] block: make BlockConf.*_size properties 32-bit
On Thu, Feb 13, 2020 at 06:47:10AM -0600, Eric Blake wrote:
> On 2/13/20 2:01 AM, Roman Kagan wrote:
> > On Wed, Feb 12, 2020 at 03:44:19PM -0600, Eric Blake wrote:
> > > On 2/11/20 5:54 AM, Roman Kagan wrote:
> > > > Devices (virtio-blk, scsi, etc.) and the block layer are happy to use
> > > > 32-bit for logical_block_size, physical_block_size, and min_io_size.
> > > > However, the properties in BlockConf are defined as uint16_t limiting
> > > > the values to 32768.
> > > >
> > > > This appears unnecessary tight, and we've seen bigger block sizes handy
> > > > at times.
> > >
> > > What larger sizes? I could see 64k or maybe even 1M block sizes,...
> >
> > We played exactly with these two :)
> >
> > > >
> > > > Make them 32 bit instead and lift the limitation.
> > > >
> > > > Signed-off-by: Roman Kagan
> > > > ---
> > > >hw/core/qdev-properties.c| 21 -
> > > >include/hw/block/block.h | 8
> > > >include/hw/qdev-properties.h | 2 +-
> > > >3 files changed, 17 insertions(+), 14 deletions(-)
> > > >
> > > > diff --git a/hw/core/qdev-properties.c b/hw/core/qdev-properties.c
> > > > index 7f93bfeb88..5f84e4a3b8 100644
> > > > --- a/hw/core/qdev-properties.c
> > > > +++ b/hw/core/qdev-properties.c
> > > > @@ -716,30 +716,32 @@ const PropertyInfo qdev_prop_pci_devfn = {
> > > >/* --- blocksize --- */
> > > > +#define MIN_BLOCK_SIZE 512
> > > > +#define MAX_BLOCK_SIZE 2147483648
> > >
> > > ...but 2G block sizes are going to have tremendous performance problems.
> > >
> > > I'm not necessarily opposed to the widening to a 32-bit type, but think
> > > you
> > > need more justification or a smaller number for the max block size,
> >
> > I thought any smaller value would just be arbitrary and hard to reason
> > about, so I went ahead with the max value that fit in the type and could
> > be made visibile to the guest.
>
> You've got bigger problems than what is visible to the guest. block/qcow2.c
> operates on a cluster at a time; if you are stating that it now requires
> reading multiple clusters to operate on one, qcow2 will have to do lots of
> wasteful read-modify-write cycles.
I'm failing to see how this is supposed to happen. The guest will issue
requests bigger than the cluster size; why would it cause RMW?
Big logical_block_size would cause RMW in the guest if it wants to
perform smaller writes, but that's up to the user to take this tradeoff,
isn't it?
> You really need a strong reason to
> support a maximum larger than 2M other than just "so the guest can
> experiment with it".
Do I get you right that your suggestion is to cap the block size
property at 2MB?
Thanks,
Roman.
> >
> > Besides this is a property that is set explicitly, so I don't see a
> > problem leaving this up to the user.
> >
> > > particularly since qcow2 refuses to use cluster sizes larger than 2M and
> > > it
> > > makes no sense to allow a block size larger than a cluster size.
> >
> > This still doesn't contradict passing a bigger value to the guest, for
> > experimenting if nothing else.
> >
> > Thanks,
> > Roman.
> >
>
> --
> Eric Blake, Principal Software Engineer
> Red Hat, Inc. +1-919-301-3226
> Virtualization: qemu.org | libvirt.org
>
Re: [PATCH v3 12/13] hw/arm/raspi: Use a unique raspi_machine_class_init() method
On Sat, 8 Feb 2020 at 16:57, Philippe Mathieu-Daudé wrote:
>
> With the exception of the ignore_memory_transaction_failures
> flag set for the raspi2, both machine_class_init() methods
> are now identical. Merge them to keep a unique method.
>
> Signed-off-by: Philippe Mathieu-Daudé
> ---
> hw/arm/raspi.c | 31 ++-
> 1 file changed, 6 insertions(+), 25 deletions(-)
>
> diff --git a/hw/arm/raspi.c b/hw/arm/raspi.c
> index 0537fc0a2d..bee6ca0a08 100644
> --- a/hw/arm/raspi.c
> +++ b/hw/arm/raspi.c
> @@ -294,7 +294,7 @@ static void raspi_machine_init(MachineState *machine)
> setup_boot(machine, version, machine->ram_size - vcram_size);
> }
>
> -static void raspi2_machine_class_init(ObjectClass *oc, void *data)
> +static void raspi_machine_class_init(ObjectClass *oc, void *data)
> {
> MachineClass *mc = MACHINE_CLASS(oc);
> RaspiMachineClass *rmc = RASPI_MACHINE_CLASS(oc);
> @@ -311,41 +311,22 @@ static void raspi2_machine_class_init(ObjectClass *oc,
> void *data)
> mc->min_cpus = BCM283X_NCPUS;
> mc->default_cpus = BCM283X_NCPUS;
> mc->default_ram_size = board_ram_size(board_rev);
> -mc->ignore_memory_transaction_failures = true;
> +if (board_version(board_rev) == 2) {
> +mc->ignore_memory_transaction_failures = true;
> +}
> };
This isn't really the correct condition here. What we want is:
* for the board named 'raspi2' which was introduced before
we added the transaction-failure support to Arm CPU emulation,
disable signaling transaction failures
* for any other board, leave it enabled (whether that new
board is BCM2836 based or anything else)
(This kind of follows on from my remark on patch 3: we should
be suspicious of anything that's conditional on board_version();
it should probably be testing something else.)
The natural way to implement this is to have the .class_data
be a pointer to a struct which is in an array and defines
relevant per-class stuff, the same way we do in
bcm2836_register_types(). That way the struct can indicate
both the board revision number and also "is this a legacy
board that needs transaction-failures disabled?".
The other approach here, as discussed on IRC, is that if
we're confident we really have all the devices in the SoC
either present or stubbed out with unimplemented-device
then we could disable ignore_memory_transaction_failures
for raspi2. (The flag is only there because I didn't want
to try to do the auditing and fielding of potential bug
reports if I changed the behaviour of a bunch of our
existing not-very-maintained board models: the real
correct behaviour in almost all cases would be to allow
transaction failures and just make sure we have stub devices
as needed.)
That said, this does give the right answer for our current boards,
so I'm ok with taking this series if you want to address this
in a followup patch.
thanks
-- PMM
Re: [PATCH v5 7/8] multifd: Add multifd-zstd-level parameter
"Dr. David Alan Gilbert" writes: > * Juan Quintela (quint...@redhat.com) wrote: >> Signed-off-by: Juan Quintela >> --- >> migration/migration.c | 15 +++ >> monitor/hmp-cmds.c| 4 >> qapi/migration.json | 29 ++--- >> 3 files changed, 45 insertions(+), 3 deletions(-) >> >> diff --git a/migration/migration.c b/migration/migration.c >> index 3b081e8147..b690500545 100644 >> --- a/migration/migration.c >> +++ b/migration/migration.c >> @@ -91,6 +91,8 @@ >> #define DEFAULT_MIGRATE_MULTIFD_METHOD MULTIFD_METHOD_NONE >> /*0: means nocompress, 1: best speed, ... 9: best compress ratio */ >> #define DEFAULT_MIGRATE_MULTIFD_ZLIB_LEVEL 1 >> +/* 0: means nocompress, 1: best speed, ... 20: best compress ratio */ >> +#define DEFAULT_MIGRATE_MULTIFD_ZSTD_LEVEL 1 >> >> /* Background transfer rate for postcopy, 0 means unlimited, note >> * that page requests can still exceed this limit. >> @@ -805,6 +807,8 @@ MigrationParameters *qmp_query_migrate_parameters(Error >> **errp) >> params->multifd_method = s->parameters.multifd_method; >> params->has_multifd_zlib_level = true; >> params->multifd_zlib_level = s->parameters.multifd_zlib_level; >> +params->has_multifd_zstd_level = true; >> +params->multifd_zstd_level = s->parameters.multifd_zstd_level; > > Do we really want different 'multifd__level's or just one > 'multifd_compress_level' - or even just reuse the existing > 'compress-level' parameter. compress-level, multifd-zlib-level, and multifd-zstd-level apply "normal" live migration compression, multifd zlib live migration compression, and multifd zstd live migration compression, respectively. Any live migration can only use one of the three compressions. Correct? > The only tricky thing about combining them is how to handle > the difference in allowed ranges; When would the right time be > to check it? > > Markus/Eric: Any idea? To have an informed opinion, I'd have to dig through the migration code. Documentation of admissible range will become a bit awkward, too. Too many migration parameters...
Re: [PATCH v3 12/13] hw/arm/raspi: Use a unique raspi_machine_class_init() method
On 2/13/20 2:59 PM, Peter Maydell wrote:
On Sat, 8 Feb 2020 at 16:57, Philippe Mathieu-Daudé wrote:
With the exception of the ignore_memory_transaction_failures
flag set for the raspi2, both machine_class_init() methods
are now identical. Merge them to keep a unique method.
Signed-off-by: Philippe Mathieu-Daudé
---
hw/arm/raspi.c | 31 ++-
1 file changed, 6 insertions(+), 25 deletions(-)
diff --git a/hw/arm/raspi.c b/hw/arm/raspi.c
index 0537fc0a2d..bee6ca0a08 100644
--- a/hw/arm/raspi.c
+++ b/hw/arm/raspi.c
@@ -294,7 +294,7 @@ static void raspi_machine_init(MachineState *machine)
setup_boot(machine, version, machine->ram_size - vcram_size);
}
-static void raspi2_machine_class_init(ObjectClass *oc, void *data)
+static void raspi_machine_class_init(ObjectClass *oc, void *data)
{
MachineClass *mc = MACHINE_CLASS(oc);
RaspiMachineClass *rmc = RASPI_MACHINE_CLASS(oc);
@@ -311,41 +311,22 @@ static void raspi2_machine_class_init(ObjectClass *oc,
void *data)
mc->min_cpus = BCM283X_NCPUS;
mc->default_cpus = BCM283X_NCPUS;
mc->default_ram_size = board_ram_size(board_rev);
-mc->ignore_memory_transaction_failures = true;
+if (board_version(board_rev) == 2) {
+mc->ignore_memory_transaction_failures = true;
+}
};
This isn't really the correct condition here. What we want is:
* for the board named 'raspi2' which was introduced before
we added the transaction-failure support to Arm CPU emulation,
disable signaling transaction failures
* for any other board, leave it enabled (whether that new
board is BCM2836 based or anything else)
(This kind of follows on from my remark on patch 3: we should
be suspicious of anything that's conditional on board_version();
it should probably be testing something else.)
The natural way to implement this is to have the .class_data
be a pointer to a struct which is in an array and defines
relevant per-class stuff, the same way we do in
bcm2836_register_types(). That way the struct can indicate
both the board revision number and also "is this a legacy
board that needs transaction-failures disabled?".
IIUC Igor insists explaining that he doesn't accept anymore a
".class_data pointer to a struct which is in an array and defines
relevant per-class stuff" and we should not use this pattern anymore.
The other approach here, as discussed on IRC, is that if
we're confident we really have all the devices in the SoC
either present or stubbed out with unimplemented-device
then we could disable ignore_memory_transaction_failures
for raspi2. (The flag is only there because I didn't want
to try to do the auditing and fielding of potential bug
reports if I changed the behaviour of a bunch of our
existing not-very-maintained board models: the real
correct behaviour in almost all cases would be to allow
transaction failures and just make sure we have stub devices
as needed.)
Yes, the plan is to add all the unimplemented peripherals (patches
ready, but out of scope of this series) and remove this flag.
That said, this does give the right answer for our current boards,
so I'm ok with taking this series if you want to address this
in a followup patch.
If you are OK, I prefer to address this in a later series than delaying
this one more longer.
Thanks!
Re: [PATCH v3 12/13] hw/arm/raspi: Use a unique raspi_machine_class_init() method
On Thu, 13 Feb 2020 at 14:16, Philippe Mathieu-Daudé wrote: > On 2/13/20 2:59 PM, Peter Maydell wrote: > > The natural way to implement this is to have the .class_data > > be a pointer to a struct which is in an array and defines > > relevant per-class stuff, the same way we do in > > bcm2836_register_types(). That way the struct can indicate > > both the board revision number and also "is this a legacy > > board that needs transaction-failures disabled?". > > IIUC Igor insists explaining that he doesn't accept anymore a > ".class_data pointer to a struct which is in an array and defines > relevant per-class stuff" and we should not use this pattern anymore. Huh? How else would you do this? I'm kinda dubious about the pattern this patch series uses of just stuffing a 32-bit board ID number into the class_data field, to be honest -- I let that pass partly not to hold up the series but partly because I expect that we'll need to turn it back into a proper pointer to a data struct soonish. thnaks -- PMM
Re: [PATCH RFC 03/14] migration/rdma: Create multiFd migration threads
Zhimin Feng wrote:
> Creation of the multifd send threads for RDMA migration,
> nothing inside yet.
>
> Signed-off-by: Zhimin Feng
> ---
> migration/multifd.c | 33 +---
> migration/multifd.h | 2 +
> migration/qemu-file.c | 5 +++
> migration/qemu-file.h | 1 +
> migration/rdma.c | 88 ++-
> migration/rdma.h | 3 ++
> 6 files changed, 125 insertions(+), 7 deletions(-)
>
> diff --git a/migration/multifd.c b/migration/multifd.c
> index b3e8ae9bcc..63678d7fdd 100644
> --- a/migration/multifd.c
> +++ b/migration/multifd.c
> @@ -424,7 +424,7 @@ void multifd_send_sync_main(QEMUFile *f)
> {
> int i;
>
> -if (!migrate_use_multifd()) {
> +if (!migrate_use_multifd() || migrate_use_rdma()) {
You don't need sync with main channel on rdma?
> +static void rdma_send_channel_create(MultiFDSendParams *p)
> +{
> +Error *local_err = NULL;
> +
> +if (p->quit) {
> +error_setg(_err, "multifd: send id %d already quit", p->id);
> +return ;
> +}
> +p->running = true;
> +
> +qemu_thread_create(>thread, p->name, multifd_rdma_send_thread, p,
> + QEMU_THREAD_JOINABLE);
> +}
> +
> static void multifd_new_send_channel_async(QIOTask *task, gpointer opaque)
> {
> MultiFDSendParams *p = opaque;
> @@ -621,7 +635,11 @@ int multifd_save_setup(Error **errp)
> p->packet->magic = cpu_to_be32(MULTIFD_MAGIC);
> p->packet->version = cpu_to_be32(MULTIFD_VERSION);
> p->name = g_strdup_printf("multifdsend_%d", i);
> -socket_send_channel_create(multifd_new_send_channel_async, p);
> +if (!migrate_use_rdma()) {
> +socket_send_channel_create(multifd_new_send_channel_async, p);
> +} else {
> +rdma_send_channel_create(p);
> +}
This is what we are trying to avoid. Just create a struct ops, where we
have a
ops->create_channel(new_channel_async, p)
or whatever, and fill it differently for rdma and for tcp.
> }
> return 0;
> }
> @@ -720,7 +738,7 @@ void multifd_recv_sync_main(void)
> {
> int i;
>
> -if (!migrate_use_multifd()) {
> +if (!migrate_use_multifd() || migrate_use_rdma()) {
> return;
> }
Ok. you can just put an empty function for you here.
> for (i = 0; i < migrate_multifd_channels(); i++) {
> @@ -890,8 +908,13 @@ bool multifd_recv_new_channel(QIOChannel *ioc, Error
> **errp)
> p->num_packets = 1;
>
> p->running = true;
> -qemu_thread_create(>thread, p->name, multifd_recv_thread, p,
> - QEMU_THREAD_JOINABLE);
> +if (!migrate_use_rdma()) {
> +qemu_thread_create(>thread, p->name, multifd_recv_thread, p,
> + QEMU_THREAD_JOINABLE);
> +} else {
> +qemu_thread_create(>thread, p->name, multifd_rdma_recv_thread, p,
> + QEMU_THREAD_JOINABLE);
> +}
new_recv_chanel() member function.
> atomic_inc(_recv_state->count);
> return atomic_read(_recv_state->count) ==
> migrate_multifd_channels();
> diff --git a/migration/multifd.h b/migration/multifd.h
> index d8b0205977..c9c11ad140 100644
> --- a/migration/multifd.h
> +++ b/migration/multifd.h
> @@ -13,6 +13,8 @@
> #ifndef QEMU_MIGRATION_MULTIFD_H
> #define QEMU_MIGRATION_MULTIFD_H
>
> +#include "migration/rdma.h"
> +
> int multifd_save_setup(Error **errp);
> void multifd_save_cleanup(void);
> int multifd_load_setup(Error **errp);
You are not exporting anything rdma related from here, are you?
> diff --git a/migration/qemu-file.c b/migration/qemu-file.c
> index 1c3a358a14..f0ed8f1381 100644
> --- a/migration/qemu-file.c
> +++ b/migration/qemu-file.c
> @@ -248,6 +248,11 @@ void qemu_fflush(QEMUFile *f)
> f->iovcnt = 0;
> }
>
> +void *getQIOChannel(QEMUFile *f)
> +{
> +return f->opaque;
> +}
> +
We really want this to return a void? and not a better type?
> +static void migration_rdma_process_incoming(QEMUFile *f, Error **errp)
> +{
> +MigrationIncomingState *mis = migration_incoming_get_current();
> +Error *local_err = NULL;
> +QIOChannel *ioc = NULL;
> +bool start_migration;
> +
> +if (!mis->from_src_file) {
> +mis->from_src_file = f;
> +qemu_file_set_blocking(f, false);
> +
> +start_migration = migrate_use_multifd();
> +} else {
> +ioc = QIO_CHANNEL(getQIOChannel(f));
> +/* Multiple connections */
> +assert(migrate_use_multifd());
I am not sure that you can make this incompatible change.
You need to have *both*, old method and new multifd one.
I would have been happy to remove old precopy tcp method, but we
*assure* backwards compatibility.
> @@ -4003,8 +4032,12 @@ static void rdma_accept_incoming_migration(void
> *opaque)
> return;
> }
>
> -rdma->migration_started_on_destination = 1;
> -migration_fd_process_incoming(f, errp);
> +if (migrate_use_multifd()) {
> +
Re: [PATCH v2] virtio: increase virtuqueue size for virtio-scsi and virtio-blk
On Thu, Feb 13, 2020 at 12:28:25PM +0300, Denis Plotnikov wrote: > > > On 13.02.2020 12:08, Stefan Hajnoczi wrote: > > On Thu, Feb 13, 2020 at 11:08:35AM +0300, Denis Plotnikov wrote: > > > On 12.02.2020 18:43, Stefan Hajnoczi wrote: > > > > On Tue, Feb 11, 2020 at 05:14:14PM +0300, Denis Plotnikov wrote: > > > > > The goal is to reduce the amount of requests issued by a guest on > > > > > 1M reads/writes. This rises the performance up to 4% on that kind of > > > > > disk access pattern. > > > > > > > > > > The maximum chunk size to be used for the guest disk accessing is > > > > > limited with seg_max parameter, which represents the max amount of > > > > > pices in the scatter-geather list in one guest disk request. > > > > > > > > > > Since seg_max is virqueue_size dependent, increasing the virtqueue > > > > > size increases seg_max, which, in turn, increases the maximum size > > > > > of data to be read/write from a guest disk. > > > > > > > > > > More details in the original problem statment: > > > > > https://lists.gnu.org/archive/html/qemu-devel/2017-12/msg03721.html > > > > > > > > > > Suggested-by: Denis V. Lunev > > > > > Signed-off-by: Denis Plotnikov > > > > > --- > > > > >hw/block/virtio-blk.c | 4 ++-- > > > > >hw/core/machine.c | 2 ++ > > > > >hw/scsi/virtio-scsi.c | 4 ++-- > > > > >3 files changed, 6 insertions(+), 4 deletions(-) > > > > > > > > > > diff --git a/hw/block/virtio-blk.c b/hw/block/virtio-blk.c > > > > > index 09f46ed85f..6df3a7a6df 100644 > > > > > --- a/hw/block/virtio-blk.c > > > > > +++ b/hw/block/virtio-blk.c > > > > > @@ -914,7 +914,7 @@ static void virtio_blk_update_config(VirtIODevice > > > > > *vdev, uint8_t *config) > > > > >memset(, 0, sizeof(blkcfg)); > > > > >virtio_stq_p(vdev, , capacity); > > > > >virtio_stl_p(vdev, _max, > > > > > - s->conf.seg_max_adjust ? s->conf.queue_size - 2 : > > > > > 128 - 2); > > > > > + s->conf.seg_max_adjust ? s->conf.queue_size - 2 : > > > > > 256 - 2); > > > > This value must not change on older machine types. > > > Yes, that's true, but .. > > > > So does this patch > > > > need to turn seg-max-adjust *on* in hw_compat_4_2 so that old machine > > > > types get 126 instead of 254? > > > If we set seg-max-adjust "on" in older machine types, the setups using > > > them > > > and having queue_sizes set , for example, 1024 will also set seg_max to > > > 1024 > > > - 2 which isn't the expected behavior: older mt didn't change seg_max in > > > that case and stuck with 128 - 2. > > > So, should we, instead, leave the default 128 - 2, for seg_max? > > Argh! Good point :-). > > > > How about a seg_max_default property that is initialized to 254 for > > modern machines and 126 to old machines? > Hmm, but we'll achieve the same but with more code changes, don't we? > 254 is because the queue-size is 256. We gonna leave 128-2 for older machine > types > just for not breaking anything. All other seg_max adjustment is provided by > seg_max_adjust which is "on" by default in modern machine types. > > to summarize: > > modern mt defaults: > seg_max_adjust = on > queue_size = 256 > > => default seg_max = 254 > => changing queue-size will change seg_max = queue_size - 2 > > old mt defaults: > seg_max_adjust = off > queue_size = 128 > > => default seg_max = 126 > => changing queue-size won't change seg_max, it's always = 126 like it was > before You're right! The only strange case is a modern machine type with seg_max_adjust=off, where queue_size will be 256 but seg_max will be 126. But no user would want to disable seg_max_adjust, so it's okay. I agree with you that the line of code can remain unchanged: /* * Only old machine types use seg_max_adjust=off and there the default * value of queue_size is 128. */ virtio_stl_p(vdev, _max, s->conf.seg_max_adjust ? s->conf.queue_size - 2 : 128 - 2); Stefan signature.asc Description: PGP signature
Re: [PATCH] block: make BlockConf.*_size properties 32-bit
On 2/13/20 2:01 AM, Roman Kagan wrote:
On Wed, Feb 12, 2020 at 03:44:19PM -0600, Eric Blake wrote:
On 2/11/20 5:54 AM, Roman Kagan wrote:
Devices (virtio-blk, scsi, etc.) and the block layer are happy to use
32-bit for logical_block_size, physical_block_size, and min_io_size.
However, the properties in BlockConf are defined as uint16_t limiting
the values to 32768.
This appears unnecessary tight, and we've seen bigger block sizes handy
at times.
What larger sizes? I could see 64k or maybe even 1M block sizes,...
We played exactly with these two :)
Make them 32 bit instead and lift the limitation.
Signed-off-by: Roman Kagan
---
hw/core/qdev-properties.c| 21 -
include/hw/block/block.h | 8
include/hw/qdev-properties.h | 2 +-
3 files changed, 17 insertions(+), 14 deletions(-)
diff --git a/hw/core/qdev-properties.c b/hw/core/qdev-properties.c
index 7f93bfeb88..5f84e4a3b8 100644
--- a/hw/core/qdev-properties.c
+++ b/hw/core/qdev-properties.c
@@ -716,30 +716,32 @@ const PropertyInfo qdev_prop_pci_devfn = {
/* --- blocksize --- */
+#define MIN_BLOCK_SIZE 512
+#define MAX_BLOCK_SIZE 2147483648
...but 2G block sizes are going to have tremendous performance problems.
I'm not necessarily opposed to the widening to a 32-bit type, but think you
need more justification or a smaller number for the max block size,
I thought any smaller value would just be arbitrary and hard to reason
about, so I went ahead with the max value that fit in the type and could
be made visibile to the guest.
You've got bigger problems than what is visible to the guest.
block/qcow2.c operates on a cluster at a time; if you are stating that
it now requires reading multiple clusters to operate on one, qcow2 will
have to do lots of wasteful read-modify-write cycles. You really need a
strong reason to support a maximum larger than 2M other than just "so
the guest can experiment with it".
Besides this is a property that is set explicitly, so I don't see a
problem leaving this up to the user.
particularly since qcow2 refuses to use cluster sizes larger than 2M and it
makes no sense to allow a block size larger than a cluster size.
This still doesn't contradict passing a bigger value to the guest, for
experimenting if nothing else.
Thanks,
Roman.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3226
Virtualization: qemu.org | libvirt.org
Re: [PATCH v2 2/2] target/arm: Split out aa64_va_parameter_tbi, aa64_va_parameter_tbid
On Tue, 11 Feb 2020 at 19:42, Richard Henderson wrote: > > For the purpose of rebuild_hflags_a64, we do not need to compute > all of the va parameters, only tbi. Moreover, we can compute them > in a form that is more useful to storing in hflags. > > This eliminates the need for aa64_va_parameter_both, so fold that > in to aa64_va_parameter. The remaining calls to aa64_va_parameter > are in get_phys_addr_lpae and in pauth_helper.c. > > This reduces the total cpu consumption of aa64_va_parameter in a > kernel boot plus a kvm guest kernel boot from 3% to 0.5%. > > Signed-off-by: Richard Henderson Reviewed-by: Peter Maydell thanks -- PMM
Re: [PATCH] console: make QMP screendump use coroutine
Gerd Hoffmann writes: > Hi, > >> Thanks to the QMP coroutine support, the screendump handler can >> trigger a graphic_hw_update(), yield and let the main loop run until >> update is done. Then the handler is resumed, and the ppm_save() will >> write the screen image to disk in the coroutine context (thus >> non-blocking). >> >> For now, HMP doesn't have coroutine support, so it remains potentially >> outdated or glitched. >> >> Fixes: >> https://bugzilla.redhat.com/show_bug.cgi?id=1230527 >> >> Based-on: <20200109183545.27452-2-kw...@redhat.com> > > What is the status here? Tried to apply (worked) and build (failed), > seems Kevins patches are not merged yet? I reviewed v3, Kevin worked in improvements promptly, and I failed to review v4 promptly. Sorry about that.
Re: [PATCH/RFC 0/1] Vhost User Cross Cable: Intro
On Tue, 14 Jan 2020 at 10:20 Stefan Hajnoczi wrote: > On Fri, Jan 10, 2020 at 10:34 AM Marc-André Lureau > wrote: > > On Wed, Jan 8, 2020 at 5:57 AM V. wrote: > > Hi V., > I think I remember you from Etherboot/gPXE days :). > > > > 3. > > > Now if Cross Cable is actually a new and (after a code-rewrite of 10) a > > > viable way to connect 2 QEMU's together, could I actually > > > suggest a better way? > > > I am thinking of a '-netdev vhost-user-slave' option to connect (as client > > > or server) to a master QEMU running '-netdev vhost-user'. > > > This way there is no need for any external program at all, the master can > > > have it's memory unshared and everything would just work > > > and be fast. > > > Also the whole thing can fall back to normal virtio if memory is not shared > > > and it would even work in pure usermode without any > > > context switch. > > > > > > Building a patch for this idea I could maybe get around to, don't clearly > > > have an idea how much work this would be but I've done > > > crazier things. > > > But is this is something that someone might be able to whip up in an hour > > > or two? Someone who actually does have a clue about vhost > > > and virtio maybe? ;-) > > > > I believe https://wiki.qemu.org/Features/VirtioVhostUser is what you > > are after. It's still being discussed and non-trivial, but not very > > active lately afaik. > > virtio-vhost-user is being experimented with in the SPDK community but > there has been no activity on VIRTIO standardization or the QEMU > patches for some time. More info here: > https://ndragazis.github.io/spdk.html > > I think the new ivshmem v2 feature may provide the functionality you > are looking for, but I haven't looked at them yet. Here is the link: > https://www.mail-archive.com/address@hidden/msg668749.html > > And here is Jan's KVM Forum presentation on ivshmem v2: > https://www.youtube.com/watch?v=TiZrngLUFMA > > Stefan Hi Stefan, First of all, sorry for the delayed response. The mail got lost somewhere in my inbox. Please keep Cc-ing me on all threads related to virtio-vhost-user. As you correctly pointed out, I have been experimenting with virtio-vhost-user on SPDK and [1] is a working demo on this matter. I have been working on getting it merged with SPDK and, to this end, I have been interacting with the SPDK team [2][3] and mostly with Darek Stojaczyk (Cc-ing him). The reason that you haven’t seen any activity for the last months is that I got a job and hence my schedule has become tighter. But I will definitely find some space and fit it into my schedule. Let me give you a heads up, so that we get synced: Originally, I created and sent a patch (influenced from your DPDK patch [4]) to SPDK that was enhancing SPDK’s internal rte_vhost library with the virtio-vhost-user transport. However, a few weeks later, the SPDK team decided to switch from their internal rte_vhost library to using DPDK’s rte_vhost library directly [3]. Given that, I refactored and sent the patch for the virtio-vhost-user transport to the DPDK mailing list [5]. Regarding the virtio-vhost-user device, I have made some enhancements [6] on your original RFC device implementation and, as you may remember, I have sent some revised versions of the spec to the virtio mailing list [7]. At the moment, the blocker is the virtio spec. The last update on this was my discussion with Michael Tsirkin (Cc-ing him as well) about the need for the VIRTIO_PCI_CAP_DOORBELL_CFG and VIRTIO_PCI_CAP_NOTIFICATION_CFG configuration structures [8]. So, I think the next steps should be the following: 1. merging the spec 2. adding the device on QEMU 3. adding the vvu transport on DPDK 4. extending SPDK to make use of the new vhost-user transport To conclude, I still believe that this device is useful and should be part of virtio/qemu/dpdk/spdk and I will continue working on this direction. Best regards, Nikos [1] https://ndragazis.github.io/spdk.html [2] https://lists.01.org/hyperkitty/list/s...@lists.01.org/thread/UR4FM45LEQIBJNQ4MTDZFH6SLTXHTGDR/#ZGPRKS47QWHXHFBEKSCA7Z66E2AGSLHN [3] https://lists.01.org/hyperkitty/list/s...@lists.01.org/thread/WLUREJGPK5UJVTHIQ5GRL3CDWR5NN5BI/#G7P3D4KF6OQDI2RYASXQOZCMITKT5DEP [4] http://mails.dpdk.org/archives/dev/2018-January/088155.html [5] https://lore.kernel.org/dpdk-dev/e03dcc29-d472-340a-9825-48d13e472...@redhat.com/T/ [6] https://lists.gnu.org/archive/html/qemu-devel/2019-04/msg02910.html [7] https://lists.oasis-open.org/archives/virtio-dev/201906/msg00036.html [8] https://lists.oasis-open.org/archives/virtio-dev/201908/msg00014.html
Re: [RFC v3 14/25] intel_iommu: add virtual command capability support
On Thu, Feb 13, 2020 at 02:40:45AM +, Liu, Yi L wrote: > > From: Peter Xu > > Sent: Wednesday, February 12, 2020 5:57 AM > > To: Liu, Yi L > > Subject: Re: [RFC v3 14/25] intel_iommu: add virtual command capability > > support > > > > On Wed, Jan 29, 2020 at 04:16:45AM -0800, Liu, Yi L wrote: > > > +/* > > > + * The basic idea is to let hypervisor to set a range for available > > > + * PASIDs for VMs. One of the reasons is PASID #0 is reserved by > > > + * RID_PASID usage. We have no idea how many reserved PASIDs in future, > > > + * so here just an evaluated value. Honestly, set it as "1" is enough > > > + * at current stage. > > > + */ > > > +#define VTD_MIN_HPASID 1 > > > +#define VTD_MAX_HPASID 0xF > > > > One more question: I see that PASID is defined as 20bits long. It's > > fine. However I start to get confused on how the Scalable Mode PASID > > Directory could service that much of PASID entries. > > > > I'm looking at spec 3.4.3, Figure 3-8. > > > > Firstly, we only have two levels for a PASID table. The context entry > > of a device stores a pointer to the "Scalable Mode PASID Directory" > > page. I see that there're 2^14 entries in "Scalable Mode PASID > > Directory" page, each is a "Scalable Mode PASID Table". > > However... how do we fit in the 4K page if each entry is a pointer of > > x86_64 (8 bytes) while there're 2^14 entries? A simple math gives me > > 4K/8 = 512, which means the "Scalable Mode PASID Directory" page can > > only have 512 entries, then how the 2^14 come from? Hmm?? > > I checked with Kevin. The spec doesn't say the dir table is 4K. It says 4K > only for pasid table. Also, if you look at 9.4, scalabe-mode context entry > includes a PDTS field to specify the actual size of the directory table. Ah I see. Then it seems to be lost then in this series. Say, I think vtd_sm_pasid_table_walk() should also stop walking until reaching the size there, and you need to fetch that size info from the context entry before walk starts. > > > Apart of this: also I just noticed (when reading the latter part of > > the series) that the time that a pasid table walk can consume will > > depend on this value too. I'd suggest to make this as small as we > > can, as long as it satisfies the usage. We can even bump it in the > > future. > > I see. This looks to be an optimization. right? Instead of modify the > value of this macro, I think we can do this optimization by tracking > the allocated PASIDs in QEMU. Thus, the pasid table walk would be more > efficient and also no dependency on the VTD_MAX_HPASID. Does it make > sense to you? :-) Yeah sounds good. :) Thanks, -- Peter Xu
Re: [PATCH RFC 00/14] *** multifd for RDMA v2 ***
Patchew URL: https://patchew.org/QEMU/20200213093755.370-1-fengzhim...@huawei.com/ Hi, This series failed the docker-mingw@fedora build test. Please find the testing commands and their output below. If you have Docker installed, you can probably reproduce it locally. === TEST SCRIPT BEGIN === #! /bin/bash export ARCH=x86_64 make docker-image-fedora V=1 NETWORK=1 time make docker-test-mingw@fedora J=14 NETWORK=1 === TEST SCRIPT END === /tmp/qemu-test/src/migration/multifd.c:663: undefined reference to `multifd_channel_rdma_connect' ../migration/multifd.o: In function `multifd_load_cleanup': /tmp/qemu-test/src/migration/multifd.c:843: undefined reference to `qemu_rdma_cleanup' collect2: error: ld returned 1 exit status make[1]: *** [Makefile:206: qemu-system-x86_64w.exe] Error 1 make: *** [Makefile:497: x86_64-softmmu/all] Error 2 make: *** Waiting for unfinished jobs ../migration/multifd.o: In function `multifd_rdma_recv_thread': /tmp/qemu-test/src/migration/multifd.c:898: undefined reference to `qemu_rdma_registration_handle' --- /tmp/qemu-test/src/migration/multifd.c:663: undefined reference to `multifd_channel_rdma_connect' ../migration/multifd.o: In function `multifd_load_cleanup': /tmp/qemu-test/src/migration/multifd.c:843: undefined reference to `qemu_rdma_cleanup' collect2: error: ld returned 1 exit status make[1]: *** [Makefile:206: qemu-system-aarch64w.exe] Error 1 make: *** [Makefile:497: aarch64-softmmu/all] Error 2 Traceback (most recent call last): File "./tests/docker/docker.py", line 664, in sys.exit(main()) --- raise CalledProcessError(retcode, cmd) subprocess.CalledProcessError: Command '['sudo', '-n', 'docker', 'run', '--label', 'com.qemu.instance.uuid=88473d634d6543ea992045cbe9a806e1', '-u', '1003', '--security-opt', 'seccomp=unconfined', '--rm', '-e', 'TARGET_LIST=', '-e', 'EXTRA_CONFIGURE_OPTS=', '-e', 'V=', '-e', 'J=14', '-e', 'DEBUG=', '-e', 'SHOW_ENV=', '-e', 'CCACHE_DIR=/var/tmp/ccache', '-v', '/home/patchew2/.cache/qemu-docker-ccache:/var/tmp/ccache:z', '-v', '/var/tmp/patchew-tester-tmp-yiq7aevf/src/docker-src.2020-02-13-05.11.35.1374:/var/tmp/qemu:z,ro', 'qemu:fedora', '/var/tmp/qemu/run', 'test-mingw']' returned non-zero exit status 2. filter=--filter=label=com.qemu.instance.uuid=88473d634d6543ea992045cbe9a806e1 make[1]: *** [docker-run] Error 1 make[1]: Leaving directory `/var/tmp/patchew-tester-tmp-yiq7aevf/src' make: *** [docker-run-test-mingw@fedora] Error 2 real2m35.791s user0m7.717s The full log is available at http://patchew.org/logs/20200213093755.370-1-fengzhim...@huawei.com/testing.docker-mingw@fedora/?type=message. --- Email generated automatically by Patchew [https://patchew.org/]. Please send your feedback to patchew-de...@redhat.com
Re: [PATCH 2/2] util: add util function buffer_zero_avx512()
On 13/02/20 08:52, Robert Hoo wrote:
> +
> +}
> +#pragma GCC pop_options
> +#endif
> +
> +
> /* Note that for test_buffer_is_zero_next_accel, the most preferred
> * ISA must have the least significant bit.
> */
> -#define CACHE_AVX21
> -#define CACHE_SSE42
> -#define CACHE_SSE24
> +#define CACHE_AVX512F 1
> +#define CACHE_AVX22
> +#define CACHE_SSE44
> +#define CACHE_SSE26
This should be 8, not 6.
Paolo
>
> /* Make sure that these variables are appropriately initialized when
> * SSE2 is enabled on the compiler command-line, but the compiler is
> @@ -226,6 +268,11 @@ static void init_accel(unsigned cache)
> fn = buffer_zero_avx2;
> }
> #endif
> +#ifdef CONFIG_AVX512F_OPT
> +if (cache & CACHE_AVX512F) {
> +fn = buffer_zero_avx512;
> +}
> +#endif
> buffer_accel = fn;
> }
>
> @@ -255,6 +302,9 @@ static void __attribute__((constructor))
> init_cpuid_cache(void)
> if ((bv & 6) == 6 && (b & bit_AVX2)) {
> cache |= CACHE_AVX2;
> }
> +if ((bv & 6) == 6 && (b & bit_AVX512F)) {
> +cache |= CACHE_AVX512F;
> +}
> }
Re: [RESEND RFC PATCH v2 1/2] target/arm: Allow to inject SError interrupt
On 2/13/20 4:39 PM, Richard Henderson wrote: On 2/12/20 7:49 PM, Gavin Shan wrote: On 2/12/20 10:34 PM, Peter Maydell wrote: Yeah, this is on my list to look at; Richard Henderson also could have a look at it. From a quick scan I suspect you may be missing handling for AArch32. [Thanks for copying Richard Henderson] Yes, the functionality is only supported on aarch64 currently by intention because the next patch enables it on "max" and "host" CPU models and both of them are running in aarch64 mode. We shouldn't leave the aarch32 exception entry paths unimplemented though. C.f. AArch32.TakePhysicalSErrorException() AArch32.TakeVirtualSErrorException() It really shouldn't be more than a couple of lines, just like arm_cpu_do_interrupt_aarch64. Remember both arm_cpu_do_interrupt_aarch32 and arm_cpu_do_interrupt_aarch32_hyp. Thanks for the details. The SError injection for aarch32 will be included in v3. However, it seems there is a long list of aarch32 CPU models, defined in target/arm/cpu.c::arm_cpus. so which CPU models you prefer to see with this supported? I think we might choose one or two popular CPU models if you agree. Even qemu-system-aarch64 -cpu max can exercise this path when EL1 is running in aarch32 mode. Admittedly it would be easier if we had the rest of the plumbing so that -cpu max,aarch64=off worked. FWIW, the rest of the patch looks good. I think "-cpu max,aarch64=off" is only valid when KVM is enabled? If that's true, the ioctl(cpu, KVM_SET_VCPU_EVENTS, ) already worked for aarch32 or aarch64 guest if I'm correct enough. But yes, I need to test it because I never tested this series on aarch32 guest :) Thanks, Gavin
Re: [PATCH] hw/arm: ast2400/ast2500: Wire up EHCI controllers
On Thu, 6 Feb 2020 at 18:34, Guenter Roeck wrote: > > Initialize EHCI controllers on AST2400 and AST2500 using the existing > TYPE_PLATFORM_EHCI. After this change, booting ast2500-evb into Linux > successfully instantiates a USB interface. > > ehci-platform 1e6a3000.usb: EHCI Host Controller > ehci-platform 1e6a3000.usb: new USB bus registered, assigned bus number 1 > ehci-platform 1e6a3000.usb: irq 21, io mem 0x1e6a3000 > ehci-platform 1e6a3000.usb: USB 2.0 started, EHCI 1.00 > usb usb1: New USB device found, idVendor=1d6b, idProduct=0002, bcdDevice= 5.05 > usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1 > usb usb1: Product: EHCI Host Controller > > Signed-off-by: Guenter Roeck Applied to target-arm.next, thanks. -- PMM
Re: [PATCH v9 02/23] softmmu: move vl.c to softmmu/
On Tue, Feb 11, 2020 at 03:34:49PM -0500, Alexander Bulekov wrote: > Signed-off-by: Alexander Bulekov > --- > Makefile.objs | 2 -- > Makefile.target | 1 + > softmmu/Makefile.objs | 2 ++ > vl.c => softmmu/vl.c | 0 > 4 files changed, 3 insertions(+), 2 deletions(-) Please update the ./MAINTAINERS entry for vl.c here too. There is also a top_of_tree check in scripts/get_maintainer.pl that needs to be updated in this commit. signature.asc Description: PGP signature
Re: [PATCH 2/2] util: add util function buffer_zero_avx512()
On Thu, 2020-02-13 at 11:30 +0100, Paolo Bonzini wrote:
> On 13/02/20 08:52, Robert Hoo wrote:
> > +
> > +}
> > +#pragma GCC pop_options
> > +#endif
> > +
> > +
> > /* Note that for test_buffer_is_zero_next_accel, the most
> > preferred
> > * ISA must have the least significant bit.
> > */
> > -#define CACHE_AVX21
> > -#define CACHE_SSE42
> > -#define CACHE_SSE24
> > +#define CACHE_AVX512F 1
> > +#define CACHE_AVX22
> > +#define CACHE_SSE44
> > +#define CACHE_SSE26
>
> This should be 8, not 6.
>
> Paolo
Thanks Paolo, going to fix it in v2.
>
> >
> > /* Make sure that these variables are appropriately initialized
> > when
> > * SSE2 is enabled on the compiler command-line, but the compiler
> > is
> > @@ -226,6 +268,11 @@ static void init_accel(unsigned cache)
> > fn = buffer_zero_avx2;
> > }
> > #endif
> > +#ifdef CONFIG_AVX512F_OPT
> > +if (cache & CACHE_AVX512F) {
> > +fn = buffer_zero_avx512;
> > +}
> > +#endif
> > buffer_accel = fn;
> > }
> >
> > @@ -255,6 +302,9 @@ static void __attribute__((constructor))
> > init_cpuid_cache(void)
> > if ((bv & 6) == 6 && (b & bit_AVX2)) {
> > cache |= CACHE_AVX2;
> > }
> > +if ((bv & 6) == 6 && (b & bit_AVX512F)) {
> > +cache |= CACHE_AVX512F;
> > +}
> > }
>
>
[Bug 1863096] [NEW] vhost-user multi-queues interrupt failed when Qemu reconnection happens
Public bug reported: After upgrade qemu to v4.2.0, vhost-user multi-queues interrupt failed with event idx interrupt mode when reconnection happens. Test Environment: DPDK version: DPDK v19.11 Other software versions: qemu 4.2.0. OS: Linux 4.15.0-20-generic Compiler: gcc (Ubuntu 7.3.0-16ubuntu3) 7.3.0 Hardware platform: Purley. The reproduce step is: 1. Launch l3fwd-power example app with client mode:: ./l3fwd-power -l 1-16 \ -n 4 --socket-mem 1024,1024 --legacy-mem --no-pci\ --log-level=9 \ --vdev 'eth_vhost0,iface=/vhost-net0,queues=16,client=1' \ -- -p 0x1 \ --parse-ptype 1 \ --config "(0,0,1),(0,1,2),(0,2,3),(0,3,4),(0,4,5),(0,5,6),(0,6,7),(0,7,8),(0,8,9),(0,9,10),(0,10,11),(0,11,12),(0,12,13),(0,13,14),(0,14,15),(0,15,16)" 2. Launch VM1 with server mode: 3. Relauch l3fwd-power sample to for reconnection: ./l3fwd-power -l 1-16 \ -n 4 --socket-mem 1024,1024 --legacy-mem --no-pci\ --log-level=9 \ --vdev 'eth_vhost0,iface=/vhost-net0,queues=16,client=1' \ -- -p 0x1 \ --parse-ptype 1 \ --config "(0,0,1),(0,1,2),(0,2,3),(0,3,4),(0,4,5),(0,5,6),(0,6,7),(0,7,8),(0,8,9),(0,9,10),(0,10,11),(0,11,12),(0,12,13),(0,13,14),(0,14,15),(0,15,16)" 4. Set vitio-net with 16 quques and give vitio-net ip address: ethtool -L [ens3] combined 16# [ens3] is the name of virtio-net ifconfig [ens3] 1.1.1.1 5. Send packets with different IPs from virtio-net, notice to bind each vcpu to different send packets process:: taskset -c 0 ping 1.1.1.2 taskset -c 1 ping 1.1.1.3 taskset -c 2 ping 1.1.1.4 taskset -c 3 ping 1.1.1.5 taskset -c 4 ping 1.1.1.6 taskset -c 5 ping 1.1.1.7 taskset -c 6 ping 1.1.1.8 taskset -c 7 ping 1.1.1.9 taskset -c 8 ping 1.1.1.2 taskset -c 9 ping 1.1.1.2 taskset -c 10 ping 1.1.1.2 taskset -c 11 ping 1.1.1.2 taskset -c 12 ping 1.1.1.2 taskset -c 13 ping 1.1.1.2 taskset -c 14 ping 1.1.1.2 taskset -c 15 ping 1.1.1.2 If everything ok, then we can see the result such as following: L3FWD_POWER: lcore 0 is waked up from rx interrupt on port 0 queue 0 ... ... L3FWD_POWER: lcore 15 is waked up from rx interrupt on port 0 queue 15 But we can't see the log above because of the bug. ** Affects: qemu Importance: Undecided Status: New -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1863096 Title: vhost-user multi-queues interrupt failed when Qemu reconnection happens Status in QEMU: New Bug description: After upgrade qemu to v4.2.0, vhost-user multi-queues interrupt failed with event idx interrupt mode when reconnection happens. Test Environment: DPDK version: DPDK v19.11 Other software versions: qemu 4.2.0. OS: Linux 4.15.0-20-generic Compiler: gcc (Ubuntu 7.3.0-16ubuntu3) 7.3.0 Hardware platform: Purley. The reproduce step is: 1. Launch l3fwd-power example app with client mode:: ./l3fwd-power -l 1-16 \ -n 4 --socket-mem 1024,1024 --legacy-mem --no-pci\ --log-level=9 \ --vdev 'eth_vhost0,iface=/vhost-net0,queues=16,client=1' \ -- -p 0x1 \ --parse-ptype 1 \ --config "(0,0,1),(0,1,2),(0,2,3),(0,3,4),(0,4,5),(0,5,6),(0,6,7),(0,7,8),(0,8,9),(0,9,10),(0,10,11),(0,11,12),(0,12,13),(0,13,14),(0,14,15),(0,15,16)" 2. Launch VM1 with server mode: 3. Relauch l3fwd-power sample to for reconnection: ./l3fwd-power -l 1-16 \ -n 4 --socket-mem 1024,1024 --legacy-mem --no-pci\ --log-level=9 \ --vdev 'eth_vhost0,iface=/vhost-net0,queues=16,client=1' \ -- -p 0x1 \ --parse-ptype 1 \ --config "(0,0,1),(0,1,2),(0,2,3),(0,3,4),(0,4,5),(0,5,6),(0,6,7),(0,7,8),(0,8,9),(0,9,10),(0,10,11),(0,11,12),(0,12,13),(0,13,14),(0,14,15),(0,15,16)" 4. Set vitio-net with 16 quques and give vitio-net ip address: ethtool -L [ens3] combined 16# [ens3] is the name of virtio-net ifconfig [ens3] 1.1.1.1 5. Send packets with different IPs from virtio-net, notice to bind each vcpu to different send packets process:: taskset -c 0 ping 1.1.1.2 taskset -c 1 ping 1.1.1.3 taskset -c 2 ping 1.1.1.4 taskset -c 3 ping 1.1.1.5 taskset -c 4 ping 1.1.1.6 taskset -c 5 ping 1.1.1.7 taskset -c 6 ping 1.1.1.8 taskset -c 7 ping 1.1.1.9 taskset -c 8 ping 1.1.1.2 taskset -c 9 ping 1.1.1.2 taskset -c 10 ping 1.1.1.2 taskset -c 11 ping 1.1.1.2 taskset -c 12 ping 1.1.1.2 taskset -c 13 ping 1.1.1.2 taskset -c 14 ping 1.1.1.2 taskset -c 15 ping 1.1.1.2 If everything ok, then we can see the result such as following: L3FWD_POWER: lcore 0 is waked up from rx interrupt on port 0 queue 0 ... ... L3FWD_POWER: lcore 15 is waked up from rx interrupt on port 0 queue 15 But we can't see the log above because of the bug. To manage notifications about this
Re: [PATCH v5 0/6] small vhost changes and in-band notifications
On Thu, 2020-01-23 at 09:17 +0100, Johannes Berg wrote: > Hi, > > Here's a repost of all the patches I sent back in August, with the > in-band notifications rebased over the reset patch, so IDs have now > changed a bit. Ping? The patches still apply on top of latest qemu. I wanted to send some corresponding kernel patches, but without the protocol nailed down ... johannes
Re: [PATCH] migration-test: fix some memleaks in migration-test
On 11/02/2020 09:45, pannengy...@huawei.com wrote:
> From: Pan Nengyuan
>
> spotted by asan, 'check-qtest-aarch64' runs fail if sanitizers is enabled.
>
> Reported-by: Euler Robot
> Signed-off-by: Pan Nengyuan
> ---
> tests/qtest/migration-test.c | 14 --
> 1 file changed, 12 insertions(+), 2 deletions(-)
>
> diff --git a/tests/qtest/migration-test.c b/tests/qtest/migration-test.c
> index cf27ebbc9d..2bb214c87f 100644
> --- a/tests/qtest/migration-test.c
> +++ b/tests/qtest/migration-test.c
> @@ -498,11 +498,13 @@ static int test_migrate_start(QTestState **from,
> QTestState **to,
> const char *arch = qtest_get_arch();
> const char *machine_opts = NULL;
> const char *memory_size;
> +int ret = 0;
>
> if (args->use_shmem) {
> if (!g_file_test("/dev/shm", G_FILE_TEST_IS_DIR)) {
> g_test_skip("/dev/shm is not supported");
> -return -1;
> +ret = -1;
> +goto out;
> }
> }
>
> @@ -611,8 +613,9 @@ static int test_migrate_start(QTestState **from,
> QTestState **to,
> g_free(shmem_path);
> }
>
> +out:
> migrate_start_destroy(args);
> -return 0;
> +return ret;
> }
>
> static void test_migrate_end(QTestState *from, QTestState *to, bool
> test_dest)
> @@ -1134,6 +1137,8 @@ static void test_validate_uuid(void)
> {
> MigrateStart *args = migrate_start_new();
>
> +g_free(args->opts_source);
> +g_free(args->opts_target);
> args->opts_source = g_strdup("-uuid
> ----");
> args->opts_target = g_strdup("-uuid
> ----");
> do_test_validate_uuid(args, false);
> @@ -1143,6 +1148,8 @@ static void test_validate_uuid_error(void)
> {
> MigrateStart *args = migrate_start_new();
>
> +g_free(args->opts_source);
> +g_free(args->opts_target);
> args->opts_source = g_strdup("-uuid
> ----");
> args->opts_target = g_strdup("-uuid
> ----");
> args->hide_stderr = true;
> @@ -1153,6 +1160,7 @@ static void test_validate_uuid_src_not_set(void)
> {
> MigrateStart *args = migrate_start_new();
>
> +g_free(args->opts_target);
> args->opts_target = g_strdup("-uuid
> ----");
> args->hide_stderr = true;
> do_test_validate_uuid(args, false);
> @@ -1162,6 +1170,7 @@ static void test_validate_uuid_dst_not_set(void)
> {
> MigrateStart *args = migrate_start_new();
>
> +g_free(args->opts_source);
> args->opts_source = g_strdup("-uuid
> ----");
> args->hide_stderr = true;
> do_test_validate_uuid(args, false);
> @@ -1379,6 +1388,7 @@ static void test_multifd_tcp_cancel(void)
> " 'arguments': { 'uri': 'tcp:127.0.0.1:0' }}");
> qobject_unref(rsp);
>
> +g_free(uri);
> uri = migrate_get_socket_address(to2, "socket-address");
>
> wait_for_migration_status(from, "cancelled", NULL);
>
Reviewed-by: Laurent Vivier
Re: [PATCH] docs: Fix virtiofsd.1 location
On 12/02/20 18:51, Peter Maydell wrote: > On Wed, 12 Feb 2020 at 16:51, Philippe Mathieu-Daudé > wrote: >> We stopped testing in-tree builds 2 months ago: >> >> commit bc4486fb233573e77b6e9ad6d6379afb5e37ad8c >> Author: Paolo Bonzini >> Date: Wed Dec 11 15:33:49 2019 +0100 >> >> ci: build out-of-tree >> >> Most developers are using out-of-tree builds and it was discussed >> in the past to only allow those. To prepare for the transition, >> use out-of-tree builds in all continuous integration jobs. > > I'd missed that. Paolo, do you have a plan for following > through and actively forbidding in-tree-builds, if that's > the route we're taking ? I can follow up on that, yes. Paolo
Re: [RESEND RFC PATCH v2 1/2] target/arm: Allow to inject SError interrupt
On Thu, 13 Feb 2020 at 03:49, Gavin Shan wrote: > On 2/12/20 10:34 PM, Peter Maydell wrote: > > Yeah, this is on my list to look at; Richard Henderson also could > > have a look at it. From a quick scan I suspect you may be missing > > handling for AArch32. > Yes, the functionality is only supported on aarch64 currently by intention > because the next patch enables it on "max" and "host" CPU models and both > of them are running in aarch64 mode. > > https://patchwork.kernel.org/patch/11366119/ > > If you really want to get this supported for aarch32 either, I can do > it. However, it seems there is a long list of aarch32 CPU models, defined > in target/arm/cpu.c::arm_cpus. so which CPU models you prefer to see with > this supported? I think we might choose one or two popular CPU models if > you agree. I don't think you should need to care about the CPU models. We should implement SError (aka "asynchronous external abort" in ARMv7 and earlier) generically for all CPUs. The SError/async abort should be triggered by a qemu_irq line inbound to the CPU (similar to FIQ and IRQ); the board can choose to wire that up to something, or not, as it likes. thanks -- PMM
Re: [RESEND RFC PATCH v2 2/2] target/arm: Support NMI injection
On Wed, 5 Feb 2020 at 11:06, Gavin Shan wrote: > > This supports QMP/HMP "nmi" command by injecting SError interrupt to > guest, which is expected to crash with that. Currently, It's supported > on two CPU models: "host" and "max". > > Signed-off-by: Gavin Shan > --- > hw/arm/virt.c | 18 > target/arm/cpu-qom.h | 1 + > target/arm/cpu.c | 48 ++ > target/arm/cpu64.c | 25 ++ > target/arm/internals.h | 8 +++ > 5 files changed, 96 insertions(+), 4 deletions(-) A few quick general notes: (1) as I mentioned on the cover letter, the mechanism for injecting an SError/async external abort into the CPU should be a qemu_irq line, like FIQ/IRQ, not a special-purpose method on the CPU object. (2) for function naming, there's a dividing line between: * code that implements the (unfortunately x86-centric) monitor command named "nmi"; these functions can have names with 'nmi' in them * code which implements the actual mechanism of 'deliver an SError to the CPU'; these functions should not have 'nmi' in the name or mention nmi, because nmi is not a concept in the Arm architecture (3) Before we expose 'nmi' to users as something that delivers an SError, we need to think about the interactions with RAS, because currently we also use SError to say "there was an error in the host memory you're using", and we might in future want to use SError for proper emulated RAS. We don't want to paint ourselves into a corner by grabbing SError exclusively for 'nmi'. thanks -- PMM
Re: [PATCH v2 5/9] linux-user: mips: Update syscall numbers to kernel 5.5 level
Le 13/02/2020 à 02:46, Aleksandar Markovic a écrit :
> From: Aleksandar Markovic
>
> Update mips syscall numbers based on Linux kernel tag v5.5.
>
> CC: Aurelien Jarno
> CC: Aleksandar Rikalo
> Signed-off-by: Aleksandar Markovic
> ---
> linux-user/mips/syscall_nr.h | 45 +++
> linux-user/mips64/syscall_nr.h | 50 -
> linux-user/mips/cpu_loop.c | 83
> +-
> 3 files changed, 175 insertions(+), 3 deletions(-)
>
...
> diff --git a/linux-user/mips/cpu_loop.c b/linux-user/mips/cpu_loop.c
> index 39915b3..a2c72fa 100644
> --- a/linux-user/mips/cpu_loop.c
> +++ b/linux-user/mips/cpu_loop.c
> @@ -25,8 +25,9 @@
> #include "internal.h"
>
> # ifdef TARGET_ABI_MIPSO32
> +# define MIPS_SYSCALL_NUMBER_UNUSED -1
> # define MIPS_SYS(name, args) args,
> -static const uint8_t mips_syscall_args[] = {
> +static const int8_t mips_syscall_args[] = {
> MIPS_SYS(sys_syscall, 8)/* 4000 */
> MIPS_SYS(sys_exit , 1)
> MIPS_SYS(sys_fork , 0)
> @@ -390,6 +391,80 @@ static const uint8_t mips_syscall_args[] = {
> MIPS_SYS(sys_copy_file_range, 6) /* 360 */
> MIPS_SYS(sys_preadv2, 6)
> MIPS_SYS(sys_pwritev2, 6)
> +MIPS_SYS(sys_pkey_mprotect, 4)
> +MIPS_SYS(sys_pkey_alloc, 2)
> +MIPS_SYS(sys_pkey_free, 1) /* 365 */
> +MIPS_SYS(sys_statx, 5)
> +MIPS_SYS(sys_rseq, 4)
> +MIPS_SYS(sys_io_pgetevents, 6)
> +MIPS_SYSCALL_NUMBER_UNUSED,
> +MIPS_SYSCALL_NUMBER_UNUSED,/* 370 */
> +MIPS_SYSCALL_NUMBER_UNUSED,
> +MIPS_SYSCALL_NUMBER_UNUSED,
> +MIPS_SYSCALL_NUMBER_UNUSED,
> +MIPS_SYSCALL_NUMBER_UNUSED,
> +MIPS_SYSCALL_NUMBER_UNUSED,/* 375 */
> +MIPS_SYSCALL_NUMBER_UNUSED,
> +MIPS_SYSCALL_NUMBER_UNUSED,
> +MIPS_SYSCALL_NUMBER_UNUSED,
> +MIPS_SYSCALL_NUMBER_UNUSED,
> +MIPS_SYSCALL_NUMBER_UNUSED,/* 380 */
> +MIPS_SYSCALL_NUMBER_UNUSED,
> +MIPS_SYSCALL_NUMBER_UNUSED,
> +MIPS_SYSCALL_NUMBER_UNUSED,
> +MIPS_SYSCALL_NUMBER_UNUSED,
> +MIPS_SYSCALL_NUMBER_UNUSED,/* 385 */
> +MIPS_SYSCALL_NUMBER_UNUSED,
> +MIPS_SYSCALL_NUMBER_UNUSED,
> +MIPS_SYSCALL_NUMBER_UNUSED,
> +MIPS_SYSCALL_NUMBER_UNUSED,
> +MIPS_SYSCALL_NUMBER_UNUSED,/* 390 */
> +MIPS_SYSCALL_NUMBER_UNUSED,
> +MIPS_SYSCALL_NUMBER_UNUSED,
> +MIPS_SYS(sys_semget, 3)
> +MIPS_SYS(sys_semctl, 4)
> +MIPS_SYS(sys_shmget, 3)/* 395 */
> +MIPS_SYS(sys_shmctl, 3)
> +MIPS_SYS(sys_shmat, 3)
> +MIPS_SYS(sys_shmdt, 1)
> +MIPS_SYS(sys_msgget, 2)
> +MIPS_SYS(sys_msgsnd, 4)/* 400 */
> +MIPS_SYS(sys_msgrcv, 5)
> +MIPS_SYS(sys_msgctl, 3)
> +MIPS_SYS(sys_clock_gettime64, 2)
> +MIPS_SYS(sys_clock_settime64, 4)
> +MIPS_SYS(sys_clock_adjtime64, 2) /* 405 */
> +MIPS_SYS(sys_clock_getres_time64, 4)
According to
https://github.com/strace/strace/blob/master/linux/syscallent-common-32.h:
[BASE_NR + 406] = { 2, 0, SEN(clock_getres_time64),
"clock_getres_time64" },
once fixed you can add my
Reviewed-by: Laurent Vivier
[PULL 1/5] linux-user: add missing TARGET_SIGRTMIN for hppa
This signal is defined for all other targets and we will need it later Signed-off-by: Laurent Vivier [pm: that this was actually an ABI change in the hppa kernel (at kernel version 3.17, kernel commit 1f25df2eff5b25f52c139d). Before that SIGRTMIN was 37... All our other HPPA TARGET_SIG* values are for the updated ABI following that commit, so using 32 for SIGRTMIN is the right thing for us.] Reviewed-by: Peter Maydell Tested-by: Taylor Simpson Message-Id: <20200212125658.644558-2-laur...@vivier.eu> Signed-off-by: Laurent Vivier --- linux-user/hppa/target_signal.h | 1 + 1 file changed, 1 insertion(+) diff --git a/linux-user/hppa/target_signal.h b/linux-user/hppa/target_signal.h index ba159ff8d006..c2a0102ed73d 100644 --- a/linux-user/hppa/target_signal.h +++ b/linux-user/hppa/target_signal.h @@ -34,6 +34,7 @@ #define TARGET_SIGURG 29 #define TARGET_SIGXFSZ 30 #define TARGET_SIGSYS 31 +#define TARGET_SIGRTMIN32 #define TARGET_SIG_BLOCK 0 #define TARGET_SIG_UNBLOCK 1 -- 2.24.1
[PULL 5/5] linux-user: implement TARGET_SO_PEERSEC
"The purpose of this option is to allow an application to obtain the
security credentials of a Unix stream socket peer. It is analogous to
SO_PEERCRED (which provides authentication using standard Unix credentials
of pid, uid and gid), and extends this concept to other security
models." -- https://lwn.net/Articles/62370/
Until now it was passed to the kernel with an "int" argument and
fails when it was supported by the host because the parameter is
like a filename: it is always a \0-terminated string with no embedded
\0 characters, but is not guaranteed to be ASCII or UTF-8.
I've tested the option with the following program:
/*
* cc -o getpeercon getpeercon.c
*/
#include
#include
#include
#include
#include
int main(void)
{
int fd;
struct sockaddr_in server, addr;
int ret;
socklen_t len;
char buf[256];
fd = socket(PF_INET, SOCK_STREAM, 0);
if (fd == -1) {
perror("socket");
return 1;
}
server.sin_family = AF_INET;
inet_aton("127.0.0.1", _addr);
server.sin_port = htons(40390);
connect(fd, (struct sockaddr*), sizeof(server));
len = sizeof(buf);
ret = getsockopt(fd, SOL_SOCKET, SO_PEERSEC, buf, );
if (ret == -1) {
perror("getsockopt");
return 1;
}
printf("%d %s\n", len, buf);
return 0;
}
On host:
$ ./getpeercon
33 system_u:object_r:unlabeled_t:s0
With qemu-aarch64/bionic without the patch:
$ ./getpeercon
getsockopt: Numerical result out of range
With the patch:
$ ./getpeercon
33 system_u:object_r:unlabeled_t:s0
Bug: https://bugs.launchpad.net/qemu/+bug/1823790
Reported-by: Matthias Lüscher
Tested-by: Matthias Lüscher
Signed-off-by: Laurent Vivier
Reviewed-by: Philippe Mathieu-Daudé
Tested-by: Philippe Mathieu-Daudé
Message-Id: <20200204211901.1731821-1-laur...@vivier.eu>
---
linux-user/syscall.c | 22 ++
1 file changed, 22 insertions(+)
diff --git a/linux-user/syscall.c b/linux-user/syscall.c
index d60142f0691c..c930577686da 100644
--- a/linux-user/syscall.c
+++ b/linux-user/syscall.c
@@ -2344,6 +2344,28 @@ static abi_long do_getsockopt(int sockfd, int level, int
optname,
}
break;
}
+case TARGET_SO_PEERSEC: {
+char *name;
+
+if (get_user_u32(len, optlen)) {
+return -TARGET_EFAULT;
+}
+if (len < 0) {
+return -TARGET_EINVAL;
+}
+name = lock_user(VERIFY_WRITE, optval_addr, len, 0);
+if (!name) {
+return -TARGET_EFAULT;
+}
+lv = len;
+ret = get_errno(getsockopt(sockfd, level, SO_PEERSEC,
+ name, ));
+if (put_user_u32(lv, optlen)) {
+ret = -TARGET_EFAULT;
+}
+unlock_user(name, optval_addr, lv);
+break;
+}
case TARGET_SO_LINGER:
{
struct linger lg;
--
2.24.1
[PULL 4/5] linux-user: fix use of SIGRTMIN
Some RT signals can be in use by glibc,
it's why SIGRTMIN (34) is generally greater than __SIGRTMIN (32).
So SIGRTMIN cannot be mapped to TARGET_SIGRTMIN.
Instead of swapping only SIGRTMIN and SIGRTMAX, map all the
range [TARGET_SIGRTMIN ... TARGET_SIGRTMAX - X] to
[__SIGRTMIN + X ... SIGRTMAX ]
(SIGRTMIN is __SIGRTMIN + X).
Signed-off-by: Laurent Vivier
Reviewed-by: Taylor Simson
Tested-by: Taylor Simpson
Reviewed-by: Peter Maydell
Message-Id: <20200212125658.644558-5-laur...@vivier.eu>
---
linux-user/signal.c | 50 -
linux-user/trace-events | 3 +++
2 files changed, 48 insertions(+), 5 deletions(-)
diff --git a/linux-user/signal.c b/linux-user/signal.c
index c1e664f97a7c..046159dd0c5b 100644
--- a/linux-user/signal.c
+++ b/linux-user/signal.c
@@ -498,18 +498,30 @@ static int core_dump_signal(int sig)
static void signal_table_init(void)
{
-int host_sig, target_sig;
+int host_sig, target_sig, count;
/*
- * Nasty hack: Reverse SIGRTMIN and SIGRTMAX to avoid overlap with
- * host libpthread signals. This assumes no one actually uses SIGRTMAX :-/
+ * Signals are supported starting from TARGET_SIGRTMIN and going up
+ * until we run out of host realtime signals.
+ * glibc at least uses only the lower 2 rt signals and probably
+ * nobody's using the upper ones.
+ * it's why SIGRTMIN (34) is generally greater than __SIGRTMIN (32)
* To fix this properly we need to do manual signal delivery multiplexed
* over a single host signal.
+ * Attempts for configure "missing" signals via sigaction will be
+ * silently ignored.
*/
-host_to_target_signal_table[__SIGRTMIN] = __SIGRTMAX;
-host_to_target_signal_table[__SIGRTMAX] = __SIGRTMIN;
+for (host_sig = SIGRTMIN; host_sig <= SIGRTMAX; host_sig++) {
+target_sig = host_sig - SIGRTMIN + TARGET_SIGRTMIN;
+if (target_sig <= TARGET_NSIG) {
+host_to_target_signal_table[host_sig] = target_sig;
+}
+}
/* generate signal conversion tables */
+for (target_sig = 1; target_sig <= TARGET_NSIG; target_sig++) {
+target_to_host_signal_table[target_sig] = _NSIG; /* poison */
+}
for (host_sig = 1; host_sig < _NSIG; host_sig++) {
if (host_to_target_signal_table[host_sig] == 0) {
host_to_target_signal_table[host_sig] = host_sig;
@@ -519,6 +531,15 @@ static void signal_table_init(void)
target_to_host_signal_table[target_sig] = host_sig;
}
}
+
+if (trace_event_get_state_backends(TRACE_SIGNAL_TABLE_INIT)) {
+for (target_sig = 1, count = 0; target_sig <= TARGET_NSIG;
target_sig++) {
+if (target_to_host_signal_table[target_sig] == _NSIG) {
+count++;
+}
+}
+trace_signal_table_init(count);
+}
}
void signal_init(void)
@@ -817,6 +838,8 @@ int do_sigaction(int sig, const struct target_sigaction
*act,
int host_sig;
int ret = 0;
+trace_signal_do_sigaction_guest(sig, TARGET_NSIG);
+
if (sig < 1 || sig > TARGET_NSIG || sig == TARGET_SIGKILL || sig ==
TARGET_SIGSTOP) {
return -TARGET_EINVAL;
}
@@ -847,6 +870,23 @@ int do_sigaction(int sig, const struct target_sigaction
*act,
/* we update the host linux signal state */
host_sig = target_to_host_signal(sig);
+trace_signal_do_sigaction_host(host_sig, TARGET_NSIG);
+if (host_sig > SIGRTMAX) {
+/* we don't have enough host signals to map all target signals */
+qemu_log_mask(LOG_UNIMP, "Unsupported target signal #%d,
ignored\n",
+ sig);
+/*
+ * we don't return an error here because some programs try to
+ * register an handler for all possible rt signals even if they
+ * don't need it.
+ * An error here can abort them whereas there can be no problem
+ * to not have the signal available later.
+ * This is the case for golang,
+ * See https://github.com/golang/go/issues/33746
+ * So we silently ignore the error.
+ */
+return 0;
+}
if (host_sig != SIGSEGV && host_sig != SIGBUS) {
sigfillset(_mask);
act1.sa_flags = SA_SIGINFO;
diff --git a/linux-user/trace-events b/linux-user/trace-events
index f6de1b8befc0..0296133daeb6 100644
--- a/linux-user/trace-events
+++ b/linux-user/trace-events
@@ -1,6 +1,9 @@
# See docs/devel/tracing.txt for syntax documentation.
# signal.c
+signal_table_init(int i) "number of unavailable signals: %d"
+signal_do_sigaction_guest(int sig, int max) "target signal %d (MAX %d)"
+signal_do_sigaction_host(int sig, int max) "host signal %d (MAX %d)"
# */signal.c
user_setup_frame(void *env, uint64_t frame_addr) "env=%p frame_addr=0x%"PRIx64
user_setup_rt_frame(void *env, uint64_t frame_addr) "env=%p
[PULL 3/5] linux-user: fix TARGET_NSIG and _NSIG uses
Valid signal numbers are between 1 (SIGHUP) and SIGRTMAX.
System includes define _NSIG to SIGRTMAX + 1, but
QEMU (like kernel) defines TARGET_NSIG to TARGET_SIGRTMAX.
Fix all the checks involving the signal range.
Signed-off-by: Laurent Vivier
Reviewed-by: Peter Maydell
Tested-by: Taylor Simpson
Message-Id: <20200212125658.644558-4-laur...@vivier.eu>
---
linux-user/signal.c | 52 -
1 file changed, 37 insertions(+), 15 deletions(-)
diff --git a/linux-user/signal.c b/linux-user/signal.c
index 246315571c09..c1e664f97a7c 100644
--- a/linux-user/signal.c
+++ b/linux-user/signal.c
@@ -30,6 +30,15 @@ static struct target_sigaction sigact_table[TARGET_NSIG];
static void host_signal_handler(int host_signum, siginfo_t *info,
void *puc);
+
+/*
+ * System includes define _NSIG as SIGRTMAX + 1,
+ * but qemu (like the kernel) defines TARGET_NSIG as TARGET_SIGRTMAX
+ * and the first signal is SIGHUP defined as 1
+ * Signal number 0 is reserved for use as kill(pid, 0), to test whether
+ * a process exists without sending it a signal.
+ */
+QEMU_BUILD_BUG_ON(__SIGRTMAX + 1 != _NSIG);
static uint8_t host_to_target_signal_table[_NSIG] = {
[SIGHUP] = TARGET_SIGHUP,
[SIGINT] = TARGET_SIGINT,
@@ -67,19 +76,24 @@ static uint8_t host_to_target_signal_table[_NSIG] = {
[SIGSYS] = TARGET_SIGSYS,
/* next signals stay the same */
};
-static uint8_t target_to_host_signal_table[_NSIG];
+static uint8_t target_to_host_signal_table[TARGET_NSIG + 1];
+
+/* valid sig is between 1 and _NSIG - 1 */
int host_to_target_signal(int sig)
{
-if (sig < 0 || sig >= _NSIG)
+if (sig < 1 || sig >= _NSIG) {
return sig;
+}
return host_to_target_signal_table[sig];
}
+/* valid sig is between 1 and TARGET_NSIG */
int target_to_host_signal(int sig)
{
-if (sig < 0 || sig >= _NSIG)
+if (sig < 1 || sig > TARGET_NSIG) {
return sig;
+}
return target_to_host_signal_table[sig];
}
@@ -100,11 +114,15 @@ static inline int target_sigismember(const
target_sigset_t *set, int signum)
void host_to_target_sigset_internal(target_sigset_t *d,
const sigset_t *s)
{
-int i;
+int host_sig, target_sig;
target_sigemptyset(d);
-for (i = 1; i <= TARGET_NSIG; i++) {
-if (sigismember(s, i)) {
-target_sigaddset(d, host_to_target_signal(i));
+for (host_sig = 1; host_sig < _NSIG; host_sig++) {
+target_sig = host_to_target_signal(host_sig);
+if (target_sig < 1 || target_sig > TARGET_NSIG) {
+continue;
+}
+if (sigismember(s, host_sig)) {
+target_sigaddset(d, target_sig);
}
}
}
@@ -122,11 +140,15 @@ void host_to_target_sigset(target_sigset_t *d, const
sigset_t *s)
void target_to_host_sigset_internal(sigset_t *d,
const target_sigset_t *s)
{
-int i;
+int host_sig, target_sig;
sigemptyset(d);
-for (i = 1; i <= TARGET_NSIG; i++) {
-if (target_sigismember(s, i)) {
-sigaddset(d, target_to_host_signal(i));
+for (target_sig = 1; target_sig <= TARGET_NSIG; target_sig++) {
+host_sig = target_to_host_signal(target_sig);
+if (host_sig < 1 || host_sig >= _NSIG) {
+continue;
+}
+if (target_sigismember(s, target_sig)) {
+sigaddset(d, host_sig);
}
}
}
@@ -492,10 +514,10 @@ static void signal_table_init(void)
if (host_to_target_signal_table[host_sig] == 0) {
host_to_target_signal_table[host_sig] = host_sig;
}
-}
-for (host_sig = 1; host_sig < _NSIG; host_sig++) {
target_sig = host_to_target_signal_table[host_sig];
-target_to_host_signal_table[target_sig] = host_sig;
+if (target_sig <= TARGET_NSIG) {
+target_to_host_signal_table[target_sig] = host_sig;
+}
}
}
@@ -518,7 +540,7 @@ void signal_init(void)
act.sa_sigaction = host_signal_handler;
for(i = 1; i <= TARGET_NSIG; i++) {
#ifdef TARGET_GPROF
-if (i == SIGPROF) {
+if (i == TARGET_SIGPROF) {
continue;
}
#endif
--
2.24.1
[PULL 0/5] Linux user for 5.0 patches
The following changes since commit e18e5501d8ac692d32657a3e1ef545b14e72b730: Merge remote-tracking branch 'remotes/dgilbert-gitlab/tags/pull-virtiofs-20200210' into staging (2020-02-10 18:09:14 +) are available in the Git repository at: git://github.com/vivier/qemu.git tags/linux-user-for-5.0-pull-request for you to fetch changes up to 6d485a55d0cd8fbb8b4337b298f79ddb0c2a5511: linux-user: implement TARGET_SO_PEERSEC (2020-02-12 18:56:45 +0100) Implement TARGET_SO_PEERSEC Fix rt signals management Laurent Vivier (5): linux-user: add missing TARGET_SIGRTMIN for hppa linux-user: cleanup signal.c linux-user: fix TARGET_NSIG and _NSIG uses linux-user: fix use of SIGRTMIN linux-user: implement TARGET_SO_PEERSEC linux-user/hppa/target_signal.h | 1 + linux-user/signal.c | 134 linux-user/syscall.c| 22 ++ linux-user/trace-events | 3 + 4 files changed, 128 insertions(+), 32 deletions(-) -- 2.24.1
Re: [PATCH v5 0/6] small vhost changes and in-band notifications
On Thu, Feb 13, 2020 at 02:26:10PM +0100, Johannes Berg wrote: > On Thu, 2020-01-23 at 09:17 +0100, Johannes Berg wrote: > > Hi, > > > > Here's a repost of all the patches I sent back in August, with the > > in-band notifications rebased over the reset patch, so IDs have now > > changed a bit. > > Ping? > > The patches still apply on top of latest qemu. > > I wanted to send some corresponding kernel patches, but without the > protocol nailed down ... > > johannes Queued, thanks!
Re: [RFC 2/2] pci-expender-bus:Add pcie-root-port to pxb-pcie under arm.
On Thu, Feb 13, 2020 at 03:49:52PM +0800, Yubo Miao wrote:
> From: miaoyubo
>
> Since devices could not directly plugged into pxb-pcie, under arm, one
> pcie-root port is plugged into pxb-pcie. Due to the bus for each pxb-pcie
> is defined as 2 in acpi dsdt tables(one for pxb-pcie, one for pcie-root-port),
> only one device could be plugged into one pxb-pcie.
What is the cause of this arm specific requirement for pxb-pcie and
more importantly can be fix it so that we don't need this patch ?
I think it is highly undesirable to have such a per-arch difference
in configuration of the pxb-pcie device. It means any mgmt app
which already supports pxb-pcie will be broken and need to special
case arm.
>
> Signed-off-by: miaoyubo
> ---
> hw/pci-bridge/pci_expander_bridge.c | 9 +
> include/hw/pci/pcie_port.h | 1 +
> 2 files changed, 10 insertions(+)
>
> diff --git a/hw/pci-bridge/pci_expander_bridge.c
> b/hw/pci-bridge/pci_expander_bridge.c
> index 47aaaf8fd1..3d896dd452 100644
> --- a/hw/pci-bridge/pci_expander_bridge.c
> +++ b/hw/pci-bridge/pci_expander_bridge.c
> @@ -15,6 +15,7 @@
> #include "hw/pci/pci.h"
> #include "hw/pci/pci_bus.h"
> #include "hw/pci/pci_host.h"
> +#include "hw/pci/pcie_port.h"
> #include "hw/qdev-properties.h"
> #include "hw/pci/pci_bridge.h"
> #include "qemu/range.h"
> @@ -233,7 +234,15 @@ static void pxb_dev_realize_common(PCIDevice *dev, bool
> pcie, Error **errp)
>
> ds = qdev_create(NULL, TYPE_PXB_HOST);
> if (pcie) {
> +#ifdef __aarch64__
> +bus = pci_root_bus_new(ds, "pxb-pcie-internal",
> + NULL, NULL, 0, TYPE_PXB_PCIE_BUS);
> +bds = qdev_create(BUS(bus), "pcie-root-port");
> +bds->id = dev_name;
> +qdev_prop_set_uint8(bds, PCIE_ROOT_PORT_PROP_CHASSIS, pxb->bus_nr);
> +#else
> bus = pci_root_bus_new(ds, dev_name, NULL, NULL, 0,
> TYPE_PXB_PCIE_BUS);
> +#endif
> } else {
> bus = pci_root_bus_new(ds, "pxb-internal", NULL, NULL, 0,
> TYPE_PXB_BUS);
> bds = qdev_create(BUS(bus), "pci-bridge");
> diff --git a/include/hw/pci/pcie_port.h b/include/hw/pci/pcie_port.h
> index 4b3d254b08..b41d473220 100644
> --- a/include/hw/pci/pcie_port.h
> +++ b/include/hw/pci/pcie_port.h
> @@ -64,6 +64,7 @@ int pcie_chassis_add_slot(struct PCIESlot *slot);
> void pcie_chassis_del_slot(PCIESlot *s);
>
> #define TYPE_PCIE_ROOT_PORT "pcie-root-port-base"
> +#define PCIE_ROOT_PORT_PROP_CHASSIS "chassis"
> #define PCIE_ROOT_PORT_CLASS(klass) \
> OBJECT_CLASS_CHECK(PCIERootPortClass, (klass), TYPE_PCIE_ROOT_PORT)
> #define PCIE_ROOT_PORT_GET_CLASS(obj) \
> --
> 2.19.1
>
>
>
Regards,
Daniel
--
|: https://berrange.com -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
Re: [PATCH v3 03/13] hw/arm/raspi: Extract the version from the board revision
On 2/13/20 2:40 PM, Peter Maydell wrote:
On Sat, 8 Feb 2020 at 16:57, Philippe Mathieu-Daudé wrote:
The board revision encode the board version. Add a helper
to extract the version, and use it.
Signed-off-by: Philippe Mathieu-Daudé
---
hw/arm/raspi.c | 31 +++
1 file changed, 27 insertions(+), 4 deletions(-)
diff --git a/hw/arm/raspi.c b/hw/arm/raspi.c
index 818146fdbb..f285e2988f 100644
--- a/hw/arm/raspi.c
+++ b/hw/arm/raspi.c
@@ -16,6 +16,7 @@
#include "qapi/error.h"
#include "cpu.h"
#include "hw/arm/bcm2836.h"
+#include "hw/registerfields.h"
#include "qemu/error-report.h"
#include "hw/boards.h"
#include "hw/loader.h"
@@ -37,6 +38,28 @@ typedef struct RasPiState {
MemoryRegion ram;
} RasPiState;
+/*
+ * Board revision codes:
+ * www.raspberrypi.org/documentation/hardware/raspberrypi/revision-codes/
+ */
+FIELD(REV_CODE, REVISION, 0, 4);
+FIELD(REV_CODE, TYPE, 4, 8);
+FIELD(REV_CODE, PROCESSOR, 12, 4);
+FIELD(REV_CODE, MANUFACTURER, 16, 4);
+FIELD(REV_CODE, MEMORY_SIZE, 20, 3);
+FIELD(REV_CODE, STYLE, 23, 1);
+
+static int board_processor_id(uint32_t board_rev)
+{
+assert(FIELD_EX32(board_rev, REV_CODE, STYLE)); /* Only new style */
+return FIELD_EX32(board_rev, REV_CODE, PROCESSOR);
+}
+
+static int board_version(uint32_t board_rev)
+{
+return board_processor_id(board_rev) + 1;
This uses the 'processor' field, which basically means the SoC
(0 for BCM2835, 1 for BCM2836, 2 for BCMM2837, 3 for BCM2711).
We use 'version' for a wider range of things in our code here:
* do we need SMP setup?
* which address does the firmware image go?
* do we need to set up SMC vectors so no-op SMC works?
* as well as "which SoC do we instantiate"?
We think of 'version' as basically "raspi 2 or 3?", but
according to the table in your url you can get a version of
the raspi 2b with a BCM2837 SoC, which confuses this idea.
Anyway, since what we have in this patch works OK for the set
of board models we support, I'm happy to leave the patch as-is,
but maybe worth checking and considering what in our code we
should really be making conditional on "actually the SoC type"
and what on something else...
Yes you are right, version = (2, 3) was too simple, I replaced the
'version' check by 'processor_id' in the series introducing the raspi4
(with other cleanups).
Eventually this file will only use the board_rev fields directly.
Re: [PATCH v3 00/13] hw/arm/raspi: Dynamically create machines based on the board revision
On Sat, 8 Feb 2020 at 16:57, Philippe Mathieu-Daudé wrote: > > Hi, > > This series is a preparatory to easily add the raspi0/raspi1/raspi4 > boards (see [1]). > > Igor has been working in his "refactor main RAM allocation to use > hostmem backend" series, and now v4 [2] is almost reviewed. > > His raspi patch [3] clashes with my work, Since it is easier for > him to apply his on top of mine, I am sending these patches first. > > Since v2: > - Split of bigger series (30 patches was scary) > - addressed Zoltan review comments > > Phil. > > [1] https://www.mail-archive.com/qemu-devel@nongnu.org/msg677145.html > [2] https://www.mail-archive.com/qemu-devel@nongnu.org/msg675738.html > [3] https://www.mail-archive.com/qemu-devel@nongnu.org/msg675752.html > Supersedes: <20200206011756.2413-1-f4...@amsat.org> I had one or two minor comments but I'm happy if we address those in follow-up patches. Applied to target-arm.next with the commit message tweak for patch 13 suggested by Igor. thanks -- PMM
Re: [PATCH v5 7/8] multifd: Add multifd-zstd-level parameter
* Markus Armbruster (arm...@redhat.com) wrote:
> "Dr. David Alan Gilbert" writes:
>
> > * Juan Quintela (quint...@redhat.com) wrote:
> >> Signed-off-by: Juan Quintela
> >> ---
> >> migration/migration.c | 15 +++
> >> monitor/hmp-cmds.c| 4
> >> qapi/migration.json | 29 ++---
> >> 3 files changed, 45 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/migration/migration.c b/migration/migration.c
> >> index 3b081e8147..b690500545 100644
> >> --- a/migration/migration.c
> >> +++ b/migration/migration.c
> >> @@ -91,6 +91,8 @@
> >> #define DEFAULT_MIGRATE_MULTIFD_METHOD MULTIFD_METHOD_NONE
> >> /*0: means nocompress, 1: best speed, ... 9: best compress ratio */
> >> #define DEFAULT_MIGRATE_MULTIFD_ZLIB_LEVEL 1
> >> +/* 0: means nocompress, 1: best speed, ... 20: best compress ratio */
> >> +#define DEFAULT_MIGRATE_MULTIFD_ZSTD_LEVEL 1
> >>
> >> /* Background transfer rate for postcopy, 0 means unlimited, note
> >> * that page requests can still exceed this limit.
> >> @@ -805,6 +807,8 @@ MigrationParameters
> >> *qmp_query_migrate_parameters(Error **errp)
> >> params->multifd_method = s->parameters.multifd_method;
> >> params->has_multifd_zlib_level = true;
> >> params->multifd_zlib_level = s->parameters.multifd_zlib_level;
> >> +params->has_multifd_zstd_level = true;
> >> +params->multifd_zstd_level = s->parameters.multifd_zstd_level;
> >
> > Do we really want different 'multifd__level's or just one
> > 'multifd_compress_level' - or even just reuse the existing
> > 'compress-level' parameter.
>
> compress-level, multifd-zlib-level, and multifd-zstd-level apply
> "normal" live migration compression, multifd zlib live migration
> compression, and multifd zstd live migration compression, respectively.
>
> Any live migration can only use one of the three compressions.
>
> Correct?
Right.
> > The only tricky thing about combining them is how to handle
> > the difference in allowed ranges; When would the right time be
> > to check it?
> >
> > Markus/Eric: Any idea?
>
> To have an informed opinion, I'd have to dig through the migration
> code.
The tricky part I see is validating settings/parameters;
when someone tries to set a parameter migrate_params_check gets called
and has checks like:
if (params->has_compress_level &&
(params->compress_level > 9)) {
error_setg(errp, QERR_INVALID_PARAMETER_VALUE, "compress_level",
"is invalid, it should be in the range of 0 to 9");
return false;
}
now that's nice because you error when you set the parameter rather
than later when you try and start a migration; the downside now
though is you get more complex interaction between parameters and
capabilities - so for example if you set the multifd-compression type
parameter to 'zstd' and *then* set the single compression level
it'll be fine taking '20' as a compresison level, but if you were
to set the compression level to 20 and then set the type to 'zstd'
it might error because with zlib you can't have 20.
> Documentation of admissible range will become a bit awkward, too.
>
> Too many migration parameters...
Nod; which why I was trying to make it 1.
Dave
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
Re: [PATCH] hw/char/exynos4210_uart: Fix memleaks in exynos4210_uart_init
Eduardo Habkost writes:
> On Wed, Feb 12, 2020 at 08:39:55AM +0100, Philippe Mathieu-Daudé wrote:
>> Cc'ing Eduardo & Markus.
>>
>> On 2/12/20 7:44 AM, Chenqun (kuhn) wrote:
>> > > -Original Message-
>> > > From: Philippe Mathieu-Daudé [mailto:phi...@redhat.com]
>> > > Sent: Wednesday, February 12, 2020 2:16 PM
>> > > To: Chenqun (kuhn) ; qemu-
>> > > de...@nongnu.org; i.mitsya...@gmail.com; peter.mayd...@linaro.org
>> > > Cc: qemu-triv...@nongnu.org; Zhanghailiang
>> > >
>> > > Subject: Re: [PATCH] hw/char/exynos4210_uart: Fix memleaks in
>> > > exynos4210_uart_init
>> > >
>> > > On 2/12/20 4:36 AM, kuhn.chen...@huawei.com wrote:
>> > > > From: Chen Qun
>> > > >
>> > > > It's easy to reproduce as follow:
>> > > > virsh qemu-monitor-command vm1 --pretty '{"execute":
>> > > > "device-list-properties", "arguments":{"typename":"exynos4210.uart"}}'
>> > > >
>> > > > ASAN shows memory leak stack:
>> > > > #1 0xfffd896d71cb in g_malloc0 (/lib64/libglib-2.0.so.0+0x571cb)
>> > > > #2 0xaaad270beee3 in timer_new_full /qemu/include/qemu/timer.h:530
>> > > > #3 0xaaad270beee3 in timer_new /qemu/include/qemu/timer.h:551
>> > > > #4 0xaaad270beee3 in timer_new_ns /qemu/include/qemu/timer.h:569
>> > > > #5 0xaaad270beee3 in exynos4210_uart_init
>> > > /qemu/hw/char/exynos4210_uart.c:677
>> > > > #6 0xaaad275c8f4f in object_initialize_with_type
>> > > > /qemu/qom/object.c:516
>> > > > #7 0xaaad275c91bb in object_new_with_type /qemu/qom/object.c:684
>> > > > #8 0xaaad2755df2f in qmp_device_list_properties
>> > > > /qemu/qom/qom-qmp-cmds.c:152
>> > > >
>> > > > Reported-by: Euler Robot
>> > > > Signed-off-by: Chen Qun
>> > > > ---
>> > > >hw/char/exynos4210_uart.c | 8
>> > > >1 file changed, 4 insertions(+), 4 deletions(-)
>> > > >
>> > > > diff --git a/hw/char/exynos4210_uart.c b/hw/char/exynos4210_uart.c
>> > > > index 25d6588e41..5048db5410 100644
>> > > > --- a/hw/char/exynos4210_uart.c
>> > > > +++ b/hw/char/exynos4210_uart.c
>> > > > @@ -674,10 +674,6 @@ static void exynos4210_uart_init(Object *obj)
>> > > >SysBusDevice *dev = SYS_BUS_DEVICE(obj);
>> > > >Exynos4210UartState *s = EXYNOS4210_UART(dev);
>> > > >
>> > > > -s->fifo_timeout_timer = timer_new_ns(QEMU_CLOCK_VIRTUAL,
>> > > > - exynos4210_uart_timeout_int,
>> > > > s);
>> > > > -s->wordtime = NANOSECONDS_PER_SECOND * 10 / 9600;
>> > >
>> > > Why are you moving s->wordtime from init() to realize()?
>> > >
>> > Hi Philippe, thanks for your reply!
>> >
>> > Because I found the variable wordtime is usually used with
>> > fifo_timeout_timer.
>> > Eg, they are used together in the exynos4210_uart_rx_timeout_set function.
>> >
>> > I didn't find anything wrong with wordtime in the realize().
>> > Does it have any other effects?
>>
>> IIUC when we use both init() and realize(), realize() should only contains
>> on code that consumes the object properties... But maybe the design is not
>> clear. Then why not move all the init() code to realize()?
>
> Normally I would recommend the opposite: delay as much as
> possible to realize(), to avoid unwanted side effects when (e.g.)
> running qom-list-properties.
Sadly, our documentation on device initialization and realization is
rather sparse, and developers are left guessing. Their guesses are
often based on what existing code does. Some of the existing code even
gets things right.
A few rules from the top of my head:
* Creating and immediately destroying an object must be safe and free of
side effects: initialization may only touch the object itself, and
finalization must clean up everything initialization creates.
* unrealize() must clean up everything realize() creates.
* Since initialization cannot fail, code that needs to fail gracefully
must live in realize().
* Since property values get set between initialization and realization,
code that uses property values must live in realize().
* Dynamic properties have to be created in initialization to be visible
in introspection.
> But as s->wordtime is a simple struct field (that we could even
> decide to expose to the outside as a read-only QOM property), it
> doesn't really matter. Personally, I would keep it where it is
> just to avoid churn.
Re: [PATCH] migration-test: fix some memleaks in migration-test
wrote: > From: Pan Nengyuan > > spotted by asan, 'check-qtest-aarch64' runs fail if sanitizers is enabled. > > Reported-by: Euler Robot > Signed-off-by: Pan Nengyuan Reviewed-by: Juan Quintela
Re: [PATCH] acpi: cpuhp: document CPHP_GET_CPU_ID_CMD command
On Wed, Feb 12, 2020 at 11:27:34PM +0100, Laszlo Ersek wrote:
> Michael,
>
> On 01/29/20 15:06, Igor Mammedov wrote:
> > Commit 3a61c8db9d25 introduced CPHP_GET_CPU_ID_CMD command but
> > did not sufficiently describe it. Fix it by adding missing command
> > documentation.
> >
> > Fixes: 3a61c8db9d25 ("acpi: cpuhp: add CPHP_GET_CPU_ID_CMD command")
> > Signed-off-by: Igor Mammedov
> > Reviewed-by: Laszlo Ersek
> > ---
> > docs/specs/acpi_cpu_hotplug.txt | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/docs/specs/acpi_cpu_hotplug.txt
> > b/docs/specs/acpi_cpu_hotplug.txt
> > index a8ce5e7..9bb22d1 100644
> > --- a/docs/specs/acpi_cpu_hotplug.txt
> > +++ b/docs/specs/acpi_cpu_hotplug.txt
> > @@ -94,6 +94,8 @@ write access:
> > register in QEMU
> > 2: following writes to 'Command data' register set OST status
> > register in QEMU
> > +3: following reads from 'Command data' and 'Command data 2'
> > return
> > + architecture specific CPU ID value for currently selected
> > CPU.
> > other values: reserved
> > [0x6-0x7] reserved
> > [0x8] Command data: (DWORD access)
> >
>
> can you please merge this?
>
> It's a docs patch, but 3a61c8db9d25 (noted in "Fixes:") had gone in
> through your tree.
>
> Thank you!
> Laszlo
Will do, thanks!
Re: [PATCH v2] hw/arm: ast2600: Wire up EHCI controllers
On Fri, 7 Feb 2020 at 17:45, Guenter Roeck wrote: > > Initialize EHCI controllers on AST2600 using the existing > TYPE_PLATFORM_EHCI. After this change, booting ast2600-evb > into Linux successfully instantiates a USB interface after > the necessary changes are made to its devicetree files. > > ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver > ehci-platform: EHCI generic platform driver > ehci-platform 1e6a3000.usb: EHCI Host Controller > ehci-platform 1e6a3000.usb: new USB bus registered, assigned bus number 1 > ehci-platform 1e6a3000.usb: irq 25, io mem 0x1e6a3000 > ehci-platform 1e6a3000.usb: USB 2.0 started, EHCI 1.00 > usb usb1: Manufacturer: Linux 5.5.0-09825-ga0802f2d0ef5-dirty ehci_hcd > usb 1-1: new high-speed USB device number 2 using ehci-platform > > Reviewed-by: Cédric Le Goater > Signed-off-by: Guenter Roeck Applied to target-arm.next, thanks. -- PMM
Re: [PATCH v2 fixed 13/16] numa: Teach ram block notifiers about resizable ram blocks
On Wed, 12 Feb 2020 at 14:44, David Hildenbrand wrote: > > We want to actually resize ram blocks (make everything between > used_length and max_length inaccessible) - however, not all ram block > notifiers will support that. Let's teach the notifier that ram blocks > are indeed resizable, but keep using max_size in the existing notifiers. > > Supply the max_size when adding and removing ram blocks. Also, notify on > resizes. Introduce a way to detect if any registered notifier does not > support resizes - ram_block_notifiers_support_resize() - which we can later > use to fallback to legacy handling if a registered notifier (esp., SEV and > HAX) does not support actual resizes. > > Cc: Richard Henderson > Cc: Paolo Bonzini > Cc: "Dr. David Alan Gilbert" > Cc: Eduardo Habkost > Cc: Marcel Apfelbaum > Cc: Stefano Stabellini > Cc: Anthony Perard > Cc: Paul Durrant > Cc: "Michael S. Tsirkin" > Cc: xen-de...@lists.xenproject.org > Cc: Igor Mammedov > Signed-off-by: David Hildenbrand Xen parts... Acked-by: Paul Durrant
Re: [PATCH v2] virtio: increase virtuqueue size for virtio-scsi and virtio-blk
On 13.02.2020 14:45, Stefan Hajnoczi wrote: On Thu, Feb 13, 2020 at 12:28:25PM +0300, Denis Plotnikov wrote: On 13.02.2020 12:08, Stefan Hajnoczi wrote: On Thu, Feb 13, 2020 at 11:08:35AM +0300, Denis Plotnikov wrote: On 12.02.2020 18:43, Stefan Hajnoczi wrote: On Tue, Feb 11, 2020 at 05:14:14PM +0300, Denis Plotnikov wrote: The goal is to reduce the amount of requests issued by a guest on 1M reads/writes. This rises the performance up to 4% on that kind of disk access pattern. The maximum chunk size to be used for the guest disk accessing is limited with seg_max parameter, which represents the max amount of pices in the scatter-geather list in one guest disk request. Since seg_max is virqueue_size dependent, increasing the virtqueue size increases seg_max, which, in turn, increases the maximum size of data to be read/write from a guest disk. More details in the original problem statment: https://lists.gnu.org/archive/html/qemu-devel/2017-12/msg03721.html Suggested-by: Denis V. Lunev Signed-off-by: Denis Plotnikov --- hw/block/virtio-blk.c | 4 ++-- hw/core/machine.c | 2 ++ hw/scsi/virtio-scsi.c | 4 ++-- 3 files changed, 6 insertions(+), 4 deletions(-) diff --git a/hw/block/virtio-blk.c b/hw/block/virtio-blk.c index 09f46ed85f..6df3a7a6df 100644 --- a/hw/block/virtio-blk.c +++ b/hw/block/virtio-blk.c @@ -914,7 +914,7 @@ static void virtio_blk_update_config(VirtIODevice *vdev, uint8_t *config) memset(, 0, sizeof(blkcfg)); virtio_stq_p(vdev, , capacity); virtio_stl_p(vdev, _max, - s->conf.seg_max_adjust ? s->conf.queue_size - 2 : 128 - 2); + s->conf.seg_max_adjust ? s->conf.queue_size - 2 : 256 - 2); This value must not change on older machine types. Yes, that's true, but .. So does this patch need to turn seg-max-adjust *on* in hw_compat_4_2 so that old machine types get 126 instead of 254? If we set seg-max-adjust "on" in older machine types, the setups using them and having queue_sizes set , for example, 1024 will also set seg_max to 1024 - 2 which isn't the expected behavior: older mt didn't change seg_max in that case and stuck with 128 - 2. So, should we, instead, leave the default 128 - 2, for seg_max? Argh! Good point :-). How about a seg_max_default property that is initialized to 254 for modern machines and 126 to old machines? Hmm, but we'll achieve the same but with more code changes, don't we? 254 is because the queue-size is 256. We gonna leave 128-2 for older machine types just for not breaking anything. All other seg_max adjustment is provided by seg_max_adjust which is "on" by default in modern machine types. to summarize: modern mt defaults: seg_max_adjust = on queue_size = 256 => default seg_max = 254 => changing queue-size will change seg_max = queue_size - 2 old mt defaults: seg_max_adjust = off queue_size = 128 => default seg_max = 126 => changing queue-size won't change seg_max, it's always = 126 like it was before You're right! The only strange case is a modern machine type with seg_max_adjust=off, where queue_size will be 256 but seg_max will be 126. But no user would want to disable seg_max_adjust, so it's okay. I agree with you that the line of code can remain unchanged: /* * Only old machine types use seg_max_adjust=off and there the default * value of queue_size is 128. */ virtio_stl_p(vdev, _max, s->conf.seg_max_adjust ? s->conf.queue_size - 2 : 128 - 2); Stefan Ok, I'll resend the patch sortly Thanks! Denis
Re: [PATCH v2 1/2] target/arm: Fix select for aa64_va_parameters_both
On Tue, 11 Feb 2020 at 19:42, Richard Henderson
wrote:
>
> Select should always be 0 for a regime with one range.
>
> Signed-off-by: Richard Henderson
This change makes sense, and matches what aa32_va_parameters() does,
but I think we need to update some of the callsites.
(1) In get_phys_addr_lpae() we have the check:
if (-top_bits != param.select || (param.select && !ttbr1_valid)) {
where ttbr1_valid is the return value of (effectively)
aarch64 ? regime_has_2_ranges() : (el != 2);
but I think it's no longer possible to get here with param.select == 1
and !ttbr1_valid, so this becomes a dead check.
(Side note, could we pull "ttbr1_valid = regime_has_2_ranges(mmu_idx);"
out of the "if (aarch64) {...} else {...}" ? -- I think it works for
aarch32 too, right?)
(2) in pauth_original_ptr() we do
uint64_t extfield = -param.select;
but in the pseudocode Auth() function the extfield is unconditionally
calculated based on bit 55 of the address, regardless of whether
the regime has 1 range or 2. So I think this code can't use
param.select any more but should simply pull out and replicate
bit 55 of its 'ptr' argument, now that param.select is not simply
the value of bit 55.
Change 1 would need to be done after this patch and change 2 before it.
thanks
-- PMM
Re: [PATCH v2 1/2] target/arm: Fix select for aa64_va_parameters_both
On Thu, 13 Feb 2020 at 13:12, Peter Maydell wrote: > > On Tue, 11 Feb 2020 at 19:42, Richard Henderson > wrote: > > > > Select should always be 0 for a regime with one range. > > > > Signed-off-by: Richard Henderson > > This change makes sense, and matches what aa32_va_parameters() does, > but I think we need to update some of the callsites. Assuming those changes are done in separate patches, for this patch itself: Reviewed-by: Peter Maydell thanks -- PMM
[RFC 1/2] arm: acpi: pci-expender-bus: Make arm to support PXB-PCIE
From: miaoyubo
Currently virt machine is not supported by pxb-pcie,
and only one main host bridge described in ACPI tables.
Under this circumstance, different io numas for differnt devices
is not possible, in order to present io numas to the guest,
especially for host pssthrough devices. PXB-PCIE is supproted
by arm and certain resource is allocated for each pxb-pcie
in acpi table.
Signed-off-by: miaoyubo
---
hw/arm/virt-acpi-build.c | 234 +--
hw/pci-host/gpex.c | 4 +
include/hw/arm/virt.h| 1 +
3 files changed, 228 insertions(+), 11 deletions(-)
diff --git a/hw/arm/virt-acpi-build.c b/hw/arm/virt-acpi-build.c
index bd5f771e9b..2e449d0098 100644
--- a/hw/arm/virt-acpi-build.c
+++ b/hw/arm/virt-acpi-build.c
@@ -49,6 +49,8 @@
#include "kvm_arm.h"
#include "migration/vmstate.h"
+#include "hw/arm/virt.h"
+#include "hw/pci/pci_bus.h"
#define ARM_SPI_BASE 32
static void acpi_dsdt_add_cpus(Aml *scope, int smp_cpus)
@@ -152,20 +154,227 @@ static void acpi_dsdt_add_virtio(Aml *scope,
}
static void acpi_dsdt_add_pci(Aml *scope, const MemMapEntry *memmap,
- uint32_t irq, bool use_highmem, bool
highmem_ecam)
+ uint32_t irq, bool use_highmem, bool
highmem_ecam,
+ VirtMachineState *vms)
{
int ecam_id = VIRT_ECAM_ID(highmem_ecam);
-Aml *method, *crs, *ifctx, *UUID, *ifctx1, *elsectx, *buf;
+Aml *method, *crs, *ifctx, *UUID, *ifctx1, *elsectx, *buf, *dev;
int i, bus_no;
+int count = 0;
hwaddr base_mmio = memmap[VIRT_PCIE_MMIO].base;
hwaddr size_mmio = memmap[VIRT_PCIE_MMIO].size;
hwaddr base_pio = memmap[VIRT_PCIE_PIO].base;
hwaddr size_pio = memmap[VIRT_PCIE_PIO].size;
hwaddr base_ecam = memmap[ecam_id].base;
hwaddr size_ecam = memmap[ecam_id].size;
+/*
+ * 0x60 would be enough for pxb device
+ * if it is too small, there is no enough space
+ * for a pcie device plugged in a pcie-root port
+ */
+hwaddr size_addr = 0x60;
+hwaddr size_io = 0x4000;
int nr_pcie_buses = size_ecam / PCIE_MMCFG_SIZE_MIN;
+int root_bus_limit = 0xFF;
+PCIBus *bus = NULL;
+bus = VIRT_MACHINE(vms)->bus;
+
+if (bus) {
+QLIST_FOREACH(bus, >child, sibling) {
+uint8_t bus_num = pci_bus_num(bus);
+uint8_t numa_node = pci_bus_numa_node(bus);
+
+if (!pci_bus_is_root(bus)) {
+continue;
+}
+if (bus_num < root_bus_limit) {
+root_bus_limit = bus_num - 1;
+}
+count++;
+dev = aml_device("PC%.02X", bus_num);
+aml_append(dev, aml_name_decl("_HID", aml_string("PNP0A08")));
+aml_append(dev, aml_name_decl("_CID", aml_string("PNP0A03")));
+aml_append(dev, aml_name_decl("_ADR", aml_int(0)));
+aml_append(dev, aml_name_decl("_CCA", aml_int(1)));
+aml_append(dev, aml_name_decl("_SEG", aml_int(0)));
+aml_append(dev, aml_name_decl("_BBN", aml_int(bus_num)));
+aml_append(dev, aml_name_decl("_UID", aml_int(bus_num)));
+aml_append(dev, aml_name_decl("_STR", aml_unicode("pxb Device")));
+if (numa_node != NUMA_NODE_UNASSIGNED) {
+method = aml_method("_PXM", 0, AML_NOTSERIALIZED);
+aml_append(method, aml_return(aml_int(numa_node)));
+aml_append(dev, method);
+}
+/* Declare the PCI Routing Table. */
+Aml *rt_pkg = aml_varpackage(nr_pcie_buses * PCI_NUM_PINS);
+for (bus_no = 0; bus_no < nr_pcie_buses; bus_no++) {
+for (i = 0; i < PCI_NUM_PINS; i++) {
+int gsi = (i + bus_no) % (PCI_NUM_PINS);
+Aml *pkg = aml_package(4);
+aml_append(pkg, aml_int((bus_no << 16) | 0x));
+aml_append(pkg, aml_int(i));
+aml_append(pkg, aml_name("GSI%d", gsi));
+aml_append(pkg, aml_int(0));
+aml_append(rt_pkg, pkg);
+}
+}
+aml_append(dev, aml_name_decl("_PRT", rt_pkg));
+
+for (i = 0; i < PCI_NUM_PINS; i++) {
+uint32_t irqs = irq + i;
+Aml *dev_gsi = aml_device("GSI%d", i);
+aml_append(dev_gsi, aml_name_decl("_HID",
+ aml_string("PNP0C0F")));
+aml_append(dev_gsi, aml_name_decl("_UID", aml_int(0)));
+crs = aml_resource_template();
+aml_append(crs,
+ aml_interrupt(AML_CONSUMER, AML_LEVEL,
+ AML_ACTIVE_HIGH,
+ AML_EXCLUSIVE, , 1));
+aml_append(dev_gsi, aml_name_decl("_PRS", crs));
+crs = aml_resource_template();
+aml_append(crs,
+
Re: [PATCH] tracing: only allow -trace to override -D if set
On Wed, Feb 12, 2020 at 11:31:00PM +0100, Philippe Mathieu-Daudé wrote: > On 2/12/20 4:34 PM, Stefan Hajnoczi wrote: > > On Tue, Feb 11, 2020 at 11:10:54AM +, Alex Bennée wrote: > > > Otherwise any -D settings the user may have made get ignored. > > > > > > Signed-off-by: Alex Bennée > > > --- > > > trace/control.c | 11 --- > > > 1 file changed, 8 insertions(+), 3 deletions(-) > > > > Thanks, applied to my tracing tree: > > https://github.com/stefanha/qemu/commits/tracing > > If possible, please add 'Fixes: e144a605a'. Done! Stefan signature.asc Description: PGP signature
Re: [PATCH v15 8/9] hw/arm/virt: Add the virtio-iommu device tree mappings
Hi Peter, Michael,
On 2/11/20 6:31 PM, Auger Eric wrote:
> Hi Peter,
>
> On 2/11/20 4:00 PM, Peter Maydell wrote:
>> On Sat, 8 Feb 2020 at 12:01, Eric Auger wrote:
>>>
>>> Adds the "virtio,pci-iommu" node in the host bridge node and
>>> the RID mapping, excluding the IOMMU RID.
>>>
>>> This is done in the virtio-iommu-pci hotplug handler which
>>> gets called only if no firmware is loaded or if -no-acpi is
>>> passed on the command line. As non DT integration is
>>> not yet supported by the kernel we must make sure we
>>> are in DT mode. This limitation will be removed as soon
>>> as the topology description feature gets supported.
>>>
>>> Signed-off-by: Eric Auger
>>>
>>> +static void create_virtio_iommu(VirtMachineState *vms, Error **errp)
>>> +{
>>> +const char compat[] = "virtio,pci-iommu";
>>> +uint16_t bdf = vms->virtio_iommu_bdf;
>>> +char *node;
>>> +
>>> +vms->iommu_phandle = qemu_fdt_alloc_phandle(vms->fdt);
>>> +
>>> +node = g_strdup_printf("%s/virtio_iommu@%d", vms->pciehb_nodename,
>>> bdf);
>>> +qemu_fdt_add_subnode(vms->fdt, node);
>>> +qemu_fdt_setprop(vms->fdt, node, "compatible", compat, sizeof(compat));
>>> +qemu_fdt_setprop_sized_cells(vms->fdt, node, "reg",
>>> + 1, bdf << 8, 1, 0, 1, 0,
>>> + 1, 0, 1, 0);
>>> +
>>> +qemu_fdt_setprop_cell(vms->fdt, node, "#iommu-cells", 1);
>>> +qemu_fdt_setprop_cell(vms->fdt, node, "phandle", vms->iommu_phandle);
>>> +g_free(node);
>>> +
>>> +qemu_fdt_setprop_cells(vms->fdt, vms->pciehb_nodename, "iommu-map",
>>> + 0x0, vms->iommu_phandle, 0x0, bdf,
>>> + bdf + 1, vms->iommu_phandle, bdf + 1, 0x -
>>> bdf);
>>> +}
>>
>> This function name implies that we're creating the IOMMU device
>> here (which would be a weird thing to do in a hotplug callback
>> for some other device), but it looks like we're only adding
>> device tree nodes ?
> yes the actual iommu device is created through the -device option. I can
> rename into create_iommu_dt_bindings
So I renamed it into create_virtio_iommu_dt_bindings()
>>
>> Given that we write the FDT blob into the guest RAM on bootup,
>> how does making changes to it here on hotplug (which I assume
>> to be 'after boot, whenever the user hot-plugs something') work?
>
> the virtio-iommu is not supposed to be hotplugged but rather
> cold-plugged. I use this hotplug mechanism to detect its presence and
> add the related dt mappings. Maybe I can add a check to detect if the
> bootup is over?
I added in virtio-iommu-pci virtio_iommu_pci_class_init()
dc->hotpluggable = false;
As far as I understand this makes the virtio-iommu-pci device not
hotpluggable (same is used for intel-iommu):
(QEMU) device_add id=hot0 driver=virtio-iommu-pci bus=head.0 addr=4
{"error": {"class": "GenericError", "desc": "Parameter 'driver' expects
pluggable device type"}}
Is that OK?
Thanks
Eric
>
> Thoughts?
>
> Eric
>>
>> thanks
>> -- PMM
>>
>
>
[PATCH] uapi: fix userspace breakage, use __BITS_PER_LONG for swap
QEMU has a funny new build error message when I use the upstream kernel headers:
CC block/file-posix.o
In file included from /home/cborntra/REPOS/qemu/include/qemu/timer.h:4,
from /home/cborntra/REPOS/qemu/include/qemu/timed-average.h:29,
from /home/cborntra/REPOS/qemu/include/block/accounting.h:28,
from /home/cborntra/REPOS/qemu/include/block/block_int.h:27,
from /home/cborntra/REPOS/qemu/block/file-posix.c:30:
/usr/include/linux/swab.h: In function ‘__swab’:
/home/cborntra/REPOS/qemu/include/qemu/bitops.h:20:34: error: "sizeof" is not
defined, evaluates to 0 [-Werror=undef]
20 | #define BITS_PER_LONG (sizeof (unsigned long) * BITS_PER_BYTE)
| ^~
/home/cborntra/REPOS/qemu/include/qemu/bitops.h:20:41: error: missing binary
operator before token "("
20 | #define BITS_PER_LONG (sizeof (unsigned long) * BITS_PER_BYTE)
| ^
cc1: all warnings being treated as errors
make: *** [/home/cborntra/REPOS/qemu/rules.mak:69: block/file-posix.o] Error 1
rm tests/qemu-iotests/socket_scm_helper.o
This was triggered by commit d5767057c9a ("uapi: rename ext2_swab() to swab()
and share globally in swab.h")
This patch is doing
+#include
but it uses BITS_PER_LONG.
The kernel file asm/bitsperlong.h provide only __BITS_PER_LONG.
Let us use the __ variant in swap.h
Fixes: d5767057c9a ("uapi: rename ext2_swab() to swab() and share globally in
swab.h")
Cc: Yury Norov
Cc: Allison Randal
Cc: Joe Perches
Cc: Thomas Gleixner
Cc: William Breathitt Gray
Signed-off-by: Christian Borntraeger
---
include/uapi/linux/swab.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/uapi/linux/swab.h b/include/uapi/linux/swab.h
index fa7f97da5b76..7272f85d6d6a 100644
--- a/include/uapi/linux/swab.h
+++ b/include/uapi/linux/swab.h
@@ -135,9 +135,9 @@ static inline __attribute_const__ __u32 __fswahb32(__u32
val)
static __always_inline unsigned long __swab(const unsigned long y)
{
-#if BITS_PER_LONG == 64
+#if __BITS_PER_LONG == 64
return __swab64(y);
-#else /* BITS_PER_LONG == 32 */
+#else /* __BITS_PER_LONG == 32 */
return __swab32(y);
#endif
}
--
2.24.1
Re: [PATCH RFC 01/14] migration: add the 'migrate_use_rdma_pin_all' function
Zhimin Feng wrote: > Signed-off-by: Zhimin Feng Reviewed-by: Juan Quintela
[PATCH v3 0/9] linux-user: Update syscall numbers to kernel 5.5 level
From: Aleksandar Markovic v2->v3: - corrected number of arguments for two mips syscalls v1->v2: - corrected mips parts based on Laurent's review This series is a spin-off of another larger linux-user series that become too large to handle, hence these patches related to syscall numbers are now in this, separate, series. This series covers updating syscall numbers defined in the following files: - linux-user/alpha/syscall_nr.h - linux-user/arm/syscall_nr.h - linux-user/m68k/syscall_nr.h - linux-user/microblaze/syscall_nr.h - linux-user/mips/cpu_loop.c - linux-user/mips/syscall_nr.h - linux-user/mips64/syscall_nr.h - linux-user/sh4/syscall_nr.h - linux-user/x86_64/syscall_nr.h - linux-user/xtensa/syscall_nr.h -- Aleksandar Markovic (9): linux-user: alpha: Update syscall numbers to kernel 5.5 level linux-user: arm: Update syscall numbers to kernel 5.5 level linux-user: m68k: Update syscall numbers to kernel 5.5 level linux-user: microblaze: Update syscall numbers to kernel 5.5 level linux-user: mips: Update syscall numbers to kernel 5.5 level linux-user: sh4: Update syscall numbers to kernel 5.5 level linux-user: x86_64: Update syscall numbers to kernel 5.5 level linux-user: xtensa: Update syscall numbers to kernel 5.5 level linux-user: xtensa: Remove unused constant TARGET_NR_syscall_count linux-user/alpha/syscall_nr.h | 35 linux-user/arm/syscall_nr.h| 44 linux-user/m68k/syscall_nr.h | 50 ++- linux-user/microblaze/syscall_nr.h | 45 + linux-user/mips/syscall_nr.h | 45 + linux-user/mips64/syscall_nr.h | 50 ++- linux-user/sh4/syscall_nr.h| 48 ++ linux-user/x86_64/syscall_nr.h | 24 +++ linux-user/xtensa/syscall_nr.h | 36 - linux-user/mips/cpu_loop.c | 83 +- 10 files changed, 454 insertions(+), 6 deletions(-) -- 2.7.4
[PATCH v3 3/9] linux-user: m68k: Update syscall numbers to kernel 5.5 level
From: Aleksandar Markovic Update m68k syscall numbers based on Linux kernel v5.5. CC: Laurent Vivier Signed-off-by: Aleksandar Markovic Reviewed-by: Laurent Vivier --- linux-user/m68k/syscall_nr.h | 50 +++- 1 file changed, 49 insertions(+), 1 deletion(-) diff --git a/linux-user/m68k/syscall_nr.h b/linux-user/m68k/syscall_nr.h index d33d8e9..01aee34 100644 --- a/linux-user/m68k/syscall_nr.h +++ b/linux-user/m68k/syscall_nr.h @@ -382,5 +382,53 @@ #define TARGET_NR_copy_file_range 376 #define TARGET_NR_preadv2 377 #define TARGET_NR_pwritev2 378 - +#define TARGET_NR_statx 379 +#define TARGET_NR_seccomp 380 +#define TARGET_NR_pkey_mprotect 381 +#define TARGET_NR_pkey_alloc382 +#define TARGET_NR_pkey_free 383 +#define TARGET_NR_rseq 384 +/* room for arch specific calls */ +#define TARGET_NR_semget393 +#define TARGET_NR_semctl394 +#define TARGET_NR_shmget395 +#define TARGET_NR_shmctl396 +#define TARGET_NR_shmat 397 +#define TARGET_NR_shmdt 398 +#define TARGET_NR_msgget399 +#define TARGET_NR_msgsnd400 +#define TARGET_NR_msgrcv401 +#define TARGET_NR_msgctl402 +#define TARGET_NR_clock_gettime64 403 +#define TARGET_NR_clock_settime64 404 +#define TARGET_NR_clock_adjtime64 405 +#define TARGET_NR_clock_getres_time64 406 +#define TARGET_NR_clock_nanosleep_time64 407 +#define TARGET_NR_timer_gettime64 408 +#define TARGET_NR_timer_settime64 409 +#define TARGET_NR_timerfd_gettime64 410 +#define TARGET_NR_timerfd_settime64 411 +#define TARGET_NR_utimensat_time64 412 +#define TARGET_NR_pselect6_time64 413 +#define TARGET_NR_ppoll_time64 414 +#define TARGET_NR_io_pgetevents_time64 416 +#define TARGET_NR_recvmmsg_time64 417 +#define TARGET_NR_mq_timedsend_time64 418 +#define TARGET_NR_mq_timedreceive_time64 419 +#define TARGET_NR_semtimedop_time64 420 +#define TARGET_NR_rt_sigtimedwait_time64 421 +#define TARGET_NR_futex_time64 422 +#define TARGET_NR_sched_rr_get_interval_time64 423 +#define TARGET_NR_pidfd_send_signal 424 +#define TARGET_NR_io_uring_setup425 +#define TARGET_NR_io_uring_enter426 +#define TARGET_NR_io_uring_register 427 +#define TARGET_NR_open_tree 428 +#define TARGET_NR_move_mount429 +#define TARGET_NR_fsopen430 +#define TARGET_NR_fsconfig 431 +#define TARGET_NR_fsmount 432 +#define TARGET_NR_fspick433 +#define TARGET_NR_pidfd_open434 +/* 435 reserved for clone3 */ #endif -- 2.7.4
[PATCH v3 1/9] linux-user: alpha: Update syscall numbers to kernel 5.5 level
From: Aleksandar Markovic Update alpha syscall numbers based on Linux kernel v5.5. CC: Richard Henderson Signed-off-by: Aleksandar Markovic Reviewed-by: Laurent Vivier --- linux-user/alpha/syscall_nr.h | 35 +++ 1 file changed, 35 insertions(+) diff --git a/linux-user/alpha/syscall_nr.h b/linux-user/alpha/syscall_nr.h index 2e5541b..c29fc17 100644 --- a/linux-user/alpha/syscall_nr.h +++ b/linux-user/alpha/syscall_nr.h @@ -453,5 +453,40 @@ #define TARGET_NR_getrandom 511 #define TARGET_NR_memfd_create 512 #define TARGET_NR_execveat 513 +#define TARGET_NR_seccomp 514 +#define TARGET_NR_bpf 515 +#define TARGET_NR_userfaultfd 516 +#define TARGET_NR_membarrier517 +#define TARGET_NR_mlock2518 +#define TARGET_NR_copy_file_range 519 +#define TARGET_NR_preadv2 520 +#define TARGET_NR_pwritev2 521 +#define TARGET_NR_statx 522 +#define TARGET_NR_io_pgetevents 523 +#define TARGET_NR_pkey_mprotect 524 +#define TARGET_NR_pkey_alloc525 +#define TARGET_NR_pkey_free 526 +#define TARGET_NR_rseq 527 +#define TARGET_NR_statfs64 528 +#define TARGET_NR_fstatfs64 529 +#define TARGET_NR_getegid 530 +#define TARGET_NR_geteuid 531 +#define TARGET_NR_getppid 532 +/* + * all other architectures have common numbers for new syscall, alpha + * is the exception. + */ +#define TARGET_NR_pidfd_send_signal 534 +#define TARGET_NR_io_uring_setup535 +#define TARGET_NR_io_uring_enter536 +#define TARGET_NR_io_uring_register 537 +#define TARGET_NR_open_tree 538 +#define TARGET_NR_move_mount539 +#define TARGET_NR_fsopen540 +#define TARGET_NR_fsconfig 541 +#define TARGET_NR_fsmount 542 +#define TARGET_NR_fspick543 +#define TARGET_NR_pidfd_open544 +/* 545 reserved for clone3 */ #endif -- 2.7.4
Re: [PATCH v3 0/9] linux-user: Update syscall numbers to kernel 5.5 level
Le 13/02/2020 à 13:29, Aleksandar Markovic a écrit : > From: Aleksandar Markovic > > v2->v3: > > - corrected number of arguments for two mips syscalls > > v1->v2: > > - corrected mips parts based on Laurent's review > > This series is a spin-off of another larger linux-user series > that become too large to handle, hence these patches related to > syscall numbers are now in this, separate, series. > > This series covers updating syscall numbers defined in the following > files: > > - linux-user/alpha/syscall_nr.h > - linux-user/arm/syscall_nr.h > - linux-user/m68k/syscall_nr.h > - linux-user/microblaze/syscall_nr.h > - linux-user/mips/cpu_loop.c > - linux-user/mips/syscall_nr.h > - linux-user/mips64/syscall_nr.h > - linux-user/sh4/syscall_nr.h > - linux-user/x86_64/syscall_nr.h > - linux-user/xtensa/syscall_nr.h > > -- > > Aleksandar Markovic (9): > linux-user: alpha: Update syscall numbers to kernel 5.5 level > linux-user: arm: Update syscall numbers to kernel 5.5 level > linux-user: m68k: Update syscall numbers to kernel 5.5 level > linux-user: microblaze: Update syscall numbers to kernel 5.5 level > linux-user: mips: Update syscall numbers to kernel 5.5 level > linux-user: sh4: Update syscall numbers to kernel 5.5 level > linux-user: x86_64: Update syscall numbers to kernel 5.5 level > linux-user: xtensa: Update syscall numbers to kernel 5.5 level > linux-user: xtensa: Remove unused constant TARGET_NR_syscall_count > > linux-user/alpha/syscall_nr.h | 35 > linux-user/arm/syscall_nr.h| 44 > linux-user/m68k/syscall_nr.h | 50 ++- > linux-user/microblaze/syscall_nr.h | 45 + > linux-user/mips/syscall_nr.h | 45 + > linux-user/mips64/syscall_nr.h | 50 ++- > linux-user/sh4/syscall_nr.h| 48 ++ > linux-user/x86_64/syscall_nr.h | 24 +++ > linux-user/xtensa/syscall_nr.h | 36 - > linux-user/mips/cpu_loop.c | 83 > +- > 10 files changed, 454 insertions(+), 6 deletions(-) > I've applied the series to my linux-user for 5.0 branch. Thanks, Laurent
[PULL 5/6] migration-test: fix some memleaks in migration-test
From: Pan Nengyuan
spotted by asan, 'check-qtest-aarch64' runs fail if sanitizers is enabled.
Reported-by: Euler Robot
Signed-off-by: Pan Nengyuan
Reviewed-by: Juan Quintela
Reviewed-by: Laurent Vivier
Signed-off-by: Juan Quintela
---
tests/qtest/migration-test.c | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/tests/qtest/migration-test.c b/tests/qtest/migration-test.c
index a78ac0c7da..ccf313f288 100644
--- a/tests/qtest/migration-test.c
+++ b/tests/qtest/migration-test.c
@@ -498,11 +498,13 @@ static int test_migrate_start(QTestState **from,
QTestState **to,
const char *arch = qtest_get_arch();
const char *machine_opts = NULL;
const char *memory_size;
+int ret = 0;
if (args->use_shmem) {
if (!g_file_test("/dev/shm", G_FILE_TEST_IS_DIR)) {
g_test_skip("/dev/shm is not supported");
-return -1;
+ret = -1;
+goto out;
}
}
@@ -611,8 +613,9 @@ static int test_migrate_start(QTestState **from, QTestState
**to,
g_free(shmem_path);
}
+out:
migrate_start_destroy(args);
-return 0;
+return ret;
}
static void test_migrate_end(QTestState *from, QTestState *to, bool test_dest)
@@ -1134,6 +1137,8 @@ static void test_validate_uuid(void)
{
MigrateStart *args = migrate_start_new();
+g_free(args->opts_source);
+g_free(args->opts_target);
args->opts_source = g_strdup("-uuid ----");
args->opts_target = g_strdup("-uuid ----");
do_test_validate_uuid(args, false);
@@ -1143,6 +1148,8 @@ static void test_validate_uuid_error(void)
{
MigrateStart *args = migrate_start_new();
+g_free(args->opts_source);
+g_free(args->opts_target);
args->opts_source = g_strdup("-uuid ----");
args->opts_target = g_strdup("-uuid ----");
args->hide_stderr = true;
@@ -1153,6 +1160,7 @@ static void test_validate_uuid_src_not_set(void)
{
MigrateStart *args = migrate_start_new();
+g_free(args->opts_target);
args->opts_target = g_strdup("-uuid ----");
args->hide_stderr = true;
do_test_validate_uuid(args, false);
@@ -1162,6 +1170,7 @@ static void test_validate_uuid_dst_not_set(void)
{
MigrateStart *args = migrate_start_new();
+g_free(args->opts_source);
args->opts_source = g_strdup("-uuid ----");
args->hide_stderr = true;
do_test_validate_uuid(args, false);
@@ -1380,6 +1389,7 @@ static void test_multifd_tcp_cancel(void)
" 'arguments': { 'uri': 'tcp:127.0.0.1:0' }}");
qobject_unref(rsp);
+g_free(uri);
uri = migrate_get_socket_address(to2, "socket-address");
wait_for_migration_status(from, "cancelled", NULL);
--
2.24.1
[PULL 6/6] git: Make submodule check only needed modules
If one is compiling more than one tree from the same source, it is possible that they need different submodules. Change the check to see that all modules that we are interested in are updated, discarding the ones that we don't care about. Signed-off-by: Juan Quintela --- v1->v2: patchw insists in not using modules --- scripts/git-submodule.sh | 12 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/scripts/git-submodule.sh b/scripts/git-submodule.sh index 98ca0f2737..65ed877aef 100755 --- a/scripts/git-submodule.sh +++ b/scripts/git-submodule.sh @@ -59,10 +59,14 @@ status) fi test -f "$substat" || exit 1 -CURSTATUS=$($GIT submodule status $modules) -OLDSTATUS=$(cat $substat) -test "$CURSTATUS" = "$OLDSTATUS" -exit $? +for module in $modules; do +CURSTATUS=$($GIT submodule status $module) +OLDSTATUS=$(cat $substat | grep $module) +if test "$CURSTATUS" != "$OLDSTATUS"; then +exit 1 +fi +done +exit 0 ;; update) if test -z "$maybe_modules" -- 2.24.1
[PULL 1/6] migration: Maybe VM is paused when migration is cancelled
From: Zhimin Feng
If the migration is cancelled when it is in the completion phase,
the migration state is set to MIGRATION_STATUS_CANCELLING.
The VM maybe wait for the 'pause_sem' semaphore in migration_maybe_pause
function, so that VM always is paused.
Reported-by: Euler Robot
Signed-off-by: Zhimin Feng
Reviewed-by: Juan Quintela
Signed-off-by: Juan Quintela
---
migration/migration.c | 24
1 file changed, 16 insertions(+), 8 deletions(-)
diff --git a/migration/migration.c b/migration/migration.c
index 3a21a4686c..1ca6be2323 100644
--- a/migration/migration.c
+++ b/migration/migration.c
@@ -2797,14 +2797,22 @@ static int migration_maybe_pause(MigrationState *s,
/* This block intentionally left blank */
}
-qemu_mutex_unlock_iothread();
-migrate_set_state(>state, *current_active_state,
- MIGRATION_STATUS_PRE_SWITCHOVER);
-qemu_sem_wait(>pause_sem);
-migrate_set_state(>state, MIGRATION_STATUS_PRE_SWITCHOVER,
- new_state);
-*current_active_state = new_state;
-qemu_mutex_lock_iothread();
+/*
+ * If the migration is cancelled when it is in the completion phase,
+ * the migration state is set to MIGRATION_STATUS_CANCELLING.
+ * So we don't need to wait a semaphore, otherwise we would always
+ * wait for the 'pause_sem' semaphore.
+ */
+if (s->state != MIGRATION_STATUS_CANCELLING) {
+qemu_mutex_unlock_iothread();
+migrate_set_state(>state, *current_active_state,
+ MIGRATION_STATUS_PRE_SWITCHOVER);
+qemu_sem_wait(>pause_sem);
+migrate_set_state(>state, MIGRATION_STATUS_PRE_SWITCHOVER,
+ new_state);
+*current_active_state = new_state;
+qemu_mutex_lock_iothread();
+}
return s->state == new_state ? 0 : -EINVAL;
}
--
2.24.1
Re: [PATCH v3 03/13] hw/arm/raspi: Extract the version from the board revision
On Sat, 8 Feb 2020 at 16:57, Philippe Mathieu-Daudé wrote:
>
> The board revision encode the board version. Add a helper
> to extract the version, and use it.
>
> Signed-off-by: Philippe Mathieu-Daudé
> ---
> hw/arm/raspi.c | 31 +++
> 1 file changed, 27 insertions(+), 4 deletions(-)
>
> diff --git a/hw/arm/raspi.c b/hw/arm/raspi.c
> index 818146fdbb..f285e2988f 100644
> --- a/hw/arm/raspi.c
> +++ b/hw/arm/raspi.c
> @@ -16,6 +16,7 @@
> #include "qapi/error.h"
> #include "cpu.h"
> #include "hw/arm/bcm2836.h"
> +#include "hw/registerfields.h"
> #include "qemu/error-report.h"
> #include "hw/boards.h"
> #include "hw/loader.h"
> @@ -37,6 +38,28 @@ typedef struct RasPiState {
> MemoryRegion ram;
> } RasPiState;
>
> +/*
> + * Board revision codes:
> + * www.raspberrypi.org/documentation/hardware/raspberrypi/revision-codes/
> + */
> +FIELD(REV_CODE, REVISION, 0, 4);
> +FIELD(REV_CODE, TYPE, 4, 8);
> +FIELD(REV_CODE, PROCESSOR, 12, 4);
> +FIELD(REV_CODE, MANUFACTURER, 16, 4);
> +FIELD(REV_CODE, MEMORY_SIZE, 20, 3);
> +FIELD(REV_CODE, STYLE, 23, 1);
> +
> +static int board_processor_id(uint32_t board_rev)
> +{
> +assert(FIELD_EX32(board_rev, REV_CODE, STYLE)); /* Only new style */
> +return FIELD_EX32(board_rev, REV_CODE, PROCESSOR);
> +}
> +
> +static int board_version(uint32_t board_rev)
> +{
> +return board_processor_id(board_rev) + 1;
This uses the 'processor' field, which basically means the SoC
(0 for BCM2835, 1 for BCM2836, 2 for BCMM2837, 3 for BCM2711).
We use 'version' for a wider range of things in our code here:
* do we need SMP setup?
* which address does the firmware image go?
* do we need to set up SMC vectors so no-op SMC works?
* as well as "which SoC do we instantiate"?
We think of 'version' as basically "raspi 2 or 3?", but
according to the table in your url you can get a version of
the raspi 2b with a BCM2837 SoC, which confuses this idea.
Anyway, since what we have in this patch works OK for the set
of board models we support, I'm happy to leave the patch as-is,
but maybe worth checking and considering what in our code we
should really be making conditional on "actually the SoC type"
and what on something else...
thanks
-- PMM
Re: [PULL 00/10] Ui 20200212 patches
On Wed, 12 Feb 2020 at 16:18, Gerd Hoffmann wrote: > > The following changes since commit e18e5501d8ac692d32657a3e1ef545b14e72b730: > > Merge remote-tracking branch > 'remotes/dgilbert-gitlab/tags/pull-virtiofs-20200210' into staging > (2020-02-10 18:09:14 +) > > are available in the Git repository at: > > git://git.kraxel.org/qemu tags/ui-20200212-pull-request > > for you to fetch changes up to 483644c25b932360018d15818d8bcd8c85ba70b8: > > ui/cocoa: Drop workarounds for pre-10.12 OSX (2020-02-12 13:27:08 +0100) > > > gtk: refresh rate fix. > cocoa: drop pre-10.12 support. > ui: rework show-cursor option. > Applied, thanks. Please update the changelog at https://wiki.qemu.org/ChangeLog/5.0 for any user-visible changes. -- PMM
Re: [PATCH v9 01/23] checkpatch: replace vl.c in the top of repo check
On Tue, Feb 11, 2020 at 03:34:48PM -0500, Alexander Bulekov wrote:
> 524b4c2c5c moves vl.c into softmmu/ , breaking the checkpatch
524b4c2c5c is a local git sha1. That commit will have a different sha1
when applied to qemu.git/master. Saying "The next patch" instead would
be fine.
However, this patch leaves the tree in a state where checkpatch.pl will
fail because softmmu/ doesn't exist yet! Please squash this patch into
the next commit instead.
I guess you kept it separate because changing checkpatch.pl can be
thought of as a separate change. However, they two need to happen in a
single step in order for checkpatch.pl to function correctly at each
commit. Therefore it's appropriate to combine them into a single
commit.
> top-of-kernel-tree check. Replace with checks for softmmu and linux-user
>
> Signed-off-by: Alexander Bulekov
> ---
> scripts/checkpatch.pl | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
> index ce43a306f8..2e2273b8a3 100755
> --- a/scripts/checkpatch.pl
> +++ b/scripts/checkpatch.pl
> @@ -462,7 +462,7 @@ sub top_of_kernel_tree {
> my @tree_check = (
> "COPYING", "MAINTAINERS", "Makefile",
> "README.rst", "docs", "VERSION",
> - "vl.c"
> + "softmmu", "linux-user"
> );
>
> foreach my $check (@tree_check) {
> --
> 2.25.0
>
signature.asc
Description: PGP signature
[PULL 2/5] linux-user: cleanup signal.c
No functional changes. Prepare the field for future fixes.
Remove memset(.., 0, ...) that is useless on a static array
Signed-off-by: Laurent Vivier
Reviewed-by: Philippe Mathieu-Daudé
Reviewed-by: Peter Maydell
Tested-by: Taylor Simpson
Message-Id: <20200212125658.644558-3-laur...@vivier.eu>
---
linux-user/signal.c | 48 ++---
1 file changed, 28 insertions(+), 20 deletions(-)
diff --git a/linux-user/signal.c b/linux-user/signal.c
index 5ca6d62b15d3..246315571c09 100644
--- a/linux-user/signal.c
+++ b/linux-user/signal.c
@@ -66,12 +66,6 @@ static uint8_t host_to_target_signal_table[_NSIG] = {
[SIGPWR] = TARGET_SIGPWR,
[SIGSYS] = TARGET_SIGSYS,
/* next signals stay the same */
-/* Nasty hack: Reverse SIGRTMIN and SIGRTMAX to avoid overlap with
- host libpthread signals. This assumes no one actually uses SIGRTMAX :-/
- To fix this properly we need to do manual signal delivery multiplexed
- over a single host signal. */
-[__SIGRTMIN] = __SIGRTMAX,
-[__SIGRTMAX] = __SIGRTMIN,
};
static uint8_t target_to_host_signal_table[_NSIG];
@@ -480,31 +474,45 @@ static int core_dump_signal(int sig)
}
}
+static void signal_table_init(void)
+{
+int host_sig, target_sig;
+
+/*
+ * Nasty hack: Reverse SIGRTMIN and SIGRTMAX to avoid overlap with
+ * host libpthread signals. This assumes no one actually uses SIGRTMAX :-/
+ * To fix this properly we need to do manual signal delivery multiplexed
+ * over a single host signal.
+ */
+host_to_target_signal_table[__SIGRTMIN] = __SIGRTMAX;
+host_to_target_signal_table[__SIGRTMAX] = __SIGRTMIN;
+
+/* generate signal conversion tables */
+for (host_sig = 1; host_sig < _NSIG; host_sig++) {
+if (host_to_target_signal_table[host_sig] == 0) {
+host_to_target_signal_table[host_sig] = host_sig;
+}
+}
+for (host_sig = 1; host_sig < _NSIG; host_sig++) {
+target_sig = host_to_target_signal_table[host_sig];
+target_to_host_signal_table[target_sig] = host_sig;
+}
+}
+
void signal_init(void)
{
TaskState *ts = (TaskState *)thread_cpu->opaque;
struct sigaction act;
struct sigaction oact;
-int i, j;
+int i;
int host_sig;
-/* generate signal conversion tables */
-for(i = 1; i < _NSIG; i++) {
-if (host_to_target_signal_table[i] == 0)
-host_to_target_signal_table[i] = i;
-}
-for(i = 1; i < _NSIG; i++) {
-j = host_to_target_signal_table[i];
-target_to_host_signal_table[j] = i;
-}
+/* initialize signal conversion tables */
+signal_table_init();
/* Set the signal mask from the host mask. */
sigprocmask(0, 0, >signal_mask);
-/* set all host signal handlers. ALL signals are blocked during
- the handlers to serialize them. */
-memset(sigact_table, 0, sizeof(sigact_table));
-
sigfillset(_mask);
act.sa_flags = SA_SIGINFO;
act.sa_sigaction = host_signal_handler;
--
2.24.1
[PATCH v3 8/9] linux-user: xtensa: Update syscall numbers to kernel 5.5 level
From: Aleksandar Markovic Update xtensa syscall numbers based on Linux kernel v5.5. CC: Max Filippov Acked-by: Max Filippov Signed-off-by: Aleksandar Markovic Reviewed-by: Laurent Vivier --- linux-user/xtensa/syscall_nr.h | 38 -- 1 file changed, 36 insertions(+), 2 deletions(-) diff --git a/linux-user/xtensa/syscall_nr.h b/linux-user/xtensa/syscall_nr.h index 27645be..3d19d0c 100644 --- a/linux-user/xtensa/syscall_nr.h +++ b/linux-user/xtensa/syscall_nr.h @@ -431,7 +431,41 @@ #define TARGET_NR_pkey_free 350 #define TARGET_NR_statx 351 - -#define TARGET_NR_syscall_count 352 +#define TARGET_NR_rseq 352 +/* 353 through 402 are unassigned to sync up with generic numbers */ +#define TARGET_NR_clock_gettime64403 +#define TARGET_NR_clock_settime64404 +#define TARGET_NR_clock_adjtime64405 +#define TARGET_NR_clock_getres_time64406 +#define TARGET_NR_clock_nanosleep_time64 407 +#define TARGET_NR_timer_gettime64408 +#define TARGET_NR_timer_settime64409 +#define TARGET_NR_timerfd_gettime64 410 +#define TARGET_NR_timerfd_settime64 411 +#define TARGET_NR_utimensat_time64 412 +#define TARGET_NR_pselect6_time64413 +#define TARGET_NR_ppoll_time64 414 +#define TARGET_NR_io_pgetevents_time64 416 +#define TARGET_NR_recvmmsg_time64417 +#define TARGET_NR_mq_timedsend_time64418 +#define TARGET_NR_mq_timedreceive_time64 419 +#define TARGET_NR_semtimedop_time64 420 +#define TARGET_NR_rt_sigtimedwait_time64 421 +#define TARGET_NR_futex_time64 422 +#define TARGET_NR_sched_rr_get_interval_time64 423 +#define TARGET_NR_pidfd_send_signal 424 +#define TARGET_NR_io_uring_setup 425 +#define TARGET_NR_io_uring_enter 426 +#define TARGET_NR_io_uring_register 427 +#define TARGET_NR_open_tree 428 +#define TARGET_NR_move_mount 429 +#define TARGET_NR_fsopen 430 +#define TARGET_NR_fsconfig 431 +#define TARGET_NR_fsmount432 +#define TARGET_NR_fspick 433 +#define TARGET_NR_pidfd_open 434 +#define TARGET_NR_clone3 435 + +#define TARGET_NR_syscall_count 436 #endif /* XTENSA_SYSCALL_NR_H */ -- 2.7.4
Re: [PULL] RISC-V Patches for the 5.0 Soft Freeze, Part 2
Hi Palmer, On Thu, Feb 13, 2020 at 1:30 AM Palmer Dabbelt wrote: > > The following changes since commit 81a23caf47956778c5a5056ad656d1ef92bf9659: > > Merge remote-tracking branch 'remotes/stefanha/tags/block-pull-request' > into staging (2020-02-10 17:08:51 +) > > are available in the Git repository at: > > g...@github.com:palmer-dabbelt/qemu.git tags/riscv-for-master-5.0-sf2 > > for you to fetch changes up to 9c8fdcece53e05590441785ab22d91a22da36e29: > > MAINTAINERS: Add maintainer entry for Goldfish RTC (2020-02-10 12:01:39 > -0800) > > > RISC-V Patches for the 5.0 Soft Freeze, Part 2 > > This is a fairly light-weight pull request, but I wanted to send it out to > avoid the Goldfish stuff getting buried as the next PR should contain the H > extension implementation. > > As far as this PR goes, it contains: > > * The addition of syscon device tree nodes for reboot and poweroff, which > allows Linux to control QEMU without an additional driver. The existing > device was already compatible with the syscon interface. > * A fix to our GDB stub to avoid confusing XLEN and FLEN, specifically useful > for rv32id-based systems. > * A device emulation for the Goldfish RTC device, a simple memory-mapped RTC. > * The addition of the Goldfish RTC device to the RISC-V virt board. > > This passes "make check" and boots buildroot for me. > This PR is still missing: http://patchwork.ozlabs.org/patch/1199516/ > > > Peter: I'm sending hw/rtc code because it was suggested that the Goldfish > implementation gets handled via the RISC-V tree as our virt board is the only > user. I'm happy to do things differently in the future (maybe send > goldfish-specific PRs?) if that's better for you. Just LMK what makes sense, > I > anticipate that this'll be a pretty low traffic device so I'm fine with pretty > much anything. > Regards, Bin
[PATCH v3 9/9] linux-user: xtensa: Remove unused constant TARGET_NR_syscall_count
From: Aleksandar Markovic Currently, there is no usage of TARGET_NR_syscall_count for target xtensa, and there is no obvious indication if there is some planned usage in future. CC: Max Filippov Acked-by: Max Filippov Signed-off-by: Aleksandar Markovic Reviewed-by: Laurent Vivier --- linux-user/xtensa/syscall_nr.h | 2 -- 1 file changed, 2 deletions(-) diff --git a/linux-user/xtensa/syscall_nr.h b/linux-user/xtensa/syscall_nr.h index 3d19d0c..39bff65 100644 --- a/linux-user/xtensa/syscall_nr.h +++ b/linux-user/xtensa/syscall_nr.h @@ -466,6 +466,4 @@ #define TARGET_NR_pidfd_open 434 #define TARGET_NR_clone3 435 -#define TARGET_NR_syscall_count 436 - #endif /* XTENSA_SYSCALL_NR_H */ -- 2.7.4
[PATCH v3 7/9] linux-user: x86_64: Update syscall numbers to kernel 5.5 level
From: Aleksandar Markovic Update x86_64 syscall numbers based on Linux kernel v5.5. CC: Paolo Bonzini CC: Richard Henderson CC: Eduardo Habkost Signed-off-by: Aleksandar Markovic Reviewed-by: Laurent Vivier --- linux-user/x86_64/syscall_nr.h | 24 1 file changed, 24 insertions(+) diff --git a/linux-user/x86_64/syscall_nr.h b/linux-user/x86_64/syscall_nr.h index 9b6981e..e5d14ec 100644 --- a/linux-user/x86_64/syscall_nr.h +++ b/linux-user/x86_64/syscall_nr.h @@ -328,5 +328,29 @@ #define TARGET_NR_membarrier324 #define TARGET_NR_mlock2325 #define TARGET_NR_copy_file_range 326 +#define TARGET_NR_preadv2 327 +#define TARGET_NR_pwritev2 328 +#define TARGET_NR_pkey_mprotect 329 +#define TARGET_NR_pkey_alloc330 +#define TARGET_NR_pkey_free 331 +#define TARGET_NR_statx 332 +#define TARGET_NR_io_pgetevents 333 +#define TARGET_NR_rseq 334 +/* + * don't use numbers 387 through 423, add new calls after the last + * 'common' entry + */ +#define TARGET_NR_pidfd_send_signal 424 +#define TARGET_NR_io_uring_setup425 +#define TARGET_NR_io_uring_enter426 +#define TARGET_NR_io_uring_register 427 +#define TARGET_NR_open_tree 428 +#define TARGET_NR_move_mount429 +#define TARGET_NR_fsopen430 +#define TARGET_NR_fsconfig 431 +#define TARGET_NR_fsmount 432 +#define TARGET_NR_fspick433 +#define TARGET_NR_pidfd_open434 +#define TARGET_NR_clone3435 #endif -- 2.7.4
Re: [PATCH v2] hw/char/exynos4210_uart: Fix memleaks in exynos4210_uart_init
On Thu, 13 Feb 2020 at 10:09, Philippe Mathieu-Daudé wrote:
>
> On 2/13/20 3:56 AM, kuhn.chen...@huawei.com wrote:
> > From: Chen Qun
> >
> > It's easy to reproduce as follow:
> > virsh qemu-monitor-command vm1 --pretty '{"execute":
> > "device-list-properties",
> > "arguments":{"typename":"exynos4210.uart"}}'
> >
> > ASAN shows memory leak stack:
> >#1 0xfffd896d71cb in g_malloc0 (/lib64/libglib-2.0.so.0+0x571cb)
> >#2 0xaaad270beee3 in timer_new_full /qemu/include/qemu/timer.h:530
> >#3 0xaaad270beee3 in timer_new /qemu/include/qemu/timer.h:551
> >#4 0xaaad270beee3 in timer_new_ns /qemu/include/qemu/timer.h:569
> >#5 0xaaad270beee3 in exynos4210_uart_init
> > /qemu/hw/char/exynos4210_uart.c:677
> >#6 0xaaad275c8f4f in object_initialize_with_type /qemu/qom/object.c:516
> >#7 0xaaad275c91bb in object_new_with_type /qemu/qom/object.c:684
> >#8 0xaaad2755df2f in qmp_device_list_properties
> > /qemu/qom/qom-qmp-cmds.c:152
> >
> > Reported-by: Euler Robot
> > Signed-off-by: Chen Qun
> > ---
> > Changes V2 to V1:
> > -Keep s->wordtime in exynos4210_uart_init (Base on Eduardo and Philippe's
> > comments).
>
> Thanks.
>
> Reviewed-by: Philippe Mathieu-Daudé
Applied to target-arm.next, thanks.
-- PMM
[RFC 0/2] pci_expander_brdige:acpi:Support pxb-pcie for ARM
From: miaoyubo Currently pxb-pcie is not supported by arm and only one main host bridge is described in acpi tables, which means it is not impossible to present different io numas for different devices. This series of patches make arm to support PXB-PCIE. Users can configure pxb-pcie with certain numa, Example command is: -device pxb-pcie,id=pci.7,bus_nr=128,numa_node=0,bus=pcie.0,addr=0x9 Since devices could not be plugged into pxb-pcie directly, one pcie-root-port is auto plugged into the pxb, therefore, the devices could be plugged into pxb-pcie. With the patches,io numa could be presented to the guest by define a pxb-pcie with the numa and plug the device into the pxb-pcie. miaoyubo (2): arm: acpi: pci-expender-bus: Make arm to support PXB-PCIE pci-expender-bus:Add pcie-root-port to pxb-pcie under arm. hw/arm/virt-acpi-build.c| 234 ++-- hw/pci-bridge/pci_expander_bridge.c | 9 ++ hw/pci-host/gpex.c | 4 + include/hw/arm/virt.h | 1 + include/hw/pci/pcie_port.h | 1 + 5 files changed, 238 insertions(+), 11 deletions(-) -- 2.19.1
[Bug 1805256] Re: qemu-img hangs on rcu_call_ready_event logic in Aarch64 when converting images
** Tags added: ikeradar -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1805256 Title: qemu-img hangs on rcu_call_ready_event logic in Aarch64 when converting images Status in kunpeng920: Incomplete Status in QEMU: In Progress Status in qemu package in Ubuntu: Incomplete Status in qemu source package in Bionic: Incomplete Status in qemu source package in Disco: Incomplete Status in qemu source package in Eoan: Incomplete Status in qemu source package in Focal: Incomplete Bug description: Command: qemu-img convert -f qcow2 -O qcow2 ./disk01.qcow2 ./output.qcow2 Hangs indefinitely approximately 30% of the runs. Workaround: qemu-img convert -m 1 -f qcow2 -O qcow2 ./disk01.qcow2 ./output.qcow2 Run "qemu-img convert" with "a single coroutine" to avoid this issue. (gdb) thread 1 ... (gdb) bt #0 0xbf1ad81c in __GI_ppoll #1 0xaabcf73c in ppoll #2 qemu_poll_ns #3 0xaabd0764 in os_host_main_loop_wait #4 main_loop_wait ... (gdb) thread 2 ... (gdb) bt #0 syscall () #1 0xaabd41cc in qemu_futex_wait #2 qemu_event_wait (ev=ev@entry=0xaac86ce8 ) #3 0xaabed05c in call_rcu_thread #4 0xaabd34c8 in qemu_thread_start #5 0xbf25c880 in start_thread #6 0xbf1b6b9c in thread_start () (gdb) thread 3 ... (gdb) bt #0 0xbf11aa20 in __GI___sigtimedwait #1 0xbf2671b4 in __sigwait #2 0xaabd1ddc in sigwait_compat #3 0xaabd34c8 in qemu_thread_start #4 0xbf25c880 in start_thread #5 0xbf1b6b9c in thread_start (gdb) run Starting program: /usr/bin/qemu-img convert -f qcow2 -O qcow2 ./disk01.ext4.qcow2 ./output.qcow2 [New Thread 0xbec5ad90 (LWP 72839)] [New Thread 0xbe459d90 (LWP 72840)] [New Thread 0xbdb57d90 (LWP 72841)] [New Thread 0xacac9d90 (LWP 72859)] [New Thread 0xa7ffed90 (LWP 72860)] [New Thread 0xa77fdd90 (LWP 72861)] [New Thread 0xa6ffcd90 (LWP 72862)] [New Thread 0xa67fbd90 (LWP 72863)] [New Thread 0xa5ffad90 (LWP 72864)] [Thread 0xa5ffad90 (LWP 72864) exited] [Thread 0xa6ffcd90 (LWP 72862) exited] [Thread 0xa77fdd90 (LWP 72861) exited] [Thread 0xbdb57d90 (LWP 72841) exited] [Thread 0xa67fbd90 (LWP 72863) exited] [Thread 0xacac9d90 (LWP 72859) exited] [Thread 0xa7ffed90 (LWP 72860) exited] """ All the tasks left are blocked in a system call, so no task left to call qemu_futex_wake() to unblock thread #2 (in futex()), which would unblock thread #1 (doing poll() in a pipe with thread #2). Those 7 threads exit before disk conversion is complete (sometimes in the beginning, sometimes at the end). [ Original Description ] On the HiSilicon D06 system - a 96 core NUMA arm64 box - qemu-img frequently hangs (~50% of the time) with this command: qemu-img convert -f qcow2 -O qcow2 /tmp/cloudimg /tmp/cloudimg2 Where "cloudimg" is a standard qcow2 Ubuntu cloud image. This qcow2->qcow2 conversion happens to be something uvtool does every time it fetches images. Once hung, attaching gdb gives the following backtrace: (gdb) bt #0 0xae4f8154 in __GI_ppoll (fds=0xe8a67dc0, nfds=187650274213760, timeout=, timeout@entry=0x0, sigmask=0xc123b950) at ../sysdeps/unix/sysv/linux/ppoll.c:39 #1 0xbbefaf00 in ppoll (__ss=0x0, __timeout=0x0, __nfds=, __fds=) at /usr/include/aarch64-linux-gnu/bits/poll2.h:77 #2 qemu_poll_ns (fds=, nfds=, timeout=timeout@entry=-1) at util/qemu-timer.c:322 #3 0xbbefbf80 in os_host_main_loop_wait (timeout=-1) at util/main-loop.c:233 #4 main_loop_wait (nonblocking=) at util/main-loop.c:497 #5 0xbbe2aa30 in convert_do_copy (s=0xc123bb58) at qemu-img.c:1980 #6 img_convert (argc=, argv=) at qemu-img.c:2456 #7 0xbbe2333c in main (argc=7, argv=) at qemu-img.c:4975 Reproduced w/ latest QEMU git (@ 53744e0a182) To manage notifications about this bug go to: https://bugs.launchpad.net/kunpeng920/+bug/1805256/+subscriptions
[RFC 2/2] pci-expender-bus:Add pcie-root-port to pxb-pcie under arm.
From: miaoyubo
Since devices could not directly plugged into pxb-pcie, under arm, one
pcie-root port is plugged into pxb-pcie. Due to the bus for each pxb-pcie
is defined as 2 in acpi dsdt tables(one for pxb-pcie, one for pcie-root-port),
only one device could be plugged into one pxb-pcie.
Signed-off-by: miaoyubo
---
hw/pci-bridge/pci_expander_bridge.c | 9 +
include/hw/pci/pcie_port.h | 1 +
2 files changed, 10 insertions(+)
diff --git a/hw/pci-bridge/pci_expander_bridge.c
b/hw/pci-bridge/pci_expander_bridge.c
index 47aaaf8fd1..3d896dd452 100644
--- a/hw/pci-bridge/pci_expander_bridge.c
+++ b/hw/pci-bridge/pci_expander_bridge.c
@@ -15,6 +15,7 @@
#include "hw/pci/pci.h"
#include "hw/pci/pci_bus.h"
#include "hw/pci/pci_host.h"
+#include "hw/pci/pcie_port.h"
#include "hw/qdev-properties.h"
#include "hw/pci/pci_bridge.h"
#include "qemu/range.h"
@@ -233,7 +234,15 @@ static void pxb_dev_realize_common(PCIDevice *dev, bool
pcie, Error **errp)
ds = qdev_create(NULL, TYPE_PXB_HOST);
if (pcie) {
+#ifdef __aarch64__
+bus = pci_root_bus_new(ds, "pxb-pcie-internal",
+ NULL, NULL, 0, TYPE_PXB_PCIE_BUS);
+bds = qdev_create(BUS(bus), "pcie-root-port");
+bds->id = dev_name;
+qdev_prop_set_uint8(bds, PCIE_ROOT_PORT_PROP_CHASSIS, pxb->bus_nr);
+#else
bus = pci_root_bus_new(ds, dev_name, NULL, NULL, 0, TYPE_PXB_PCIE_BUS);
+#endif
} else {
bus = pci_root_bus_new(ds, "pxb-internal", NULL, NULL, 0,
TYPE_PXB_BUS);
bds = qdev_create(BUS(bus), "pci-bridge");
diff --git a/include/hw/pci/pcie_port.h b/include/hw/pci/pcie_port.h
index 4b3d254b08..b41d473220 100644
--- a/include/hw/pci/pcie_port.h
+++ b/include/hw/pci/pcie_port.h
@@ -64,6 +64,7 @@ int pcie_chassis_add_slot(struct PCIESlot *slot);
void pcie_chassis_del_slot(PCIESlot *s);
#define TYPE_PCIE_ROOT_PORT "pcie-root-port-base"
+#define PCIE_ROOT_PORT_PROP_CHASSIS "chassis"
#define PCIE_ROOT_PORT_CLASS(klass) \
OBJECT_CLASS_CHECK(PCIERootPortClass, (klass), TYPE_PCIE_ROOT_PORT)
#define PCIE_ROOT_PORT_GET_CLASS(obj) \
--
2.19.1
[PATCH v2 2/2] tests/tcg/multiarch: Add tests for implemented alsa sound timer ioctls
This patch adds tests for following 14 implemented alsa timer ioctls:
* SNDRV_TIMER_IOCTL_PVERSION* SNDRV_TIMER_IOCTL_INFO
* SNDRV_TIMER_IOCTL_NEXT_DEVICE * SNDRV_TIMER_IOCTL_PARAMS
* SNDRV_TIMER_IOCTL_TREAD * SNDRV_TIMER_IOCTL_STATUS
* SNDRV_TIMER_IOCTL_GINFO * SNDRV_TIMER_IOCTL_START
* SNDRV_TIMER_IOCTL_GPARAMS * SNDRV_TIMER_IOCTL_STOP
* SNDRV_TIMER_IOCTL_GSTATUS * SNDRV_TIMER_IOCTL_CONTINUE
* SNDRV_TIMER_IOCTL_SELECT * SNDRV_TIMER_IOCTL_PAUSE
Names and descriptions of these ioctls can be found in patches that
implement them.
Test folder for these ioctl tests is located at
"tests/tcg/multiarch/alsa-timer-ioctl-tests/"
There are two folders located in the test folder, one for test that was written
manually ("/manual-test") and one for the test that was obtained remotely
("/remote-test").
Manual test:
This test was written manually to test all the implemented alsa timer ioctls
and was added at "/manual-test/alsa-timer-ioctl-manual-test.c". A separate
test
function was written for each ioctl. Each of these functions uses a global
test
macro 'TEST_ALSA_IOCTL' to run these tests. The file can be run to test all
ioctls
or it can test only the specified ioctls. This depends on the commands
specified
when running the test.
For Example (assuming 'rtc-ioctl-manual-test' is the compiled .exe file):
running './alsa-timer-ioctl-manual-test SNDRV_TIMER_IOCTL_TREAD' tests
only the
ioctl SNDRV_TIMER_IOCTL_TREAD
running './alsa-timer-ioctl-manual-test SNDRV_TIMER_IOCTL_INFO
SNDRV_TIMER_IOCTL_STOP
SNDRV_TIMER_IOCTL_PAUSE' tests ioctls SNDRV_TIMER_IOCTL_INFO,
SNDRV_TIMER_IOCTL_STOP,
SNDRV_TIMER_IOCTL_PAUSE
If no ioctl is specified when running the test file, all the ioctls
are tested:
running './rtc-ioctl-test' tests all ioctls
Remote test:
Besides the manual tests, a remote alsa timer ioctl test was added at
"/remote-test/timer.c". This test file was downloaded from a git repository
that contains alsa ioctl test suite. This repository is located at
"https://github.com/takaswie/alsa-ioctl-test;. It is used to test all of the
alsa timer ioctls at once by running a test macro defined in that file.
The file was modified a little bit by adding an output line that shows which
test passed and at which test the program aborts. It was also modified so
that
it doesn't have styling problems detected by 'scripts/checkpatch.pl'.
Signed-off-by: Filip Bozuta
---
.../manual-test/alsa-timer-ioctl-manual-test.c | 294 +
.../alsa-timer-ioctl-tests/remote-test/timer.c | 158 +++
2 files changed, 452 insertions(+)
create mode 100644
tests/tcg/multiarch/alsa-timer-ioctl-tests/manual-test/alsa-timer-ioctl-manual-test.c
create mode 100644
tests/tcg/multiarch/alsa-timer-ioctl-tests/remote-test/timer.c
diff --git
a/tests/tcg/multiarch/alsa-timer-ioctl-tests/manual-test/alsa-timer-ioctl-manual-test.c
b/tests/tcg/multiarch/alsa-timer-ioctl-tests/manual-test/alsa-timer-ioctl-manual-test.c
new file mode 100644
index 000..95803ff
--- /dev/null
+++
b/tests/tcg/multiarch/alsa-timer-ioctl-tests/manual-test/alsa-timer-ioctl-manual-test.c
@@ -0,0 +1,294 @@
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define ERROR -1
+
+#define TEST_ALSA_IOCTL(fd, command, argument, supported) \
+do { \
+printf("%s:\n", #command);\
+if (ioctl(fd, command, argument) == ERROR) { \
+perror("ioctl"); \
+printf("\n"); \
+supported = false;\
+} \
+} while (0)
+
+static bool test_pversion(int fd, bool supported)
+{
+int version = 0;
+
+TEST_ALSA_IOCTL(fd, SNDRV_TIMER_IOCTL_PVERSION, , supported);
+if (supported) {
+printf("Timer version: %d\n", version);
+printf("\n");
+}
+return supported;
+}
+
+static bool test_next_device(int fd, bool supported)
+{
+struct snd_timer_id id = {1, 0, 0, 0, 0};
+
+TEST_ALSA_IOCTL(fd, SNDRV_TIMER_IOCTL_NEXT_DEVICE, , supported);
+if (supported) {
+printf("Timer dev_class: %d\n", id.dev_class);
+printf("Timer dev_sclass: %d\n", id.dev_class);
+printf("Timer card: %d\n", id.dev_class);
+printf("Timer device: %d\n", id.dev_class);
+printf("Timer subdevice: %d\n", id.dev_class);
+printf("\n");
+}
+return supported;
+}
+
+static bool test_tread(int fd, bool supported)
+{
+int tread = 1;
+
+TEST_ALSA_IOCTL(fd, SNDRV_TIMER_IOCTL_TREAD, , supported);
+if (supported) {
+printf("Enhanced read enabled!\n");
+printf("\n");
+}
+return
[PATCH v2 0/2] tests/tcg/multiarch: Add tests for implemented real
This series covers tests for implemented rtc and alsa timer ioctls. The names of ioctls that are covered by these tests can be found in patch descriptions. The functionalities of each ioctl that is tested can be found in patches that implement them. Some of the features that are accessible through these ioctls are not supported on all test host pc's. These tests were written so that the implemented ioctls can be properly tested on pc's that support all of their features. Both rtc and alsa timer test folders have separate files for manually written and remotely obtained tests. Tests that were obtained remotely run multiple ioctl tests at once, while the manually written tests can be used to run both individual and multiple ioctl tests based on the command specified when running the test. Filip Bozuta (2): tests/tcg/multiarch: Add tests for implemented rtc ioctls tests/tcg/multiarch: Add tests for implemented alsa sound timer ioctls .../manual-test/alsa-timer-ioctl-manual-test.c | 294 + .../alsa-timer-ioctl-tests/remote-test/timer.c | 158 + .../manual-test/rtc-ioctl-manual-test.c| 352 + .../rtc-ioctl-tests/remote-test/rtc-test.c | 226 + 4 files changed, 1030 insertions(+) create mode 100644 tests/tcg/multiarch/alsa-timer-ioctl-tests/manual-test/alsa-timer-ioctl-manual-test.c create mode 100644 tests/tcg/multiarch/alsa-timer-ioctl-tests/remote-test/timer.c create mode 100644 tests/tcg/multiarch/rtc-ioctl-tests/manual-test/rtc-ioctl-manual-test.c create mode 100644 tests/tcg/multiarch/rtc-ioctl-tests/remote-test/rtc-test.c -- 2.7.4
[PATCH v2 1/2] tests/tcg/multiarch: Add tests for implemented rtc ioctls
This patch adds tests for following 22 implemented rtc ioctls:
* RTC_AIE_ON * RTC_ALM_SET * RTC_WKALM_SET
* RTC_AIE_OFF* RTC_ALM_READ * RTC_WKALM_RD
* RTC_UIE_ON * RTC_RD_TIME * RTC_PLL_GET
* RTC_UIE_OFF* RTC_SET_TIME * RTC_PLL_SET
* RTC_PIE_ON * RTC_IRQP_READ* RTC_VL_READ
* RTC_PIE_OFF* RTC_IRQP_SET * RTC_VL_CLR
* RTC_WIE_ON * RTC_EPOCH_READ
* RTC_WIE_OFF* RTC_EPOCH_SET
Names and descriptions of these ioctls can be found in patches that
implement them.
Test folder for these ioctl tests is located at
"tests/tcg/multiarch/rtc-ioctl-tests/"
There are two folders located in the test folder, one for test that was written
manually ("/manual-test") and one the test that was obtained remotely
("/remote-test").
Manual test:
This test was written manually to test all the implemented rtc ioctls and
was added at "/manual-test/rtc-ioctl-manual-test.c". A separate test
function
was written for each ioctl. Each of these functions uses a global test macro
'TEST_RTC_IOCTL' to run these tests. The file can be run to test all ioctls
or it can test only the specified ioctls. This depends on the commands
specified when running the test.
For Example (assuming 'rtc-ioctl-manual-test' is the compiled .exe file):
running './rtc-ioctl-manual-test RTC_AIE_ON' tests only the ioctl
RTC_AIE_ON
running './rtc-ioctl-manual-test RTC_AIE_ON RTC_SET_TIME RTC_ALM_READ'
tests
ioctls RTC_AIE_ON, RTC_SET_TIME, RTC_ALM_READ
If no ioctl is specified when running the test file, all the ioctls
are tested:
running './rtc-ioctl-test' tests all ioctls
Remote test:
Besides the manual test, a remote rtc ioctl test was added at
"/remote-test/rtc-test.c". The test file "rtc-test.c" was downloaded
from linux kernel and is located at "linux/drivers/rtc/rtc-test.c".
This file was modified a little bit so that it doesn't have styling
problems identified by "scripts/checkpatch.pl". It is used to further
test functionalities of some rtc ioctls by running rtc clock at different
frequencies.
Signed-off-by: Filip Bozuta
---
.../manual-test/rtc-ioctl-manual-test.c| 352 +
.../rtc-ioctl-tests/remote-test/rtc-test.c | 226 +
2 files changed, 578 insertions(+)
create mode 100644
tests/tcg/multiarch/rtc-ioctl-tests/manual-test/rtc-ioctl-manual-test.c
create mode 100644 tests/tcg/multiarch/rtc-ioctl-tests/remote-test/rtc-test.c
diff --git
a/tests/tcg/multiarch/rtc-ioctl-tests/manual-test/rtc-ioctl-manual-test.c
b/tests/tcg/multiarch/rtc-ioctl-tests/manual-test/rtc-ioctl-manual-test.c
new file mode 100644
index 000..f073442
--- /dev/null
+++ b/tests/tcg/multiarch/rtc-ioctl-tests/manual-test/rtc-ioctl-manual-test.c
@@ -0,0 +1,352 @@
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define ERROR -1
+
+#define TEST_RTC_IOCTL(fd, command, argument, supported) \
+do { \
+printf("%s:\n", #command);\
+if (ioctl(fd, command, argument) == ERROR) { \
+perror("ioctl"); \
+printf("\n"); \
+supported = false;\
+} \
+} while (0)
+
+static bool test_aie_on(int fd, bool supported)
+{
+TEST_RTC_IOCTL(fd, RTC_AIE_ON, NULL, supported);
+if (supported) {
+printf("Alarm interrupt enabled!\n\n");
+}
+return supported;
+}
+
+static bool test_aie_off(int fd, bool supported)
+{
+TEST_RTC_IOCTL(fd, RTC_AIE_OFF, NULL, supported);
+if (supported) {
+printf("Alarm interrupt disabled!\n\n");
+}
+return supported;
+}
+
+static bool test_pie_on(int fd, bool supported)
+{
+TEST_RTC_IOCTL(fd, RTC_PIE_ON, NULL, supported);
+if (supported) {
+printf("Periodic interrupt enabled!\n\n");
+}
+return supported;
+}
+
+static bool test_pie_off(int fd, bool supported)
+{
+TEST_RTC_IOCTL(fd, RTC_PIE_OFF, NULL, supported);
+if (supported) {
+printf("Periodic interrupt disabled!\n\n");
+}
+return supported;
+}
+
+static bool test_uie_on(int fd, bool supported)
+{
+TEST_RTC_IOCTL(fd, RTC_UIE_ON, NULL, supported);
+if (supported) {
+printf("Update interrupt enabled!\n\n");
+}
+return supported;
+}
+
+static bool test_uie_off(int fd, bool supported)
+{
+TEST_RTC_IOCTL(fd, RTC_UIE_OFF, NULL, supported);
+if (supported) {
+printf("Update interrupt disabled!\n\n");
+}
+return supported;
+}
+
+static bool test_wie_on(int fd, bool supported)
+{
+TEST_RTC_IOCTL(fd, RTC_WIE_ON, NULL, supported);
+if (supported) {
+printf("Watchdog interrupt enabled!\n\n");
+}
+return
Re: Question about (and problem with) pflash data access
On 2/13/20 1:51 AM, Paolo Bonzini wrote: On 13/02/20 08:40, Alexey Kardashevskiy wrote: memory-region: system - (prio 0, i/o): system -01ff (prio 0, romd): omap_sx1.flash0-1 -01ff (prio 0, rom): omap_sx1.flash0-0 Eh two memory regions with same size and same priority... Is this legal? I'd say yes if used with memory_region_set_enabled() to make sure only one is enabled. Having both enabled is weird and we should print a warning. Yeah, it's undefined which one becomes visible. I have a patch fixing that, resulting in (qemu) info mtree -f FlatView #0 AS "I/O", root: io Root memory region: io - (prio 0, i/o): io FlatView #1 AS "memory", root: system AS "cpu-memory-0", root: system Root memory region: system -01ff (prio 0, romd): omap_sx1.flash0 0200-03ff (prio 0, i/o): sx1.cs0 0400-07ff (prio 0, i/o): sx1.cs1 0800-0bff (prio 0, i/o): sx1.cs2 0c00-0fff (prio 0, i/o): sx1.cs3 ... but unfortunately that doesn't fix my problem. The data in the omap_sx1.flash0 region is as wrong as before. What really puzzles me is that there is no trace output for flash data accesses (trace_pflash_data_read and trace_pflash_data_write), meaning the actual flash data access must be handled elsewhere. Can someone give me a hint where that might be ? Clearly I am missing something about inner workings of qemu. Thanks, Guenter
Re: [PATCH v2 0/4] arm64: Add the cpufreq device to show cpufreq info to guest
On 2020/2/13 16:18, Andrew Jones wrote: On Thu, Feb 13, 2020 at 03:36:26PM +0800, Ying Fang wrote: On ARM64 platform, cpu frequency is retrieved via ACPI CPPC. A virtual cpufreq device based on ACPI CPPC is created to present cpu frequency info to the guest. The default frequency is set to host cpu nominal frequency, which is obtained from the host CPPC sysfs. Other performance data are set to the same value, since we don't support guest performance scaling here. Performance counters are also not emulated and they simply return 1 if read, and guest should fallback to use desired performance value as the current performance. Guest kernel version above 4.18 is required to make it work. This is v2 of the series, but I don't see a changelog. Hi Andrew, please forgive my carelessness, I forget to add the changelog here. Actually v2 is slightly modified with a few fixes for compilation warning and a commit message. Can you please describe the motivation for this? If I understand correctly, all of this is just to inform the guest of the host's CPU0 nominal or max (if nominal isn't present?) frequency. Why do that? Yes, you are right. The motivation is that there seems no other formal way than the CPPC feature for arm64 to present cpu frequency info to the OS. However on x86 platform we have the CPUID method to do that. Some of our VM customers and cloud developers want that information to do something. So we come up with the virtual cpufreq device way. What happens if the guest migrates somewhere where the frequency is different? If the guest is migrated to any host where the frequency is different, a next read on the CPPC related register may return the new cpufreq info. If this is for a special use case, then why not come up with a different channel (guest agent?) to pass this information? Maybe some userspace apps need it to do perf tuning or they want to know the accurate cpu nominal frequency by using tools like lshw. We use the CPPC cpufreq way because we think this is a much more standard way to do that. Thanks, drew . Thanks， Ying
[PULL 00/46] target-arm queue
Big pullreq this week, since it's got RTH's PAN/UAO/ATS1E1 implementation in it, and also Philippe's raspi board model cleanup patchset, as well as a scattering of smaller stuff. -- PMM The following changes since commit 7ce9ce89930ce260af839fb3e3e5f9101f5c69a0: Merge remote-tracking branch 'remotes/kraxel/tags/ui-20200212-pull-request' into staging (2020-02-13 11:06:32 +) are available in the Git repository at: https://git.linaro.org/people/pmaydell/qemu-arm.git tags/pull-target-arm-20200213 for you to fetch changes up to dc7a88d0810ad272bdcd2e0869359af78fdd9114: target/arm: Implement ARMv8.1-VMID16 extension (2020-02-13 14:30:51 +) target-arm queue: * i.MX: Fix inverted sense of register bits in watchdog timer * i.MX: Add support for WDT on i.MX6 * arm/virt: cleanups to ACPI tables * Implement ARMv8.1-VMID16 extension * Implement ARMv8.1-PAN * Implement ARMv8.2-UAO * Implement ARMv8.2-ATS1E1 * ast2400/2500/2600: Wire up EHCI controllers * hw/char/exynos4210_uart: Fix memleaks in exynos4210_uart_init * hw/arm/raspi: Clean up the board code Chen Qun (1): hw/char/exynos4210_uart: Fix memleaks in exynos4210_uart_init Guenter Roeck (2): hw/arm: ast2400/ast2500: Wire up EHCI controllers hw/arm: ast2600: Wire up EHCI controllers Heyi Guo (7): bios-tables-test: prepare to change ARM virt ACPI DSDT arm/virt/acpi: remove meaningless sub device "RP0" from PCI0 arm/virt/acpi: remove _ADR from devices identified by _HID arm/acpi: fix PCI _PRT definition arm/acpi: fix duplicated _UID of PCI interrupt link devices arm/acpi: simplify the description of PCI _CRS virt/acpi: update golden masters for DSDT update Peter Maydell (1): target/arm: Implement ARMv8.1-VMID16 extension Philippe Mathieu-Daudé (13): hw/arm/raspi: Use BCM2708 machine type with pre Device Tree kernels hw/arm/raspi: Correct the board descriptions hw/arm/raspi: Extract the version from the board revision hw/arm/raspi: Extract the RAM size from the board revision hw/arm/raspi: Extract the processor type from the board revision hw/arm/raspi: Trivial code movement hw/arm/raspi: Make machines children of abstract RaspiMachineClass hw/arm/raspi: Make board_rev a field of RaspiMachineClass hw/arm/raspi: Let class_init() directly call raspi_machine_init() hw/arm/raspi: Set default RAM size to size encoded in board revision hw/arm/raspi: Extract the board model from the board revision hw/arm/raspi: Use a unique raspi_machine_class_init() method hw/arm/raspi: Extract the cores count from the board revision Richard Henderson (20): target/arm: Add arm_mmu_idx_is_stage1_of_2 target/arm: Add mmu_idx for EL1 and EL2 w/ PAN enabled target/arm: Add isar_feature tests for PAN + ATS1E1 target/arm: Move LOR regdefs to file scope target/arm: Split out aarch32_cpsr_valid_mask target/arm: Mask CPSR_J when Jazelle is not enabled target/arm: Replace CPSR_ERET_MASK with aarch32_cpsr_valid_mask target/arm: Use aarch32_cpsr_valid_mask in helper_exception_return target/arm: Remove CPSR_RESERVED target/arm: Introduce aarch64_pstate_valid_mask target/arm: Update MSR access for PAN target/arm: Update arm_mmu_idx_el for PAN target/arm: Enforce PAN semantics in get_S1prot target/arm: Set PAN bit as required on exception entry target/arm: Implement ATS1E1 system registers target/arm: Enable ARMv8.2-ATS1E1 in -cpu max target/arm: Add ID_AA64MMFR2_EL1 target/arm: Update MSR access to UAO target/arm: Implement UAO semantics target/arm: Enable ARMv8.2-UAO in -cpu max Roman Kapl (2): i.MX: Fix inverted register bits in wdt code. i.MX: Add support for WDT on i.MX6 include/hw/arm/aspeed_soc.h | 6 + include/hw/arm/fsl-imx6.h | 3 + target/arm/cpu-param.h| 2 +- target/arm/cpu.h | 95 --- target/arm/internals.h| 85 ++ hw/arm/aspeed_ast2600.c | 23 +++ hw/arm/aspeed_soc.c | 25 +++ hw/arm/fsl-imx6.c | 21 +++ hw/arm/raspi.c| 190 -- hw/arm/virt-acpi-build.c | 25 +-- hw/char/exynos4210_uart.c | 5 +- hw/misc/imx2_wdt.c| 2 +- target/arm/cpu.c | 4 + target/arm/cpu64.c| 10 ++ target/arm/helper-a64.c | 6 +- target/arm/helper.c | 327 +- target/arm/kvm64.c| 2 + target/arm/op_helper.c| 14 +- target/arm/translate-a64.c| 31 target/arm/translate.c| 42 +++-- tests/data/acpi/virt/DSDT |
[PULL 15/46] target/arm: Mask CPSR_J when Jazelle is not enabled
From: Richard Henderson
The J bit signals Jazelle mode, and so of course is RES0
when the feature is not enabled.
Signed-off-by: Richard Henderson
Reviewed-by: Peter Maydell
Message-id: 20200208125816.14954-7-richard.hender...@linaro.org
Signed-off-by: Peter Maydell
---
target/arm/internals.h | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/target/arm/internals.h b/target/arm/internals.h
index 4d4896fcdcf..0569c96fd94 100644
--- a/target/arm/internals.h
+++ b/target/arm/internals.h
@@ -1064,7 +1064,7 @@ static inline bool arm_mmu_idx_is_stage1_of_2(ARMMMUIdx
mmu_idx)
static inline uint32_t aarch32_cpsr_valid_mask(uint64_t features,
const ARMISARegisters *id)
{
-uint32_t valid = CPSR_M | CPSR_AIF | CPSR_IL | CPSR_NZCV | CPSR_J;
+uint32_t valid = CPSR_M | CPSR_AIF | CPSR_IL | CPSR_NZCV;
if ((features >> ARM_FEATURE_V4T) & 1) {
valid |= CPSR_T;
@@ -1078,6 +1078,9 @@ static inline uint32_t aarch32_cpsr_valid_mask(uint64_t
features,
if ((features >> ARM_FEATURE_THUMB2) & 1) {
valid |= CPSR_IT;
}
+if (isar_feature_jazelle(id)) {
+valid |= CPSR_J;
+}
return valid;
}
--
2.20.1
[PULL 03/46] bios-tables-test: prepare to change ARM virt ACPI DSDT
From: Heyi Guo We are going to change ARM virt ACPI DSDT table, which will cause make check to fail, so temporarily add related golden masters to ignore list. Signed-off-by: Heyi Guo Reviewed-by: Michael S. Tsirkin Message-id: 20200204014325.16279-2-guoh...@huawei.com Signed-off-by: Peter Maydell --- tests/qtest/bios-tables-test-allowed-diff.h | 3 +++ 1 file changed, 3 insertions(+) diff --git a/tests/qtest/bios-tables-test-allowed-diff.h b/tests/qtest/bios-tables-test-allowed-diff.h index dfb8523c8bf..32a401ae35f 100644 --- a/tests/qtest/bios-tables-test-allowed-diff.h +++ b/tests/qtest/bios-tables-test-allowed-diff.h @@ -1 +1,4 @@ /* List of comma-separated changed AML files to ignore */ +"tests/data/acpi/virt/DSDT", +"tests/data/acpi/virt/DSDT.memhp", +"tests/data/acpi/virt/DSDT.numamem", -- 2.20.1
[PULL 32/46] hw/char/exynos4210_uart: Fix memleaks in exynos4210_uart_init
From: Chen Qun
It's easy to reproduce as follow:
virsh qemu-monitor-command vm1 --pretty '{"execute": "device-list-properties",
"arguments":{"typename":"exynos4210.uart"}}'
ASAN shows memory leak stack:
#1 0xfffd896d71cb in g_malloc0 (/lib64/libglib-2.0.so.0+0x571cb)
#2 0xaaad270beee3 in timer_new_full /qemu/include/qemu/timer.h:530
#3 0xaaad270beee3 in timer_new /qemu/include/qemu/timer.h:551
#4 0xaaad270beee3 in timer_new_ns /qemu/include/qemu/timer.h:569
#5 0xaaad270beee3 in exynos4210_uart_init /qemu/hw/char/exynos4210_uart.c:677
#6 0xaaad275c8f4f in object_initialize_with_type /qemu/qom/object.c:516
#7 0xaaad275c91bb in object_new_with_type /qemu/qom/object.c:684
#8 0xaaad2755df2f in qmp_device_list_properties /qemu/qom/qom-qmp-cmds.c:152
Reported-by: Euler Robot
Signed-off-by: Chen Qun
Reviewed-by: Philippe Mathieu-Daudé
Message-id: 20200213025603.149432-1-kuhn.chen...@huawei.com
Signed-off-by: Peter Maydell
---
hw/char/exynos4210_uart.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/hw/char/exynos4210_uart.c b/hw/char/exynos4210_uart.c
index 25d6588e413..96d5180e3e2 100644
--- a/hw/char/exynos4210_uart.c
+++ b/hw/char/exynos4210_uart.c
@@ -674,8 +674,6 @@ static void exynos4210_uart_init(Object *obj)
SysBusDevice *dev = SYS_BUS_DEVICE(obj);
Exynos4210UartState *s = EXYNOS4210_UART(dev);
-s->fifo_timeout_timer = timer_new_ns(QEMU_CLOCK_VIRTUAL,
- exynos4210_uart_timeout_int, s);
s->wordtime = NANOSECONDS_PER_SECOND * 10 / 9600;
/* memory mapping */
@@ -691,6 +689,9 @@ static void exynos4210_uart_realize(DeviceState *dev, Error
**errp)
{
Exynos4210UartState *s = EXYNOS4210_UART(dev);
+s->fifo_timeout_timer = timer_new_ns(QEMU_CLOCK_VIRTUAL,
+ exynos4210_uart_timeout_int, s);
+
qemu_chr_fe_set_handlers(>chr, exynos4210_uart_can_receive,
exynos4210_uart_receive, exynos4210_uart_event,
NULL, s, NULL, true);
--
2.20.1
[PULL 26/46] target/arm: Add ID_AA64MMFR2_EL1
From: Richard Henderson
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.
Reviewed-by: Peter Maydell
Signed-off-by: Richard Henderson
Message-id: 20200208125816.14954-18-richard.hender...@linaro.org
Signed-off-by: Peter Maydell
---
target/arm/cpu.h| 17 +
target/arm/helper.c | 4 ++--
target/arm/kvm64.c | 2 ++
3 files changed, 21 insertions(+), 2 deletions(-)
diff --git a/target/arm/cpu.h b/target/arm/cpu.h
index 65a0ef8cd6b..71879393c22 100644
--- a/target/arm/cpu.h
+++ b/target/arm/cpu.h
@@ -871,6 +871,7 @@ struct ARMCPU {
uint64_t id_aa64pfr1;
uint64_t id_aa64mmfr0;
uint64_t id_aa64mmfr1;
+uint64_t id_aa64mmfr2;
} isar;
uint32_t midr;
uint32_t revidr;
@@ -1803,6 +1804,22 @@ FIELD(ID_AA64MMFR1, PAN, 20, 4)
FIELD(ID_AA64MMFR1, SPECSEI, 24, 4)
FIELD(ID_AA64MMFR1, XNX, 28, 4)
+FIELD(ID_AA64MMFR2, CNP, 0, 4)
+FIELD(ID_AA64MMFR2, UAO, 4, 4)
+FIELD(ID_AA64MMFR2, LSM, 8, 4)
+FIELD(ID_AA64MMFR2, IESB, 12, 4)
+FIELD(ID_AA64MMFR2, VARANGE, 16, 4)
+FIELD(ID_AA64MMFR2, CCIDX, 20, 4)
+FIELD(ID_AA64MMFR2, NV, 24, 4)
+FIELD(ID_AA64MMFR2, ST, 28, 4)
+FIELD(ID_AA64MMFR2, AT, 32, 4)
+FIELD(ID_AA64MMFR2, IDS, 36, 4)
+FIELD(ID_AA64MMFR2, FWB, 40, 4)
+FIELD(ID_AA64MMFR2, TTL, 48, 4)
+FIELD(ID_AA64MMFR2, BBM, 52, 4)
+FIELD(ID_AA64MMFR2, EVT, 56, 4)
+FIELD(ID_AA64MMFR2, E0PD, 60, 4)
+
FIELD(ID_DFR0, COPDBG, 0, 4)
FIELD(ID_DFR0, COPSDBG, 4, 4)
FIELD(ID_DFR0, MMAPDBG, 8, 4)
diff --git a/target/arm/helper.c b/target/arm/helper.c
index d99661d4ea5..d29722d8acb 100644
--- a/target/arm/helper.c
+++ b/target/arm/helper.c
@@ -7073,11 +7073,11 @@ void register_cp_regs_for_features(ARMCPU *cpu)
.access = PL1_R, .type = ARM_CP_CONST,
.accessfn = access_aa64_tid3,
.resetvalue = cpu->isar.id_aa64mmfr1 },
-{ .name = "ID_AA64MMFR2_EL1_RESERVED", .state = ARM_CP_STATE_AA64,
+{ .name = "ID_AA64MMFR2_EL1", .state = ARM_CP_STATE_AA64,
.opc0 = 3, .opc1 = 0, .crn = 0, .crm = 7, .opc2 = 2,
.access = PL1_R, .type = ARM_CP_CONST,
.accessfn = access_aa64_tid3,
- .resetvalue = 0 },
+ .resetvalue = cpu->isar.id_aa64mmfr2 },
{ .name = "ID_AA64MMFR3_EL1_RESERVED", .state = ARM_CP_STATE_AA64,
.opc0 = 3, .opc1 = 0, .crn = 0, .crm = 7, .opc2 = 3,
.access = PL1_R, .type = ARM_CP_CONST,
diff --git a/target/arm/kvm64.c b/target/arm/kvm64.c
index fb21ab9e737..3bae9e4a663 100644
--- a/target/arm/kvm64.c
+++ b/target/arm/kvm64.c
@@ -549,6 +549,8 @@ bool kvm_arm_get_host_cpu_features(ARMHostCPUFeatures *ahcf)
ARM64_SYS_REG(3, 0, 0, 7, 0));
err |= read_sys_reg64(fdarray[2], >isar.id_aa64mmfr1,
ARM64_SYS_REG(3, 0, 0, 7, 1));
+err |= read_sys_reg64(fdarray[2], >isar.id_aa64mmfr2,
+ ARM64_SYS_REG(3, 0, 0, 7, 2));
/*
* Note that if AArch32 support is not present in the host,
--
2.20.1
[PULL 08/46] arm/acpi: simplify the description of PCI _CRS
From: Heyi Guo
The original code defines a named object for the resource template but
then returns the resource template object itself; the resulted output
is like below:
Method (_CRS, 0, NotSerialized) // _CRS: Current Resource Settings
{
Name (RBUF, ResourceTemplate ()
{
WordBusNumber (ResourceProducer, MinFixed, MaxFixed, PosDecode,
0x, // Granularity
0x, // Range Minimum
0x00FF, // Range Maximum
0x, // Translation Offset
0x0100, // Length
,, )
..
})
Return (ResourceTemplate ()
{
WordBusNumber (ResourceProducer, MinFixed, MaxFixed, PosDecode,
0x, // Granularity
0x, // Range Minimum
0x00FF, // Range Maximum
0x, // Translation Offset
0x0100, // Length
,, )
..
})
}
So the named object "RBUF" is actually useless. The more natural way
is to return RBUF instead, or simply drop RBUF definition.
Choose the latter one to simplify the code.
Signed-off-by: Heyi Guo
Reviewed-by: Michael S. Tsirkin
Message-id: 20200204014325.16279-7-guoh...@huawei.com
Signed-off-by: Peter Maydell
---
hw/arm/virt-acpi-build.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/hw/arm/virt-acpi-build.c b/hw/arm/virt-acpi-build.c
index f3e340b1729..fb4b166f82c 100644
--- a/hw/arm/virt-acpi-build.c
+++ b/hw/arm/virt-acpi-build.c
@@ -236,7 +236,6 @@ static void acpi_dsdt_add_pci(Aml *scope, const MemMapEntry
*memmap,
size_mmio_high));
}
-aml_append(method, aml_name_decl("RBUF", rbuf));
aml_append(method, aml_return(rbuf));
aml_append(dev, method);
--
2.20.1
