[Qemu-devel] [PATCH resend v4 2/3] ACPI: Add APEI GHES Table Generation support
This implements APEI GHES Table by passing the error CPER info to the guest via a fw_cfg_blob. After a CPER info is recorded, an SEA(Synchronous External Abort)/SEI(SError Interrupt) exception will be injected into the guest OS. Below is the table layout, the max number of error soure is 11, which is classified by notification type. etc/acpi/tables etc/hardware_errors == +---+ +--+ | address | +-> +--+ |HEST + | registers | | | Error Status | + ++ | +-+ | | Data Block 0 | | | GHES0 | --> | |address0 | + | ++ | | GHES1 | --> | |address1 | --+ | | CPER | | | GHES2 | --> | |address2 | + | | | CPER | | | | --> | | ... | | | | | CPER | | | GHES10 | --> | |address10| -+ | | | | CPER | +-++ +-+-+ | | | +-++ | | | | | +---> +--+ | | | Error Status | | | | Data Block 1 | | | | ++ | | | | CPER | | | | | CPER | | | +-++ | | | +-> +--+ | | Error Status | | | Data Block 2 | | | ++ | | | CPER | | +-++ |... +> +--+ | Error Status | | Data Block 10| | ++ | | CPER | | | CPER | | | CPER | +-++ Signed-off-by: Dongjiu Geng --- thanks a lot Laszlo's review and comments: change since v3: 1. remove the unnecessary include for "hw/acpi/vmgenid.h" in hw/arm/virt-acpi-build.c 2. add conversion between LE and host-endian for the CPER record 3. handle the case that run out of the preallocated memory for the CPER record 4. change to use g_malloc0 instead of g_malloc 5. change block_reqr_size name to block_rer_size 6. change QEMU coding style, that is, the operator is at the end of the line. 7. drop the ERROR_STATUS_ADDRESS_OFFSET and GAS_ADDRESS_OFFSET macros (from the header file as well), and use the offsetof to replace it. 8. remove the init_aml_allocator() / free_aml_allocator(), calculate the needed size, and push that many bytes directly to "table_data". 9. take an "OVMF header probe suppressor" into account 10.corrct HEST and CPER value assigment, for example, correct the source_id for every error source, this identifier of source_id should be unique among all error sources; 11. create only one WRITE_POINTER command, for the base address of "etc/hardware_errors". This should be done outside of the loop.The base addresses of the individual error status data blocks should be calculated in ghes_update_guest(), based on the error source / notification type 12.correct the commit message lists error sources / notification types 0 through 10 (count=11 in total). 13.correct the size calculation for GHES_DATA_ADDR_FW_CFG_FILE 14.range-checked the value of "notify" before using it as an array subscript --- hw/acpi/aml-build.c | 2 + hw/acpi/hest_ghes.c | 219 +++ hw/arm/virt-acpi-build.c | 6 ++ 3 files changed, 227 insertions(+) create mode 100644 hw/acpi/hest_ghes.c diff --git a/hw/acpi/aml-build.c b/hw/acpi/aml-build.c index c6f2032..802b98d 100644 --- a/hw/acpi/aml-build.c +++ b/hw/acpi/aml-build.c @@ -1560,6 +1560,7 @@ void acpi_build_tables_init(AcpiBuildTables *tables) tables->table_data = g_array_new(false, true /* clear */, 1); tables->tcpalog = g_array_new(false, true /* clear */, 1); tables->vmgenid = g_array_new(false, true /* clear */, 1); +tables->hardware_errors = g_array_new(false, true /* clear */, 1); tables->linker = bios_linker_loader_init(); } @@ -1570,6 +1571,7 @@ void acpi_build_tables_cleanup(AcpiBuildTables *tables, bool mfre) g_array_free(tables->table_
[Qemu-devel] [PATCH resend v4 3/3] ACPI: build and enable APEI GHES in the Makefile and configuration
Add CONFIG_ACPI_APEI configuration in the Makefile and enable it in the arm-softmmu.mak Signed-off-by: Dongjiu Geng --- thanks a lot Laszlo's review and comments: change since v3: (1) change name to "CONFIG_ACPI_APEI" from CONFIG_ACPI_APEI_GENERATION --- default-configs/arm-softmmu.mak | 1 + hw/acpi/Makefile.objs | 1 + 2 files changed, 2 insertions(+) diff --git a/default-configs/arm-softmmu.mak b/default-configs/arm-softmmu.mak index 1e3bd2b..ee6f5fc 100644 --- a/default-configs/arm-softmmu.mak +++ b/default-configs/arm-softmmu.mak @@ -121,3 +121,4 @@ CONFIG_ACPI=y CONFIG_SMBIOS=y CONFIG_ASPEED_SOC=y CONFIG_GPIO_KEY=y +CONFIG_ACPI_APEI=y diff --git a/hw/acpi/Makefile.objs b/hw/acpi/Makefile.objs index 11c35bc..bafb148 100644 --- a/hw/acpi/Makefile.objs +++ b/hw/acpi/Makefile.objs @@ -6,6 +6,7 @@ common-obj-$(CONFIG_ACPI_MEMORY_HOTPLUG) += memory_hotplug.o common-obj-$(CONFIG_ACPI_CPU_HOTPLUG) += cpu.o common-obj-$(CONFIG_ACPI_NVDIMM) += nvdimm.o common-obj-$(CONFIG_ACPI_VMGENID) += vmgenid.o +common-obj-$(CONFIG_ACPI_APEI) += hest_ghes.o common-obj-$(call lnot,$(CONFIG_ACPI_X86)) += acpi-stub.o common-obj-y += acpi_interface.o -- 2.10.1
[Qemu-devel] [PATCH resend v4 1/3] ACPI: Add new ACPI structures and macros
(1) Add related APEI/HEST table structures and macros, these
definition refer to ACPI 6.1 and UEFI 2.6 spec.
(2) Add generic error status block and CPER memory section
definition, user space only handle memory section errors.
Signed-off-by: Dongjiu Geng
---
thanks Laszlo and Michael's review:
(1) separate the original one patch into three patches: one is new
ACPI structures and macros, another is C source file to generate ACPI HEST
table and dynamically record CPER ,final patch is the change about Makefile
and configuration
(2) add comments about where the ACPI structures and macros come from, for
example,
they come from the UEFI Spec 2.6, ""; ACPI 6.1 spec,
"xx".
(3) correct the macros name, for emaple, prefix some macro names with
"UEFI_".
(4) remove the uuid_le struct and use the QemuUUID in the include/qemu/uuid.h"
(5) remove the duplicate ACPI address space, because it already defined in
the "include/hw/acpi/aml-build.h"
(6) remove the acpi_generic_address structure because same definition exists in
the
AcpiGenericAddress.
(7) rename the struct acpi_hest_notify to AcpiHestNotifyType
(8) rename the struct acpi_hest_types to AcpiHestSourceType
(9) rename enum constants AcpiHestSourceType to ACPI_HEST_SOURCE_xxx from
ACPI_HEST_TYPE_xxx
(10) remove the NOT_USED{3,4,5} enum constants in the AcpiHestSourceType.
(11) add missed QEMU_PACKED for the struct definition.
(12) remove the defnition of AcpiGenericErrorData, and rename the
AcpiGenericErrorDataV300 to AcpiGenericErrorData.
(13) use the QemuUUID type for the "section_type" field AcpiGenericErrorData,
and rename it
to section_type_le.
(14) moving type AcpiGenericErrorSeverity above AcpiGenericErrorData and
AcpiGenericErrorDataV300, and remarking on the "error_severity" fields
that they take their values from AcpiGenericErrorSeverity
(15) remove the wrongly call to BERT(Boot Error Record Table)
(16) add comments for the struction member, for example, pint out that
the block_status member in the AcpiGenericErrorStatus is a bitmask
composed of ACPI_GEBS_xxx macros
(17) remove the hardware error source notification type list, and rename
the MAX_ERROR_SOURCE_COUNT_V6 to ACPI_HEST_NOTIFY_RESERVED.
(18) remove the physical_addr member of GhesErrorState
(19) change the "uint64_t ghes_addr_le[8]" in GhesErrorState to uint64_t
ghes_addr_le
(20) change the second parameter to "error_physical_addr" in the
ghes_update_guest
API statement
---
include/hw/acpi/acpi-defs.h | 194
include/hw/acpi/aml-build.h | 1 +
include/hw/acpi/hest_ghes.h | 47 +++
include/qemu/uuid.h | 11 +++
4 files changed, 253 insertions(+)
create mode 100644 include/hw/acpi/hest_ghes.h
diff --git a/include/hw/acpi/acpi-defs.h b/include/hw/acpi/acpi-defs.h
index 4cc3630..0756339 100644
--- a/include/hw/acpi/acpi-defs.h
+++ b/include/hw/acpi/acpi-defs.h
@@ -15,6 +15,7 @@
#ifndef QEMU_ACPI_DEFS_H
#define QEMU_ACPI_DEFS_H
+#include "qemu/uuid.h"
enum {
ACPI_FADT_F_WBINVD,
ACPI_FADT_F_WBINVD_FLUSH,
@@ -295,6 +296,44 @@ typedef struct AcpiMultipleApicTable AcpiMultipleApicTable;
#define ACPI_APIC_GENERIC_TRANSLATOR15
#define ACPI_APIC_RESERVED 16 /* 16 and greater are reserved */
+/* UEFI Spec 2.6, "N.2.5 Memory Error Section */
+#define UEFI_CPER_MEM_VALID_ERROR_STATUS 0x0001
+#define UEFI_CPER_MEM_VALID_PA 0x0002
+#define UEFI_CPER_MEM_VALID_PA_MASK 0x0004
+#define UEFI_CPER_MEM_VALID_NODE 0x0008
+#define UEFI_CPER_MEM_VALID_CARD 0x0010
+#define UEFI_CPER_MEM_VALID_MODULE 0x0020
+#define UEFI_CPER_MEM_VALID_BANK 0x0040
+#define UEFI_CPER_MEM_VALID_DEVICE 0x0080
+#define UEFI_CPER_MEM_VALID_ROW 0x0100
+#define UEFI_CPER_MEM_VALID_COLUMN 0x0200
+#define UEFI_CPER_MEM_VALID_BIT_POSITION 0x0400
+#define UEFI_CPER_MEM_VALID_REQUESTOR0x0800
+#define UEFI_CPER_MEM_VALID_RESPONDER0x1000
+#define UEFI_CPER_MEM_VALID_TARGET 0x2000
+#define UEFI_CPER_MEM_VALID_ERROR_TYPE 0x4000
+#define UEFI_CPER_MEM_VALID_RANK_NUMBER 0x8000
+#define UEFI_CPER_MEM_VALID_CARD_HANDLE 0x1
+#define UEFI_CPER_MEM_VALID_MODULE_HANDLE0x2
+#define UEFI_CPER_MEM_ERROR_TYPE_MULTI_ECC 3
+
+/* This is from the ACPI 6.1 spec, "18.3.2.9 Hardware Error Notification" */
+
+enum AcpiHestNotifyType {
+ACPI_HEST_NOTIFY_POLLED = 0,
+ACPI_HEST_NOTIFY_EXTERNAL = 1,
+ACPI_HEST_NOTIFY_LOCAL = 2,
+ACPI_HEST_NOTIFY_SCI = 3,
+ACPI_HEST_NOTIFY_NMI = 4,
+ACPI_HEST_NOTIFY_CMCI = 5, /* ACPI 5.0 */
+ACPI_HEST_NOTIFY_MCE = 6, /* ACPI 5.0 */
+ACPI_HEST_NOTIFY_GPIO = 7, /* ACPI 6.0 */
+ACPI_HEST_NOTIFY_SEA = 8, /* ACPI 6.1 */
+ACPI_HEST_NOTIFY_SEI = 9, /* ACPI 6.1 */
+ACPI_HEST_NOTIFY_GSIV = 10, /* ACPI 6.1 */
+ACPI_HE
[Qemu-devel] [PATCH resend v4 0/3] Generate APEI GHES table and dynamically record CPER
In the armv8 platform, the mainly hardware error source are ARMv8 SEA/SEI/GSIV. For the ARMv8 SEA/SEI, the KVM or host kernel will signal SIGBUS or use other interface to notify user space, such as Qemu. After Qemu gets the notification, it will record the CPER and inject the SEA/SEI to KVM. this series of patches will generate APEI table when guest OS boot up, and dynamically record CPER for the guest OS about the generic hardware errors how to test: 1. In the guest OS, use this command to dump the APEI table: "iasl -p ./HEST -d /sys/firmware/acpi/tables/HEST" 2. And find the address for the generic error status block according to the notification type 3. then find the CPER record through the generic error status block. For example(notification type is SEA): (1) root@genericarmv8:~# iasl -p ./HEST -d /sys/firmware/acpi/tables/HEST (2) root@genericarmv8:~# cat HEST.dsl /* * Intel ACPI Component Architecture * AML/ASL+ Disassembler version 20170303 (64-bit version) * Copyright (c) 2000 - 2017 Intel Corporation * * Disassembly of /sys/firmware/acpi/tables/HEST, Mon Dec 12 07:19:43 2016 * * ACPI Data Table [HEST] * * Format: [HexOffset DecimalOffset ByteLength] FieldName : FieldValue */ .. [228h 0552 2]Subtable Type : 0009 [Generic Hardware Error Source] [22Ah 0554 2]Source Id : 0008 [22Ch 0556 2]Related Source Id : [22Eh 0558 1] Reserved : 00 [22Fh 0559 1] Enabled : 01 [230h 0560 4] Records To Preallocate : 0001 [234h 0564 4] Max Sections Per Record : 0001 [238h 0568 4] Max Raw Data Length : 1000 [23Ch 0572 12] Error Status Address : [Generic Address Structure] [23Ch 0572 1] Space ID : 00 [SystemMemory] [23Dh 0573 1]Bit Width : 40 [23Eh 0574 1] Bit Offset : 00 [23Fh 0575 1] Encoded Access Width : 04 [QWord Access:64] [240h 0576 8] Address : 785D0040 [248h 0584 28] Notify : [Hardware Error Notification Structure] [248h 0584 1] Notify Type : 08 [SEA] [249h 0585 1]Notify Length : 1C [24Ah 0586 2] Configuration Write Enable : [24Ch 0588 4] PollInterval : [250h 0592 4] Vector : [254h 0596 4] Polling Threshold Value : [258h 0600 4] Polling Threshold Window : [25Ch 0604 4]Error Threshold Value : [260h 0608 4] Error Threshold Window : [264h 0612 4]Error Status Block Length : 1000 . (3) according to above table, the address that contains the physical address of a block of memory that holds the error status data for SEA notification error source is 0x785D0040 (4) the address for SEA notification error source is 0x785d8058 (qemu) xp /2x 0x785D0040 785d0040: 0x785d8058 0x (5) check the content of generic error status block and generic error data entry (qemu) xp /100x 0x785d8058 785d8058: 0x0001 0x 0x 0x0098 785d8068: 0x0001 0xa5bc1114 0x4ede6f64 0x833e63b8 785d8078: 0xb1837ced 0x 0x 0x0050 785d8088: 0x 0x 0x 0x 785d8098: 0x 0x 0x 0x 785d80a8: 0x 0x 0x 0x4002 785d80b8: 0x 0x 0x 0x 785d80c8: 0x 0x 0x 0x 785d80d8: 0x 0x 0x 0x 785d80e8: 0x 0x 0x 0x 785d80f8: 0x 0x0003 0x 0x 785d8108: 0x 0x 0x 0x 785d8118: 0x 0x 0x 0x 785d8128: 0x 0x 0x 0x 785d8138: 0x 0x 0x 0x Dongjiu Geng (3): ACPI: Add new ACPI structures and macros ACPI: Add APEI GHES Table Generation support ACPI: build and enable APEI GHES in the Makefile and configuration default-configs/arm-softmmu.mak | 1 + hw/acpi/Makefile.objs | 1 + hw/acpi/aml-build.c | 2 + hw/acpi/hest_ghes.c
[Qemu-devel] Prime Day: solo per oggi una giornata di promozioni Amazon!
Se non visualizzi correttamente questa email clicca:http://email.mailtoshop.com/c/eJxVjsFuwyAQRL_G3IJ2lwDhwCGy3ZvVSv2AiASILRmTOqRW_75EyiXSHGbe4Wm8jZeoJJssAWrQiKBIEHBCPABvqe-x7bUUoNsOTLOH5Ka55PuYb_ySExstRaOcQO_kOXqBDrxH7WN0MkBFhiVLe6ONBDbbsZRbI44NfdRs28bfdRUCQEOSoOuHup6vnlDo3asO7edw-lqnFDr3d_rOsczTEu58LImt9iekx86H3zDXq0tersuD5_XKik1VT0r9A9KqRzI";>qui.
Scopri le migliori promozioni del giorno, aggiungi d...@mailtoshop.com
alla tua rubrica.
http://email.mailtoshop.com/c/eJwVjk0OgyAUhE8ju5LHQ3iyYNFYe4CmFzDgXwJiFev1S5PJTL7FZMbb0Y1ascUiCAISAjRKBI5CNMBb7DrRdqQkUPsAU9UQ-yXkdMxp4y5FNlskp5VXGqhRBA56J70yYPrG1SS0ZtFibcgoYMHOOW-VvFf4LLqui1-Sp30q8H4Vm3MMdcmQ0jFwnz3b7WeI580P3yGU9TWt03r-KyzbWA6g1j9Kujij";>
Prime Day su Amazon.it
.ReadMsgBody {
width: 100%;
}
.ExternalClass {
width: 100%;
}
http://email.mailtoshop.com/c/eJwVj7GOhDAMRL8Guo0chwQoUqxY6K67q5GBsCCRhIPsIt3Xn1cay3rjKcaTncfZ6Hy1CLKEUkowqBAESlmBaLBtZdOWWkHZPKDOCvC0bimeS9zFGH2-WKICiMpaI7pxGAaDANUIOOipkG6k3Fssar5Dvtklpf3M1D3DjnVdlyBPfzGINTF_xYl4DTyHmzP1SHEP9O7PFA-XaOiZe2IdR7wy1a2OMz_fXZWhCXH6kNYSsTKgJHuJnmz5T1nuekOZH_bX-ddtcm-38TMhhmd4iXg882Q9Z9CYf8fLU2w";>http://email.mailtoshop.com/c/eJwdT8tuhDAM_BpyI3IMJMshB8SyPW1XKpeqFxRIeEgkoRB66Nc3VPJ4RmPJHms5DiMvyCIRmADBGHDMECgydgNaY9OwuhFFBqK-Q5nkYNWyBn_MfqODt2SWTOQMNZa8ZGOmRsHLnvUcRQ_aZKA4sRLzUpQFkFXOIWxHklUJPmJZao1eVKqs-vXu2hfNxarJHFG8RcAttm33-hzC5R1-DOvi_ufNFSVy2zIRqXpWX6_39Pm6V7RrP2P8rv1ALBKsC-jo5iayy29jz1SbH7PGV5x3kzup3ycSpI3XkfM_2VxQIA";
alt="" width="176" height="auto" />
http://email.mailtoshop.com/c/eJwVjk1uhSAUhVcjs5LLRUAHDF58uoJ2ATxFIQGhijXt6stLTs7P4CTfotd5lYJ4jcAUKMZAIkegyFgHdMBxZMOoBAc1PKFvWojGh5JOlzKdUyROd4ZzA7ZdUHGFYgHZWrFaRKHMS9oXiRrbXvUCSNCulNzwR4NT1X3f1ETzl3bqS91bruZseMd8nSVFe9S6-DMH80tdieF95JO3DX9-fU5dg9LETA79beP1sdgfGyrinvZtv2g6NlJ0rJQo5T_fyUWo;nodeId=201050620&tag=mshopcom-21";>RESI
GRATUITI Soggetto a limitazioni
http://email.mailtoshop.com/c/eJwVjktuwyAURVcDs6DH42cPGESOvYJ2AWDwRzKQJqSWuvpi6U7O0R2cYJd50YruFoEbMJyDRoHAkPMO2IDjyIfRKAFmeEBPJCS3H7W8t_Jkc0l0szwqjLg47b0zc9BeemX6Lmh0i5Rxpsmi7E2vgB52q_X5JuJOcGo7z5O55P5KZntt7C8tpj0S8fj-mjqCOpdwkQEQvTAgeHPVrU2lq6El3JDTl_2J6XML8TcerTGXvOYPK6-VVpvaB7X-B80fRAM";>
http://email.mailtoshop.com/c/eJxFj8FugzAQRL8mvsVaG2zDwQcLnBaphKpEUdsLcoIhVBgokErt19f0Uml3Z_QOq5laNteGM9RJCkSAIAQ4DShgSkgEOKFak0QLFoBIUoh3ITjT9eu43MYJX0eHbjIitaCsEfwaXWx9MSCYDQPSxE1teUMD5CQNYxEzQL28reu07AK1owc_Djtbd2ZvnPkZh-2fh50zrV28efBLY39Urt6L4_6gysesOG7UZ_XyD55firz40yzXqXrzVm9BNzR3zqbmm4hK5yp7qlRZFkmmTrqsOIHXEKDKTrg6M2BhxHgQV_hjatEsP62772v7ZXtfexiHdrjjcW7RKp1PSjn_Bcr4Wzw";
alt="Amazon Fashion;" width="610" />
Questa email ti è stata inviata da Mailtoshop e dai suoi partner perchè
ti sei iscritto o hai partecipato ad una delle nostre iniziative.
Se non vuoi più ricevere le nostre offerte, promozioni e sconti,la
cancellazione è semplice,basta un solo click http://email.mailtoshop.com/u/eJwNzEkSwiAQAMDXyE1qZlgGDpwwD0lYklQF0Gh8v_YDOoeaqjViDwTIwIhgSRFIQnQgI00TxomNAo4P8DcNbd6Pz3hv4ynTaGILGRd2BbS2S6mZqc4OE8zolS7sFhAtkPbsDYgzvEq77rl8y_Gv-uhrv-Q41x-G_iZf";>qui.
Re: [Qemu-devel] [RFC v2 0/8] VIRTIO-IOMMU device
Hi Jean,
> -Original Message-
> From: Jean-Philippe Brucker [mailto:jean-philippe.bruc...@arm.com]
> Sent: Friday, July 07, 2017 8:50 PM
> To: Bharat Bhushan ; Auger Eric
> ; eric.auger@gmail.com;
> peter.mayd...@linaro.org; alex.william...@redhat.com; m...@redhat.com;
> qemu-...@nongnu.org; qemu-devel@nongnu.org
> Cc: w...@redhat.com; kevin.t...@intel.com; marc.zyng...@arm.com;
> t...@semihalf.com; will.dea...@arm.com; drjo...@redhat.com;
> robin.mur...@arm.com; christoffer.d...@linaro.org
> Subject: Re: [Qemu-devel] [RFC v2 0/8] VIRTIO-IOMMU device
>
> On 07/07/17 12:36, Bharat Bhushan wrote:
> >>> In this proposal, QEMU reserves a iova-range for guest (not host) and
> guest
> >> kernel will use this as msi-iova untranslated (IOMMU_RESV_MSI). While
> this
> >> does not change host interface and it will continue to use host reserved
> >> mapping for actual interrupt generation, no?
> >> But then userspace needs to provide IOMMU_RESV_MSI range to guest
> >> kernel, right? What would be the proposed manner?
> >
> > Just an opinion, we can define feature
> (VIRTIO_IOMMU_F_RES_MSI_RANGE) and provide this info via a command
> (VIRTIO_IOMMU_T_MSI_RANGE). Guest iommu-driver will make this call
> during initialization and store the value. This value will just replace
> MSI_IOVA_BASE and MSI_IOVA_LENGHT hash define. Rest will remain same
> in virtio-iommu driver.
>
> Yes I had something similar in mind, although more generic since we'll
> need to get other bits of information from the device in future extensions
> (fault handling, page table formats and dynamic reserves of memory for
> SVM), and maybe also for finding out per-address-space page granularity
> (see my reply of patch 3/8). These are per-endpoint properties that cannot
> be advertise in the virtio config space.
>
> ***
>
> So I propose to add a per-endpoint probing mechanism on the request
> queue:
What is per-endpoint? Is it "per-pci/platform-device"?
>
> * The device advertises a new command VIRTIO_IOMMU_T_PROBE with
> feature
> bit VIRTIO_IOMMU_F_PROBE.
> * When this feature is advertised, the device sets probe_size field in the
> the config space.
Probably I did not get how virtio-iommu device emulation decides value of
"probe_size", can you share more info?
> * When device offers VIRTIO_IOMMU_F_PROBE, the driver should send an
> VIRTIO_IOMMU_T_PROBE request for each new endpoint.
> * The driver allocates a device-writeable buffer of probe_size (plus
> framing) and sends it as a VIRTIO_IOMMU_T_PROBE request.
> * The device fills the buffer with various information.
>
> struct virtio_iommu_req_probe {
> /* device-readable */
> struct virtio_iommu_req_head head;
> le32 device;
> le32 flags;
>
> /* maybe also le32 content_size, but it must be equal to
> probe_size */
Can you please describe why we need to pass size of "probe_size" in probe
request?
>
> /* device-writeable */
> u8 content[];
I assume content_size above is the size of array "content[]" and max value can
be equal to probe_size advertised by device?
> struct virtio_iommu_req_tail tail;
> };
>
> I'm still struggling with the content and layout of the probe request, and
> would appreciate any feedback. To be easily extended, I think it should
> contain a list of fields of variable size:
>
> |0 15|16 31|32 N|
> | type |length | values |
>
> 'length' might be made optional if it can be deduced from type, but might
> make driver-side parsing more robust.
>
> The probe could either be done for each endpoint, or for each address
> space. I much prefer endpoint because it is the smallest granularity. The
> driver can then decide what endpoints to put together in the same address
> space based on their individual capabilities. The specification would
> described how each endpoint property is combined when endpoints are put
> in
> the same address space. For example, take the minimum of all PASID size,
> the maximum of all page granularities, combine doorbell addresses, etc.
>
> If we did the probe on address spaces instead, the driver would have to
> re-send a probe request each time a new endpoint is attached to an
> existing address space, to see if it is still capable of page table
> handover or if the driver just combined a VFIO and an emulated endpoint by
> accident.
>
> ***
>
> Using this framework, the device can declare doorbell regions by adding
> one or more RESV fields into the probe buffer:
>
> /* 'type' */
> #define VIRTIO_IOMMU_PROBE_T_RESV 0x1
>
> /* 'values'. 'length' is sizeof(struct virtio_iommu_probe_resv) */
> struct virtio_iommu_probe_resv {
> le64 gpa;
> le64 size;
>
> #define VIRTIO_IOMMU_PROBE_RESV_MSI 0x1
> u8 type;
type is 16 bit above?
> };
>
> Such a region would be subject to the following rules:
>
> * Drive
[Qemu-devel] [PATCH qemu v3] vfio-pci, ppc64/spapr: Reorder group-to-container attaching
At the moment VFIO PCI device initialization works as follows: vfio_realize vfio_get_group vfio_connect_container register memory listeners (1) update QEMU groups lists vfio_kvm_device_add_group Then (example for pseries) the machine reset hook triggers region_add() for all regions where listeners from (1) are listening: ppc_spapr_reset spapr_phb_reset spapr_tce_table_enable memory_region_add_subregion vfio_listener_region_add vfio_spapr_create_window This scheme works fine until we need to handle VFIO PCI device hotplug and we want to enable PPC64/sPAPR in-kernel TCE acceleration on, i.e. after PCI hotplug we need a place to call ioctl(vfio_kvm_device_fd, KVM_DEV_VFIO_GROUP_SET_SPAPR_TCE). Since the ioctl needs a LIOBN fd (from sPAPRTCETable) and a IOMMU group fd (from VFIOGroup), vfio_listener_region_add() seems to be the only place for this ioctl(). However this only works during boot time because the machine reset happens strictly after all devices are finalized. When hotplug happens, vfio_listener_region_add() is called when a memory listener is registered but when this happens: 1. new group is not added to the container->group_list yet; 2. VFIO KVM device is unaware of the new IOMMU group. This moves bits around to have all necessary VFIO infrastructure in place for both initial startup and hotplug cases. Signed-off-by: Alexey Kardashevskiy Reviewed-by: David Gibson --- This is an independend part of a bigger patchset to enable in-kernel acceleration of TCE operations. While I stuck with IOMMU MR QOM-fication, let's try to parallel patchset pieces' review/acceptance. --- Changes: v3: * rebased on current upstream v2: * moved container->initialized back to its correct location * added missing QLIST_REMOVE() --- hw/vfio/common.c | 19 +++ 1 file changed, 11 insertions(+), 8 deletions(-) diff --git a/hw/vfio/common.c b/hw/vfio/common.c index 2965b68e5d..4e75dc8c56 100644 --- a/hw/vfio/common.c +++ b/hw/vfio/common.c @@ -1107,6 +1107,14 @@ static int vfio_connect_container(VFIOGroup *group, AddressSpace *as, goto free_container_exit; } +vfio_kvm_device_add_group(group); + +QLIST_INIT(&container->group_list); +QLIST_INSERT_HEAD(&space->containers, container, next); + +group->container = container; +QLIST_INSERT_HEAD(&container->group_list, group, container_next); + container->listener = vfio_memory_listener; memory_listener_register(&container->listener, container->space->as); @@ -1120,14 +1128,11 @@ static int vfio_connect_container(VFIOGroup *group, AddressSpace *as, container->initialized = true; -QLIST_INIT(&container->group_list); -QLIST_INSERT_HEAD(&space->containers, container, next); - -group->container = container; -QLIST_INSERT_HEAD(&container->group_list, group, container_next); - return 0; listener_release_exit: +QLIST_REMOVE(group, container_next); +QLIST_REMOVE(container, next); +vfio_kvm_device_del_group(group); vfio_listener_release(container); free_container_exit: @@ -1232,8 +1237,6 @@ VFIOGroup *vfio_get_group(int groupid, AddressSpace *as, Error **errp) QLIST_INSERT_HEAD(&vfio_group_list, group, next); -vfio_kvm_device_add_group(group); - return group; close_fd_exit: -- 2.11.0
Re: [Qemu-devel] [PATCH] tests: check-qom-proplist: fix leak
Copying qemu-trivial. Marc-André Lureau writes: > user_creatable_add_opts() returns a reference (the other reference is > for the root parent/child link). > > Leak introduced in commit a1af255f065cc. > > Signed-off-by: Marc-André Lureau > --- > tests/check-qom-proplist.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/tests/check-qom-proplist.c b/tests/check-qom-proplist.c > index 8e432e9ab6..a3cd7ab29f 100644 > --- a/tests/check-qom-proplist.c > +++ b/tests/check-qom-proplist.c > @@ -428,6 +428,8 @@ static void test_dummy_createcmdl(void) > g_assert(err == NULL); > error_free(err); > > +object_unref(OBJECT(dobj)); > + > /* > * cmdline-parsing via qemu_opts_parse() results in a QemuOpts entry > * corresponding to the Object's ID to be added to the QemuOptsList Reviewed-by: Markus Armbruster
[Qemu-devel] [Bug 1703506] [NEW] SMT not supported by QEMU on AMD Ryzen CPU
Public bug reported: HyperThreading/SMT is supported by AMD Ryzen CPUs but results in this message when setting the topology to threads=2: qemu-system-x86_64: AMD CPU doesn't support hyperthreading. Please configure -smp options properly. Checking in a Windows 10 guest reveals that SMT is not enabled, and from what I understand, QEMU converts the topology from threads to cores internally on AMD CPUs. This appears to cause performance problems in the guest perhaps because programs are assuming that these threads are actual cores. Software: Linux 4.12, qemu 2.9.0 host with KVM enabled, Windows 10 pro guest ** 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/1703506 Title: SMT not supported by QEMU on AMD Ryzen CPU Status in QEMU: New Bug description: HyperThreading/SMT is supported by AMD Ryzen CPUs but results in this message when setting the topology to threads=2: qemu-system-x86_64: AMD CPU doesn't support hyperthreading. Please configure -smp options properly. Checking in a Windows 10 guest reveals that SMT is not enabled, and from what I understand, QEMU converts the topology from threads to cores internally on AMD CPUs. This appears to cause performance problems in the guest perhaps because programs are assuming that these threads are actual cores. Software: Linux 4.12, qemu 2.9.0 host with KVM enabled, Windows 10 pro guest To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1703506/+subscriptions
[Qemu-devel] [PULL 08/17] spapr: Add DRC release method
At the moment, spapr_drc_release() has an ugly switch on the DRC type to
call the right, device-specific release function. This cleans it up by
doing that via a proper QOM method.
It's still arguably an abstraction violation for the DRC code to call into
the specific device code, but one mess at a time.
Signed-off-by: David Gibson
Reviewed-by: Laurent Vivier
Reviewed-by: Greg Kurz
---
hw/ppc/spapr_drc.c | 22 ++
include/hw/ppc/spapr_drc.h | 1 +
2 files changed, 7 insertions(+), 16 deletions(-)
diff --git a/hw/ppc/spapr_drc.c b/hw/ppc/spapr_drc.c
index c831aa3..aa37a47 100644
--- a/hw/ppc/spapr_drc.c
+++ b/hw/ppc/spapr_drc.c
@@ -370,22 +370,9 @@ void spapr_drc_attach(sPAPRDRConnector *drc, DeviceState
*d, void *fdt,
static void spapr_drc_release(sPAPRDRConnector *drc)
{
-/* Calling release callbacks based on spapr_drc_type(drc). */
-switch (spapr_drc_type(drc)) {
-case SPAPR_DR_CONNECTOR_TYPE_CPU:
-spapr_core_release(drc->dev);
-break;
-case SPAPR_DR_CONNECTOR_TYPE_PCI:
-spapr_phb_remove_pci_device_cb(drc->dev);
-break;
-case SPAPR_DR_CONNECTOR_TYPE_LMB:
-spapr_lmb_release(drc->dev);
-break;
-case SPAPR_DR_CONNECTOR_TYPE_PHB:
-case SPAPR_DR_CONNECTOR_TYPE_VIO:
-default:
-g_assert(false);
-}
+sPAPRDRConnectorClass *drck = SPAPR_DR_CONNECTOR_GET_CLASS(drc);
+
+drck->release(drc->dev);
drc->awaiting_release = false;
g_free(drc->fdt);
@@ -631,6 +618,7 @@ static void spapr_drc_cpu_class_init(ObjectClass *k, void
*data)
drck->typeshift = SPAPR_DR_CONNECTOR_TYPE_SHIFT_CPU;
drck->typename = "CPU";
drck->drc_name_prefix = "CPU ";
+drck->release = spapr_core_release;
}
static void spapr_drc_pci_class_init(ObjectClass *k, void *data)
@@ -640,6 +628,7 @@ static void spapr_drc_pci_class_init(ObjectClass *k, void
*data)
drck->typeshift = SPAPR_DR_CONNECTOR_TYPE_SHIFT_PCI;
drck->typename = "28";
drck->drc_name_prefix = "C";
+drck->release = spapr_phb_remove_pci_device_cb;
}
static void spapr_drc_lmb_class_init(ObjectClass *k, void *data)
@@ -649,6 +638,7 @@ static void spapr_drc_lmb_class_init(ObjectClass *k, void
*data)
drck->typeshift = SPAPR_DR_CONNECTOR_TYPE_SHIFT_LMB;
drck->typename = "MEM";
drck->drc_name_prefix = "LMB ";
+drck->release = spapr_lmb_release;
}
static const TypeInfo spapr_dr_connector_info = {
diff --git a/include/hw/ppc/spapr_drc.h b/include/hw/ppc/spapr_drc.h
index d9cacb3..6fd84d1 100644
--- a/include/hw/ppc/spapr_drc.h
+++ b/include/hw/ppc/spapr_drc.h
@@ -217,6 +217,7 @@ typedef struct sPAPRDRConnectorClass {
sPAPRDREntitySense (*dr_entity_sense)(sPAPRDRConnector *drc);
uint32_t (*isolate)(sPAPRDRConnector *drc);
uint32_t (*unisolate)(sPAPRDRConnector *drc);
+void (*release)(DeviceState *dev);
/* QEMU interfaces for managing hotplug operations */
bool (*release_pending)(sPAPRDRConnector *drc);
--
2.9.4
[Qemu-devel] [PULL 04/17] spapr: fix migration to pseries machine < 2.8
From: Laurent Vivier
since commit 5c4537bd ("spapr: Fix 2.7<->2.8 migration of PCI host bridge"),
some migration fields are forged from the new ones in spapr_pci_pre_save().
It works well, except when the number of MSI devices is 0,
because in this case the function exits immediately.
This fix moves the migration code before the exit code.
The problem can be reproduced with these commands:
source qemu-2.9:
qemu-system-ppc64 -monitor stdio -M pseries-2.6 -nodefaults -S
destination qemu-2.6:
qemu-system-ppc64 -monitor stdio -M pseries-2.6 -nodefaults \
-incoming tcp:0:
on the source:
migrate tcp:localhost:
Destination fails with the following error:
qemu-system-ppc64: error while loading state for
instance 0x0 of device 'spapr_pci'
qemu-system-ppc64: load of migration failed: Invalid argument
Signed-off-by: Laurent Vivier
Reviewed-by: Greg Kurz
Signed-off-by: David Gibson
---
hw/ppc/spapr_pci.c | 28 ++--
1 file changed, 14 insertions(+), 14 deletions(-)
diff --git a/hw/ppc/spapr_pci.c b/hw/ppc/spapr_pci.c
index 3b37dcd..f09b4e1 100644
--- a/hw/ppc/spapr_pci.c
+++ b/hw/ppc/spapr_pci.c
@@ -1873,20 +1873,6 @@ static void spapr_pci_pre_save(void *opaque)
gpointer key, value;
int i;
-g_free(sphb->msi_devs);
-sphb->msi_devs = NULL;
-sphb->msi_devs_num = g_hash_table_size(sphb->msi);
-if (!sphb->msi_devs_num) {
-return;
-}
-sphb->msi_devs = g_malloc(sphb->msi_devs_num * sizeof(spapr_pci_msi_mig));
-
-g_hash_table_iter_init(&iter, sphb->msi);
-for (i = 0; g_hash_table_iter_next(&iter, &key, &value); ++i) {
-sphb->msi_devs[i].key = *(uint32_t *) key;
-sphb->msi_devs[i].value = *(spapr_pci_msi *) value;
-}
-
if (sphb->pre_2_8_migration) {
sphb->mig_liobn = sphb->dma_liobn[0];
sphb->mig_mem_win_addr = sphb->mem_win_addr;
@@ -1900,6 +1886,20 @@ static void spapr_pci_pre_save(void *opaque)
sphb->mig_mem_win_size += sphb->mem64_win_size;
}
}
+
+g_free(sphb->msi_devs);
+sphb->msi_devs = NULL;
+sphb->msi_devs_num = g_hash_table_size(sphb->msi);
+if (!sphb->msi_devs_num) {
+return;
+}
+sphb->msi_devs = g_malloc(sphb->msi_devs_num * sizeof(spapr_pci_msi_mig));
+
+g_hash_table_iter_init(&iter, sphb->msi);
+for (i = 0; g_hash_table_iter_next(&iter, &key, &value); ++i) {
+sphb->msi_devs[i].key = *(uint32_t *) key;
+sphb->msi_devs[i].value = *(spapr_pci_msi *) value;
+}
}
static int spapr_pci_post_load(void *opaque, int version_id)
--
2.9.4
[Qemu-devel] [PULL 02/17] spapr: refresh "platform-specific" hcalls comment
From: Greg Kurz
We have more of these since the addition of KVMPPC_H_LOGICAL_MEMOP in 2012.
Signed-off-by: Greg Kurz
Reviewed-by: Thomas Huth
Signed-off-by: David Gibson
---
include/hw/ppc/spapr.h | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/include/hw/ppc/spapr.h b/include/hw/ppc/spapr.h
index 12bf969..a184ffa 100644
--- a/include/hw/ppc/spapr.h
+++ b/include/hw/ppc/spapr.h
@@ -377,9 +377,8 @@ struct sPAPRMachineState {
* as well.
*
* We also need some hcalls which are specific to qemu / KVM-on-POWER.
- * So far we just need one for H_RTAS, but in future we'll need more
- * for extensions like virtio. We put those into the 0xf000-0xfffc
- * range which is reserved by PAPR for "platform-specific" hcalls.
+ * We put those into the 0xf000-0xfffc range which is reserved by PAPR
+ * for "platform-specific" hcalls.
*/
#define KVMPPC_HCALL_BASE 0xf000
#define KVMPPC_H_RTAS (KVMPPC_HCALL_BASE + 0x0)
--
2.9.4
[Qemu-devel] [PULL 16/17] spapr: introduce the XIVE_EXPLOIT option in CAS
From: Cédric Le Goater
On POWER9, the Client Architecture Support (CAS) negotiation process
determines whether the guest operates in XIVE Legacy compatibility
(the former POWER8 interrupt model) or in XIVE exploitation mode (the
newer POWER9 interrupt model).
Bit 7 of Byte 23 of vector 5 is used for this purpose.
Signed-off-by: Cédric Le Goater
Signed-off-by: David Gibson
---
hw/ppc/spapr.c | 13 +++--
include/hw/ppc/spapr_ovec.h | 1 +
2 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
index ba8f57a..ff78a22 100644
--- a/hw/ppc/spapr.c
+++ b/hw/ppc/spapr.c
@@ -910,7 +910,8 @@ static void spapr_dt_ov5_platform_support(void *fdt, int
chosen)
{
PowerPCCPU *first_ppc_cpu = POWERPC_CPU(first_cpu);
-char val[2 * 3] = {
+char val[2 * 4] = {
+23, 0x00, /* Xive mode: 0 = legacy (as in ISA 2.7), 1 = Exploitation */
24, 0x00, /* Hash/Radix, filled in below. */
25, 0x00, /* Hash options: Segment Tables == no, GTSE == no. */
26, 0x40, /* Radix options: GTSE == yes. */
@@ -918,19 +919,19 @@ static void spapr_dt_ov5_platform_support(void *fdt, int
chosen)
if (kvm_enabled()) {
if (kvmppc_has_cap_mmu_radix() && kvmppc_has_cap_mmu_hash_v3()) {
-val[1] = 0x80; /* OV5_MMU_BOTH */
+val[3] = 0x80; /* OV5_MMU_BOTH */
} else if (kvmppc_has_cap_mmu_radix()) {
-val[1] = 0x40; /* OV5_MMU_RADIX_300 */
+val[3] = 0x40; /* OV5_MMU_RADIX_300 */
} else {
-val[1] = 0x00; /* Hash */
+val[3] = 0x00; /* Hash */
}
} else {
if (first_ppc_cpu->env.mmu_model & POWERPC_MMU_V3) {
/* V3 MMU supports both hash and radix (with dynamic switching) */
-val[1] = 0xC0;
+val[3] = 0xC0;
} else {
/* Otherwise we can only do hash */
-val[1] = 0x00;
+val[3] = 0x00;
}
}
_FDT(fdt_setprop(fdt, chosen, "ibm,arch-vec-5-platform-support",
diff --git a/include/hw/ppc/spapr_ovec.h b/include/hw/ppc/spapr_ovec.h
index f088833..0b464e2 100644
--- a/include/hw/ppc/spapr_ovec.h
+++ b/include/hw/ppc/spapr_ovec.h
@@ -50,6 +50,7 @@ typedef struct sPAPROptionVector sPAPROptionVector;
#define OV5_DRCONF_MEMORY OV_BIT(2, 2)
#define OV5_FORM1_AFFINITY OV_BIT(5, 0)
#define OV5_HP_EVT OV_BIT(6, 5)
+#define OV5_XIVE_EXPLOITOV_BIT(23, 7)
/* ISA 3.00 MMU features: */
#define OV5_MMU_BOTHOV_BIT(24, 0) /* Radix and hash */
--
2.9.4
[Qemu-devel] [PULL 15/17] ppc/kvm: have the "family" CPU alias to point to TYPE_HOST_POWERPC_CPU
From: Greg Kurz
When running KVM on POWER, we allow the user to pass "-cpu POWERx" instead
of "-cpu host". This is achieved by patching the ppc_cpu_aliases[] array
so that "POWERx" points to the CPU class with the same PVR as the host CPU.
This causes CPUs to be instantiated from this CPU class instead of the
TYPE_HOST_POWERPC_CPU class which is used with "-cpu host". These CPUs thus
miss all the KVM specific tuning from kvmppc_host_cpu_class_init().
This currently causes QEMU with "-cpu POWER9" to fail when running KVM on a
POWER9 DD1 host:
qemu-system-ppc64: Register sync failed... If you're using kvm-hv.ko, only
"-cpu host" is possible
kvm_init_vcpu failed: Invalid argument
Let's have the "POWERx" alias to point to TYPE_HOST_POWERPC_CPU directly,
so that "-cpu POWERx" instantiates CPUs from the same class as "-cpu host".
Signed-off-by: Greg Kurz
Tested-by: Laurent Vivier
Reviewed-by: Laurent Vivier
Reviewed-by: Thomas Huth
Signed-off-by: David Gibson
---
target/ppc/kvm.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/target/ppc/kvm.c b/target/ppc/kvm.c
index f2f7c53..f7a7ea5 100644
--- a/target/ppc/kvm.c
+++ b/target/ppc/kvm.c
@@ -2445,6 +2445,7 @@ static int kvm_ppc_register_host_cpu_type(void)
.class_init = kvmppc_host_cpu_class_init,
};
PowerPCCPUClass *pvr_pcc;
+ObjectClass *oc;
DeviceClass *dc;
int i;
@@ -2455,6 +2456,9 @@ static int kvm_ppc_register_host_cpu_type(void)
type_info.parent = object_class_get_name(OBJECT_CLASS(pvr_pcc));
type_register(&type_info);
+oc = object_class_by_name(type_info.name);
+g_assert(oc);
+
#if defined(TARGET_PPC64)
type_info.name = g_strdup_printf("%s-"TYPE_SPAPR_CPU_CORE, "host");
type_info.parent = TYPE_SPAPR_CPU_CORE,
@@ -2474,7 +2478,6 @@ static int kvm_ppc_register_host_cpu_type(void)
dc = DEVICE_CLASS(ppc_cpu_get_family_class(pvr_pcc));
for (i = 0; ppc_cpu_aliases[i].alias != NULL; i++) {
if (strcmp(ppc_cpu_aliases[i].alias, dc->desc) == 0) {
-ObjectClass *oc = OBJECT_CLASS(pvr_pcc);
char *suffix;
ppc_cpu_aliases[i].model = g_strdup(object_class_get_name(oc));
--
2.9.4
[Qemu-devel] [PULL 13/17] spapr: fix memory hotplug error path
From: Greg Kurz
QEMU shouldn't abort if spapr_add_lmbs()->spapr_drc_attach() fails.
Let's propagate the error instead, like it is done everywhere else
where spapr_drc_attach() is called.
Signed-off-by: Greg Kurz
Reviewed-by: Daniel Barboza
Signed-off-by: David Gibson
---
hw/ppc/spapr.c | 26 ++
1 file changed, 22 insertions(+), 4 deletions(-)
diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
index 70b3fd3..ba8f57a 100644
--- a/hw/ppc/spapr.c
+++ b/hw/ppc/spapr.c
@@ -2601,6 +2601,7 @@ static void spapr_add_lmbs(DeviceState *dev, uint64_t
addr_start, uint64_t size,
int i, fdt_offset, fdt_size;
void *fdt;
uint64_t addr = addr_start;
+Error *local_err = NULL;
for (i = 0; i < nr_lmbs; i++) {
drc = spapr_drc_by_id(TYPE_SPAPR_DRC_LMB,
@@ -2611,7 +2612,18 @@ static void spapr_add_lmbs(DeviceState *dev, uint64_t
addr_start, uint64_t size,
fdt_offset = spapr_populate_memory_node(fdt, node, addr,
SPAPR_MEMORY_BLOCK_SIZE);
-spapr_drc_attach(drc, dev, fdt, fdt_offset, errp);
+spapr_drc_attach(drc, dev, fdt, fdt_offset, &local_err);
+if (local_err) {
+while (addr > addr_start) {
+addr -= SPAPR_MEMORY_BLOCK_SIZE;
+drc = spapr_drc_by_id(TYPE_SPAPR_DRC_LMB,
+ addr / SPAPR_MEMORY_BLOCK_SIZE);
+spapr_drc_detach(drc, dev, NULL);
+}
+g_free(fdt);
+error_propagate(errp, local_err);
+return;
+}
addr += SPAPR_MEMORY_BLOCK_SIZE;
}
/* send hotplug notification to the
@@ -2651,14 +2663,20 @@ static void spapr_memory_plug(HotplugHandler
*hotplug_dev, DeviceState *dev,
addr = object_property_get_uint(OBJECT(dimm),
PC_DIMM_ADDR_PROP, &local_err);
if (local_err) {
-pc_dimm_memory_unplug(dev, &ms->hotplug_memory, mr);
-goto out;
+goto out_unplug;
}
spapr_add_lmbs(dev, addr, size, node,
spapr_ovec_test(ms->ov5_cas, OV5_HP_EVT),
- &error_abort);
+ &local_err);
+if (local_err) {
+goto out_unplug;
+}
+
+return;
+out_unplug:
+pc_dimm_memory_unplug(dev, &ms->hotplug_memory, mr);
out:
error_propagate(errp, local_err);
}
--
2.9.4
[Qemu-devel] [PULL 14/17] spapr: Only report host/guest IOMMU page size mismatches on KVM
We print a warning if the spapr IOMMU isn't configured to support a page
size matching the host page size backing RAM. When that's the case we need
more complex logic to translate VFIO mappings, which is slower.
But, it's not so slow that it would be at all noticeable against the
general slowness of TCG. So, only warn when using KVM. This removes some
noisy and unhelpful warnings from make check on hosts with page sizes
which typically differ from those on POWER (e.g. Sparc).
Reported-by: Peter Maydell
Signed-off-by: David Gibson
Reviewed-by: Thomas Huth
---
hw/ppc/spapr_pci.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/hw/ppc/spapr_pci.c b/hw/ppc/spapr_pci.c
index cc1588d..a52dcf8 100644
--- a/hw/ppc/spapr_pci.c
+++ b/hw/ppc/spapr_pci.c
@@ -1745,7 +1745,8 @@ static void spapr_phb_realize(DeviceState *dev, Error
**errp)
}
/* DMA setup */
-if ((sphb->page_size_mask & qemu_getrampagesize()) == 0) {
+if (((sphb->page_size_mask & qemu_getrampagesize()) == 0)
+&& kvm_enabled()) {
error_report("System page size 0x%lx is not enabled in page_size_mask "
"(0x%"PRIx64"). Performance may be slow",
qemu_getrampagesize(), sphb->page_size_mask);
--
2.9.4
[Qemu-devel] [PULL 17/17] spapr: populate device tree depending on XIVE_EXPLOIT option
From: Cédric Le Goater
When XIVE is supported, the device tree should be populated
accordingly and the XIVE memory regions mapped to activate MMIOs.
Depending on the design we choose, we could also allocate different
ICS and ICP objects, or switch between objects. This needs to be
discussed.
Signed-off-by: Cédric Le Goater
Signed-off-by: David Gibson
---
hw/ppc/spapr.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
index ff78a22..f4e011c 100644
--- a/hw/ppc/spapr.c
+++ b/hw/ppc/spapr.c
@@ -778,6 +778,11 @@ static int spapr_dt_cas_updates(sPAPRMachineState *spapr,
void *fdt,
}
}
+/* /interrupt controller */
+if (!spapr_ovec_test(ov5_updates, OV5_XIVE_EXPLOIT)) {
+spapr_dt_xics(xics_max_server_number(), fdt, PHANDLE_XICP);
+}
+
offset = fdt_path_offset(fdt, "/chosen");
if (offset < 0) {
offset = fdt_add_subnode(fdt, 0, "chosen");
@@ -801,7 +806,7 @@ int spapr_h_cas_compose_response(sPAPRMachineState *spapr,
size -= sizeof(hdr);
-/* Create sceleton */
+/* Create skeleton */
fdt_skel = g_malloc0(size);
_FDT((fdt_create(fdt_skel, size)));
_FDT((fdt_begin_node(fdt_skel, "")));
@@ -1069,9 +1074,6 @@ static void *spapr_build_fdt(sPAPRMachineState *spapr,
_FDT(fdt_setprop_cell(fdt, 0, "#address-cells", 2));
_FDT(fdt_setprop_cell(fdt, 0, "#size-cells", 2));
-/* /interrupt controller */
-spapr_dt_xics(xics_max_server_number(), fdt, PHANDLE_XICP);
-
ret = spapr_populate_memory(spapr, fdt);
if (ret < 0) {
error_report("couldn't setup memory nodes in fdt");
--
2.9.4
[Qemu-devel] [PULL 09/17] spapr: Remove unnecessary differences between hotplug and coldplug paths
spapr_drc_attach() has a 'coldplug' parameter which sets the DRC into
configured state initially, instead of the usual ISOLATED/UNUSABLE state.
It turns out this is unnecessary: although coldplugged devices do need to
be in CONFIGURED state once the guest starts, that will already be
accomplished by the reset code which will move DRCs for already plugged
devices into a coldplug equivalent state.
Signed-off-by: David Gibson
Reviewed-by: Laurent Vivier
Reviewed-by: Greg Kurz
---
hw/ppc/spapr.c | 13 +++--
hw/ppc/spapr_drc.c | 5 ++---
hw/ppc/spapr_pci.c | 3 +--
include/hw/ppc/spapr_drc.h | 2 +-
4 files changed, 7 insertions(+), 16 deletions(-)
diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
index 4fa982d..70b3fd3 100644
--- a/hw/ppc/spapr.c
+++ b/hw/ppc/spapr.c
@@ -2611,7 +2611,7 @@ static void spapr_add_lmbs(DeviceState *dev, uint64_t
addr_start, uint64_t size,
fdt_offset = spapr_populate_memory_node(fdt, node, addr,
SPAPR_MEMORY_BLOCK_SIZE);
-spapr_drc_attach(drc, dev, fdt, fdt_offset, !dev->hotplugged, errp);
+spapr_drc_attach(drc, dev, fdt, fdt_offset, errp);
addr += SPAPR_MEMORY_BLOCK_SIZE;
}
/* send hotplug notification to the
@@ -2956,17 +2956,10 @@ static void spapr_core_plug(HotplugHandler
*hotplug_dev, DeviceState *dev,
g_assert(drc || !mc->has_hotpluggable_cpus);
-/*
- * Setup CPU DT entries only for hotplugged CPUs. For boot time or
- * coldplugged CPUs DT entries are setup in spapr_build_fdt().
- */
-if (dev->hotplugged) {
-fdt = spapr_populate_hotplug_cpu_dt(cs, &fdt_offset, spapr);
-}
+fdt = spapr_populate_hotplug_cpu_dt(cs, &fdt_offset, spapr);
if (drc) {
-spapr_drc_attach(drc, dev, fdt, fdt_offset, !dev->hotplugged,
- &local_err);
+spapr_drc_attach(drc, dev, fdt, fdt_offset, &local_err);
if (local_err) {
g_free(fdt);
error_propagate(errp, local_err);
diff --git a/hw/ppc/spapr_drc.c b/hw/ppc/spapr_drc.c
index aa37a47..f34355d 100644
--- a/hw/ppc/spapr_drc.c
+++ b/hw/ppc/spapr_drc.c
@@ -340,7 +340,7 @@ static void prop_get_fdt(Object *obj, Visitor *v, const
char *name,
}
void spapr_drc_attach(sPAPRDRConnector *drc, DeviceState *d, void *fdt,
- int fdt_start_offset, bool coldplug, Error **errp)
+ int fdt_start_offset, Error **errp)
{
trace_spapr_drc_attach(spapr_drc_index(drc));
@@ -351,12 +351,11 @@ void spapr_drc_attach(sPAPRDRConnector *drc, DeviceState
*d, void *fdt,
if (spapr_drc_type(drc) == SPAPR_DR_CONNECTOR_TYPE_PCI) {
g_assert(drc->allocation_state == SPAPR_DR_ALLOCATION_STATE_USABLE);
}
-g_assert(fdt || coldplug);
+g_assert(fdt);
drc->dev = d;
drc->fdt = fdt;
drc->fdt_start_offset = fdt_start_offset;
-drc->configured = coldplug;
if (spapr_drc_type(drc) != SPAPR_DR_CONNECTOR_TYPE_PCI) {
drc->awaiting_allocation = true;
diff --git a/hw/ppc/spapr_pci.c b/hw/ppc/spapr_pci.c
index f09b4e1..49c8db8 100644
--- a/hw/ppc/spapr_pci.c
+++ b/hw/ppc/spapr_pci.c
@@ -1435,8 +1435,7 @@ static void spapr_phb_hot_plug_child(HotplugHandler
*plug_handler,
goto out;
}
-spapr_drc_attach(drc, DEVICE(pdev), fdt, fdt_start_offset,
- !plugged_dev->hotplugged, &local_err);
+spapr_drc_attach(drc, DEVICE(pdev), fdt, fdt_start_offset, &local_err);
if (local_err) {
goto out;
}
diff --git a/include/hw/ppc/spapr_drc.h b/include/hw/ppc/spapr_drc.h
index 6fd84d1..d15e9eb 100644
--- a/include/hw/ppc/spapr_drc.h
+++ b/include/hw/ppc/spapr_drc.h
@@ -234,7 +234,7 @@ int spapr_drc_populate_dt(void *fdt, int fdt_offset, Object
*owner,
uint32_t drc_type_mask);
void spapr_drc_attach(sPAPRDRConnector *drc, DeviceState *d, void *fdt,
- int fdt_start_offset, bool coldplug, Error **errp);
+ int fdt_start_offset, Error **errp);
void spapr_drc_detach(sPAPRDRConnector *drc, DeviceState *d, Error **errp);
#endif /* HW_SPAPR_DRC_H */
--
2.9.4
[Qemu-devel] [PULL 05/17] target-ppc: SPR_BOOKE_ESR not set on FP exceptions
From: Aaron Larson
Properly set the book E exception syndrome register when a floating
point exception occurs.
Currently on a book E processor, the POWERPC_EXCP_FP exception handler
fails to set "env->spr[SPR_BOOKE_ESR] = ESR_FP;" as required by the
book E specification.
Signed-off-by: Aaron Larson
Signed-off-by: David Gibson
---
target/ppc/excp_helper.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/target/ppc/excp_helper.c b/target/ppc/excp_helper.c
index 3a9f086..e6009e7 100644
--- a/target/ppc/excp_helper.c
+++ b/target/ppc/excp_helper.c
@@ -283,6 +283,7 @@ static inline void powerpc_excp(PowerPCCPU *cpu, int
excp_model, int excp)
* precise in the MSR.
*/
msr |= 0x0010;
+env->spr[SPR_BOOKE_ESR] = ESR_FP;
break;
case POWERPC_EXCP_INVAL:
LOG_EXCP("Invalid instruction at " TARGET_FMT_lx "\n", env->nip);
--
2.9.4
[Qemu-devel] [PULL 10/17] spapr: Use unplug_request for PCI hot unplug
AIUI, ->unplug_request in the HotplugHandler is used for "soft"
unplug, where acknowledgement from the guest is required before
completing the unplug, whereas ->unplug is used for "hard" unplug
where qemu unilaterally removes the device, and the guest just has to
cope with its sudden absence. For spapr we (correctly) use
->unplug_request for CPU and memory hot unplug but we use ->unplug for
PCI.
While I think it might be possible to support "hard" PCI unplug within
the PAPR model, that's not how it actually works now. Although it's
called from ->unplug, the PCI unplug path will usually just mark the
device for removal, with completion of the unplug delayed until
userspace responds to the unplug notification. If the guest doesn't
respond as expected, that could delay the unplug completion arbitrarily
long.
To reflect that, change the PCI unplug path to be called from
->unplug_request. We also rename spapr_phb_hot_plug_child() and
spapr_phb_hot_unplug_child() to spapr_pci_plug() and
spapr_pci_unplug_request() to more obviously reflect the callbacks they're
implementing.
Signed-off-by: David Gibson
Reviewed-by: Laurent Vivier
Reviewed-by: Greg Kurz
---
hw/ppc/spapr_pci.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/hw/ppc/spapr_pci.c b/hw/ppc/spapr_pci.c
index 49c8db8..cc1588d 100644
--- a/hw/ppc/spapr_pci.c
+++ b/hw/ppc/spapr_pci.c
@@ -1388,8 +1388,8 @@ static uint32_t spapr_phb_get_pci_drc_index(sPAPRPHBState
*phb,
return spapr_drc_index(drc);
}
-static void spapr_phb_hot_plug_child(HotplugHandler *plug_handler,
- DeviceState *plugged_dev, Error **errp)
+static void spapr_pci_plug(HotplugHandler *plug_handler,
+ DeviceState *plugged_dev, Error **errp)
{
sPAPRPHBState *phb = SPAPR_PCI_HOST_BRIDGE(DEVICE(plug_handler));
PCIDevice *pdev = PCI_DEVICE(plugged_dev);
@@ -1469,8 +1469,8 @@ out:
}
}
-static void spapr_phb_hot_unplug_child(HotplugHandler *plug_handler,
- DeviceState *plugged_dev, Error **errp)
+static void spapr_pci_unplug_request(HotplugHandler *plug_handler,
+ DeviceState *plugged_dev, Error **errp)
{
sPAPRPHBState *phb = SPAPR_PCI_HOST_BRIDGE(DEVICE(plug_handler));
PCIDevice *pdev = PCI_DEVICE(plugged_dev);
@@ -1485,6 +1485,7 @@ static void spapr_phb_hot_unplug_child(HotplugHandler
*plug_handler,
}
g_assert(drc);
+g_assert(drc->dev == plugged_dev);
drck = SPAPR_DR_CONNECTOR_GET_CLASS(drc);
if (!drck->release_pending(drc)) {
@@ -1972,8 +1973,8 @@ static void spapr_phb_class_init(ObjectClass *klass, void
*data)
/* Supported by TYPE_SPAPR_MACHINE */
dc->user_creatable = true;
set_bit(DEVICE_CATEGORY_BRIDGE, dc->categories);
-hp->plug = spapr_phb_hot_plug_child;
-hp->unplug = spapr_phb_hot_unplug_child;
+hp->plug = spapr_pci_plug;
+hp->unplug_request = spapr_pci_unplug_request;
}
static const TypeInfo spapr_phb_info = {
--
2.9.4
[Qemu-devel] [PULL 03/17] spapr: fix bogus function name in comment
From: Greg Kurz
$ git grep spapr_ppc_reset
hw/ppc/spapr.c: * as part of spapr_ppc_reset().
$ git grep ppc_spapr_reset
hw/ppc/spapr.c:static void ppc_spapr_reset(void)
hw/ppc/spapr.c:mc->reset = ppc_spapr_reset;
hw/ppc/spapr_hcall.c:/* If ppc_spapr_reset() did not set up a HPT
but one is necessary
Signed-off-by: Greg Kurz
Signed-off-by: David Gibson
---
hw/ppc/spapr.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
index 65d8ad2..5acfb47 100644
--- a/hw/ppc/spapr.c
+++ b/hw/ppc/spapr.c
@@ -1973,7 +1973,7 @@ static void spapr_boot_set(void *opaque, const char
*boot_device,
* Unlike PCI DR devices, LMB DR devices explicitly register this reset
* routine. Reset for PCI DR devices will be handled by PHB reset routine
* when it walks all its children devices. LMB devices reset occurs
- * as part of spapr_ppc_reset().
+ * as part of ppc_spapr_reset().
*/
static void spapr_drc_reset(void *opaque)
{
--
2.9.4
[Qemu-devel] [PULL 06/17] spapr: Leave DR-indicator management to the guest
The DR-indicator is essentially a "virtual LED" attached to a hotpluggable
device, which the guest can set to various states for the attention of
the operator or management layers.
It's mostly guest managed, except that we once-off set it to
ACTIVE/INACTIVE in the attach/detach path. While that makes certain sense,
there's no indication in PAPR that the hypervisor should do this, and the
drmgr code on the guest side doesn't appear to need it (it will already set
the indicator to ACTIVE on hotplug, and INACTIVE on remove).
So, leave the DR-indicator entirely to the guest; the only thing we need
to do is ensure it's in a sane state on reset.
Signed-off-by: David Gibson
Reviewed-by: Laurent Vivier
Reviewed-by: Greg Kurz
---
hw/ppc/spapr_drc.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/hw/ppc/spapr_drc.c b/hw/ppc/spapr_drc.c
index bd40b84..22d4d81 100644
--- a/hw/ppc/spapr_drc.c
+++ b/hw/ppc/spapr_drc.c
@@ -353,8 +353,6 @@ void spapr_drc_attach(sPAPRDRConnector *drc, DeviceState
*d, void *fdt,
}
g_assert(fdt || coldplug);
-drc->dr_indicator = SPAPR_DR_INDICATOR_ACTIVE;
-
drc->dev = d;
drc->fdt = fdt;
drc->fdt_start_offset = fdt_start_offset;
@@ -372,8 +370,6 @@ void spapr_drc_attach(sPAPRDRConnector *drc, DeviceState
*d, void *fdt,
static void spapr_drc_release(sPAPRDRConnector *drc)
{
-drc->dr_indicator = SPAPR_DR_INDICATOR_INACTIVE;
-
/* Calling release callbacks based on spapr_drc_type(drc). */
switch (spapr_drc_type(drc)) {
case SPAPR_DR_CONNECTOR_TYPE_CPU:
@@ -454,12 +450,14 @@ static void reset(DeviceState *d)
if (spapr_drc_type(drc) != SPAPR_DR_CONNECTOR_TYPE_PCI) {
drc->allocation_state = SPAPR_DR_ALLOCATION_STATE_USABLE;
}
+drc->dr_indicator = SPAPR_DR_INDICATOR_ACTIVE;
} else {
/* Otherwise device is absent, but might be hotplugged */
drc->isolation_state = SPAPR_DR_ISOLATION_STATE_ISOLATED;
if (spapr_drc_type(drc) != SPAPR_DR_CONNECTOR_TYPE_PCI) {
drc->allocation_state = SPAPR_DR_ALLOCATION_STATE_UNUSABLE;
}
+drc->dr_indicator = SPAPR_DR_INDICATOR_INACTIVE;
}
}
--
2.9.4
[Qemu-devel] [PULL 11/17] target/ppc: Refactor tcg radix mmu code
From: Suraj Jitindar Singh
The mmu-radix64.c file implements functions to enable the radix mmu
emulation in tcg mode. There is a function ppc_radix64_walk_tree() which
performs the radix tree walk and also implicitly checks the pte
protection.
Move the protection checking of the pte from the ppc_radix64_walk_tree()
function into the caller. This means the ppc_radix64_walk_tree() function
can be used without protection checking which is useful for debugging.
ppc_radix64_walk_tree() no longer needs to take the rwx and prot variables.
Signed-off-by: Suraj Jitindar Singh
Signed-off-by: David Gibson
---
target/ppc/mmu-radix64.c | 22 --
1 file changed, 8 insertions(+), 14 deletions(-)
diff --git a/target/ppc/mmu-radix64.c b/target/ppc/mmu-radix64.c
index 69fde65..1a650fd 100644
--- a/target/ppc/mmu-radix64.c
+++ b/target/ppc/mmu-radix64.c
@@ -147,11 +147,10 @@ static void ppc_radix64_set_rc(PowerPCCPU *cpu, int rwx,
uint64_t pte,
}
}
-static uint64_t ppc_radix64_walk_tree(PowerPCCPU *cpu, int rwx, vaddr eaddr,
+static uint64_t ppc_radix64_walk_tree(PowerPCCPU *cpu, vaddr eaddr,
uint64_t base_addr, uint64_t nls,
hwaddr *raddr, int *psize,
- int *fault_cause, int *prot,
- hwaddr *pte_addr)
+ int *fault_cause, hwaddr *pte_addr)
{
CPUState *cs = CPU(cpu);
uint64_t index, pde;
@@ -177,10 +176,6 @@ static uint64_t ppc_radix64_walk_tree(PowerPCCPU *cpu, int
rwx, vaddr eaddr,
uint64_t rpn = pde & R_PTE_RPN;
uint64_t mask = (1UL << *psize) - 1;
-if (ppc_radix64_check_prot(cpu, rwx, pde, fault_cause, prot)) {
-return 0; /* Protection Denied Access */
-}
-
/* Or high bits of rpn and low bits to ea to form whole real addr */
*raddr = (rpn & ~mask) | (eaddr & mask);
*pte_addr = base_addr + (index * sizeof(pde));
@@ -188,9 +183,8 @@ static uint64_t ppc_radix64_walk_tree(PowerPCCPU *cpu, int
rwx, vaddr eaddr,
}
/* Next Level of Radix Tree */
-return ppc_radix64_walk_tree(cpu, rwx, eaddr, pde & R_PDE_NLB,
- pde & R_PDE_NLS, raddr, psize,
- fault_cause, prot, pte_addr);
+return ppc_radix64_walk_tree(cpu, eaddr, pde & R_PDE_NLB, pde & R_PDE_NLS,
+ raddr, psize, fault_cause, pte_addr);
}
int ppc_radix64_handle_mmu_fault(PowerPCCPU *cpu, vaddr eaddr, int rwx,
@@ -241,11 +235,11 @@ int ppc_radix64_handle_mmu_fault(PowerPCCPU *cpu, vaddr
eaddr, int rwx,
/* Walk Radix Tree from Process Table Entry to Convert EA to RA */
page_size = PRTBE_R_GET_RTS(prtbe0);
-pte = ppc_radix64_walk_tree(cpu, rwx, eaddr & R_EADDR_MASK,
+pte = ppc_radix64_walk_tree(cpu, eaddr & R_EADDR_MASK,
prtbe0 & PRTBE_R_RPDB, prtbe0 & PRTBE_R_RPDS,
-&raddr, &page_size, &fault_cause, &prot,
-&pte_addr);
-if (!pte) {
+&raddr, &page_size, &fault_cause, &pte_addr);
+if (!pte || ppc_radix64_check_prot(cpu, rwx, pte, &fault_cause, &prot)) {
+/* Couldn't get pte or access denied due to protection */
ppc_radix64_raise_si(cpu, rwx, eaddr, fault_cause);
return 1;
}
--
2.9.4
[Qemu-devel] [PULL 12/17] target/ppc: Add debug function for radix mmu translation
From: Suraj Jitindar Singh
In target/ppc/mmu-hash64.c there already exists the function
ppc_hash64_get_phys_page_debug() to get the physical (real) address for
a given effective address in hash mode.
Implement the function ppc_radix64_get_phys_page_debug() to allow a real
address to be obtained for a given effective address in radix mode.
This is used when a debugger is attached to qemu.
Previously we just had a comment saying this is unimplemented which then
fell through to the default case and caused an abort due to
unrecognised mmu model as the default had no case for the V3 mmu, which
was misleading at best.
We reuse ppc_radix64_walk_tree() which is used by the radix fault
handler since the process of walking the radix tree is identical.
Reported-by: Balbir Singh
Signed-off-by: Suraj Jitindar Singh
Signed-off-by: David Gibson
---
target/ppc/mmu-radix64.c | 45 +
target/ppc/mmu-radix64.h | 1 +
target/ppc/mmu_helper.c | 3 ++-
3 files changed, 48 insertions(+), 1 deletion(-)
diff --git a/target/ppc/mmu-radix64.c b/target/ppc/mmu-radix64.c
index 1a650fd..bbd37e3 100644
--- a/target/ppc/mmu-radix64.c
+++ b/target/ppc/mmu-radix64.c
@@ -251,3 +251,48 @@ int ppc_radix64_handle_mmu_fault(PowerPCCPU *cpu, vaddr
eaddr, int rwx,
prot, mmu_idx, 1UL << page_size);
return 0;
}
+
+hwaddr ppc_radix64_get_phys_page_debug(PowerPCCPU *cpu, target_ulong eaddr)
+{
+CPUState *cs = CPU(cpu);
+CPUPPCState *env = &cpu->env;
+PPCVirtualHypervisorClass *vhc =
+PPC_VIRTUAL_HYPERVISOR_GET_CLASS(cpu->vhyp);
+hwaddr raddr, pte_addr;
+uint64_t lpid = 0, pid = 0, offset, size, patbe, prtbe0, pte;
+int page_size, fault_cause = 0;
+
+/* Handle Real Mode */
+if (msr_dr == 0) {
+/* In real mode top 4 effective addr bits (mostly) ignored */
+return eaddr & 0x0FFFULL;
+}
+
+/* Virtual Mode Access - get the fully qualified address */
+if (!ppc_radix64_get_fully_qualified_addr(env, eaddr, &lpid, &pid)) {
+return -1;
+}
+
+/* Get Process Table */
+patbe = vhc->get_patbe(cpu->vhyp);
+
+/* Index Process Table by PID to Find Corresponding Process Table Entry */
+offset = pid * sizeof(struct prtb_entry);
+size = 1ULL << ((patbe & PATBE1_R_PRTS) + 12);
+if (offset >= size) {
+/* offset exceeds size of the process table */
+return -1;
+}
+prtbe0 = ldq_phys(cs->as, (patbe & PATBE1_R_PRTB) + offset);
+
+/* Walk Radix Tree from Process Table Entry to Convert EA to RA */
+page_size = PRTBE_R_GET_RTS(prtbe0);
+pte = ppc_radix64_walk_tree(cpu, eaddr & R_EADDR_MASK,
+prtbe0 & PRTBE_R_RPDB, prtbe0 & PRTBE_R_RPDS,
+&raddr, &page_size, &fault_cause, &pte_addr);
+if (!pte) {
+return -1;
+}
+
+return raddr & TARGET_PAGE_MASK;
+}
diff --git a/target/ppc/mmu-radix64.h b/target/ppc/mmu-radix64.h
index 1d5c7cf..0ecf063 100644
--- a/target/ppc/mmu-radix64.h
+++ b/target/ppc/mmu-radix64.h
@@ -46,6 +46,7 @@
int ppc_radix64_handle_mmu_fault(PowerPCCPU *cpu, vaddr eaddr, int rwx,
int mmu_idx);
+hwaddr ppc_radix64_get_phys_page_debug(PowerPCCPU *cpu, target_ulong addr);
static inline int ppc_radix64_get_prot_eaa(uint64_t pte)
{
diff --git a/target/ppc/mmu_helper.c b/target/ppc/mmu_helper.c
index 65d1c86..b7b9088 100644
--- a/target/ppc/mmu_helper.c
+++ b/target/ppc/mmu_helper.c
@@ -30,6 +30,7 @@
#include "helper_regs.h"
#include "qemu/error-report.h"
#include "mmu-book3s-v3.h"
+#include "mmu-radix64.h"
//#define DEBUG_MMU
//#define DEBUG_BATS
@@ -1432,7 +1433,7 @@ hwaddr ppc_cpu_get_phys_page_debug(CPUState *cs, vaddr
addr)
return ppc_hash64_get_phys_page_debug(cpu, addr);
case POWERPC_MMU_VER_3_00:
if (ppc64_radix_guest(ppc_env_get_cpu(env))) {
-/* TODO - Unsupported */
+return ppc_radix64_get_phys_page_debug(cpu, addr);
} else {
return ppc_hash64_get_phys_page_debug(cpu, addr);
}
--
2.9.4
[Qemu-devel] [PULL 00/17] ppc-for-2.10 queue 20170711
The following changes since commit 6b06e3e49eb8c91cc286c16d6bf3181ac296f33d: Merge remote-tracking branch 'remotes/ericb/tags/pull-nbd-2017-07-10-v2' into staging (2017-07-10 16:12:47 +0100) are available in the git repository at: git://github.com/dgibson/qemu.git tags/ppc-for-2.10-20170711 for you to fetch changes up to b87680427e8a3ff682f66514e99a8344e7437247: spapr: populate device tree depending on XIVE_EXPLOIT option (2017-07-11 11:04:02 +1000) ppc patch queue 2017-07-11 * Several minor cleanups from Greg Kurz * Fix for migration of pseries-2.7 and earlier machine types * More reworking of the DRC hotplug code, fixing several problems though there are still more to go * Fixes for CPU family / alias handling on POWER9 * Preliminary patches for POWER9 XIVE (new interrupt controller) support * Assorted other fixes Aaron Larson (1): target-ppc: SPR_BOOKE_ESR not set on FP exceptions Cédric Le Goater (2): spapr: introduce the XIVE_EXPLOIT option in CAS spapr: populate device tree depending on XIVE_EXPLOIT option David Gibson (6): spapr: Leave DR-indicator management to the guest spapr: Uniform DRC reset paths spapr: Add DRC release method spapr: Remove unnecessary differences between hotplug and coldplug paths spapr: Use unplug_request for PCI hot unplug spapr: Only report host/guest IOMMU page size mismatches on KVM Greg Kurz (5): spapr: make spapr_populate_hotplug_cpu_dt() static spapr: refresh "platform-specific" hcalls comment spapr: fix bogus function name in comment spapr: fix memory hotplug error path ppc/kvm: have the "family" CPU alias to point to TYPE_HOST_POWERPC_CPU Laurent Vivier (1): spapr: fix migration to pseries machine < 2.8 Suraj Jitindar Singh (2): target/ppc: Refactor tcg radix mmu code target/ppc: Add debug function for radix mmu translation hw/ppc/spapr.c | 95 - hw/ppc/spapr_drc.c | 37 ++ hw/ppc/spapr_pci.c | 47 +++--- include/hw/ppc/spapr.h | 7 +--- include/hw/ppc/spapr_drc.h | 3 +- include/hw/ppc/spapr_ovec.h | 1 + target/ppc/excp_helper.c| 1 + target/ppc/kvm.c| 5 ++- target/ppc/mmu-radix64.c| 67 +--- target/ppc/mmu-radix64.h| 1 + target/ppc/mmu_helper.c | 3 +- 11 files changed, 145 insertions(+), 122 deletions(-)
[Qemu-devel] [PULL 01/17] spapr: make spapr_populate_hotplug_cpu_dt() static
From: Greg Kurz
Since commit ff9006ddbfd1 ("spapr: move spapr_core_[foo]plug() callbacks
close to machine code in spapr.c"), this function doesn't need to be extern
anymore.
Signed-off-by: Greg Kurz
Signed-off-by: David Gibson
---
hw/ppc/spapr.c | 4 ++--
include/hw/ppc/spapr.h | 2 --
2 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
index 0ee9fac..65d8ad2 100644
--- a/hw/ppc/spapr.c
+++ b/hw/ppc/spapr.c
@@ -2863,8 +2863,8 @@ out:
error_propagate(errp, local_err);
}
-void *spapr_populate_hotplug_cpu_dt(CPUState *cs, int *fdt_offset,
-sPAPRMachineState *spapr)
+static void *spapr_populate_hotplug_cpu_dt(CPUState *cs, int *fdt_offset,
+ sPAPRMachineState *spapr)
{
PowerPCCPU *cpu = POWERPC_CPU(cs);
DeviceClass *dc = DEVICE_GET_CLASS(cs);
diff --git a/include/hw/ppc/spapr.h b/include/hw/ppc/spapr.h
index a66bbac..12bf969 100644
--- a/include/hw/ppc/spapr.h
+++ b/include/hw/ppc/spapr.h
@@ -640,8 +640,6 @@ void
spapr_hotplug_req_add_by_count_indexed(sPAPRDRConnectorType drc_type,
void spapr_hotplug_req_remove_by_count_indexed(sPAPRDRConnectorType drc_type,
uint32_t count, uint32_t index);
void spapr_cpu_parse_features(sPAPRMachineState *spapr);
-void *spapr_populate_hotplug_cpu_dt(CPUState *cs, int *fdt_offset,
-sPAPRMachineState *spapr);
/* CPU and LMB DRC release callbacks. */
void spapr_core_release(DeviceState *dev);
--
2.9.4
[Qemu-devel] [PULL 07/17] spapr: Uniform DRC reset paths
DRC objects have a regular device reset method. However, it only gets
called in the usual way for PCI DRCs. Because of where CPU and LMB DRCs
are in the QOM tree, their device reset method isn't automatically called.
So, the machine manually registers reset handlers to call device_reset().
This patch removes the device reset method, and instead always explicitly
registers the reset handler from realize(). This means the callers don't
have to worry about the two cases, and we always get proper resets.
Signed-off-by: David Gibson
Reviewed-by: Greg Kurz
Reviewed-by: Laurent Vivier
---
hw/ppc/spapr.c | 31 ---
hw/ppc/spapr_drc.c | 6 +++---
2 files changed, 7 insertions(+), 30 deletions(-)
diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
index 5acfb47..4fa982d 100644
--- a/hw/ppc/spapr.c
+++ b/hw/ppc/spapr.c
@@ -1967,24 +1967,6 @@ static void spapr_boot_set(void *opaque, const char
*boot_device,
machine->boot_order = g_strdup(boot_device);
}
-/*
- * Reset routine for LMB DR devices.
- *
- * Unlike PCI DR devices, LMB DR devices explicitly register this reset
- * routine. Reset for PCI DR devices will be handled by PHB reset routine
- * when it walks all its children devices. LMB devices reset occurs
- * as part of ppc_spapr_reset().
- */
-static void spapr_drc_reset(void *opaque)
-{
-sPAPRDRConnector *drc = opaque;
-DeviceState *d = DEVICE(drc);
-
-if (d) {
-device_reset(d);
-}
-}
-
static void spapr_create_lmb_dr_connectors(sPAPRMachineState *spapr)
{
MachineState *machine = MACHINE(spapr);
@@ -1993,13 +1975,11 @@ static void
spapr_create_lmb_dr_connectors(sPAPRMachineState *spapr)
int i;
for (i = 0; i < nr_lmbs; i++) {
-sPAPRDRConnector *drc;
uint64_t addr;
addr = i * lmb_size + spapr->hotplug_memory.base;
-drc = spapr_dr_connector_new(OBJECT(spapr), TYPE_SPAPR_DRC_LMB,
- addr/lmb_size);
-qemu_register_reset(spapr_drc_reset, drc);
+spapr_dr_connector_new(OBJECT(spapr), TYPE_SPAPR_DRC_LMB,
+ addr / lmb_size);
}
}
@@ -2093,11 +2073,8 @@ static void spapr_init_cpus(sPAPRMachineState *spapr)
int core_id = i * smp_threads;
if (mc->has_hotpluggable_cpus) {
-sPAPRDRConnector *drc =
-spapr_dr_connector_new(OBJECT(spapr), TYPE_SPAPR_DRC_CPU,
- (core_id / smp_threads) * smt);
-
-qemu_register_reset(spapr_drc_reset, drc);
+spapr_dr_connector_new(OBJECT(spapr), TYPE_SPAPR_DRC_CPU,
+ (core_id / smp_threads) * smt);
}
if (i < boot_cores_nr) {
diff --git a/hw/ppc/spapr_drc.c b/hw/ppc/spapr_drc.c
index 22d4d81..c831aa3 100644
--- a/hw/ppc/spapr_drc.c
+++ b/hw/ppc/spapr_drc.c
@@ -426,9 +426,9 @@ static bool release_pending(sPAPRDRConnector *drc)
return drc->awaiting_release;
}
-static void reset(DeviceState *d)
+static void drc_reset(void *opaque)
{
-sPAPRDRConnector *drc = SPAPR_DR_CONNECTOR(d);
+sPAPRDRConnector *drc = SPAPR_DR_CONNECTOR(opaque);
trace_spapr_drc_reset(spapr_drc_index(drc));
@@ -538,6 +538,7 @@ static void realize(DeviceState *d, Error **errp)
g_free(child_name);
vmstate_register(DEVICE(drc), spapr_drc_index(drc), &vmstate_spapr_drc,
drc);
+qemu_register_reset(drc_reset, drc);
trace_spapr_drc_realize_complete(spapr_drc_index(drc));
}
@@ -596,7 +597,6 @@ static void spapr_dr_connector_class_init(ObjectClass *k,
void *data)
DeviceClass *dk = DEVICE_CLASS(k);
sPAPRDRConnectorClass *drck = SPAPR_DR_CONNECTOR_CLASS(k);
-dk->reset = reset;
dk->realize = realize;
dk->unrealize = unrealize;
drck->release_pending = release_pending;
--
2.9.4
[Qemu-devel] [PATCH V2] chardev: fix parallel device can't be reconnect
Parallel device don't register be->chr_can_read function, but remote
disconnect event is handled in chr_read.So connected parallel device
can not detect remote disconnect event. The chardevs with chr_can_read=NULL
has the same problem.
Signed-off-by: Peng Hao
Reviewed-by: Wang Yechao
---
chardev/char-socket.c | 11 +++
chardev/char.c | 10 ++
include/chardev/char.h | 9 +
3 files changed, 30 insertions(+)
diff --git a/chardev/char-socket.c b/chardev/char-socket.c
index ccc499c..aa44f8f 100644
--- a/chardev/char-socket.c
+++ b/chardev/char-socket.c
@@ -139,6 +139,9 @@ static int tcp_chr_read_poll(void *opaque)
return 0;
}
s->max_size = qemu_chr_be_can_write(chr);
+if (qemu_chr_null_be_can_read(chr)) {
+return 1;
+}
return s->max_size;
}
@@ -422,6 +425,14 @@ static gboolean tcp_chr_read(QIOChannel *chan,
GIOCondition cond, void *opaque)
uint8_t buf[CHR_READ_BUF_LEN];
int len, size;
+if (qemu_chr_null_be_can_read(chr)) {
+size = tcp_chr_recv(chr, (void *)buf, CHR_READ_BUF_LEN);
+if (size == 0 || size == -1) {
+tcp_chr_disconnect(chr);
+}
+return TRUE;
+}
+
if (!s->connected || s->max_size <= 0) {
return TRUE;
}
diff --git a/chardev/char.c b/chardev/char.c
index 2b679a2..7f7f486 100644
--- a/chardev/char.c
+++ b/chardev/char.c
@@ -148,6 +148,16 @@ int qemu_chr_write(Chardev *s, const uint8_t *buf, int
len, bool write_all)
return offset;
}
+int qemu_chr_null_be_can_read(Chardev *s)
+{
+CharBackend *be = s->be;
+
+if (!be || !be->chr_can_read) {
+return 1;
+}
+return 0;
+}
+
int qemu_chr_be_can_write(Chardev *s)
{
CharBackend *be = s->be;
diff --git a/include/chardev/char.h b/include/chardev/char.h
index 8a9ade4..8dd28a8 100644
--- a/include/chardev/char.h
+++ b/include/chardev/char.h
@@ -114,6 +114,15 @@ void qemu_chr_cleanup(void);
Chardev *qemu_chr_new_noreplay(const char *label, const char *filename);
/**
+ * @qemu_chr_null_be_can_read:
+ *
+ * Check if Chardev's chr_can_read is registered.
+ *
+ * Returns: 1 if Chardev's chr_can_read is null.
+ */
+int qemu_chr_null_be_can_read(Chardev *s);
+
+/**
* @qemu_chr_be_can_write:
*
* Determine how much data the front end can currently accept. This function
--
1.8.3.1
Re: [Qemu-devel] [RFC 22/29] vhost+postcopy: Call wakeups
On Wed, Jun 28, 2017 at 08:00:40PM +0100, Dr. David Alan Gilbert (git) wrote: > From: "Dr. David Alan Gilbert" > > Cause the vhost-user client to be woken up whenever: > a) We place a page in postcopy mode Just to make sure I understand it correctly - UFFDIO_COPY will only wake up the waiters on the same userfaultfd context, so we don't need to wake up QEMU userfaultfd (vcpu threads), but we need to explicitly wake up other ufds/threads, like vhost-user backends. Am I right? Thanks, > b) We get a fault and the page has already been received -- Peter Xu
[Qemu-devel] [PATCH qemu v9 2/2] memory/iommu: introduce IOMMUMemoryRegionClass
This finishes QOM'fication of IOMMUMemoryRegion by introducing
a IOMMUMemoryRegionClass. This also provides a fastpath analog for
IOMMU_MEMORY_REGION_GET_CLASS().
This makes IOMMUMemoryRegion an abstract class.
Signed-off-by: Alexey Kardashevskiy
---
Changes:
v9:
* moved IOMMU MR typenames next to respective IOMMU device typenames
* renamed few definitions and functions to match the rest of the code
(for example intel_vtd_iommu_memory_region_class_init ->
vtd_iommu_memory_region_class_init
as the rest of that file uses "vtd_" as a prefix)
v8:
* first appearance
---
hw/i386/amd_iommu.h | 5 ++---
hw/s390x/s390-pci-bus.h | 1 +
include/exec/memory.h | 45 +--
include/hw/i386/intel_iommu.h | 3 ++-
include/hw/ppc/spapr.h| 4
exec.c| 6 --
hw/alpha/typhoon.c| 23 +-
hw/dma/rc4030.c | 26 +++--
hw/i386/amd_iommu.c | 24 +++
hw/i386/intel_iommu.c | 25 +++-
hw/pci-host/apb.c | 23 +-
hw/ppc/spapr_iommu.c | 26 ++---
hw/s390x/s390-pci-bus.c | 23 --
hw/s390x/s390-pci-inst.c | 5 -
memory.c | 36 +++---
15 files changed, 205 insertions(+), 70 deletions(-)
diff --git a/hw/i386/amd_iommu.h b/hw/i386/amd_iommu.h
index 0d3dc6a9f2..d370ae3549 100644
--- a/hw/i386/amd_iommu.h
+++ b/hw/i386/amd_iommu.h
@@ -220,6 +220,8 @@
#define TYPE_AMD_IOMMU_PCI "AMDVI-PCI"
+#define TYPE_AMD_IOMMU_MEMORY_REGION "amd-iommu-iommu-memory-region"
+
typedef struct AMDVIAddressSpace AMDVIAddressSpace;
/* functions to steal PCI config space */
@@ -276,9 +278,6 @@ typedef struct AMDVIState {
uint8_t romask[AMDVI_MMIO_SIZE]; /* MMIO read/only mask */
bool mmio_enabled;
-/* IOMMU function */
-MemoryRegionIOMMUOps iommu_ops;
-
/* for each served device */
AMDVIAddressSpace **address_spaces[PCI_BUS_MAX];
diff --git a/hw/s390x/s390-pci-bus.h b/hw/s390x/s390-pci-bus.h
index 6a599ed353..67af2c12ff 100644
--- a/hw/s390x/s390-pci-bus.h
+++ b/hw/s390x/s390-pci-bus.h
@@ -24,6 +24,7 @@
#define TYPE_S390_PCI_BUS "s390-pcibus"
#define TYPE_S390_PCI_DEVICE "zpci"
#define TYPE_S390_PCI_IOMMU "s390-pci-iommu"
+#define TYPE_S390_IOMMU_MEMORY_REGION "s390-iommu-memory-region"
#define FH_MASK_ENABLE 0x8000
#define FH_MASK_INSTANCE 0x7f00
#define FH_MASK_SHM 0x00ff
diff --git a/include/exec/memory.h b/include/exec/memory.h
index 92980abfad..b7966014fe 100644
--- a/include/exec/memory.h
+++ b/include/exec/memory.h
@@ -25,6 +25,7 @@
#include "qemu/notify.h"
#include "qom/object.h"
#include "qemu/rcu.h"
+#include "hw/qdev-core.h"
#define RAM_ADDR_INVALID (~(ram_addr_t)0)
@@ -38,6 +39,12 @@
#define TYPE_IOMMU_MEMORY_REGION "qemu:iommu-memory-region"
#define IOMMU_MEMORY_REGION(obj) \
OBJECT_CHECK(IOMMUMemoryRegion, (obj), TYPE_IOMMU_MEMORY_REGION)
+#define IOMMU_MEMORY_REGION_CLASS(klass) \
+OBJECT_CLASS_CHECK(IOMMUMemoryRegionClass, (klass), \
+ TYPE_IOMMU_MEMORY_REGION)
+#define IOMMU_MEMORY_REGION_GET_CLASS(obj) \
+OBJECT_GET_CLASS(IOMMUMemoryRegionClass, (obj), \
+ TYPE_IOMMU_MEMORY_REGION)
typedef struct MemoryRegionOps MemoryRegionOps;
typedef struct MemoryRegionMmio MemoryRegionMmio;
@@ -193,9 +200,10 @@ struct MemoryRegionOps {
const MemoryRegionMmio old_mmio;
};
-typedef struct MemoryRegionIOMMUOps MemoryRegionIOMMUOps;
+typedef struct IOMMUMemoryRegionClass {
+/* private */
+struct DeviceClass parent_class;
-struct MemoryRegionIOMMUOps {
/*
* Return a TLB entry that contains a given address. Flag should
* be the access permission of this translation operation. We can
@@ -212,7 +220,7 @@ struct MemoryRegionIOMMUOps {
IOMMUNotifierFlag new_flags);
/* Set this up to provide customized IOMMU replay function */
void (*replay)(IOMMUMemoryRegion *iommu, IOMMUNotifier *notifier);
-};
+} IOMMUMemoryRegionClass;
typedef struct CoalescedMemoryRange CoalescedMemoryRange;
typedef struct MemoryRegionIoeventfd MemoryRegionIoeventfd;
@@ -261,7 +269,6 @@ struct MemoryRegion {
struct IOMMUMemoryRegion {
MemoryRegion parent_obj;
-const MemoryRegionIOMMUOps *iommu_ops;
QLIST_HEAD(, IOMMUNotifier) iommu_notify;
IOMMUNotifierFlag iommu_notify_flags;
};
@@ -622,21 +629,24 @@ static inline void
memory_region_init_reservation(MemoryRegion *mr,
}
/**
- * memory_region_init_iommu: Initialize a memory region that translates
- * addresses
+ * memory_region_init_iommu: Initialize a memory region of a custom type
+ * that translates addresses
*
* An IOMMU region translates addresses and forwards accesses to a target
* memory region.
[Qemu-devel] [PATCH qemu v9 1/2] memory/iommu: QOM'fy IOMMU MemoryRegion
This defines new QOM object - IOMMUMemoryRegion - with MemoryRegion
as a parent.
This moves IOMMU-related fields from MR to IOMMU MR. However to avoid
dymanic QOM casting in fast path (address_space_translate, etc),
this adds an @is_iommu boolean flag to MR and provides new helper to
do simple cast to IOMMU MR - memory_region_get_iommu. The flag
is set in the instance init callback. This defines
memory_region_is_iommu as memory_region_get_iommu()!=NULL.
This switches MemoryRegion to IOMMUMemoryRegion in most places except
the ones where MemoryRegion may be an alias.
Signed-off-by: Alexey Kardashevskiy
Reviewed-by: David Gibson
---
Changes:
v9:
* added rb:David
v8:
* moved is_iommu flag closer to the beginning of the MemoryRegion struct
* removed memory_region_init_iommu_type()
v7:
* rebased on top of the current upstream
v6:
* s/\/iommu_mr/g
v5:
* fixed sparc64, first time in many years did run "./configure" without
--target-list :-D Sorry for the noise though :(
v4:
* fixed alpha, mips64el and sparc
v3:
* rebased on sha1 81b2d5ceb0
v2:
* added mr->is_iommu
* updated i386/x86_64/s390/sun
---
hw/s390x/s390-pci-bus.h | 2 +-
include/exec/memory.h | 55 ++
include/hw/i386/intel_iommu.h | 2 +-
include/hw/mips/mips.h| 2 +-
include/hw/ppc/spapr.h| 3 +-
include/hw/vfio/vfio-common.h | 2 +-
include/qemu/typedefs.h | 1 +
exec.c| 12 ++---
hw/alpha/typhoon.c| 8 ++--
hw/dma/rc4030.c | 8 ++--
hw/i386/amd_iommu.c | 9 ++--
hw/i386/intel_iommu.c | 17 +++
hw/mips/mips_jazz.c | 2 +-
hw/pci-host/apb.c | 6 +--
hw/ppc/spapr_iommu.c | 16 ---
hw/s390x/s390-pci-bus.c | 6 +--
hw/s390x/s390-pci-inst.c | 8 ++--
hw/vfio/common.c | 12 +++--
hw/vfio/spapr.c | 3 +-
memory.c | 105 --
20 files changed, 170 insertions(+), 109 deletions(-)
diff --git a/hw/s390x/s390-pci-bus.h b/hw/s390x/s390-pci-bus.h
index cf142a3e68..6a599ed353 100644
--- a/hw/s390x/s390-pci-bus.h
+++ b/hw/s390x/s390-pci-bus.h
@@ -266,7 +266,7 @@ typedef struct S390PCIIOMMU {
S390PCIBusDevice *pbdev;
AddressSpace as;
MemoryRegion mr;
-MemoryRegion iommu_mr;
+IOMMUMemoryRegion iommu_mr;
bool enabled;
uint64_t g_iota;
uint64_t pba;
diff --git a/include/exec/memory.h b/include/exec/memory.h
index 8503685455..92980abfad 100644
--- a/include/exec/memory.h
+++ b/include/exec/memory.h
@@ -35,6 +35,10 @@
#define MEMORY_REGION(obj) \
OBJECT_CHECK(MemoryRegion, (obj), TYPE_MEMORY_REGION)
+#define TYPE_IOMMU_MEMORY_REGION "qemu:iommu-memory-region"
+#define IOMMU_MEMORY_REGION(obj) \
+OBJECT_CHECK(IOMMUMemoryRegion, (obj), TYPE_IOMMU_MEMORY_REGION)
+
typedef struct MemoryRegionOps MemoryRegionOps;
typedef struct MemoryRegionMmio MemoryRegionMmio;
@@ -198,16 +202,16 @@ struct MemoryRegionIOMMUOps {
* set flag to IOMMU_NONE to mean that we don't need any
* read/write permission checks, like, when for region replay.
*/
-IOMMUTLBEntry (*translate)(MemoryRegion *iommu, hwaddr addr,
+IOMMUTLBEntry (*translate)(IOMMUMemoryRegion *iommu, hwaddr addr,
IOMMUAccessFlags flag);
/* Returns minimum supported page size */
-uint64_t (*get_min_page_size)(MemoryRegion *iommu);
+uint64_t (*get_min_page_size)(IOMMUMemoryRegion *iommu);
/* Called when IOMMU Notifier flag changed */
-void (*notify_flag_changed)(MemoryRegion *iommu,
+void (*notify_flag_changed)(IOMMUMemoryRegion *iommu,
IOMMUNotifierFlag old_flags,
IOMMUNotifierFlag new_flags);
/* Set this up to provide customized IOMMU replay function */
-void (*replay)(MemoryRegion *iommu, IOMMUNotifier *notifier);
+void (*replay)(IOMMUMemoryRegion *iommu, IOMMUNotifier *notifier);
};
typedef struct CoalescedMemoryRange CoalescedMemoryRange;
@@ -227,9 +231,9 @@ struct MemoryRegion {
bool flush_coalesced_mmio;
bool global_locking;
uint8_t dirty_log_mask;
+bool is_iommu;
RAMBlock *ram_block;
Object *owner;
-const MemoryRegionIOMMUOps *iommu_ops;
const MemoryRegionOps *ops;
void *opaque;
@@ -252,6 +256,12 @@ struct MemoryRegion {
const char *name;
unsigned ioeventfd_nb;
MemoryRegionIoeventfd *ioeventfds;
+};
+
+struct IOMMUMemoryRegion {
+MemoryRegion parent_obj;
+
+const MemoryRegionIOMMUOps *iommu_ops;
QLIST_HEAD(, IOMMUNotifier) iommu_notify;
IOMMUNotifierFlag iommu_notify_flags;
};
@@ -618,13 +628,13 @@ static inline void
memory_region_init_reservation(MemoryRegion *mr,
* An IOMMU region translates addresses and forwards accesses to a target
* memory region.
*
- * @mr: the #MemoryRegion to be initialized
+ * @iommu_mr: the
[Qemu-devel] [PATCH qemu v9 0/2] memory/iommu: QOM'fy IOMMU MemoryRegion
Here is a couple of patches to QOM'fy IOMMU memory regions. I have made them in order to proceed with in-kernel TCE stuff acceleration enablement which sort of depends on sPAPR IOMMU MR being QOM'ed. This is based on sha1 3f0602927b Peter Maydell "Merge remote-tracking branch 'remotes/pmaydell/tags/pull-target-arm-20170613' into staging". Please comment. Thanks. Changes: v9: * reworked 2/2 to follow the existing function naming style v8: * now 2 patches This is based on sha1 b113658675 Peter Maydell "Merge remote-tracking branch 'remotes/borntraeger/tags/s390x-20170706' into staging". Please comment. Thanks. Alexey Kardashevskiy (2): memory/iommu: QOM'fy IOMMU MemoryRegion memory/iommu: introduce IOMMUMemoryRegionClass hw/i386/amd_iommu.h | 5 +- hw/s390x/s390-pci-bus.h | 3 +- include/exec/memory.h | 94 +-- include/hw/i386/intel_iommu.h | 5 +- include/hw/mips/mips.h| 2 +- include/hw/ppc/spapr.h| 7 ++- include/hw/vfio/vfio-common.h | 2 +- include/qemu/typedefs.h | 1 + exec.c| 14 +++--- hw/alpha/typhoon.c| 31 +--- hw/dma/rc4030.c | 34 + hw/i386/amd_iommu.c | 33 +--- hw/i386/intel_iommu.c | 42 +++- hw/mips/mips_jazz.c | 2 +- hw/pci-host/apb.c | 29 --- hw/ppc/spapr_iommu.c | 42 ++-- hw/s390x/s390-pci-bus.c | 29 +++ hw/s390x/s390-pci-inst.c | 11 ++-- hw/vfio/common.c | 12 +++-- hw/vfio/spapr.c | 3 +- memory.c | 113 -- 21 files changed, 355 insertions(+), 159 deletions(-) -- 2.11.0
Re: [Qemu-devel] [RFC 16/29] vhost+postcopy: Stash RAMBlock and offset
On Wed, Jun 28, 2017 at 08:00:34PM +0100, Dr. David Alan Gilbert (git) wrote:
> From: "Dr. David Alan Gilbert"
>
> Stash the RAMBlock and offset for later use looking up
> addresses.
>
> Signed-off-by: Dr. David Alan Gilbert
> ---
> hw/virtio/trace-events | 1 +
> hw/virtio/vhost-user.c | 11 +++
> 2 files changed, 12 insertions(+)
>
> diff --git a/hw/virtio/trace-events b/hw/virtio/trace-events
> index f7be340a45..1fd194363a 100644
> --- a/hw/virtio/trace-events
> +++ b/hw/virtio/trace-events
> @@ -3,6 +3,7 @@
> # hw/virtio/vhost-user.c
> vhost_user_postcopy_listen(void) ""
> vhost_user_set_mem_table_postcopy(uint64_t client_addr, uint64_t qhva, int
> reply_i, int region_i) "client:%"PRIx64" for hva: %"PRIx64" reply %d region
> %d"
> +vhost_user_set_mem_table_withfd(int index, const char *name, uint64_t
> memory_size, uint64_t guest_phys_addr, uint64_t userspace_addr, uint64_t
> offset) "%d:%s: size:%"PRIx64" GPA:%"PRIx64" QVA/userspace:%"PRIx64" RB
> offset:%"PRIx64
>
> # hw/virtio/virtio.c
> virtqueue_alloc_element(void *elem, size_t sz, unsigned in_num, unsigned
> out_num) "elem %p size %zd in_num %u out_num %u"
> diff --git a/hw/virtio/vhost-user.c b/hw/virtio/vhost-user.c
> index 6be3e7ff2d..3185af7a45 100644
> --- a/hw/virtio/vhost-user.c
> +++ b/hw/virtio/vhost-user.c
> @@ -133,6 +133,11 @@ struct vhost_user {
> NotifierWithReturn postcopy_notifier;
> struct PostCopyFD postcopy_fd;
> uint64_t postcopy_client_bases[VHOST_MEMORY_MAX_NREGIONS];
> +RAMBlock *region_rb[VHOST_MEMORY_MAX_NREGIONS];
> +/* The offset from the start of the RAMBlock to the start of the
> + * vhost region.
> + */
> +ram_addr_t region_rb_offset[VHOST_MEMORY_MAX_NREGIONS];
Here the array size is VHOST_MEMORY_MAX_NREGIONS, while...
> };
>
> static bool ioeventfd_enabled(void)
> @@ -324,8 +329,14 @@ static int vhost_user_set_mem_table(struct vhost_dev
> *dev,
> assert((uintptr_t)reg->userspace_addr == reg->userspace_addr);
> mr = memory_region_from_host((void *)(uintptr_t)reg->userspace_addr,
> &offset);
> +u->region_rb_offset[i] = offset;
> +u->region_rb[i] = mr->ram_block;
... can i>=VHOST_MEMORY_MAX_NREGIONS here? Or do we only need to note
this down if fd > 0 below? Thanks,
> fd = memory_region_get_fd(mr);
> if (fd > 0) {
> +trace_vhost_user_set_mem_table_withfd(fd_num, mr->name,
> + reg->memory_size,
> + reg->guest_phys_addr,
> + reg->userspace_addr,
> offset);
> msg.payload.memory.regions[fd_num].userspace_addr =
> reg->userspace_addr;
> msg.payload.memory.regions[fd_num].memory_size =
> reg->memory_size;
> msg.payload.memory.regions[fd_num].guest_phys_addr =
> reg->guest_phys_addr;
> --
> 2.13.0
>
--
Peter Xu
Re: [Qemu-devel] [PATCH v6 17/18] shippable: add powerpc target
Hmmm it seems I squashed "add debian/powerpc" (only docker + Makefile) altogether with this one (shippable entry) On Tue, Jul 11, 2017 at 12:09 AM, Philippe Mathieu-Daudé wrote: > Signed-off-by: Philippe Mathieu-Daudé > Reviewed-by: Alex Bennée > --- > .shippable.yml | 2 ++ > tests/docker/Makefile.include | 3 ++ > .../docker/dockerfiles/debian-powerpc-cross.docker | 40 > ++ > 3 files changed, 45 insertions(+) > create mode 100644 tests/docker/dockerfiles/debian-powerpc-cross.docker > > diff --git a/.shippable.yml b/.shippable.yml > index 7a89341cea..4c8a85941f 100644 > --- a/.shippable.yml > +++ b/.shippable.yml > @@ -18,6 +18,8 @@ env: > # mips64el-softmmu disabled due to libfdt problem > - IMAGE=debian-mipsel-cross >TARGET_LIST=mipsel-softmmu,mipsel-linux-user,mips64el-linux-user > +- IMAGE=debian-powerpc-cross > + TARGET_LIST=ppc-softmmu,ppcemb-softmmu,ppc-linux-user > - IMAGE=debian-ppc64el-cross >TARGET_LIST=ppc64-softmmu,ppc64-linux-user,ppc64abi32-linux-user > build: > diff --git a/tests/docker/Makefile.include b/tests/docker/Makefile.include > index d2a81b0d71..a6babf4f1d 100644 > --- a/tests/docker/Makefile.include > +++ b/tests/docker/Makefile.include > @@ -55,11 +55,14 @@ docker-image-%: $(DOCKER_FILES_DIR)/%.docker > $(if $(EXECUTABLE),--include-executable=$(EXECUTABLE)),\ > "BUILD","$*") > > +docker-image-debian-powerpc-cross: > EXTRA_FILES:=tests/docker/dockerfiles/debian-apt-fake.sh > + > # Enforce dependancies for composite images > docker-image-debian-armel-cross: docker-image-debian9 > docker-image-debian-armhf-cross: docker-image-debian9 > docker-image-debian-arm64-cross: docker-image-debian9 > docker-image-debian-mipsel-cross: docker-image-debian9 > +docker-image-debian-powerpc-cross: docker-image-debian8 > docker-image-debian-ppc64el-cross: docker-image-debian9 > docker-image-debian-s390x-cross: docker-image-debian9 > docker-image-debian-amd64-cross: docker-image-debian9 > diff --git a/tests/docker/dockerfiles/debian-powerpc-cross.docker > b/tests/docker/dockerfiles/debian-powerpc-cross.docker > new file mode 100644 > index 00..a5dd46b4ac > --- /dev/null > +++ b/tests/docker/dockerfiles/debian-powerpc-cross.docker > @@ -0,0 +1,40 @@ > +# > +# Docker powerpc cross-compiler target > +# > +# This docker target builds on the debian Jessie base image. > +# > +FROM qemu:debian8 > +MAINTAINER Philippe Mathieu-Daudé > + > +# Add the foreign architecture we want and install dependencies > +RUN dpkg --add-architecture powerpc > +RUN apt-get update > +RUN DEBIAN_FRONTEND=noninteractive eatmydata \ > +apt-get install -y --no-install-recommends \ > +crossbuild-essential-powerpc > + > +# to fix "following packages have unmet dependencies" ... > +ADD debian-apt-fake.sh /usr/local/bin/apt-fake > +RUN apt-get install -y --no-install-recommends \ > +equivs \ > +pkg-config > +RUN apt-fake install \ > +pkg-config:powerpc=0.28-1.1-fake && \ > +ln -s pkg-config /usr/bin/powerpc-linux-gnu-pkg-config > +ENV PKG_CONFIG_PATH /usr/lib/powerpc-linux-gnu/pkgconfig > +# > + > +# Specify the cross prefix for this image (see tests/docker/common.rc) > +ENV QEMU_CONFIGURE_OPTS --cross-prefix=powerpc-linux-gnu- > + > +RUN DEBIAN_FRONTEND=noninteractive eatmydata \ > +apt-get build-dep -yy -a powerpc qemu > +RUN DEBIAN_FRONTEND=noninteractive \ > +apt-get install -y --no-install-recommends \ > +glusterfs-common:powerpc \ > +libbz2-dev:powerpc \ > +liblzo2-dev:powerpc \ > +libncursesw5-dev:powerpc \ > +libnfs-dev:powerpc \ > +librdmacm-dev:powerpc \ > +libsnappy-dev:powerpc > -- > 2.13.2 >
Re: [Qemu-devel] [PATCH] util/cacheinfo: add missing include
Hi Richard,
On Mon, Jul 10, 2017 at 11:38 PM, Richard Henderson wrote:
> On 07/10/2017 03:55 PM, Philippe Mathieu-Daudé wrote:
>>
>> This include was forgotten when splitting cacheinfo.c out of
>> tcg/ppc/tcg-target.inc.c (see commit b255b2c8).
>>
>> While compiling on powerpc:
>>
>>CC util/cacheinfo.o
>> qemu/util/cacheinfo.c: In function 'arch_cache_info':
>> qemu/util/cacheinfo.c:137:33: error: 'AT_ICACHEBSIZE' undeclared
>> (first use in this function)
>> *isize = qemu_getauxval(AT_ICACHEBSIZE);
>> ^
>> qemu/util/cacheinfo.c:137:33: note: each undeclared identifier is
>> reported only once for each function it appears in
>> qemu/util/cacheinfo.c:140:33: error: 'AT_DCACHEBSIZE' undeclared
>> (first use in this function)
>> *dsize = qemu_getauxval(AT_DCACHEBSIZE);
>> ^
>> qemu/rules.mak:66: recipe for target 'util/cacheinfo.o' failed
>> make: *** [util/cacheinfo.o] Error 1
>
>
> For the record, what is the os version?
> Because this doesn't happen here for Centos7.
Oops true I forgot to log this info in the commit.
This happens on debian/powerpc Jessie, using GCC 4.9.2-10
$ make subdir-ppc-softmmu
CC util/cacheinfo.o
/home/phil/source/qemu/util/cacheinfo.c: In function 'arch_cache_info':
/home/phil/source/qemu/util/cacheinfo.c:137:33: error:
'AT_ICACHEBSIZE' undeclared (first use in this function)
*isize = qemu_getauxval(AT_ICACHEBSIZE);
^
compiling with -dU:
#define _ARCH_PPC 1
# 134 "/home/phil/source/qemu/util/cacheinfo.c"
static void arch_cache_info(int *isize, int *dsize)
{
if (*isize == 0) {
*isize = qemu_getauxval(AT_ICACHEBSIZE);
}
if (*dsize == 0) {
*dsize = qemu_getauxval(AT_DCACHEBSIZE);
}
}
Regards,
Phil.
[Qemu-devel] [PATCH v6 18/18] shippable: restrict builds to master/staging and shippable* branches
Signed-off-by: Philippe Mathieu-Daudé --- .shippable.yml | 5 + 1 file changed, 5 insertions(+) diff --git a/.shippable.yml b/.shippable.yml index 4c8a85941f..1f05d934e4 100644 --- a/.shippable.yml +++ b/.shippable.yml @@ -1,6 +1,11 @@ language: c git: submodules: false +branches: + only: +- master +- staging +- shippable* env: global: - LC_ALL=C -- 2.13.2
[Qemu-devel] [PATCH v6 16/18] docker: add qemu:debian-jessie based on outdated jessie release
Signed-off-by: Philippe Mathieu-Daudé --- tests/docker/dockerfiles/debian8.docker | 31 +++ 1 file changed, 31 insertions(+) create mode 100644 tests/docker/dockerfiles/debian8.docker diff --git a/tests/docker/dockerfiles/debian8.docker b/tests/docker/dockerfiles/debian8.docker new file mode 100644 index 00..ea9083633a --- /dev/null +++ b/tests/docker/dockerfiles/debian8.docker @@ -0,0 +1,31 @@ +# +# Docker multiarch cross-compiler target +# +# This docker target is builds on Debian and Emdebian's cross compiler targets +# to build distro with a selection of cross compilers for building test binaries. +# +# On its own you can't build much but the docker-foo-cross targets +# build on top of the base debian image. +# +FROM debian:jessie-slim +MAINTAINER Philippe Mathieu-Daudé + +# Setup some basic tools we need +RUN apt update +RUN DEBIAN_FRONTEND=noninteractive apt install -yy eatmydata +RUN DEBIAN_FRONTEND=noninteractive eatmydata \ +apt install -y --no-install-recommends \ +bison \ +build-essential \ +ca-certificates \ +clang \ +curl \ +flex \ +git \ +pkg-config \ +python-minimal + +# Duplicate deb line as deb-src, setup Emdebian +RUN cat /etc/apt/sources.list | sed "s/^deb\ /deb-src /" >> /etc/apt/sources.list && \ +echo "deb http://emdebian.org/tools/debian/ jessie main" >> /etc/apt/sources.list && \ +curl http://emdebian.org/tools/debian/emdebian-toolchain-archive.key | apt-key add - -- 2.13.2
[Qemu-devel] [PATCH v6 14/18] shippable: add x86_64 targets
Signed-off-by: Philippe Mathieu-Daudé --- .shippable.yml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/.shippable.yml b/.shippable.yml index 189d193da5..7a89341cea 100644 --- a/.shippable.yml +++ b/.shippable.yml @@ -5,6 +5,8 @@ env: global: - LC_ALL=C matrix: +- IMAGE=debian-amd64-cross + TARGET_LIST=x86_64-softmmu,x86_64-linux-user - IMAGE=debian-armel-cross TARGET_LIST=arm-softmmu,arm-linux-user,armeb-linux-user - IMAGE=debian-armhf-cross -- 2.13.2
[Qemu-devel] [PATCH v6 10/18] docker: enable gcrypt to extend code coverage on amd64
Signed-off-by: Philippe Mathieu-Daudé --- tests/docker/dockerfiles/debian-amd64-cross.docker | 3 +++ 1 file changed, 3 insertions(+) diff --git a/tests/docker/dockerfiles/debian-amd64-cross.docker b/tests/docker/dockerfiles/debian-amd64-cross.docker index 8fb9f90814..48a5e77db7 100644 --- a/tests/docker/dockerfiles/debian-amd64-cross.docker +++ b/tests/docker/dockerfiles/debian-amd64-cross.docker @@ -33,3 +33,6 @@ RUN DEBIAN_FRONTEND=noninteractive eatmydata \ RUN git clone https://github.com/luigirizzo/netmap.git /usr/src/netmap RUN cd /usr/src/netmap/LINUX && ./configure --no-drivers --no-apps --kernel-dir=$(ls -d /usr/src/linux-headers-*-amd64) && make install ENV QEMU_CONFIGURE_OPTS --enable-netmap + +# gcrypt +ENV QEMU_CONFIGURE_OPTS $QEMU_CONFIGURE_OPTS --enable-gcrypt -- 2.13.2
[Qemu-devel] [PATCH v6 11/18] docker: enable nettle to extend code coverage on arm64
Signed-off-by: Philippe Mathieu-Daudé --- tests/docker/dockerfiles/debian-arm64-cross.docker | 3 +++ 1 file changed, 3 insertions(+) diff --git a/tests/docker/dockerfiles/debian-arm64-cross.docker b/tests/docker/dockerfiles/debian-arm64-cross.docker index 6ed12a3f6e..877d863475 100644 --- a/tests/docker/dockerfiles/debian-arm64-cross.docker +++ b/tests/docker/dockerfiles/debian-arm64-cross.docker @@ -24,3 +24,6 @@ RUN DEBIAN_FRONTEND=noninteractive eatmydata \ librdmacm-dev:arm64 \ libsnappy-dev:arm64 \ libxen-dev:arm64 + +# nettle +ENV QEMU_CONFIGURE_OPTS $QEMU_CONFIGURE_OPTS --enable-nettle -- 2.13.2
[Qemu-devel] [PATCH v6 09/18] docker: enable netmap to extend code coverage on amd64
Signed-off-by: Philippe Mathieu-Daudé --- tests/docker/dockerfiles/debian-amd64-cross.docker | 8 1 file changed, 8 insertions(+) diff --git a/tests/docker/dockerfiles/debian-amd64-cross.docker b/tests/docker/dockerfiles/debian-amd64-cross.docker index 88b1b3f4e3..8fb9f90814 100644 --- a/tests/docker/dockerfiles/debian-amd64-cross.docker +++ b/tests/docker/dockerfiles/debian-amd64-cross.docker @@ -25,3 +25,11 @@ RUN DEBIAN_FRONTEND=noninteractive eatmydata \ libgbm-dev RUN git clone git://anongit.freedesktop.org/virglrenderer /usr/src/virglrenderer RUN cd /usr/src/virglrenderer && ./autogen.sh && ./configure --with-glx --disable-tests && make install + +# netmap +RUN DEBIAN_FRONTEND=noninteractive eatmydata \ +apt-get install -y --no-install-recommends \ +linux-headers-amd64 +RUN git clone https://github.com/luigirizzo/netmap.git /usr/src/netmap +RUN cd /usr/src/netmap/LINUX && ./configure --no-drivers --no-apps --kernel-dir=$(ls -d /usr/src/linux-headers-*-amd64) && make install +ENV QEMU_CONFIGURE_OPTS --enable-netmap -- 2.13.2
[Qemu-devel] [PATCH v6 17/18] shippable: add powerpc target
Signed-off-by: Philippe Mathieu-Daudé Reviewed-by: Alex Bennée --- .shippable.yml | 2 ++ tests/docker/Makefile.include | 3 ++ .../docker/dockerfiles/debian-powerpc-cross.docker | 40 ++ 3 files changed, 45 insertions(+) create mode 100644 tests/docker/dockerfiles/debian-powerpc-cross.docker diff --git a/.shippable.yml b/.shippable.yml index 7a89341cea..4c8a85941f 100644 --- a/.shippable.yml +++ b/.shippable.yml @@ -18,6 +18,8 @@ env: # mips64el-softmmu disabled due to libfdt problem - IMAGE=debian-mipsel-cross TARGET_LIST=mipsel-softmmu,mipsel-linux-user,mips64el-linux-user +- IMAGE=debian-powerpc-cross + TARGET_LIST=ppc-softmmu,ppcemb-softmmu,ppc-linux-user - IMAGE=debian-ppc64el-cross TARGET_LIST=ppc64-softmmu,ppc64-linux-user,ppc64abi32-linux-user build: diff --git a/tests/docker/Makefile.include b/tests/docker/Makefile.include index d2a81b0d71..a6babf4f1d 100644 --- a/tests/docker/Makefile.include +++ b/tests/docker/Makefile.include @@ -55,11 +55,14 @@ docker-image-%: $(DOCKER_FILES_DIR)/%.docker $(if $(EXECUTABLE),--include-executable=$(EXECUTABLE)),\ "BUILD","$*") +docker-image-debian-powerpc-cross: EXTRA_FILES:=tests/docker/dockerfiles/debian-apt-fake.sh + # Enforce dependancies for composite images docker-image-debian-armel-cross: docker-image-debian9 docker-image-debian-armhf-cross: docker-image-debian9 docker-image-debian-arm64-cross: docker-image-debian9 docker-image-debian-mipsel-cross: docker-image-debian9 +docker-image-debian-powerpc-cross: docker-image-debian8 docker-image-debian-ppc64el-cross: docker-image-debian9 docker-image-debian-s390x-cross: docker-image-debian9 docker-image-debian-amd64-cross: docker-image-debian9 diff --git a/tests/docker/dockerfiles/debian-powerpc-cross.docker b/tests/docker/dockerfiles/debian-powerpc-cross.docker new file mode 100644 index 00..a5dd46b4ac --- /dev/null +++ b/tests/docker/dockerfiles/debian-powerpc-cross.docker @@ -0,0 +1,40 @@ +# +# Docker powerpc cross-compiler target +# +# This docker target builds on the debian Jessie base image. +# +FROM qemu:debian8 +MAINTAINER Philippe Mathieu-Daudé + +# Add the foreign architecture we want and install dependencies +RUN dpkg --add-architecture powerpc +RUN apt-get update +RUN DEBIAN_FRONTEND=noninteractive eatmydata \ +apt-get install -y --no-install-recommends \ +crossbuild-essential-powerpc + +# to fix "following packages have unmet dependencies" ... +ADD debian-apt-fake.sh /usr/local/bin/apt-fake +RUN apt-get install -y --no-install-recommends \ +equivs \ +pkg-config +RUN apt-fake install \ +pkg-config:powerpc=0.28-1.1-fake && \ +ln -s pkg-config /usr/bin/powerpc-linux-gnu-pkg-config +ENV PKG_CONFIG_PATH /usr/lib/powerpc-linux-gnu/pkgconfig +# + +# Specify the cross prefix for this image (see tests/docker/common.rc) +ENV QEMU_CONFIGURE_OPTS --cross-prefix=powerpc-linux-gnu- + +RUN DEBIAN_FRONTEND=noninteractive eatmydata \ +apt-get build-dep -yy -a powerpc qemu +RUN DEBIAN_FRONTEND=noninteractive \ +apt-get install -y --no-install-recommends \ +glusterfs-common:powerpc \ +libbz2-dev:powerpc \ +liblzo2-dev:powerpc \ +libncursesw5-dev:powerpc \ +libnfs-dev:powerpc \ +librdmacm-dev:powerpc \ +libsnappy-dev:powerpc -- 2.13.2
[Qemu-devel] [PATCH v6 03/18] docker: debian/s390x no more in unstable, now available in Stretch
Signed-off-by: Philippe Mathieu-Daudé --- tests/docker/Makefile.include | 1 + tests/docker/dockerfiles/debian-s390x-cross.docker | 20 ++-- 2 files changed, 11 insertions(+), 10 deletions(-) diff --git a/tests/docker/Makefile.include b/tests/docker/Makefile.include index 01d7af9698..1eb32eebfa 100644 --- a/tests/docker/Makefile.include +++ b/tests/docker/Makefile.include @@ -59,6 +59,7 @@ docker-image-%: $(DOCKER_FILES_DIR)/%.docker docker-image-debian-armhf-cross: docker-image-debian9 docker-image-debian-arm64-cross: docker-image-debian9 docker-image-debian-mipsel-cross: docker-image-debian9 +docker-image-debian-s390x-cross: docker-image-debian9 # Expand all the pre-requistes for each docker image and test combination $(foreach i,$(DOCKER_IMAGES), \ diff --git a/tests/docker/dockerfiles/debian-s390x-cross.docker b/tests/docker/dockerfiles/debian-s390x-cross.docker index cfc354ce5d..18fe813aa7 100644 --- a/tests/docker/dockerfiles/debian-s390x-cross.docker +++ b/tests/docker/dockerfiles/debian-s390x-cross.docker @@ -1,27 +1,27 @@ # # Docker s390 cross-compiler target # -# This docker target is based on stretch (testing) as the stable build -# doesn't have the cross compiler available. +# This docker target builds on the debian Stretch base image. # -FROM debian:testing-slim - -# Duplicate deb line as deb-src -RUN cat /etc/apt/sources.list | sed "s/deb/deb-src/" >> /etc/apt/sources.list +FROM qemu:debian9 # Add the s390x architecture RUN dpkg --add-architecture s390x # Grab the updated list of packages RUN apt update && apt dist-upgrade -yy -RUN apt install -yy build-essential clang -RUN apt-get build-dep -yy -a s390x qemu || apt-get -f install -RUN apt install -yy gcc-multilib-s390x-linux-gnu binutils-multiarch +RUN DEBIAN_FRONTEND=noninteractive eatmydata \ +apt-get install -y --no-install-recommends \ +binutils-multiarch \ +gcc-multilib-s390x-linux-gnu + +RUN DEBIAN_FRONTEND=noninteractive eatmydata \ +apt-get build-dep -yy -a s390x qemu # Specify the cross prefix for this image (see tests/docker/common.rc) ENV QEMU_CONFIGURE_OPTS --cross-prefix=s390x-linux-gnu- -RUN DEBIAN_FRONTEND=noninteractive \ +RUN DEBIAN_FRONTEND=noninteractive eatmydata \ apt-get install -y --no-install-recommends \ glusterfs-common:s390x \ libbz2-dev:s390x \ -- 2.13.2
[Qemu-devel] [PATCH v6 01/18] docker: rename debian stable -> 9 (Stretch)
Signed-off-by: Philippe Mathieu-Daudé
---
tests/docker/Makefile.include | 6 +++---
tests/docker/dockerfiles/debian-arm64-cross.docker | 4 ++--
tests/docker/dockerfiles/debian-armhf-cross.docker | 4 ++--
tests/docker/dockerfiles/debian-mipsel-cross.docker| 4 ++--
tests/docker/dockerfiles/{debian.docker => debian9.docker} | 13 +
5 files changed, 18 insertions(+), 13 deletions(-)
rename tests/docker/dockerfiles/{debian.docker => debian9.docker} (62%)
diff --git a/tests/docker/Makefile.include b/tests/docker/Makefile.include
index 037cb9e9e7..01d7af9698 100644
--- a/tests/docker/Makefile.include
+++ b/tests/docker/Makefile.include
@@ -56,9 +56,9 @@ docker-image-%: $(DOCKER_FILES_DIR)/%.docker
"BUILD","$*")
# Enforce dependancies for composite images
-docker-image-debian-armhf-cross: docker-image-debian
-docker-image-debian-arm64-cross: docker-image-debian
-docker-image-debian-mipsel-cross: docker-image-debian
+docker-image-debian-armhf-cross: docker-image-debian9
+docker-image-debian-arm64-cross: docker-image-debian9
+docker-image-debian-mipsel-cross: docker-image-debian9
# Expand all the pre-requistes for each docker image and test combination
$(foreach i,$(DOCKER_IMAGES), \
diff --git a/tests/docker/dockerfiles/debian-arm64-cross.docker
b/tests/docker/dockerfiles/debian-arm64-cross.docker
index 45b891d57a..f1bfa64160 100644
--- a/tests/docker/dockerfiles/debian-arm64-cross.docker
+++ b/tests/docker/dockerfiles/debian-arm64-cross.docker
@@ -1,9 +1,9 @@
#
# Docker arm64 cross-compiler target
#
-# This docker target builds on the base debian image.
+# This docker target builds on the debian Stretch base image.
#
-FROM qemu:debian
+FROM qemu:debian9
# Add the foreign architecture we want and install dependencies
RUN dpkg --add-architecture arm64
diff --git a/tests/docker/dockerfiles/debian-armhf-cross.docker
b/tests/docker/dockerfiles/debian-armhf-cross.docker
index e67dfdccc5..2beacef49b 100644
--- a/tests/docker/dockerfiles/debian-armhf-cross.docker
+++ b/tests/docker/dockerfiles/debian-armhf-cross.docker
@@ -1,9 +1,9 @@
#
# Docker armhf cross-compiler target
#
-# This docker target builds on the base debian image.
+# This docker target builds on the debian Stretch base image.
#
-FROM qemu:debian
+FROM qemu:debian9
# Add the foreign architecture we want and install dependencies
RUN dpkg --add-architecture armhf
diff --git a/tests/docker/dockerfiles/debian-mipsel-cross.docker
b/tests/docker/dockerfiles/debian-mipsel-cross.docker
index 2156bdb28d..9ee997aa54 100644
--- a/tests/docker/dockerfiles/debian-mipsel-cross.docker
+++ b/tests/docker/dockerfiles/debian-mipsel-cross.docker
@@ -1,9 +1,9 @@
#
# Docker mipsel cross-compiler target
#
-# This docker target builds on the base debian image.
+# This docker target builds on the debian Stretch base image.
#
-FROM qemu:debian
+FROM qemu:debian9
MAINTAINER Philippe Mathieu-Daudé
# Add the foreign architecture we want and install dependencies
diff --git a/tests/docker/dockerfiles/debian.docker
b/tests/docker/dockerfiles/debian9.docker
similarity index 62%
rename from tests/docker/dockerfiles/debian.docker
rename to tests/docker/dockerfiles/debian9.docker
index 10953b2425..c74f71283c 100644
--- a/tests/docker/dockerfiles/debian.docker
+++ b/tests/docker/dockerfiles/debian9.docker
@@ -1,13 +1,13 @@
#
# Docker multiarch cross-compiler target
#
-# This docker target is builds on Debian and Emdebian's cross compiler targets
-# to build distro with a selection of cross compilers for building test
binaries.
+# This docker target is builds on Debian cross compiler targets to build distro
+# with a selection of cross compilers for building test binaries.
#
# On its own you can't build much but the docker-foo-cross targets
# build on top of the base debian image.
#
-FROM debian:stable-slim
+FROM debian:stretch-slim
# Duplicate deb line as deb-src
RUN cat /etc/apt/sources.list | sed "s/^deb\ /deb-src /" >>
/etc/apt/sources.list
@@ -17,4 +17,9 @@ RUN apt update
RUN DEBIAN_FRONTEND=noninteractive apt install -yy eatmydata
RUN DEBIAN_FRONTEND=noninteractive eatmydata \
apt install -y --no-install-recommends \
-ca-certificates build-essential clang git bison flex
+bison \
+build-essential \
+ca-certificates \
+clang \
+flex \
+git
--
2.13.2
[Qemu-devel] [PATCH v6 06/18] docker: add debian/ppc64el based on Stretch
Signed-off-by: Philippe Mathieu-Daudé --- tests/docker/Makefile.include | 1 + .../docker/dockerfiles/debian-ppc64el-cross.docker | 24 ++ 2 files changed, 25 insertions(+) create mode 100644 tests/docker/dockerfiles/debian-ppc64el-cross.docker diff --git a/tests/docker/Makefile.include b/tests/docker/Makefile.include index 238bb7276c..59b08b4aca 100644 --- a/tests/docker/Makefile.include +++ b/tests/docker/Makefile.include @@ -60,6 +60,7 @@ docker-image-debian-armel-cross: docker-image-debian9 docker-image-debian-armhf-cross: docker-image-debian9 docker-image-debian-arm64-cross: docker-image-debian9 docker-image-debian-mipsel-cross: docker-image-debian9 +docker-image-debian-ppc64el-cross: docker-image-debian9 docker-image-debian-s390x-cross: docker-image-debian9 # Expand all the pre-requistes for each docker image and test combination diff --git a/tests/docker/dockerfiles/debian-ppc64el-cross.docker b/tests/docker/dockerfiles/debian-ppc64el-cross.docker new file mode 100644 index 00..f34f09a8cd --- /dev/null +++ b/tests/docker/dockerfiles/debian-ppc64el-cross.docker @@ -0,0 +1,24 @@ +# +# Docker ppc64el cross-compiler target +# +# This docker target builds on the debian Stretch base image. +# +FROM qemu:debian9 + +# Add the foreign architecture we want and install dependencies +RUN dpkg --add-architecture ppc64el && \ +apt update +RUN apt install -yy crossbuild-essential-ppc64el + +RUN DEBIAN_FRONTEND=noninteractive eatmydata \ +apt-get build-dep -yy -a ppc64el qemu + +# Specify the cross prefix for this image (see tests/docker/common.rc) +ENV QEMU_CONFIGURE_OPTS --cross-prefix=powerpc64le-linux-gnu- + +RUN DEBIAN_FRONTEND=noninteractive eatmydata \ +apt-get install -y --no-install-recommends \ +libbz2-dev:ppc64el \ +liblzo2-dev:ppc64el \ +librdmacm-dev:ppc64el \ +libsnappy-dev:ppc64el -- 2.13.2
[Qemu-devel] [PATCH v6 07/18] docker: add debian/amd64
Signed-off-by: Philippe Mathieu-Daudé --- tests/docker/Makefile.include | 1 + tests/docker/dockerfiles/debian-amd64-cross.docker | 18 ++ 2 files changed, 19 insertions(+) create mode 100644 tests/docker/dockerfiles/debian-amd64-cross.docker diff --git a/tests/docker/Makefile.include b/tests/docker/Makefile.include index 59b08b4aca..d2a81b0d71 100644 --- a/tests/docker/Makefile.include +++ b/tests/docker/Makefile.include @@ -62,6 +62,7 @@ docker-image-debian-arm64-cross: docker-image-debian9 docker-image-debian-mipsel-cross: docker-image-debian9 docker-image-debian-ppc64el-cross: docker-image-debian9 docker-image-debian-s390x-cross: docker-image-debian9 +docker-image-debian-amd64-cross: docker-image-debian9 # Expand all the pre-requistes for each docker image and test combination $(foreach i,$(DOCKER_IMAGES), \ diff --git a/tests/docker/dockerfiles/debian-amd64-cross.docker b/tests/docker/dockerfiles/debian-amd64-cross.docker new file mode 100644 index 00..9d10a886df --- /dev/null +++ b/tests/docker/dockerfiles/debian-amd64-cross.docker @@ -0,0 +1,18 @@ +# +# Docker x86_64 cross-compiler target +# +# This docker target builds on the debian Stretch base image. +# +FROM qemu:debian9 +MAINTAINER Philippe Mathieu-Daudé + +RUN DEBIAN_FRONTEND=noninteractive eatmydata \ +apt-get build-dep -yy qemu + +RUN DEBIAN_FRONTEND=noninteractive eatmydata \ +apt-get install -y --no-install-recommends \ +libbz2-dev \ +liblzo2-dev \ +librdmacm-dev \ +libsnappy-dev \ +libvte-dev -- 2.13.2
[Qemu-devel] [PATCH v6 08/18] docker: enable virgl to extend code coverage on amd64
Signed-off-by: Philippe Mathieu-Daudé --- tests/docker/dockerfiles/debian-amd64-cross.docker | 9 + 1 file changed, 9 insertions(+) diff --git a/tests/docker/dockerfiles/debian-amd64-cross.docker b/tests/docker/dockerfiles/debian-amd64-cross.docker index 9d10a886df..88b1b3f4e3 100644 --- a/tests/docker/dockerfiles/debian-amd64-cross.docker +++ b/tests/docker/dockerfiles/debian-amd64-cross.docker @@ -16,3 +16,12 @@ RUN DEBIAN_FRONTEND=noninteractive eatmydata \ librdmacm-dev \ libsnappy-dev \ libvte-dev + +# virgl +RUN DEBIAN_FRONTEND=noninteractive eatmydata \ +apt-get install -y --no-install-recommends \ +libegl1-mesa-dev \ +libepoxy-dev \ +libgbm-dev +RUN git clone git://anongit.freedesktop.org/virglrenderer /usr/src/virglrenderer +RUN cd /usr/src/virglrenderer && ./autogen.sh && ./configure --with-glx --disable-tests && make install -- 2.13.2
[Qemu-devel] [PATCH v6 12/18] shippable: add armel targets
Signed-off-by: Philippe Mathieu-Daudé --- .shippable.yml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/.shippable.yml b/.shippable.yml index 5e0caa65c5..abcaf6f4d4 100644 --- a/.shippable.yml +++ b/.shippable.yml @@ -5,6 +5,8 @@ env: global: - LC_ALL=C matrix: +- IMAGE=debian-armel-cross + TARGET_LIST=arm-softmmu,arm-linux-user,armeb-linux-user - IMAGE=debian-armhf-cross TARGET_LIST=arm-softmmu,arm-linux-user,armeb-linux-user - IMAGE=debian-arm64-cross -- 2.13.2
[Qemu-devel] [PATCH v6 15/18] docker: add 'apt-fake' script which generate fake debian packages
Signed-off-by: Philippe Mathieu-Daudé
Reviewed-by: Alex Bennée
---
tests/docker/dockerfiles/debian-apt-fake.sh | 46 +
1 file changed, 46 insertions(+)
create mode 100755 tests/docker/dockerfiles/debian-apt-fake.sh
diff --git a/tests/docker/dockerfiles/debian-apt-fake.sh
b/tests/docker/dockerfiles/debian-apt-fake.sh
new file mode 100755
index 00..387522c174
--- /dev/null
+++ b/tests/docker/dockerfiles/debian-apt-fake.sh
@@ -0,0 +1,46 @@
+#! /bin/sh
+#
+# Generate fake debian package to resolve unimportant unmet dependencies held
+# by upstream multiarch broken packages.
+#
+# Copyright (c) 2017 Philippe Mathieu-Daudé
+#
+# This work is licensed under the terms of the GNU GPL, version 2
+# or (at your option) any later version. See the COPYING file in
+# the top-level directory.
+
+test $1 = "install" && shift 1
+
+fake_install()
+{
+echo "Generating fake $2 $1 $3 ..."
+(cd /var/cache/apt/archives
+(cat << 'EOF'
+Section: misc
+Priority: optional
+Standards-Version: 3.9.2
+
+Package: NAME
+Version: VERSION
+Maintainer: qemu-devel@nongnu.org
+Architecture: any
+Multi-Arch: same
+Description: fake NAME
+EOF
+) | sed s/NAME/$2/g | sed s/VERSION/$3/g > $2.control
+equivs-build -a $1 $2.control 1>/dev/null 2>/dev/null
+dpkg -i $2_$3_$1.deb
+)
+}
+
+try_install()
+{
+name=$(echo $1|sed "s/\(.*\):\(.*\)=\(.*\)/\1/")
+arch=$(echo $1|sed "s/\(.*\):\(.*\)=\(.*\)/\2/")
+vers=$(echo $1|sed "s/\(.*\):\(.*\)=\(.*\)/\3/")
+apt-get install -q -yy $1 || fake_install $arch $name $vers
+}
+
+for package in $*; do
+try_install $package
+done
--
2.13.2
[Qemu-devel] [PATCH v6 00/18] docker/shippable: rework debian images, add powerpc ppc64el and amd64
This patchset add 3 more architectures to the cross-build farm.
Altough amd64 'cross' target sounds weird, I find it useful to cover
more codebase having libraries installed in image I don't need on my
workstation.
There is still some issue trying to cross-build mips64el-softmmu, it
seems the cross tools use the system outdated libfdt instead of the one
checkouted in the dtc submodule. I disabled this target for now.
The branch https://github.com/philmd/qemu/tree/shippable-docker-shippable_v6
can be checked at Shippable:
https://app.shippable.com/github/philmd/qemu/runs/15/summary/console
The first time an image is built, the docker image is fully build in
~3min (cache miss). Then Shippable keeps this image cached.
Cross building QEMU takes ~6min (2 or 3 targets).
The first time a branch is pushed, each arch build will take ~9min, up
to 1h for the current 8 archs.
Subsequent pushes take less than 50min to build all archs.
v6:
- cleaning up Stretch based images
- restore powerpc image (based on debian Jessie)
- add ppc64el and amd64 images (based on debian Stretch)
- extend coverage enabling virgl/netmap/gcrypt on amd64
- extend coverage enabling nettle on arm64
- add Shippable yml filter rule to restrict branches to build
[most part of previous patchset merged in commit 469819a3e8e3]
v5:
- Addressed minor review feedback from Alex/Fam (improving a comment)
- Added Alex R-b
v4:
- Addressed review feedbacks from Fam (improving english, cleaner hashing)
- Added Alex R-b
v3:
- Addressed review feedbacks from Fam:
- Keep building images in various layers, but use DEBIAN_FRONTEND=noninteractive
- Document '--extra-files', now it supports adding various files at once
- Checksum extra files to trigger a docker image rebuild if modified
- Use better regex to generate deb-src entries
- Reordered extra libs, to ease further add/remove diffs
v2:
- Addressed review feedback from Alex, added his R-B
- Fixed the "Problem with the SSL CA cert" problem while cloning from github.com
installing the ca-certificates package.
- Squashed/split some commits
- use 'apt-get clean' instead of brutal 'rm -rf'
- checked how many cores are available on Shippable and use them fully
(reduced total time from 44min to 38min)
- build armeb-linux-user target
v1:
- Reorganize Dockerfiles to use less layers, resulting in smaller images.
This also reduce time of image transfer, for example while using:
`docker save qemu:debian | ssh remote docker load`
- Install more debian packages so the configure script enable more features and
more code can be compiled/covered.
- There are still some incorrect multiarch packages on debian/jessie used in
the docker images, add a script to generate fake packages and avoid
dependencies issues.
- Modify the docker.py script to include an extra file while building images.
Regards,
Phil.
Philippe Mathieu-Daudé (18):
docker: rename debian stable -> 9 (Stretch)
docker: add pkg-config and python-minimal packages to debian base
docker: debian/s390x no more in unstable, now available in Stretch
docker: remove packages now dependent of qemu in Stretch
docker: add debian/armel based on Stretch
docker: add debian/ppc64el based on Stretch
docker: add debian/amd64
docker: enable virgl coverage on amd64
docker: enable netmap coverage on amd64
docker: enable gcrypt coverage on amd64
docker: enable nettle coverage on arm64
shippable: add armel targets
shippable: add ppc64el targets
shippable: add x86_64 targets
docker: add 'apt-fake' script which generate fake debian packages
docker: add qemu:debian-jessie based on outdated jessie release
shippable: add powerpc target
shippable: restrict builds to master/staging and shippable* branches
.shippable.yml | 13 ++
tests/docker/Makefile.include | 13 --
tests/docker/dockerfiles/debian-amd64-cross.docker | 38 ++
tests/docker/dockerfiles/debian-apt-fake.sh| 46 ++
tests/docker/dockerfiles/debian-arm64-cross.docker | 10 ++---
tests/docker/dockerfiles/debian-armel-cross.docker | 24 +++
tests/docker/dockerfiles/debian-armhf-cross.docker | 7 +---
.../docker/dockerfiles/debian-mipsel-cross.docker | 7 +---
.../docker/dockerfiles/debian-powerpc-cross.docker | 40 +++
.../docker/dockerfiles/debian-ppc64el-cross.docker | 24 +++
tests/docker/dockerfiles/debian-s390x-cross.docker | 23 +--
tests/docker/dockerfiles/debian8.docker| 31 +++
.../dockerfiles/{debian.docker => debian9.docker} | 15 +--
13 files changed, 256 insertions(+), 35 deletions(-)
create mode 100644 tests/docker/dockerfiles/debian-amd64-cross.docker
create mode 100755 tests/docker/dockerfiles/debian-apt-fake.sh
create mode 100644 tests/docker/dockerfiles/debian-armel-cross.docker
create mode 100644 tests/docker/dockerfiles/debian-powerpc-cross.docker
create mode 100644 te
[Qemu-devel] [PATCH v6 05/18] docker: add debian/armel based on Stretch
Signed-off-by: Philippe Mathieu-Daudé --- tests/docker/Makefile.include | 1 + tests/docker/dockerfiles/debian-armel-cross.docker | 24 ++ 2 files changed, 25 insertions(+) create mode 100644 tests/docker/dockerfiles/debian-armel-cross.docker diff --git a/tests/docker/Makefile.include b/tests/docker/Makefile.include index 1eb32eebfa..238bb7276c 100644 --- a/tests/docker/Makefile.include +++ b/tests/docker/Makefile.include @@ -56,6 +56,7 @@ docker-image-%: $(DOCKER_FILES_DIR)/%.docker "BUILD","$*") # Enforce dependancies for composite images +docker-image-debian-armel-cross: docker-image-debian9 docker-image-debian-armhf-cross: docker-image-debian9 docker-image-debian-arm64-cross: docker-image-debian9 docker-image-debian-mipsel-cross: docker-image-debian9 diff --git a/tests/docker/dockerfiles/debian-armel-cross.docker b/tests/docker/dockerfiles/debian-armel-cross.docker new file mode 100644 index 00..e3bd68f51e --- /dev/null +++ b/tests/docker/dockerfiles/debian-armel-cross.docker @@ -0,0 +1,24 @@ +# +# Docker armel cross-compiler target +# +# This docker target builds on the debian Stretch base image. +# +FROM qemu:debian9 +MAINTAINER Philippe Mathieu-Daudé + +# Add the foreign architecture we want and install dependencies +RUN dpkg --add-architecture armel && \ +apt update +RUN apt install -yy crossbuild-essential-armel +RUN DEBIAN_FRONTEND=noninteractive eatmydata \ +apt-get build-dep -yy -a armel qemu + +# Specify the cross prefix for this image (see tests/docker/common.rc) +ENV QEMU_CONFIGURE_OPTS --cross-prefix=arm-linux-gnueabi- + +RUN DEBIAN_FRONTEND=noninteractive eatmydata \ +apt-get install -y --no-install-recommends \ +libbz2-dev:armel \ +liblzo2-dev:armel \ +librdmacm-dev:armel \ +libsnappy-dev:armel -- 2.13.2
[Qemu-devel] [PATCH v6 02/18] docker: add pkg-config and python-minimal packages to debian base
Signed-off-by: Philippe Mathieu-Daudé --- tests/docker/dockerfiles/debian9.docker | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/tests/docker/dockerfiles/debian9.docker b/tests/docker/dockerfiles/debian9.docker index c74f71283c..51c13939ff 100644 --- a/tests/docker/dockerfiles/debian9.docker +++ b/tests/docker/dockerfiles/debian9.docker @@ -22,4 +22,6 @@ RUN DEBIAN_FRONTEND=noninteractive eatmydata \ ca-certificates \ clang \ flex \ -git +git \ +pkg-config \ +python-minimal -- 2.13.2
[Qemu-devel] [PATCH v6 13/18] shippable: add ppc64el targets
Signed-off-by: Philippe Mathieu-Daudé
---
.shippable.yml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/.shippable.yml b/.shippable.yml
index abcaf6f4d4..189d193da5 100644
--- a/.shippable.yml
+++ b/.shippable.yml
@@ -16,6 +16,8 @@ env:
# mips64el-softmmu disabled due to libfdt problem
- IMAGE=debian-mipsel-cross
TARGET_LIST=mipsel-softmmu,mipsel-linux-user,mips64el-linux-user
+- IMAGE=debian-ppc64el-cross
+ TARGET_LIST=ppc64-softmmu,ppc64-linux-user,ppc64abi32-linux-user
build:
pre_ci:
- make docker-image-${IMAGE} V=1
--
2.13.2
[Qemu-devel] [PATCH v6 04/18] docker: remove packages now dependent of qemu in Stretch
Signed-off-by: Philippe Mathieu-Daudé --- tests/docker/dockerfiles/debian-arm64-cross.docker | 3 --- tests/docker/dockerfiles/debian-armhf-cross.docker | 3 --- tests/docker/dockerfiles/debian-mipsel-cross.docker | 3 --- tests/docker/dockerfiles/debian-s390x-cross.docker | 3 --- 4 files changed, 12 deletions(-) diff --git a/tests/docker/dockerfiles/debian-arm64-cross.docker b/tests/docker/dockerfiles/debian-arm64-cross.docker index f1bfa64160..6ed12a3f6e 100644 --- a/tests/docker/dockerfiles/debian-arm64-cross.docker +++ b/tests/docker/dockerfiles/debian-arm64-cross.docker @@ -19,11 +19,8 @@ ENV QEMU_CONFIGURE_OPTS --cross-prefix=aarch64-linux-gnu- RUN DEBIAN_FRONTEND=noninteractive eatmydata \ apt-get install -y --no-install-recommends \ -glusterfs-common:arm64 \ libbz2-dev:arm64 \ liblzo2-dev:arm64 \ -libncursesw5-dev:arm64 \ -libnfs-dev:arm64 \ librdmacm-dev:arm64 \ libsnappy-dev:arm64 \ libxen-dev:arm64 diff --git a/tests/docker/dockerfiles/debian-armhf-cross.docker b/tests/docker/dockerfiles/debian-armhf-cross.docker index 2beacef49b..5100b0afc0 100644 --- a/tests/docker/dockerfiles/debian-armhf-cross.docker +++ b/tests/docker/dockerfiles/debian-armhf-cross.docker @@ -19,11 +19,8 @@ ENV QEMU_CONFIGURE_OPTS --cross-prefix=arm-linux-gnueabihf- RUN DEBIAN_FRONTEND=noninteractive eatmydata \ apt-get install -y --no-install-recommends \ -glusterfs-common:armhf \ libbz2-dev:armhf \ liblzo2-dev:armhf \ -libncursesw5-dev:armhf \ -libnfs-dev:armhf \ librdmacm-dev:armhf \ libsnappy-dev:armhf \ libxen-dev:armhf diff --git a/tests/docker/dockerfiles/debian-mipsel-cross.docker b/tests/docker/dockerfiles/debian-mipsel-cross.docker index 9ee997aa54..eb279c5044 100644 --- a/tests/docker/dockerfiles/debian-mipsel-cross.docker +++ b/tests/docker/dockerfiles/debian-mipsel-cross.docker @@ -20,10 +20,7 @@ RUN DEBIAN_FRONTEND=noninteractive eatmydata \ apt-get build-dep -yy -a mipsel qemu RUN DEBIAN_FRONTEND=noninteractive eatmydata \ apt-get install -y --no-install-recommends \ -glusterfs-common:mipsel \ libbz2-dev:mipsel \ liblzo2-dev:mipsel \ -libncursesw5-dev:mipsel \ -libnfs-dev:mipsel \ librdmacm-dev:mipsel \ libsnappy-dev:mipsel diff --git a/tests/docker/dockerfiles/debian-s390x-cross.docker b/tests/docker/dockerfiles/debian-s390x-cross.docker index 18fe813aa7..a085943290 100644 --- a/tests/docker/dockerfiles/debian-s390x-cross.docker +++ b/tests/docker/dockerfiles/debian-s390x-cross.docker @@ -23,10 +23,7 @@ ENV QEMU_CONFIGURE_OPTS --cross-prefix=s390x-linux-gnu- RUN DEBIAN_FRONTEND=noninteractive eatmydata \ apt-get install -y --no-install-recommends \ -glusterfs-common:s390x \ libbz2-dev:s390x \ liblzo2-dev:s390x \ -libncursesw5-dev:s390x \ -libnfs-dev:s390x \ librdmacm-dev:s390x \ libsnappy-dev:s390x -- 2.13.2
[Qemu-devel] [RFC PATCH 2/3] xen/mapcache: disable Xen on arm*
linking on Linux debian/stretch/arm[64] with libxen-4.8: exec.o: In function `reclaim_ramblock': qemu/exec.c:2071: undefined reference to `xen_invalidate_map_cache_entry' exec.o: In function `qemu_map_ram_ptr': qemu/exec.c:2177: undefined reference to `xen_map_cache' qemu/exec.c:2174: undefined reference to `xen_map_cache' exec.o: In function `qemu_ram_block_from_host': qemu/exec.c:2242: undefined reference to `xen_ram_addr_from_mapcache' qemu/exec.c:2242: undefined reference to `xen_ram_addr_from_mapcache' exec.o: In function `qemu_ram_ptr_length': qemu/exec.c:2210: undefined reference to `xen_map_cache' qemu/exec.c:2207: undefined reference to `xen_map_cache' exec.o: In function `address_space_unmap': qemu/exec.c:3357: undefined reference to `xen_invalidate_map_cache_entry' collect2: error: ld returned 1 exit status Makefile:197: recipe for target 'qemu-system-aarch64' failed make[1]: *** [qemu-system-aarch64] Error 1 Signed-off-by: Philippe Mathieu-Daudé --- include/sysemu/xen-mapcache.h | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/include/sysemu/xen-mapcache.h b/include/sysemu/xen-mapcache.h index 01daaad00c..75f0988e04 100644 --- a/include/sysemu/xen-mapcache.h +++ b/include/sysemu/xen-mapcache.h @@ -12,7 +12,9 @@ typedef hwaddr (*phys_offset_to_gaddr_t)(hwaddr start_addr, ram_addr_t size, void *opaque); -#ifdef CONFIG_XEN +/* FIXME ARM supported since Xen 4.3? */ +#if defined(CONFIG_XEN) /* XXX supported_xen_target() wrong? */ && \ +!defined(HOST_ARM) && !defined(HOST_AARCH64) void xen_map_cache_init(phys_offset_to_gaddr_t f, void *opaque); -- 2.13.2
[Qemu-devel] [RFC PATCH 3/3] xen/pt: add comments about !x86 archs
Signed-off-by: Philippe Mathieu-Daudé
---
hw/xen/xen_pt.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/hw/xen/xen_pt.c b/hw/xen/xen_pt.c
index 375efa68f6..21c32b0991 100644
--- a/hw/xen/xen_pt.c
+++ b/hw/xen/xen_pt.c
@@ -58,7 +58,7 @@
#include "hw/pci/pci.h"
#include "hw/xen/xen.h"
-#include "hw/i386/pc.h"
+#include "hw/i386/pc.h" /* TODO check !x86 */
#include "hw/xen/xen_backend.h"
#include "xen_pt.h"
#include "qemu/range.h"
@@ -687,7 +687,7 @@ static const MemoryListener xen_pt_io_listener = {
.priority = 10,
};
-static void
+static void /* TODO check !x86 */
xen_igd_passthrough_isa_bridge_create(XenPCIPassthroughState *s,
XenHostPCIDevice *dev)
{
--
2.13.2
[Qemu-devel] [RFC PATCH 1/3] configure: disable Xen PCI Passthrough on !x86 archs
linking on Linux debian/stretch/arm64 with libxen-4.8: hw/xen/xen_pt.o: In function `xen_pt_pci_read_config': qemu/hw/xen/xen_pt.c:206: undefined reference to `xen_shutdown_fatal_error' hw/xen/xen_pt.o: In function `xen_igd_passthrough_isa_bridge_create': qemu/hw/xen/xen_pt.c:698: undefined reference to `igd_passthrough_isa_bridge_create' hw/xen/xen_pt.o: In function `xen_pt_pci_write_config': qemu/hw/xen/xen_pt.c:355: undefined reference to `xen_shutdown_fatal_error' hw/xen/xen_pt_config_init.o: In function `xen_pt_status_reg_init': qemu/hw/xen/xen_pt_config_init.c:281: undefined reference to `xen_shutdown_fatal_error' qemu/hw/xen/xen_pt_config_init.c:275: undefined reference to `xen_shutdown_fatal_error' hw/xen/xen_pt_graphics.o: In function `get_vgabios': qemu/hw/xen/xen_pt_graphics.c:135: undefined reference to `pci_assign_dev_load_option_rom' collect2: error: ld returned 1 exit status Makefile:197: recipe for target 'qemu-system-aarch64' failed make[1]: *** [qemu-system-aarch64] Error 1 Signed-off-by: Philippe Mathieu-Daudé --- configure | 11 +-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/configure b/configure index 806658c98b..e4b173405a 100755 --- a/configure +++ b/configure @@ -2344,8 +2344,15 @@ EOF fi if test "$xen_pci_passthrough" != "no"; then - if test "$xen" = "yes" && test "$linux" = "yes"; then -xen_pci_passthrough=yes + if test "$xen" = "yes"; then +case "$cpu" in +i386|x32|x86_64) +if test "$linux" = "yes"; then +xen_pci_passthrough=yes +fi ;; +*) echo "Disabling Xen PCI Passthrough (not implemented on $cpu)" +xen_pci_passthrough=no ;; +esac else if test "$xen_pci_passthrough" = "yes"; then error_exit "User requested feature Xen PCI Passthrough" \ -- 2.13.2
[Qemu-devel] [RFC PATCH 0/3] disable Xen on ARM (until supported)
Hi, Those errors were triggered installing libxen v4.8 on debian Stretch ARM (32b and 64b). It seems QEMU only support Xen on x86 host. patch 1 disable PCI Passthrough if not on x86, patch 2 disable xen_map_cache() on ARM, I don't think it is the correct way to do it, then patch 3 add few comments to think about spliting x86 part from arch agnostic Xen code. That said, I realize there is no Xen ARM entry in MAINTAINERS, I'll Cc: X86 maintainers although. Regards, Phil. Philippe Mathieu-Daudé (3): configure: disable Xen PCI Passthrough on !x86 archs [XXX] xen/mapcache: disable on arm* [XXX] xen/pt: comment about !x86 archs configure | 11 +-- hw/xen/xen_pt.c | 4 ++-- include/sysemu/xen-mapcache.h | 4 +++- 3 files changed, 14 insertions(+), 5 deletions(-) -- 2.13.2
Re: [Qemu-devel] [PATCH] util/cacheinfo: add missing include
On 07/10/2017 03:55 PM, Philippe Mathieu-Daudé wrote: This include was forgotten when splitting cacheinfo.c out of tcg/ppc/tcg-target.inc.c (see commit b255b2c8). While compiling on powerpc: CC util/cacheinfo.o qemu/util/cacheinfo.c: In function 'arch_cache_info': qemu/util/cacheinfo.c:137:33: error: 'AT_ICACHEBSIZE' undeclared (first use in this function) *isize = qemu_getauxval(AT_ICACHEBSIZE); ^ qemu/util/cacheinfo.c:137:33: note: each undeclared identifier is reported only once for each function it appears in qemu/util/cacheinfo.c:140:33: error: 'AT_DCACHEBSIZE' undeclared (first use in this function) *dsize = qemu_getauxval(AT_DCACHEBSIZE); ^ qemu/rules.mak:66: recipe for target 'util/cacheinfo.o' failed make: *** [util/cacheinfo.o] Error 1 For the record, what is the os version? Because this doesn't happen here for Centos7. r~
Re: [Qemu-devel] [PATCH v6 1/2] bitmaps.md: Convert to rST; move it into 'interop' dir
On 07/10/2017 03:15 AM, Kashyap Chamarthy wrote: > This is part of the on-going effort to convert QEMU upstream > documentation syntax to reStructuredText (rST). > > The conversion to rST was done using: > > $ pandoc -f markdown -t rst bitmaps.md -o bitmaps.rst > > Then, make a couple of small syntactical adjustments. While at it, > reword a statement to avoid ambiguity. Addressing the feedback from > this thread: > > https://lists.nongnu.org/archive/html/qemu-devel/2017-06/msg05428.html > > Signed-off-by: Kashyap Chamarthy > Reviewed-by: John Snow > --- > --- > docs/devel/bitmaps.md| 505 -- > docs/interop/bitmaps.rst | 555 > +++ A shame that git rename detection doesn't see these as the same rough contents, but not too bad. I'll just review the new text; if I point out something that was pre-existing in the old text, it may be nicer to split the cleanups into a separate followup patch, but I'm also okay if they go in as part of this patch. My review is less focused on the choices used in representing things in rST and on the final display outcome, and more on the text itself (grammar and such). > +++ b/docs/interop/bitmaps.rst > + > +- Dirty bitmaps can be created at any time and attached to any node > + (not just complete drives.) Looks a bit nicer with '.' outside the sub-sentence '()'. > + > +.. contents:: > + > +Dirty Bitmap Names > +-- > + > +- A dirty bitmap's name is unique to the node, but bitmaps attached to > + different nodes can share the same name. > + > +- Dirty bitmaps created for internal use by QEMU may be anonymous and > + have no name, but any user-created bitmaps may not be. There can be s/may not be/must have a name/ > + > +- This bitmap will have a default granularity that matches the cluster > + size of its associated drive, if available, clamped to between [4KiB, s/clamped to/clamped/ > + 64KiB]. The current default for qcow2 is 64KiB. > + > + > +- QMP example response, highlighting one success and one failure: > + > + - Acknowledgement that the Transaction was accepted and jobs were > + launched: US spelling prefers Acknowledgment, but I think you are okay because of UK spelling. Again, since these are probably pre-existing and just code motion, and if you've gotten positive review of your use of rST, I'm fine with adding: Reviewed-by: Eric Blake -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org signature.asc Description: OpenPGP digital signature
Re: [Qemu-devel] [PATCH v4 1/3] ACPI: Add new ACPI structures and macros
Hi Eric, On 2017/7/10 21:54, Eric Blake wrote: > On 07/10/2017 04:25 AM, Dongjiu Geng wrote: >> (1) Add related APEI/HEST table structures and macros, these >> definition refer to ACPI 6.1 and UEFI 2.6 spec. > > Your mail is missing In-Reply-To: and References: headers, which makes > it appear as a new top-level thread for each patch. You'll want to > figure out why you didn't properly link back to your 0/3 cover letter > with Message-ID: <1499678736-5244-1-git-send-email-gengdong...@huawei.com> sorry for that and thanks for the pointing out. I will use Laszlo's suggested method to change it. and resend the patchset. $ git config --bool sendemail.thread true $ git config --bool sendemail.chainreplyto false
[Qemu-devel] [PATCH] util/cacheinfo: add missing include
This include was forgotten when splitting cacheinfo.c out of
tcg/ppc/tcg-target.inc.c (see commit b255b2c8).
While compiling on powerpc:
CC util/cacheinfo.o
qemu/util/cacheinfo.c: In function 'arch_cache_info':
qemu/util/cacheinfo.c:137:33: error: 'AT_ICACHEBSIZE' undeclared (first use
in this function)
*isize = qemu_getauxval(AT_ICACHEBSIZE);
^
qemu/util/cacheinfo.c:137:33: note: each undeclared identifier is reported
only once for each function it appears in
qemu/util/cacheinfo.c:140:33: error: 'AT_DCACHEBSIZE' undeclared (first use
in this function)
*dsize = qemu_getauxval(AT_DCACHEBSIZE);
^
qemu/rules.mak:66: recipe for target 'util/cacheinfo.o' failed
make: *** [util/cacheinfo.o] Error 1
Signed-off-by: Philippe Mathieu-Daudé
---
util/cacheinfo.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/util/cacheinfo.c b/util/cacheinfo.c
index 6253049533..593940f27b 100644
--- a/util/cacheinfo.c
+++ b/util/cacheinfo.c
@@ -129,6 +129,7 @@ static void arch_cache_info(int *isize, int *dsize)
}
#elif defined(_ARCH_PPC) && defined(__linux__)
+# include "elf.h"
static void arch_cache_info(int *isize, int *dsize)
{
--
2.13.2
Re: [Qemu-devel] [PATCH v4 1/3] ACPI: Add new ACPI structures and macros
Dear,Laszlo On 2017/7/10 22:04, Laszlo Ersek wrote: > Yes, the git-send-email options to use are: > > --thread --no-chain-reply-to > > Best to set them permanently in one's qemu clone, > > $ git config --bool sendemail.thread true > $ git config --bool sendemail.chainreplyto false > > This is called "shallow threading" (see git-send-email(1)). great, thanks for your suggestion.
Re: [Qemu-devel] About the trace framework
On 07/10/2017 01:24 PM, Xie Changlong wrote: 在 7/9/2017 5:57 PM, Wang Dong 写道: Hi, I am new to QEMU. But I got some problem so that I want to figure it out. So I try to debug qemu to see what happened. And I found trace framework. I think this will help me understand the point. So I compiled qemu with option: ## *--enable-trace-backends=simple* And did as the docs/tracing.txt tell. But when I execute the example command in it, nothing just happens. *./scripts/simpletrace.py trace-events-all trace-xx(my trace file produced by qemu) I am not sure what happened. Just ask this. Any clue will be appreciated. Thanks in advance. * Did you set *trace-event*? I've encountered this issue in the past :) (qemu) help trace-event trace-event name on|off -- changes status of a specific trace event (qemu) info trace-events yes, I set it. I just did as the docs told. If this does not work or misses something, it should be corrected I think. Have you also tried out the examples in docs? how did you do that? I think I misses some. Could you tell more about it? Thanks. -- Best regards. Wang Dong
[Qemu-devel] [PATCH 3/3] Revert "machine: Convert abstract typename on compat_props to subclass names"
This reverts commit 0bcba41fe379e4c6834adcf1456d9099db31a5b2.
The bug addressed by that commit is now fixed in a better way by the
commit "qdev: fix the order compat and global properties are applied".
Signed-off-by: Eduardo Habkost
---
hw/core/machine.c | 26 +++---
1 file changed, 3 insertions(+), 23 deletions(-)
diff --git a/hw/core/machine.c b/hw/core/machine.c
index ecb5552..1d10b01 100644
--- a/hw/core/machine.c
+++ b/hw/core/machine.c
@@ -770,18 +770,11 @@ static void machine_class_finalize(ObjectClass *klass,
void *data)
g_free(mc->name);
}
-static void machine_register_compat_for_subclass(ObjectClass *oc, void *opaque)
-{
-GlobalProperty *p = opaque;
-register_compat_prop(object_class_get_name(oc), p->property, p->value);
-}
-
void machine_register_compat_props(MachineState *machine)
{
MachineClass *mc = MACHINE_GET_CLASS(machine);
int i;
GlobalProperty *p;
-ObjectClass *oc;
if (!mc->compat_props) {
return;
@@ -789,22 +782,9 @@ void machine_register_compat_props(MachineState *machine)
for (i = 0; i < mc->compat_props->len; i++) {
p = g_array_index(mc->compat_props, GlobalProperty *, i);
-oc = object_class_by_name(p->driver);
-if (oc && object_class_is_abstract(oc)) {
-/* temporary hack to make sure we do not override
- * globals set explicitly on -global: if an abstract class
- * is on compat_props, register globals for all its
- * non-abstract subtypes instead.
- *
- * This doesn't solve the problem for cases where
- * a non-abstract typename mentioned on compat_props
- * has subclasses, like spapr-pci-host-bridge.
- */
-object_class_foreach(machine_register_compat_for_subclass,
- p->driver, false, p);
-} else {
-register_compat_prop(p->driver, p->property, p->value);
-}
+/* Machine compat_props must never cause errors: */
+p->errp = &error_abort;
+qdev_prop_register_global(p);
}
}
--
2.9.4
[Qemu-devel] [PATCH 2/3] test-qdev-global-props: Test global property ordering
Test case to detect the bug fixed by commit
"qdev: fix the order compat and global properties are applied".
Signed-off-by: Eduardo Habkost
---
tests/test-qdev-global-props.c | 33 +
1 file changed, 33 insertions(+)
diff --git a/tests/test-qdev-global-props.c b/tests/test-qdev-global-props.c
index 48e5b73..ef2951f 100644
--- a/tests/test-qdev-global-props.c
+++ b/tests/test-qdev-global-props.c
@@ -33,6 +33,8 @@
#define STATIC_TYPE(obj) \
OBJECT_CHECK(MyType, (obj), TYPE_STATIC_PROPS)
+#define TYPE_SUBCLASS "static_prop_subtype"
+
#define PROP_DEFAULT 100
typedef struct MyType {
@@ -63,6 +65,11 @@ static const TypeInfo static_prop_type = {
.class_init = static_prop_class_init,
};
+static const TypeInfo subclass_type = {
+.name = TYPE_SUBCLASS,
+.parent = TYPE_STATIC_PROPS,
+};
+
/* Test simple static property setting to default value */
static void test_static_prop_subprocess(void)
{
@@ -279,12 +286,35 @@ static void test_dynamic_globalprop_nouser(void)
g_test_trap_assert_stdout("");
}
+/* Test if global props affecting subclasses are applied in the right order */
+static void test_subclass_global_props(void)
+{
+MyType *mt;
+/* Global properties must be applied in the order they were registered */
+static GlobalProperty props[] = {
+{ TYPE_STATIC_PROPS, "prop1", "101" },
+{ TYPE_SUBCLASS, "prop1", "102" },
+{ TYPE_SUBCLASS, "prop2", "103" },
+{ TYPE_STATIC_PROPS, "prop2", "104" },
+{}
+};
+
+qdev_prop_register_global_list(props);
+
+mt = STATIC_TYPE(object_new(TYPE_SUBCLASS));
+qdev_init_nofail(DEVICE(mt));
+
+g_assert_cmpuint(mt->prop1, ==, 102);
+g_assert_cmpuint(mt->prop2, ==, 104);
+}
+
int main(int argc, char **argv)
{
g_test_init(&argc, &argv, NULL);
module_call_init(MODULE_INIT_QOM);
type_register_static(&static_prop_type);
+type_register_static(&subclass_type);
type_register_static(&dynamic_prop_type);
type_register_static(&hotplug_type);
type_register_static(&nohotplug_type);
@@ -310,6 +340,9 @@ int main(int argc, char **argv)
g_test_add_func("/qdev/properties/dynamic/global/nouser",
test_dynamic_globalprop_nouser);
+g_test_add_func("/qdev/properties/global/subclass",
+test_subclass_global_props);
+
g_test_run();
return 0;
--
2.9.4
[Qemu-devel] [PATCH 1/3] qdev: fix the order compat and global properties are applied
From: Greg Kurz
The current code recursively applies global properties from child up to
parent types. This can cause properties passed with the -global option to
be silently overridden by internal compat properties.
This is exactly what happens with virtio-*-pci drivers since commit:
"9a4c0e220d8a hw/virtio-pci: fix virtio behaviour"
Passing -device virtio-blk-pci.disable-modern=off has no effect on 2.6
machine types because the internal virtio-pci.disable-modern=on compat
property always prevail.
This patch fixes the issue by reversing the logic: we now go through the
global property list and, for each property, we check if it is applicable
to the device.
This result in compat properties being applied first, in the order they
appear in the HW_COMPAT_* macros, followed by global properties, in they
order appear on the command line.
Signed-off-by: Greg Kurz
Message-Id:
<148103887228.22326.47840687360929.st...@bahia.lab.toulouse-stg.fr.ibm.com>
Signed-off-by: Eduardo Habkost
---
hw/core/qdev-properties.c | 15 ++-
1 file changed, 2 insertions(+), 13 deletions(-)
diff --git a/hw/core/qdev-properties.c b/hw/core/qdev-properties.c
index f11d578..41cca9d 100644
--- a/hw/core/qdev-properties.c
+++ b/hw/core/qdev-properties.c
@@ -1148,8 +1148,7 @@ int qdev_prop_check_globals(void)
return ret;
}
-static void qdev_prop_set_globals_for_type(DeviceState *dev,
- const char *typename)
+void qdev_prop_set_globals(DeviceState *dev)
{
GList *l;
@@ -1157,7 +1156,7 @@ static void qdev_prop_set_globals_for_type(DeviceState
*dev,
GlobalProperty *prop = l->data;
Error *err = NULL;
-if (strcmp(typename, prop->driver) != 0) {
+if (object_dynamic_cast(OBJECT(dev), prop->driver) == NULL) {
continue;
}
prop->used = true;
@@ -1175,16 +1174,6 @@ static void qdev_prop_set_globals_for_type(DeviceState
*dev,
}
}
-void qdev_prop_set_globals(DeviceState *dev)
-{
-ObjectClass *class = object_get_class(OBJECT(dev));
-
-do {
-qdev_prop_set_globals_for_type(dev, object_class_get_name(class));
-class = object_class_get_parent(class);
-} while (class);
-}
-
/* --- 64bit unsigned int 'size' type --- */
static void get_size(Object *obj, Visitor *v, const char *name, void *opaque,
--
2.9.4
[Qemu-devel] [PATCH 0/3] qdev: fix the order compat and global properties are applied
Before 2.8 was released, we found a bug in the way global properties are applied by device code. Greg Kurz sent a fix[1], but we decide to include a more conservative workaround[2] because the 2.8 release was very close. The plan was to include Greg's patch in 2.9, but we forgot to do that. I'm now resending: Greg's original patch; a test case to detect the original bug; and a revert of the workaround we included in 2.8. [1] https://www.mail-archive.com/qemu-devel@nongnu.org/msg416944.html [2] commit 0bcba41fe379e4c6834adcf1456d9099db31a5b2 "machine: Convert abstract typename on compat_props to subclass names" Eduardo Habkost (2): test-qdev-global-props: Test global property ordering Revert "machine: Convert abstract typename on compat_props to subclass names" Greg Kurz (1): qdev: fix the order compat and global properties are applied hw/core/machine.c | 26 +++--- hw/core/qdev-properties.c | 15 ++- tests/test-qdev-global-props.c | 33 + 3 files changed, 38 insertions(+), 36 deletions(-) -- 2.9.4
Re: [Qemu-devel] [PATCH 09/22] exec-all: shrink tb->invalid to uint8_t
On Sun, Jul 09, 2017 at 10:11:21 -1000, Richard Henderson wrote: > On 07/08/2017 09:50 PM, Emilio G. Cota wrote: > >To avoid wasting a byte. I don't have any use in mind for this byte, > >but I think it's good to leave this byte explicitly free for future use. > >See this discussion for how the u16 came to be: > > https://lists.gnu.org/archive/html/qemu-devel/2016-07/msg04564.html > >We could use a bool but in some systems that would take > 1 byte. > > > >Signed-off-by: Emilio G. Cota > >--- > > include/exec/exec-all.h | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > What I would prefer to do is generalize tb->cflags. Those values *do* > affect how we compile the TB, and yet we don't take them into account. So I > think it would be a good idea to feed that into the TB hash. I'm having trouble seeing how this could work. Where do we get the "current" values from the current state, i.e. the ones we need to generate the hash and perform comparisons? In particular: - CF_COUNT_MASK: just use CF_COUNT_MASK? - CF_LAST_IO: ? - CF_NOCACHE: always 0 I guess - CF_USE/IGNORE_ICOUNT: ? Or should we just mask these out for hashing/cmp purposes? > At present we use 18 bits of the uint32_t. That leaves plenty of room for: > > * the compile-time value of parallel_cpus, so we don't have to keep flushing > the TBs that we create for cpu_exec_step_atomic. This makes sense, yes. > * invalid, which no TB within the hashtable would have set. Agreed. E.
Re: [Qemu-devel] qemu-x86_64: Error processing bextr
On 07/10/2017 01:17 PM, Ricardo Ribalda Delgado wrote: 0x0040008179bf <+31>: 8f ea 78 10 d0 08 04 00 00 bextr $0x408,%eax,%edx ... It seems that, bextr is not supported by the emulator/cpu, althoug I have launched the emualtor with -cpu Haswell, that should support bmi1 (https://en.wikipedia.org/wiki/Bit_Manipulation_Instruction_Sets#BMI1) This is not the BMI1 version of bextr, it's the TBM version of bextr. https://en.wikipedia.org/wiki/Bit_Manipulation_Instruction_Sets#TBM_.28Trailing_Bit_Manipulation.29 TBM is not implemented in qemu yet. r~
[Qemu-devel] 答复: Re: [PATCH] tcg/mips: reserve a register for the guest_base.
> On 07/09/2017 11:12 PM, Jiang Biao wrote: > > Reserve a register for the guest_base using ppc code for reference. > > By doing so, we do not have to recompute it for every memory load. > > > > Signed-off-by: Jiang Biao > > Signed-off-by: Richard Henderson > > --- > > tcg/mips/tcg-target.inc.c | 17 + > > 1 file changed, 13 insertions(+), 4 deletions(-) > > For future reference, you should not add a Signed-off-by for someone else. > That is like writing someone else's signature. > > You may acknowledge my suggestion with a Suggested-by tag. > > QEMU uses the same rules for this as does the linux kernel. Please read > > > https://github.com/torvalds/linux/blob/master/Documentation/process/submitting-patches.rst > > or at least section 11 from > >> https://github.com/torvalds/linux/blob/master/Documentation/translations/zh_CN/SubmittingPatches > (The translation may be be out of date. I don't see any of the other tags, > like Suggested-by, within the Chinese text.) > > That said, applied to tcg-next. Got that:-). Thanks for your advice.
Re: [Qemu-devel] [PATCH 12/17] migration: add postcopy migration of dirty bitmaps
On 07/10/2017 05:17 AM, Vladimir Sementsov-Ogievskiy wrote: Can we document this somehow? In this terminology, what happens with frozen bitmap (which in fact is like "active" for the user) on successful backup finish? It turns into a difference between current-state and what-was-backed-up? It is not very transparent.. May be bitmap part, related to the backup is substituted from the bitmap? // it's hard for me to believe that 'frozen' doesn't mean 'can not move', but if it is already established idea then ok. Admittedly a mistake on my part, mixing up implementation detail and exposed interface. It's not necessarily an established idea... To the end-user, a bitmap that is "frozen" is still indeed recording new writes from a certain point of view, because once the backup completes, the bitmap (secretly: the promoted successor) will contain writes that occurred during that frozen period of time. How could this happen unless our "frozen" bitmap was recording writes? Oops, that's not very frozen at all, is it. That's an unfortunate bit of design that I didn't take into account when I named the "Frozen" property and exposed it via the JSON API. I was only thinking about it from the implementation point of view, like you are -- the bitmap _is_ well and truly frozen: it cannot be modified and does not record any writes. (Only the successor does, as you know.) So as it stands we have a discrepancy in the code between internal and external usage over what exactly "frozen" implies. It's a poor name. I should have named the QAPI-facing portion of it "locked" or "protected" or something that helped imply that it could continue to change, but it was off-limits.
Re: [Qemu-devel] [PATCH v4 09/17] dirty-bitmap: Change bdrv_dirty_iter_next() to report byte offset
On 07/03/2017 11:10 AM, Eric Blake wrote: Thanks to recent cleanups, most callers were scaling a return value of sectors into bytes (the exception, in qcow2-bitmap, will be converted to byte-based iteration later). Update the interface to do the scaling internally instead. Signed-off-by: Eric Blake Reviewed-By: John Snow I still think about getting Arby's when I write that line, and now I'm hungry.
[Qemu-devel] qemu-x86_64: Error processing bextr
Hi I have the following assembly snipset (from get_common_indeces in glibc compiled with gcc 6.3 -march=bdver4) 0x0040008179b3 <+19>: 89 15 8b c3 20 00 mov %edx,0x20c38b(%rip)# 0x4000a23d44 <_rtld_local_ro+132> 0x0040008179b9 <+25>: 89 1d 7d c3 20 00 mov %ebx,0x20c37d(%rip)# 0x4000a23d3c <_rtld_local_ro+124> 0x0040008179bf <+31>: 8f ea 78 10 d0 08 04 00 00 bextr $0x408,%eax,%edx 0x0040008179c8 <+40>: 89 0d 72 c3 20 00 mov %ecx,0x20c372(%rip)# 0x4000a23d40 <_rtld_local_ro+128> 0x0040008179ce <+46>: 89 05 64 c3 20 00 mov %eax,0x20c364(%rip)# 0x4000a23d38 <_rtld_local_ro+120> When I run the application using qemu-x86-64, the instruction bextr is not understood by the emulator and results in a SIGSEGV, because it runs: 0x0040008179b9: mov%ebx,0x20c37d(%rip)# 0x4000a23d3c 0x0040008179bf: (bad) 0x0040008179c0: (bad) 0x0040008179c1: js 0x40008179d3 0x0040008179c3: rorb (%rax) It seems that, bextr is not supported by the emulator/cpu, althoug I have launched the emualtor with -cpu Haswell, that should support bmi1 (https://en.wikipedia.org/wiki/Bit_Manipulation_Instruction_Sets#BMI1) What am I doing wrong? Thanks! cc: Richard Henderson and Blue Swril, that Implemented BEXTR -- Ricardo Ribalda
Re: [Qemu-devel] [PATCH v4 08/17] dirty-bitmap: Set iterator start by offset, not sector
On 07/03/2017 11:10 AM, Eric Blake wrote: All callers to bdrv_dirty_iter_new() passed 0 for their initial starting point, drop that parameter. Most callers to bdrv_set_dirty_iter() were scaling a byte offset to a sector number; the exception qcow2-bitmap will be converted later to use byte rather than sector iteration. Move the scaling to occur internally to dirty bitmap code instead, so that callers now pass in bytes. Signed-off-by: Eric Blake Reviewed-by: John Snow
Re: [Qemu-devel] [PATCH v4 07/17] qcow2: Switch sectors_covered_by_bitmap_cluster() to byte-based
On 07/03/2017 11:10 AM, Eric Blake wrote: We are gradually converting to byte-based interfaces, as they are easier to reason about than sector-based. Change the qcow2 bitmap helper function sectors_covered_by_bitmap_cluster(), renaming it in the process. Signed-off-by: Eric Blake It really will be nice to not have multiple layers of scaling for bitmaps anymore. Reviewed-by: John Snow
[Qemu-devel] [PATCH v3 3/4] xen/mapcache: introduce xen_replace_cache_entry()
This new call is trying to update a requested map cache entry
according to the changes in the physmap. The call is searching
for the entry, unmaps it and maps again at the same place using
a new guest address. If the mapping is dummy this call will
make it real.
This function makes use of a new xenforeignmemory_map2() call
with an extended interface that was recently introduced in
libxenforeignmemory [1].
[1] https://www.mail-archive.com/xen-devel@lists.xen.org/msg113007.html
Signed-off-by: Igor Druzhinin
---
configure | 18 +
hw/i386/xen/xen-mapcache.c| 85 +++
include/hw/xen/xen_common.h | 14 +++
include/sysemu/xen-mapcache.h | 11 +-
4 files changed, 119 insertions(+), 9 deletions(-)
diff --git a/configure b/configure
index c571ad1..ad6156b 100755
--- a/configure
+++ b/configure
@@ -2021,6 +2021,24 @@ EOF
# Xen unstable
elif
cat > $TMPC <
+int main(void) {
+ xenforeignmemory_handle *xfmem;
+
+ xfmem = xenforeignmemory_open(0, 0);
+ xenforeignmemory_map2(xfmem, 0, 0, 0, 0, 0, 0, 0);
+
+ return 0;
+}
+EOF
+compile_prog "" "$xen_libs -lxendevicemodel $xen_stable_libs"
+ then
+ xen_stable_libs="-lxendevicemodel $xen_stable_libs"
+ xen_ctrl_version=41000
+ xen=yes
+elif
+cat > $TMPC <
diff --git a/hw/i386/xen/xen-mapcache.c b/hw/i386/xen/xen-mapcache.c
index 39cb511..8bc63e0 100644
--- a/hw/i386/xen/xen-mapcache.c
+++ b/hw/i386/xen/xen-mapcache.c
@@ -151,6 +151,7 @@ void xen_map_cache_init(phys_offset_to_gaddr_t f, void
*opaque)
}
static void xen_remap_bucket(MapCacheEntry *entry,
+ void *vaddr,
hwaddr size,
hwaddr address_index,
bool dummy)
@@ -167,7 +168,9 @@ static void xen_remap_bucket(MapCacheEntry *entry,
err = g_malloc0(nb_pfn * sizeof (int));
if (entry->vaddr_base != NULL) {
-ram_block_notify_remove(entry->vaddr_base, entry->size);
+if (!(entry->flags & XEN_MAPCACHE_ENTRY_DUMMY)) {
+ram_block_notify_remove(entry->vaddr_base, entry->size);
+}
if (munmap(entry->vaddr_base, entry->size) != 0) {
perror("unmap fails");
exit(-1);
@@ -181,11 +184,11 @@ static void xen_remap_bucket(MapCacheEntry *entry,
}
if (!dummy) {
-vaddr_base = xenforeignmemory_map(xen_fmem, xen_domid,
- PROT_READ | PROT_WRITE,
+vaddr_base = xenforeignmemory_map2(xen_fmem, xen_domid, vaddr,
+ PROT_READ | PROT_WRITE, 0,
nb_pfn, pfns, err);
if (vaddr_base == NULL) {
-perror("xenforeignmemory_map");
+perror("xenforeignmemory_map2");
exit(-1);
}
} else {
@@ -193,7 +196,7 @@ static void xen_remap_bucket(MapCacheEntry *entry,
* We create dummy mappings where we are unable to create a foreign
* mapping immediately due to certain circumstances (i.e. on resume
now)
*/
-vaddr_base = mmap(NULL, size, PROT_READ | PROT_WRITE,
+vaddr_base = mmap(vaddr, size, PROT_READ | PROT_WRITE,
MAP_ANON | MAP_SHARED, -1, 0);
if (vaddr_base == NULL) {
perror("mmap");
@@ -201,6 +204,10 @@ static void xen_remap_bucket(MapCacheEntry *entry,
}
}
+if (!(entry->flags & XEN_MAPCACHE_ENTRY_DUMMY)) {
+ram_block_notify_add(vaddr_base, size);
+}
+
entry->vaddr_base = vaddr_base;
entry->paddr_index = address_index;
entry->size = size;
@@ -213,7 +220,6 @@ static void xen_remap_bucket(MapCacheEntry *entry,
entry->flags &= ~(XEN_MAPCACHE_ENTRY_DUMMY);
}
-ram_block_notify_add(entry->vaddr_base, entry->size);
bitmap_zero(entry->valid_mapping, nb_pfn);
for (i = 0; i < nb_pfn; i++) {
if (!err[i]) {
@@ -286,14 +292,14 @@ tryagain:
if (!entry) {
entry = g_malloc0(sizeof (MapCacheEntry));
pentry->next = entry;
-xen_remap_bucket(entry, cache_size, address_index, dummy);
+xen_remap_bucket(entry, NULL, cache_size, address_index, dummy);
} else if (!entry->lock) {
if (!entry->vaddr_base || entry->paddr_index != address_index ||
entry->size != cache_size ||
!test_bits(address_offset >> XC_PAGE_SHIFT,
test_bit_size >> XC_PAGE_SHIFT,
entry->valid_mapping)) {
-xen_remap_bucket(entry, cache_size, address_index, dummy);
+xen_remap_bucket(entry, NULL, cache_size, address_index, dummy);
}
}
@@ -490,3 +496,66 @@ void xen_invalidate_map_cache(void)
mapcache_unlock();
}
+
+static uint8_t *xen_replace_cache_entry_unlocked(hwaddr old_phys_addr,
+
[Qemu-devel] [PATCH v3 4/4] xen: don't use xenstore to save/restore physmap anymore
If we have a system with xenforeignmemory_map2() implemented
we don't need to save/restore physmap on suspend/restore
anymore. In case we resume a VM without physmap - try to
recreate the physmap during memory region restore phase and
remap map cache entries accordingly. The old code is left
for compatibility reasons.
Signed-off-by: Igor Druzhinin
---
hw/i386/xen/xen-hvm.c | 48 ++---
hw/i386/xen/xen-mapcache.c | 4
include/hw/xen/xen_common.h | 1 +
3 files changed, 42 insertions(+), 11 deletions(-)
diff --git a/hw/i386/xen/xen-hvm.c b/hw/i386/xen/xen-hvm.c
index d259cf7..d24ca47 100644
--- a/hw/i386/xen/xen-hvm.c
+++ b/hw/i386/xen/xen-hvm.c
@@ -289,6 +289,7 @@ static XenPhysmap *get_physmapping(XenIOState *state,
return NULL;
}
+#ifdef XEN_COMPAT_PHYSMAP
static hwaddr xen_phys_offset_to_gaddr(hwaddr start_addr,
ram_addr_t size, void
*opaque)
{
@@ -334,6 +335,12 @@ static int xen_save_physmap(XenIOState *state, XenPhysmap
*physmap)
}
return 0;
}
+#else
+static int xen_save_physmap(XenIOState *state, XenPhysmap *physmap)
+{
+return 0;
+}
+#endif
static int xen_add_to_physmap(XenIOState *state,
hwaddr start_addr,
@@ -368,6 +375,26 @@ go_physmap:
DPRINTF("mapping vram to %"HWADDR_PRIx" - %"HWADDR_PRIx"\n",
start_addr, start_addr + size);
+mr_name = memory_region_name(mr);
+
+physmap = g_malloc(sizeof (XenPhysmap));
+
+physmap->start_addr = start_addr;
+physmap->size = size;
+physmap->name = mr_name;
+physmap->phys_offset = phys_offset;
+
+QLIST_INSERT_HEAD(&state->physmap, physmap, list);
+
+if (runstate_check(RUN_STATE_INMIGRATE)) {
+/* Now when we have a physmap entry we can replace a dummy mapping with
+ * a real one of guest foreign memory. */
+uint8_t *p = xen_replace_cache_entry(phys_offset, start_addr, size);
+assert(p && p == memory_region_get_ram_ptr(mr));
+
+return 0;
+}
+
pfn = phys_offset >> TARGET_PAGE_BITS;
start_gpfn = start_addr >> TARGET_PAGE_BITS;
for (i = 0; i < size >> TARGET_PAGE_BITS; i++) {
@@ -382,17 +409,6 @@ go_physmap:
}
}
-mr_name = memory_region_name(mr);
-
-physmap = g_malloc(sizeof (XenPhysmap));
-
-physmap->start_addr = start_addr;
-physmap->size = size;
-physmap->name = mr_name;
-physmap->phys_offset = phys_offset;
-
-QLIST_INSERT_HEAD(&state->physmap, physmap, list);
-
xc_domain_pin_memory_cacheattr(xen_xc, xen_domid,
start_addr >> TARGET_PAGE_BITS,
(start_addr + size - 1) >> TARGET_PAGE_BITS,
@@ -1158,6 +1174,7 @@ static void xen_exit_notifier(Notifier *n, void *data)
xs_daemon_close(state->xenstore);
}
+#ifdef XEN_COMPAT_PHYSMAP
static void xen_read_physmap(XenIOState *state)
{
XenPhysmap *physmap = NULL;
@@ -1205,6 +1222,11 @@ static void xen_read_physmap(XenIOState *state)
}
free(entries);
}
+#else
+static void xen_read_physmap(XenIOState *state)
+{
+}
+#endif
static void xen_wakeup_notifier(Notifier *notifier, void *data)
{
@@ -1331,7 +1353,11 @@ void xen_hvm_init(PCMachineState *pcms, MemoryRegion
**ram_memory)
state->bufioreq_local_port = rc;
/* Init RAM management */
+#ifdef XEN_COMPAT_PHYSMAP
xen_map_cache_init(xen_phys_offset_to_gaddr, state);
+#else
+xen_map_cache_init(NULL, state);
+#endif
xen_ram_init(pcms, ram_size, ram_memory);
qemu_add_vm_change_state_handler(xen_hvm_change_state_handler, state);
diff --git a/hw/i386/xen/xen-mapcache.c b/hw/i386/xen/xen-mapcache.c
index 8bc63e0..84cc4a2 100644
--- a/hw/i386/xen/xen-mapcache.c
+++ b/hw/i386/xen/xen-mapcache.c
@@ -239,7 +239,9 @@ static uint8_t *xen_map_cache_unlocked(hwaddr phys_addr,
hwaddr size,
hwaddr address_offset;
hwaddr cache_size = size;
hwaddr test_bit_size;
+#ifdef XEN_COMPAT_PHYSMAP
bool translated = false;
+#endif
bool dummy = false;
tryagain:
@@ -307,11 +309,13 @@ tryagain:
test_bit_size >> XC_PAGE_SHIFT,
entry->valid_mapping)) {
mapcache->last_entry = NULL;
+#ifdef XEN_COMPAT_PHYSMAP
if (!translated && mapcache->phys_offset_to_gaddr) {
phys_addr = mapcache->phys_offset_to_gaddr(phys_addr, size,
mapcache->opaque);
translated = true;
goto tryagain;
}
+#endif
if (!dummy && runstate_check(RUN_STATE_INMIGRATE)) {
dummy = true;
goto tryagain;
diff --git a/include/hw/xen/xen_common.h b/include/hw/xen/xen_common.h
index e28ed48..86c7f26 100644
--- a/include/hw/xen/xen_common.h
+++ b/include/hw/xen/xen_common.h
@@ -80,6 +80,7 @@ extern xenforeignmemory_handle *xen_fmem;
#if CONFIG_XEN_CTRL_INTERFACE_VERSION < 41000
+#define XEN_COMPAT_PHYSMAP
static inline void *xenforeignmemory_
[Qemu-devel] [PATCH v3 1/4] xen: move physmap saving into a separate function
Non-functional change.
Signed-off-by: Igor Druzhinin
Reviewed-by: Stefano Stabellini
Reviewed-by: Paul Durrant
---
hw/i386/xen/xen-hvm.c | 57 ---
1 file changed, 31 insertions(+), 26 deletions(-)
diff --git a/hw/i386/xen/xen-hvm.c b/hw/i386/xen/xen-hvm.c
index cffa7e2..d259cf7 100644
--- a/hw/i386/xen/xen-hvm.c
+++ b/hw/i386/xen/xen-hvm.c
@@ -305,6 +305,36 @@ static hwaddr xen_phys_offset_to_gaddr(hwaddr start_addr,
return start_addr;
}
+static int xen_save_physmap(XenIOState *state, XenPhysmap *physmap)
+{
+char path[80], value[17];
+
+snprintf(path, sizeof(path),
+"/local/domain/0/device-model/%d/physmap/%"PRIx64"/start_addr",
+xen_domid, (uint64_t)physmap->phys_offset);
+snprintf(value, sizeof(value), "%"PRIx64, (uint64_t)physmap->start_addr);
+if (!xs_write(state->xenstore, 0, path, value, strlen(value))) {
+return -1;
+}
+snprintf(path, sizeof(path),
+"/local/domain/0/device-model/%d/physmap/%"PRIx64"/size",
+xen_domid, (uint64_t)physmap->phys_offset);
+snprintf(value, sizeof(value), "%"PRIx64, (uint64_t)physmap->size);
+if (!xs_write(state->xenstore, 0, path, value, strlen(value))) {
+return -1;
+}
+if (physmap->name) {
+snprintf(path, sizeof(path),
+"/local/domain/0/device-model/%d/physmap/%"PRIx64"/name",
+xen_domid, (uint64_t)physmap->phys_offset);
+if (!xs_write(state->xenstore, 0, path,
+ physmap->name, strlen(physmap->name))) {
+return -1;
+}
+}
+return 0;
+}
+
static int xen_add_to_physmap(XenIOState *state,
hwaddr start_addr,
ram_addr_t size,
@@ -316,7 +346,6 @@ static int xen_add_to_physmap(XenIOState *state,
XenPhysmap *physmap = NULL;
hwaddr pfn, start_gpfn;
hwaddr phys_offset = memory_region_get_ram_addr(mr);
-char path[80], value[17];
const char *mr_name;
if (get_physmapping(state, start_addr, size)) {
@@ -368,31 +397,7 @@ go_physmap:
start_addr >> TARGET_PAGE_BITS,
(start_addr + size - 1) >> TARGET_PAGE_BITS,
XEN_DOMCTL_MEM_CACHEATTR_WB);
-
-snprintf(path, sizeof(path),
-"/local/domain/0/device-model/%d/physmap/%"PRIx64"/start_addr",
-xen_domid, (uint64_t)phys_offset);
-snprintf(value, sizeof(value), "%"PRIx64, (uint64_t)start_addr);
-if (!xs_write(state->xenstore, 0, path, value, strlen(value))) {
-return -1;
-}
-snprintf(path, sizeof(path),
-"/local/domain/0/device-model/%d/physmap/%"PRIx64"/size",
-xen_domid, (uint64_t)phys_offset);
-snprintf(value, sizeof(value), "%"PRIx64, (uint64_t)size);
-if (!xs_write(state->xenstore, 0, path, value, strlen(value))) {
-return -1;
-}
-if (mr_name) {
-snprintf(path, sizeof(path),
-"/local/domain/0/device-model/%d/physmap/%"PRIx64"/name",
-xen_domid, (uint64_t)phys_offset);
-if (!xs_write(state->xenstore, 0, path, mr_name, strlen(mr_name))) {
-return -1;
-}
-}
-
-return 0;
+return xen_save_physmap(state, physmap);
}
static int xen_remove_from_physmap(XenIOState *state,
--
2.7.4
[Qemu-devel] [PATCH v3 0/4] xen: don't save/restore the physmap on VM save/restore
Saving/restoring the physmap to/from xenstore was introduced to QEMU majorly in order to cover up the VRAM region restore issue. The sequence of restore operations implies that we should know the effective guest VRAM address *before* we have the VRAM region restored (which happens later). Unfortunately, in Xen environment VRAM memory does actually belong to a guest - not QEMU itself - which means the position of this region is unknown beforehand and can't be mapped into QEMU address space immediately. Previously, recreating xenstore keys, holding the physmap, by the toolstack helped to get this information in place at the right moment ready to be consumed by QEMU to map the region properly. But using xenstore for it has certain disadvantages: toolstack needs to be aware of these keys and save/restore them accordingly; accessing xenstore requires extra privileges which hinders QEMU sandboxing. The previous attempt to get rid of that was to remember all the VRAM pointers during QEMU initialization phase and then update them all at once when an actual foreign mapping is established. Unfortunately, this approach worked only for VRAM and only for a predefined set of devices - stdvga and cirrus. QXL and other possible future devices using a moving emulated MMIO region would be equally broken. The new approach leverages xenforeignmemory_map2() call recently introduced in libxenforeignmemory. It allows to create a dummy anonymous mapping for QEMU during its initialization and change it to a real one later during machine state restore. --- Changes in v3: * Patch 3: use dummy flag based checks to gate ram_block_notify_* functions * Patch 3: switch to inline compat function instead of a straight define * Patch 4: add additional XEN_COMPAT_PHYSMAP blocks Changed in v2: * Patch 2: set dummy flag in a new flags field in struct MapCacheEntry * Patch 3: change xen_remap_cache_entry name and signature * Patch 3: gate ram_block_notify_* functions in xen_remap_bucket * Patch 3: rewrite the logic of xen_replace_cache_entry_unlocked to reuse the existing entry instead of allocating a new one * Patch 4: don't use xen_phys_offset_to_gaddr in non-compat mode --- Igor Druzhinin (4): xen: move physmap saving into a separate function xen/mapcache: add an ability to create dummy mappings xen/mapcache: introduce xen_replace_cache_entry() xen: don't use xenstore to save/restore physmap anymore configure | 18 +++ hw/i386/xen/xen-hvm.c | 105 +++- hw/i386/xen/xen-mapcache.c| 121 ++ include/hw/xen/xen_common.h | 15 ++ include/sysemu/xen-mapcache.h | 11 +++- 5 files changed, 222 insertions(+), 48 deletions(-) -- 2.7.4
[Qemu-devel] [PATCH v3 2/4] xen/mapcache: add an ability to create dummy mappings
Dummys are simple anonymous mappings that are placed instead
of regular foreign mappings in certain situations when we need
to postpone the actual mapping but still have to give a
memory region to QEMU to play with.
This is planned to be used for restore on Xen.
Signed-off-by: Igor Druzhinin
Reviewed-by: Paul Durrant
Reviewed-by: Stefano Stabellini
---
hw/i386/xen/xen-mapcache.c | 44
1 file changed, 36 insertions(+), 8 deletions(-)
diff --git a/hw/i386/xen/xen-mapcache.c b/hw/i386/xen/xen-mapcache.c
index e60156c..39cb511 100644
--- a/hw/i386/xen/xen-mapcache.c
+++ b/hw/i386/xen/xen-mapcache.c
@@ -53,6 +53,8 @@ typedef struct MapCacheEntry {
uint8_t *vaddr_base;
unsigned long *valid_mapping;
uint8_t lock;
+#define XEN_MAPCACHE_ENTRY_DUMMY (1 << 0)
+uint8_t flags;
hwaddr size;
struct MapCacheEntry *next;
} MapCacheEntry;
@@ -150,7 +152,8 @@ void xen_map_cache_init(phys_offset_to_gaddr_t f, void
*opaque)
static void xen_remap_bucket(MapCacheEntry *entry,
hwaddr size,
- hwaddr address_index)
+ hwaddr address_index,
+ bool dummy)
{
uint8_t *vaddr_base;
xen_pfn_t *pfns;
@@ -177,11 +180,25 @@ static void xen_remap_bucket(MapCacheEntry *entry,
pfns[i] = (address_index << (MCACHE_BUCKET_SHIFT-XC_PAGE_SHIFT)) + i;
}
-vaddr_base = xenforeignmemory_map(xen_fmem, xen_domid,
PROT_READ|PROT_WRITE,
- nb_pfn, pfns, err);
-if (vaddr_base == NULL) {
-perror("xenforeignmemory_map");
-exit(-1);
+if (!dummy) {
+vaddr_base = xenforeignmemory_map(xen_fmem, xen_domid,
+ PROT_READ | PROT_WRITE,
+ nb_pfn, pfns, err);
+if (vaddr_base == NULL) {
+perror("xenforeignmemory_map");
+exit(-1);
+}
+} else {
+/*
+ * We create dummy mappings where we are unable to create a foreign
+ * mapping immediately due to certain circumstances (i.e. on resume
now)
+ */
+vaddr_base = mmap(NULL, size, PROT_READ | PROT_WRITE,
+ MAP_ANON | MAP_SHARED, -1, 0);
+if (vaddr_base == NULL) {
+perror("mmap");
+exit(-1);
+}
}
entry->vaddr_base = vaddr_base;
@@ -190,6 +207,12 @@ static void xen_remap_bucket(MapCacheEntry *entry,
entry->valid_mapping = (unsigned long *) g_malloc0(sizeof(unsigned long) *
BITS_TO_LONGS(size >> XC_PAGE_SHIFT));
+if (dummy) {
+entry->flags |= XEN_MAPCACHE_ENTRY_DUMMY;
+} else {
+entry->flags &= ~(XEN_MAPCACHE_ENTRY_DUMMY);
+}
+
ram_block_notify_add(entry->vaddr_base, entry->size);
bitmap_zero(entry->valid_mapping, nb_pfn);
for (i = 0; i < nb_pfn; i++) {
@@ -211,6 +234,7 @@ static uint8_t *xen_map_cache_unlocked(hwaddr phys_addr,
hwaddr size,
hwaddr cache_size = size;
hwaddr test_bit_size;
bool translated = false;
+bool dummy = false;
tryagain:
address_index = phys_addr >> MCACHE_BUCKET_SHIFT;
@@ -262,14 +286,14 @@ tryagain:
if (!entry) {
entry = g_malloc0(sizeof (MapCacheEntry));
pentry->next = entry;
-xen_remap_bucket(entry, cache_size, address_index);
+xen_remap_bucket(entry, cache_size, address_index, dummy);
} else if (!entry->lock) {
if (!entry->vaddr_base || entry->paddr_index != address_index ||
entry->size != cache_size ||
!test_bits(address_offset >> XC_PAGE_SHIFT,
test_bit_size >> XC_PAGE_SHIFT,
entry->valid_mapping)) {
-xen_remap_bucket(entry, cache_size, address_index);
+xen_remap_bucket(entry, cache_size, address_index, dummy);
}
}
@@ -282,6 +306,10 @@ tryagain:
translated = true;
goto tryagain;
}
+if (!dummy && runstate_check(RUN_STATE_INMIGRATE)) {
+dummy = true;
+goto tryagain;
+}
trace_xen_map_cache_return(NULL);
return NULL;
}
--
2.7.4
Re: [Qemu-devel] [PATCH] test-i386: Make x86 test program compile on clang
I don’t believe so, I haven’t been able to find it in the bug database. ~Theodore > On Jul 10, 2017, at 2:48 PM, Paolo Bonzini wrote: > > On 10/07/2017 22:57, Theodore Dubois wrote: >> - Clang doesn't support size suffixes on the loop instructions. > > Has this bug been reported? > > Paolo >
Re: [Qemu-devel] [PATCH 21/22] tcg: enable per-thread TCG for softmmu
On Mon, Jul 10, 2017 at 17:33:07 -0400, Paolo Bonzini wrote: > > > I agree that it would be nice to have the same mechanism for all. > > > > The main hurdle I see is how to allow for concurrent code generation while > > minimizing flushes of the single, fixed-size[*] code_gen_buffer. > > In user-mode this is tricky because there is no way to bound the number > > of threads that might be spawned by the guest code (I don't think reading > > /proc/sys/kernel/threads-max is a viable solution here). > > > > Switching to a "__thread *tcg_ctx_ptr" model will help minimize > > user-mode/softmmu differences though. The only remaining difference would be > > that user-mode would need tb_lock() around tb_gen_code, whereas softmmu > > wouldn't, but everything else would be the same. > > Hmm, tb_gen_code is already protected by mmap_lock in linux-user, so you > wouldn't > get any parallelism. On the other hand, you could just say that the > fixed-size > code_gen_buffer is protected by mmap_lock, which doesn't exist for softmmu. Yes. tb_lock/mmap_lock, or like they're called in some asserts, memory_lock. A way to get some parallelism in user-mode given the constraints would be to share regions among TCG threads. Threads would still need to take a per-region lock, but it wouldn't be a global lock so that would scale better. I'm not sure we really need that much parallelism for code generation in user-mode, though. So I wouldn't focus on this until seeing benchmarks that have a clear bottleneck due to "memory_lock". E.
Re: [Qemu-devel] [PATCH v2 5/5] target/arm: use DISAS_EXIT for eret handling
On 10 July 2017 at 20:58, Richard Henderson wrote: > As an aside, I presume we don't have support for armv7ve? I was expecting > there to be an eret insn in the aa32 translator and had to dig up previous > manuals to see when that insn was introduced. We don't yet fully support 32-bit EL2, no. We've been adding bits and pieces but still haven't filled it all in. Edgar might have a patch to add ARM A32 ERET to the decoder in the xilinx tree? thanks -- PMM
Re: [Qemu-devel] [PATCH] test-i386: Make x86 test program compile on clang
On 10/07/2017 22:57, Theodore Dubois wrote: > - Clang doesn't support size suffixes on the loop instructions. Has this bug been reported? Paolo
Re: [Qemu-devel] [PATCH v4 06/17] dirty-bitmap: Change bdrv_dirty_bitmap_*serialize*() to take bytes
On 07/03/2017 11:10 AM, Eric Blake wrote: Right now, the dirty-bitmap code exposes the fact that we use a scale of sector granularity in the underlying hbitmap to anything that wants to serialize a dirty bitmap. It's nicer to uniformly expose bytes as our dirty-bitmap interface, matching the previous change to bitmap size. The only caller to serialization is currently qcow2-cluster.c, which becomes a bit more verbose because it is still tracking sectors for other reasons, but a later patch will fix that to more uniformly use byte offsets everywhere. Likewise, within dirty-bitmap, we have to add more assertions that we are not truncating incorrectly, which can go away once the internal hbitmap is byte-based rather than sector-based. Signed-off-by: Eric Blake Reviewed-by: John Snow
Re: [Qemu-devel] [PATCH 21/22] tcg: enable per-thread TCG for softmmu
> I agree that it would be nice to have the same mechanism for all. > > The main hurdle I see is how to allow for concurrent code generation while > minimizing flushes of the single, fixed-size[*] code_gen_buffer. > In user-mode this is tricky because there is no way to bound the number > of threads that might be spawned by the guest code (I don't think reading > /proc/sys/kernel/threads-max is a viable solution here). > > Switching to a "__thread *tcg_ctx_ptr" model will help minimize > user-mode/softmmu differences though. The only remaining difference would be > that user-mode would need tb_lock() around tb_gen_code, whereas softmmu > wouldn't, but everything else would be the same. Hmm, tb_gen_code is already protected by mmap_lock in linux-user, so you wouldn't get any parallelism. On the other hand, you could just say that the fixed-size code_gen_buffer is protected by mmap_lock, which doesn't exist for softmmu. Paolo
Re: [Qemu-devel] [PATCH v4 2/5] qapi: Add qobject_is_equal()
First of all, OK, you don't want QNum(42.0) to equal QNum(42) at all (at least not right now and in the foreseeable future). You're the maintainer, so you decide, so I'll go along with it. :-) Now, let's follow up with my therefore rather useless commentary: (Feel free to disregard, because honestly, I can see how replying to most of the points I'm asking isn't really worth the time...) On 2017-07-10 11:17, Markus Armbruster wrote: > Max Reitz writes: > >> On 2017-07-06 16:30, Markus Armbruster wrote: >>> Max Reitz writes: >>> This generic function (along with its implementations for different types) determines whether two QObjects are equal. Signed-off-by: Max Reitz --- Markus also proposed just reporting two values as unequal if they have a different internal representation (i.e. a different QNum kind). I don't like this very much, because I feel like QInt and QFloat have been unified for a reason: Outside of these classes, nobody should care about the exact internal representation. In JSON, there is no difference anyway. We probably want to use integers as long as we can and doubles whenever we cannot. >>> >>> You're right in that JSON has no notion of integer and floating-point, >>> only "number". RFC 4627 is famously useless[1] on what exactly a number >>> ought to be, and its successor RFC 7159 could then (due to wildly >>> varying existing practice) merely state that a number is what the >>> implementation makes it to be, and advises "good interoperability can be >>> achieved" by making it double". Pffft. >>> >>> For us, being able to represent 64 bit integers is more important than >>> interoperating with crappy JSON implementations, so we made it the union >>> of int64_t, uint64_t and double[2]. >>> >>> You make a fair point when you say that nothing outside QNum should care >>> about the exact internal representation. Trouble is that unless I'm >>> mistaken, your idea of "care" doesn't match the existing code's idea. >> >> I disagree that it doesn't match the existing code's idea. I think the >> existing code doesn't match its idea, but mine does. >> >>> Let i42 = qnum_from_int(42) >>> u42 = qnum_from_uint(42) >>> d42 = qnum_from_double(42) >>> >>> Then >>> >>> qnum_is_equal(i42, u42) yields true, I think. >>> qnum_is_equal(i42, d42) yields true, I think. >>> qnum_get_int(i42) yields 42. >>> qnum_get_int(u42) yields 42. >>> qnum_get_int(d42) fails its assertion. >>> >>> Failing an assertion qualifies as "care", doesn't it? >> >> It doesn't convert the value? That's definitely not what I would have >> thought and it doesn't make a lot of sense to me. I call that a bug. :-) > > It's the existing code's idea, going back all the way to the dawn of > QMP: integers and floating point numbers are distinct. > > Yes, they aren't distinct in the JSON grammar. So sue the designers of > QMP. Sounds like it was a reasonable idea at the time but could be done better today. But that's how it always is, right? > Yes, they are less distinct in QMP than say integers and strings, > because there's an automatic conversion from integer to floating point. > Doesn't make them non-distinct; there is no conversion from floating > point to integer. I can very well see that as a technical reason, but OK. > Yes, we recently changed the code to use the same C type for both. That > was done to keep the code simple, not to change the semantics of QMP. Hm, OK. >> From the other side we see that qnum_get_double() on all of this would >> yield 42.0 without failing. So why is it that qnum_get_int() doesn't? >> Because there are doubles you cannot reasonably convert to integers, I >> presume, whereas the other way around the worst that can happen is that >> you lose some precision. >> >> But that has no implication on qnum_is_equal(). If the double cannot be >> converted to an integer because it is out of bounds, the values just are >> not equal. Simple. >> >> So since qnum_get_double() does a conversion, I very much think that the >> reason qnum_get_int() doesn't is mostly "because sometimes it's not >> reasonably possible" and very much not because it is not intended to. > > It doesn't because the whole shebang is for QMP, and QMP does not ever > treat floating point numbers (numbers with decimal point or exponent) as > integers. Well, to my defense, I couldn't see that from looking at the code. From that point of view, it just looks like qnum_get_int() is lacking. > Yes, there are users other than QMP. They adopted it because it was > convenient. They thus adopted its oddities due to QMP's requirements, > too. To me, that mostly sounds like an excuse that distinguishing between integers and floats will not be wrong, but not like a reason it is right. In any case, I feel like the class should hide the different internal representations from the user. This necessitates being able to compare >
Re: [Qemu-devel] [PATCH v4 05/17] dirty-bitmap: Change bdrv_dirty_bitmap_size() to report bytes
On 07/10/2017 05:19 PM, Eric Blake wrote:
On 07/10/2017 04:09 PM, John Snow wrote:
On 07/03/2017 11:10 AM, Eric Blake wrote:
We are still using an internal hbitmap that tracks a size in sectors,
with the granularity scaled down accordingly, because it lets us
use a shortcut for our iterators which are currently sector-based.
But there's no reason we can't track the dirty bitmap size in bytes,
since it is (mostly) an internal-only variable (remember, the size
is how many bytes are covered by the bitmap, not how many bytes the
bitmap occupies). Furthermore, we're already reporting bytes for
bdrv_dirty_bitmap_granularity(); mixing bytes and sectors in our
return values is a recipe for confusion.
The only external caller in qcow2-bitmap.c is temporarily more verbose
(because it is still using sector-based math), but will later be
switched to track progress by bytes instead of sectors.
Use is_power_of_2() while at it, instead of open-coding that.
Signed-off-by: Eric Blake
@@ -305,8 +307,10 @@ BdrvDirtyBitmap
*bdrv_reclaim_dirty_bitmap(BlockDriverState *bs,
void bdrv_dirty_bitmap_truncate(BlockDriverState *bs)
{
BdrvDirtyBitmap *bitmap;
-uint64_t size = bdrv_nb_sectors(bs);
+int64_t size = bdrv_getlength(bs);
+assert(size >= 0);
+size = DIV_ROUND_UP(size, BDRV_SECTOR_SIZE);
Do we need a TODO here as well, or are we going to track these in terms
of "sectors" permanently?
The rounding goes away in patch 17/17 when I flip the internals to
byte-based. If a TODO comment here (that goes away in patch 17) makes
review easier, I can add that.
Email confirmation is enough for me, personally.
--js
Re: [Qemu-devel] [PATCH v4 05/17] dirty-bitmap: Change bdrv_dirty_bitmap_size() to report bytes
On 07/10/2017 04:09 PM, John Snow wrote:
>
>
> On 07/03/2017 11:10 AM, Eric Blake wrote:
>> We are still using an internal hbitmap that tracks a size in sectors,
>> with the granularity scaled down accordingly, because it lets us
>> use a shortcut for our iterators which are currently sector-based.
>> But there's no reason we can't track the dirty bitmap size in bytes,
>> since it is (mostly) an internal-only variable (remember, the size
>> is how many bytes are covered by the bitmap, not how many bytes the
>> bitmap occupies). Furthermore, we're already reporting bytes for
>> bdrv_dirty_bitmap_granularity(); mixing bytes and sectors in our
>> return values is a recipe for confusion.
>>
>> The only external caller in qcow2-bitmap.c is temporarily more verbose
>> (because it is still using sector-based math), but will later be
>> switched to track progress by bytes instead of sectors.
>>
>> Use is_power_of_2() while at it, instead of open-coding that.
>>
>> Signed-off-by: Eric Blake
>>
>> @@ -305,8 +307,10 @@ BdrvDirtyBitmap
>> *bdrv_reclaim_dirty_bitmap(BlockDriverState *bs,
>> void bdrv_dirty_bitmap_truncate(BlockDriverState *bs)
>> {
>> BdrvDirtyBitmap *bitmap;
>> -uint64_t size = bdrv_nb_sectors(bs);
>> +int64_t size = bdrv_getlength(bs);
>>
>> +assert(size >= 0);
>> +size = DIV_ROUND_UP(size, BDRV_SECTOR_SIZE);
>
> Do we need a TODO here as well, or are we going to track these in terms
> of "sectors" permanently?
The rounding goes away in patch 17/17 when I flip the internals to
byte-based. If a TODO comment here (that goes away in patch 17) makes
review easier, I can add that.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org
signature.asc
Description: OpenPGP digital signature
Re: [Qemu-devel] [PATCH 21/22] tcg: enable per-thread TCG for softmmu
On Mon, Jul 10, 2017 at 14:05:01 +0200, Paolo Bonzini wrote: > On 09/07/2017 09:50, Emilio G. Cota wrote: > > User-mode is kept out of this: contention due to concurrent translation > > is more commonly found in full-system mode. > > Out of curiosity, is it harder or you just didn't try? It would be nice > if the commit message mentioned the problems (if any) in addition to the > reason why you didn't do it. > > Having similar policies for user and softmmu emulation is much more > maintainable (for an earlier example, see the unification of user mode > emulation's start/end_exclusive logic with softmmu's "safe work"). I agree that it would be nice to have the same mechanism for all. The main hurdle I see is how to allow for concurrent code generation while minimizing flushes of the single, fixed-size[*] code_gen_buffer. In user-mode this is tricky because there is no way to bound the number of threads that might be spawned by the guest code (I don't think reading /proc/sys/kernel/threads-max is a viable solution here). Switching to a "__thread *tcg_ctx_ptr" model will help minimize user-mode/softmmu differences though. The only remaining difference would be that user-mode would need tb_lock() around tb_gen_code, whereas softmmu wouldn't, but everything else would be the same. E. [*] Note that in user-mode we use code_gen_buffer defined at compile-time as a static buffer[].
Re: [Qemu-devel] [PATCH v4 05/17] dirty-bitmap: Change bdrv_dirty_bitmap_size() to report bytes
On 07/03/2017 11:10 AM, Eric Blake wrote:
We are still using an internal hbitmap that tracks a size in sectors,
with the granularity scaled down accordingly, because it lets us
use a shortcut for our iterators which are currently sector-based.
But there's no reason we can't track the dirty bitmap size in bytes,
since it is (mostly) an internal-only variable (remember, the size
is how many bytes are covered by the bitmap, not how many bytes the
bitmap occupies). Furthermore, we're already reporting bytes for
bdrv_dirty_bitmap_granularity(); mixing bytes and sectors in our
return values is a recipe for confusion.
The only external caller in qcow2-bitmap.c is temporarily more verbose
(because it is still using sector-based math), but will later be
switched to track progress by bytes instead of sectors.
Use is_power_of_2() while at it, instead of open-coding that.
Signed-off-by: Eric Blake
---
v4: retitle from "Track size in bytes", rebase to persistent bitmaps,
round up when converting bytes to sectors
v3: no change
v2: tweak commit message, no code change
---
block/dirty-bitmap.c | 25 +++--
block/qcow2-bitmap.c | 14 --
2 files changed, 23 insertions(+), 16 deletions(-)
diff --git a/block/dirty-bitmap.c b/block/dirty-bitmap.c
index 42a55e4..3d8cfe6 100644
--- a/block/dirty-bitmap.c
+++ b/block/dirty-bitmap.c
@@ -1,7 +1,7 @@
/*
* Block Dirty Bitmap
*
- * Copyright (c) 2016 Red Hat. Inc
+ * Copyright (c) 2016-2017 Red Hat. Inc
*
* Permission is hereby granted, free of charge, to any person obtaining a
copy
* of this software and associated documentation files (the "Software"), to
deal
@@ -42,7 +42,7 @@ struct BdrvDirtyBitmap {
HBitmap *meta; /* Meta dirty bitmap */
BdrvDirtyBitmap *successor; /* Anonymous child; implies frozen status */
char *name; /* Optional non-empty unique ID */
-int64_t size; /* Size of the bitmap (Number of sectors) */
+int64_t size; /* Size of the bitmap, in bytes */
bool disabled; /* Bitmap is disabled. It ignores all writes
to
the device */
int active_iterators; /* How many iterators are active */
@@ -115,17 +115,14 @@ BdrvDirtyBitmap
*bdrv_create_dirty_bitmap(BlockDriverState *bs,
{
int64_t bitmap_size;
BdrvDirtyBitmap *bitmap;
-uint32_t sector_granularity;
-assert((granularity & (granularity - 1)) == 0);
+assert(is_power_of_2(granularity) && granularity >= BDRV_SECTOR_SIZE);
if (name && bdrv_find_dirty_bitmap(bs, name)) {
error_setg(errp, "Bitmap already exists: %s", name);
return NULL;
}
-sector_granularity = granularity >> BDRV_SECTOR_BITS;
-assert(sector_granularity);
-bitmap_size = bdrv_nb_sectors(bs);
+bitmap_size = bdrv_getlength(bs);
if (bitmap_size < 0) {
error_setg_errno(errp, -bitmap_size, "could not get length of
device");
errno = -bitmap_size;
@@ -133,7 +130,12 @@ BdrvDirtyBitmap *bdrv_create_dirty_bitmap(BlockDriverState
*bs,
}
bitmap = g_new0(BdrvDirtyBitmap, 1);
bitmap->mutex = &bs->dirty_bitmap_mutex;
-bitmap->bitmap = hbitmap_alloc(bitmap_size, ctz32(sector_granularity));
+/*
+ * TODO - let hbitmap track full granularity. For now, it is tracking
+ * only sector granularity, as a shortcut for our iterators.
+ */
+bitmap->bitmap = hbitmap_alloc(DIV_ROUND_UP(bitmap_size, BDRV_SECTOR_SIZE),
+ ctz32(granularity) - BDRV_SECTOR_BITS);
bitmap->size = bitmap_size;
bitmap->name = g_strdup(name);
bitmap->disabled = false;
@@ -305,8 +307,10 @@ BdrvDirtyBitmap
*bdrv_reclaim_dirty_bitmap(BlockDriverState *bs,
void bdrv_dirty_bitmap_truncate(BlockDriverState *bs)
{
BdrvDirtyBitmap *bitmap;
-uint64_t size = bdrv_nb_sectors(bs);
+int64_t size = bdrv_getlength(bs);
+assert(size >= 0);
+size = DIV_ROUND_UP(size, BDRV_SECTOR_SIZE);
Do we need a TODO here as well, or are we going to track these in terms
of "sectors" permanently?
bdrv_dirty_bitmaps_lock(bs);
QLIST_FOREACH(bitmap, &bs->dirty_bitmaps, list) {
assert(!bdrv_dirty_bitmap_frozen(bitmap));
@@ -549,7 +553,8 @@ void bdrv_clear_dirty_bitmap(BdrvDirtyBitmap *bitmap,
HBitmap **out)
hbitmap_reset_all(bitmap->bitmap);
} else {
HBitmap *backup = bitmap->bitmap;
-bitmap->bitmap = hbitmap_alloc(bitmap->size,
+bitmap->bitmap = hbitmap_alloc(DIV_ROUND_UP(bitmap->size,
+BDRV_SECTOR_SIZE),
hbitmap_granularity(backup));
*out = backup;
}
diff --git a/block/qcow2-bitmap.c b/block/qcow2-bitmap.c
index 75ee238..f6f7770 100644
--- a/block/qcow2-bitmap.c
+++ b/block/qcow2-bitmap.c
@@ -295,10 +295,11 @@ static int load_bitmap_data(Bloc
Re: [Qemu-devel] [PATCH v7 06/16] qapi: add dirty-bitmaps migration capability
On 07/10/2017 11:30 AM, Vladimir Sementsov-Ogievskiy wrote:
> Signed-off-by: Vladimir Sementsov-Ogievskiy
> Reviewed-by: John Snow
> Reviewed-by: Eric Blake
> Reviewed-by: Juan Quintela
> ---
> migration/migration.c | 9 +
> migration/migration.h | 1 +
> qapi-schema.json | 4 +++-
> 3 files changed, 13 insertions(+), 1 deletion(-)
>
> +++ b/qapi-schema.json
> @@ -903,12 +903,14 @@
> # @return-path: If enabled, migration will use the return path even
> # for precopy. (since 2.10)
> #
> +# @dirty-bitmaps: If enabled, QEMU will migrate named dirty bitmaps. (since
> 2.9)
We've missed 2.9; this should be 2.10.
> +#
> # Since: 1.2
> ##
> { 'enum': 'MigrationCapability',
>'data': ['xbzrle', 'rdma-pin-all', 'auto-converge', 'zero-blocks',
> 'compress', 'events', 'postcopy-ram', 'x-colo', 'release-ram',
> - 'block', 'return-path' ] }
> + 'block', 'return-path', 'dirty-bitmaps' ] }
>
> ##
> # @MigrationCapabilityStatus:
>
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org
signature.asc
Description: OpenPGP digital signature
Re: [Qemu-devel] [RFC PATCH 03/26] target/ppc/POWER9: add POWERPC_EXCP_POWER9
On Mon, 2017-07-10 at 14:49 +0200, Cédric Le Goater wrote:
> On 07/10/2017 12:26 PM, David Gibson wrote:
> > On Wed, Jul 05, 2017 at 07:13:16PM +0200, Cédric Le Goater wrote:
> > > Prepare ground for the new exception model XIVE of POWER9.
> >
> > I'm a bit confused by this. The excp_model is about the CPU core's
> > irq model, not the external irq controller's.
>
> yes this is true, but the POWER9 CPU is the only criteria we have
> to distinguish a machine supporting XIVE and XICS from one only
> supporting XICS.
Why ? I don't understand.
We do want an EXCP_POWER9 for other things, like the fact that we have
a separate interrupt input for hypervisor, with associated vectors
etc... but that still doesn't relate to what interrupt controller is
there.
> My idea was to use this flag to activate the OV5_XIVE_EXPLOIT bit
> in ibm,arch-vec-5-platform-support ov5_platform, like this is done
> for the MMU. See spapr_dt_ov5_platform_support()
I disagree, the MMU is in the core, the XIVE isn't. It would be
possibly to make a P9 core if a XICS in theory :-)
> > Now.. I could imagine the POWER9 having a different core model that
> > came along with XIVE, but I can't see this new model being used for
> > anything anywhere in the rest of the series.
>
> See patch 26. But, maybe, I am taking a shortcut and we need another
> family of flags.
Or just some kind of enum for the interrupt controller, how do we do
with OpenPIC vs. XICS already ? Old POWER3 had OpenPIC.
> Thanks,
>
> C.
>
> > >
> > > Signed-off-by: Cédric Le Goater
> > > ---
> > > target/ppc/cpu-qom.h| 2 ++
> > > target/ppc/excp_helper.c| 9 ++---
> > > target/ppc/translate.c | 3 ++-
> > > target/ppc/translate_init.c | 2 +-
> > > 4 files changed, 11 insertions(+), 5 deletions(-)
> > >
> > > diff --git a/target/ppc/cpu-qom.h b/target/ppc/cpu-qom.h
> > > index d0cf6ca2a971..d7b78cf3f71c 100644
> > > --- a/target/ppc/cpu-qom.h
> > > +++ b/target/ppc/cpu-qom.h
> > > @@ -132,6 +132,8 @@ enum powerpc_excp_t {
> > > POWERPC_EXCP_POWER7,
> > > /* POWER8 exception model */
> > > POWERPC_EXCP_POWER8,
> > > +/* POWER9 exception model */
> > > +POWERPC_EXCP_POWER9,
> > > };
> > >
> > >
> > > /*/
> > > diff --git a/target/ppc/excp_helper.c b/target/ppc/excp_helper.c
> > > index 3a9f0861e773..dc7dff36a580 100644
> > > --- a/target/ppc/excp_helper.c
> > > +++ b/target/ppc/excp_helper.c
> > > @@ -148,9 +148,11 @@ static inline void powerpc_excp(PowerPCCPU *cpu, int
> > > excp_model, int excp)
> > > */
> > > #if defined(TARGET_PPC64)
> > > if (excp_model == POWERPC_EXCP_POWER7 ||
> > > -excp_model == POWERPC_EXCP_POWER8) {
> > > +excp_model == POWERPC_EXCP_POWER8 ||
> > > +excp_model == POWERPC_EXCP_POWER9) {
> > > lpes0 = !!(env->spr[SPR_LPCR] & LPCR_LPES0);
> > > -if (excp_model == POWERPC_EXCP_POWER8) {
> > > +if (excp_model == POWERPC_EXCP_POWER8 ||
> > > +excp_model == POWERPC_EXCP_POWER9) {
> > > ail = (env->spr[SPR_LPCR] & LPCR_AIL) >> LPCR_AIL_SHIFT;
> > > } else {
> > > ail = 0;
> > > @@ -651,7 +653,8 @@ static inline void powerpc_excp(PowerPCCPU *cpu, int
> > > excp_model, int excp)
> > > if (!(new_msr & MSR_HVB) && (env->spr[SPR_LPCR] & LPCR_ILE)) {
> > > new_msr |= (target_ulong)1 << MSR_LE;
> > > }
> > > -} else if (excp_model == POWERPC_EXCP_POWER8) {
> > > +} else if (excp_model == POWERPC_EXCP_POWER8 ||
> > > + excp_model == POWERPC_EXCP_POWER9) {
> > > if (new_msr & MSR_HVB) {
> > > if (env->spr[SPR_HID0] & HID0_HILE) {
> > > new_msr |= (target_ulong)1 << MSR_LE;
> > > diff --git a/target/ppc/translate.c b/target/ppc/translate.c
> > > index c0cd64d927c2..2d8c1b9e6836 100644
> > > --- a/target/ppc/translate.c
> > > +++ b/target/ppc/translate.c
> > > @@ -7064,7 +7064,8 @@ void ppc_cpu_dump_state(CPUState *cs, FILE *f,
> > > fprintf_function cpu_fprintf,
> > >
> > > #if defined(TARGET_PPC64)
> > > if (env->excp_model == POWERPC_EXCP_POWER7 ||
> > > -env->excp_model == POWERPC_EXCP_POWER8) {
> > > +env->excp_model == POWERPC_EXCP_POWER8 ||
> > > +env->excp_model == POWERPC_EXCP_POWER9) {
> > > cpu_fprintf(f, "HSRR0 " TARGET_FMT_lx " HSRR1 " TARGET_FMT_lx
> > > "\n",
> > > env->spr[SPR_HSRR0], env->spr[SPR_HSRR1]);
> > > }
> > > diff --git a/target/ppc/translate_init.c b/target/ppc/translate_init.c
> > > index 53aff5a7b734..b8c7b8150318 100644
> > > --- a/target/ppc/translate_init.c
> > > +++ b/target/ppc/translate_init.c
> > > @@ -8962,7 +8962,7 @@ POWERPC_FAMILY(POWER9)(ObjectClass *oc, void *data)
> > > pcc->sps = &POWER7_POWER8_sps;
> > > pcc->radix_page_info = &POWER9_radix_page_info;
> > > #endif
> > > -pcc->exc
[Qemu-devel] [PATCH] test-i386: Make x86 test program compile on clang
Clang's assembler is slightly incompatible with GCC's assembler, which
caused the program to not compile on Clang for these reasons:
- The "q" constraint was specified for an argument to the set
instruction, which didn't work because Clang chose the esi register,
which has no 8-bit form on i386.
- Clang doesn't support size suffixes on the loop instructions.
- Clang requires a size suffix on the fist instruction.
- Clang doesn't support specifying segment prefixes before the
instruction, and requires specifying them on the address.
- The arguments to the bound instruction are in the wrong order on
Clang. https://bugs.llvm.org/show_bug.cgi?id=27653
Signed-off-by: Theodore Dubois
---
tests/tcg/test-i386.c | 20
1 file changed, 16 insertions(+), 4 deletions(-)
diff --git a/tests/tcg/test-i386.c b/tests/tcg/test-i386.c
index 0f7b943b0c..dcb8e4876e 100644
--- a/tests/tcg/test-i386.c
+++ b/tests/tcg/test-i386.c
@@ -369,7 +369,7 @@ void test_lea(void)
asm("movl $0, %0\n\t"\
"cmpl %2, %1\n\t"\
"set" JCC " %b0\n\t"\
-: "=r" (res)\
+: "=q" (res)\
: "r" (v1), "r" (v2));\
printf("%-10s %d\n", "set" JCC, res);\
if (TEST_CMOV) {\
@@ -491,15 +491,23 @@ void test_loop(void)
#if !defined(__x86_64__)
TEST_LOOP("jcxz");
+#if !defined(__clang__)
TEST_LOOP("loopw");
TEST_LOOP("loopzw");
TEST_LOOP("loopnzw");
#endif
+#endif
TEST_LOOP("jecxz");
+#if !defined(__clang__)
TEST_LOOP("loopl");
TEST_LOOP("loopzl");
TEST_LOOP("loopnzl");
+#else
+TEST_LOOP("loop");
+TEST_LOOP("loopz");
+TEST_LOOP("loopnz");
+#endif
}
#undef CC_MASK
@@ -867,7 +875,7 @@ void test_fcvt(double a)
uint16_t val16;
val16 = (fpuc & ~0x0c00) | (i << 10);
asm volatile ("fldcw %0" : : "m" (val16));
-asm volatile ("fist %0" : "=m" (wa) : "t" (a));
+asm volatile ("fists %0" : "=m" (wa) : "t" (a));
asm volatile ("fistl %0" : "=m" (ia) : "t" (a));
asm volatile ("fistpll %0" : "=m" (lla) : "t" (a) : "st");
asm volatile ("frndint ; fstl %0" : "=m" (ra) : "t" (a));
@@ -1318,12 +1326,12 @@ void test_segs(void)
seg_data1[1] = 0xaa;
seg_data2[1] = 0x55;
-asm volatile ("fs movzbl 0x1, %0" : "=r" (res));
+asm volatile ("movzbl %%fs:0x1, %0" : "=r" (res));
printf("FS[1] = %02x\n", res);
asm volatile ("pushl %%gs\n"
"movl %1, %%gs\n"
- "gs movzbl 0x1, %0\n"
+ "movzbl %%gs:0x1, %0\n"
"popl %%gs\n"
: "=r" (res)
: "r" (MK_SEL(2)));
@@ -1764,7 +1772,11 @@ void test_exceptions(void)
/* bound exception */
tab[0] = 1;
tab[1] = 10;
+#if defined(__clang__)
+asm volatile ("bound %1, %0" : : "r" (11), "m" (tab[0]));
+#else
asm volatile ("bound %0, %1" : : "r" (11), "m" (tab[0]));
+#endif
}
#endif
--
2.13.2
~Theodore
[Qemu-devel] [PATCH v3 8/8] target/s390x: Fix risbg handling
The rotation is to the left, but extract shifts to the right.
The computation of the extract parameters needs adjusting.
For the entry condition, simplify
64 - rot + len <= 64
-rot + len <= 0
len <= rot
Reviewed-by: Aurelien Jarno
Reported-by: David Hildenbrand
Suggested-by: Aurelien Jarno
Signed-off-by: Richard Henderson
---
target/s390x/translate.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/target/s390x/translate.c b/target/s390x/translate.c
index f94ba7c..0c609bd 100644
--- a/target/s390x/translate.c
+++ b/target/s390x/translate.c
@@ -3471,8 +3471,8 @@ static ExitStatus op_risbg(DisasContext *s, DisasOps *o)
}
/* In some cases we can implement this with extract. */
-if (imask == 0 && pos == 0 && len > 0 && rot + len <= 64) {
-tcg_gen_extract_i64(o->out, o->in2, rot, len);
+if (imask == 0 && pos == 0 && len > 0 && len <= rot) {
+tcg_gen_extract_i64(o->out, o->in2, 64 - rot, len);
return NO_EXIT;
}
--
2.9.4
[Qemu-devel] [PATCH v3 5/8] target/s390x: Implement TRTR
Drop TRT from the set of insns handled internally by EXECUTE.
It's more important to adjust the existing helper to handle
both TRT and TRTR.
Reviewed-by: Aurelien Jarno
Signed-off-by: Richard Henderson
---
target/s390x/helper.h | 1 +
target/s390x/mem_helper.c | 20 +---
target/s390x/translate.c | 9 +
target/s390x/insn-data.def | 2 ++
4 files changed, 25 insertions(+), 7 deletions(-)
diff --git a/target/s390x/helper.h b/target/s390x/helper.h
index 32314e0..4b02907 100644
--- a/target/s390x/helper.h
+++ b/target/s390x/helper.h
@@ -97,6 +97,7 @@ DEF_HELPER_FLAGS_3(tp, TCG_CALL_NO_WG, i32, env, i64, i32)
DEF_HELPER_FLAGS_4(tr, TCG_CALL_NO_WG, void, env, i32, i64, i64)
DEF_HELPER_4(tre, i64, env, i64, i64, i64)
DEF_HELPER_4(trt, i32, env, i32, i64, i64)
+DEF_HELPER_4(trtr, i32, env, i32, i64, i64)
DEF_HELPER_5(trXX, i32, env, i32, i32, i32, i32)
DEF_HELPER_4(cksm, i64, env, i64, i64, i64)
DEF_HELPER_FLAGS_5(calc_cc, TCG_CALL_NO_RWG_SE, i32, env, i32, i64, i64, i64)
diff --git a/target/s390x/mem_helper.c b/target/s390x/mem_helper.c
index e3db68d..b9d0477 100644
--- a/target/s390x/mem_helper.c
+++ b/target/s390x/mem_helper.c
@@ -1277,17 +1277,18 @@ uint64_t HELPER(tre)(CPUS390XState *env, uint64_t array,
return array + i;
}
-static uint32_t do_helper_trt(CPUS390XState *env, uint32_t len, uint64_t array,
- uint64_t trans, uintptr_t ra)
+static inline uint32_t do_helper_trt(CPUS390XState *env, int len,
+ uint64_t array, uint64_t trans,
+ int inc, uintptr_t ra)
{
-uint32_t i;
+int i;
for (i = 0; i <= len; i++) {
-uint8_t byte = cpu_ldub_data_ra(env, array + i, ra);
+uint8_t byte = cpu_ldub_data_ra(env, array + i * inc, ra);
uint8_t sbyte = cpu_ldub_data_ra(env, trans + byte, ra);
if (sbyte != 0) {
-set_address(env, 1, array + i);
+set_address(env, 1, array + i * inc);
env->regs[2] = deposit64(env->regs[2], 0, 8, sbyte);
return (i == len) ? 2 : 1;
}
@@ -1299,7 +1300,13 @@ static uint32_t do_helper_trt(CPUS390XState *env,
uint32_t len, uint64_t array,
uint32_t HELPER(trt)(CPUS390XState *env, uint32_t len, uint64_t array,
uint64_t trans)
{
-return do_helper_trt(env, len, array, trans, GETPC());
+return do_helper_trt(env, len, array, trans, 1, GETPC());
+}
+
+uint32_t HELPER(trtr)(CPUS390XState *env, uint32_t len, uint64_t array,
+ uint64_t trans)
+{
+return do_helper_trt(env, len, array, trans, -1, GETPC());
}
/* Translate one/two to one/two */
@@ -2119,7 +2126,6 @@ void HELPER(ex)(CPUS390XState *env, uint32_t ilen,
uint64_t r1, uint64_t addr)
[0x6] = do_helper_oc,
[0x7] = do_helper_xc,
[0xc] = do_helper_tr,
-[0xd] = do_helper_trt,
};
dx_helper helper = dx[opc & 0xf];
diff --git a/target/s390x/translate.c b/target/s390x/translate.c
index 57e6909..f94ba7c 100644
--- a/target/s390x/translate.c
+++ b/target/s390x/translate.c
@@ -4439,6 +4439,15 @@ static ExitStatus op_trt(DisasContext *s, DisasOps *o)
return NO_EXIT;
}
+static ExitStatus op_trtr(DisasContext *s, DisasOps *o)
+{
+TCGv_i32 l = tcg_const_i32(get_field(s->fields, l1));
+gen_helper_trtr(cc_op, cpu_env, l, o->addr1, o->in2);
+tcg_temp_free_i32(l);
+set_cc_static(s);
+return NO_EXIT;
+}
+
static ExitStatus op_trXX(DisasContext *s, DisasOps *o)
{
TCGv_i32 r1 = tcg_const_i32(get_field(s->fields, r1));
diff --git a/target/s390x/insn-data.def b/target/s390x/insn-data.def
index 1d34df03..ad84c74 100644
--- a/target/s390x/insn-data.def
+++ b/target/s390x/insn-data.def
@@ -916,6 +916,8 @@
C(0xdc00, TR, SS_a, Z, la1, a2, 0, 0, tr, 0)
/* TRANSLATE AND TEST */
C(0xdd00, TRT, SS_a, Z, la1, a2, 0, 0, trt, 0)
+/* TRANSLATE AND TEST REVERSE */
+C(0xd000, TRTR,SS_a, ETF3, la1, a2, 0, 0, trtr, 0)
/* TRANSLATE EXTENDED */
C(0xb2a5, TRE, RRE, Z, 0, r2, r1_P, 0, tre, 0)
--
2.9.4
[Qemu-devel] [PATCH v3 4/8] target/s390x: Implement SRSTU
Reviewed-by: Aurelien Jarno
Signed-off-by: Richard Henderson
---
target/s390x/helper.h | 1 +
target/s390x/mem_helper.c | 41 +
target/s390x/translate.c | 13 +
target/s390x/insn-data.def | 2 ++
4 files changed, 57 insertions(+)
diff --git a/target/s390x/helper.h b/target/s390x/helper.h
index a2e5b9b..32314e0 100644
--- a/target/s390x/helper.h
+++ b/target/s390x/helper.h
@@ -13,6 +13,7 @@ DEF_HELPER_FLAGS_3(divu32, TCG_CALL_NO_WG, i64, env, i64, i64)
DEF_HELPER_FLAGS_3(divs64, TCG_CALL_NO_WG, s64, env, s64, s64)
DEF_HELPER_FLAGS_4(divu64, TCG_CALL_NO_WG, i64, env, i64, i64, i64)
DEF_HELPER_3(srst, void, env, i32, i32)
+DEF_HELPER_3(srstu, void, env, i32, i32)
DEF_HELPER_4(clst, i64, env, i64, i64, i64)
DEF_HELPER_FLAGS_4(mvn, TCG_CALL_NO_WG, void, env, i32, i64, i64)
DEF_HELPER_FLAGS_4(mvo, TCG_CALL_NO_WG, void, env, i32, i64, i64)
diff --git a/target/s390x/mem_helper.c b/target/s390x/mem_helper.c
index 74b48aa..e3db68d 100644
--- a/target/s390x/mem_helper.c
+++ b/target/s390x/mem_helper.c
@@ -576,6 +576,47 @@ void HELPER(srst)(CPUS390XState *env, uint32_t r1,
uint32_t r2)
set_address(env, r2, str + len);
}
+void HELPER(srstu)(CPUS390XState *env, uint32_t r1, uint32_t r2)
+{
+uintptr_t ra = GETPC();
+uint32_t len;
+uint16_t v, c = env->regs[0];
+uint64_t end, str, adj_end;
+
+/* Bits 32-47 of R0 must be zero. */
+if (env->regs[0] & 0xu) {
+cpu_restore_state(ENV_GET_CPU(env), ra);
+program_interrupt(env, PGM_SPECIFICATION, 6);
+}
+
+str = get_address(env, r2);
+end = get_address(env, r1);
+
+/* If the LSB of the two addresses differ, use one extra byte. */
+adj_end = end + ((str ^ end) & 1);
+
+/* Lest we fail to service interrupts in a timely manner, limit the
+ amount of work we're willing to do. For now, let's cap at 8k. */
+for (len = 0; len < 0x2000; len += 2) {
+if (str + len == adj_end) {
+/* End of input found. */
+env->cc_op = 2;
+return;
+}
+v = cpu_lduw_data_ra(env, str + len, ra);
+if (v == c) {
+/* Character found. Set R1 to the location; R2 is unmodified. */
+env->cc_op = 1;
+set_address(env, r1, str + len);
+return;
+}
+}
+
+/* CPU-determined bytes processed. Advance R2 to next byte to process. */
+env->cc_op = 3;
+set_address(env, r2, str + len);
+}
+
/* unsigned string compare (c is string terminator) */
uint64_t HELPER(clst)(CPUS390XState *env, uint64_t c, uint64_t s1, uint64_t s2)
{
diff --git a/target/s390x/translate.c b/target/s390x/translate.c
index ba22e3d..57e6909 100644
--- a/target/s390x/translate.c
+++ b/target/s390x/translate.c
@@ -4290,6 +4290,19 @@ static ExitStatus op_srst(DisasContext *s, DisasOps *o)
return NO_EXIT;
}
+static ExitStatus op_srstu(DisasContext *s, DisasOps *o)
+{
+TCGv_i32 r1 = tcg_const_i32(get_field(s->fields, r1));
+TCGv_i32 r2 = tcg_const_i32(get_field(s->fields, r2));
+
+gen_helper_srstu(cpu_env, r1, r2);
+
+tcg_temp_free_i32(r1);
+tcg_temp_free_i32(r2);
+set_cc_static(s);
+return NO_EXIT;
+}
+
static ExitStatus op_sub(DisasContext *s, DisasOps *o)
{
tcg_gen_sub_i64(o->out, o->in1, o->in2);
diff --git a/target/s390x/insn-data.def b/target/s390x/insn-data.def
index bc6ff01..1d34df03 100644
--- a/target/s390x/insn-data.def
+++ b/target/s390x/insn-data.def
@@ -737,6 +737,8 @@
/* SEARCH STRING */
C(0xb25e, SRST,RRE, Z, 0, 0, 0, 0, srst, 0)
+/* SEARCH STRING UNICODE */
+C(0xb9be, SRSTU, RRE, ETF3, 0, 0, 0, 0, srstu, 0)
/* SET ACCESS */
C(0xb24e, SAR, RRE, Z, 0, r2_o, 0, 0, sar, 0)
--
2.9.4
[Qemu-devel] [PATCH v3 0/8] target/s390x tcg improvements
Changes since v2: * Another error in CONVERT UNICODE Changes since v1: * Errors corrected in CONVERT UNICODE * Address writeback corrected in SRST/SRSTU * IDTES feature added. * RISBG handling fixed. r~ David Hildenbrand (1): target/s390x: Allow to enable "idtes" feature for TCG Richard Henderson (7): target/s390x: Implement CSST target/s390x: Implement CONVERT UNICODE insns target/s390x: Tidy SRST target/s390x: Implement SRSTU target/s390x: Implement TRTR target/s390x: Mark ETF3 and ETF3_ENH facilities as available target/s390x: Fix risbg handling target/s390x/helper.h | 11 +- target/s390x/cpu_models.c | 5 + target/s390x/mem_helper.c | 585 +++-- target/s390x/translate.c | 91 ++- target/s390x/insn-data.def | 21 +- 5 files changed, 688 insertions(+), 25 deletions(-) -- 2.9.4
[Qemu-devel] [PATCH v3 3/8] target/s390x: Tidy SRST
Since we require all registers saved on input, read R0 from ENV instead
of passing it manually. Recognize the specification exception when R0
contains incorrect data. Keep high bits of result registers unmodified
when in 31 or 24-bit mode.
Reviewed-by: Aurelien Jarno
Signed-off-by: Richard Henderson
---
target/s390x/helper.h | 2 +-
target/s390x/mem_helper.c | 25 ++---
target/s390x/translate.c | 9 +++--
target/s390x/insn-data.def | 2 +-
4 files changed, 23 insertions(+), 15 deletions(-)
diff --git a/target/s390x/helper.h b/target/s390x/helper.h
index 2793cf3..a2e5b9b 100644
--- a/target/s390x/helper.h
+++ b/target/s390x/helper.h
@@ -12,7 +12,7 @@ DEF_HELPER_FLAGS_3(divs32, TCG_CALL_NO_WG, s64, env, s64, s64)
DEF_HELPER_FLAGS_3(divu32, TCG_CALL_NO_WG, i64, env, i64, i64)
DEF_HELPER_FLAGS_3(divs64, TCG_CALL_NO_WG, s64, env, s64, s64)
DEF_HELPER_FLAGS_4(divu64, TCG_CALL_NO_WG, i64, env, i64, i64, i64)
-DEF_HELPER_4(srst, i64, env, i64, i64, i64)
+DEF_HELPER_3(srst, void, env, i32, i32)
DEF_HELPER_4(clst, i64, env, i64, i64, i64)
DEF_HELPER_FLAGS_4(mvn, TCG_CALL_NO_WG, void, env, i32, i64, i64)
DEF_HELPER_FLAGS_4(mvo, TCG_CALL_NO_WG, void, env, i32, i64, i64)
diff --git a/target/s390x/mem_helper.c b/target/s390x/mem_helper.c
index 0b18560..74b48aa 100644
--- a/target/s390x/mem_helper.c
+++ b/target/s390x/mem_helper.c
@@ -538,18 +538,21 @@ static inline void set_length(CPUS390XState *env, int
reg, uint64_t length)
}
/* search string (c is byte to search, r2 is string, r1 end of string) */
-uint64_t HELPER(srst)(CPUS390XState *env, uint64_t r0, uint64_t end,
- uint64_t str)
+void HELPER(srst)(CPUS390XState *env, uint32_t r1, uint32_t r2)
{
uintptr_t ra = GETPC();
+uint64_t end, str;
uint32_t len;
-uint8_t v, c = r0;
+uint8_t v, c = env->regs[0];
-str = wrap_address(env, str);
-end = wrap_address(env, end);
+/* Bits 32-55 must contain all 0. */
+if (env->regs[0] & 0xff00u) {
+cpu_restore_state(ENV_GET_CPU(env), ra);
+program_interrupt(env, PGM_SPECIFICATION, 6);
+}
-/* Assume for now that R2 is unmodified. */
-env->retxl = str;
+str = get_address(env, r2);
+end = get_address(env, r1);
/* Lest we fail to service interrupts in a timely manner, limit the
amount of work we're willing to do. For now, let's cap at 8k. */
@@ -557,20 +560,20 @@ uint64_t HELPER(srst)(CPUS390XState *env, uint64_t r0,
uint64_t end,
if (str + len == end) {
/* Character not found. R1 & R2 are unmodified. */
env->cc_op = 2;
-return end;
+return;
}
v = cpu_ldub_data_ra(env, str + len, ra);
if (v == c) {
/* Character found. Set R1 to the location; R2 is unmodified. */
env->cc_op = 1;
-return str + len;
+set_address(env, r1, str + len);
+return;
}
}
/* CPU-determined bytes processed. Advance R2 to next byte to process. */
-env->retxl = str + len;
env->cc_op = 3;
-return end;
+set_address(env, r2, str + len);
}
/* unsigned string compare (c is string terminator) */
diff --git a/target/s390x/translate.c b/target/s390x/translate.c
index 339b31e..ba22e3d 100644
--- a/target/s390x/translate.c
+++ b/target/s390x/translate.c
@@ -4279,9 +4279,14 @@ static ExitStatus op_stpq(DisasContext *s, DisasOps *o)
static ExitStatus op_srst(DisasContext *s, DisasOps *o)
{
-gen_helper_srst(o->in1, cpu_env, regs[0], o->in1, o->in2);
+TCGv_i32 r1 = tcg_const_i32(get_field(s->fields, r1));
+TCGv_i32 r2 = tcg_const_i32(get_field(s->fields, r2));
+
+gen_helper_srst(cpu_env, r1, r2);
+
+tcg_temp_free_i32(r1);
+tcg_temp_free_i32(r2);
set_cc_static(s);
-return_low128(o->in2);
return NO_EXIT;
}
diff --git a/target/s390x/insn-data.def b/target/s390x/insn-data.def
index 323a301..bc6ff01 100644
--- a/target/s390x/insn-data.def
+++ b/target/s390x/insn-data.def
@@ -736,7 +736,7 @@
C(0xec57, RXSBG, RIE_f, GIE, 0, r2, r1, 0, rosbg, 0)
/* SEARCH STRING */
-C(0xb25e, SRST,RRE, Z, r1_o, r2_o, 0, 0, srst, 0)
+C(0xb25e, SRST,RRE, Z, 0, 0, 0, 0, srst, 0)
/* SET ACCESS */
C(0xb24e, SAR, RRE, Z, 0, r2_o, 0, 0, sar, 0)
--
2.9.4
