Re: [PATCH for 8.0 0/2] virtio-iommu: Fix Replay
Hi Peter, On 12/8/22 00:49, Peter Xu wrote: > Hi, Eric, > > On Wed, Dec 07, 2022 at 02:36:44PM +0100, Eric Auger wrote: >> When assigning VFIO devices protected by a virtio-iommu we need to replay >> the mappings when adding a new IOMMU MR and when attaching a device to >> a domain. While we do a "remap" we currently fail to first unmap the >> existing IOVA mapping and just map the new one. With some device/group >> topology this can lead to errors in VFIO when trying to DMA_MAP IOVA >> ranges onto existing ones. > I'm not sure whether virtio-iommu+vfio will suffer from DMA races like when > we were working on the vt-d replay for vfio. The issue is whether DMA can > happen right after UNMAP but before MAP of the same page if the page was > always mapped. I don't think it can race because a mutex is hold while doing the virtio_iommu_replay(), and each time a virtio cmd is handled (attach, map, unmap), see virtio_iommu_handle_command. So I think it is safe. Thanks Eric > > The vt-d resolved it by using iova_tree so in a replay vt-d knows the page > didn't change, so it avoids unmap+map. It only notifies newly unmapped or > newly mapped. > > Thanks, >
Re: [PATCH] FreeBSD: Upgrade to 12.4 release
On 8/12/22 07:52, Brad Smith wrote: FreeBSD: Upgrade to 12.4 release Signed-off-by: Brad Smith --- .gitlab-ci.d/cirrus.yml | 2 +- tests/vm/freebsd| 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/.gitlab-ci.d/cirrus.yml b/.gitlab-ci.d/cirrus.yml index 634a73a742..785b163aa6 100644 --- a/.gitlab-ci.d/cirrus.yml +++ b/.gitlab-ci.d/cirrus.yml @@ -50,7 +50,7 @@ x64-freebsd-12-build: NAME: freebsd-12 CIRRUS_VM_INSTANCE_TYPE: freebsd_instance CIRRUS_VM_IMAGE_SELECTOR: image_family -CIRRUS_VM_IMAGE_NAME: freebsd-12-3 +CIRRUS_VM_IMAGE_NAME: freebsd-12-4 CIRRUS_VM_CPUS: 8 CIRRUS_VM_RAM: 8G UPDATE_COMMAND: pkg update diff --git a/tests/vm/freebsd b/tests/vm/freebsd index d6ff4461ba..ba2ba23d24 100755 --- a/tests/vm/freebsd +++ b/tests/vm/freebsd @@ -28,8 +28,8 @@ class FreeBSDVM(basevm.BaseVM): name = "freebsd" arch = "x86_64" -link = "https://download.freebsd.org/ftp/releases/ISO-IMAGES/12.3/FreeBSD-12.3-RELEASE-amd64-disc1.iso.xz; -csum = "36dd0de50f1fe5f0a88e181e94657656de26fb64254412f74e80e128e8b938b4" +link = "https://download.freebsd.org/ftp/releases/ISO-IMAGES/12.4/FreeBSD-12.4-RELEASE-amd64-disc1.iso.xz; +csum = "1dcf6446e31bf3f81b582e9aba3319a258c29a937a2af6138ee4b181ed719a87" I don't remember and wonder why we don't use the pre-populated image: https://download.freebsd.org/ftp/releases/VM-IMAGES/12.4-RELEASE/amd64/Latest/FreeBSD-12.4-RELEASE-amd64.qcow2.xz Anyhow, Reviewed-by: Philippe Mathieu-Daudé Tested-by: Philippe Mathieu-Daudé
Re: [PATCH v11 1/2] vhost-vdpa: Skip the range check while MR is IOMMU
On Wed, Nov 30, 2022 at 1:33 PM Cindy Lu wrote:
>
> Skip the check in vhost_vdpa_listener_skipped_section() while
> MR is IOMMU, Move this check to vhost_vdpa_iommu_map_notify()
>
> Signed-off-by: Cindy Lu
> ---
> hw/virtio/vhost-vdpa.c | 21 ++---
> 1 file changed, 14 insertions(+), 7 deletions(-)
>
> diff --git a/hw/virtio/vhost-vdpa.c b/hw/virtio/vhost-vdpa.c
> index 3ff9ce3501..f0e9963d19 100644
> --- a/hw/virtio/vhost-vdpa.c
> +++ b/hw/virtio/vhost-vdpa.c
> @@ -60,15 +60,22 @@ static bool
> vhost_vdpa_listener_skipped_section(MemoryRegionSection *section,
> iova_min, section->offset_within_address_space);
> return true;
> }
> +/*
> + * While using vIOMMU, Sometimes the section will be larger than iova_max
> + * but the memory that actually mapping is smaller, So skip the check
> + * here. Will add the check in vhost_vdpa_iommu_map_notify,
> + *There is the real size that maps to the kernel
> + */
>
I suggest squashing this into the next patch since we haven't
implemented vhost_vdpa_iommu_map_notify() yet.
Thanks
> -llend = vhost_vdpa_section_end(section);
> -if (int128_gt(llend, int128_make64(iova_max))) {
> -error_report("RAM section out of device range (max=0x%" PRIx64
> - ", end addr=0x%" PRIx64 ")",
> - iova_max, int128_get64(llend));
> -return true;
> +if (!memory_region_is_iommu(section->mr)) {
> +llend = vhost_vdpa_section_end(section);
> +if (int128_gt(llend, int128_make64(iova_max))) {
> +error_report("RAM section out of device range (max=0x%" PRIx64
> + ", end addr=0x%" PRIx64 ")",
> + iova_max, int128_get64(llend));
> +return true;
> +}
> }
> -
> return false;
> }
>
> --
> 2.34.3
>
Re: [RFC PATCH for 8.0 00/13] vDPA-net inflight descriptors migration with SVQ
On Wed, Dec 7, 2022 at 5:00 PM Eugenio Perez Martin wrote: > > On Tue, Dec 6, 2022 at 8:08 AM Jason Wang wrote: > > > > On Tue, Dec 6, 2022 at 1:04 AM Eugenio Pérez wrote: > > > > > > The state of the descriptors (avail or used) may not be recoverable just > > > looking at the guest memory. Out of order used descriptor may override > > > previous avail ones in the descriptor table or avail vring. > > > > > > Currently we're not migrating this status in net devices because > > > virtio-net, > > > vhost-kernel etc use the descriptors in order, > > > > Note that this might not be the truth (when zerocopy is enabled). > > > > Good point. So will virtio-net wait for those to complete then? Vhost-net will wait for all the inflight descriptors to be completed. > How > does qemu handle if there are still inflight descriptors? It doesn't care right now. For networking devices, devices can choose to flush inflight before suspending. But this won't work for other type of device like block. Thanks > > > > so the information always > > > recoverable from guest's memory. However, vDPA devices may use them out > > > of > > > order, and other kind of devices like block need this support. > > > > > > Shadow virtqueue is able to track these and resend them at the > > > destination. > > > > As discussed, there's a bootstrap issue here: > > > > When SVQ needs to be enabled on demand, do we still need another way > > to get inflight ones without the help of SVQ? > > > > To send and retrieve the descriptor without SVQ needs to be developed > on top of this. I should have made that more clear here in the cover > letter. > > Thanks! > > > Thanks > > > > > Add them to the virtio-net migration description so they are not lose in > > > the > > > process. > > > > > > This is a very early RFC just to validate the first draft so expect > > > leftovers. > > > To fetch and request the descriptors from a device without SVQ need to be > > > implemented on top. Some other notable pending items are: > > > * Do not send the descriptors actually recoverable from the guest memory. > > > * Properly version the migrate data. > > > * Properly abstract the descriptors access from virtio-net to SVQ. > > > * Do not use VirtQueueElementOld but migrate directly VirtQueueElement. > > > * Replace lots of assertions with runtime conditionals. > > > * Other TODOs in the patch message or code changes. > > > > > > Thanks. > > > > > > Eugenio Pérez (13): > > > vhost: add available descriptor list in SVQ > > > vhost: iterate only available descriptors at SVQ stop > > > vhost: merge avail list and next avail descriptors detach > > > vhost: add vhost_svq_save_inflight > > > virtio: Specify uint32_t as VirtQueueElementOld members type > > > virtio: refactor qemu_get_virtqueue_element > > > virtio: refactor qemu_put_virtqueue_element > > > virtio: expose VirtQueueElementOld > > > virtio: add vmstate_virtqueue_element_old > > > virtio-net: Migrate vhost inflight descriptors > > > virtio-net: save inflight descriptors at vhost shutdown > > > vhost: expose vhost_svq_add_element > > > vdpa: Recover inflight descriptors > > > > > > hw/virtio/vhost-shadow-virtqueue.h | 9 ++ > > > include/hw/virtio/virtio-net.h | 2 + > > > include/hw/virtio/virtio.h | 32 ++ > > > include/migration/vmstate.h| 22 > > > hw/net/vhost_net.c | 56 ++ > > > hw/net/virtio-net.c| 129 +++ > > > hw/virtio/vhost-shadow-virtqueue.c | 52 +++-- > > > hw/virtio/vhost-vdpa.c | 11 -- > > > hw/virtio/virtio.c | 162 ++--- > > > 9 files changed, 392 insertions(+), 83 deletions(-) > > > > > > -- > > > 2.31.1 > > > > > > > > >
[PATCH 0/6] target/i386: Support new Intel platform Instructions in CPUID enumeration
Latest Intel platform Granite Rapids/Sierra Forest has introduced below new instructions and CPUIDs: - CMPccXADD CPUID.(EAX=7,ECX=1):EAX[bit 7] - AMX-FP16 CPUID.(EAX=7,ECX=1):EAX[bit 21] - AVX-IFMA CPUID.(EAX=7,ECX=1):EAX[bit 23] - AVX-VNNI-INT8 CPUID.(EAX=7,ECX=1):EDX[bit 4] - AVX-NE-CONVERT CPUID.(EAX=7,ECX=1):EDX[bit 5] - PREFETCHITI CPUID.(EAX=7,ECX=1):EDX[bit 14] Details can be found in recent Intel ISE (Instruction Set Extensions)[1]. Linux 6.2 will support for advertising these features to userspace. KVM patches have been merged into kvm/next[2]. This patch series adds CPUID definitions of the corresponding features in QEMU. [1] Intel ISE: https://cdrdv2.intel.com/v1/dl/getContent/671368 [2] kvm/next: https://git.kernel.org/pub/scm/virt/kvm/kvm.git Jiaxi Chen (6): target/i386: Add support for CMPCCXADD in CPUID enumeration target/i386: Add support for AMX-FP16 in CPUID enumeration target/i386: Add support for AVX-IFMA in CPUID enumeration target/i386: Add support for AVX-VNNI-INT8 in CPUID enumeration target/i386: Add support for AVX-NE-CONVERT in CPUID enumeration target/i386: Add support for PREFETCHIT0/1 in CPUID enumeration target/i386/cpu.c | 26 +++--- target/i386/cpu.h | 15 +++ 2 files changed, 38 insertions(+), 3 deletions(-) base-commit: ea3a008d2d9ced9c4f93871c823baee237047f93 -- 2.27.0
[PATCH 2/6] target/i386: Add support for AMX-FP16 in CPUID enumeration
Latest Intel platform Granite Rapids has introduced a new instruction -
AMX-FP16, which performs dot-products of two FP16 tiles and accumulates
the results into a packed single precision tile. AMX-FP16 adds FP16
capability and allows a FP16 GPU trained model to run faster without
loss of accuracy or added SW overhead.
The bit definition:
CPUID.(EAX=7,ECX=1):EAX[bit 21]
Add CPUID definition for AMX-FP16.
Signed-off-by: Jiaxi Chen
---
target/i386/cpu.c | 2 +-
target/i386/cpu.h | 2 ++
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index a61f936eef..cd787b3d97 100644
--- a/target/i386/cpu.c
+++ b/target/i386/cpu.c
@@ -875,7 +875,7 @@ FeatureWordInfo feature_word_info[FEATURE_WORDS] = {
NULL, NULL, NULL, NULL,
NULL, NULL, NULL, NULL,
NULL, NULL, NULL, NULL,
-NULL, NULL, NULL, NULL,
+NULL, "amx-fp16", NULL, NULL,
NULL, NULL, NULL, NULL,
NULL, NULL, NULL, NULL,
},
diff --git a/target/i386/cpu.h b/target/i386/cpu.h
index 3391b99456..d2e3079dfb 100644
--- a/target/i386/cpu.h
+++ b/target/i386/cpu.h
@@ -902,6 +902,8 @@ uint64_t x86_cpu_get_supported_feature_word(FeatureWord w,
#define CPUID_7_1_EAX_AVX512_BF16 (1U << 5)
/* CMPCCXADD Instructions */
#define CPUID_7_1_EAX_CMPCCXADD (1U << 7)
+/* Support Tile Computational Operations on FP16 Numbers */
+#define CPUID_7_1_EAX_AMX_FP16 (1U << 21)
/* XFD Extend Feature Disabled */
#define CPUID_D_1_EAX_XFD (1U << 4)
--
2.27.0
[PATCH 1/6] target/i386: Add support for CMPCCXADD in CPUID enumeration
CMPccXADD is a new set of instructions in the latest Intel platform
Sierra Forest. This new instruction set includes a semaphore operation
that can compare and add the operands if condition is met, which can
improve database performance.
The bit definition:
CPUID.(EAX=7,ECX=1):EAX[bit 7]
Add CPUID definition for CMPCCXADD.
Signed-off-by: Jiaxi Chen
---
target/i386/cpu.c | 2 +-
target/i386/cpu.h | 3 +++
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index 22b681ca37..a61f936eef 100644
--- a/target/i386/cpu.c
+++ b/target/i386/cpu.c
@@ -871,7 +871,7 @@ FeatureWordInfo feature_word_info[FEATURE_WORDS] = {
.type = CPUID_FEATURE_WORD,
.feat_names = {
NULL, NULL, NULL, NULL,
-"avx-vnni", "avx512-bf16", NULL, NULL,
+"avx-vnni", "avx512-bf16", NULL, "cmpccxadd",
NULL, NULL, NULL, NULL,
NULL, NULL, NULL, NULL,
NULL, NULL, NULL, NULL,
diff --git a/target/i386/cpu.h b/target/i386/cpu.h
index d4bc19577a..3391b99456 100644
--- a/target/i386/cpu.h
+++ b/target/i386/cpu.h
@@ -900,6 +900,9 @@ uint64_t x86_cpu_get_supported_feature_word(FeatureWord w,
#define CPUID_7_1_EAX_AVX_VNNI (1U << 4)
/* AVX512 BFloat16 Instruction */
#define CPUID_7_1_EAX_AVX512_BF16 (1U << 5)
+/* CMPCCXADD Instructions */
+#define CPUID_7_1_EAX_CMPCCXADD (1U << 7)
+
/* XFD Extend Feature Disabled */
#define CPUID_D_1_EAX_XFD (1U << 4)
--
2.27.0
[PATCH 4/6] target/i386: Add support for AVX-VNNI-INT8 in CPUID enumeration
AVX-VNNI-INT8 is a new set of instructions in the latest Intel platform
Sierra Forest, aims for the platform to have superior AI capabilities.
This instruction multiplies the individual bytes of two unsigned or
unsigned source operands, then adds and accumulates the results into the
destination dword element size operand.
The bit definition:
CPUID.(EAX=7,ECX=1):EDX[bit 4]
AVX-VNNI-INT8 is on a new feature bits leaf. Add a CPUID feature word
FEAT_7_1_EDX for this leaf.
Add CPUID definition for AVX-VNNI-INT8.
Signed-off-by: Jiaxi Chen
---
target/i386/cpu.c | 22 +-
target/i386/cpu.h | 4
2 files changed, 25 insertions(+), 1 deletion(-)
diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index 5ba0fc61d2..ea1daf6b7e 100644
--- a/target/i386/cpu.c
+++ b/target/i386/cpu.c
@@ -663,6 +663,7 @@ void x86_cpu_vendor_words2str(char *dst, uint32_t vendor1,
CPUID_7_0_ECX_LA57 | CPUID_7_0_ECX_PKS | CPUID_7_0_ECX_VAES)
#define TCG_7_0_EDX_FEATURES 0
#define TCG_7_1_EAX_FEATURES 0
+#define TCG_7_1_EDX_FEATURES 0
#define TCG_APM_FEATURES 0
#define TCG_6_EAX_FEATURES CPUID_6_EAX_ARAT
#define TCG_XSAVE_FEATURES (CPUID_XSAVE_XSAVEOPT | CPUID_XSAVE_XGETBV1)
@@ -886,6 +887,25 @@ FeatureWordInfo feature_word_info[FEATURE_WORDS] = {
},
.tcg_features = TCG_7_1_EAX_FEATURES,
},
+[FEAT_7_1_EDX] = {
+.type = CPUID_FEATURE_WORD,
+.feat_names = {
+NULL, NULL, NULL, NULL,
+"avx-vnni-int8", NULL, NULL, NULL,
+NULL, NULL, NULL, NULL,
+NULL, NULL, NULL, NULL,
+NULL, NULL, NULL, NULL,
+NULL, NULL, NULL, NULL,
+NULL, NULL, NULL, NULL,
+NULL, NULL, NULL, NULL,
+},
+.cpuid = {
+.eax = 7,
+.needs_ecx = true, .ecx = 1,
+.reg = R_EDX,
+},
+.tcg_features = TCG_7_1_EDX_FEATURES,
+},
[FEAT_8000_0007_EDX] = {
.type = CPUID_FEATURE_WORD,
.feat_names = {
@@ -5387,9 +5407,9 @@ void cpu_x86_cpuid(CPUX86State *env, uint32_t index,
uint32_t count,
}
} else if (count == 1) {
*eax = env->features[FEAT_7_1_EAX];
+*edx = env->features[FEAT_7_1_EDX];
*ebx = 0;
*ecx = 0;
-*edx = 0;
} else {
*eax = 0;
*ebx = 0;
diff --git a/target/i386/cpu.h b/target/i386/cpu.h
index 1223f0018b..da4fb1cfca 100644
--- a/target/i386/cpu.h
+++ b/target/i386/cpu.h
@@ -623,6 +623,7 @@ typedef enum FeatureWord {
FEAT_SGX_12_1_EAX, /* CPUID[EAX=0x12,ECX=1].EAX (SGX ATTRIBUTES[31:0]) */
FEAT_XSAVE_XSS_LO, /* CPUID[EAX=0xd,ECX=1].ECX */
FEAT_XSAVE_XSS_HI, /* CPUID[EAX=0xd,ECX=1].EDX */
+FEAT_7_1_EDX, /* CPUID[EAX=7,ECX=1].EDX */
FEATURE_WORDS,
} FeatureWord;
@@ -907,6 +908,9 @@ uint64_t x86_cpu_get_supported_feature_word(FeatureWord w,
/* Support for VPMADD52[H,L]UQ */
#define CPUID_7_1_EAX_AVX_IFMA (1U << 23)
+/* Support for VPDPB[SU,UU,SS]D[,S] */
+#define CPUID_7_1_EDX_AVX_VNNI_INT8 (1U << 4)
+
/* XFD Extend Feature Disabled */
#define CPUID_D_1_EAX_XFD (1U << 4)
--
2.27.0
[PATCH 6/6] target/i386: Add support for PREFETCHIT0/1 in CPUID enumeration
Latest Intel platform Granite Rapids has introduced a new instruction -
PREFETCHIT0/1, which moves code to memory (cache) closer to the
processor depending on specific hints.
The bit definition:
CPUID.(EAX=7,ECX=1):EDX[bit 14]
Add CPUID definition for PREFETCHIT0/1.
Signed-off-by: Jiaxi Chen
---
target/i386/cpu.c | 2 +-
target/i386/cpu.h | 2 ++
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index 4aca5360cc..81d13800db 100644
--- a/target/i386/cpu.c
+++ b/target/i386/cpu.c
@@ -893,7 +893,7 @@ FeatureWordInfo feature_word_info[FEATURE_WORDS] = {
NULL, NULL, NULL, NULL,
"avx-vnni-int8", "avx-ne-convert", NULL, NULL,
NULL, NULL, NULL, NULL,
-NULL, NULL, NULL, NULL,
+NULL, NULL, "prefetchiti", NULL,
NULL, NULL, NULL, NULL,
NULL, NULL, NULL, NULL,
NULL, NULL, NULL, NULL,
diff --git a/target/i386/cpu.h b/target/i386/cpu.h
index c4571d726c..7b55ef289d 100644
--- a/target/i386/cpu.h
+++ b/target/i386/cpu.h
@@ -912,6 +912,8 @@ uint64_t x86_cpu_get_supported_feature_word(FeatureWord w,
#define CPUID_7_1_EDX_AVX_VNNI_INT8 (1U << 4)
/* AVX NE CONVERT Instructions */
#define CPUID_7_1_EDX_AVX_NE_CONVERT(1U << 5)
+/* PREFETCHIT0/1 Instructions */
+#define CPUID_7_1_EDX_PREFETCHITI (1U << 14)
/* XFD Extend Feature Disabled */
#define CPUID_D_1_EAX_XFD (1U << 4)
--
2.27.0
[PATCH 3/6] target/i386: Add support for AVX-IFMA in CPUID enumeration
AVX-IFMA is a new instruction in the latest Intel platform Sierra
Forest. This instruction packed multiplies unsigned 52-bit integers and
adds the low/high 52-bit products to Qword Accumulators.
The bit definition:
CPUID.(EAX=7,ECX=1):EAX[bit 23]
Add CPUID definition for AVX-IFMA.
Signed-off-by: Jiaxi Chen
---
target/i386/cpu.c | 2 +-
target/i386/cpu.h | 2 ++
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index cd787b3d97..5ba0fc61d2 100644
--- a/target/i386/cpu.c
+++ b/target/i386/cpu.c
@@ -875,7 +875,7 @@ FeatureWordInfo feature_word_info[FEATURE_WORDS] = {
NULL, NULL, NULL, NULL,
NULL, NULL, NULL, NULL,
NULL, NULL, NULL, NULL,
-NULL, "amx-fp16", NULL, NULL,
+NULL, "amx-fp16", NULL, "avx-ifma",
NULL, NULL, NULL, NULL,
NULL, NULL, NULL, NULL,
},
diff --git a/target/i386/cpu.h b/target/i386/cpu.h
index d2e3079dfb..1223f0018b 100644
--- a/target/i386/cpu.h
+++ b/target/i386/cpu.h
@@ -904,6 +904,8 @@ uint64_t x86_cpu_get_supported_feature_word(FeatureWord w,
#define CPUID_7_1_EAX_CMPCCXADD (1U << 7)
/* Support Tile Computational Operations on FP16 Numbers */
#define CPUID_7_1_EAX_AMX_FP16 (1U << 21)
+/* Support for VPMADD52[H,L]UQ */
+#define CPUID_7_1_EAX_AVX_IFMA (1U << 23)
/* XFD Extend Feature Disabled */
#define CPUID_D_1_EAX_XFD (1U << 4)
--
2.27.0
[PATCH 5/6] target/i386: Add support for AVX-NE-CONVERT in CPUID enumeration
AVX-NE-CONVERT is a new set of instructions which can convert low
precision floating point like BF16/FP16 to high precision floating point
FP32, as well as convert FP32 elements to BF16. This instruction allows
the platform to have improved AI capabilities and better compatibility.
The bit definition:
CPUID.(EAX=7,ECX=1):EDX[bit 5]
Add CPUID definition for AVX-NE-CONVERT.
Signed-off-by: Jiaxi Chen
---
target/i386/cpu.c | 2 +-
target/i386/cpu.h | 2 ++
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index ea1daf6b7e..4aca5360cc 100644
--- a/target/i386/cpu.c
+++ b/target/i386/cpu.c
@@ -891,7 +891,7 @@ FeatureWordInfo feature_word_info[FEATURE_WORDS] = {
.type = CPUID_FEATURE_WORD,
.feat_names = {
NULL, NULL, NULL, NULL,
-"avx-vnni-int8", NULL, NULL, NULL,
+"avx-vnni-int8", "avx-ne-convert", NULL, NULL,
NULL, NULL, NULL, NULL,
NULL, NULL, NULL, NULL,
NULL, NULL, NULL, NULL,
diff --git a/target/i386/cpu.h b/target/i386/cpu.h
index da4fb1cfca..c4571d726c 100644
--- a/target/i386/cpu.h
+++ b/target/i386/cpu.h
@@ -910,6 +910,8 @@ uint64_t x86_cpu_get_supported_feature_word(FeatureWord w,
/* Support for VPDPB[SU,UU,SS]D[,S] */
#define CPUID_7_1_EDX_AVX_VNNI_INT8 (1U << 4)
+/* AVX NE CONVERT Instructions */
+#define CPUID_7_1_EDX_AVX_NE_CONVERT(1U << 5)
/* XFD Extend Feature Disabled */
#define CPUID_D_1_EAX_XFD (1U << 4)
--
2.27.0
Re: [PATCH v3 1/2] hw/nvme: Implement shadow doorbell buffer support
On Dec 7 09:49, Guenter Roeck wrote: > Hi, > > On Thu, Jun 16, 2022 at 08:34:07PM +0800, Jinhao Fan wrote: > > Implement Doorbel Buffer Config command (Section 5.7 in NVMe Spec 1.3) > > and Shadow Doorbel buffer & EventIdx buffer handling logic (Section 7.13 > > in NVMe Spec 1.3). For queues created before the Doorbell Buffer Config > > command, the nvme_dbbuf_config function tries to associate each existing > > SQ and CQ with its Shadow Doorbel buffer and EventIdx buffer address. > > Queues created after the Doorbell Buffer Config command will have the > > doorbell buffers associated with them when they are initialized. > > > > In nvme_process_sq and nvme_post_cqe, proactively check for Shadow > > Doorbell buffer changes instead of wait for doorbell register changes. > > This reduces the number of MMIOs. > > > > In nvme_process_db(), update the shadow doorbell buffer value with > > the doorbell register value if it is the admin queue. This is a hack > > since hosts like Linux NVMe driver and SPDK do not use shadow > > doorbell buffer for the admin queue. Copying the doorbell register > > value to the shadow doorbell buffer allows us to support these hosts > > as well as spec-compliant hosts that use shadow doorbell buffer for > > the admin queue. > > > > Signed-off-by: Jinhao Fan > > I noticed that I can no longer boot Linux kernels from nvme on riscv64 > systems. The problem is seen with qemu v7.1 and qemu v7.2-rc4. > The log shows: > > [ 35.904128] nvme nvme0: I/O 642 (I/O Cmd) QID 1 timeout, aborting > [ 35.905000] EXT4-fs (nvme0n1): mounting ext2 file system using the ext4 > subsystem > [ 66.623863] nvme nvme0: I/O 643 (I/O Cmd) QID 1 timeout, aborting > [ 97.343989] nvme nvme0: Abort status: 0x0 > [ 97.344355] nvme nvme0: Abort status: 0x0 > [ 97.344647] nvme nvme0: I/O 7 QID 0 timeout, reset controller > [ 97.350568] nvme nvme0: I/O 644 (I/O Cmd) QID 1 timeout, aborting > > This is with the mainline Linux kernel (v6.1-rc8). > > Bisect points to this patch. Reverting this patch and a number of associated > patches (to fix conflicts) fixes the problem. > > 06143d8771 Revert "hw/nvme: Implement shadow doorbell buffer support" > acb4443e3a Revert "hw/nvme: Use ioeventfd to handle doorbell updates" > d5fd309feb Revert "hw/nvme: do not enable ioeventfd by default" > 1ca1e6c47c Revert "hw/nvme: unregister the event notifier handler on the main > loop" > 2d26abd51e Revert "hw/nvme: skip queue processing if notifier is cleared" > 99d411b5a5 Revert "hw/nvme: reenable cqe batching" > 2293d3ca6c Revert "hw/nvme: Add trace events for shadow doorbell buffer" > > Qemu command line: > > qemu-system-riscv64 -M virt -m 512M \ > -kernel arch/riscv/boot/Image -snapshot \ > -device nvme,serial=foo,drive=d0 \ > -drive file=rootfs.ext2,if=none,format=raw,id=d0 \ > -bios default \ > -append "root=/dev/nvme0n1 console=ttyS0,115200 > earlycon=uart8250,mmio,0x1000,115200" \ > -nographic -monitor none > > Guenter Hi Guenter, Thanks for the bisect. The shadow doorbell is also an obvious candidate for this regression. I wonder if this could be a kernel bug, since we are not observing this on other architectures. The memory barriers required are super finicky, but in QEMU all the operations are associated with full memory barriers. The barriers are more fine grained in the kernel though. I will dig into this together with Keith. signature.asc Description: PGP signature
Re: [PULL 11/21] docs: Build and install all the docs in a single manual
Am 12.01.21 um 17:57 schrieb Peter Maydell:
[...]
diff --git a/docs/meson.build b/docs/meson.build
index fae9849b79b..bb14eaebd3b 100644
--- a/docs/meson.build
+++ b/docs/meson.build
@@ -46,19 +46,11 @@ if build_docs
meson.source_root() / 'docs/sphinx/qmp_lexer.py',
qapi_gen_depends ]
- configure_file(output: 'index.html',
- input: files('index.html.in'),
- configuration: {'VERSION': meson.project_version()},
- install_dir: qemu_docdir)
- manuals = [ 'devel', 'interop', 'tools', 'specs', 'system', 'user' ]
man_pages = {
-'interop' : {
'qemu-ga.8': (have_tools ? 'man8' : ''),
'qemu-ga-ref.7': 'man7',
'qemu-qmp-ref.7': 'man7',
'qemu-storage-daemon-qmp-ref.7': (have_tools ? 'man7' : ''),
-},
-'tools': {
'qemu-img.1': (have_tools ? 'man1' : ''),
'qemu-nbd.8': (have_tools ? 'man8' : ''),
'qemu-pr-helper.8': (have_tools ? 'man8' : ''),
@@ -66,53 +58,47 @@ if build_docs
'qemu-trace-stap.1': (config_host.has_key('CONFIG_TRACE_SYSTEMTAP') ?
'man1' : ''),
'virtfs-proxy-helper.1': (have_virtfs_proxy_helper ? 'man1' : ''),
'virtiofsd.1': (have_virtiofsd ? 'man1' : ''),
-},
-'system': {
'qemu.1': 'man1',
'qemu-block-drivers.7': 'man7',
'qemu-cpu-models.7': 'man7'
-},
}
sphinxdocs = []
sphinxmans = []
- foreach manual : manuals
-private_dir = meson.current_build_dir() / (manual + '.p')
-output_dir = meson.current_build_dir() / manual
-input_dir = meson.current_source_dir() / manual
-this_manual = custom_target(manual + ' manual',
+ private_dir = meson.current_build_dir() / 'manual.p'
+ output_dir = meson.current_build_dir() / 'manual'
+ input_dir = meson.current_source_dir()
+
+ this_manual = custom_target('QEMU manual',
build_by_default: build_docs,
-output: [manual + '.stamp'],
-input: [files('conf.py'), files(manual / 'conf.py')],
-depfile: manual + '.d',
+output: 'docs.stamp',
+input: files('conf.py'),
+depfile: 'docs.d',
depend_files: sphinx_extn_depends,
command: [SPHINX_ARGS, '-Ddepfile=@DEPFILE@',
'-Ddepfile_stamp=@OUTPUT0@',
'-b', 'html', '-d', private_dir,
input_dir, output_dir])
-sphinxdocs += this_manual
-if build_docs and manual != 'devel'
- install_subdir(output_dir, install_dir: qemu_docdir)
-endif
+ sphinxdocs += this_manual
+ install_subdir(output_dir, install_dir: qemu_docdir, strip_directory: true)
This line causes a build warning with the latest code:
../../../docs/meson.build:74: WARNING: Project targets '>=0.61.3' but
uses feature deprecated since '0.60.0': install_subdir with empty
directory. It worked by accident and is buggy. Use install_emptydir instead.
It looks like `qemu_docdir` is no longer defined anywhere.
I still did not find out whether this is an issue which needs a fix for 7.2.
Stefan
-these_man_pages = []
-install_dirs = []
[...]
[PATCH] FreeBSD: Upgrade to 12.4 release
FreeBSD: Upgrade to 12.4 release Signed-off-by: Brad Smith --- .gitlab-ci.d/cirrus.yml | 2 +- tests/vm/freebsd| 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/.gitlab-ci.d/cirrus.yml b/.gitlab-ci.d/cirrus.yml index 634a73a742..785b163aa6 100644 --- a/.gitlab-ci.d/cirrus.yml +++ b/.gitlab-ci.d/cirrus.yml @@ -50,7 +50,7 @@ x64-freebsd-12-build: NAME: freebsd-12 CIRRUS_VM_INSTANCE_TYPE: freebsd_instance CIRRUS_VM_IMAGE_SELECTOR: image_family -CIRRUS_VM_IMAGE_NAME: freebsd-12-3 +CIRRUS_VM_IMAGE_NAME: freebsd-12-4 CIRRUS_VM_CPUS: 8 CIRRUS_VM_RAM: 8G UPDATE_COMMAND: pkg update diff --git a/tests/vm/freebsd b/tests/vm/freebsd index d6ff4461ba..ba2ba23d24 100755 --- a/tests/vm/freebsd +++ b/tests/vm/freebsd @@ -28,8 +28,8 @@ class FreeBSDVM(basevm.BaseVM): name = "freebsd" arch = "x86_64" -link = "https://download.freebsd.org/ftp/releases/ISO-IMAGES/12.3/FreeBSD-12.3-RELEASE-amd64-disc1.iso.xz; -csum = "36dd0de50f1fe5f0a88e181e94657656de26fb64254412f74e80e128e8b938b4" +link = "https://download.freebsd.org/ftp/releases/ISO-IMAGES/12.4/FreeBSD-12.4-RELEASE-amd64-disc1.iso.xz; +csum = "1dcf6446e31bf3f81b582e9aba3319a258c29a937a2af6138ee4b181ed719a87" size = "20G" pkgs = [ # build tools -- 2.38.1
Re: [PATCH 2/5] hw/acpi/Kconfig: Rename ACPI_X86_ICH to ACPI_ICH9
On 8/12/22 00:12, Bernhard Beschow wrote: Although the ICH9 ACPI controller may currently be tied to x86 it doesn't have to. Furthermore, the source files this configuration switch manages contain a '9', so this name fits more. Signed-off-by: Bernhard Beschow --- hw/acpi/Kconfig | 2 +- hw/acpi/meson.build | 2 +- hw/i2c/meson.build | 2 +- hw/isa/Kconfig | 2 +- 4 files changed, 4 insertions(+), 4 deletions(-) Reviewed-by: Philippe Mathieu-Daudé
[PATCH v3 0/8] Make Intel PT configurable
Initial virtualization of Intel PT was added by making it as fixed feature set of ICX's capabilities. However, it breaks the Intel PT exposure on SPR machine because SPR has less PT capabilities of CPUID(0x14,1):EBX[15:0]. This series aims to make Intel PT configurable that named CPU model can define its own PT feature set and "-cpu host/max" can use host pass-through feature set of Intel PT. At the same time, it also ensures existing named CPU model to generate the same PT CPUID set as before to not break live migration. Changes in v3: - rebase to v7.2.0-rc4 - Add bit 7 and 8 of FEAT_14_0_EBX in Patch 3 v2: https://lore.kernel.org/qemu-devel/20220808085834.3227541-1-xiaoyao...@intel.com/ Changes in v2: - split out 3 patches (per Eduardo's comment) - determine if the named cpu model uses default Intel PT capabilities (to be compatible with the old behavior) by condition that all PT feature leaves are all zero. v1: https://lore.kernel.org/qemu-devel/20210909144150.1728418-1-xiaoyao...@intel.com/ Xiaoyao Li (8): target/i386: Print CPUID subleaf info for unsupported feature target/i386/intel-pt: Fix INTEL_PT_ADDR_RANGES_NUM_MASK target/i386/intel-pt: Introduce FeatureWordInfo for Intel PT CPUID leaf 0x14 target/i386/intel-pt: print special message for INTEL_PT_ADDR_RANGES_NUM target/i386/intel-pt: Rework/rename the default INTEL-PT feature set target/i386/intel-pt: Enable host pass through of Intel PT target/i386/intel-pt: Define specific PT feature set for IceLake-server and Snowridge target/i386/intel-pt: Access MSR_IA32_RTIT_ADDRn based on guest CPUID configuration target/i386/cpu.c | 293 +++--- target/i386/cpu.h | 40 +- target/i386/kvm/kvm.c | 8 +- 3 files changed, 263 insertions(+), 78 deletions(-) -- 2.27.0
[PATCH v3 7/8] target/i386/intel-pt: Define specific PT feature set for IceLake-server and Snowridge
For IceLake-server, it's just the same as using the default PT
feature set since the default one is exact taken from ICX.
For Snowridge, define it according to real SNR silicon capabilities.
Signed-off-by: Xiaoyao Li
---
target/i386/cpu.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index 24f3c7b06698..ef574c819671 100644
--- a/target/i386/cpu.c
+++ b/target/i386/cpu.c
@@ -3458,6 +3458,14 @@ static const X86CPUDefinition builtin_x86_defs[] = {
.features[FEAT_6_EAX] =
CPUID_6_EAX_ARAT,
/* Missing: Mode-based execute control (XS/XU), processor tracing, TSC
scaling */
+.features[FEAT_14_0_EBX] =
+CPUID_14_0_EBX_CR3_FILTER | CPUID_14_0_EBX_PSB |
+CPUID_14_0_EBX_IP_FILTER | CPUID_14_0_EBX_MTC,
+.features[FEAT_14_0_ECX] =
+CPUID_14_0_ECX_TOPA | CPUID_14_0_ECX_MULTI_ENTRIES |
+CPUID_14_0_ECX_SINGLE_RANGE,
+.features[FEAT_14_1_EAX] = 0x249 << 16 | 0x2,
+.features[FEAT_14_1_EBX] = 0x003f << 16 | 0x1fff,
.features[FEAT_VMX_BASIC] = MSR_VMX_BASIC_INS_OUTS |
MSR_VMX_BASIC_TRUE_CTLS,
.features[FEAT_VMX_ENTRY_CTLS] = VMX_VM_ENTRY_IA32E_MODE |
@@ -3735,6 +3743,16 @@ static const X86CPUDefinition builtin_x86_defs[] = {
CPUID_XSAVE_XGETBV1,
.features[FEAT_6_EAX] =
CPUID_6_EAX_ARAT,
+.features[FEAT_14_0_EBX] =
+CPUID_14_0_EBX_CR3_FILTER | CPUID_14_0_EBX_PSB |
+CPUID_14_0_EBX_IP_FILTER | CPUID_14_0_EBX_MTC |
+CPUID_14_0_EBX_PTWRITE | CPUID_14_0_EBX_POWER_EVENT |
+CPUID_14_0_EBX_PSB_PMI_PRESERVATION,
+.features[FEAT_14_0_ECX] =
+CPUID_14_0_ECX_TOPA | CPUID_14_0_ECX_MULTI_ENTRIES |
+CPUID_14_0_ECX_SINGLE_RANGE | CPUID_14_0_ECX_LIP,
+.features[FEAT_14_1_EAX] = 0x249 << 16 | 0x2,
+.features[FEAT_14_1_EBX] = 0x003f << 16 | 0x,
.features[FEAT_VMX_BASIC] = MSR_VMX_BASIC_INS_OUTS |
MSR_VMX_BASIC_TRUE_CTLS,
.features[FEAT_VMX_ENTRY_CTLS] = VMX_VM_ENTRY_IA32E_MODE |
--
2.27.0
[PATCH v3 3/8] target/i386/intel-pt: Introduce FeatureWordInfo for Intel PT CPUID leaf 0x14
CPUID leaf 0x14 subleaf 0x0 and 0x1 enumerate the resource and
capability of Intel PT.
Introduce FeatureWord FEAT_14_0_EBX, FEAT_14_1_EAX and FEAT_14_1_EBX,
and complete FEAT_14_0_ECX. Thus all the features of Intel PT can be
expanded when "-cpu host/max" and can be configured in named CPU model.
Signed-off-by: Xiaoyao Li
---
v3:
- Add bit 7 and 8 of FEAT_14_0_EBX
---
target/i386/cpu.c | 138 +++---
target/i386/cpu.h | 3 +
2 files changed, 132 insertions(+), 9 deletions(-)
diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index 9ae36639d380..65c6f8ae771a 100644
--- a/target/i386/cpu.c
+++ b/target/i386/cpu.c
@@ -1208,17 +1208,34 @@ FeatureWordInfo feature_word_info[FEATURE_WORDS] = {
}
},
+[FEAT_14_0_EBX] = {
+.type = CPUID_FEATURE_WORD,
+.feat_names = {
+[0] = "intel-pt-cr3-filter",
+[1] = "intel-pt-psb",
+[2] = "intel-pt-ip-filter",
+[3] = "intel-pt-mtc",
+[4] = "intel-pt-ptwrite",
+[5] = "intel-pt-power-event",
+[6] = "intel-pt-psb-pmi-preservation",
+[7] = "intel-pt-event-trace",
+[8] = "intel-pt-tnt-disable",
+},
+.cpuid = {
+.eax = 0x14,
+.needs_ecx = true, .ecx = 0,
+.reg = R_EBX,
+},
+},
+
[FEAT_14_0_ECX] = {
.type = CPUID_FEATURE_WORD,
.feat_names = {
-NULL, NULL, NULL, NULL,
-NULL, NULL, NULL, NULL,
-NULL, NULL, NULL, NULL,
-NULL, NULL, NULL, NULL,
-NULL, NULL, NULL, NULL,
-NULL, NULL, NULL, NULL,
-NULL, NULL, NULL, NULL,
-NULL, NULL, NULL, "intel-pt-lip",
+[0] = "intel-pt-topa",
+[1] = "intel-pt-multi-topa-entries",
+[2] = "intel-pt-single-range",
+[3] = "intel-pt-trace-transport-subsystem",
+[31] = "intel-pt-lip",
},
.cpuid = {
.eax = 0x14,
@@ -1228,6 +1245,79 @@ FeatureWordInfo feature_word_info[FEATURE_WORDS] = {
.tcg_features = TCG_14_0_ECX_FEATURES,
},
+[FEAT_14_1_EAX] = {
+.type = CPUID_FEATURE_WORD,
+.feat_names = {
+[0] = "intel-pt-addr-range-num-bit0",
+[1] = "intel-pt-addr-range-num-bit1",
+[2] = "intel-pt-addr-range-num-bit2",
+[16] = "intel-pt-mtc-period-encoding-0",
+[17] = "intel-pt-mtc-period-encoding-1",
+[18] = "intel-pt-mtc-period-encoding-2",
+[19] = "intel-pt-mtc-period-encoding-3",
+[20] = "intel-pt-mtc-period-encoding-4",
+[21] = "intel-pt-mtc-period-encoding-5",
+[22] = "intel-pt-mtc-period-encoding-6",
+[23] = "intel-pt-mtc-period-encoding-7",
+[24] = "intel-pt-mtc-period-encoding-8",
+[25] = "intel-pt-mtc-period-encoding-9",
+[26] = "intel-pt-mtc-period-encoding-10",
+[27] = "intel-pt-mtc-period-encoding-11",
+[28] = "intel-pt-mtc-period-encoding-12",
+[29] = "intel-pt-mtc-period-encoding-13",
+[30] = "intel-pt-mtc-period-encoding-14",
+[31] = "intel-pt-mtc-period-encoding-15",
+},
+.cpuid = {
+.eax = 0x14,
+.needs_ecx = true, .ecx = 1,
+.reg = R_EAX,
+},
+},
+
+[FEAT_14_1_EBX] = {
+.type = CPUID_FEATURE_WORD,
+.feat_names = {
+[0] = "intel-pt-cyc-thresh-0",
+[1] = "intel-pt-cyc-thresh-1",
+[2] = "intel-pt-cyc-thresh-2",
+[3] = "intel-pt-cyc-thresh-4",
+[4] = "intel-pt-cyc-thresh-8",
+[5] = "intel-pt-cyc-thresh-16",
+[6] = "intel-pt-cyc-thresh-32",
+[7] = "intel-pt-cyc-thresh-64",
+[8] = "intel-pt-cyc-thresh-128",
+[9] = "intel-pt-cyc-thresh-256",
+[10] = "intel-pt-cyc-thresh-512",
+[11] = "intel-pt-cyc-thresh-1024",
+[12] = "intel-pt-cyc-thresh-2048",
+[13] = "intel-pt-cyc-thresh-4096",
+[14] = "intel-pt-cyc-thresh-8192",
+[15] = "intel-pt-cyc-thresh-16384",
+[16] = "intel-pt-psb-freq-2k",
+[17] = "intel-pt-psb-freq-4k",
+[18] = "intel-pt-psb-freq-8k",
+[19] = "intel-pt-psb-freq-16k",
+[20] = "intel-pt-psb-freq-32k",
+[21] = "intel-pt-psb-freq-64k",
+[22] = "intel-pt-psb-freq-128k",
+[23] = "intel-pt-psb-freq-256k",
+[24] = "intel-pt-psb-freq-512k",
+[25] = "intel-pt-psb-freq-1m",
+[26] = "intel-pt-psb-freq-2m",
+[27] = "intel-pt-psb-freq-4m",
+[28] = "intel-pt-psb-freq-8m",
+[29] = "intel-pt-psb-freq-16m",
+[30] = "intel-pt-psb-freq-32m",
+[31] = "intel-pt-psb-freq-64m",
+},
+
[PATCH v3 2/8] target/i386/intel-pt: Fix INTEL_PT_ADDR_RANGES_NUM_MASK
Per Intel SDM, bits 2:0 of CPUID(0x14,0x1).EAX indicate the number of
address ranges for INTEL-PT.
Signed-off-by: Xiaoyao Li
---
target/i386/cpu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index 8d95202f6a42..9ae36639d380 100644
--- a/target/i386/cpu.c
+++ b/target/i386/cpu.c
@@ -570,7 +570,7 @@ static CPUCacheInfo legacy_l3_cache = {
/* generated packets which contain IP payloads have LIP values */
#define INTEL_PT_IP_LIP (1 << 31)
#define INTEL_PT_ADDR_RANGES_NUM 0x2 /* Number of configurable address ranges
*/
-#define INTEL_PT_ADDR_RANGES_NUM_MASK 0x3
+#define INTEL_PT_ADDR_RANGES_NUM_MASK 0x7
#define INTEL_PT_MTC_BITMAP (0x0249 << 16) /* Support ART(0,3,6,9) */
#define INTEL_PT_CYCLE_BITMAP0x1fff /* Support 0,2^(0~11) */
#define INTEL_PT_PSB_BITMAP (0x003f << 16) /* Support
2K,4K,8K,16K,32K,64K */
--
2.27.0
[PATCH v3 6/8] target/i386/intel-pt: Enable host pass through of Intel PT
commit e37a5c7fa459 ("i386: Add Intel Processor Trace feature support")
added the support of Intel PT by making CPUID[14] of PT as fixed feature
set (from ICX) for any CPU model on any host. This truly breaks the PT
exposure on Intel SPR platform because SPR has less supported bitmap of
CPUID(0x14,1):EBX[15:0] than ICX.
To fix the problem, enable pass through of host's PT capabilities for
the cases "-cpu host/max" that it won't use default fixed PT feature set
of ICX but expand automatically based on get_supported_cpuid reported by
host. Meanwhile, it needs to ensure named CPU model still has the fixed
PT feature set to not break the live migration case of
"-cpu named_cpu_model,+intel-pt"
Introduces env->use_default_intel_pt flag.
- True means it's old CPU model that uses fixed PT feature set of ICX.
- False means the named CPU model has its own PT feature set.
Besides, to keep the same behavior for old CPU models that validate PT
feature set against default fixed PT feature set of ICX in addition to
validate from host's capabilities (via get_supported_cpuid) in
x86_cpu_filter_features().
In the future, new named CPU model, e.g., Sapphire Rapids, can define
its own PT feature set by setting @has_specific_intel_pt_feature_set to
true and defines it's own FEAT_14_0_EBX, FEAT_14_0_ECX, FEAT_14_1_EAX
and FEAT_14_1_EBX.
Signed-off-by: Xiaoyao Li
---
target/i386/cpu.c | 71 ++-
target/i386/cpu.h | 1 +
2 files changed, 40 insertions(+), 32 deletions(-)
diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index e302cbbebfc5..24f3c7b06698 100644
--- a/target/i386/cpu.c
+++ b/target/i386/cpu.c
@@ -5194,6 +5194,21 @@ static void x86_cpu_load_model(X86CPU *cpu, X86CPUModel
*model)
env->features[w] = def->features[w];
}
+/*
+ * All (old) named CPU models have the same default values for INTEL_PT_*
+ *
+ * Assign the default value here since we don't want to manually copy/paste
+ * it to all entries in builtin_x86_defs.
+ */
+if (!env->features[FEAT_14_0_EBX] && !env->features[FEAT_14_0_ECX] &&
+!env->features[FEAT_14_1_EAX] && !env->features[FEAT_14_1_EBX]) {
+env->use_default_intel_pt = true;
+env->features[FEAT_14_0_EBX] = INTEL_PT_DEFAULT_0_EBX;
+env->features[FEAT_14_0_ECX] = INTEL_PT_DEFAULT_0_ECX;
+env->features[FEAT_14_1_EAX] = INTEL_PT_DEFAULT_1_EAX;
+env->features[FEAT_14_1_EBX] = INTEL_PT_DEFAULT_1_EBX;
+}
+
/* legacy-cache defaults to 'off' if CPU model provides cache info */
cpu->legacy_cache = !def->cache_info;
@@ -5716,14 +5731,11 @@ void cpu_x86_cpuid(CPUX86State *env, uint32_t index,
uint32_t count,
if (count == 0) {
*eax = INTEL_PT_MAX_SUBLEAF;
-*ebx = INTEL_PT_DEFAULT_0_EBX;
-*ecx = INTEL_PT_DEFAULT_0_ECX;
-if (env->features[FEAT_14_0_ECX] & CPUID_14_0_ECX_LIP) {
-*ecx |= CPUID_14_0_ECX_LIP;
-}
+*ebx = env->features[FEAT_14_0_EBX];
+*ecx = env->features[FEAT_14_0_ECX];
} else if (count == 1) {
-*eax = INTEL_PT_DEFAULT_1_EAX;
-*ebx = INTEL_PT_DEFAULT_1_EBX;
+*eax = env->features[FEAT_14_1_EAX];
+*ebx = env->features[FEAT_14_1_EBX];
}
break;
}
@@ -6425,6 +6437,7 @@ static void x86_cpu_filter_features(X86CPU *cpu, bool
verbose)
CPUX86State *env = >env;
FeatureWord w;
const char *prefix = NULL;
+uint64_t host_feat;
if (verbose) {
prefix = accel_uses_host_cpuid()
@@ -6433,8 +6446,7 @@ static void x86_cpu_filter_features(X86CPU *cpu, bool
verbose)
}
for (w = 0; w < FEATURE_WORDS; w++) {
-uint64_t host_feat =
-x86_cpu_get_supported_feature_word(w, false);
+host_feat = x86_cpu_get_supported_feature_word(w, false);
uint64_t requested_features = env->features[w];
uint64_t unavailable_features;
@@ -6458,31 +6470,26 @@ static void x86_cpu_filter_features(X86CPU *cpu, bool
verbose)
mark_unavailable_features(cpu, w, unavailable_features, prefix);
}
-if ((env->features[FEAT_7_0_EBX] & CPUID_7_0_EBX_INTEL_PT) &&
-kvm_enabled()) {
-KVMState *s = CPU(cpu)->kvm_state;
-uint32_t eax_0 = kvm_arch_get_supported_cpuid(s, 0x14, 0, R_EAX);
-uint32_t ebx_0 = kvm_arch_get_supported_cpuid(s, 0x14, 0, R_EBX);
-uint32_t ecx_0 = kvm_arch_get_supported_cpuid(s, 0x14, 0, R_ECX);
-uint32_t eax_1 = kvm_arch_get_supported_cpuid(s, 0x14, 1, R_EAX);
-uint32_t ebx_1 = kvm_arch_get_supported_cpuid(s, 0x14, 1, R_EBX);
-
-if (!eax_0 ||
- ((ebx_0 & INTEL_PT_DEFAULT_0_EBX) != INTEL_PT_DEFAULT_0_EBX) ||
- ((ecx_0 & INTEL_PT_DEFAULT_0_ECX) != INTEL_PT_DEFAULT_0_ECX) ||
- ((eax_1 & INTEL_PT_DEFAULT_MTC_BITMAP) !=
INTEL_PT_DEFAULT_MTC_BITMAP) ||
- ((eax_1 &
[PATCH v3 5/8] target/i386/intel-pt: Rework/rename the default INTEL-PT feature set
Historically the Intel PT feature set reported from ICX silicon
was chosen as the fixed feature set for Intel PT. If want to enable
and expose INTEL-PT to guest, the supported Intel PT reported by host
must cover the fixed feature set, which are named with MINIMAL in
INTEL_PT_MINIMAL_EBX and INTEL_PT_MINIMAL_ECX. However, it's not
accurate that it's more as default than minimal since SPR has less
capabilities regarding CPUID(0x14,1):EBX[15:0].
Rename the feature set name to avoid future confusion and
opportunistically define each feature bit.
No functional change intended.
Signed-off-by: Xiaoyao Li
---
target/i386/cpu.c | 70 ++-
target/i386/cpu.h | 34 ++-
2 files changed, 65 insertions(+), 39 deletions(-)
diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index 4d7beccc0af7..e302cbbebfc5 100644
--- a/target/i386/cpu.c
+++ b/target/i386/cpu.c
@@ -546,34 +546,29 @@ static CPUCacheInfo legacy_l3_cache = {
#define L2_ITLB_4K_ASSOC 4
#define L2_ITLB_4K_ENTRIES 512
-/* CPUID Leaf 0x14 constants: */
-#define INTEL_PT_MAX_SUBLEAF 0x1
-/*
- * bit[00]: IA32_RTIT_CTL.CR3 filter can be set to 1 and IA32_RTIT_CR3_MATCH
- * MSR can be accessed;
- * bit[01]: Support Configurable PSB and Cycle-Accurate Mode;
- * bit[02]: Support IP Filtering, TraceStop filtering, and preservation
- * of Intel PT MSRs across warm reset;
- * bit[03]: Support MTC timing packet and suppression of COFI-based packets;
- */
-#define INTEL_PT_MINIMAL_EBX 0xf
-/*
- * bit[00]: Tracing can be enabled with IA32_RTIT_CTL.ToPA = 1 and
- * IA32_RTIT_OUTPUT_BASE and IA32_RTIT_OUTPUT_MASK_PTRS MSRs can be
- * accessed;
- * bit[01]: ToPA tables can hold any number of output entries, up to the
- * maximum allowed by the MaskOrTableOffset field of
- * IA32_RTIT_OUTPUT_MASK_PTRS;
- * bit[02]: Support Single-Range Output scheme;
- */
-#define INTEL_PT_MINIMAL_ECX 0x7
-/* generated packets which contain IP payloads have LIP values */
-#define INTEL_PT_IP_LIP (1 << 31)
-#define INTEL_PT_ADDR_RANGES_NUM 0x2 /* Number of configurable address ranges
*/
-#define INTEL_PT_ADDR_RANGES_NUM_MASK 0x7
-#define INTEL_PT_MTC_BITMAP (0x0249 << 16) /* Support ART(0,3,6,9) */
-#define INTEL_PT_CYCLE_BITMAP0x1fff /* Support 0,2^(0~11) */
-#define INTEL_PT_PSB_BITMAP (0x003f << 16) /* Support
2K,4K,8K,16K,32K,64K */
+/* INTEL PT definitions: */
+
+#define INTEL_PT_MAX_SUBLEAF0x1
+
+#define INTEL_PT_ADDR_RANGES_NUM_MASK 0x7
+#define INTEL_PT_DEFAULT_ADDR_RANGES_NUM0x2
+
+/* Support ART(0,3,6,9) */
+#define INTEL_PT_DEFAULT_MTC_BITMAP (0x0249 << 16)
+/* Support 0,2^(0~11) */
+#define INTEL_PT_DEFAULT_CYCLE_BITMAP 0x1fff
+/* Support 2K,4K,8K,16K,32K,64K */
+#define INTEL_PT_DEFAULT_PSB_BITMAP (0x003f << 16)
+
+#define INTEL_PT_DEFAULT_0_EBX (CPUID_14_0_EBX_CR3_FILTER |
CPUID_14_0_EBX_PSB | \
+ CPUID_14_0_EBX_IP_FILTER | CPUID_14_0_EBX_MTC)
+
+#define INTEL_PT_DEFAULT_0_ECX (CPUID_14_0_ECX_TOPA |
CPUID_14_0_ECX_MULTI_ENTRIES | \
+ CPUID_14_0_ECX_SINGLE_RANGE)
+
+#define INTEL_PT_DEFAULT_1_EAX (INTEL_PT_DEFAULT_MTC_BITMAP |
INTEL_PT_DEFAULT_ADDR_RANGES_NUM)
+
+#define INTEL_PT_DEFAULT_1_EBX (INTEL_PT_DEFAULT_PSB_BITMAP |
INTEL_PT_DEFAULT_CYCLE_BITMAP)
/* CPUID Leaf 0x1D constants: */
#define INTEL_AMX_TILE_MAX_SUBLEAF 0x1
@@ -5721,14 +5716,14 @@ void cpu_x86_cpuid(CPUX86State *env, uint32_t index,
uint32_t count,
if (count == 0) {
*eax = INTEL_PT_MAX_SUBLEAF;
-*ebx = INTEL_PT_MINIMAL_EBX;
-*ecx = INTEL_PT_MINIMAL_ECX;
+*ebx = INTEL_PT_DEFAULT_0_EBX;
+*ecx = INTEL_PT_DEFAULT_0_ECX;
if (env->features[FEAT_14_0_ECX] & CPUID_14_0_ECX_LIP) {
*ecx |= CPUID_14_0_ECX_LIP;
}
} else if (count == 1) {
-*eax = INTEL_PT_MTC_BITMAP | INTEL_PT_ADDR_RANGES_NUM;
-*ebx = INTEL_PT_PSB_BITMAP | INTEL_PT_CYCLE_BITMAP;
+*eax = INTEL_PT_DEFAULT_1_EAX;
+*ebx = INTEL_PT_DEFAULT_1_EBX;
}
break;
}
@@ -6473,13 +6468,12 @@ static void x86_cpu_filter_features(X86CPU *cpu, bool
verbose)
uint32_t ebx_1 = kvm_arch_get_supported_cpuid(s, 0x14, 1, R_EBX);
if (!eax_0 ||
- ((ebx_0 & INTEL_PT_MINIMAL_EBX) != INTEL_PT_MINIMAL_EBX) ||
- ((ecx_0 & INTEL_PT_MINIMAL_ECX) != INTEL_PT_MINIMAL_ECX) ||
- ((eax_1 & INTEL_PT_MTC_BITMAP) != INTEL_PT_MTC_BITMAP) ||
+ ((ebx_0 & INTEL_PT_DEFAULT_0_EBX) != INTEL_PT_DEFAULT_0_EBX) ||
+ ((ecx_0 & INTEL_PT_DEFAULT_0_ECX) != INTEL_PT_DEFAULT_0_ECX) ||
+ ((eax_1 & INTEL_PT_DEFAULT_MTC_BITMAP) !=
INTEL_PT_DEFAULT_MTC_BITMAP) ||
((eax_1 & INTEL_PT_ADDR_RANGES_NUM_MASK) <
-
[PATCH v3 4/8] target/i386/intel-pt: print special message for INTEL_PT_ADDR_RANGES_NUM
Bit[2:0] of CPUID.14H_01H:EAX stands as a whole for the number of INTEL
PT ADDR RANGES. For unsupported value that exceeds what KVM reports,
report it as a whole in mark_unavailable_features() as well.
Signed-off-by: Xiaoyao Li
---
target/i386/cpu.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index 65c6f8ae771a..4d7beccc0af7 100644
--- a/target/i386/cpu.c
+++ b/target/i386/cpu.c
@@ -4387,7 +4387,14 @@ static void mark_unavailable_features(X86CPU *cpu,
FeatureWord w, uint64_t mask,
return;
}
-for (i = 0; i < 64; ++i) {
+if ((w == FEAT_14_1_EAX) && (mask & INTEL_PT_ADDR_RANGES_NUM_MASK)) {
+warn_report("%s: CPUID.14H_01H:EAX [bit 2:0]", verbose_prefix);
+i = 3;
+} else {
+i = 0;
+}
+
+for (; i < 64; ++i) {
if ((1ULL << i) & mask) {
g_autofree char *feat_word_str = feature_word_description(f, i);
warn_report("%s: %s%s%s [bit %d]",
--
2.27.0
[PATCH v3 8/8] target/i386/intel-pt: Access MSR_IA32_RTIT_ADDRn based on guest CPUID configuration
KVM only allows userspace to access legal number of MSR_IA32_RTIT_ADDRn,
which is enumrated by guest's CPUID(0x14,0x1):EAX[2:0], i.e.,
env->features[FEAT_14_1_EAX] & INTEL_PT_ADDR_RANGES_NUM_MASK
Signed-off-by: Xiaoyao Li
---
target/i386/cpu.h | 2 ++
target/i386/kvm/kvm.c | 8
2 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/target/i386/cpu.h b/target/i386/cpu.h
index 91a3971c1c29..1156813ed0ad 100644
--- a/target/i386/cpu.h
+++ b/target/i386/cpu.h
@@ -941,6 +941,8 @@ uint64_t x86_cpu_get_supported_feature_word(FeatureWord w,
/* Packets which contain IP payload have LIP values */
#define CPUID_14_0_ECX_LIP (1U << 31)
+#define INTEL_PT_ADDR_RANGES_NUM_MASK 0x7
+
/* CLZERO instruction */
#define CPUID_8000_0008_EBX_CLZERO (1U << 0)
/* Always save/restore FP error pointers */
diff --git a/target/i386/kvm/kvm.c b/target/i386/kvm/kvm.c
index a21320937943..e06a25f5e3ee 100644
--- a/target/i386/kvm/kvm.c
+++ b/target/i386/kvm/kvm.c
@@ -3446,8 +3446,8 @@ static int kvm_put_msrs(X86CPU *cpu, int level)
}
}
if (env->features[FEAT_7_0_EBX] & CPUID_7_0_EBX_INTEL_PT) {
-int addr_num = kvm_arch_get_supported_cpuid(kvm_state,
-0x14, 1, R_EAX) & 0x7;
+int addr_num = env->features[FEAT_14_1_EAX] &
+ INTEL_PT_ADDR_RANGES_NUM_MASK;
kvm_msr_entry_add(cpu, MSR_IA32_RTIT_CTL,
env->msr_rtit_ctrl);
@@ -3889,8 +3889,8 @@ static int kvm_get_msrs(X86CPU *cpu)
}
if (env->features[FEAT_7_0_EBX] & CPUID_7_0_EBX_INTEL_PT) {
-int addr_num =
-kvm_arch_get_supported_cpuid(kvm_state, 0x14, 1, R_EAX) & 0x7;
+int addr_num = env->features[FEAT_14_1_EAX] &
+ INTEL_PT_ADDR_RANGES_NUM_MASK;
kvm_msr_entry_add(cpu, MSR_IA32_RTIT_CTL, 0);
kvm_msr_entry_add(cpu, MSR_IA32_RTIT_STATUS, 0);
--
2.27.0
[PATCH v3 1/8] target/i386: Print CPUID subleaf info for unsupported feature
Some CPUID leaves have meaningful subleaf index. Print the subleaf info
in feature_word_description for CPUID features.
Signed-off-by: Xiaoyao Li
Reviewed-by: Eduardo Habkost
---
target/i386/cpu.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index 22b681ca37dd..8d95202f6a42 100644
--- a/target/i386/cpu.c
+++ b/target/i386/cpu.c
@@ -4244,8 +4244,9 @@ static char *feature_word_description(FeatureWordInfo *f,
uint32_t bit)
{
const char *reg = get_register_name_32(f->cpuid.reg);
assert(reg);
-return g_strdup_printf("CPUID.%02XH:%s",
- f->cpuid.eax, reg);
+return g_strdup_printf("CPUID.%02XH_%02XH:%s",
+ f->cpuid.eax,
+ f->cpuid.needs_ecx ? f->cpuid.ecx : 0, reg);
}
case MSR_FEATURE_WORD:
return g_strdup_printf("MSR(%02XH)",
--
2.27.0
Re: [PATCH 2/2] target/riscv: Clear mstatus.MPRV when leaving M-mode for priv spec 1.12+
On Wed, Dec 7, 2022 at 7:11 PM Bin Meng wrote:
>
> Since priv spec v1.12, MRET and SRET now clear mstatus.MPRV when
> leaving M-mode.
>
> Signed-off-by: Bin Meng
Thanks!
Applied to riscv-to-apply.next
Alistair
>
> ---
>
> target/riscv/op_helper.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/target/riscv/op_helper.c b/target/riscv/op_helper.c
> index a047d38152..878bcb03b8 100644
> --- a/target/riscv/op_helper.c
> +++ b/target/riscv/op_helper.c
> @@ -154,6 +154,9 @@ target_ulong helper_sret(CPURISCVState *env)
> get_field(mstatus, MSTATUS_SPIE));
> mstatus = set_field(mstatus, MSTATUS_SPIE, 1);
> mstatus = set_field(mstatus, MSTATUS_SPP, PRV_U);
> +if (env->priv_ver >= PRIV_VERSION_1_12_0) {
> +mstatus = set_field(mstatus, MSTATUS_MPRV, 0);
> +}
> env->mstatus = mstatus;
>
> if (riscv_has_ext(env, RVH) && !riscv_cpu_virt_enabled(env)) {
> @@ -203,6 +206,9 @@ target_ulong helper_mret(CPURISCVState *env)
> mstatus = set_field(mstatus, MSTATUS_MPIE, 1);
> mstatus = set_field(mstatus, MSTATUS_MPP, PRV_U);
> mstatus = set_field(mstatus, MSTATUS_MPV, 0);
> +if ((env->priv_ver >= PRIV_VERSION_1_12_0) && (prev_priv != PRV_M)) {
> +mstatus = set_field(mstatus, MSTATUS_MPRV, 0);
> +}
> env->mstatus = mstatus;
> riscv_cpu_set_mode(env, prev_priv);
>
> --
> 2.34.1
>
>
Re: [PATCH v2 08/16] hw/intc: sifive_plic: Use error_setg() to propagate the error up via errp in sifive_plic_realize()
On Wed, Dec 7, 2022 at 8:06 PM Bin Meng wrote:
>
> The realize() callback has an errp for us to propagate the error up.
> While we are here, corret the wrong multi-line comment format.
>
> Signed-off-by: Bin Meng
Reviewed-by: Alistair Francis
Alistair
>
> ---
>
> Changes in v2:
> - new patch: "hw/intc: sifive_plic: Use error_setg() to propagate the error
> up via errp in sifive_plic_realize()"
>
> hw/intc/sifive_plic.c | 7 ---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/hw/intc/sifive_plic.c b/hw/intc/sifive_plic.c
> index c9af94a888..9cb4c6d6d4 100644
> --- a/hw/intc/sifive_plic.c
> +++ b/hw/intc/sifive_plic.c
> @@ -379,7 +379,8 @@ static void sifive_plic_realize(DeviceState *dev, Error
> **errp)
> s->m_external_irqs = g_malloc(sizeof(qemu_irq) * s->num_harts);
> qdev_init_gpio_out(dev, s->m_external_irqs, s->num_harts);
>
> -/* We can't allow the supervisor to control SEIP as this would allow the
> +/*
> + * We can't allow the supervisor to control SEIP as this would allow the
> * supervisor to clear a pending external interrupt which will result in
> * lost a interrupt in the case a PLIC is attached. The SEIP bit must be
> * hardware controlled when a PLIC is attached.
> @@ -387,8 +388,8 @@ static void sifive_plic_realize(DeviceState *dev, Error
> **errp)
> for (i = 0; i < s->num_harts; i++) {
> RISCVCPU *cpu = RISCV_CPU(qemu_get_cpu(s->hartid_base + i));
> if (riscv_cpu_claim_interrupts(cpu, MIP_SEIP) < 0) {
> -error_report("SEIP already claimed");
> -exit(1);
> +error_setg(errp, "SEIP already claimed");
> +return;
> }
> }
>
> --
> 2.34.1
>
>
Re: [PATCH 2/2] target/riscv: Clear mstatus.MPRV when leaving M-mode for priv spec 1.12+
On Wed, Dec 7, 2022 at 7:11 PM Bin Meng wrote:
>
> Since priv spec v1.12, MRET and SRET now clear mstatus.MPRV when
> leaving M-mode.
>
> Signed-off-by: Bin Meng
Reviewed-by: Alistair Francis
Alistair
>
> ---
>
> target/riscv/op_helper.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/target/riscv/op_helper.c b/target/riscv/op_helper.c
> index a047d38152..878bcb03b8 100644
> --- a/target/riscv/op_helper.c
> +++ b/target/riscv/op_helper.c
> @@ -154,6 +154,9 @@ target_ulong helper_sret(CPURISCVState *env)
> get_field(mstatus, MSTATUS_SPIE));
> mstatus = set_field(mstatus, MSTATUS_SPIE, 1);
> mstatus = set_field(mstatus, MSTATUS_SPP, PRV_U);
> +if (env->priv_ver >= PRIV_VERSION_1_12_0) {
> +mstatus = set_field(mstatus, MSTATUS_MPRV, 0);
> +}
> env->mstatus = mstatus;
>
> if (riscv_has_ext(env, RVH) && !riscv_cpu_virt_enabled(env)) {
> @@ -203,6 +206,9 @@ target_ulong helper_mret(CPURISCVState *env)
> mstatus = set_field(mstatus, MSTATUS_MPIE, 1);
> mstatus = set_field(mstatus, MSTATUS_MPP, PRV_U);
> mstatus = set_field(mstatus, MSTATUS_MPV, 0);
> +if ((env->priv_ver >= PRIV_VERSION_1_12_0) && (prev_priv != PRV_M)) {
> +mstatus = set_field(mstatus, MSTATUS_MPRV, 0);
> +}
> env->mstatus = mstatus;
> riscv_cpu_set_mode(env, prev_priv);
>
> --
> 2.34.1
>
>
Re: [PATCH 1/2] target/riscv: Simplify helper_sret() a little bit
On Wed, Dec 7, 2022 at 7:05 PM Bin Meng wrote:
>
> There are 2 paths in helper_sret() and the same mstatus update codes
> are replicated. Extract the common parts to simplify it a little bit.
>
> Signed-off-by: Bin Meng
Reviewed-by: Alistair Francis
Alistair
> ---
>
> target/riscv/op_helper.c | 20 ++--
> 1 file changed, 6 insertions(+), 14 deletions(-)
>
> diff --git a/target/riscv/op_helper.c b/target/riscv/op_helper.c
> index d7af7f056b..a047d38152 100644
> --- a/target/riscv/op_helper.c
> +++ b/target/riscv/op_helper.c
> @@ -149,21 +149,21 @@ target_ulong helper_sret(CPURISCVState *env)
> }
>
> mstatus = env->mstatus;
> +prev_priv = get_field(mstatus, MSTATUS_SPP);
> +mstatus = set_field(mstatus, MSTATUS_SIE,
> +get_field(mstatus, MSTATUS_SPIE));
> +mstatus = set_field(mstatus, MSTATUS_SPIE, 1);
> +mstatus = set_field(mstatus, MSTATUS_SPP, PRV_U);
> +env->mstatus = mstatus;
>
> if (riscv_has_ext(env, RVH) && !riscv_cpu_virt_enabled(env)) {
> /* We support Hypervisor extensions and virtulisation is disabled */
> target_ulong hstatus = env->hstatus;
>
> -prev_priv = get_field(mstatus, MSTATUS_SPP);
> prev_virt = get_field(hstatus, HSTATUS_SPV);
>
> hstatus = set_field(hstatus, HSTATUS_SPV, 0);
> -mstatus = set_field(mstatus, MSTATUS_SPP, 0);
> -mstatus = set_field(mstatus, SSTATUS_SIE,
> -get_field(mstatus, SSTATUS_SPIE));
> -mstatus = set_field(mstatus, SSTATUS_SPIE, 1);
>
> -env->mstatus = mstatus;
> env->hstatus = hstatus;
>
> if (prev_virt) {
> @@ -171,14 +171,6 @@ target_ulong helper_sret(CPURISCVState *env)
> }
>
> riscv_cpu_set_virt_enabled(env, prev_virt);
> -} else {
> -prev_priv = get_field(mstatus, MSTATUS_SPP);
> -
> -mstatus = set_field(mstatus, MSTATUS_SIE,
> -get_field(mstatus, MSTATUS_SPIE));
> -mstatus = set_field(mstatus, MSTATUS_SPIE, 1);
> -mstatus = set_field(mstatus, MSTATUS_SPP, PRV_U);
> -env->mstatus = mstatus;
> }
>
> riscv_cpu_set_mode(env, prev_priv);
> --
> 2.34.1
>
>
Re: [PATCH v2 2/5] target/riscv: Update VS timer whenever htimedelta changes
On Tue, Nov 8, 2022 at 11:07 PM Anup Patel wrote:
>
> The htimedelta[h] CSR has impact on the VS timer comparison so we
> should call riscv_timer_write_timecmp() whenever htimedelta changes.
>
> Fixes: 3ec0fe18a31f ("target/riscv: Add vstimecmp suppor")
> Signed-off-by: Anup Patel
> Reviewed-by: Alistair Francis
This patch breaks my Xvisor test. When running OpenSBI and Xvisor like this:
qemu-system-riscv64 -machine virt \
-m 1G -serial mon:stdio -serial null -nographic \
-append 'vmm.console=uart@1000 vmm.bootcmd="vfs mount initrd
/;vfs run /boot.xscript;vfs cat /system/banner.txt; guest kick guest0;
vserial bind guest0/uart0"' \
-smp 4 -d guest_errors \
-bios none \
-device loader,file=./images/qemuriscv64/vmm.bin,addr=0x8020 \
-kernel ./images/qemuriscv64/fw_jump.elf \
-initrd ./images/qemuriscv64/vmm-disk-linux.img -cpu rv64,h=true
Running:
Xvisor v0.3.0-129-gbc33f339 (Jan 1 1970 00:00:00)
I see this failure:
INIT: bootcmd: guest kick guest0
guest0: Kicked
INIT: bootcmd: vserial bind guest0/uart0
[guest0/uart0] cpu_vcpu_stage2_map: guest_phys=0x3B9AC000
size=0x4096 map failed
do_error: CPU3: VCPU=guest0/vcpu0 page fault failed (error -1)
zero=0x ra=0x80001B4E
sp=0x8001CF80 gp=0x
tp=0x s0=0x8001CFB0
s1=0x a0=0x10001048
a1=0x a2=0x00989680
a3=0x3B9ACA00 a4=0x0048
a5=0x a6=0x00019000
a7=0x s2=0x
s3=0x s4=0x
s5=0x s6=0x
s7=0x s8=0x
s9=0x s10=0x
s11=0x t0=0x4000
t1=0x0100 t2=0x
t3=0x t4=0x
t5=0x t6=0x
sepc=0x80001918 sstatus=0x00024120
hstatus=0x0002002001C0 sp_exec=0x10A64000
scause=0x0017 stval=0x3B9ACAF8
htval=0x0EE6B2BE htinst=0x00D03021
I have tried updating to a newer Xvisor release, but with that I don't
get any serial output.
Can you help get the Xvisor tests back up and running?
Alistair
[ANNOUNCE] QEMU 7.2.0-rc4 is now available
Hello, On behalf of the QEMU Team, I'd like to announce the availability of the fifth and final planned release candidate for the QEMU 7.2 release. This release is meant for testing purposes and should not be used in a production environment. http://download.qemu-project.org/qemu-7.2.0-rc4.tar.xz http://download.qemu-project.org/qemu-7.2.0-rc4.tar.xz.sig You can help improve the quality of the QEMU 7.2 release by testing this release and reporting bugs using our GitLab issue tracker: https://gitlab.com/qemu-project/qemu/-/milestones/7#tab-issues The release plan, as well a documented known issues for release candidates, are available at: http://wiki.qemu.org/Planning/7.2 Please add entries to the ChangeLog for the 7.2 release below: http://wiki.qemu.org/ChangeLog/7.2 Thank you to everyone involved! Changes since rc3: ea3a008d2d: Update VERSION for v7.2.0-rc4 (Stefan Hajnoczi) edc93f455f: Revert "hw/loongarch/virt: Add cfi01 pflash device" (Song Gao) c1966f515d: hw/display/next-fb: Fix comment typo (Evgeny Ermakov) 21be74a9a5: target/s390x/tcg: Fix and improve the SACF instruction (Thomas Huth) 0f0a9e4e5c: tests/qtest/migration-test: Fix unlink error and memory leaks (Thomas Huth) 14dccc8ea6: hw/loongarch/virt: Add cfi01 pflash device (Xiaojuan Yang) 8218c048be: target/i386: Always completely initialize TranslateFault (Richard Henderson) 38e65936a8: target/i386: allow MMX instructions with CR4.OSFXSR=0 (Paolo Bonzini) 83f56ac321: hw/nvme: remove copy bh scheduling (Klaus Jensen) 818b9b8f5e: hw/nvme: fix aio cancel in dsm (Klaus Jensen) 36a251c346: hw/nvme: fix aio cancel in zone reset (Klaus Jensen) 3dbc1708ea: hw/nvme: fix aio cancel in flush (Klaus Jensen) 433c71e494: hw/nvme: fix aio cancel in format (Klaus Jensen) 4987e5bf2e: include/hw: VM state takes precedence in virtio_device_should_start (Alex Bennée) 71e076a07d: hw/virtio: generalise CHR_EVENT_CLOSED handling (Alex Bennée) 060f4a9440: hw/virtio: add started_vu status field to vhost-user-gpio (Alex Bennée) 4daa5054c5: vhost: enable vrings in vhost_dev_start() for vhost-user devices (Stefano Garzarella) 523e40022f: tests/qtests: override "force-legacy" for gpio virtio-mmio tests (Alex Bennée)
Re: [PATCH v10 8/9] KVM: Handle page fault for private memory
On Fri, Dec 02, 2022 at 02:13:46PM +0800, Chao Peng wrote:
> A KVM_MEM_PRIVATE memslot can include both fd-based private memory and
> hva-based shared memory. Architecture code (like TDX code) can tell
> whether the on-going fault is private or not. This patch adds a
> 'is_private' field to kvm_page_fault to indicate this and architecture
> code is expected to set it.
>
> To handle page fault for such memslot, the handling logic is different
> depending on whether the fault is private or shared. KVM checks if
> 'is_private' matches the host's view of the page (maintained in
> mem_attr_array).
> - For a successful match, private pfn is obtained with
> restrictedmem_get_page() and shared pfn is obtained with existing
> get_user_pages().
> - For a failed match, KVM causes a KVM_EXIT_MEMORY_FAULT exit to
> userspace. Userspace then can convert memory between private/shared
> in host's view and retry the fault.
>
> Co-developed-by: Yu Zhang
> Signed-off-by: Yu Zhang
> Signed-off-by: Chao Peng
> ---
> arch/x86/kvm/mmu/mmu.c | 63 +++--
> arch/x86/kvm/mmu/mmu_internal.h | 14 +++-
> arch/x86/kvm/mmu/mmutrace.h | 1 +
> arch/x86/kvm/mmu/tdp_mmu.c | 2 +-
> include/linux/kvm_host.h| 30
> 5 files changed, 105 insertions(+), 5 deletions(-)
>
> diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c
> index 2190fd8c95c0..b1953ebc012e 100644
> --- a/arch/x86/kvm/mmu/mmu.c
> +++ b/arch/x86/kvm/mmu/mmu.c
> @@ -3058,7 +3058,7 @@ static int host_pfn_mapping_level(struct kvm *kvm,
> gfn_t gfn,
>
> int kvm_mmu_max_mapping_level(struct kvm *kvm,
> const struct kvm_memory_slot *slot, gfn_t gfn,
> - int max_level)
> + int max_level, bool is_private)
> {
> struct kvm_lpage_info *linfo;
> int host_level;
> @@ -3070,6 +3070,9 @@ int kvm_mmu_max_mapping_level(struct kvm *kvm,
> break;
> }
>
> + if (is_private)
> + return max_level;
lpage mixed information already saved, so is that possible
to query info->disallow_lpage without care 'is_private' ?
> +
> if (max_level == PG_LEVEL_4K)
> return PG_LEVEL_4K;
>
> @@ -3098,7 +3101,8 @@ void kvm_mmu_hugepage_adjust(struct kvm_vcpu *vcpu,
> struct kvm_page_fault *fault
>* level, which will be used to do precise, accurate accounting.
>*/
> fault->req_level = kvm_mmu_max_mapping_level(vcpu->kvm, slot,
> - fault->gfn,
> fault->max_level);
> + fault->gfn,
> fault->max_level,
> + fault->is_private);
> if (fault->req_level == PG_LEVEL_4K || fault->huge_page_disallowed)
> return;
>
> @@ -4178,6 +4182,49 @@ void kvm_arch_async_page_ready(struct kvm_vcpu *vcpu,
> struct kvm_async_pf *work)
> kvm_mmu_do_page_fault(vcpu, work->cr2_or_gpa, 0, true);
> }
>
> +static inline u8 order_to_level(int order)
> +{
> + BUILD_BUG_ON(KVM_MAX_HUGEPAGE_LEVEL > PG_LEVEL_1G);
> +
> + if (order >= KVM_HPAGE_GFN_SHIFT(PG_LEVEL_1G))
> + return PG_LEVEL_1G;
> +
> + if (order >= KVM_HPAGE_GFN_SHIFT(PG_LEVEL_2M))
> + return PG_LEVEL_2M;
> +
> + return PG_LEVEL_4K;
> +}
> +
> +static int kvm_do_memory_fault_exit(struct kvm_vcpu *vcpu,
> + struct kvm_page_fault *fault)
> +{
> + vcpu->run->exit_reason = KVM_EXIT_MEMORY_FAULT;
> + if (fault->is_private)
> + vcpu->run->memory.flags = KVM_MEMORY_EXIT_FLAG_PRIVATE;
> + else
> + vcpu->run->memory.flags = 0;
> + vcpu->run->memory.gpa = fault->gfn << PAGE_SHIFT;
> + vcpu->run->memory.size = PAGE_SIZE;
> + return RET_PF_USER;
> +}
> +
> +static int kvm_faultin_pfn_private(struct kvm_vcpu *vcpu,
> +struct kvm_page_fault *fault)
> +{
> + int order;
> + struct kvm_memory_slot *slot = fault->slot;
> +
> + if (!kvm_slot_can_be_private(slot))
> + return kvm_do_memory_fault_exit(vcpu, fault);
> +
> + if (kvm_restricted_mem_get_pfn(slot, fault->gfn, >pfn, ))
> + return RET_PF_RETRY;
> +
> + fault->max_level = min(order_to_level(order), fault->max_level);
> + fault->map_writable = !(slot->flags & KVM_MEM_READONLY);
> + return RET_PF_CONTINUE;
> +}
> +
> static int kvm_faultin_pfn(struct kvm_vcpu *vcpu, struct kvm_page_fault
> *fault)
> {
> struct kvm_memory_slot *slot = fault->slot;
> @@ -4210,6 +4257,12 @@ static int kvm_faultin_pfn(struct kvm_vcpu *vcpu,
> struct kvm_page_fault *fault)
> return RET_PF_EMULATE;
> }
>
> + if (fault->is_private != kvm_mem_is_private(vcpu->kvm, fault->gfn))
> + return kvm_do_memory_fault_exit(vcpu, fault);
> +
> + if (fault->is_private)
> +
Re: [PATCH for 8.0 0/2] virtio-iommu: Fix Replay
Hi, Eric, On Wed, Dec 07, 2022 at 02:36:44PM +0100, Eric Auger wrote: > When assigning VFIO devices protected by a virtio-iommu we need to replay > the mappings when adding a new IOMMU MR and when attaching a device to > a domain. While we do a "remap" we currently fail to first unmap the > existing IOVA mapping and just map the new one. With some device/group > topology this can lead to errors in VFIO when trying to DMA_MAP IOVA > ranges onto existing ones. I'm not sure whether virtio-iommu+vfio will suffer from DMA races like when we were working on the vt-d replay for vfio. The issue is whether DMA can happen right after UNMAP but before MAP of the same page if the page was always mapped. The vt-d resolved it by using iova_tree so in a replay vt-d knows the page didn't change, so it avoids unmap+map. It only notifies newly unmapped or newly mapped. Thanks, -- Peter Xu
[PATCH 1/5] hw/acpi/Kconfig: Add missing dependencies to ACPI_PIIX4
piix4_pm_realize() uses apm_init() and pm_smbus_init(), so both APM and ACPI_SMBUS are provided by the device model managed by ACPI_PIIX4. Signed-off-by: Bernhard Beschow --- configs/devices/mips-softmmu/common.mak | 2 -- hw/acpi/Kconfig | 2 ++ hw/i386/Kconfig | 2 -- 3 files changed, 2 insertions(+), 4 deletions(-) diff --git a/configs/devices/mips-softmmu/common.mak b/configs/devices/mips-softmmu/common.mak index 416161f833..3011304443 100644 --- a/configs/devices/mips-softmmu/common.mak +++ b/configs/devices/mips-softmmu/common.mak @@ -19,7 +19,6 @@ CONFIG_PCKBD=y CONFIG_FDC=y CONFIG_ACPI=y CONFIG_ACPI_PIIX4=y -CONFIG_APM=y CONFIG_I8257=y CONFIG_PIIX4=y CONFIG_IDE_ISA=y @@ -32,6 +31,5 @@ CONFIG_MIPS_ITU=y CONFIG_MALTA=y CONFIG_PCNET_PCI=y CONFIG_MIPSSIM=y -CONFIG_ACPI_SMBUS=y CONFIG_SMBUS_EEPROM=y CONFIG_TEST_DEVICES=y diff --git a/hw/acpi/Kconfig b/hw/acpi/Kconfig index 3703aca212..9504cbad2f 100644 --- a/hw/acpi/Kconfig +++ b/hw/acpi/Kconfig @@ -30,6 +30,8 @@ config ACPI_NVDIMM config ACPI_PIIX4 bool +select ACPI_SMBUS +select APM depends on ACPI config ACPI_PCIHP diff --git a/hw/i386/Kconfig b/hw/i386/Kconfig index d22ac4a4b9..2fdefd7458 100644 --- a/hw/i386/Kconfig +++ b/hw/i386/Kconfig @@ -62,7 +62,6 @@ config PC_ACPI select ACPI_VIOT select SMBUS_EEPROM select PFLASH_CFI01 -depends on ACPI_SMBUS config I440FX bool @@ -71,7 +70,6 @@ config I440FX imply VMMOUSE select PC_PCI select PC_ACPI -select ACPI_SMBUS select PCI_I440FX select PIIX3 select IDE_PIIX -- 2.38.1
[PATCH 5/5] hw/ppc/Kconfig: Remove unused dependencies from PEGASOS2
Removes the following dependencies from ppc-softmmu: - CONFIG_ACPI_CPU_HOTPLUG - CONFIG_ACPI_CXL - CONFIG_ACPI_HMAT - CONFIG_ACPI_MEMORY_HOTPLUG - CONFIG_ACPI_NVDIMM - CONFIG_ACPI_PCIHP - CONFIG_ACPI_PIIX4 - CONFIG_ACPI_X86 - CONFIG_MEM_DEVICE Signed-off-by: Bernhard Beschow --- hw/ppc/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/hw/ppc/Kconfig b/hw/ppc/Kconfig index b8d2522f45..0ab77177a8 100644 --- a/hw/ppc/Kconfig +++ b/hw/ppc/Kconfig @@ -77,7 +77,7 @@ config PEGASOS2 select SMBUS_EEPROM select VOF # This should come with VT82C686 -select ACPI_X86 +select ACPI config PREP bool -- 2.38.1
[PATCH 0/5] Clean up dependencies of ACPI controllers
This small series establishes consistency between ICH9, PIIX4 and VT82C686 ACPI controllers to 1/ depend on ACPI and 2/ to select ACPI_SMBUS and APM since the latter are provided by the device models. Due to the PIIX4 cleanup PEGASOS2's dependency can be reduced to just ACPI, eliminating 9 compilation units from the softmmu-ppc build. Bernhard Beschow (5): hw/acpi/Kconfig: Add missing dependencies to ACPI_PIIX4 hw/acpi/Kconfig: Rename ACPI_X86_ICH to ACPI_ICH9 hw/acpi/Kconfig: Add missing dependencies to ACPI_ICH9 hw/isa/Kconfig: Add missing dependency to VT82C686 hw/ppc/Kconfig: Remove unused dependencies from PEGASOS2 configs/devices/mips-softmmu/common.mak | 2 -- hw/acpi/Kconfig | 6 +- hw/acpi/meson.build | 2 +- hw/i2c/meson.build | 2 +- hw/i386/Kconfig | 3 --- hw/isa/Kconfig | 4 ++-- hw/ppc/Kconfig | 2 +- 7 files changed, 10 insertions(+), 11 deletions(-) -- 2.38.1
[PATCH 2/5] hw/acpi/Kconfig: Rename ACPI_X86_ICH to ACPI_ICH9
Although the ICH9 ACPI controller may currently be tied to x86 it
doesn't have to. Furthermore, the source files this configuration switch
manages contain a '9', so this name fits more.
Signed-off-by: Bernhard Beschow
---
hw/acpi/Kconfig | 2 +-
hw/acpi/meson.build | 2 +-
hw/i2c/meson.build | 2 +-
hw/isa/Kconfig | 2 +-
4 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/hw/acpi/Kconfig b/hw/acpi/Kconfig
index 9504cbad2f..ec16dd20e6 100644
--- a/hw/acpi/Kconfig
+++ b/hw/acpi/Kconfig
@@ -13,7 +13,7 @@ config ACPI_X86
select ACPI_PCIHP
select ACPI_ERST
-config ACPI_X86_ICH
+config ACPI_ICH9
bool
select ACPI_X86
diff --git a/hw/acpi/meson.build b/hw/acpi/meson.build
index f8c820ca94..cfae2f58f6 100644
--- a/hw/acpi/meson.build
+++ b/hw/acpi/meson.build
@@ -22,7 +22,7 @@ acpi_ss.add(when: 'CONFIG_ACPI_PIIX4', if_true:
files('piix4.c'))
acpi_ss.add(when: 'CONFIG_ACPI_PCIHP', if_true: files('pcihp.c'))
acpi_ss.add(when: 'CONFIG_ACPI_PCIHP', if_false:
files('acpi-pci-hotplug-stub.c'))
acpi_ss.add(when: 'CONFIG_ACPI_VIOT', if_true: files('viot.c'))
-acpi_ss.add(when: 'CONFIG_ACPI_X86_ICH', if_true: files('ich9.c', 'tco.c'))
+acpi_ss.add(when: 'CONFIG_ACPI_ICH9', if_true: files('ich9.c', 'tco.c'))
acpi_ss.add(when: 'CONFIG_ACPI_ERST', if_true: files('erst.c'))
acpi_ss.add(when: 'CONFIG_IPMI', if_true: files('ipmi.c'), if_false:
files('ipmi-stub.c'))
acpi_ss.add(when: 'CONFIG_PC', if_false: files('acpi-x86-stub.c'))
diff --git a/hw/i2c/meson.build b/hw/i2c/meson.build
index d3df273251..6e7340aaac 100644
--- a/hw/i2c/meson.build
+++ b/hw/i2c/meson.build
@@ -2,7 +2,7 @@ i2c_ss = ss.source_set()
i2c_ss.add(when: 'CONFIG_I2C', if_true: files('core.c'))
i2c_ss.add(when: 'CONFIG_SMBUS', if_true: files('smbus_slave.c',
'smbus_master.c'))
i2c_ss.add(when: 'CONFIG_ACPI_SMBUS', if_true: files('pm_smbus.c'))
-i2c_ss.add(when: 'CONFIG_ACPI_X86_ICH', if_true: files('smbus_ich9.c'))
+i2c_ss.add(when: 'CONFIG_ACPI_ICH9', if_true: files('smbus_ich9.c'))
i2c_ss.add(when: 'CONFIG_ASPEED_SOC', if_true: files('aspeed_i2c.c'))
i2c_ss.add(when: 'CONFIG_BITBANG_I2C', if_true: files('bitbang_i2c.c'))
i2c_ss.add(when: 'CONFIG_EXYNOS4', if_true: files('exynos4210_i2c.c'))
diff --git a/hw/isa/Kconfig b/hw/isa/Kconfig
index 18b5c6bf3f..01f330d941 100644
--- a/hw/isa/Kconfig
+++ b/hw/isa/Kconfig
@@ -78,4 +78,4 @@ config LPC_ICH9
select I8257
select ISA_BUS
select ACPI_SMBUS
-select ACPI_X86_ICH
+select ACPI_ICH9
--
2.38.1
[PATCH 3/5] hw/acpi/Kconfig: Add missing dependencies to ACPI_ICH9
ich9_lpc_realize() uses apm_init() and ich9_smbus_realize() uses pm_smbus_init(), so both APM and ACPI_SMBUS are provided by the device models managed by ACPI_ICH9. Signed-off-by: Bernhard Beschow --- hw/acpi/Kconfig | 2 ++ hw/i386/Kconfig | 1 - hw/isa/Kconfig | 1 - 3 files changed, 2 insertions(+), 2 deletions(-) diff --git a/hw/acpi/Kconfig b/hw/acpi/Kconfig index ec16dd20e6..5a678b07c7 100644 --- a/hw/acpi/Kconfig +++ b/hw/acpi/Kconfig @@ -15,7 +15,9 @@ config ACPI_X86 config ACPI_ICH9 bool +select ACPI_SMBUS select ACPI_X86 +select APM config ACPI_CPU_HOTPLUG bool diff --git a/hw/i386/Kconfig b/hw/i386/Kconfig index 2fdefd7458..4b4b5265bb 100644 --- a/hw/i386/Kconfig +++ b/hw/i386/Kconfig @@ -51,7 +51,6 @@ config PC_PCI bool select APIC select IOAPIC -select APM select PC config PC_ACPI diff --git a/hw/isa/Kconfig b/hw/isa/Kconfig index 01f330d941..0a6a04947c 100644 --- a/hw/isa/Kconfig +++ b/hw/isa/Kconfig @@ -77,5 +77,4 @@ config LPC_ICH9 # for ICH9. select I8257 select ISA_BUS -select ACPI_SMBUS select ACPI_ICH9 -- 2.38.1
[PATCH 4/5] hw/isa/Kconfig: Add missing dependency to VT82C686
Both ACPI_PIIX4 (directly) and ACPI_ICH9 (indirectly) require ACPI to be selected. Require it for VT82C686's ACPI controller too for consistency. Signed-off-by: Bernhard Beschow --- hw/isa/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/hw/isa/Kconfig b/hw/isa/Kconfig index 0a6a04947c..bc2e3ecf02 100644 --- a/hw/isa/Kconfig +++ b/hw/isa/Kconfig @@ -63,6 +63,7 @@ config VT82C686 select IDE_VIA select MC146818RTC select PARALLEL +depends on ACPI config SMC37C669 bool -- 2.38.1
Re: [PATCH 6/6] hw/arm: Allwinner A10 enable SPL load from MMC
Hi Strahinja,
On Sun, Dec 4, 2022 at 12:19 AM Strahinja Jankovic <
strahinjapjanko...@gmail.com> wrote:
> This patch enables copying of SPL from MMC if `-kernel` parameter is not
> passed when starting QEMU. SPL is copied to SRAM_A.
>
> The approach is reused from Allwinner H3 implementation.
>
> Tested with Armbian and custom Yocto image.
>
> Signed-off-by: Strahinja Jankovic
> ---
> hw/arm/allwinner-a10.c | 18 ++
> hw/arm/cubieboard.c| 5 +
> include/hw/arm/allwinner-a10.h | 21 +
> 3 files changed, 44 insertions(+)
>
> diff --git a/hw/arm/allwinner-a10.c b/hw/arm/allwinner-a10.c
> index 17e439777e..dc1966ff7a 100644
> --- a/hw/arm/allwinner-a10.c
> +++ b/hw/arm/allwinner-a10.c
> @@ -24,7 +24,9 @@
> #include "sysemu/sysemu.h"
> #include "hw/boards.h"
> #include "hw/usb/hcd-ohci.h"
> +#include "hw/loader.h"
>
> +#define AW_A10_SRAM_A_BASE 0x
> #define AW_A10_DRAMC_BASE 0x01c01000
> #define AW_A10_MMC0_BASE0x01c0f000
> #define AW_A10_CCM_BASE 0x01c2
> @@ -38,6 +40,22 @@
> #define AW_A10_RTC_BASE 0x01c20d00
> #define AW_A10_I2C0_BASE0x01c2ac00
>
> +void allwinner_a10_bootrom_setup(AwA10State *s, BlockBackend *blk)
> +{
> +const int64_t rom_size = 32 * KiB;
> +g_autofree uint8_t *buffer = g_new0(uint8_t, rom_size);
> +
> +if (blk_pread(blk, 8 * KiB, rom_size, buffer, 0) < 0) {
> +error_setg(_fatal, "%s: failed to read BlockBackend data",
> + __func__);
> +return;
> +}
> +
> +rom_add_blob("allwinner-a10.bootrom", buffer, rom_size,
> + rom_size, AW_A10_SRAM_A_BASE,
> + NULL, NULL, NULL, NULL, false);
> +}
>
Its probably fine for now to do it in the same way here for the A10 indeed.
Perhaps in the future, we can try
to share some overlapping code between the A10 and H3.
So the patch looks fine to me:
Reviewed-by: Niek Linnenbank
Regards,
Niek
> +
> static void aw_a10_init(Object *obj)
> {
> AwA10State *s = AW_A10(obj);
> diff --git a/hw/arm/cubieboard.c b/hw/arm/cubieboard.c
> index afc7980414..37659c35fd 100644
> --- a/hw/arm/cubieboard.c
> +++ b/hw/arm/cubieboard.c
> @@ -99,6 +99,11 @@ static void cubieboard_init(MachineState *machine)
> memory_region_add_subregion(get_system_memory(), AW_A10_SDRAM_BASE,
> machine->ram);
>
> +/* Load target kernel or start using BootROM */
> +if (!machine->kernel_filename && blk && blk_is_available(blk)) {
> +/* Use Boot ROM to copy data from SD card to SRAM */
> +allwinner_a10_bootrom_setup(a10, blk);
> +}
> /* TODO create and connect IDE devices for ide_drive_get() */
>
> cubieboard_binfo.ram_size = machine->ram_size;
> diff --git a/include/hw/arm/allwinner-a10.h
> b/include/hw/arm/allwinner-a10.h
> index 763935fca9..b3c9ed24c7 100644
> --- a/include/hw/arm/allwinner-a10.h
> +++ b/include/hw/arm/allwinner-a10.h
> @@ -15,6 +15,7 @@
> #include "hw/misc/allwinner-a10-ccm.h"
> #include "hw/misc/allwinner-a10-dramc.h"
> #include "hw/i2c/allwinner-i2c.h"
> +#include "sysemu/block-backend.h"
>
> #include "target/arm/cpu.h"
> #include "qom/object.h"
> @@ -47,4 +48,24 @@ struct AwA10State {
> OHCISysBusState ohci[AW_A10_NUM_USB];
> };
>
> +/**
> + * Emulate Boot ROM firmware setup functionality.
> + *
> + * A real Allwinner A10 SoC contains a Boot ROM
> + * which is the first code that runs right after
> + * the SoC is powered on. The Boot ROM is responsible
> + * for loading user code (e.g. a bootloader) from any
> + * of the supported external devices and writing the
> + * downloaded code to internal SRAM. After loading the SoC
> + * begins executing the code written to SRAM.
> + *
> + * This function emulates the Boot ROM by copying 32 KiB
> + * of data from the given block device and writes it to
> + * the start of the first internal SRAM memory.
> + *
> + * @s: Allwinner A10 state object pointer
> + * @blk: Block backend device object pointer
> + */
> +void allwinner_a10_bootrom_setup(AwA10State *s, BlockBackend *blk);
> +
> #endif
> --
> 2.30.2
>
>
--
Niek Linnenbank
Re: [PATCH 1/6] hw/misc: Allwinner-A10 Clock Controller Module Emulation
Hi Strahinja,
On Sun, Dec 4, 2022 at 12:19 AM Strahinja Jankovic <
strahinjapjanko...@gmail.com> wrote:
> During SPL boot several Clock Controller Module (CCM) registers are
> read, most important are PLL and Tuning, as well as divisor registers.
>
> This patch adds these registers and initializes reset values from user's
> guide.
>
> Signed-off-by: Strahinja Jankovic
>
Looks fine to me:
Reviewed-by: Niek Linnenbank
Regards,
Niek
> ---
> hw/arm/Kconfig | 1 +
> hw/arm/allwinner-a10.c | 7 +
> hw/misc/Kconfig | 3 +
> hw/misc/allwinner-a10-ccm.c | 224
> hw/misc/meson.build | 1 +
> include/hw/arm/allwinner-a10.h | 2 +
> include/hw/misc/allwinner-a10-ccm.h | 67 +
> 7 files changed, 305 insertions(+)
> create mode 100644 hw/misc/allwinner-a10-ccm.c
> create mode 100644 include/hw/misc/allwinner-a10-ccm.h
>
> diff --git a/hw/arm/Kconfig b/hw/arm/Kconfig
> index 17fcde8e1c..14f52b41af 100644
> --- a/hw/arm/Kconfig
> +++ b/hw/arm/Kconfig
> @@ -319,6 +319,7 @@ config ALLWINNER_A10
> select AHCI
> select ALLWINNER_A10_PIT
> select ALLWINNER_A10_PIC
> +select ALLWINNER_A10_CCM
> select ALLWINNER_EMAC
> select SERIAL
> select UNIMP
> diff --git a/hw/arm/allwinner-a10.c b/hw/arm/allwinner-a10.c
> index 79082289ea..86baeeeca2 100644
> --- a/hw/arm/allwinner-a10.c
> +++ b/hw/arm/allwinner-a10.c
> @@ -26,6 +26,7 @@
> #include "hw/usb/hcd-ohci.h"
>
> #define AW_A10_MMC0_BASE0x01c0f000
> +#define AW_A10_CCM_BASE 0x01c2
> #define AW_A10_PIC_REG_BASE 0x01c20400
> #define AW_A10_PIT_REG_BASE 0x01c20c00
> #define AW_A10_UART0_REG_BASE 0x01c28000
> @@ -46,6 +47,8 @@ static void aw_a10_init(Object *obj)
>
> object_initialize_child(obj, "timer", >timer, TYPE_AW_A10_PIT);
>
> +object_initialize_child(obj, "ccm", >ccm, TYPE_AW_A10_CCM);
> +
> object_initialize_child(obj, "emac", >emac, TYPE_AW_EMAC);
>
> object_initialize_child(obj, "sata", >sata, TYPE_ALLWINNER_AHCI);
> @@ -103,6 +106,10 @@ static void aw_a10_realize(DeviceState *dev, Error
> **errp)
> memory_region_add_subregion(get_system_memory(), 0x,
> >sram_a);
> create_unimplemented_device("a10-sram-ctrl", 0x01c0, 4 * KiB);
>
> +/* Clock Control Module */
> +sysbus_realize(SYS_BUS_DEVICE(>ccm), _fatal);
> +sysbus_mmio_map(SYS_BUS_DEVICE(>ccm), 0, AW_A10_CCM_BASE);
> +
> /* FIXME use qdev NIC properties instead of nd_table[] */
> if (nd_table[0].used) {
> qemu_check_nic_model(_table[0], TYPE_AW_EMAC);
> diff --git a/hw/misc/Kconfig b/hw/misc/Kconfig
> index cbabe9f78c..ed07bf4133 100644
> --- a/hw/misc/Kconfig
> +++ b/hw/misc/Kconfig
> @@ -174,4 +174,7 @@ config VIRT_CTRL
> config LASI
> bool
>
> +config ALLWINNER_A10_CCM
> +bool
> +
> source macio/Kconfig
> diff --git a/hw/misc/allwinner-a10-ccm.c b/hw/misc/allwinner-a10-ccm.c
> new file mode 100644
> index 00..68146ee340
> --- /dev/null
> +++ b/hw/misc/allwinner-a10-ccm.c
> @@ -0,0 +1,224 @@
> +/*
> + * Allwinner A10 Clock Control Module emulation
> + *
> + * Copyright (C) 2022 Strahinja Jankovic
> + *
> + * This file is derived from Allwinner H3 CCU,
> + * by Niek Linnenbank.
> + *
> + * This program is free software: you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation, either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program. If not, see
Re: [PATCH 2/6] hw/misc: Allwinner A10 DRAM Controller Emulation
Hi Strahinja,
On Sun, Dec 4, 2022 at 12:19 AM Strahinja Jankovic <
strahinjapjanko...@gmail.com> wrote:
> During SPL boot several DRAM Controller registers are used. Most
> important registers are those related to DRAM initialization and
> calibration, where SPL initiates process and waits until certain bit is
> set/cleared.
>
> This patch adds these registers, initializes reset values from user's
> guide and updates state of registers as SPL expects it.
>
> Signed-off-by: Strahinja Jankovic
> ---
> hw/arm/Kconfig| 1 +
> hw/arm/allwinner-a10.c| 7 +
> hw/misc/Kconfig | 3 +
> hw/misc/allwinner-a10-dramc.c | 179 ++
> hw/misc/meson.build | 1 +
> include/hw/arm/allwinner-a10.h| 2 +
> include/hw/misc/allwinner-a10-dramc.h | 68 ++
> 7 files changed, 261 insertions(+)
> create mode 100644 hw/misc/allwinner-a10-dramc.c
> create mode 100644 include/hw/misc/allwinner-a10-dramc.h
>
> diff --git a/hw/arm/Kconfig b/hw/arm/Kconfig
> index 14f52b41af..140f142ae5 100644
> --- a/hw/arm/Kconfig
> +++ b/hw/arm/Kconfig
> @@ -320,6 +320,7 @@ config ALLWINNER_A10
> select ALLWINNER_A10_PIT
> select ALLWINNER_A10_PIC
> select ALLWINNER_A10_CCM
> +select ALLWINNER_A10_DRAMC
> select ALLWINNER_EMAC
> select SERIAL
> select UNIMP
> diff --git a/hw/arm/allwinner-a10.c b/hw/arm/allwinner-a10.c
> index 86baeeeca2..a5f7a36ac9 100644
> --- a/hw/arm/allwinner-a10.c
> +++ b/hw/arm/allwinner-a10.c
> @@ -25,6 +25,7 @@
> #include "hw/boards.h"
> #include "hw/usb/hcd-ohci.h"
>
> +#define AW_A10_DRAMC_BASE 0x01c01000
> #define AW_A10_MMC0_BASE0x01c0f000
> #define AW_A10_CCM_BASE 0x01c2
> #define AW_A10_PIC_REG_BASE 0x01c20400
> @@ -49,6 +50,8 @@ static void aw_a10_init(Object *obj)
>
> object_initialize_child(obj, "ccm", >ccm, TYPE_AW_A10_CCM);
>
> +object_initialize_child(obj, "dramc", >dramc, TYPE_AW_A10_DRAMC);
> +
> object_initialize_child(obj, "emac", >emac, TYPE_AW_EMAC);
>
> object_initialize_child(obj, "sata", >sata, TYPE_ALLWINNER_AHCI);
> @@ -110,6 +113,10 @@ static void aw_a10_realize(DeviceState *dev, Error
> **errp)
> sysbus_realize(SYS_BUS_DEVICE(>ccm), _fatal);
> sysbus_mmio_map(SYS_BUS_DEVICE(>ccm), 0, AW_A10_CCM_BASE);
>
> +/* DRAM Control Module */
> +sysbus_realize(SYS_BUS_DEVICE(>dramc), _fatal);
> +sysbus_mmio_map(SYS_BUS_DEVICE(>dramc), 0, AW_A10_DRAMC_BASE);
> +
> /* FIXME use qdev NIC properties instead of nd_table[] */
> if (nd_table[0].used) {
> qemu_check_nic_model(_table[0], TYPE_AW_EMAC);
> diff --git a/hw/misc/Kconfig b/hw/misc/Kconfig
> index ed07bf4133..052fb54310 100644
> --- a/hw/misc/Kconfig
> +++ b/hw/misc/Kconfig
> @@ -177,4 +177,7 @@ config LASI
> config ALLWINNER_A10_CCM
> bool
>
> +config ALLWINNER_A10_DRAMC
> +bool
> +
> source macio/Kconfig
> diff --git a/hw/misc/allwinner-a10-dramc.c b/hw/misc/allwinner-a10-dramc.c
> new file mode 100644
> index 00..e118b0c2fd
> --- /dev/null
> +++ b/hw/misc/allwinner-a10-dramc.c
> @@ -0,0 +1,179 @@
> +/*
> + * Allwinner A10 DRAM Controller emulation
> + *
> + * Copyright (C) 2022 Strahinja Jankovic
> + *
> + * This file is derived from Allwinner H3 DRAMC,
> + * by Niek Linnenbank.
> + *
> + * This program is free software: you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation, either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program. If not, see
Re: [PATCH v3 02/13] tcg/s390x: Remove TCG_REG_TB
On Tue, 2022-12-06 at 16:22 -0600, Richard Henderson wrote:
> On 12/6/22 13:29, Ilya Leoshkevich wrote:
> > On Thu, Dec 01, 2022 at 10:51:49PM -0800, Richard Henderson wrote:
> > > This reverts 829e1376d940 ("tcg/s390: Introduce TCG_REG_TB"), and
> > > several follow-up patches. The primary motivation is to reduce
> > > the
> > > less-tested code paths, pre-z10. Secondarily, this allows the
> > > unconditional use of TCG_TARGET_HAS_direct_jump, which might be
> > > more
> > > important for performance than any slight increase in code size.
> > >
> > > Signed-off-by: Richard Henderson
> > > ---
> > > tcg/s390x/tcg-target.h | 2 +-
> > > tcg/s390x/tcg-target.c.inc | 176 +-
> > > ---
> > > 2 files changed, 23 insertions(+), 155 deletions(-)
> >
> > Reviewed-by: Ilya Leoshkevich
> >
> > I have a few questions/ideas for the future below.
> > >
...
> >
> > > - /* Use the constant pool if USE_REG_TB, but not for small
> > > constants. */
> > > - if (maybe_out_small_movi(s, type, TCG_TMP0, val)) {
> > > - if (type == TCG_TYPE_I32) {
> > > - tcg_out_insn(s, RR, XR, dest, TCG_TMP0);
> > > - } else {
> > > - tcg_out_insn(s, RRE, XGR, dest, TCG_TMP0);
> > > - }
> > > - } else if (USE_REG_TB) {
> > > - tcg_out_insn(s, RXY, XG, dest, TCG_REG_TB, TCG_REG_NONE,
> > > 0);
> > > - new_pool_label(s, val, R_390_20, s->code_ptr - 2,
> > > - tcg_tbrel_diff(s, NULL));
> > > + tcg_out_movi(s, type, TCG_TMP0, val);
> > > + if (type == TCG_TYPE_I32) {
> > > + tcg_out_insn(s, RR, XR, dest, TCG_TMP0);
> > > } else {
> > > - /* Perform the xor by parts. */
> > > - tcg_debug_assert(HAVE_FACILITY(EXT_IMM));
> > > - if (val & 0x) {
> > > - tcg_out_insn(s, RIL, XILF, dest, val);
> > > - }
> > > - if (val > 0x) {
> > > - tcg_out_insn(s, RIL, XIHF, dest, val >> 32);
> > > - }
> > > + tcg_out_insn(s, RRE, XGR, dest, TCG_TMP0);
> > > }
> > > }
> >
> > Wouldn't it be worth keeping XILF/XIFH here?
>
> I don't know. It's difficult for me to guess whether a dependency
> chain like
>
> val -> xor -> xor
>
> (3 insns with serial dependencies) is better than
>
> val --> xor
> load -/
>
> (3 insns, but only one serial dependency) is better. But there may
> also be instruction
> fusion going on at the micro-architectural level, so that there's
> really only one xor.
>
> If you have suggestions, I'm all ears.
I ran some experiments, and it turned out you were right: xilf+xihf is
slower exactly because of dependency chains.
So no need to change anything here and sorry for the noise.
> > I don't have any numbers right now, but it looks more
> > compact/efficient
> > than a load + XGR.
>
> If we assume general-instruction-extension-facility (z10?), LGRL +
> XGR is smaller than
> XILF + XIFH, ignoring the constant pool entry which might be shared,
> and modulo the µarch
> questions above.
>
>
> > Same for OGR above; I even wonder if both implementations could be
> > unified.
>
> Sadly not, because of OILL et al. There are no 16-bit xor immediate
> insns.
>
> > > + /*
> > > + * branch displacement must be aligned for atomic
> > > patching;
> > > + * see if we need to add extra nop before branch
> > > + */
> > > + if (!QEMU_PTR_IS_ALIGNED(s->code_ptr + 1, 4)) {
> > > + tcg_out16(s, NOP);
> > > }
> > > + tcg_out16(s, RIL_BRCL | (S390_CC_ALWAYS << 4));
> > > + s->tb_jmp_insn_offset[a0] = tcg_current_code_size(s);
> > > + tcg_out32(s, 0);
> > > set_jmp_reset_offset(s, a0);
> >
> > This seems to work in practice, but I don't think patching branch
> > offsets is allowed by PoP (in a multi-threaded environment). For
> > example, I had to do [2] in order to work around this limitation in
> > ftrace.
>
> Really? How does the processor distinguish between overwriting
> opcode/condition vs
> overwriting immediate operand when invalidating cached instructions?
The problem is that nothing in PoP prevents a CPU from fetching
instruction bytes one by one, in random order and more than one time.
It's not that this is necessarily going to happen, rather, it's just
that this has never been verified for all instructions and formally
stated. The observation that I use in the ftrace patch is not
formalized either, but it's specific to a single instruction and should
hold in practice for the existing hardware to the best of my knowledge.
> If overwriting operand truly isn't correct, then I think we have to
> use indirect branch
> always for goto_tb.
>
> > A third benefit seems to be that we now have one more register to
> > allocate.
>
> Yes. It's call clobbered, so it isn't live so often, but sometimes.
>
>
> r~
Re: [External] Re: [RFC PATCH] migration: reduce time of loading non-iterable vmstate
On Thu, Dec 08, 2022 at 12:07:03AM +0800, Chuang Xu wrote:
>
> On 2022/12/6 上午12:28, Peter Xu wrote:
> > Chuang,
> >
> > No worry on the delay; you're faster than when I read yours. :)
> >
> > On Mon, Dec 05, 2022 at 02:56:15PM +0800, Chuang Xu wrote:
> > > > As a start, maybe you can try with poison address_space_to_flatview()
> > > > (by
> > > > e.g. checking the start_pack_mr_change flag and assert it is not set)
> > > > during this process to see whether any call stack can even try to
> > > > dereference a flatview.
> > > >
> > > > It's just that I didn't figure a good way to "prove" its validity, even
> > > > if
> > > > I think this is an interesting idea worth thinking to shrink the
> > > > downtime.
> > > Thanks for your sugguestions!
> > > I used a thread local variable to identify whether the current thread is a
> > > migration thread(main thread of target qemu) and I modified the code of
> > > qemu_coroutine_switch to make sure the thread local variable true only in
> > > process_incoming_migration_co call stack. If the target qemu detects that
> > > start_pack_mr_change is set and address_space_to_flatview() is called in
> > > non-migrating threads or non-migrating coroutine, it will crash.
> > Are you using the thread var just to avoid the assert triggering in the
> > migration thread when commiting memory changes?
> >
> > I think _maybe_ another cleaner way to sanity check this is directly upon
> > the depth:
> >
> > static inline FlatView *address_space_to_flatview(AddressSpace *as)
> > {
> > /*
> > * Before using any flatview, sanity check we're not during a memory
> > * region transaction or the map can be invalid. Note that this can
> > * also be called during commit phase of memory transaction, but that
> > * should also only happen when the depth decreases to 0 first.
> > */
> > assert(memory_region_transaction_depth == 0);
> > return qatomic_rcu_read(>current_map);
> > }
> >
> > That should also cover the safe cases of memory transaction commits during
> > migration.
> >
> Peter, I tried this way and found that the target qemu will crash.
>
> Here is the gdb backtrace:
>
> #0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
> #1 0x7ff2929d851a in __GI_abort () at abort.c:118
> #2 0x7ff2929cfe67 in __assert_fail_base (fmt=,
> assertion=assertion@entry=0x55a32578cdc0 "memory_region_transaction_depth ==
> 0", file=file@entry=0x55a32575d9b0
> "/data00/migration/qemu-5.2.0/include/exec/memory.h",
> line=line@entry=766, function=function@entry=0x55a32578d6e0
> <__PRETTY_FUNCTION__.20463> "address_space_to_flatview") at assert.c:92
> #3 0x7ff2929cff12 in __GI___assert_fail
> (assertion=assertion@entry=0x55a32578cdc0 "memory_region_transaction_depth ==
> 0", file=file@entry=0x55a32575d9b0
> "/data00/migration/qemu-5.2.0/include/exec/memory.h", line=line@entry=766,
> function=function@entry=0x55a32578d6e0 <__PRETTY_FUNCTION__.20463>
> "address_space_to_flatview") at assert.c:101
> #4 0x55a324b2ed5e in address_space_to_flatview (as=0x55a326132580
> ) at
> /data00/migration/qemu-5.2.0/include/exec/memory.h:766
> #5 0x55a324e79559 in address_space_to_flatview (as=0x55a326132580
> ) at ../softmmu/memory.c:811
> #6 address_space_get_flatview (as=0x55a326132580 ) at
> ../softmmu/memory.c:805
> #7 0x55a324e96474 in address_space_cache_init
> (cache=cache@entry=0x55a32a4fb000, as=,
> addr=addr@entry=68404985856, len=len@entry=4096, is_write=false) at
> ../softmmu/physmem.c:3307
> #8 0x55a324ea9cba in virtio_init_region_cache (vdev=0x55a32985d9a0, n=0)
> at ../hw/virtio/virtio.c:185
> #9 0x55a324eaa615 in virtio_load (vdev=0x55a32985d9a0, f= out>, version_id=) at ../hw/virtio/virtio.c:3203
> #10 0x55a324c6ab96 in vmstate_load_state (f=f@entry=0x55a329dc0c00,
> vmsd=0x55a325fc1a60 , opaque=0x55a32985d9a0,
> version_id=1) at ../migration/vmstate.c:143
> #11 0x55a324cda138 in vmstate_load (f=0x55a329dc0c00, se=0x55a329941c90)
> at ../migration/savevm.c:913
> #12 0x55a324cdda34 in qemu_loadvm_section_start_full (mis=0x55a3284ef9e0,
> f=0x55a329dc0c00) at ../migration/savevm.c:2741
> #13 qemu_loadvm_state_main (f=f@entry=0x55a329dc0c00,
> mis=mis@entry=0x55a3284ef9e0) at ../migration/savevm.c:2939
> #14 0x55a324cdf66a in qemu_loadvm_state (f=0x55a329dc0c00) at
> ../migration/savevm.c:3021
> #15 0x55a324d14b4e in process_incoming_migration_co (opaque= out>) at ../migration/migration.c:574
> #16 0x55a32501ae3b in coroutine_trampoline (i0=,
> i1=) at ../util/coroutine-ucontext.c:173
> #17 0x7ff2929e8000 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
> #18 0x7ffed80dc2a0 in ?? ()
> #19 0x in ?? ()
>
> address_space_cache_init() is the only caller of address_space_to_flatview
> I can find in vmstate_load call stack so far. Although I think the mr used
> by address_space_cache_init() won't be affected by the delay of
Re: [PATCH 3/6] hw/i2c: Allwinner TWI/I2C Emulation
Hi Strahinja,
On Sun, Dec 4, 2022 at 12:19 AM Strahinja Jankovic <
strahinjapjanko...@gmail.com> wrote:
> This patch implements Allwinner TWI/I2C controller emulation. Only
> master-mode functionality is implemented.
>
> The SPL boot for Cubieboard expects AXP209 PMIC on TWI0/I2C0 bus, so this
> is
> first part enabling the TWI/I2C bus operation.
>
> Since both Allwinner A10 and H3 use the same module, it is added for
> both boards.
>
The A10 and H3 datasheets have the same introduction text on the TWI,
suggesting re-use indeed. Unfortunately
the A10 datasheet seems to be missing register documentation, so I can't
compare that with the H3 datasheet.
At least according to what is implemented in the linux kernel, looks like
that indeed both SoCs implement the same I2C module.
The file drivers/i2c/busses/i2c-mv64xxx.c has the following
mv64xxx_i2c_of_match_table:
{ .compatible = "allwinner,sun4i-a10-i2c", .data =
_i2c_regs_sun4i},
{ .compatible = "allwinner,sun6i-a31-i2c", .data =
_i2c_regs_sun4i},
And both SoCs define the sun4i-a10-i2c and sun6i-a31-i2c in their device
tree files, respectively.
Could you please also update the documentation files for both boards, so we
can show that they now support TWI/I2C?
docs/system/arm/cubieboard.rst
docs/system/arm/orangepi.rst
>
> Signed-off-by: Strahinja Jankovic
> ---
> hw/arm/Kconfig | 2 +
> hw/arm/allwinner-a10.c | 8 +
> hw/arm/allwinner-h3.c | 11 +-
> hw/i2c/Kconfig | 4 +
> hw/i2c/allwinner-i2c.c | 417 +
> hw/i2c/meson.build | 1 +
> include/hw/arm/allwinner-a10.h | 2 +
> include/hw/arm/allwinner-h3.h | 3 +
> include/hw/i2c/allwinner-i2c.h | 112 +
> 9 files changed, 559 insertions(+), 1 deletion(-)
> create mode 100644 hw/i2c/allwinner-i2c.c
> create mode 100644 include/hw/i2c/allwinner-i2c.h
>
> diff --git a/hw/arm/Kconfig b/hw/arm/Kconfig
> index 140f142ae5..eefe1fd134 100644
> --- a/hw/arm/Kconfig
> +++ b/hw/arm/Kconfig
> @@ -322,6 +322,7 @@ config ALLWINNER_A10
> select ALLWINNER_A10_CCM
> select ALLWINNER_A10_DRAMC
> select ALLWINNER_EMAC
> +select ALLWINNER_I2C
> select SERIAL
> select UNIMP
>
> @@ -329,6 +330,7 @@ config ALLWINNER_H3
> bool
> select ALLWINNER_A10_PIT
> select ALLWINNER_SUN8I_EMAC
> +select ALLWINNER_I2C
> select SERIAL
> select ARM_TIMER
> select ARM_GIC
> diff --git a/hw/arm/allwinner-a10.c b/hw/arm/allwinner-a10.c
> index a5f7a36ac9..17e439777e 100644
> --- a/hw/arm/allwinner-a10.c
> +++ b/hw/arm/allwinner-a10.c
> @@ -36,6 +36,7 @@
> #define AW_A10_OHCI_BASE0x01c14400
> #define AW_A10_SATA_BASE0x01c18000
> #define AW_A10_RTC_BASE 0x01c20d00
> +#define AW_A10_I2C0_BASE0x01c2ac00
>
> static void aw_a10_init(Object *obj)
> {
> @@ -56,6 +57,8 @@ static void aw_a10_init(Object *obj)
>
> object_initialize_child(obj, "sata", >sata, TYPE_ALLWINNER_AHCI);
>
> +object_initialize_child(obj, "i2c0", >i2c0, TYPE_AW_I2C);
> +
> if (machine_usb(current_machine)) {
> int i;
>
> @@ -176,6 +179,11 @@ static void aw_a10_realize(DeviceState *dev, Error
> **errp)
> /* RTC */
> sysbus_realize(SYS_BUS_DEVICE(>rtc), _fatal);
> sysbus_mmio_map_overlap(SYS_BUS_DEVICE(>rtc), 0, AW_A10_RTC_BASE,
> 10);
> +
> +/* I2C */
> +sysbus_realize(SYS_BUS_DEVICE(>i2c0), _fatal);
> +sysbus_mmio_map(SYS_BUS_DEVICE(>i2c0), 0, AW_A10_I2C0_BASE);
> +sysbus_connect_irq(SYS_BUS_DEVICE(>i2c0), 0, qdev_get_gpio_in(dev,
> 7));
> }
>
> static void aw_a10_class_init(ObjectClass *oc, void *data)
> diff --git a/hw/arm/allwinner-h3.c b/hw/arm/allwinner-h3.c
> index 308ed15552..bfce3c8d92 100644
> --- a/hw/arm/allwinner-h3.c
> +++ b/hw/arm/allwinner-h3.c
> @@ -53,6 +53,7 @@ const hwaddr allwinner_h3_memmap[] = {
> [AW_H3_DEV_UART1] = 0x01c28400,
> [AW_H3_DEV_UART2] = 0x01c28800,
> [AW_H3_DEV_UART3] = 0x01c28c00,
> +[AW_H3_DEV_TWI0] = 0x01c2ac00,
> [AW_H3_DEV_EMAC] = 0x01c3,
> [AW_H3_DEV_DRAMCOM]= 0x01c62000,
> [AW_H3_DEV_DRAMCTL]= 0x01c63000,
> @@ -106,7 +107,6 @@ struct AwH3Unimplemented {
> { "uart1", 0x01c28400, 1 * KiB },
> { "uart2", 0x01c28800, 1 * KiB },
> { "uart3", 0x01c28c00, 1 * KiB },
> -{ "twi0", 0x01c2ac00, 1 * KiB },
> { "twi1", 0x01c2b000, 1 * KiB },
> { "twi2", 0x01c2b400, 1 * KiB },
> { "scr", 0x01c2c400, 1 * KiB },
> @@ -150,6 +150,7 @@ enum {
> AW_H3_GIC_SPI_UART1 = 1,
> AW_H3_GIC_SPI_UART2 = 2,
> AW_H3_GIC_SPI_UART3 = 3,
> +AW_H3_GIC_SPI_TWI0 = 6,
> AW_H3_GIC_SPI_TIMER0= 18,
> AW_H3_GIC_SPI_TIMER1= 19,
> AW_H3_GIC_SPI_MMC0 = 60,
> @@ -225,6 +226,8 @@ static void allwinner_h3_init(Object *obj)
>"ram-size");
>
>
Re: [PULL 02/39] scsi: Add buf_len parameter to scsi_req_new()
On Thu, Sep 01, 2022 at 08:23:52PM +0200, Paolo Bonzini wrote:
> From: John Millikin
>
> When a SCSI command is received from the guest, the CDB length implied
> by the first byte might exceed the number of bytes the guest sent. In
> this case scsi_req_new() will read uninitialized data, causing
> unpredictable behavior.
>
> Adds the buf_len parameter to scsi_req_new() and plumbs it through the
> call stack.
>
> Signed-off-by: John Millikin
> Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1127
> Message-Id: <20220817053458.698416-1-j...@john-millikin.com>
> [Fill in correct length for adapters other than ESP. - Paolo]
> Signed-off-by: Paolo Bonzini
> ---
> hw/scsi/esp.c | 2 +-
> hw/scsi/lsi53c895a.c | 2 +-
> hw/scsi/megasas.c | 10 +-
...
> @@ -1823,7 +1823,7 @@ static int megasas_handle_io(MegasasState *s,
> MegasasCmd *cmd, int frame_cmd)
>
> megasas_encode_lba(cdb, lba_start, lba_count, is_write);
> cmd->req = scsi_req_new(sdev, cmd->index,
> -lun_id, cdb, cmd);
> +lun_id, cdb, cdb_len, cmd);
This doesn't work for me. cdb is a local array in this function,
its contents are filled in the function, and Linux doesn't set the
cdb_len field for io requests (or, rather, treats it as reserved
field and sets it to 0). This results in Linux boot failures when
trying to boot from the affected controllers.
The patch below fixes the problem for me, though I have no idea if
it is correct.
Guenter
---
>From 687093dc7e48ce42de22c5675a1005890f014f22 Mon Sep 17 00:00:00 2001
From: Guenter Roeck
Date: Wed, 7 Dec 2022 13:45:07 -0800
Subject: [PATCH] scsi: megasas: Internal cdbs have 16-byte length
Linux does not set cdb_len in megasas io commands. With commits d1511cea0
("scsi: Reject commands if the CDB length exceeds buf_len") and fe9d8927e2
("scsi: Add buf_len parameter to scsi_req_new()"), this results in
failures to boot from affected SCSI drives because cdb_len is 0.
Signed-off-by: Guenter Roeck
---
hw/scsi/megasas.c | 14 ++
1 file changed, 2 insertions(+), 12 deletions(-)
diff --git a/hw/scsi/megasas.c b/hw/scsi/megasas.c
index 9cbbb16121..d624866bb6 100644
--- a/hw/scsi/megasas.c
+++ b/hw/scsi/megasas.c
@@ -1780,7 +1780,7 @@ static int megasas_handle_io(MegasasState *s, MegasasCmd
*cmd, int frame_cmd)
uint8_t cdb[16];
int len;
struct SCSIDevice *sdev = NULL;
-int target_id, lun_id, cdb_len;
+int target_id, lun_id;
lba_count = le32_to_cpu(cmd->frame->io.header.data_len);
lba_start_lo = le32_to_cpu(cmd->frame->io.lba_lo);
@@ -1789,7 +1789,6 @@ static int megasas_handle_io(MegasasState *s, MegasasCmd
*cmd, int frame_cmd)
target_id = cmd->frame->header.target_id;
lun_id = cmd->frame->header.lun_id;
-cdb_len = cmd->frame->header.cdb_len;
if (target_id < MFI_MAX_LD && lun_id == 0) {
sdev = scsi_device_find(>bus, 0, target_id, lun_id);
@@ -1804,15 +1803,6 @@ static int megasas_handle_io(MegasasState *s, MegasasCmd
*cmd, int frame_cmd)
return MFI_STAT_DEVICE_NOT_FOUND;
}
-if (cdb_len > 16) {
-trace_megasas_scsi_invalid_cdb_len(
-mfi_frame_desc(frame_cmd), 1, target_id, lun_id, cdb_len);
-megasas_write_sense(cmd, SENSE_CODE(INVALID_OPCODE));
-cmd->frame->header.scsi_status = CHECK_CONDITION;
-s->event_count++;
-return MFI_STAT_SCSI_DONE_WITH_ERROR;
-}
-
cmd->iov_size = lba_count * sdev->blocksize;
if (megasas_map_sgl(s, cmd, >frame->io.sgl)) {
megasas_write_sense(cmd, SENSE_CODE(TARGET_FAILURE));
@@ -1823,7 +1813,7 @@ static int megasas_handle_io(MegasasState *s, MegasasCmd
*cmd, int frame_cmd)
megasas_encode_lba(cdb, lba_start, lba_count, is_write);
cmd->req = scsi_req_new(sdev, cmd->index,
-lun_id, cdb, cdb_len, cmd);
+lun_id, cdb, sizeof(cdb), cmd);
if (!cmd->req) {
trace_megasas_scsi_req_alloc_failed(
mfi_frame_desc(frame_cmd), target_id, lun_id);
--
2.36.2
Re: [PATCH v3 02/13] tcg/s390x: Remove TCG_REG_TB
Am 07.12.22 um 21:40 schrieb Ilya Leoshkevich: On Wed, 2022-12-07 at 08:55 -0600, Richard Henderson wrote: On 12/7/22 01:45, Thomas Huth wrote: On 06/12/2022 23.22, Richard Henderson wrote: On 12/6/22 13:29, Ilya Leoshkevich wrote: This change doesn't seem to affect that, but what is the minimum supported s390x qemu host? z900? Possibly z990, if I'm reading the gcc processor_flags_table[] correctly; long-displacement-facility is definitely a minimum. We probably should revisit what the minimum for TCG should be, assert those features at startup, and drop the corresponding runtime tests. If we consider the official IBM support statement: https://www.ibm.com/support/pages/system/files/inline-files/IBM%20Mainframe%20Life%20Cycle%20History%20V2.10%20-%20Sept%2013%202022_1.pdf ... that would mean that the z10 and all older machines are not supported anymore. Thanks for the pointer. It would appear that z114 exits support at the end of this month, which would leave z12 as minimum supported cpu. Even assuming z196 gets us extended-immediate, general-insn- extension, load-on-condition, and distinct-operands, which are all quite important to TCG, and constitute almost all of the current runtime checks. The other metric would be matching the set of supported cpus from the set of supported os distributions, but I would be ready to believe z196 is below the minimum there too. r~ I think it should be safe to raise the minimum required hardware for TCG to z196: We recently raised the minimum hardware for the Linux kernel to be z10, so that would be super-safe, but z196 is certainly a sane minimum. * The oldest supported RHEL is v7, it requires z196: https://access.redhat.com/product-life-cycles/ https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/installation_guide/chap-installation-planning-s390 * The oldest supported SLES is v12, it requires z196: https://www.suse.com/de-de/lifecycle/ https://documentation.suse.com/sles/12-SP5/html/SLES-all/cha-zseries.html * The oldest supported Ubuntu is v16.04, it requires zEC12+: https://wiki.ubuntu.com/S390X Best regards, Ilya
Re: [PATCH v3 02/13] tcg/s390x: Remove TCG_REG_TB
On Wed, 2022-12-07 at 08:55 -0600, Richard Henderson wrote: > On 12/7/22 01:45, Thomas Huth wrote: > > On 06/12/2022 23.22, Richard Henderson wrote: > > > On 12/6/22 13:29, Ilya Leoshkevich wrote: > > > > This change doesn't seem to affect that, but what is the > > > > minimum > > > > supported s390x qemu host? z900? > > > > > > Possibly z990, if I'm reading the gcc processor_flags_table[] > > > correctly; > > > long-displacement-facility is definitely a minimum. > > > > > > We probably should revisit what the minimum for TCG should be, > > > assert those features at > > > startup, and drop the corresponding runtime tests. > > > > If we consider the official IBM support statement: > > > > https://www.ibm.com/support/pages/system/files/inline-files/IBM%20Mainframe%20Life%20Cycle%20History%20V2.10%20-%20Sept%2013%202022_1.pdf > > > > ... that would mean that the z10 and all older machines are not > > supported anymore. > > Thanks for the pointer. It would appear that z114 exits support at > the end of this month, > which would leave z12 as minimum supported cpu. > > Even assuming z196 gets us extended-immediate, general-insn- > extension, load-on-condition, > and distinct-operands, which are all quite important to TCG, and > constitute almost all of > the current runtime checks. > > The other metric would be matching the set of supported cpus from the > set of supported os > distributions, but I would be ready to believe z196 is below the > minimum there too. > > > r~ I think it should be safe to raise the minimum required hardware for TCG to z196: * The oldest supported RHEL is v7, it requires z196: https://access.redhat.com/product-life-cycles/ https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/installation_guide/chap-installation-planning-s390 * The oldest supported SLES is v12, it requires z196: https://www.suse.com/de-de/lifecycle/ https://documentation.suse.com/sles/12-SP5/html/SLES-all/cha-zseries.html * The oldest supported Ubuntu is v16.04, it requires zEC12+: https://wiki.ubuntu.com/S390X Best regards, Ilya
Re: [PATCH for 7.2?] target/i386: Remove compilation errors when -Werror=maybe-uninitialized
Hi Peter, On 12/7/22 21:28, Peter Maydell wrote: > On Wed, 7 Dec 2022 at 18:44, Eric Auger wrote: >> On 12/7/22 19:23, Richard Henderson wrote: >>> Adding -Wall is not standard, nor all the other -W that you are >>> adding. I think you should not be surprised that you run into problems. >> OK that's a useful indication. I used to have this configure cmd line >> for a while and have not paid much attention to it until now, I >> acknowledge. This was useful to catch compilation errors at some point I >> guess. >>> While you can make a case for auditing the code base and adding these >>> to the default set of warning flags, that's a job for the next >>> development cycle. >> Let me clarify, I am not insisting for that fix to land in 7.2 all the >> more so it is pretty late. I just wanted to report the compilation issue >> and since I use the std qemu pieces with a pretty standard tool chain I >> thought somebody else would be likely to hit the same problem. > As Richard says, we don't expect people to randomly add extra > warning flags, and anybody who does should expect to see extra > warnings (and that they need to --disable-werror if they don't want > those extra warnings to turn into errors). > > We specifically disable some warnings, there are some not-on-by-default > warnings that we know we have work to do if we want to eliminate them > (eg -Wvla) and there's probably a few where we conceptually disagree > with a warning flag or don't find it useful for QEMU (like > -Wgnu-statement-expression -- we deliberately use GNU statement > expressions so warning about them isn't useful to us). > > Sorting through which of the currently non-enabled warning flags > are worth trying to fix existing warnings and enable by default > is a pretty big task (not dissimilar to sorting through Coverity > issue reports -- maybe some of the things you fix are real bugs > but there's a lot of false-positives to wade through to get there). > > maybe-uninitialized warnings are particularly awkward because whether > you get them depends a lot on the version of the compiler and how > smart its data analysis is. OK. I don't exactly remember how I came to this configure cmd line. Maybe in the old times bots were complaining about such kind of warnings or some of the extra warning flags were used downstream. I simply thought we had a stricter policy with regards to those and I have been using this configure command for a long time, without trouble, until recently, hence that belief. Thanks Eric > > thanks > -- PMM >
Re: [PATCH for 7.2?] target/i386: Remove compilation errors when -Werror=maybe-uninitialized
On Wed, 7 Dec 2022 at 18:44, Eric Auger wrote: > On 12/7/22 19:23, Richard Henderson wrote: > > Adding -Wall is not standard, nor all the other -W that you are > > adding. I think you should not be surprised that you run into problems. > OK that's a useful indication. I used to have this configure cmd line > for a while and have not paid much attention to it until now, I > acknowledge. This was useful to catch compilation errors at some point I > guess. > > > > While you can make a case for auditing the code base and adding these > > to the default set of warning flags, that's a job for the next > > development cycle. > > Let me clarify, I am not insisting for that fix to land in 7.2 all the > more so it is pretty late. I just wanted to report the compilation issue > and since I use the std qemu pieces with a pretty standard tool chain I > thought somebody else would be likely to hit the same problem. As Richard says, we don't expect people to randomly add extra warning flags, and anybody who does should expect to see extra warnings (and that they need to --disable-werror if they don't want those extra warnings to turn into errors). We specifically disable some warnings, there are some not-on-by-default warnings that we know we have work to do if we want to eliminate them (eg -Wvla) and there's probably a few where we conceptually disagree with a warning flag or don't find it useful for QEMU (like -Wgnu-statement-expression -- we deliberately use GNU statement expressions so warning about them isn't useful to us). Sorting through which of the currently non-enabled warning flags are worth trying to fix existing warnings and enable by default is a pretty big task (not dissimilar to sorting through Coverity issue reports -- maybe some of the things you fix are real bugs but there's a lot of false-positives to wade through to get there). maybe-uninitialized warnings are particularly awkward because whether you get them depends a lot on the version of the compiler and how smart its data analysis is. thanks -- PMM
Re: [PATCH 0/6] Enable Cubieboard A10 boot SPL from SD card
Hello Strahinja, Thanks for contribution these patches, and also taking the H3 into account :-) I've ran the avocado based acceptance tests for both boards and got these results: $ ARMBIAN_ARTIFACTS_CACHED=yes AVOCADO_ALLOW_LARGE_STORAGE=yes ./build/tests/venv/bin/avocado --show=app,console run -t machine:orangepi-pc tests/avocado/boot_linux_console.py ... RESULTS: PASS 5 | ERROR 0 | FAIL 0 | SKIP 0 | WARN 0 | INTERRUPT 0 | CANCEL 0 JOB TIME : 114.24 s $ ./build/tests/venv/bin/avocado --show=app,console run -t machine:cubieboard tests/avocado/boot_linux_console.py ... RESULTS: PASS 2 | ERROR 0 | FAIL 0 | SKIP 0 | WARN 0 | INTERRUPT 0 | CANCEL 0 JOB TIME : 22.79 s So that shows both machines are still running fine. During startup of the bionic 20.08 image for orangepi-pc it did show this message: console: i2c i2c-0: mv64xxx: I2C bus locked, block: 1, time_left: 0 console: sy8106a: probe of 0-0065 failed with error -110 The SY8106a appears to be an peripheral attached to the I2C bus on the orangepi-pc, and we don't emulate the SY8106a yet, so that's an error to be expected: https://linux-sunxi.org/SY8106A So for the series: Tested-by: Niek Linnenbank I'll try to reply to each patch as well. Kind regards, Niek On Sun, Dec 4, 2022 at 12:19 AM Strahinja Jankovic < strahinjapjanko...@gmail.com> wrote: > This patch series adds missing Allwinner A10 modules needed for > successful SPL boot: > - Clock controller module > - DRAM controller > - I2C0 controller (added also for Allwinner H3 since it is the same) > - AXP-209 connected to I2C0 bus > > It also updates Allwinner A10 emulation so SPL is copied from attached > SD card if `-kernel` parameter is not passed when starting QEMU > (approach adapted from Allwinner H3 implementation). > > Boot from SD card has been tested with Cubieboard Armbian SD card image > and custom > Yocto image built for Cubieboard. > Example usage for Armbian image: > qemu-system-arm -M cubieboard -nographic -sd > ~/Armbian_22.11.0-trunk_Cubieboard_kinetic_edge_6.0.7.img > > > Strahinja Jankovic (6): > hw/misc: Allwinner-A10 Clock Controller Module Emulation > hw/misc: Allwinner A10 DRAM Controller Emulation > hw/i2c: Allwinner TWI/I2C Emulation > hw/misc: Allwinner AXP-209 Emulation > hw/arm: Add AXP-209 to Cubieboard > hw/arm: Allwinner A10 enable SPL load from MMC > > hw/arm/Kconfig| 5 + > hw/arm/allwinner-a10.c| 40 +++ > hw/arm/allwinner-h3.c | 11 +- > hw/arm/cubieboard.c | 11 + > hw/i2c/Kconfig| 4 + > hw/i2c/allwinner-i2c.c| 417 ++ > hw/i2c/meson.build| 1 + > hw/misc/Kconfig | 10 + > hw/misc/allwinner-a10-ccm.c | 224 ++ > hw/misc/allwinner-a10-dramc.c | 179 +++ > hw/misc/allwinner-axp-209.c | 263 > hw/misc/meson.build | 3 + > include/hw/arm/allwinner-a10.h| 27 ++ > include/hw/arm/allwinner-h3.h | 3 + > include/hw/i2c/allwinner-i2c.h| 112 +++ > include/hw/misc/allwinner-a10-ccm.h | 67 + > include/hw/misc/allwinner-a10-dramc.h | 68 + > 17 files changed, 1444 insertions(+), 1 deletion(-) > create mode 100644 hw/i2c/allwinner-i2c.c > create mode 100644 hw/misc/allwinner-a10-ccm.c > create mode 100644 hw/misc/allwinner-a10-dramc.c > create mode 100644 hw/misc/allwinner-axp-209.c > create mode 100644 include/hw/i2c/allwinner-i2c.h > create mode 100644 include/hw/misc/allwinner-a10-ccm.h > create mode 100644 include/hw/misc/allwinner-a10-dramc.h > > -- > 2.30.2 > > -- Niek Linnenbank
Re: [PATCH for 7.2?] target/i386: Remove compilation errors when -Werror=maybe-uninitialized
Hi Stefan,
On 12/7/22 20:11, Stefan Weil via wrote:
> Am 07.12.22 um 19:22 schrieb Eric Auger:
>>
>> On 12/7/22 17:55, Philippe Mathieu-Daudé wrote:
>>> On 7/12/22 15:33, Eric Auger wrote:
On 12/7/22 15:09, Stefan Hajnoczi wrote:
> On Wed, 7 Dec 2022 at 08:31, Eric Auger
> wrote:
>> On 12/7/22 14:24, Eric Auger wrote:
>>> Initialize r0-3 to avoid compilation errors when
>>> -Werror=maybe-uninitialized is used
>>>
>>> ../target/i386/ops_sse.h: In function ‘helper_vpermdq_ymm’:
>>> ../target/i386/ops_sse.h:2495:13: error: ‘r3’ may be used
>>> uninitialized in this function [-Werror=maybe-uninitialized]
>>> 2495 | d->Q(3) = r3;
>>> | ^~~~
>>> ../target/i386/ops_sse.h:2494:13: error: ‘r2’ may be used
>>> uninitialized in this function [-Werror=maybe-uninitialized]
>>> 2494 | d->Q(2) = r2;
>>> | ^~~~
>>> ../target/i386/ops_sse.h:2493:13: error: ‘r1’ may be used
>>> uninitialized in this function [-Werror=maybe-uninitialized]
>>> 2493 | d->Q(1) = r1;
>>> | ^~~~
>>> ../target/i386/ops_sse.h:2492:13: error: ‘r0’ may be used
>>> uninitialized in this function [-Werror=maybe-uninitialized]
>>> 2492 | d->Q(0) = r0;
>>> | ^~~~
>>>
>>> Signed-off-by: Eric Auger
>>> Fixes: 790684776861 ("target/i386: reimplement 0x0f 0x3a, add AVX")
>>>
>>> ---
>>>
>>> Am I the only one getting this? Or anything wrong in my setup.
>
> Hi Eric,
>
> no, you are not the only one. I regularly build with higher warning
> levels, for example with -Weverything on macOS, and get a much longer
> list which includes the mentioned warnings (see below).
thanks! Interesting to see the exhaustive list below and your stats
sorted by warning category.
>
> The warnings for ops_sse.h are false positives, so I think no fix is
> needed for 7.2. The compiler is not clever enough to see that the
> switch statements handle all possible cases. It should be sufficient
> to replace `case 3` by `default` to help the compiler and fix the
> warning. Your fix might produce new compiler warnings because setting
> the variables to 0 has no effect.
OK. I will respin according to your suggestion for 8.0.
Eric
>
> Cheers
> Stefan
>
> ../block/mirror.c:1024:13: warning: variable 'iostatus' may be
> uninitialized when used here [-Wconditional-uninitialized]
> ../block/mirror.c:1498:20: warning: variable 'bounce_buf' may be
> uninitialized when used here [-Wconditional-uninitialized]
> ../block/nbd.c:1208:24: warning: variable 'request_ret' may be
> uninitialized when used here [-Wconditional-uninitialized]
> ../block/nbd.c:1266:24: warning: variable 'request_ret' may be
> uninitialized when used here [-Wconditional-uninitialized]
> ../block/nbd.c:1424:20: warning: variable 'request_ret' may be
> uninitialized when used here [-Wconditional-uninitialized]
> ../block/qcow2-snapshot.c:423:51: warning: variable 'snapshots_size'
> may be uninitialized when used here [-Wconditional-uninitialized]
> ../block/qcow2.c:3236:23: warning: variable 'cur_bytes' may be
> uninitialized when used here [-Wconditional-uninitialized]
> ../block/ssh.c:306:52: warning: variable 'server_hash_len' may be
> uninitialized when used here [-Wconditional-uninitialized]
> ../block/ssh.c:313:45: warning: variable 'pubkey_type' may be
> uninitialized when used here [-Wconditional-uninitialized]
> ../contrib/elf2dmp/main.c:138:17: warning: variable 'kwn' may be
> uninitialized when used here [-Wconditional-uninitialized]
> ../contrib/elf2dmp/main.c:138:22: warning: variable 'kwa' may be
> uninitialized when used here [-Wconditional-uninitialized]
> ../contrib/elf2dmp/main.c:138:27: warning: variable
> 'KdpDataBlockEncoded' may be uninitialized when used here
> [-Wconditional-uninitialized]
> ../crypto/block-luks.c:844:29: warning: variable 'splitkeylen' may be
> uninitialized when used here [-Wconditional-uninitialized]
> ../disas/m68k.c:1513:47: warning: variable 'flval' may be
> uninitialized when used here [-Wconditional-uninitialized]
> ../dump/win_dump.c:105:18: warning: variable 'ptr64' may be
> uninitialized when used here [-Wconditional-uninitialized]
> ../dump/win_dump.c:105:26: warning: variable 'ptr32' may be
> uninitialized when used here [-Wconditional-uninitialized]
> ../gdbstub/gdbstub.c:1191:39: warning: variable 'pid' may be
> uninitialized when used here [-Wconditional-uninitialized]
> ../gdbstub/gdbstub.c:1209:36: warning: variable 'tid' may be
> uninitialized when used here [-Wconditional-uninitialized]
> ../hw/9pfs/9p.c:1911:13: warning: variable 'fidst' may be
> uninitialized when used here [-Wconditional-uninitialized]
> ../hw/block/block.c:110:33: warning: variable 'bs' may be
> uninitialized when used here [-Wconditional-uninitialized]
> ../hw/core/generic-loader.c:160:23: warning: variable 'entry' may be
> uninitialized when used here
Re: [PATCH-for-8.0 2/4] gdbstub: Use vaddr type for generic insert/remove_breakpoint() API
On Wed, 7 Dec 2022 at 18:27, Philippe Mathieu-Daudé wrote:
>
> On 7/12/22 19:23, Peter Maydell wrote:
> > On Wed, 7 Dec 2022 at 17:42, Philippe Mathieu-Daudé
> > wrote:
> >>
> >> Both insert/remove_breakpoint() handlers are used in system and
> >> user emulation. We can not use the 'hwaddr' type on user emulation,
> >> we have to use 'vaddr' which is defined as "wide enough to contain
> >> any #target_ulong virtual address".
> >> @@ -48,8 +48,8 @@ struct AccelOpsClass {
> >>
> >> /* gdbstub hooks */
> >> bool (*supports_guest_debug)(void);
> >> -int (*insert_breakpoint)(CPUState *cpu, int type, hwaddr addr, hwaddr
> >> len);
> >> -int (*remove_breakpoint)(CPUState *cpu, int type, hwaddr addr, hwaddr
> >> len);
> >> +int (*insert_breakpoint)(CPUState *cpu, int type, vaddr addr, vaddr
> >> len);
> >> +int (*remove_breakpoint)(CPUState *cpu, int type, vaddr addr, vaddr
> >> len);
> >> void (*remove_all_breakpoints)(CPUState *cpu);
> >> };
> >
> > If you're changing the prototype of these methods on AccelOpsClass
> > don't you also want to change the implementations, eg
> > tcg_breakpoint_insert()?
> > Interestingly that function calls cpu_breakpoint_insert() which
> > already takes a 'vaddr' rather than a 'hwaddr'.
>
> Yes I neglected to include these changes here:
>
> -- >8 --
> diff --git a/gdbstub/gdbstub.c b/gdbstub/gdbstub.c
> diff --git a/gdbstub/softmmu.c b/gdbstub/softmmu.c
> diff --git a/gdbstub/user.c b/gdbstub/user.c
Those are the callsites to the methods, not the implementations, I think.
-- PMM
Re: [PATCH for 7.2?] target/i386: Remove compilation errors when -Werror=maybe-uninitialized
Hi Stefan,
On 12/7/22 20:59, Stefan Hajnoczi wrote:
> On Wed, 7 Dec 2022 at 14:11, Stefan Weil wrote:
>> Am 07.12.22 um 19:22 schrieb Eric Auger:
>>> On 12/7/22 17:55, Philippe Mathieu-Daudé wrote:
On 7/12/22 15:33, Eric Auger wrote:
> On 12/7/22 15:09, Stefan Hajnoczi wrote:
>> On Wed, 7 Dec 2022 at 08:31, Eric Auger wrote:
>>> On 12/7/22 14:24, Eric Auger wrote:
Initialize r0-3 to avoid compilation errors when
-Werror=maybe-uninitialized is used
../target/i386/ops_sse.h: In function ‘helper_vpermdq_ymm’:
../target/i386/ops_sse.h:2495:13: error: ‘r3’ may be used
uninitialized in this function [-Werror=maybe-uninitialized]
2495 | d->Q(3) = r3;
| ^~~~
../target/i386/ops_sse.h:2494:13: error: ‘r2’ may be used
uninitialized in this function [-Werror=maybe-uninitialized]
2494 | d->Q(2) = r2;
| ^~~~
../target/i386/ops_sse.h:2493:13: error: ‘r1’ may be used
uninitialized in this function [-Werror=maybe-uninitialized]
2493 | d->Q(1) = r1;
| ^~~~
../target/i386/ops_sse.h:2492:13: error: ‘r0’ may be used
uninitialized in this function [-Werror=maybe-uninitialized]
2492 | d->Q(0) = r0;
| ^~~~
Signed-off-by: Eric Auger
Fixes: 790684776861 ("target/i386: reimplement 0x0f 0x3a, add AVX")
---
Am I the only one getting this? Or anything wrong in my setup.
>> Hi Eric,
>>
>> no, you are not the only one. I regularly build with higher warning
>> levels, for example with -Weverything on macOS, and get a much longer
>> list which includes the mentioned warnings (see below).
>>
>> The warnings for ops_sse.h are false positives, so I think no fix is
>> needed for 7.2. The compiler is not clever enough to see that the switch
>> statements handle all possible cases. It should be sufficient to replace
>> `case 3` by `default` to help the compiler and fix the warning. Your fix
>> might produce new compiler warnings because setting the variables to 0
>> has no effect.
> Eric: do you want to try the switch "default" approach for 8.0?
Yes sure!
Eric
>
> Thanks,
> Stefan
>
Compiler warnings with maximum warning level (was: Re: [PATCH for 7.2?] target/i386: Remove compilation errors when -Werror=maybe-uninitialized)
Am 07.12.22 um 20:11 schrieb Stefan Weil:
On 12/7/22 14:24, Eric Auger wrote:
Initialize r0-3 to avoid compilation errors when
-Werror=maybe-uninitialized is used
../target/i386/ops_sse.h: In function ‘helper_vpermdq_ymm’:
../target/i386/ops_sse.h:2495:13: error: ‘r3’ may be used
uninitialized in this function [-Werror=maybe-uninitialized]
2495 | d->Q(3) = r3;
| ^~~~
../target/i386/ops_sse.h:2494:13: error: ‘r2’ may be used
uninitialized in this function [-Werror=maybe-uninitialized]
2494 | d->Q(2) = r2;
| ^~~~
../target/i386/ops_sse.h:2493:13: error: ‘r1’ may be used
uninitialized in this function [-Werror=maybe-uninitialized]
2493 | d->Q(1) = r1;
| ^~~~
../target/i386/ops_sse.h:2492:13: error: ‘r0’ may be used
uninitialized in this function [-Werror=maybe-uninitialized]
2492 | d->Q(0) = r0;
| ^~~~
Signed-off-by: Eric Auger
Fixes: 790684776861 ("target/i386: reimplement 0x0f 0x3a, add AVX")
---
Am I the only one getting this? Or anything wrong in my setup.
Hi Eric,
no, you are not the only one. I regularly build with higher warning
levels, for example with -Weverything on macOS, and get a much longer
list which includes the mentioned warnings (see below).
The latest QEMU code produces 6780505 compiler warnings and a build log
file with 2.7 GB (!) with compiler option `-Weverything` on macOS.
Many warnings occur more than once, but there remain 193313 unique
warnings for the QEMU code (see
https://qemu.weilnetz.de/test/warnings-20221207.txt). Here is a list of
all kinds of warnings sorted by frequency:
1 -Wkeyword-macro
1 -Wundeclared-selector
1 -Wunreachable-code-loop-increment
1 -Wunused-but-set-parameter
2 -Wgnu-union-cast
2 -Woverlength-strings
3 -Walloca
5 -Wflexible-array-extensions
5 -Wstrict-selector-match
5 -Wstring-conversion
5 -Wtautological-value-range-compare
6 -Wcstring-format-directive
8 -Wstatic-in-inline
13 -Wobjc-messaging-id
13 -Wvla
14 -Wobjc-interface-ivars
16 -Wimplicit-float-conversion
17 -Wformat-nonliteral
24 -Wredundant-parens
39 -Wfloat-equal
44 -Wc++-compat
47 -Wzero-length-array
53 -Wdouble-promotion
53 -Wvariadic-macros
65 -Wpacked
74 -Wcomma
82 -Wunreachable-code-return
90 -Wformat-pedantic
90 -Wmissing-noreturn
94 -Wgnu-flexible-array-initializer
120 -Wcovered-switch-default
132 -Wdirect-ivar-access
136 -Wconditional-uninitialized
144 -Wgnu-designator
147 -Wdisabled-macro-expansion
150 -Wgnu-conditional-omitted-operand
161 -Wunreachable-code-break
184 -Wcompound-token-split-by-space
228 -Wfloat-conversion
248 -Wunreachable-code
348 -Wgnu-binary-literal
443 -Wshadow
534 -Wmissing-variable-declarations
563 -Wshift-sign-overflow
613 -Wembedded-directive
620 -Wgnu-zero-variadic-macro-arguments
742 -Wswitch-enum
843 -Wdocumentation
897 -Wgnu-case-range
1292 -Wassign-enum
1621 -Wgnu-empty-struct
1700 -Wextra-semi
1779 -Wpointer-arith
1847 -Wbad-function-cast
2176 -Wdocumentation-unknown-command
2221 -Wmissing-field-initializers
3101 -Wsign-compare
3238 -Wunused-macros
3559 -Wcast-align
4528 -Wcast-qual
7066 -Wgnu-statement-expression
7651 -Wnull-pointer-subtraction
7995 -Wimplicit-int-conversion
8854 -Wpadded
9737 -Wshorten-64-to-32
10596 -Wgnu-empty-initializer
13274 -Wlanguage-extension-token
13899 -Wunused-parameter
15642 -Wused-but-marked-unused
18669 -Wpedantic
44737 -Wsign-conversion
Re: [PATCH for 7.2?] target/i386: Remove compilation errors when -Werror=maybe-uninitialized
On Wed, 7 Dec 2022 at 14:11, Stefan Weil wrote:
>
> Am 07.12.22 um 19:22 schrieb Eric Auger:
> >
> > On 12/7/22 17:55, Philippe Mathieu-Daudé wrote:
> >> On 7/12/22 15:33, Eric Auger wrote:
> >>> On 12/7/22 15:09, Stefan Hajnoczi wrote:
> On Wed, 7 Dec 2022 at 08:31, Eric Auger wrote:
> > On 12/7/22 14:24, Eric Auger wrote:
> >> Initialize r0-3 to avoid compilation errors when
> >> -Werror=maybe-uninitialized is used
> >>
> >> ../target/i386/ops_sse.h: In function ‘helper_vpermdq_ymm’:
> >> ../target/i386/ops_sse.h:2495:13: error: ‘r3’ may be used
> >> uninitialized in this function [-Werror=maybe-uninitialized]
> >>2495 | d->Q(3) = r3;
> >> | ^~~~
> >> ../target/i386/ops_sse.h:2494:13: error: ‘r2’ may be used
> >> uninitialized in this function [-Werror=maybe-uninitialized]
> >>2494 | d->Q(2) = r2;
> >> | ^~~~
> >> ../target/i386/ops_sse.h:2493:13: error: ‘r1’ may be used
> >> uninitialized in this function [-Werror=maybe-uninitialized]
> >>2493 | d->Q(1) = r1;
> >> | ^~~~
> >> ../target/i386/ops_sse.h:2492:13: error: ‘r0’ may be used
> >> uninitialized in this function [-Werror=maybe-uninitialized]
> >>2492 | d->Q(0) = r0;
> >> | ^~~~
> >>
> >> Signed-off-by: Eric Auger
> >> Fixes: 790684776861 ("target/i386: reimplement 0x0f 0x3a, add AVX")
> >>
> >> ---
> >>
> >> Am I the only one getting this? Or anything wrong in my setup.
>
> Hi Eric,
>
> no, you are not the only one. I regularly build with higher warning
> levels, for example with -Weverything on macOS, and get a much longer
> list which includes the mentioned warnings (see below).
>
> The warnings for ops_sse.h are false positives, so I think no fix is
> needed for 7.2. The compiler is not clever enough to see that the switch
> statements handle all possible cases. It should be sufficient to replace
> `case 3` by `default` to help the compiler and fix the warning. Your fix
> might produce new compiler warnings because setting the variables to 0
> has no effect.
Eric: do you want to try the switch "default" approach for 8.0?
Thanks,
Stefan
Re: [PATCH for 7.2?] target/i386: Remove compilation errors when -Werror=maybe-uninitialized
Am 07.12.22 um 19:22 schrieb Eric Auger:
On 12/7/22 17:55, Philippe Mathieu-Daudé wrote:
On 7/12/22 15:33, Eric Auger wrote:
On 12/7/22 15:09, Stefan Hajnoczi wrote:
On Wed, 7 Dec 2022 at 08:31, Eric Auger wrote:
On 12/7/22 14:24, Eric Auger wrote:
Initialize r0-3 to avoid compilation errors when
-Werror=maybe-uninitialized is used
../target/i386/ops_sse.h: In function ‘helper_vpermdq_ymm’:
../target/i386/ops_sse.h:2495:13: error: ‘r3’ may be used
uninitialized in this function [-Werror=maybe-uninitialized]
2495 | d->Q(3) = r3;
| ^~~~
../target/i386/ops_sse.h:2494:13: error: ‘r2’ may be used
uninitialized in this function [-Werror=maybe-uninitialized]
2494 | d->Q(2) = r2;
| ^~~~
../target/i386/ops_sse.h:2493:13: error: ‘r1’ may be used
uninitialized in this function [-Werror=maybe-uninitialized]
2493 | d->Q(1) = r1;
| ^~~~
../target/i386/ops_sse.h:2492:13: error: ‘r0’ may be used
uninitialized in this function [-Werror=maybe-uninitialized]
2492 | d->Q(0) = r0;
| ^~~~
Signed-off-by: Eric Auger
Fixes: 790684776861 ("target/i386: reimplement 0x0f 0x3a, add AVX")
---
Am I the only one getting this? Or anything wrong in my setup.
Hi Eric,
no, you are not the only one. I regularly build with higher warning
levels, for example with -Weverything on macOS, and get a much longer
list which includes the mentioned warnings (see below).
The warnings for ops_sse.h are false positives, so I think no fix is
needed for 7.2. The compiler is not clever enough to see that the switch
statements handle all possible cases. It should be sufficient to replace
`case 3` by `default` to help the compiler and fix the warning. Your fix
might produce new compiler warnings because setting the variables to 0
has no effect.
Cheers
Stefan
../block/mirror.c:1024:13: warning: variable 'iostatus' may be
uninitialized when used here [-Wconditional-uninitialized]
../block/mirror.c:1498:20: warning: variable 'bounce_buf' may be
uninitialized when used here [-Wconditional-uninitialized]
../block/nbd.c:1208:24: warning: variable 'request_ret' may be
uninitialized when used here [-Wconditional-uninitialized]
../block/nbd.c:1266:24: warning: variable 'request_ret' may be
uninitialized when used here [-Wconditional-uninitialized]
../block/nbd.c:1424:20: warning: variable 'request_ret' may be
uninitialized when used here [-Wconditional-uninitialized]
../block/qcow2-snapshot.c:423:51: warning: variable 'snapshots_size' may
be uninitialized when used here [-Wconditional-uninitialized]
../block/qcow2.c:3236:23: warning: variable 'cur_bytes' may be
uninitialized when used here [-Wconditional-uninitialized]
../block/ssh.c:306:52: warning: variable 'server_hash_len' may be
uninitialized when used here [-Wconditional-uninitialized]
../block/ssh.c:313:45: warning: variable 'pubkey_type' may be
uninitialized when used here [-Wconditional-uninitialized]
../contrib/elf2dmp/main.c:138:17: warning: variable 'kwn' may be
uninitialized when used here [-Wconditional-uninitialized]
../contrib/elf2dmp/main.c:138:22: warning: variable 'kwa' may be
uninitialized when used here [-Wconditional-uninitialized]
../contrib/elf2dmp/main.c:138:27: warning: variable
'KdpDataBlockEncoded' may be uninitialized when used here
[-Wconditional-uninitialized]
../crypto/block-luks.c:844:29: warning: variable 'splitkeylen' may be
uninitialized when used here [-Wconditional-uninitialized]
../disas/m68k.c:1513:47: warning: variable 'flval' may be uninitialized
when used here [-Wconditional-uninitialized]
../dump/win_dump.c:105:18: warning: variable 'ptr64' may be
uninitialized when used here [-Wconditional-uninitialized]
../dump/win_dump.c:105:26: warning: variable 'ptr32' may be
uninitialized when used here [-Wconditional-uninitialized]
../gdbstub/gdbstub.c:1191:39: warning: variable 'pid' may be
uninitialized when used here [-Wconditional-uninitialized]
../gdbstub/gdbstub.c:1209:36: warning: variable 'tid' may be
uninitialized when used here [-Wconditional-uninitialized]
../hw/9pfs/9p.c:1911:13: warning: variable 'fidst' may be uninitialized
when used here [-Wconditional-uninitialized]
../hw/block/block.c:110:33: warning: variable 'bs' may be uninitialized
when used here [-Wconditional-uninitialized]
../hw/core/generic-loader.c:160:23: warning: variable 'entry' may be
uninitialized when used here [-Wconditional-uninitialized]
../hw/i386/intel_iommu.c:323:12: warning: variable 'entry' may be
uninitialized when used here [-Wconditional-uninitialized]
../hw/ide/ahci.c:968:60: warning: variable 'tbl_entry_size' may be
uninitialized when used here [-Wconditional-uninitialized]
../hw/microblaze/boot.c:107:42: warning: variable 'fdt_size' may be
uninitialized when used here [-Wconditional-uninitialized]
../hw/net/rtl8139.c:1801:20: warning: variable 'buf2' may be
uninitialized when used here [-Wconditional-uninitialized]
Re: [PATCH for 7.2?] target/i386: Remove compilation errors when -Werror=maybe-uninitialized
Hi, On 12/7/22 19:23, Richard Henderson wrote: > On 12/7/22 10:08, Eric Auger wrote: >> On 12/7/22 16:55, Stefan Hajnoczi wrote: I am using this configure cmd line: ./configure --prefix=/usr --sysconfdir=/etc --libexecdir=/usr/lib/qemu --target-list=x86_64-softmmu --docdir=/usr/share/doc/qemu --enable-kvm --extra-cflags=-O --enable-trace-backends=log --python=/usr/bin/python3 --extra-cflags=-Wall --extra-cflags=-Wundef --extra-cflags=-Wwrite-strings --extra-cflags=-Wmissing-prototypes --extra-cflags=-fno-strict-aliasing --extra-cflags=-fno-common --extra-cflags=-Werror=type-limits > If you added it manually then let's fix this in 8.0 since it's not > tested/supported and very few people will see this issue. >>> Did you create the ./configure command-line manually? Do you think >>> other people will hit this? >> no I did not. I just tried to install a fresh qemu repo and just ran the >> above configure command. > > Stefan's question is where did you get this configure command? this is the native unmodified configure from https://git.qemu.org/git/qemu.git/. > > If it came from an rpm script or suchlike, we might take more notice > than if this is just you adding --extra-cflags for your own testing. > > >> I am actually surprised nobody hit that already. > > Adding -Wall is not standard, nor all the other -W that you are > adding. I think you should not be surprised that you run into problems. OK that's a useful indication. I used to have this configure cmd line for a while and have not paid much attention to it until now, I acknowledge. This was useful to catch compilation errors at some point I guess. > > While you can make a case for auditing the code base and adding these > to the default set of warning flags, that's a job for the next > development cycle. Let me clarify, I am not insisting for that fix to land in 7.2 all the more so it is pretty late. I just wanted to report the compilation issue and since I use the std qemu pieces with a pretty standard tool chain I thought somebody else would be likely to hit the same problem. Thanks Eric > > > r~ >
[PATCH v4 1/4] qom: add default value
qmp_qom_list_properties can print default values if they are available as qmp_device_list_properties does, because both of them use the ObjectPropertyInfo structure with default_value field. This can be useful when working with "not device" types. Signed-off-by: Maksim Davydov Reviewed-by: Vladimir Sementsov-Ogievskiy --- qom/qom-qmp-cmds.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/qom/qom-qmp-cmds.c b/qom/qom-qmp-cmds.c index 2e63a4c184..1d7867dc19 100644 --- a/qom/qom-qmp-cmds.c +++ b/qom/qom-qmp-cmds.c @@ -217,6 +217,8 @@ ObjectPropertyInfoList *qmp_qom_list_properties(const char *typename, info->type = g_strdup(prop->type); info->has_description = !!prop->description; info->description = g_strdup(prop->description); +info->default_value = qobject_ref(prop->defval); +info->has_default_value = !!info->default_value; QAPI_LIST_PREPEND(prop_list, info); } -- 2.25.1
[PATCH v4 4/4] scripts: add script to compare compatible properties
This script run QEMU to obtain compat_props of machines and default
values of different types and produce appropriate table. This table
can be used to compare machine types to choose the most suitable
machine. Also this table in json or csv format should be used to check that
new machine doesn't affect previous ones by comparing tables with and
without new machine.
Default values of properties are needed to fill "holes" in the table (one
machine has these properties and another not. For instance, 2.12 mt has
`{ "EPYC-" TYPE_X86_CPU, "xlevel", "0x800a" }`, but compat_pros of
3.1 mt doesn't have it. So, to compare these machines we need to fill
unknown value of "EPYC-x86_64-cpu-xlevel" for 3.1 mt. This unknown value
in the table I called "hole". To get values (default values) for these
"holes" the script uses list of appropriate methods.)
Notes:
* some init values from the devices can't be available like properties
from virtio-9p when configure has --disable-virtfs. This situations will
be seen in the table as "unavailable driver".
* Default values can be obtained in an unobvious way, like x86 features.
If the script doesn't know how to get property default value to compare
one machine with another it fills "holes" with "unavailable method". This
is done because script uses whitelist model to get default values of
different types. It means that the method that can't be applied to a new
type that can crash this script. It is better to get an "unavailable
driver" when creating a new machine with new compatible properties than
to break this script. So it turns out a more stable and generic script.
* If the default value can't be obtained because this property doesn't
exist or because this property can't have default value, appropriate
"hole" will be filled by "unknown property" or "no default value"
* If the property is applied to the abstract class, the script collects
default values from all child classes (set of default values)
Example: ./scripts/compare_mt.py --mt pc-q35-3.1 pc-q35-4.0
╒═══╤══╤╕
│ │ pc-q35-3.1 │
pc-q35-4.0 │
╞═══╪══╪╡
│ Cascadelake-Server-x86_64-cpu:mpx │ True │
False│
├───┼──┼┤
│ Cascadelake-Server-x86_64-cpu:stepping│ 5 │
6 │
├───┼──┼┤
│ Icelake-Client-x86_64-cpu:mpx │ True │
unavailable driver │
├───┼──┼┤
│ Icelake-Server-x86_64-cpu:mpx │ True │
False│
├───┼──┼┤
│ Opteron_G3-x86_64-cpu:rdtscp │False │
True│
├───┼──┼┤
│ Opteron_G4-x86_64-cpu:rdtscp │False │
True│
├───┼──┼┤
│ Opteron_G5-x86_64-cpu:rdtscp │False │
True│
├───┼──┼┤
│ Skylake-Client-IBRS-x86_64-cpu:mpx│ True │
False│
├───┼──┼┤
│ Skylake-Client-x86_64-cpu:mpx │ True │
False│
├───┼──┼┤
│ Skylake-Server-IBRS-x86_64-cpu:mpx│ True │
False│
├───┼──┼┤
│ Skylake-Server-x86_64-cpu:mpx │ True │
False│
├───┼──┼┤
│ intel-iommu:dma-drain │False │
True│
├───┼──┼┤
│ memory-backend-file:x-use-canonical-path-for-ramblock-id │ True │
no default value │
├───┼──┼┤
│ memory-backend-memfd:x-use-canonical-path-for-ramblock-id │ True │
no default
[PATCH v4 0/4] compare machine type compat_props
This script is necessary to choose the best machine type in the appropriate cases. Also we have to check compat_props of the old MT after changes to be sure that they haven't broken old the MT. For example, pc_compat_3_1 of pc-q35-3.1 has Icelake-Client which was removed in March. v4 -> v3: * increase read buffer limit to limit value in libvirt * add caching of qmp requests to speed up the script v3 -> v2: * simplify adding new methods for getting QEMU default values * add typing * change concept from fixed dictionaries to classes v2 -> v1: * fix script code style and descriptions * reorder patches v1 -> previous iteration: * new default value print concept * QEMU python library is used to collect qmp data * remove auxiliary patches (that was used to fix `->get` sematics) * print compat_props in the correct order * delete `absract` field to reduce output JSON size Maksim Davydov (4): qom: add default value python/qmp: increase read buffer size qmp: add dump machine type compatible properties scripts: add script to compare compatible properties hw/core/machine-qmp-cmds.c| 22 +- python/qemu/qmp/qmp_client.py | 4 +- qapi/machine.json | 54 +++- qom/qom-qmp-cmds.c| 2 + scripts/compare_mt.py | 506 ++ tests/qtest/fuzz/qos_fuzz.c | 2 +- 6 files changed, 584 insertions(+), 6 deletions(-) create mode 100755 scripts/compare_mt.py -- 2.25.1
[PATCH v4 3/4] qmp: add dump machine type compatible properties
To control that creating new machine type doesn't affect the previous
types (their compat_props) and to check complex compat_props inheritance
we need qmp command to print machine type compatible properties.
This patch adds the ability to get list of all the compat_props of the
corresponding supported machines for their comparison via new optional
argument of "query-machines" command.
Signed-off-by: Maksim Davydov
Reviewed-by: Vladimir Sementsov-Ogievskiy
---
hw/core/machine-qmp-cmds.c | 22 ++-
qapi/machine.json | 54 +++--
tests/qtest/fuzz/qos_fuzz.c | 2 +-
3 files changed, 74 insertions(+), 4 deletions(-)
diff --git a/hw/core/machine-qmp-cmds.c b/hw/core/machine-qmp-cmds.c
index 4f4ab30f8c..a6fc387439 100644
--- a/hw/core/machine-qmp-cmds.c
+++ b/hw/core/machine-qmp-cmds.c
@@ -74,7 +74,8 @@ CpuInfoFastList *qmp_query_cpus_fast(Error **errp)
return head;
}
-MachineInfoList *qmp_query_machines(Error **errp)
+MachineInfoList *qmp_query_machines(bool has_compat_props, bool compat_props,
+Error **errp)
{
GSList *el, *machines = object_class_get_list(TYPE_MACHINE, false);
MachineInfoList *mach_list = NULL;
@@ -107,6 +108,25 @@ MachineInfoList *qmp_query_machines(Error **errp)
info->default_ram_id = g_strdup(mc->default_ram_id);
info->has_default_ram_id = true;
}
+if (compat_props && mc->compat_props) {
+int i;
+info->compat_props = NULL;
+CompatPropertyList **tail = &(info->compat_props);
+info->has_compat_props = true;
+
+for (i = 0; i < mc->compat_props->len; i++) {
+GlobalProperty *mt_prop = g_ptr_array_index(mc->compat_props,
+i);
+CompatProperty *prop;
+
+prop = g_malloc0(sizeof(*prop));
+prop->driver = g_strdup(mt_prop->driver);
+prop->property = g_strdup(mt_prop->property);
+prop->value = g_strdup(mt_prop->value);
+
+QAPI_LIST_APPEND(tail, prop);
+}
+}
QAPI_LIST_PREPEND(mach_list, info);
}
diff --git a/qapi/machine.json b/qapi/machine.json
index b9228a5e46..07d3b01358 100644
--- a/qapi/machine.json
+++ b/qapi/machine.json
@@ -127,6 +127,25 @@
##
{ 'command': 'query-cpus-fast', 'returns': [ 'CpuInfoFast' ] }
+##
+# @CompatProperty:
+#
+# Machine type compatible property. It's based on GlobalProperty and created
+# for machine type compat properties (see scripts)
+#
+# @driver: name of the driver that has GlobalProperty
+#
+# @property: global property name
+#
+# @value: global property value
+#
+# Since: 7.2
+##
+{ 'struct': 'CompatProperty',
+ 'data': { 'driver': 'str',
+'property': 'str',
+'value': 'str' } }
+
##
# @MachineInfo:
#
@@ -155,6 +174,9 @@
#
# @default-ram-id: the default ID of initial RAM memory backend (since 5.2)
#
+# @compat-props: List of compatible properties that defines machine type
+#(since 7.2)
+#
# Since: 1.2
##
{ 'struct': 'MachineInfo',
@@ -162,18 +184,46 @@
'*is-default': 'bool', 'cpu-max': 'int',
'hotpluggable-cpus': 'bool', 'numa-mem-supported': 'bool',
'deprecated': 'bool', '*default-cpu-type': 'str',
-'*default-ram-id': 'str' } }
+'*default-ram-id': 'str', '*compat-props': ['CompatProperty'] } }
##
# @query-machines:
#
# Return a list of supported machines
#
+# @compat-props: if true return will contain information about machine type
+#compatible properties (since 7.2)
+#
# Returns: a list of MachineInfo
#
# Since: 1.2
+#
+# Example:
+#
+# -> { "execute": "query-machines", "arguments": { "compat-props": true } }
+# <- { "return": [
+# {
+# "hotpluggable-cpus": true,
+# "name": "pc-q35-6.2",
+# "compat-props": [
+# {
+# "driver": "virtio-mem",
+# "property": "unplugged-inaccessible",
+# "value": "off"
+# }
+# ],
+# "numa-mem-supported": false,
+# "default-cpu-type": "qemu64-x86_64-cpu",
+# "cpu-max": 288,
+# "deprecated": false,
+# "default-ram-id": "pc.ram"
+# },
+# ...
+#}
##
-{ 'command': 'query-machines', 'returns': ['MachineInfo'] }
+{ 'command': 'query-machines',
+ 'data': { '*compat-props': 'bool' },
+ 'returns': ['MachineInfo'] }
##
# @CurrentMachineParams:
diff --git a/tests/qtest/fuzz/qos_fuzz.c b/tests/qtest/fuzz/qos_fuzz.c
index 3a3d9c16dd..9420f950fd 100644
--- a/tests/qtest/fuzz/qos_fuzz.c
+++ b/tests/qtest/fuzz/qos_fuzz.c
@@ -46,7 +46,7 @@ static void qos_set_machines_devices_available(void)
MachineInfoList *mach_info;
[PATCH v4 2/4] python/qmp: increase read buffer size
Current 256KB is not enough for some real cases. As a possible solution limit can be chosen to be the same as libvirt (10MB) Signed-off-by: Maksim Davydov --- python/qemu/qmp/qmp_client.py | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/python/qemu/qmp/qmp_client.py b/python/qemu/qmp/qmp_client.py index 5dcda04a75..b5772e7f32 100644 --- a/python/qemu/qmp/qmp_client.py +++ b/python/qemu/qmp/qmp_client.py @@ -197,8 +197,8 @@ async def run(self, address='/tmp/qemu.socket'): #: Logger object used for debugging messages. logger = logging.getLogger(__name__) -# Read buffer limit; large enough to accept query-qmp-schema -_limit = (256 * 1024) +# Read buffer limit; 10MB like libvirt default +_limit = (10 * 1024 * 1024) # Type alias for pending execute() result items _PendingT = Union[Message, ExecInterruptedError] -- 2.25.1
Re: [PATCH-for-8.0 2/4] gdbstub: Use vaddr type for generic insert/remove_breakpoint() API
On 7/12/22 19:23, Peter Maydell wrote:
On Wed, 7 Dec 2022 at 17:42, Philippe Mathieu-Daudé wrote:
Both insert/remove_breakpoint() handlers are used in system and
user emulation. We can not use the 'hwaddr' type on user emulation,
we have to use 'vaddr' which is defined as "wide enough to contain
any #target_ulong virtual address".
Signed-off-by: Philippe Mathieu-Daudé
---
gdbstub/internals.h| 6 --
include/sysemu/accel-ops.h | 6 +++---
2 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/gdbstub/internals.h b/gdbstub/internals.h
index eabb0341d1..b23999f951 100644
--- a/gdbstub/internals.h
+++ b/gdbstub/internals.h
@@ -9,9 +9,11 @@
#ifndef _INTERNALS_H_
#define _INTERNALS_H_
+#include "exec/cpu-common.h"
+
bool gdb_supports_guest_debug(void);
-int gdb_breakpoint_insert(CPUState *cs, int type, hwaddr addr, hwaddr len);
-int gdb_breakpoint_remove(CPUState *cs, int type, hwaddr addr, hwaddr len);
+int gdb_breakpoint_insert(CPUState *cs, int type, vaddr addr, vaddr len);
+int gdb_breakpoint_remove(CPUState *cs, int type, vaddr addr, vaddr len);
void gdb_breakpoint_remove_all(CPUState *cs);
#endif /* _INTERNALS_H_ */
diff --git a/include/sysemu/accel-ops.h b/include/sysemu/accel-ops.h
index 8cc7996def..30690c71bd 100644
--- a/include/sysemu/accel-ops.h
+++ b/include/sysemu/accel-ops.h
@@ -10,7 +10,7 @@
#ifndef ACCEL_OPS_H
#define ACCEL_OPS_H
-#include "exec/hwaddr.h"
+#include "exec/cpu-common.h"
#include "qom/object.h"
#define ACCEL_OPS_SUFFIX "-ops"
@@ -48,8 +48,8 @@ struct AccelOpsClass {
/* gdbstub hooks */
bool (*supports_guest_debug)(void);
-int (*insert_breakpoint)(CPUState *cpu, int type, hwaddr addr, hwaddr len);
-int (*remove_breakpoint)(CPUState *cpu, int type, hwaddr addr, hwaddr len);
+int (*insert_breakpoint)(CPUState *cpu, int type, vaddr addr, vaddr len);
+int (*remove_breakpoint)(CPUState *cpu, int type, vaddr addr, vaddr len);
void (*remove_all_breakpoints)(CPUState *cpu);
};
If you're changing the prototype of these methods on AccelOpsClass
don't you also want to change the implementations, eg tcg_breakpoint_insert()?
Interestingly that function calls cpu_breakpoint_insert() which
already takes a 'vaddr' rather than a 'hwaddr'.
Yes I neglected to include these changes here:
-- >8 --
diff --git a/gdbstub/gdbstub.c b/gdbstub/gdbstub.c
index be88ca0d71..c3fbc31123 100644
--- a/gdbstub/gdbstub.c
+++ b/gdbstub/gdbstub.c
@@ -48,7 +48,6 @@
#include "sysemu/runstate.h"
#include "semihosting/semihost.h"
#include "exec/exec-all.h"
-#include "exec/hwaddr.h"
#include "sysemu/replay.h"
#include "internals.h"
diff --git a/gdbstub/softmmu.c b/gdbstub/softmmu.c
index f208c6cf15..129575e510 100644
--- a/gdbstub/softmmu.c
+++ b/gdbstub/softmmu.c
@@ -11,7 +11,6 @@
#include "qemu/osdep.h"
#include "exec/gdbstub.h"
-#include "exec/hwaddr.h"
#include "sysemu/cpus.h"
#include "internals.h"
@@ -24,7 +23,7 @@ bool gdb_supports_guest_debug(void)
return false;
}
-int gdb_breakpoint_insert(CPUState *cs, int type, hwaddr addr, hwaddr len)
+int gdb_breakpoint_insert(CPUState *cs, int type, vaddr addr, vaddr len)
{
const AccelOpsClass *ops = cpus_get_accel();
if (ops->insert_breakpoint) {
@@ -33,7 +32,7 @@ int gdb_breakpoint_insert(CPUState *cs, int type,
hwaddr addr, hwaddr len)
return -ENOSYS;
}
-int gdb_breakpoint_remove(CPUState *cs, int type, hwaddr addr, hwaddr len)
+int gdb_breakpoint_remove(CPUState *cs, int type, vaddr addr, vaddr len)
{
const AccelOpsClass *ops = cpus_get_accel();
if (ops->remove_breakpoint) {
diff --git a/gdbstub/user.c b/gdbstub/user.c
index 033e5fdd71..484bd8f461 100644
--- a/gdbstub/user.c
+++ b/gdbstub/user.c
@@ -9,7 +9,6 @@
*/
#include "qemu/osdep.h"
-#include "exec/hwaddr.h"
#include "exec/gdbstub.h"
#include "hw/core/cpu.h"
#include "internals.h"
@@ -20,7 +19,7 @@ bool gdb_supports_guest_debug(void)
return true;
}
-int gdb_breakpoint_insert(CPUState *cs, int type, hwaddr addr, hwaddr len)
+int gdb_breakpoint_insert(CPUState *cs, int type, vaddr addr, vaddr len)
{
CPUState *cpu;
int err = 0;
@@ -41,7 +40,7 @@ int gdb_breakpoint_insert(CPUState *cs, int type,
hwaddr addr, hwaddr len)
}
}
-int gdb_breakpoint_remove(CPUState *cs, int type, hwaddr addr, hwaddr len)
+int gdb_breakpoint_remove(CPUState *cs, int type, vaddr addr, vaddr len)
{
CPUState *cpu;
int err = 0;
---
In looking at this I discovered some rather confusing gdbstub behaviour:
if you use the qemu.PhyMemMode custom gdb flag to put the stub into
"physical memory mode", data reads and writes are done on physical
addresses, but breakpoints and watchpoints continue to take virtual
addresses.
But at any rate given that currently breakpoints are always on virtual
addresses, vaddr is definitely the right type here and probably all
the way down through the callstack.
thanks
-- PMM
Re: [PATCH for 7.2?] target/i386: Remove compilation errors when -Werror=maybe-uninitialized
On 12/7/22 10:08, Eric Auger wrote: On 12/7/22 16:55, Stefan Hajnoczi wrote: I am using this configure cmd line: ./configure --prefix=/usr --sysconfdir=/etc --libexecdir=/usr/lib/qemu --target-list=x86_64-softmmu --docdir=/usr/share/doc/qemu --enable-kvm --extra-cflags=-O --enable-trace-backends=log --python=/usr/bin/python3 --extra-cflags=-Wall --extra-cflags=-Wundef --extra-cflags=-Wwrite-strings --extra-cflags=-Wmissing-prototypes --extra-cflags=-fno-strict-aliasing --extra-cflags=-fno-common --extra-cflags=-Werror=type-limits If you added it manually then let's fix this in 8.0 since it's not tested/supported and very few people will see this issue. Did you create the ./configure command-line manually? Do you think other people will hit this? no I did not. I just tried to install a fresh qemu repo and just ran the above configure command. Stefan's question is where did you get this configure command? If it came from an rpm script or suchlike, we might take more notice than if this is just you adding --extra-cflags for your own testing. I am actually surprised nobody hit that already. Adding -Wall is not standard, nor all the other -W that you are adding. I think you should not be surprised that you run into problems. While you can make a case for auditing the code base and adding these to the default set of warning flags, that's a job for the next development cycle. r~
Re: [PATCH-for-8.0 2/4] gdbstub: Use vaddr type for generic insert/remove_breakpoint() API
On Wed, 7 Dec 2022 at 17:42, Philippe Mathieu-Daudé wrote:
>
> Both insert/remove_breakpoint() handlers are used in system and
> user emulation. We can not use the 'hwaddr' type on user emulation,
> we have to use 'vaddr' which is defined as "wide enough to contain
> any #target_ulong virtual address".
>
> Signed-off-by: Philippe Mathieu-Daudé
> ---
> gdbstub/internals.h| 6 --
> include/sysemu/accel-ops.h | 6 +++---
> 2 files changed, 7 insertions(+), 5 deletions(-)
>
> diff --git a/gdbstub/internals.h b/gdbstub/internals.h
> index eabb0341d1..b23999f951 100644
> --- a/gdbstub/internals.h
> +++ b/gdbstub/internals.h
> @@ -9,9 +9,11 @@
> #ifndef _INTERNALS_H_
> #define _INTERNALS_H_
>
> +#include "exec/cpu-common.h"
> +
> bool gdb_supports_guest_debug(void);
> -int gdb_breakpoint_insert(CPUState *cs, int type, hwaddr addr, hwaddr len);
> -int gdb_breakpoint_remove(CPUState *cs, int type, hwaddr addr, hwaddr len);
> +int gdb_breakpoint_insert(CPUState *cs, int type, vaddr addr, vaddr len);
> +int gdb_breakpoint_remove(CPUState *cs, int type, vaddr addr, vaddr len);
> void gdb_breakpoint_remove_all(CPUState *cs);
>
> #endif /* _INTERNALS_H_ */
> diff --git a/include/sysemu/accel-ops.h b/include/sysemu/accel-ops.h
> index 8cc7996def..30690c71bd 100644
> --- a/include/sysemu/accel-ops.h
> +++ b/include/sysemu/accel-ops.h
> @@ -10,7 +10,7 @@
> #ifndef ACCEL_OPS_H
> #define ACCEL_OPS_H
>
> -#include "exec/hwaddr.h"
> +#include "exec/cpu-common.h"
> #include "qom/object.h"
>
> #define ACCEL_OPS_SUFFIX "-ops"
> @@ -48,8 +48,8 @@ struct AccelOpsClass {
>
> /* gdbstub hooks */
> bool (*supports_guest_debug)(void);
> -int (*insert_breakpoint)(CPUState *cpu, int type, hwaddr addr, hwaddr
> len);
> -int (*remove_breakpoint)(CPUState *cpu, int type, hwaddr addr, hwaddr
> len);
> +int (*insert_breakpoint)(CPUState *cpu, int type, vaddr addr, vaddr len);
> +int (*remove_breakpoint)(CPUState *cpu, int type, vaddr addr, vaddr len);
> void (*remove_all_breakpoints)(CPUState *cpu);
> };
If you're changing the prototype of these methods on AccelOpsClass
don't you also want to change the implementations, eg tcg_breakpoint_insert()?
Interestingly that function calls cpu_breakpoint_insert() which
already takes a 'vaddr' rather than a 'hwaddr'.
In looking at this I discovered some rather confusing gdbstub behaviour:
if you use the qemu.PhyMemMode custom gdb flag to put the stub into
"physical memory mode", data reads and writes are done on physical
addresses, but breakpoints and watchpoints continue to take virtual
addresses.
But at any rate given that currently breakpoints are always on virtual
addresses, vaddr is definitely the right type here and probably all
the way down through the callstack.
thanks
-- PMM
Re: [PATCH for 7.2?] target/i386: Remove compilation errors when -Werror=maybe-uninitialized
On 12/7/22 17:55, Philippe Mathieu-Daudé wrote:
> On 7/12/22 15:33, Eric Auger wrote:
>> On 12/7/22 15:09, Stefan Hajnoczi wrote:
>>> On Wed, 7 Dec 2022 at 08:31, Eric Auger wrote:
On 12/7/22 14:24, Eric Auger wrote:
> Initialize r0-3 to avoid compilation errors when
> -Werror=maybe-uninitialized is used
>
> ../target/i386/ops_sse.h: In function ‘helper_vpermdq_ymm’:
> ../target/i386/ops_sse.h:2495:13: error: ‘r3’ may be used
> uninitialized in this function [-Werror=maybe-uninitialized]
> 2495 | d->Q(3) = r3;
> | ^~~~
> ../target/i386/ops_sse.h:2494:13: error: ‘r2’ may be used
> uninitialized in this function [-Werror=maybe-uninitialized]
> 2494 | d->Q(2) = r2;
> | ^~~~
> ../target/i386/ops_sse.h:2493:13: error: ‘r1’ may be used
> uninitialized in this function [-Werror=maybe-uninitialized]
> 2493 | d->Q(1) = r1;
> | ^~~~
> ../target/i386/ops_sse.h:2492:13: error: ‘r0’ may be used
> uninitialized in this function [-Werror=maybe-uninitialized]
> 2492 | d->Q(0) = r0;
> | ^~~~
>
> Signed-off-by: Eric Auger
> Fixes: 790684776861 ("target/i386: reimplement 0x0f 0x3a, add AVX")
>
> ---
>
> Am I the only one getting this? Or anything wrong in my setup.
With Stefan's correct address. Forgive me for the noise.
>>> When is -Wmaybe-uninitialized used? QEMU's build system doesn't set
>>> it. Unless it's automatically set by meson this must be a manual
>>> --extra-cflags= option you set.
>>
>> I am using this configure cmd line:
>>
>> ./configure --prefix=/usr --sysconfdir=/etc --libexecdir=/usr/lib/qemu
>> --target-list=x86_64-softmmu --docdir=/usr/share/doc/qemu --enable-kvm
>> --extra-cflags=-O --enable-trace-backends=log --python=/usr/bin/python3
>> --extra-cflags=-Wall --extra-cflags=-Wundef
>> --extra-cflags=-Wwrite-strings --extra-cflags=-Wmissing-prototypes
>> --extra-cflags=-fno-strict-aliasing --extra-cflags=-fno-common
>> --extra-cflags=-Werror=type-limits
>>>
>>> If you added it manually then let's fix this in 8.0 since it's not
>>> tested/supported and very few people will see this issue.
> Please include the relevant meson output in the commit description, i.e.:
>
> C compiler for the host machine: clang (clang 14.0.0 "Apple clang
> version 14.0.0 (clang-1400.0.29.202)")
> C linker for the host machine: clang ld64 820.1
>
> Compilation
> host CPU : aarch64
> host endianness : little
> C compiler : clang
> Host C compiler : clang
> C++ compiler : c++
> Objective-C compiler : clang
> CFLAGS : -ggdb
> -Werror=incompatible-function-pointer-types -O2 -g
> CXXFLAGS : -ggdb
> -Werror=incompatible-function-pointer-types -O2 -g
> OBJCFLAGS : -ggdb
> -Werror=incompatible-function-pointer-types -ggdb -O2 -g
> LDFLAGS : -ggdb
> -Werror=incompatible-function-pointer-types
> QEMU_CFLAGS : ...
> QEMU_CXXFLAGS : ...
> QEMU_OBJCFLAGS : ...
> QEMU_LDFLAGS : -fstack-protector-strong
Here is the data:
C compiler for the host machine: cc -m64 -mcx16 (gcc 11.3.1 "cc (GCC)
11.3.1 20220421 (Red Hat 11.3.1-2)")
C linker for the host machine: cc -m64 -mcx16 ld.bfd 2.35.2-24
Compilation
host CPU : x86_64
host endianness : little
C compiler : cc -m64 -mcx16
Host C compiler : cc -m64 -mcx16
C++ compiler : c++ -m64 -mcx16
CFLAGS : -O -Wall -Wundef -Wwrite-strings
-Wmissing-prototypes -fno-strict-aliasing -fno-common
-Werror=type-limits -O2 -g
CXXFLAGS : -O -Wall -Wundef -Wwrite-strings
-Wmissing-prototypes -fno-strict-aliasing -fno-common
-Werror=type-limits -O2 -g
LDFLAGS : -O -Wall -Wundef -Wwrite-strings
-Wmissing-prototypes -fno-strict-aliasing -fno-common -Werror=type-limits
QEMU_CFLAGS : -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2
-D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE
-Wstrict-prototypes -Wredundant-decls -Wundef -Wwrite-strings
-Wmissing-prototypes -fno-strict-aliasing -fno-common -fwrapv
-Wold-style-declaration -Wold-style-definition -Wtype-limits
-Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers
-Wempty-body -Wnested-externs -Wendif-labels -Wexpansion-to-defined
-Wimplicit-fallthrough=2 -Wno-missing-include-dirs
-Wno-shift-negative-value -Wno-psabi -fstack-protector-strong
QEMU_CXXFLAGS : -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2
-D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wundef
-Wwrite-strings -fno-strict-aliasing -fno-common -fwrapv -Wtype-limits
-Wformat-security
Re: [PATCH-for-8.0 2/4] gdbstub: Use vaddr type for generic insert/remove_breakpoint() API
On 7/12/22 19:08, Fabiano Rosas wrote:
Philippe Mathieu-Daudé writes:
Both insert/remove_breakpoint() handlers are used in system and
user emulation. We can not use the 'hwaddr' type on user emulation,
we have to use 'vaddr' which is defined as "wide enough to contain
any #target_ulong virtual address".
Signed-off-by: Philippe Mathieu-Daudé
---
gdbstub/internals.h| 6 --
include/sysemu/accel-ops.h | 6 +++---
2 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/gdbstub/internals.h b/gdbstub/internals.h
index eabb0341d1..b23999f951 100644
--- a/gdbstub/internals.h
+++ b/gdbstub/internals.h
@@ -9,9 +9,11 @@
#ifndef _INTERNALS_H_
#define _INTERNALS_H_
+#include "exec/cpu-common.h"
+
bool gdb_supports_guest_debug(void);
-int gdb_breakpoint_insert(CPUState *cs, int type, hwaddr addr, hwaddr len);
-int gdb_breakpoint_remove(CPUState *cs, int type, hwaddr addr, hwaddr len);
+int gdb_breakpoint_insert(CPUState *cs, int type, vaddr addr, vaddr len);
+int gdb_breakpoint_remove(CPUState *cs, int type, vaddr addr, vaddr len);
Now we should be able to remove the "exec/hwaddr.h" include from
gdbstub.c
Yes. And you made me notice I didn't commit the changes in
gdbstub/{system,user}.c...
Re: [PATCH-for-8.0 2/4] gdbstub: Use vaddr type for generic insert/remove_breakpoint() API
Philippe Mathieu-Daudé writes:
> Both insert/remove_breakpoint() handlers are used in system and
> user emulation. We can not use the 'hwaddr' type on user emulation,
> we have to use 'vaddr' which is defined as "wide enough to contain
> any #target_ulong virtual address".
>
> Signed-off-by: Philippe Mathieu-Daudé
> ---
> gdbstub/internals.h| 6 --
> include/sysemu/accel-ops.h | 6 +++---
> 2 files changed, 7 insertions(+), 5 deletions(-)
>
> diff --git a/gdbstub/internals.h b/gdbstub/internals.h
> index eabb0341d1..b23999f951 100644
> --- a/gdbstub/internals.h
> +++ b/gdbstub/internals.h
> @@ -9,9 +9,11 @@
> #ifndef _INTERNALS_H_
> #define _INTERNALS_H_
>
> +#include "exec/cpu-common.h"
> +
> bool gdb_supports_guest_debug(void);
> -int gdb_breakpoint_insert(CPUState *cs, int type, hwaddr addr, hwaddr len);
> -int gdb_breakpoint_remove(CPUState *cs, int type, hwaddr addr, hwaddr len);
> +int gdb_breakpoint_insert(CPUState *cs, int type, vaddr addr, vaddr len);
> +int gdb_breakpoint_remove(CPUState *cs, int type, vaddr addr, vaddr len);
Now we should be able to remove the "exec/hwaddr.h" include from
gdbstub.c
> void gdb_breakpoint_remove_all(CPUState *cs);
>
> #endif /* _INTERNALS_H_ */
> diff --git a/include/sysemu/accel-ops.h b/include/sysemu/accel-ops.h
> index 8cc7996def..30690c71bd 100644
> --- a/include/sysemu/accel-ops.h
> +++ b/include/sysemu/accel-ops.h
> @@ -10,7 +10,7 @@
> #ifndef ACCEL_OPS_H
> #define ACCEL_OPS_H
>
> -#include "exec/hwaddr.h"
> +#include "exec/cpu-common.h"
> #include "qom/object.h"
>
> #define ACCEL_OPS_SUFFIX "-ops"
> @@ -48,8 +48,8 @@ struct AccelOpsClass {
>
> /* gdbstub hooks */
> bool (*supports_guest_debug)(void);
> -int (*insert_breakpoint)(CPUState *cpu, int type, hwaddr addr, hwaddr
> len);
> -int (*remove_breakpoint)(CPUState *cpu, int type, hwaddr addr, hwaddr
> len);
> +int (*insert_breakpoint)(CPUState *cpu, int type, vaddr addr, vaddr len);
> +int (*remove_breakpoint)(CPUState *cpu, int type, vaddr addr, vaddr len);
> void (*remove_all_breakpoints)(CPUState *cpu);
> };
Re: [PATCH v3 1/2] hw/nvme: Implement shadow doorbell buffer support
Hi, On Thu, Jun 16, 2022 at 08:34:07PM +0800, Jinhao Fan wrote: > Implement Doorbel Buffer Config command (Section 5.7 in NVMe Spec 1.3) > and Shadow Doorbel buffer & EventIdx buffer handling logic (Section 7.13 > in NVMe Spec 1.3). For queues created before the Doorbell Buffer Config > command, the nvme_dbbuf_config function tries to associate each existing > SQ and CQ with its Shadow Doorbel buffer and EventIdx buffer address. > Queues created after the Doorbell Buffer Config command will have the > doorbell buffers associated with them when they are initialized. > > In nvme_process_sq and nvme_post_cqe, proactively check for Shadow > Doorbell buffer changes instead of wait for doorbell register changes. > This reduces the number of MMIOs. > > In nvme_process_db(), update the shadow doorbell buffer value with > the doorbell register value if it is the admin queue. This is a hack > since hosts like Linux NVMe driver and SPDK do not use shadow > doorbell buffer for the admin queue. Copying the doorbell register > value to the shadow doorbell buffer allows us to support these hosts > as well as spec-compliant hosts that use shadow doorbell buffer for > the admin queue. > > Signed-off-by: Jinhao Fan I noticed that I can no longer boot Linux kernels from nvme on riscv64 systems. The problem is seen with qemu v7.1 and qemu v7.2-rc4. The log shows: [ 35.904128] nvme nvme0: I/O 642 (I/O Cmd) QID 1 timeout, aborting [ 35.905000] EXT4-fs (nvme0n1): mounting ext2 file system using the ext4 subsystem [ 66.623863] nvme nvme0: I/O 643 (I/O Cmd) QID 1 timeout, aborting [ 97.343989] nvme nvme0: Abort status: 0x0 [ 97.344355] nvme nvme0: Abort status: 0x0 [ 97.344647] nvme nvme0: I/O 7 QID 0 timeout, reset controller [ 97.350568] nvme nvme0: I/O 644 (I/O Cmd) QID 1 timeout, aborting This is with the mainline Linux kernel (v6.1-rc8). Bisect points to this patch. Reverting this patch and a number of associated patches (to fix conflicts) fixes the problem. 06143d8771 Revert "hw/nvme: Implement shadow doorbell buffer support" acb4443e3a Revert "hw/nvme: Use ioeventfd to handle doorbell updates" d5fd309feb Revert "hw/nvme: do not enable ioeventfd by default" 1ca1e6c47c Revert "hw/nvme: unregister the event notifier handler on the main loop" 2d26abd51e Revert "hw/nvme: skip queue processing if notifier is cleared" 99d411b5a5 Revert "hw/nvme: reenable cqe batching" 2293d3ca6c Revert "hw/nvme: Add trace events for shadow doorbell buffer" Qemu command line: qemu-system-riscv64 -M virt -m 512M \ -kernel arch/riscv/boot/Image -snapshot \ -device nvme,serial=foo,drive=d0 \ -drive file=rootfs.ext2,if=none,format=raw,id=d0 \ -bios default \ -append "root=/dev/nvme0n1 console=ttyS0,115200 earlycon=uart8250,mmio,0x1000,115200" \ -nographic -monitor none Guenter
Re: [PATCH for-8.0] hw/rtc/mc146818rtc: Make this rtc device target independent
On 07/12/2022 16:20, Bernhard Beschow wrote:
Am 7. Dezember 2022 15:29:00 UTC schrieb Mark Cave-Ayland
:
On 06/12/2022 20:06, Thomas Huth wrote:
The only code that is really, really target dependent is the apic-related
code in rtc_policy_slew_deliver_irq(). By moving this code into the hw/i386/
folder (renamed to rtc_apic_policy_slew_deliver_irq()) and passing this
function as parameter to mc146818_rtc_init(), we can make the RTC completely
target-independent.
Signed-off-by: Thomas Huth
---
include/hw/rtc/mc146818rtc.h | 7 +--
hw/alpha/dp264.c | 2 +-
hw/hppa/machine.c| 2 +-
hw/i386/microvm.c| 3 ++-
hw/i386/pc.c | 10 +-
hw/mips/jazz.c | 2 +-
hw/ppc/pnv.c | 2 +-
hw/rtc/mc146818rtc.c | 34 +++---
hw/rtc/meson.build | 3 +--
9 files changed, 32 insertions(+), 33 deletions(-)
diff --git a/include/hw/rtc/mc146818rtc.h b/include/hw/rtc/mc146818rtc.h
index 1db0fcee92..c687953cc4 100644
--- a/include/hw/rtc/mc146818rtc.h
+++ b/include/hw/rtc/mc146818rtc.h
@@ -46,14 +46,17 @@ struct RTCState {
Notifier clock_reset_notifier;
LostTickPolicy lost_tick_policy;
Notifier suspend_notifier;
+bool (*policy_slew_deliver_irq)(RTCState *s);
QLIST_ENTRY(RTCState) link;
};
#define RTC_ISA_IRQ 8
-ISADevice *mc146818_rtc_init(ISABus *bus, int base_year,
- qemu_irq intercept_irq);
+ISADevice *mc146818_rtc_init(ISABus *bus, int base_year, qemu_irq
intercept_irq,
+ bool (*policy_slew_deliver_irq)(RTCState *s));
void rtc_set_memory(ISADevice *dev, int addr, int val);
int rtc_get_memory(ISADevice *dev, int addr);
+bool rtc_apic_policy_slew_deliver_irq(RTCState *s);
+void qmp_rtc_reset_reinjection(Error **errp);
#endif /* HW_RTC_MC146818RTC_H */
diff --git a/hw/alpha/dp264.c b/hw/alpha/dp264.c
index c502c8c62a..8723942b52 100644
--- a/hw/alpha/dp264.c
+++ b/hw/alpha/dp264.c
@@ -118,7 +118,7 @@ static void clipper_init(MachineState *machine)
qdev_connect_gpio_out(i82378_dev, 0, isa_irq);
/* Since we have an SRM-compatible PALcode, use the SRM epoch. */
-mc146818_rtc_init(isa_bus, 1900, rtc_irq);
+mc146818_rtc_init(isa_bus, 1900, rtc_irq, NULL);
/* VGA setup. Don't bother loading the bios. */
pci_vga_init(pci_bus);
diff --git a/hw/hppa/machine.c b/hw/hppa/machine.c
index de1cc7ab71..311031714a 100644
--- a/hw/hppa/machine.c
+++ b/hw/hppa/machine.c
@@ -232,7 +232,7 @@ static void machine_hppa_init(MachineState *machine)
assert(isa_bus);
/* Realtime clock, used by firmware for PDC_TOD call. */
-mc146818_rtc_init(isa_bus, 2000, NULL);
+mc146818_rtc_init(isa_bus, 2000, NULL, NULL);
/* Serial ports: Lasi and Dino use a 7.272727 MHz clock. */
serial_mm_init(addr_space, LASI_UART_HPA + 0x800, 0,
diff --git a/hw/i386/microvm.c b/hw/i386/microvm.c
index 170a331e3f..d0ed4dca50 100644
--- a/hw/i386/microvm.c
+++ b/hw/i386/microvm.c
@@ -267,7 +267,8 @@ static void microvm_devices_init(MicrovmMachineState *mms)
if (mms->rtc == ON_OFF_AUTO_ON ||
(mms->rtc == ON_OFF_AUTO_AUTO && !kvm_enabled())) {
-rtc_state = mc146818_rtc_init(isa_bus, 2000, NULL);
+rtc_state = mc146818_rtc_init(isa_bus, 2000, NULL,
+ rtc_apic_policy_slew_deliver_irq);
microvm_set_rtc(mms, rtc_state);
}
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index 546b703cb4..650e7bc199 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -1244,6 +1244,13 @@ static void pc_superio_init(ISABus *isa_bus, bool
create_fdctrl,
g_free(a20_line);
}
+bool rtc_apic_policy_slew_deliver_irq(RTCState *s)
+{
+apic_reset_irq_delivered();
+qemu_irq_raise(s->irq);
+return apic_get_irq_delivered();
+}
+
void pc_basic_device_init(struct PCMachineState *pcms,
ISABus *isa_bus, qemu_irq *gsi,
ISADevice **rtc_state,
@@ -1299,7 +1306,8 @@ void pc_basic_device_init(struct PCMachineState *pcms,
pit_alt_irq = qdev_get_gpio_in(hpet, HPET_LEGACY_PIT_INT);
rtc_irq = qdev_get_gpio_in(hpet, HPET_LEGACY_RTC_INT);
}
-*rtc_state = mc146818_rtc_init(isa_bus, 2000, rtc_irq);
+*rtc_state = mc146818_rtc_init(isa_bus, 2000, rtc_irq,
+ rtc_apic_policy_slew_deliver_irq);
qemu_register_boot_set(pc_boot_set, *rtc_state);
diff --git a/hw/mips/jazz.c b/hw/mips/jazz.c
index 6aefe9a61b..50fbd57b23 100644
--- a/hw/mips/jazz.c
+++ b/hw/mips/jazz.c
@@ -356,7 +356,7 @@ static void mips_jazz_init(MachineState *machine,
fdctrl_init_sysbus(qdev_get_gpio_in(rc4030, 1), 0x80003000, fds);
/* Real time clock */
-mc146818_rtc_init(isa_bus, 1980, NULL);
+mc146818_rtc_init(isa_bus, 1980, NULL, NULL);
[PATCH-for-8.0 2/4] gdbstub: Use vaddr type for generic insert/remove_breakpoint() API
Both insert/remove_breakpoint() handlers are used in system and
user emulation. We can not use the 'hwaddr' type on user emulation,
we have to use 'vaddr' which is defined as "wide enough to contain
any #target_ulong virtual address".
Signed-off-by: Philippe Mathieu-Daudé
---
gdbstub/internals.h| 6 --
include/sysemu/accel-ops.h | 6 +++---
2 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/gdbstub/internals.h b/gdbstub/internals.h
index eabb0341d1..b23999f951 100644
--- a/gdbstub/internals.h
+++ b/gdbstub/internals.h
@@ -9,9 +9,11 @@
#ifndef _INTERNALS_H_
#define _INTERNALS_H_
+#include "exec/cpu-common.h"
+
bool gdb_supports_guest_debug(void);
-int gdb_breakpoint_insert(CPUState *cs, int type, hwaddr addr, hwaddr len);
-int gdb_breakpoint_remove(CPUState *cs, int type, hwaddr addr, hwaddr len);
+int gdb_breakpoint_insert(CPUState *cs, int type, vaddr addr, vaddr len);
+int gdb_breakpoint_remove(CPUState *cs, int type, vaddr addr, vaddr len);
void gdb_breakpoint_remove_all(CPUState *cs);
#endif /* _INTERNALS_H_ */
diff --git a/include/sysemu/accel-ops.h b/include/sysemu/accel-ops.h
index 8cc7996def..30690c71bd 100644
--- a/include/sysemu/accel-ops.h
+++ b/include/sysemu/accel-ops.h
@@ -10,7 +10,7 @@
#ifndef ACCEL_OPS_H
#define ACCEL_OPS_H
-#include "exec/hwaddr.h"
+#include "exec/cpu-common.h"
#include "qom/object.h"
#define ACCEL_OPS_SUFFIX "-ops"
@@ -48,8 +48,8 @@ struct AccelOpsClass {
/* gdbstub hooks */
bool (*supports_guest_debug)(void);
-int (*insert_breakpoint)(CPUState *cpu, int type, hwaddr addr, hwaddr len);
-int (*remove_breakpoint)(CPUState *cpu, int type, hwaddr addr, hwaddr len);
+int (*insert_breakpoint)(CPUState *cpu, int type, vaddr addr, vaddr len);
+int (*remove_breakpoint)(CPUState *cpu, int type, vaddr addr, vaddr len);
void (*remove_all_breakpoints)(CPUState *cpu);
};
--
2.38.1
[PATCH-for-8.0 0/4] target/cpu: System/User cleanups around hwaddr/vaddr
We are not supposed to use hwaddr on user emulation. This series is a - trivial - preparatory cleanup before few refactors to isolate further System vs User code. Philippe Mathieu-Daudé (4): cputlb: Restrict SavedIOTLB to system emulation gdbstub: Use vaddr type for generic insert/remove_breakpoint() API target/cpu: Restrict cpu_get_phys_page_debug() handlers to sysemu target/sparc: Cleanup around sparc_cpu_do_unaligned_access() accel/tcg/cputlb.c | 4 ++-- gdbstub/internals.h| 6 -- include/hw/core/cpu.h | 6 -- include/sysemu/accel-ops.h | 6 +++--- target/alpha/cpu.h | 2 +- target/cris/cpu.h | 3 +-- target/hppa/cpu.h | 2 +- target/m68k/cpu.h | 2 +- target/nios2/cpu.h | 2 +- target/openrisc/cpu.h | 3 ++- target/ppc/cpu.h | 2 +- target/rx/cpu.h| 2 +- target/rx/helper.c | 4 ++-- target/sh4/cpu.h | 2 +- target/sparc/cpu.h | 3 ++- target/sparc/mmu_helper.c | 2 -- target/xtensa/cpu.h| 2 +- 17 files changed, 28 insertions(+), 25 deletions(-) -- 2.38.1
[PATCH-for-8.0 3/4] target/cpu: Restrict cpu_get_phys_page_debug() handlers to sysemu
cpu_get_phys_page_debug() is a system-emulation specific handler.
Signed-off-by: Philippe Mathieu-Daudé
---
target/alpha/cpu.h| 2 +-
target/cris/cpu.h | 3 +--
target/hppa/cpu.h | 2 +-
target/m68k/cpu.h | 2 +-
target/nios2/cpu.h| 2 +-
target/openrisc/cpu.h | 3 ++-
target/ppc/cpu.h | 2 +-
target/rx/cpu.h | 2 +-
target/rx/helper.c| 4 ++--
target/sh4/cpu.h | 2 +-
target/sparc/cpu.h| 3 ++-
target/xtensa/cpu.h | 2 +-
12 files changed, 15 insertions(+), 14 deletions(-)
diff --git a/target/alpha/cpu.h b/target/alpha/cpu.h
index d0abc949a8..5e67304d81 100644
--- a/target/alpha/cpu.h
+++ b/target/alpha/cpu.h
@@ -276,9 +276,9 @@ extern const VMStateDescription vmstate_alpha_cpu;
void alpha_cpu_do_interrupt(CPUState *cpu);
bool alpha_cpu_exec_interrupt(CPUState *cpu, int int_req);
+hwaddr alpha_cpu_get_phys_page_debug(CPUState *cpu, vaddr addr);
#endif /* !CONFIG_USER_ONLY */
void alpha_cpu_dump_state(CPUState *cs, FILE *f, int flags);
-hwaddr alpha_cpu_get_phys_page_debug(CPUState *cpu, vaddr addr);
int alpha_cpu_gdb_read_register(CPUState *cpu, GByteArray *buf, int reg);
int alpha_cpu_gdb_write_register(CPUState *cpu, uint8_t *buf, int reg);
diff --git a/target/cris/cpu.h b/target/cris/cpu.h
index e6776f25b1..71fa1f96e0 100644
--- a/target/cris/cpu.h
+++ b/target/cris/cpu.h
@@ -193,12 +193,11 @@ bool cris_cpu_exec_interrupt(CPUState *cpu, int int_req);
bool cris_cpu_tlb_fill(CPUState *cs, vaddr address, int size,
MMUAccessType access_type, int mmu_idx,
bool probe, uintptr_t retaddr);
+hwaddr cris_cpu_get_phys_page_debug(CPUState *cpu, vaddr addr);
#endif
void cris_cpu_dump_state(CPUState *cs, FILE *f, int flags);
-hwaddr cris_cpu_get_phys_page_debug(CPUState *cpu, vaddr addr);
-
int crisv10_cpu_gdb_read_register(CPUState *cpu, GByteArray *buf, int reg);
int cris_cpu_gdb_read_register(CPUState *cpu, GByteArray *buf, int reg);
int cris_cpu_gdb_write_register(CPUState *cpu, uint8_t *buf, int reg);
diff --git a/target/hppa/cpu.h b/target/hppa/cpu.h
index 6f3b6beecf..b595ef25a9 100644
--- a/target/hppa/cpu.h
+++ b/target/hppa/cpu.h
@@ -322,11 +322,11 @@ static inline void cpu_hppa_change_prot_id(CPUHPPAState
*env) { }
void cpu_hppa_change_prot_id(CPUHPPAState *env);
#endif
-hwaddr hppa_cpu_get_phys_page_debug(CPUState *cs, vaddr addr);
int hppa_cpu_gdb_read_register(CPUState *cpu, GByteArray *buf, int reg);
int hppa_cpu_gdb_write_register(CPUState *cpu, uint8_t *buf, int reg);
void hppa_cpu_dump_state(CPUState *cs, FILE *f, int);
#ifndef CONFIG_USER_ONLY
+hwaddr hppa_cpu_get_phys_page_debug(CPUState *cs, vaddr addr);
bool hppa_cpu_tlb_fill(CPUState *cs, vaddr address, int size,
MMUAccessType access_type, int mmu_idx,
bool probe, uintptr_t retaddr);
diff --git a/target/m68k/cpu.h b/target/m68k/cpu.h
index 3a9cfe2f33..68ed531fc3 100644
--- a/target/m68k/cpu.h
+++ b/target/m68k/cpu.h
@@ -176,9 +176,9 @@ struct ArchCPU {
#ifndef CONFIG_USER_ONLY
void m68k_cpu_do_interrupt(CPUState *cpu);
bool m68k_cpu_exec_interrupt(CPUState *cpu, int int_req);
+hwaddr m68k_cpu_get_phys_page_debug(CPUState *cpu, vaddr addr);
#endif /* !CONFIG_USER_ONLY */
void m68k_cpu_dump_state(CPUState *cpu, FILE *f, int flags);
-hwaddr m68k_cpu_get_phys_page_debug(CPUState *cpu, vaddr addr);
int m68k_cpu_gdb_read_register(CPUState *cpu, GByteArray *buf, int reg);
int m68k_cpu_gdb_write_register(CPUState *cpu, uint8_t *buf, int reg);
diff --git a/target/nios2/cpu.h b/target/nios2/cpu.h
index f85581ee56..2f43b67a8f 100644
--- a/target/nios2/cpu.h
+++ b/target/nios2/cpu.h
@@ -262,7 +262,6 @@ void nios2_tcg_init(void);
void nios2_cpu_do_interrupt(CPUState *cs);
void dump_mmu(CPUNios2State *env);
void nios2_cpu_dump_state(CPUState *cpu, FILE *f, int flags);
-hwaddr nios2_cpu_get_phys_page_debug(CPUState *cpu, vaddr addr);
G_NORETURN void nios2_cpu_do_unaligned_access(CPUState *cpu, vaddr addr,
MMUAccessType access_type, int
mmu_idx,
uintptr_t retaddr);
@@ -288,6 +287,7 @@ static inline int cpu_mmu_index(CPUNios2State *env, bool
ifetch)
}
#ifndef CONFIG_USER_ONLY
+hwaddr nios2_cpu_get_phys_page_debug(CPUState *cpu, vaddr addr);
bool nios2_cpu_tlb_fill(CPUState *cs, vaddr address, int size,
MMUAccessType access_type, int mmu_idx,
bool probe, uintptr_t retaddr);
diff --git a/target/openrisc/cpu.h b/target/openrisc/cpu.h
index 1d5efa5ca2..31a4ae5ad3 100644
--- a/target/openrisc/cpu.h
+++ b/target/openrisc/cpu.h
@@ -312,7 +312,6 @@ struct ArchCPU {
void cpu_openrisc_list(void);
void openrisc_cpu_dump_state(CPUState *cpu, FILE *f, int flags);
-hwaddr openrisc_cpu_get_phys_page_debug(CPUState *cpu, vaddr addr);
int openrisc_cpu_gdb_read_register(CPUState *cpu, GByteArray *buf, int reg);
int
[PATCH-for-8.0 4/4] target/sparc: Cleanup around sparc_cpu_do_unaligned_access()
Commit caac44a52a ("target/sparc: Make sparc_cpu_tlb_fill sysemu
only") restricted mmu_helper.c to system emulation. Checking
whether CONFIG_USER_ONLY is defined is now pointless.
Signed-off-by: Philippe Mathieu-Daudé
---
target/sparc/mmu_helper.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/target/sparc/mmu_helper.c b/target/sparc/mmu_helper.c
index 919448a494..a7e51e4b7d 100644
--- a/target/sparc/mmu_helper.c
+++ b/target/sparc/mmu_helper.c
@@ -924,7 +924,6 @@ hwaddr sparc_cpu_get_phys_page_debug(CPUState *cs, vaddr
addr)
return phys_addr;
}
-#ifndef CONFIG_USER_ONLY
G_NORETURN void sparc_cpu_do_unaligned_access(CPUState *cs, vaddr addr,
MMUAccessType access_type,
int mmu_idx,
@@ -942,4 +941,3 @@ G_NORETURN void sparc_cpu_do_unaligned_access(CPUState *cs,
vaddr addr,
cpu_raise_exception_ra(env, TT_UNALIGNED, retaddr);
}
-#endif /* !CONFIG_USER_ONLY */
--
2.38.1
[PATCH-for-8.0 1/4] cputlb: Restrict SavedIOTLB to system emulation
Commit 2f3a57ee47 ("cputlb: ensure we save the IOTLB data in
case of reset") added the SavedIOTLB structure -- which is
system emulation specific -- in the generic CPUState structure.
Signed-off-by: Philippe Mathieu-Daudé
---
accel/tcg/cputlb.c| 4 ++--
include/hw/core/cpu.h | 6 --
2 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/accel/tcg/cputlb.c b/accel/tcg/cputlb.c
index 6f1c00682b..0ea96fbcdf 100644
--- a/accel/tcg/cputlb.c
+++ b/accel/tcg/cputlb.c
@@ -1395,7 +1395,7 @@ static uint64_t io_readx(CPUArchState *env,
CPUTLBEntryFull *full,
static void save_iotlb_data(CPUState *cs, MemoryRegionSection *section,
hwaddr mr_offset)
{
-#ifdef CONFIG_PLUGIN
+#if defined(CONFIG_PLUGIN) && !defined(CONFIG_USER_ONLY)
SavedIOTLB *saved = >saved_iotlb;
saved->section = section;
saved->mr_offset = mr_offset;
@@ -1699,7 +1699,7 @@ tb_page_addr_t get_page_addr_code_hostp(CPUArchState
*env, target_ulong addr,
return qemu_ram_addr_from_host_nofail(p);
}
-#ifdef CONFIG_PLUGIN
+#if defined(CONFIG_PLUGIN) && !defined(CONFIG_USER_ONLY)
/*
* Perform a TLB lookup and populate the qemu_plugin_hwaddr structure.
* This should be a hot path as we will have just looked this path up
diff --git a/include/hw/core/cpu.h b/include/hw/core/cpu.h
index 8830546121..bc3229ae13 100644
--- a/include/hw/core/cpu.h
+++ b/include/hw/core/cpu.h
@@ -222,7 +222,7 @@ struct CPUWatchpoint {
QTAILQ_ENTRY(CPUWatchpoint) entry;
};
-#ifdef CONFIG_PLUGIN
+#if defined(CONFIG_PLUGIN) && !defined(CONFIG_USER_ONLY)
/*
* For plugins we sometime need to save the resolved iotlb data before
* the memory regions get moved around by io_writex.
@@ -406,9 +406,11 @@ struct CPUState {
#ifdef CONFIG_PLUGIN
GArray *plugin_mem_cbs;
+#if !defined(CONFIG_USER_ONLY)
/* saved iotlb data from io_writex */
SavedIOTLB saved_iotlb;
-#endif
+#endif /* !CONFIG_USER_ONLY */
+#endif /* CONFIG_PLUGIN */
/* TODO Move common fields from CPUArchState here. */
int cpu_index;
--
2.38.1
Re: [PATCH v10 6/9] KVM: Unmap existing mappings when change the memory attributes
Hi,
On Fri, Dec 2, 2022 at 6:19 AM Chao Peng wrote:
>
> Unmap the existing guest mappings when memory attribute is changed
> between shared and private. This is needed because shared pages and
> private pages are from different backends, unmapping existing ones
> gives a chance for page fault handler to re-populate the mappings
> according to the new attribute.
>
> Only architecture has private memory support needs this and the
> supported architecture is expected to rewrite the weak
> kvm_arch_has_private_mem().
This kind of ties into the discussion of being able to share memory in
place. For pKVM for example, shared and private memory would have the
same backend, and the unmapping wouldn't be needed.
So I guess that, instead of kvm_arch_has_private_mem(), can the check
be done differently, e.g., with a different function, say
kvm_arch_private_notify_attribute_change() (but maybe with a more
friendly name than what I suggested :) )?
Thanks,
/fuad
>
> Also, during memory attribute changing and the unmapping time frame,
> page fault handler may happen in the same memory range and can cause
> incorrect page state, invoke kvm_mmu_invalidate_* helpers to let the
> page fault handler retry during this time frame.
>
> Signed-off-by: Chao Peng
> ---
> include/linux/kvm_host.h | 7 +-
> virt/kvm/kvm_main.c | 168 ++-
> 2 files changed, 116 insertions(+), 59 deletions(-)
>
> diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
> index 3d69484d2704..3331c0c92838 100644
> --- a/include/linux/kvm_host.h
> +++ b/include/linux/kvm_host.h
> @@ -255,7 +255,6 @@ bool kvm_setup_async_pf(struct kvm_vcpu *vcpu, gpa_t
> cr2_or_gpa,
> int kvm_async_pf_wakeup_all(struct kvm_vcpu *vcpu);
> #endif
>
> -#ifdef KVM_ARCH_WANT_MMU_NOTIFIER
> struct kvm_gfn_range {
> struct kvm_memory_slot *slot;
> gfn_t start;
> @@ -264,6 +263,8 @@ struct kvm_gfn_range {
> bool may_block;
> };
> bool kvm_unmap_gfn_range(struct kvm *kvm, struct kvm_gfn_range *range);
> +
> +#ifdef KVM_ARCH_WANT_MMU_NOTIFIER
> bool kvm_age_gfn(struct kvm *kvm, struct kvm_gfn_range *range);
> bool kvm_test_age_gfn(struct kvm *kvm, struct kvm_gfn_range *range);
> bool kvm_set_spte_gfn(struct kvm *kvm, struct kvm_gfn_range *range);
> @@ -785,11 +786,12 @@ struct kvm {
>
> #if defined(CONFIG_MMU_NOTIFIER) && defined(KVM_ARCH_WANT_MMU_NOTIFIER)
> struct mmu_notifier mmu_notifier;
> +#endif
> unsigned long mmu_invalidate_seq;
> long mmu_invalidate_in_progress;
> gfn_t mmu_invalidate_range_start;
> gfn_t mmu_invalidate_range_end;
> -#endif
> +
> struct list_head devices;
> u64 manual_dirty_log_protect;
> struct dentry *debugfs_dentry;
> @@ -1480,6 +1482,7 @@ bool kvm_arch_dy_has_pending_interrupt(struct kvm_vcpu
> *vcpu);
> int kvm_arch_post_init_vm(struct kvm *kvm);
> void kvm_arch_pre_destroy_vm(struct kvm *kvm);
> int kvm_arch_create_vm_debugfs(struct kvm *kvm);
> +bool kvm_arch_has_private_mem(struct kvm *kvm);
>
> #ifndef __KVM_HAVE_ARCH_VM_ALLOC
> /*
> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
> index ad55dfbc75d7..4e1e1e113bf0 100644
> --- a/virt/kvm/kvm_main.c
> +++ b/virt/kvm/kvm_main.c
> @@ -520,6 +520,62 @@ void kvm_destroy_vcpus(struct kvm *kvm)
> }
> EXPORT_SYMBOL_GPL(kvm_destroy_vcpus);
>
> +void kvm_mmu_invalidate_begin(struct kvm *kvm)
> +{
> + /*
> +* The count increase must become visible at unlock time as no
> +* spte can be established without taking the mmu_lock and
> +* count is also read inside the mmu_lock critical section.
> +*/
> + kvm->mmu_invalidate_in_progress++;
> +
> + if (likely(kvm->mmu_invalidate_in_progress == 1)) {
> + kvm->mmu_invalidate_range_start = INVALID_GPA;
> + kvm->mmu_invalidate_range_end = INVALID_GPA;
> + }
> +}
> +
> +void kvm_mmu_invalidate_range_add(struct kvm *kvm, gfn_t start, gfn_t end)
> +{
> + WARN_ON_ONCE(!kvm->mmu_invalidate_in_progress);
> +
> + if (likely(kvm->mmu_invalidate_in_progress == 1)) {
> + kvm->mmu_invalidate_range_start = start;
> + kvm->mmu_invalidate_range_end = end;
> + } else {
> + /*
> +* Fully tracking multiple concurrent ranges has diminishing
> +* returns. Keep things simple and just find the minimal range
> +* which includes the current and new ranges. As there won't
> be
> +* enough information to subtract a range after its invalidate
> +* completes, any ranges invalidated concurrently will
> +* accumulate and persist until all outstanding invalidates
> +* complete.
> +*/
> + kvm->mmu_invalidate_range_start =
> + min(kvm->mmu_invalidate_range_start, start);
> + kvm->mmu_invalidate_range_end =
> +
Re: [PATCH for 7.2?] target/i386: Remove compilation errors when -Werror=maybe-uninitialized
On 7/12/22 15:33, Eric Auger wrote:
On 12/7/22 15:09, Stefan Hajnoczi wrote:
On Wed, 7 Dec 2022 at 08:31, Eric Auger wrote:
On 12/7/22 14:24, Eric Auger wrote:
Initialize r0-3 to avoid compilation errors when
-Werror=maybe-uninitialized is used
../target/i386/ops_sse.h: In function ‘helper_vpermdq_ymm’:
../target/i386/ops_sse.h:2495:13: error: ‘r3’ may be used uninitialized in this
function [-Werror=maybe-uninitialized]
2495 | d->Q(3) = r3;
| ^~~~
../target/i386/ops_sse.h:2494:13: error: ‘r2’ may be used uninitialized in this
function [-Werror=maybe-uninitialized]
2494 | d->Q(2) = r2;
| ^~~~
../target/i386/ops_sse.h:2493:13: error: ‘r1’ may be used uninitialized in this
function [-Werror=maybe-uninitialized]
2493 | d->Q(1) = r1;
| ^~~~
../target/i386/ops_sse.h:2492:13: error: ‘r0’ may be used uninitialized in this
function [-Werror=maybe-uninitialized]
2492 | d->Q(0) = r0;
| ^~~~
Signed-off-by: Eric Auger
Fixes: 790684776861 ("target/i386: reimplement 0x0f 0x3a, add AVX")
---
Am I the only one getting this? Or anything wrong in my setup.
With Stefan's correct address. Forgive me for the noise.
When is -Wmaybe-uninitialized used? QEMU's build system doesn't set
it. Unless it's automatically set by meson this must be a manual
--extra-cflags= option you set.
I am using this configure cmd line:
./configure --prefix=/usr --sysconfdir=/etc --libexecdir=/usr/lib/qemu
--target-list=x86_64-softmmu --docdir=/usr/share/doc/qemu --enable-kvm
--extra-cflags=-O --enable-trace-backends=log --python=/usr/bin/python3
--extra-cflags=-Wall --extra-cflags=-Wundef
--extra-cflags=-Wwrite-strings --extra-cflags=-Wmissing-prototypes
--extra-cflags=-fno-strict-aliasing --extra-cflags=-fno-common
--extra-cflags=-Werror=type-limits
If you added it manually then let's fix this in 8.0 since it's not
tested/supported and very few people will see this issue.
Please include the relevant meson output in the commit description, i.e.:
C compiler for the host machine: clang (clang 14.0.0 "Apple clang
version 14.0.0 (clang-1400.0.29.202)")
C linker for the host machine: clang ld64 820.1
Compilation
host CPU : aarch64
host endianness : little
C compiler : clang
Host C compiler : clang
C++ compiler : c++
Objective-C compiler : clang
CFLAGS : -ggdb
-Werror=incompatible-function-pointer-types -O2 -g
CXXFLAGS : -ggdb
-Werror=incompatible-function-pointer-types -O2 -g
OBJCFLAGS: -ggdb
-Werror=incompatible-function-pointer-types -ggdb -O2 -g
LDFLAGS : -ggdb
-Werror=incompatible-function-pointer-types
QEMU_CFLAGS : ...
QEMU_CXXFLAGS: ...
QEMU_OBJCFLAGS : ...
QEMU_LDFLAGS : -fstack-protector-strong
Thanks,
Phil.
Re: [PATCH for-8.0] hw/rtc/mc146818rtc: Make this rtc device target independent
Am 7. Dezember 2022 15:29:00 UTC schrieb Mark Cave-Ayland
:
>On 06/12/2022 20:06, Thomas Huth wrote:
>
>> The only code that is really, really target dependent is the apic-related
>> code in rtc_policy_slew_deliver_irq(). By moving this code into the hw/i386/
>> folder (renamed to rtc_apic_policy_slew_deliver_irq()) and passing this
>> function as parameter to mc146818_rtc_init(), we can make the RTC completely
>> target-independent.
>>
>> Signed-off-by: Thomas Huth
>> ---
>> include/hw/rtc/mc146818rtc.h | 7 +--
>> hw/alpha/dp264.c | 2 +-
>> hw/hppa/machine.c| 2 +-
>> hw/i386/microvm.c| 3 ++-
>> hw/i386/pc.c | 10 +-
>> hw/mips/jazz.c | 2 +-
>> hw/ppc/pnv.c | 2 +-
>> hw/rtc/mc146818rtc.c | 34 +++---
>> hw/rtc/meson.build | 3 +--
>> 9 files changed, 32 insertions(+), 33 deletions(-)
>>
>> diff --git a/include/hw/rtc/mc146818rtc.h b/include/hw/rtc/mc146818rtc.h
>> index 1db0fcee92..c687953cc4 100644
>> --- a/include/hw/rtc/mc146818rtc.h
>> +++ b/include/hw/rtc/mc146818rtc.h
>> @@ -46,14 +46,17 @@ struct RTCState {
>> Notifier clock_reset_notifier;
>> LostTickPolicy lost_tick_policy;
>> Notifier suspend_notifier;
>> +bool (*policy_slew_deliver_irq)(RTCState *s);
>> QLIST_ENTRY(RTCState) link;
>> };
>> #define RTC_ISA_IRQ 8
>> -ISADevice *mc146818_rtc_init(ISABus *bus, int base_year,
>> - qemu_irq intercept_irq);
>> +ISADevice *mc146818_rtc_init(ISABus *bus, int base_year, qemu_irq
>> intercept_irq,
>> + bool (*policy_slew_deliver_irq)(RTCState *s));
>> void rtc_set_memory(ISADevice *dev, int addr, int val);
>> int rtc_get_memory(ISADevice *dev, int addr);
>> +bool rtc_apic_policy_slew_deliver_irq(RTCState *s);
>> +void qmp_rtc_reset_reinjection(Error **errp);
>> #endif /* HW_RTC_MC146818RTC_H */
>> diff --git a/hw/alpha/dp264.c b/hw/alpha/dp264.c
>> index c502c8c62a..8723942b52 100644
>> --- a/hw/alpha/dp264.c
>> +++ b/hw/alpha/dp264.c
>> @@ -118,7 +118,7 @@ static void clipper_init(MachineState *machine)
>> qdev_connect_gpio_out(i82378_dev, 0, isa_irq);
>> /* Since we have an SRM-compatible PALcode, use the SRM epoch. */
>> -mc146818_rtc_init(isa_bus, 1900, rtc_irq);
>> +mc146818_rtc_init(isa_bus, 1900, rtc_irq, NULL);
>> /* VGA setup. Don't bother loading the bios. */
>> pci_vga_init(pci_bus);
>> diff --git a/hw/hppa/machine.c b/hw/hppa/machine.c
>> index de1cc7ab71..311031714a 100644
>> --- a/hw/hppa/machine.c
>> +++ b/hw/hppa/machine.c
>> @@ -232,7 +232,7 @@ static void machine_hppa_init(MachineState *machine)
>> assert(isa_bus);
>> /* Realtime clock, used by firmware for PDC_TOD call. */
>> -mc146818_rtc_init(isa_bus, 2000, NULL);
>> +mc146818_rtc_init(isa_bus, 2000, NULL, NULL);
>> /* Serial ports: Lasi and Dino use a 7.272727 MHz clock. */
>> serial_mm_init(addr_space, LASI_UART_HPA + 0x800, 0,
>> diff --git a/hw/i386/microvm.c b/hw/i386/microvm.c
>> index 170a331e3f..d0ed4dca50 100644
>> --- a/hw/i386/microvm.c
>> +++ b/hw/i386/microvm.c
>> @@ -267,7 +267,8 @@ static void microvm_devices_init(MicrovmMachineState
>> *mms)
>> if (mms->rtc == ON_OFF_AUTO_ON ||
>> (mms->rtc == ON_OFF_AUTO_AUTO && !kvm_enabled())) {
>> -rtc_state = mc146818_rtc_init(isa_bus, 2000, NULL);
>> +rtc_state = mc146818_rtc_init(isa_bus, 2000, NULL,
>> + rtc_apic_policy_slew_deliver_irq);
>> microvm_set_rtc(mms, rtc_state);
>> }
>> diff --git a/hw/i386/pc.c b/hw/i386/pc.c
>> index 546b703cb4..650e7bc199 100644
>> --- a/hw/i386/pc.c
>> +++ b/hw/i386/pc.c
>> @@ -1244,6 +1244,13 @@ static void pc_superio_init(ISABus *isa_bus, bool
>> create_fdctrl,
>> g_free(a20_line);
>> }
>> +bool rtc_apic_policy_slew_deliver_irq(RTCState *s)
>> +{
>> +apic_reset_irq_delivered();
>> +qemu_irq_raise(s->irq);
>> +return apic_get_irq_delivered();
>> +}
>> +
>> void pc_basic_device_init(struct PCMachineState *pcms,
>> ISABus *isa_bus, qemu_irq *gsi,
>> ISADevice **rtc_state,
>> @@ -1299,7 +1306,8 @@ void pc_basic_device_init(struct PCMachineState *pcms,
>> pit_alt_irq = qdev_get_gpio_in(hpet, HPET_LEGACY_PIT_INT);
>> rtc_irq = qdev_get_gpio_in(hpet, HPET_LEGACY_RTC_INT);
>> }
>> -*rtc_state = mc146818_rtc_init(isa_bus, 2000, rtc_irq);
>> +*rtc_state = mc146818_rtc_init(isa_bus, 2000, rtc_irq,
>> + rtc_apic_policy_slew_deliver_irq);
>> qemu_register_boot_set(pc_boot_set, *rtc_state);
>> diff --git a/hw/mips/jazz.c b/hw/mips/jazz.c
>> index 6aefe9a61b..50fbd57b23 100644
>> --- a/hw/mips/jazz.c
>> +++ b/hw/mips/jazz.c
>> @@ -356,7 +356,7 @@ static void
Re: [PATCH 00/18] block: Introduce a block graph rwlock
Am 07.12.2022 um 15:12 hat Emanuele Giuseppe Esposito geschrieben: > > Emanuele Giuseppe Esposito (7): > > graph-lock: Implement guard macros > > async: Register/unregister aiocontext in graph lock list > > block: wrlock in bdrv_replace_child_noperm > > block: remove unnecessary assert_bdrv_graph_writable() > > block: assert that graph read and writes are performed correctly > > block-coroutine-wrapper.py: introduce annotations that take the graph > > rdlock > > block: use co_wrapper_mixed_bdrv_rdlock in functions taking the rdlock > > > > Kevin Wolf (10): > > block: Factor out bdrv_drain_all_begin_nopoll() > > Import clang-tsa.h > > clang-tsa: Add TSA_ASSERT() macro > > clang-tsa: Add macros for shared locks > > configure: Enable -Wthread-safety if present > > test-bdrv-drain: Fix incorrrect drain assumptions > > block: Fix locking in external_snapshot_prepare() > > graph-lock: TSA annotations for lock/unlock functions > > Mark assert_bdrv_graph_readable/writable() GRAPH_RD/WRLOCK > > block: GRAPH_RDLOCK for functions only called by co_wrappers > > > > Paolo Bonzini (1): > > graph-lock: Introduce a lock to protect block graph operations > > > Reviewed-by: Emanuele Giuseppe Esposito Thanks! > ^ I am curious to see if I am allowed to have my r-b also on my patches :) That's actually a good question. I wondered myself whether I should add my R-b to patches that I picked up from you, but which already have my S-o-b now, of course, and are possibly modified by me. I would say you're allowed as long as you actually reviewed them in the version I sent to make sure that I didn't mess them up. :-) And similarly I'll probably add my R-b on patches that contain code from you. Kevin
Re: [PATCH for 7.2?] target/i386: Remove compilation errors when -Werror=maybe-uninitialized
Hi Stefan,
On 12/7/22 16:55, Stefan Hajnoczi wrote:
> On Wed, 7 Dec 2022 at 09:34, Eric Auger wrote:
>> Hi Stefan,
>>
>> On 12/7/22 15:09, Stefan Hajnoczi wrote:
>>> On Wed, 7 Dec 2022 at 08:31, Eric Auger wrote:
On 12/7/22 14:24, Eric Auger wrote:
> Initialize r0-3 to avoid compilation errors when
> -Werror=maybe-uninitialized is used
>
> ../target/i386/ops_sse.h: In function ‘helper_vpermdq_ymm’:
> ../target/i386/ops_sse.h:2495:13: error: ‘r3’ may be used uninitialized
> in this function [-Werror=maybe-uninitialized]
> 2495 | d->Q(3) = r3;
> | ^~~~
> ../target/i386/ops_sse.h:2494:13: error: ‘r2’ may be used uninitialized
> in this function [-Werror=maybe-uninitialized]
> 2494 | d->Q(2) = r2;
> | ^~~~
> ../target/i386/ops_sse.h:2493:13: error: ‘r1’ may be used uninitialized
> in this function [-Werror=maybe-uninitialized]
> 2493 | d->Q(1) = r1;
> | ^~~~
> ../target/i386/ops_sse.h:2492:13: error: ‘r0’ may be used uninitialized
> in this function [-Werror=maybe-uninitialized]
> 2492 | d->Q(0) = r0;
> | ^~~~
>
> Signed-off-by: Eric Auger
> Fixes: 790684776861 ("target/i386: reimplement 0x0f 0x3a, add AVX")
>
> ---
>
> Am I the only one getting this? Or anything wrong in my setup.
With Stefan's correct address. Forgive me for the noise.
>>> When is -Wmaybe-uninitialized used? QEMU's build system doesn't set
>>> it. Unless it's automatically set by meson this must be a manual
>>> --extra-cflags= option you set.
>> I am using this configure cmd line:
>>
>> ./configure --prefix=/usr --sysconfdir=/etc --libexecdir=/usr/lib/qemu
>> --target-list=x86_64-softmmu --docdir=/usr/share/doc/qemu --enable-kvm
>> --extra-cflags=-O --enable-trace-backends=log --python=/usr/bin/python3
>> --extra-cflags=-Wall --extra-cflags=-Wundef
>> --extra-cflags=-Wwrite-strings --extra-cflags=-Wmissing-prototypes
>> --extra-cflags=-fno-strict-aliasing --extra-cflags=-fno-common
>> --extra-cflags=-Werror=type-limits
>>> If you added it manually then let's fix this in 8.0 since it's not
>>> tested/supported and very few people will see this issue.
> Did you create the ./configure command-line manually? Do you think
> other people will hit this?
no I did not. I just tried to install a fresh qemu repo and just ran the
above configure command. You should be able to reproduce I think.
I am actually surprised nobody hit that already.
Thanks
Eric
>
> Stefan
>
Re: [External] Re: [RFC PATCH] migration: reduce time of loading non-iterable vmstate
On 2022/12/6 上午12:28, Peter Xu wrote:
Chuang,
No worry on the delay; you're faster than when I read yours. :)
On Mon, Dec 05, 2022 at 02:56:15PM +0800, Chuang Xu wrote:
As a start, maybe you can try with poison address_space_to_flatview() (by
e.g. checking the start_pack_mr_change flag and assert it is not set)
during this process to see whether any call stack can even try to
dereference a flatview.
It's just that I didn't figure a good way to "prove" its validity, even if
I think this is an interesting idea worth thinking to shrink the downtime.
Thanks for your sugguestions!
I used a thread local variable to identify whether the current thread is a
migration thread(main thread of target qemu) and I modified the code of
qemu_coroutine_switch to make sure the thread local variable true only in
process_incoming_migration_co call stack. If the target qemu detects that
start_pack_mr_change is set and address_space_to_flatview() is called in
non-migrating threads or non-migrating coroutine, it will crash.
Are you using the thread var just to avoid the assert triggering in the
migration thread when commiting memory changes?
I think _maybe_ another cleaner way to sanity check this is directly upon
the depth:
static inline FlatView *address_space_to_flatview(AddressSpace *as)
{
/*
* Before using any flatview, sanity check we're not during a memory
* region transaction or the map can be invalid. Note that this can
* also be called during commit phase of memory transaction, but that
* should also only happen when the depth decreases to 0 first.
*/
assert(memory_region_transaction_depth == 0);
return qatomic_rcu_read(>current_map);
}
That should also cover the safe cases of memory transaction commits during
migration.
Peter, I tried this way and found that the target qemu will crash.
Here is the gdb backtrace:
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
#1 0x7ff2929d851a in __GI_abort () at abort.c:118
#2 0x7ff2929cfe67 in __assert_fail_base (fmt=,
assertion=assertion@entry=0x55a32578cdc0 "memory_region_transaction_depth == 0",
file=file@entry=0x55a32575d9b0 "/data00/migration/qemu-5.2.0/include/exec/memory.h",
line=line@entry=766, function=function@entry=0x55a32578d6e0
<__PRETTY_FUNCTION__.20463> "address_space_to_flatview") at assert.c:92
#3 0x7ff2929cff12 in __GI___assert_fail (assertion=assertion@entry=0x55a32578cdc0
"memory_region_transaction_depth == 0", file=file@entry=0x55a32575d9b0
"/data00/migration/qemu-5.2.0/include/exec/memory.h", line=line@entry=766,
function=function@entry=0x55a32578d6e0 <__PRETTY_FUNCTION__.20463>
"address_space_to_flatview") at assert.c:101
#4 0x55a324b2ed5e in address_space_to_flatview (as=0x55a326132580
) at
/data00/migration/qemu-5.2.0/include/exec/memory.h:766
#5 0x55a324e79559 in address_space_to_flatview (as=0x55a326132580
) at ../softmmu/memory.c:811
#6 address_space_get_flatview (as=0x55a326132580 ) at
../softmmu/memory.c:805
#7 0x55a324e96474 in address_space_cache_init (cache=cache@entry=0x55a32a4fb000,
as=, addr=addr@entry=68404985856, len=len@entry=4096,
is_write=false) at ../softmmu/physmem.c:3307
#8 0x55a324ea9cba in virtio_init_region_cache (vdev=0x55a32985d9a0, n=0)
at ../hw/virtio/virtio.c:185
#9 0x55a324eaa615 in virtio_load (vdev=0x55a32985d9a0, f=,
version_id=) at ../hw/virtio/virtio.c:3203
#10 0x55a324c6ab96 in vmstate_load_state (f=f@entry=0x55a329dc0c00,
vmsd=0x55a325fc1a60 , opaque=0x55a32985d9a0, version_id=1)
at ../migration/vmstate.c:143
#11 0x55a324cda138 in vmstate_load (f=0x55a329dc0c00, se=0x55a329941c90) at
../migration/savevm.c:913
#12 0x55a324cdda34 in qemu_loadvm_section_start_full (mis=0x55a3284ef9e0,
f=0x55a329dc0c00) at ../migration/savevm.c:2741
#13 qemu_loadvm_state_main (f=f@entry=0x55a329dc0c00,
mis=mis@entry=0x55a3284ef9e0) at ../migration/savevm.c:2939
#14 0x55a324cdf66a in qemu_loadvm_state (f=0x55a329dc0c00) at
../migration/savevm.c:3021
#15 0x55a324d14b4e in process_incoming_migration_co (opaque=) at ../migration/migration.c:574
#16 0x55a32501ae3b in coroutine_trampoline (i0=, i1=) at ../util/coroutine-ucontext.c:173
#17 0x7ff2929e8000 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#18 0x7ffed80dc2a0 in ?? ()
#19 0x in ?? ()
address_space_cache_init() is the only caller of address_space_to_flatview
I can find in vmstate_load call stack so far. Although I think the mr used
by address_space_cache_init() won't be affected by the delay of
memory_region_transaction_commit(), we really need a mechanism to prevent
the modified mr from being used.
Maybe we can build a stale list:
If a subregion is added, add its parent to the stale list(considering that
new subregion's priority has uncertain effects on flatviews).
If a subregion is deleted, add itself to the stale list.
When memory_region_transaction_commit() regenerates flatviews, clear
Re: [PATCH for 7.2?] target/i386: Remove compilation errors when -Werror=maybe-uninitialized
On Wed, 7 Dec 2022 at 09:34, Eric Auger wrote:
>
> Hi Stefan,
>
> On 12/7/22 15:09, Stefan Hajnoczi wrote:
> > On Wed, 7 Dec 2022 at 08:31, Eric Auger wrote:
> >> On 12/7/22 14:24, Eric Auger wrote:
> >>> Initialize r0-3 to avoid compilation errors when
> >>> -Werror=maybe-uninitialized is used
> >>>
> >>> ../target/i386/ops_sse.h: In function ‘helper_vpermdq_ymm’:
> >>> ../target/i386/ops_sse.h:2495:13: error: ‘r3’ may be used uninitialized
> >>> in this function [-Werror=maybe-uninitialized]
> >>> 2495 | d->Q(3) = r3;
> >>> | ^~~~
> >>> ../target/i386/ops_sse.h:2494:13: error: ‘r2’ may be used uninitialized
> >>> in this function [-Werror=maybe-uninitialized]
> >>> 2494 | d->Q(2) = r2;
> >>> | ^~~~
> >>> ../target/i386/ops_sse.h:2493:13: error: ‘r1’ may be used uninitialized
> >>> in this function [-Werror=maybe-uninitialized]
> >>> 2493 | d->Q(1) = r1;
> >>> | ^~~~
> >>> ../target/i386/ops_sse.h:2492:13: error: ‘r0’ may be used uninitialized
> >>> in this function [-Werror=maybe-uninitialized]
> >>> 2492 | d->Q(0) = r0;
> >>> | ^~~~
> >>>
> >>> Signed-off-by: Eric Auger
> >>> Fixes: 790684776861 ("target/i386: reimplement 0x0f 0x3a, add AVX")
> >>>
> >>> ---
> >>>
> >>> Am I the only one getting this? Or anything wrong in my setup.
> >> With Stefan's correct address. Forgive me for the noise.
> > When is -Wmaybe-uninitialized used? QEMU's build system doesn't set
> > it. Unless it's automatically set by meson this must be a manual
> > --extra-cflags= option you set.
>
> I am using this configure cmd line:
>
> ./configure --prefix=/usr --sysconfdir=/etc --libexecdir=/usr/lib/qemu
> --target-list=x86_64-softmmu --docdir=/usr/share/doc/qemu --enable-kvm
> --extra-cflags=-O --enable-trace-backends=log --python=/usr/bin/python3
> --extra-cflags=-Wall --extra-cflags=-Wundef
> --extra-cflags=-Wwrite-strings --extra-cflags=-Wmissing-prototypes
> --extra-cflags=-fno-strict-aliasing --extra-cflags=-fno-common
> --extra-cflags=-Werror=type-limits
> >
> > If you added it manually then let's fix this in 8.0 since it's not
> > tested/supported and very few people will see this issue.
Did you create the ./configure command-line manually? Do you think
other people will hit this?
Stefan
RE: [PATCH] configure: Fix check-tcg not executing any tests
Thank you for the pointers, Philippe Will keep them in mind for the future
patches.
Regards,
Mukilan
-Original Message-
From: Philippe Mathieu-Daudé
Sent: Wednesday, December 7, 2022 2:37 PM
To: Mukilan Thiyagarajan (QUIC) ;
qemu-devel@nongnu.org; Brian Cain ; Matheus Bernardino
(QUIC)
Cc: Alex Bennée ; Richard Henderson
; Paolo Bonzini ; Thomas
Huth
Subject: Re: [PATCH] configure: Fix check-tcg not executing any tests
Hi Mukilan,
On 7/12/22 09:23, Mukilan Thiyagarajan wrote:
> After configuring with --target-list=hexagon-linux-user
> running `make check-tcg` just prints the following:
>
> ```
> make: Nothing to be done for 'check-tcg'
> ```
>
> In the probe_target_compiler function, the 'break'
> command is used incorrectly. There are no lexically
> enclosing loops associated with that break command which
> is an unspecfied behaviour in the POSIX standard.
>
> The dash shell implementation aborts the currently executing
> loop, in this case, causing the rest of the logic for the loop
> in line 2490 to be skipped, which means no Makefiles are
> generated for the tcg target tests.
>
> Fixes: c3b570b5a9a24d25 (configure: don't enable
> cross compilers unless in target_list)
When posting a patch fixing an issue introduced by another one,
you'll get more feedback if Cc'ing the author/reviewers of such
patch.
Also Cc'ing the maintainers also help in having your patch picked
up :) See:
https://www.qemu.org/docs/master/devel/submitting-a-patch.html#cc-the-relevant-maintainer
I've Cc'ed the corresponding developers for you.
Regards,
Phil.
> Signed-off-by: Mukilan Thiyagarajan
> ---
> configure | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/configure b/configure
> index 26c7bc5154..7a804fb657 100755
> --- a/configure
> +++ b/configure
> @@ -1881,9 +1881,7 @@ probe_target_compiler() {
> # We shall skip configuring the target compiler if the user didn't
> # bother enabling an appropriate guest. This avoids building
> # extraneous firmware images and tests.
> - if test "${target_list#*$1}" != "$1"; then
> - break;
> - else
> + if test "${target_list#*$1}" = "$1"; then
> return 1
> fi
>
Re: [PATCH V9 00/46] Live Update
This series desperately needs review in its intersection with live migration. The code in other areas has been reviewed and revised multiple times -- thank you! David, Juan, can you spare some time to review this? I have done my best to order the patches logically (see the labelled groups in this email), and to provide complete and clear cover letter and commit messages. Can I do anything to facilitate, like doing a code walk through via zoom? And of course, I welcome anyone's feedback. Here is the original posting. https://lore.kernel.org/qemu-devel/1658851843-236870-1-git-send-email-steven.sist...@oracle.com/ - Steve On 7/26/2022 12:09 PM, Steve Sistare wrote: > This version of the live update patch series integrates live update into the > live migration framework. The new interfaces are: > * mode (migration parameter) > * cpr-exec-args (migration parameter) > * file (migration URI) > * migrate-mode-enable (command-line argument) > * only-cpr-capable (command-line argument) > > Provide the cpr-exec and cpr-reboot migration modes for live update. These > save and restore VM state, with minimal guest pause time, so that qemu may be > updated to a new version in between. The caller sets the mode parameter > before invoking the migrate or migrate-incoming commands. > > In cpr-reboot mode, the migrate command saves state to a file, allowing > one to quit qemu, reboot to an updated kernel, start an updated version of > qemu, and resume via the migrate-incoming command. The caller must specify > a migration URI that writes to and reads from a file. Unlike normal mode, > the use of certain local storage options does not block the migration, but > the caller must not modify guest block devices between the quit and restart. > The guest RAM memory-backend must be shared, and the @x-ignore-shared > migration capability must be set, to avoid saving it to the file. Guest RAM > must be non-volatile across reboot, which can be achieved by backing it with > a dax device, or /dev/shm PKRAM as proposed in > https://lore.kernel.org/lkml/1617140178-8773-1-git-send-email-anthony.yzn...@oracle.com > but this is not enforced. The restarted qemu arguments must match those used > to initially start qemu, plus the -incoming option. > > The reboot mode supports vfio devices if the caller first suspends the guest, > such as by issuing guest-suspend-ram to the qemu guest agent. The guest > drivers' suspend methods flush outstanding requests and re-initialize the > devices, and thus there is no device state to save and restore. After > issuing migrate-incoming, the caller must issue a system_wakeup command to > resume. > > In cpr-exec mode, the migrate command saves state to a file and directly > exec's a new version of qemu on the same host, replacing the original process > while retaining its PID. The caller must specify a migration URI that writes > to and reads from a file, and resumes execution via the migrate-incoming > command. Arguments for the new qemu process are taken from the cpr-exec-args > migration parameter, and must include the -incoming option. > > Guest RAM must be backed by a memory backend with share=on, but cannot be > memory-backend-ram. The memory is re-mmap'd in the updated process, so guest > ram is efficiently preserved in place, albeit with new virtual addresses. > In addition, the '-migrate-mode-enable cpr-exec' option is required. This > causes secondary guest ram blocks (those not specified on the command line) > to be allocated by mmap'ing a memfd. The memfds are kept open across exec, > their values are saved in special cpr state which is retrieved after exec, > and they are re-mmap'd. Since guest RAM is not copied, and storage blocks > are not migrated, the caller must disable all capabilities related to page > and block copy. The implementation ignores all related parameters. > > The exec mode supports vfio devices by preserving the vfio container, group, > device, and event descriptors across the qemu re-exec, and by updating DMA > mapping virtual addresses using VFIO_DMA_UNMAP_FLAG_VADDR and > VFIO_DMA_MAP_FLAG_VADDR as defined in > > https://lore.kernel.org/kvm/1611939252-7240-1-git-send-email-steven.sist...@oracle.com > and integrated in Linux kernel 5.12. > > Here is an example of updating qemu from v7.0.50 to v7.0.51 using exec mode. > The software update is performed while the guest is running to minimize > downtime. > > window 1| window 2 > | > # qemu-system-$arch ... | > -migrate-mode-enable cpr-exec | > QEMU 7.0.50 monitor - type 'help' ... | > (qemu) info status | > VM status: running | > | # yum update qemu > (qemu) migrate_set_parameter mode cpr-exec | > (qemu) migrate_set_parameter
Re: [PATCH for-8.0] hw/rtc/mc146818rtc: Make this rtc device target independent
Am 7. Dezember 2022 08:43:31 UTC schrieb Thomas Huth :
>On 07/12/2022 00.38, Bernhard Beschow wrote:
>>
>>
>> Am 6. Dezember 2022 20:06:41 UTC schrieb Thomas Huth :
>>> The only code that is really, really target dependent is the apic-related
>>> code in rtc_policy_slew_deliver_irq(). By moving this code into the hw/i386/
>>> folder (renamed to rtc_apic_policy_slew_deliver_irq()) and passing this
>>> function as parameter to mc146818_rtc_init(), we can make the RTC completely
>>> target-independent.
>>>
>>> Signed-off-by: Thomas Huth
>>> ---
>>> include/hw/rtc/mc146818rtc.h | 7 +--
>>> hw/alpha/dp264.c | 2 +-
>>> hw/hppa/machine.c| 2 +-
>>> hw/i386/microvm.c| 3 ++-
>>> hw/i386/pc.c | 10 +-
>>> hw/mips/jazz.c | 2 +-
>>> hw/ppc/pnv.c | 2 +-
>>> hw/rtc/mc146818rtc.c | 34 +++---
>>> hw/rtc/meson.build | 3 +--
>>> 9 files changed, 32 insertions(+), 33 deletions(-)
>>>
>>> diff --git a/include/hw/rtc/mc146818rtc.h b/include/hw/rtc/mc146818rtc.h
>>> index 1db0fcee92..c687953cc4 100644
>>> --- a/include/hw/rtc/mc146818rtc.h
>>> +++ b/include/hw/rtc/mc146818rtc.h
>>> @@ -46,14 +46,17 @@ struct RTCState {
>>> Notifier clock_reset_notifier;
>>> LostTickPolicy lost_tick_policy;
>>> Notifier suspend_notifier;
>>> +bool (*policy_slew_deliver_irq)(RTCState *s);
>>> QLIST_ENTRY(RTCState) link;
>>> };
>>>
>>> #define RTC_ISA_IRQ 8
>>>
>>> -ISADevice *mc146818_rtc_init(ISABus *bus, int base_year,
>>> - qemu_irq intercept_irq);
>>> +ISADevice *mc146818_rtc_init(ISABus *bus, int base_year, qemu_irq
>>> intercept_irq,
>>> + bool (*policy_slew_deliver_irq)(RTCState *s));
>>> void rtc_set_memory(ISADevice *dev, int addr, int val);
>>> int rtc_get_memory(ISADevice *dev, int addr);
>>> +bool rtc_apic_policy_slew_deliver_irq(RTCState *s);
>>> +void qmp_rtc_reset_reinjection(Error **errp);
>>>
>>> #endif /* HW_RTC_MC146818RTC_H */
>>> diff --git a/hw/alpha/dp264.c b/hw/alpha/dp264.c
>>> index c502c8c62a..8723942b52 100644
>>> --- a/hw/alpha/dp264.c
>>> +++ b/hw/alpha/dp264.c
>>> @@ -118,7 +118,7 @@ static void clipper_init(MachineState *machine)
>>> qdev_connect_gpio_out(i82378_dev, 0, isa_irq);
>>>
>>> /* Since we have an SRM-compatible PALcode, use the SRM epoch. */
>>> -mc146818_rtc_init(isa_bus, 1900, rtc_irq);
>>> +mc146818_rtc_init(isa_bus, 1900, rtc_irq, NULL);
>>>
>>> /* VGA setup. Don't bother loading the bios. */
>>> pci_vga_init(pci_bus);
>>> diff --git a/hw/hppa/machine.c b/hw/hppa/machine.c
>>> index de1cc7ab71..311031714a 100644
>>> --- a/hw/hppa/machine.c
>>> +++ b/hw/hppa/machine.c
>>> @@ -232,7 +232,7 @@ static void machine_hppa_init(MachineState *machine)
>>> assert(isa_bus);
>>>
>>> /* Realtime clock, used by firmware for PDC_TOD call. */
>>> -mc146818_rtc_init(isa_bus, 2000, NULL);
>>> +mc146818_rtc_init(isa_bus, 2000, NULL, NULL);
>>>
>>> /* Serial ports: Lasi and Dino use a 7.272727 MHz clock. */
>>> serial_mm_init(addr_space, LASI_UART_HPA + 0x800, 0,
>>> diff --git a/hw/i386/microvm.c b/hw/i386/microvm.c
>>> index 170a331e3f..d0ed4dca50 100644
>>> --- a/hw/i386/microvm.c
>>> +++ b/hw/i386/microvm.c
>>> @@ -267,7 +267,8 @@ static void microvm_devices_init(MicrovmMachineState
>>> *mms)
>>>
>>> if (mms->rtc == ON_OFF_AUTO_ON ||
>>> (mms->rtc == ON_OFF_AUTO_AUTO && !kvm_enabled())) {
>>> -rtc_state = mc146818_rtc_init(isa_bus, 2000, NULL);
>>> +rtc_state = mc146818_rtc_init(isa_bus, 2000, NULL,
>>> + rtc_apic_policy_slew_deliver_irq);
>>> microvm_set_rtc(mms, rtc_state);
>>> }
>>>
>>> diff --git a/hw/i386/pc.c b/hw/i386/pc.c
>>> index 546b703cb4..650e7bc199 100644
>>> --- a/hw/i386/pc.c
>>> +++ b/hw/i386/pc.c
>>> @@ -1244,6 +1244,13 @@ static void pc_superio_init(ISABus *isa_bus, bool
>>> create_fdctrl,
>>> g_free(a20_line);
>>> }
>>>
>>> +bool rtc_apic_policy_slew_deliver_irq(RTCState *s)
>>> +{
>>> +apic_reset_irq_delivered();
>>> +qemu_irq_raise(s->irq);
>>> +return apic_get_irq_delivered();
>>> +}
>>> +
>>> void pc_basic_device_init(struct PCMachineState *pcms,
>>>ISABus *isa_bus, qemu_irq *gsi,
>>>ISADevice **rtc_state,
>>> @@ -1299,7 +1306,8 @@ void pc_basic_device_init(struct PCMachineState *pcms,
>>> pit_alt_irq = qdev_get_gpio_in(hpet, HPET_LEGACY_PIT_INT);
>>> rtc_irq = qdev_get_gpio_in(hpet, HPET_LEGACY_RTC_INT);
>>> }
>>> -*rtc_state = mc146818_rtc_init(isa_bus, 2000, rtc_irq);
>>> +*rtc_state = mc146818_rtc_init(isa_bus, 2000, rtc_irq,
>>> + rtc_apic_policy_slew_deliver_irq);
>>
>> In my PIIX consolidation series [1] I'm instantiating the RTC in the south
>> bridges since embedding
Re: [PATCH for-8.0] hw/rtc/mc146818rtc: Make this rtc device target independent
On 06/12/2022 20:06, Thomas Huth wrote:
The only code that is really, really target dependent is the apic-related
code in rtc_policy_slew_deliver_irq(). By moving this code into the hw/i386/
folder (renamed to rtc_apic_policy_slew_deliver_irq()) and passing this
function as parameter to mc146818_rtc_init(), we can make the RTC completely
target-independent.
Signed-off-by: Thomas Huth
---
include/hw/rtc/mc146818rtc.h | 7 +--
hw/alpha/dp264.c | 2 +-
hw/hppa/machine.c| 2 +-
hw/i386/microvm.c| 3 ++-
hw/i386/pc.c | 10 +-
hw/mips/jazz.c | 2 +-
hw/ppc/pnv.c | 2 +-
hw/rtc/mc146818rtc.c | 34 +++---
hw/rtc/meson.build | 3 +--
9 files changed, 32 insertions(+), 33 deletions(-)
diff --git a/include/hw/rtc/mc146818rtc.h b/include/hw/rtc/mc146818rtc.h
index 1db0fcee92..c687953cc4 100644
--- a/include/hw/rtc/mc146818rtc.h
+++ b/include/hw/rtc/mc146818rtc.h
@@ -46,14 +46,17 @@ struct RTCState {
Notifier clock_reset_notifier;
LostTickPolicy lost_tick_policy;
Notifier suspend_notifier;
+bool (*policy_slew_deliver_irq)(RTCState *s);
QLIST_ENTRY(RTCState) link;
};
#define RTC_ISA_IRQ 8
-ISADevice *mc146818_rtc_init(ISABus *bus, int base_year,
- qemu_irq intercept_irq);
+ISADevice *mc146818_rtc_init(ISABus *bus, int base_year, qemu_irq
intercept_irq,
+ bool (*policy_slew_deliver_irq)(RTCState *s));
void rtc_set_memory(ISADevice *dev, int addr, int val);
int rtc_get_memory(ISADevice *dev, int addr);
+bool rtc_apic_policy_slew_deliver_irq(RTCState *s);
+void qmp_rtc_reset_reinjection(Error **errp);
#endif /* HW_RTC_MC146818RTC_H */
diff --git a/hw/alpha/dp264.c b/hw/alpha/dp264.c
index c502c8c62a..8723942b52 100644
--- a/hw/alpha/dp264.c
+++ b/hw/alpha/dp264.c
@@ -118,7 +118,7 @@ static void clipper_init(MachineState *machine)
qdev_connect_gpio_out(i82378_dev, 0, isa_irq);
/* Since we have an SRM-compatible PALcode, use the SRM epoch. */
-mc146818_rtc_init(isa_bus, 1900, rtc_irq);
+mc146818_rtc_init(isa_bus, 1900, rtc_irq, NULL);
/* VGA setup. Don't bother loading the bios. */
pci_vga_init(pci_bus);
diff --git a/hw/hppa/machine.c b/hw/hppa/machine.c
index de1cc7ab71..311031714a 100644
--- a/hw/hppa/machine.c
+++ b/hw/hppa/machine.c
@@ -232,7 +232,7 @@ static void machine_hppa_init(MachineState *machine)
assert(isa_bus);
/* Realtime clock, used by firmware for PDC_TOD call. */
-mc146818_rtc_init(isa_bus, 2000, NULL);
+mc146818_rtc_init(isa_bus, 2000, NULL, NULL);
/* Serial ports: Lasi and Dino use a 7.272727 MHz clock. */
serial_mm_init(addr_space, LASI_UART_HPA + 0x800, 0,
diff --git a/hw/i386/microvm.c b/hw/i386/microvm.c
index 170a331e3f..d0ed4dca50 100644
--- a/hw/i386/microvm.c
+++ b/hw/i386/microvm.c
@@ -267,7 +267,8 @@ static void microvm_devices_init(MicrovmMachineState *mms)
if (mms->rtc == ON_OFF_AUTO_ON ||
(mms->rtc == ON_OFF_AUTO_AUTO && !kvm_enabled())) {
-rtc_state = mc146818_rtc_init(isa_bus, 2000, NULL);
+rtc_state = mc146818_rtc_init(isa_bus, 2000, NULL,
+ rtc_apic_policy_slew_deliver_irq);
microvm_set_rtc(mms, rtc_state);
}
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index 546b703cb4..650e7bc199 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -1244,6 +1244,13 @@ static void pc_superio_init(ISABus *isa_bus, bool
create_fdctrl,
g_free(a20_line);
}
+bool rtc_apic_policy_slew_deliver_irq(RTCState *s)
+{
+apic_reset_irq_delivered();
+qemu_irq_raise(s->irq);
+return apic_get_irq_delivered();
+}
+
void pc_basic_device_init(struct PCMachineState *pcms,
ISABus *isa_bus, qemu_irq *gsi,
ISADevice **rtc_state,
@@ -1299,7 +1306,8 @@ void pc_basic_device_init(struct PCMachineState *pcms,
pit_alt_irq = qdev_get_gpio_in(hpet, HPET_LEGACY_PIT_INT);
rtc_irq = qdev_get_gpio_in(hpet, HPET_LEGACY_RTC_INT);
}
-*rtc_state = mc146818_rtc_init(isa_bus, 2000, rtc_irq);
+*rtc_state = mc146818_rtc_init(isa_bus, 2000, rtc_irq,
+ rtc_apic_policy_slew_deliver_irq);
qemu_register_boot_set(pc_boot_set, *rtc_state);
diff --git a/hw/mips/jazz.c b/hw/mips/jazz.c
index 6aefe9a61b..50fbd57b23 100644
--- a/hw/mips/jazz.c
+++ b/hw/mips/jazz.c
@@ -356,7 +356,7 @@ static void mips_jazz_init(MachineState *machine,
fdctrl_init_sysbus(qdev_get_gpio_in(rc4030, 1), 0x80003000, fds);
/* Real time clock */
-mc146818_rtc_init(isa_bus, 1980, NULL);
+mc146818_rtc_init(isa_bus, 1980, NULL, NULL);
memory_region_init_io(rtc, NULL, _ops, NULL, "rtc", 0x1000);
memory_region_add_subregion(address_space, 0x80004000, rtc);
diff
Re: [PATCH v10 5/9] KVM: Use gfn instead of hva for mmu_notifier_retry
On Tue, Dec 06, 2022 at 10:34:11PM -0800, Isaku Yamahata wrote:
> On Tue, Dec 06, 2022 at 07:56:23PM +0800,
> Chao Peng wrote:
>
> > > > - if (unlikely(kvm->mmu_invalidate_in_progress) &&
> > > > - hva >= kvm->mmu_invalidate_range_start &&
> > > > - hva < kvm->mmu_invalidate_range_end)
> > > > - return 1;
> > > > + if (unlikely(kvm->mmu_invalidate_in_progress)) {
> > > > + /*
> > > > +* Dropping mmu_lock after bumping
> > > > mmu_invalidate_in_progress
> > > > +* but before updating the range is a KVM bug.
> > > > +*/
> > > > + if (WARN_ON_ONCE(kvm->mmu_invalidate_range_start ==
> > > > INVALID_GPA ||
> > > > +kvm->mmu_invalidate_range_end ==
> > > > INVALID_GPA))
> > >
> > > INVALID_GPA is an x86-specific define in
> > > arch/x86/include/asm/kvm_host.h, so this doesn't build on other
> > > architectures. The obvious fix is to move it to
> > > include/linux/kvm_host.h.
> >
> > Hmm, INVALID_GPA is defined as ZERO for x86, not 100% confident this is
> > correct choice for other architectures, but after search it has not been
> > used for other architectures, so should be safe to make it common.
>
> INVALID_GPA is defined as all bit 1. Please notice "~" (tilde).
>
> #define INVALID_GPA (~(gpa_t)0)
Thanks for mention. Still looks right moving it to include/linux/kvm_host.h.
Chao
> --
> Isaku Yamahata
Re: [PATCH v10 4/9] KVM: Add KVM_EXIT_MEMORY_FAULT exit
On Tue, Dec 06, 2022 at 03:47:20PM +, Fuad Tabba wrote:
> Hi,
>
> On Fri, Dec 2, 2022 at 6:19 AM Chao Peng wrote:
> >
> > This new KVM exit allows userspace to handle memory-related errors. It
> > indicates an error happens in KVM at guest memory range [gpa, gpa+size).
> > The flags includes additional information for userspace to handle the
> > error. Currently bit 0 is defined as 'private memory' where '1'
> > indicates error happens due to private memory access and '0' indicates
> > error happens due to shared memory access.
> >
> > When private memory is enabled, this new exit will be used for KVM to
> > exit to userspace for shared <-> private memory conversion in memory
> > encryption usage. In such usage, typically there are two kind of memory
> > conversions:
> > - explicit conversion: happens when guest explicitly calls into KVM
> > to map a range (as private or shared), KVM then exits to userspace
> > to perform the map/unmap operations.
> > - implicit conversion: happens in KVM page fault handler where KVM
> > exits to userspace for an implicit conversion when the page is in a
> > different state than requested (private or shared).
> >
> > Suggested-by: Sean Christopherson
> > Co-developed-by: Yu Zhang
> > Signed-off-by: Yu Zhang
> > Signed-off-by: Chao Peng
> > Reviewed-by: Fuad Tabba
> > ---
> > Documentation/virt/kvm/api.rst | 22 ++
> > include/uapi/linux/kvm.h | 8
> > 2 files changed, 30 insertions(+)
> >
> > diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst
> > index 99352170c130..d9edb14ce30b 100644
> > --- a/Documentation/virt/kvm/api.rst
> > +++ b/Documentation/virt/kvm/api.rst
> > @@ -6634,6 +6634,28 @@ array field represents return values. The userspace
> > should update the return
> > values of SBI call before resuming the VCPU. For more details on RISC-V SBI
> > spec refer, https://github.com/riscv/riscv-sbi-doc.
> >
> > +::
> > +
> > + /* KVM_EXIT_MEMORY_FAULT */
> > + struct {
> > + #define KVM_MEMORY_EXIT_FLAG_PRIVATE (1ULL << 0)
> > + __u64 flags;
>
> I see you've removed the padding and increased the flag size.
Yes Sean suggested this and also looks good to me.
Chao
>
> Reviewed-by: Fuad Tabba
> Tested-by: Fuad Tabba
>
> Cheers,
> /fuad
>
>
>
>
> > + __u64 gpa;
> > + __u64 size;
> > + } memory;
> > +
> > +If exit reason is KVM_EXIT_MEMORY_FAULT then it indicates that the VCPU has
> > +encountered a memory error which is not handled by KVM kernel module and
> > +userspace may choose to handle it. The 'flags' field indicates the memory
> > +properties of the exit.
> > +
> > + - KVM_MEMORY_EXIT_FLAG_PRIVATE - indicates the memory error is caused by
> > + private memory access when the bit is set. Otherwise the memory error is
> > + caused by shared memory access when the bit is clear.
> > +
> > +'gpa' and 'size' indicate the memory range the error occurs at. The
> > userspace
> > +may handle the error and return to KVM to retry the previous memory access.
> > +
> > ::
> >
> > /* KVM_EXIT_NOTIFY */
> > diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
> > index 13bff963b8b0..c7e9d375a902 100644
> > --- a/include/uapi/linux/kvm.h
> > +++ b/include/uapi/linux/kvm.h
> > @@ -300,6 +300,7 @@ struct kvm_xen_exit {
> > #define KVM_EXIT_RISCV_SBI35
> > #define KVM_EXIT_RISCV_CSR36
> > #define KVM_EXIT_NOTIFY 37
> > +#define KVM_EXIT_MEMORY_FAULT 38
> >
> > /* For KVM_EXIT_INTERNAL_ERROR */
> > /* Emulate instruction failed. */
> > @@ -541,6 +542,13 @@ struct kvm_run {
> > #define KVM_NOTIFY_CONTEXT_INVALID (1 << 0)
> > __u32 flags;
> > } notify;
> > + /* KVM_EXIT_MEMORY_FAULT */
> > + struct {
> > +#define KVM_MEMORY_EXIT_FLAG_PRIVATE (1ULL << 0)
> > + __u64 flags;
> > + __u64 gpa;
> > + __u64 size;
> > + } memory;
> > /* Fix the size of the union. */
> > char padding[256];
> > };
> > --
> > 2.25.1
> >
Re: [PATCH v10 3/9] KVM: Extend the memslot to support fd-based private memory
On Tue, Dec 06, 2022 at 12:39:18PM +, Fuad Tabba wrote:
> Hi Chao,
>
> On Tue, Dec 6, 2022 at 11:58 AM Chao Peng wrote:
> >
> > On Mon, Dec 05, 2022 at 09:03:11AM +, Fuad Tabba wrote:
> > > Hi Chao,
> > >
> > > On Fri, Dec 2, 2022 at 6:18 AM Chao Peng
> > > wrote:
> > > >
> > > > In memory encryption usage, guest memory may be encrypted with special
> > > > key and can be accessed only by the guest itself. We call such memory
> > > > private memory. It's valueless and sometimes can cause problem to allow
> > > > userspace to access guest private memory. This new KVM memslot extension
> > > > allows guest private memory being provided through a restrictedmem
> > > > backed file descriptor(fd) and userspace is restricted to access the
> > > > bookmarked memory in the fd.
> > > >
> > > > This new extension, indicated by the new flag KVM_MEM_PRIVATE, adds two
> > > > additional KVM memslot fields restricted_fd/restricted_offset to allow
> > > > userspace to instruct KVM to provide guest memory through restricted_fd.
> > > > 'guest_phys_addr' is mapped at the restricted_offset of restricted_fd
> > > > and the size is 'memory_size'.
> > > >
> > > > The extended memslot can still have the userspace_addr(hva). When use, a
> > > > single memslot can maintain both private memory through restricted_fd
> > > > and shared memory through userspace_addr. Whether the private or shared
> > > > part is visible to guest is maintained by other KVM code.
> > > >
> > > > A restrictedmem_notifier field is also added to the memslot structure to
> > > > allow the restricted_fd's backing store to notify KVM the memory change,
> > > > KVM then can invalidate its page table entries or handle memory errors.
> > > >
> > > > Together with the change, a new config HAVE_KVM_RESTRICTED_MEM is added
> > > > and right now it is selected on X86_64 only.
> > > >
> > > > To make future maintenance easy, internally use a binary compatible
> > > > alias struct kvm_user_mem_region to handle both the normal and the
> > > > '_ext' variants.
> > > >
> > > > Co-developed-by: Yu Zhang
> > > > Signed-off-by: Yu Zhang
> > > > Signed-off-by: Chao Peng
> > > > Reviewed-by: Fuad Tabba
> > > > Tested-by: Fuad Tabba
> > >
> > > V9 of this patch [*] had KVM_CAP_PRIVATE_MEM, but it's not in this
> > > patch series anymore. Any reason you removed it, or is it just an
> > > omission?
> >
> > We had some discussion in v9 [1] to add generic memory attributes ioctls
> > and KVM_CAP_PRIVATE_MEM can be implemented as a new
> > KVM_MEMORY_ATTRIBUTE_PRIVATE flag via KVM_GET_SUPPORTED_MEMORY_ATTRIBUTES()
> > ioctl [2]. The api doc has been updated:
> >
> > +- KVM_MEM_PRIVATE, if KVM_MEMORY_ATTRIBUTE_PRIVATE is supported (see
> > + KVM_GET_SUPPORTED_MEMORY_ATTRIBUTES ioctl) …
> >
> >
> > [1] https://lore.kernel.org/linux-mm/y2wb48kd0j4vg...@google.com/
> > [2]
> > https://lore.kernel.org/linux-mm/20221202061347.1070246-3-chao.p.p...@linux.intel.com/
>
> I see. I just retested it with KVM_GET_SUPPORTED_MEMORY_ATTRIBUTES,
> and my Reviewed/Tested-by still apply.
Thanks for the info.
Chao
>
> Cheers,
> /fuad
>
> >
> > Thanks,
> > Chao
> > >
> > > [*]
> > > https://lore.kernel.org/linux-mm/20221025151344.3784230-3-chao.p.p...@linux.intel.com/
> > >
> > > Thanks,
> > > /fuad
> > >
> > > > ---
> > > > Documentation/virt/kvm/api.rst | 40 ++-
> > > > arch/x86/kvm/Kconfig | 2 ++
> > > > arch/x86/kvm/x86.c | 2 +-
> > > > include/linux/kvm_host.h | 8 --
> > > > include/uapi/linux/kvm.h | 28 +++
> > > > virt/kvm/Kconfig | 3 +++
> > > > virt/kvm/kvm_main.c| 49 --
> > > > 7 files changed, 114 insertions(+), 18 deletions(-)
> > > >
> > > > diff --git a/Documentation/virt/kvm/api.rst
> > > > b/Documentation/virt/kvm/api.rst
> > > > index bb2f709c0900..99352170c130 100644
> > > > --- a/Documentation/virt/kvm/api.rst
> > > > +++ b/Documentation/virt/kvm/api.rst
> > > > @@ -1319,7 +1319,7 @@ yet and must be cleared on entry.
> > > > :Capability: KVM_CAP_USER_MEMORY
> > > > :Architectures: all
> > > > :Type: vm ioctl
> > > > -:Parameters: struct kvm_userspace_memory_region (in)
> > > > +:Parameters: struct kvm_userspace_memory_region(_ext) (in)
> > > > :Returns: 0 on success, -1 on error
> > > >
> > > > ::
> > > > @@ -1332,9 +1332,18 @@ yet and must be cleared on entry.
> > > > __u64 userspace_addr; /* start of the userspace allocated
> > > > memory */
> > > >};
> > > >
> > > > + struct kvm_userspace_memory_region_ext {
> > > > + struct kvm_userspace_memory_region region;
> > > > + __u64 restricted_offset;
> > > > + __u32 restricted_fd;
> > > > + __u32 pad1;
> > > > + __u64 pad2[14];
> > > > + };
> > > > +
> > > >/* for kvm_memory_region::flags */
> > > >#define KVM_MEM_LOG_DIRTY_PAGES (1UL << 0)
> > > >#define KVM_MEM_READONLY (1UL << 1)
> > > > +
Re: [PATCH for-8.0] hw/rtc/mc146818rtc: Make this rtc device target independent
Am 6. Dezember 2022 20:06:41 UTC schrieb Thomas Huth :
>The only code that is really, really target dependent is the apic-related
>code in rtc_policy_slew_deliver_irq(). By moving this code into the hw/i386/
>folder (renamed to rtc_apic_policy_slew_deliver_irq()) and passing this
>function as parameter to mc146818_rtc_init(), we can make the RTC completely
>target-independent.
>
>Signed-off-by: Thomas Huth
>---
> include/hw/rtc/mc146818rtc.h | 7 +--
> hw/alpha/dp264.c | 2 +-
> hw/hppa/machine.c| 2 +-
> hw/i386/microvm.c| 3 ++-
> hw/i386/pc.c | 10 +-
> hw/mips/jazz.c | 2 +-
> hw/ppc/pnv.c | 2 +-
> hw/rtc/mc146818rtc.c | 34 +++---
> hw/rtc/meson.build | 3 +--
> 9 files changed, 32 insertions(+), 33 deletions(-)
>
>diff --git a/include/hw/rtc/mc146818rtc.h b/include/hw/rtc/mc146818rtc.h
>index 1db0fcee92..c687953cc4 100644
>--- a/include/hw/rtc/mc146818rtc.h
>+++ b/include/hw/rtc/mc146818rtc.h
>@@ -46,14 +46,17 @@ struct RTCState {
> Notifier clock_reset_notifier;
> LostTickPolicy lost_tick_policy;
> Notifier suspend_notifier;
>+bool (*policy_slew_deliver_irq)(RTCState *s);
> QLIST_ENTRY(RTCState) link;
> };
>
> #define RTC_ISA_IRQ 8
>
>-ISADevice *mc146818_rtc_init(ISABus *bus, int base_year,
>- qemu_irq intercept_irq);
>+ISADevice *mc146818_rtc_init(ISABus *bus, int base_year, qemu_irq
>intercept_irq,
>+ bool (*policy_slew_deliver_irq)(RTCState *s));
> void rtc_set_memory(ISADevice *dev, int addr, int val);
> int rtc_get_memory(ISADevice *dev, int addr);
>+bool rtc_apic_policy_slew_deliver_irq(RTCState *s);
Can we move this declaration into pc.h since it is also implemented there? This
makes it more clear that it is only used in x86 and avoids a "dangling"
declaration for all other architectures.
Thanks,
Bernhard
>+void qmp_rtc_reset_reinjection(Error **errp);
>
> #endif /* HW_RTC_MC146818RTC_H */
>diff --git a/hw/alpha/dp264.c b/hw/alpha/dp264.c
>index c502c8c62a..8723942b52 100644
>--- a/hw/alpha/dp264.c
>+++ b/hw/alpha/dp264.c
>@@ -118,7 +118,7 @@ static void clipper_init(MachineState *machine)
> qdev_connect_gpio_out(i82378_dev, 0, isa_irq);
>
> /* Since we have an SRM-compatible PALcode, use the SRM epoch. */
>-mc146818_rtc_init(isa_bus, 1900, rtc_irq);
>+mc146818_rtc_init(isa_bus, 1900, rtc_irq, NULL);
>
> /* VGA setup. Don't bother loading the bios. */
> pci_vga_init(pci_bus);
>diff --git a/hw/hppa/machine.c b/hw/hppa/machine.c
>index de1cc7ab71..311031714a 100644
>--- a/hw/hppa/machine.c
>+++ b/hw/hppa/machine.c
>@@ -232,7 +232,7 @@ static void machine_hppa_init(MachineState *machine)
> assert(isa_bus);
>
> /* Realtime clock, used by firmware for PDC_TOD call. */
>-mc146818_rtc_init(isa_bus, 2000, NULL);
>+mc146818_rtc_init(isa_bus, 2000, NULL, NULL);
>
> /* Serial ports: Lasi and Dino use a 7.272727 MHz clock. */
> serial_mm_init(addr_space, LASI_UART_HPA + 0x800, 0,
>diff --git a/hw/i386/microvm.c b/hw/i386/microvm.c
>index 170a331e3f..d0ed4dca50 100644
>--- a/hw/i386/microvm.c
>+++ b/hw/i386/microvm.c
>@@ -267,7 +267,8 @@ static void microvm_devices_init(MicrovmMachineState *mms)
>
> if (mms->rtc == ON_OFF_AUTO_ON ||
> (mms->rtc == ON_OFF_AUTO_AUTO && !kvm_enabled())) {
>-rtc_state = mc146818_rtc_init(isa_bus, 2000, NULL);
>+rtc_state = mc146818_rtc_init(isa_bus, 2000, NULL,
>+ rtc_apic_policy_slew_deliver_irq);
> microvm_set_rtc(mms, rtc_state);
> }
>
>diff --git a/hw/i386/pc.c b/hw/i386/pc.c
>index 546b703cb4..650e7bc199 100644
>--- a/hw/i386/pc.c
>+++ b/hw/i386/pc.c
>@@ -1244,6 +1244,13 @@ static void pc_superio_init(ISABus *isa_bus, bool
>create_fdctrl,
> g_free(a20_line);
> }
>
>+bool rtc_apic_policy_slew_deliver_irq(RTCState *s)
>+{
>+apic_reset_irq_delivered();
>+qemu_irq_raise(s->irq);
>+return apic_get_irq_delivered();
>+}
>+
> void pc_basic_device_init(struct PCMachineState *pcms,
> ISABus *isa_bus, qemu_irq *gsi,
> ISADevice **rtc_state,
>@@ -1299,7 +1306,8 @@ void pc_basic_device_init(struct PCMachineState *pcms,
> pit_alt_irq = qdev_get_gpio_in(hpet, HPET_LEGACY_PIT_INT);
> rtc_irq = qdev_get_gpio_in(hpet, HPET_LEGACY_RTC_INT);
> }
>-*rtc_state = mc146818_rtc_init(isa_bus, 2000, rtc_irq);
>+*rtc_state = mc146818_rtc_init(isa_bus, 2000, rtc_irq,
>+ rtc_apic_policy_slew_deliver_irq);
>
> qemu_register_boot_set(pc_boot_set, *rtc_state);
>
>diff --git a/hw/mips/jazz.c b/hw/mips/jazz.c
>index 6aefe9a61b..50fbd57b23 100644
>--- a/hw/mips/jazz.c
>+++ b/hw/mips/jazz.c
>@@ -356,7 +356,7 @@ static void mips_jazz_init(MachineState *machine,
> fdctrl_init_sysbus(qdev_get_gpio_in(rc4030, 1),
Re: [PATCH v3] hw/pvrdma: Protect against buggy or malicious guest driver
On 4/5/22 12:31, Marcel Apfelbaum wrote:
> Hi Yuval,
> Thank you for the changes.
>
> On Sun, Apr 3, 2022 at 11:54 AM Yuval Shaia wrote:
>>
>> Guest driver might execute HW commands when shared buffers are not yet
>> allocated.
>> This could happen on purpose (malicious guest) or because of some other
>> guest/host address mapping error.
>> We need to protect againts such case.
>>
>> Fixes: CVE-2022-1050
>>
>> Reported-by: Raven
>> Signed-off-by: Yuval Shaia
>> ---
>> v1 -> v2:
>> * Commit message changes
>> v2 -> v3:
>> * Exclude cosmetic changes
>> ---
>> hw/rdma/vmw/pvrdma_cmd.c | 6 ++
>> 1 file changed, 6 insertions(+)
>>
>> diff --git a/hw/rdma/vmw/pvrdma_cmd.c b/hw/rdma/vmw/pvrdma_cmd.c
>> index da7ddfa548..89db963c46 100644
>> --- a/hw/rdma/vmw/pvrdma_cmd.c
>> +++ b/hw/rdma/vmw/pvrdma_cmd.c
>> @@ -796,6 +796,12 @@ int pvrdma_exec_cmd(PVRDMADev *dev)
>>
>> dsr_info = >dsr_info;
>>
>> +if (!dsr_info->dsr) {
>> +/* Buggy or malicious guest driver */
>> +rdma_error_report("Exec command without dsr, req or rsp
>> buffers");
>> +goto out;
>> +}
>> +
>> if (dsr_info->req->hdr.cmd >= sizeof(cmd_handlers) /
>>sizeof(struct cmd_handler)) {
>> rdma_error_report("Unsupported command");
>> --
>> 2.20.1
>>
>
> cc-ing Peter and Philippe for a question:
> Do we have a "Security Fixes" or a "Misc" subtree? Otherwise it will
> have to wait a week or so.
>
> Reviewed by: Marcel Apfelbaum
> Thanks,
> Marcel
>
Hi all,
patch is reviewed, anything holding back the inclusion of this security fix?
Thanks,
Claudio
Re: Thoughts on removing the TARGET_I386 part of hw/display/vga/vbe_portio_list[]
On 06/12/2022 16:23, Richard Henderson wrote: On 12/6/22 10:02, Peter Maydell wrote: On Tue, 6 Dec 2022 at 15:56, Philippe Mathieu-Daudé wrote: On 6/12/22 13:30, Dr. David Alan Gilbert wrote: I don't know that bit of qemu well enough to know whether the cpu part of qemu should be splitting the unaligned accesses or not. All I/O accesses are gated thru access_with_adjusted_size() in softmmu/memory.c. There is an old access_with_adjusted_size_unaligned() version [1] from Andrew and a more recent series [2] from Richard. Maybe the latter fixes some long-standing bug [3] we have here? There definitely are some unaddressed bugs there -- maybe this is the time to work through what semantics we want that softmmu code to provide and fix the bugs... Yes, indeed. Let's not forget Mark C-A's m68k bug[1] which so far has no resolution. r~ [1] https://gitlab.com/qemu-project/qemu/-/issues/360 That would definitely be useful: since Richard worked on this series, I managed to develop a hack that allows me to work around the issue for my particular use-case which is why I haven't been focusing on this. The main concerns are listed in the above issue at https://gitlab.com/qemu-project/qemu/-/issues/360#note_597130838. Defining the behaviour doesn't seem too bad, but it is likely some things that unintentionally depend upon the existing behaviour will break. ATB, Mark.
Re: [PATCH v10 2/9] KVM: Introduce per-page memory attributes
On Tue, Dec 06, 2022 at 03:07:27PM +, Fuad Tabba wrote:
> Hi,
>
> On Fri, Dec 2, 2022 at 6:18 AM Chao Peng wrote:
> >
> > In confidential computing usages, whether a page is private or shared is
> > necessary information for KVM to perform operations like page fault
> > handling, page zapping etc. There are other potential use cases for
> > per-page memory attributes, e.g. to make memory read-only (or no-exec,
> > or exec-only, etc.) without having to modify memslots.
> >
> > Introduce two ioctls (advertised by KVM_CAP_MEMORY_ATTRIBUTES) to allow
> > userspace to operate on the per-page memory attributes.
> > - KVM_SET_MEMORY_ATTRIBUTES to set the per-page memory attributes to
> > a guest memory range.
> > - KVM_GET_SUPPORTED_MEMORY_ATTRIBUTES to return the KVM supported
> > memory attributes.
> >
> > KVM internally uses xarray to store the per-page memory attributes.
> >
> > Suggested-by: Sean Christopherson
> > Signed-off-by: Chao Peng
> > Link: https://lore.kernel.org/all/y2wb48kd0j4vg...@google.com/
> > ---
> > Documentation/virt/kvm/api.rst | 63
> > arch/x86/kvm/Kconfig | 1 +
> > include/linux/kvm_host.h | 3 ++
> > include/uapi/linux/kvm.h | 17
> > virt/kvm/Kconfig | 3 ++
> > virt/kvm/kvm_main.c| 76 ++
> > 6 files changed, 163 insertions(+)
> >
> > diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst
> > index 5617bc4f899f..bb2f709c0900 100644
> > --- a/Documentation/virt/kvm/api.rst
> > +++ b/Documentation/virt/kvm/api.rst
> > @@ -5952,6 +5952,59 @@ delivery must be provided via the "reg_aen" struct.
> > The "pad" and "reserved" fields may be used for future extensions and
> > should be
> > set to 0s by userspace.
> >
> > +4.138 KVM_GET_SUPPORTED_MEMORY_ATTRIBUTES
> > +-
> > +
> > +:Capability: KVM_CAP_MEMORY_ATTRIBUTES
> > +:Architectures: x86
> > +:Type: vm ioctl
> > +:Parameters: u64 memory attributes bitmask(out)
> > +:Returns: 0 on success, <0 on error
> > +
> > +Returns supported memory attributes bitmask. Supported memory attributes
> > will
> > +have the corresponding bits set in u64 memory attributes bitmask.
> > +
> > +The following memory attributes are defined::
> > +
> > + #define KVM_MEMORY_ATTRIBUTE_READ (1ULL << 0)
> > + #define KVM_MEMORY_ATTRIBUTE_WRITE (1ULL << 1)
> > + #define KVM_MEMORY_ATTRIBUTE_EXECUTE (1ULL << 2)
> > + #define KVM_MEMORY_ATTRIBUTE_PRIVATE (1ULL << 3)
> > +
> > +4.139 KVM_SET_MEMORY_ATTRIBUTES
> > +-
> > +
> > +:Capability: KVM_CAP_MEMORY_ATTRIBUTES
> > +:Architectures: x86
> > +:Type: vm ioctl
> > +:Parameters: struct kvm_memory_attributes(in/out)
> > +:Returns: 0 on success, <0 on error
> > +
> > +Sets memory attributes for pages in a guest memory range. Parameters are
> > +specified via the following structure::
> > +
> > + struct kvm_memory_attributes {
> > + __u64 address;
> > + __u64 size;
> > + __u64 attributes;
> > + __u64 flags;
> > + };
> > +
> > +The user sets the per-page memory attributes to a guest memory range
> > indicated
> > +by address/size, and in return KVM adjusts address and size to reflect the
> > +actual pages of the memory range have been successfully set to the
> > attributes.
> > +If the call returns 0, "address" is updated to the last successful address
> > + 1
> > +and "size" is updated to the remaining address size that has not been set
> > +successfully. The user should check the return value as well as the size to
> > +decide if the operation succeeded for the whole range or not. The user may
> > want
> > +to retry the operation with the returned address/size if the previous
> > range was
> > +partially successful.
> > +
> > +Both address and size should be page aligned and the supported attributes
> > can be
> > +retrieved with KVM_GET_SUPPORTED_MEMORY_ATTRIBUTES.
> > +
> > +The "flags" field may be used for future extensions and should be set to
> > 0s.
> > +
> > 5. The kvm_run structure
> >
> >
> > @@ -8270,6 +8323,16 @@ structure.
> > When getting the Modified Change Topology Report value, the attr->addr
> > must point to a byte where the value will be stored or retrieved from.
> >
> > +8.40 KVM_CAP_MEMORY_ATTRIBUTES
> > +--
> > +
> > +:Capability: KVM_CAP_MEMORY_ATTRIBUTES
> > +:Architectures: x86
> > +:Type: vm
> > +
> > +This capability indicates KVM supports per-page memory attributes and
> > ioctls
> > +KVM_GET_SUPPORTED_MEMORY_ATTRIBUTES/KVM_SET_MEMORY_ATTRIBUTES are
> > available.
> > +
> > 9. Known KVM API problems
> > =
> >
> > diff --git a/arch/x86/kvm/Kconfig b/arch/x86/kvm/Kconfig
> > index fbeaa9ddef59..a8e379a3afee 100644
> > --- a/arch/x86/kvm/Kconfig
> > +++ b/arch/x86/kvm/Kconfig
> > @@ -49,6
Re: [PATCH v3 02/13] tcg/s390x: Remove TCG_REG_TB
On 12/7/22 01:45, Thomas Huth wrote: On 06/12/2022 23.22, Richard Henderson wrote: On 12/6/22 13:29, Ilya Leoshkevich wrote: This change doesn't seem to affect that, but what is the minimum supported s390x qemu host? z900? Possibly z990, if I'm reading the gcc processor_flags_table[] correctly; long-displacement-facility is definitely a minimum. We probably should revisit what the minimum for TCG should be, assert those features at startup, and drop the corresponding runtime tests. If we consider the official IBM support statement: https://www.ibm.com/support/pages/system/files/inline-files/IBM%20Mainframe%20Life%20Cycle%20History%20V2.10%20-%20Sept%2013%202022_1.pdf ... that would mean that the z10 and all older machines are not supported anymore. Thanks for the pointer. It would appear that z114 exits support at the end of this month, which would leave z12 as minimum supported cpu. Even assuming z196 gets us extended-immediate, general-insn-extension, load-on-condition, and distinct-operands, which are all quite important to TCG, and constitute almost all of the current runtime checks. The other metric would be matching the set of supported cpus from the set of supported os distributions, but I would be ready to believe z196 is below the minimum there too. r~
Re: [PATCH for-8.0] hw/rtc/mc146818rtc: Make this rtc device target independent
Am 6. Dezember 2022 20:06:41 UTC schrieb Thomas Huth :
>The only code that is really, really target dependent is the apic-related
>code in rtc_policy_slew_deliver_irq(). By moving this code into the hw/i386/
>folder (renamed to rtc_apic_policy_slew_deliver_irq()) and passing this
>function as parameter to mc146818_rtc_init(), we can make the RTC completely
>target-independent.
>
>Signed-off-by: Thomas Huth
>---
> include/hw/rtc/mc146818rtc.h | 7 +--
> hw/alpha/dp264.c | 2 +-
> hw/hppa/machine.c| 2 +-
> hw/i386/microvm.c| 3 ++-
> hw/i386/pc.c | 10 +-
> hw/mips/jazz.c | 2 +-
> hw/ppc/pnv.c | 2 +-
> hw/rtc/mc146818rtc.c | 34 +++---
> hw/rtc/meson.build | 3 +--
> 9 files changed, 32 insertions(+), 33 deletions(-)
>
>diff --git a/include/hw/rtc/mc146818rtc.h b/include/hw/rtc/mc146818rtc.h
>index 1db0fcee92..c687953cc4 100644
>--- a/include/hw/rtc/mc146818rtc.h
>+++ b/include/hw/rtc/mc146818rtc.h
>@@ -46,14 +46,17 @@ struct RTCState {
> Notifier clock_reset_notifier;
> LostTickPolicy lost_tick_policy;
This lost_tick_policy attribute along with its enum is now redundant and can be
removed. Removing it avoids an error condition (see below).
> Notifier suspend_notifier;
>+bool (*policy_slew_deliver_irq)(RTCState *s);
> QLIST_ENTRY(RTCState) link;
> };
>
> #define RTC_ISA_IRQ 8
>
>-ISADevice *mc146818_rtc_init(ISABus *bus, int base_year,
>- qemu_irq intercept_irq);
>+ISADevice *mc146818_rtc_init(ISABus *bus, int base_year, qemu_irq
>intercept_irq,
>+ bool (*policy_slew_deliver_irq)(RTCState *s));
> void rtc_set_memory(ISADevice *dev, int addr, int val);
> int rtc_get_memory(ISADevice *dev, int addr);
>+bool rtc_apic_policy_slew_deliver_irq(RTCState *s);
>+void qmp_rtc_reset_reinjection(Error **errp);
>
> #endif /* HW_RTC_MC146818RTC_H */
>diff --git a/hw/alpha/dp264.c b/hw/alpha/dp264.c
>index c502c8c62a..8723942b52 100644
>--- a/hw/alpha/dp264.c
>+++ b/hw/alpha/dp264.c
>@@ -118,7 +118,7 @@ static void clipper_init(MachineState *machine)
> qdev_connect_gpio_out(i82378_dev, 0, isa_irq);
>
> /* Since we have an SRM-compatible PALcode, use the SRM epoch. */
>-mc146818_rtc_init(isa_bus, 1900, rtc_irq);
>+mc146818_rtc_init(isa_bus, 1900, rtc_irq, NULL);
>
> /* VGA setup. Don't bother loading the bios. */
> pci_vga_init(pci_bus);
>diff --git a/hw/hppa/machine.c b/hw/hppa/machine.c
>index de1cc7ab71..311031714a 100644
>--- a/hw/hppa/machine.c
>+++ b/hw/hppa/machine.c
>@@ -232,7 +232,7 @@ static void machine_hppa_init(MachineState *machine)
> assert(isa_bus);
>
> /* Realtime clock, used by firmware for PDC_TOD call. */
>-mc146818_rtc_init(isa_bus, 2000, NULL);
>+mc146818_rtc_init(isa_bus, 2000, NULL, NULL);
>
> /* Serial ports: Lasi and Dino use a 7.272727 MHz clock. */
> serial_mm_init(addr_space, LASI_UART_HPA + 0x800, 0,
>diff --git a/hw/i386/microvm.c b/hw/i386/microvm.c
>index 170a331e3f..d0ed4dca50 100644
>--- a/hw/i386/microvm.c
>+++ b/hw/i386/microvm.c
>@@ -267,7 +267,8 @@ static void microvm_devices_init(MicrovmMachineState *mms)
>
> if (mms->rtc == ON_OFF_AUTO_ON ||
> (mms->rtc == ON_OFF_AUTO_AUTO && !kvm_enabled())) {
>-rtc_state = mc146818_rtc_init(isa_bus, 2000, NULL);
>+rtc_state = mc146818_rtc_init(isa_bus, 2000, NULL,
>+ rtc_apic_policy_slew_deliver_irq);
> microvm_set_rtc(mms, rtc_state);
> }
>
>diff --git a/hw/i386/pc.c b/hw/i386/pc.c
>index 546b703cb4..650e7bc199 100644
>--- a/hw/i386/pc.c
>+++ b/hw/i386/pc.c
>@@ -1244,6 +1244,13 @@ static void pc_superio_init(ISABus *isa_bus, bool
>create_fdctrl,
> g_free(a20_line);
> }
>
>+bool rtc_apic_policy_slew_deliver_irq(RTCState *s)
>+{
>+apic_reset_irq_delivered();
>+qemu_irq_raise(s->irq);
>+return apic_get_irq_delivered();
>+}
>+
> void pc_basic_device_init(struct PCMachineState *pcms,
> ISABus *isa_bus, qemu_irq *gsi,
> ISADevice **rtc_state,
>@@ -1299,7 +1306,8 @@ void pc_basic_device_init(struct PCMachineState *pcms,
> pit_alt_irq = qdev_get_gpio_in(hpet, HPET_LEGACY_PIT_INT);
> rtc_irq = qdev_get_gpio_in(hpet, HPET_LEGACY_RTC_INT);
> }
>-*rtc_state = mc146818_rtc_init(isa_bus, 2000, rtc_irq);
>+*rtc_state = mc146818_rtc_init(isa_bus, 2000, rtc_irq,
>+ rtc_apic_policy_slew_deliver_irq);
>
> qemu_register_boot_set(pc_boot_set, *rtc_state);
>
>diff --git a/hw/mips/jazz.c b/hw/mips/jazz.c
>index 6aefe9a61b..50fbd57b23 100644
>--- a/hw/mips/jazz.c
>+++ b/hw/mips/jazz.c
>@@ -356,7 +356,7 @@ static void mips_jazz_init(MachineState *machine,
> fdctrl_init_sysbus(qdev_get_gpio_in(rc4030, 1), 0x80003000, fds);
>
> /* Real time clock */
>-
Re: [PATCH v10 2/9] KVM: Introduce per-page memory attributes
On Tue, Dec 06, 2022 at 10:34:32AM -0300, Fabiano Rosas wrote:
> Chao Peng writes:
>
> > In confidential computing usages, whether a page is private or shared is
> > necessary information for KVM to perform operations like page fault
> > handling, page zapping etc. There are other potential use cases for
> > per-page memory attributes, e.g. to make memory read-only (or no-exec,
> > or exec-only, etc.) without having to modify memslots.
> >
> > Introduce two ioctls (advertised by KVM_CAP_MEMORY_ATTRIBUTES) to allow
> > userspace to operate on the per-page memory attributes.
> > - KVM_SET_MEMORY_ATTRIBUTES to set the per-page memory attributes to
> > a guest memory range.
> > - KVM_GET_SUPPORTED_MEMORY_ATTRIBUTES to return the KVM supported
> > memory attributes.
> >
> > KVM internally uses xarray to store the per-page memory attributes.
> >
> > Suggested-by: Sean Christopherson
> > Signed-off-by: Chao Peng
> > Link: https://lore.kernel.org/all/y2wb48kd0j4vg...@google.com/
> > ---
> > Documentation/virt/kvm/api.rst | 63
> > arch/x86/kvm/Kconfig | 1 +
> > include/linux/kvm_host.h | 3 ++
> > include/uapi/linux/kvm.h | 17
> > virt/kvm/Kconfig | 3 ++
> > virt/kvm/kvm_main.c| 76 ++
> > 6 files changed, 163 insertions(+)
> >
> > diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst
> > index 5617bc4f899f..bb2f709c0900 100644
> > --- a/Documentation/virt/kvm/api.rst
> > +++ b/Documentation/virt/kvm/api.rst
> > @@ -5952,6 +5952,59 @@ delivery must be provided via the "reg_aen" struct.
> > The "pad" and "reserved" fields may be used for future extensions and
> > should be
> > set to 0s by userspace.
> >
> > +4.138 KVM_GET_SUPPORTED_MEMORY_ATTRIBUTES
> > +-
> > +
> > +:Capability: KVM_CAP_MEMORY_ATTRIBUTES
> > +:Architectures: x86
> > +:Type: vm ioctl
> > +:Parameters: u64 memory attributes bitmask(out)
> > +:Returns: 0 on success, <0 on error
> > +
> > +Returns supported memory attributes bitmask. Supported memory attributes
> > will
> > +have the corresponding bits set in u64 memory attributes bitmask.
> > +
> > +The following memory attributes are defined::
> > +
> > + #define KVM_MEMORY_ATTRIBUTE_READ (1ULL << 0)
> > + #define KVM_MEMORY_ATTRIBUTE_WRITE (1ULL << 1)
> > + #define KVM_MEMORY_ATTRIBUTE_EXECUTE (1ULL << 2)
> > + #define KVM_MEMORY_ATTRIBUTE_PRIVATE (1ULL << 3)
> > +
> > +4.139 KVM_SET_MEMORY_ATTRIBUTES
> > +-
> > +
> > +:Capability: KVM_CAP_MEMORY_ATTRIBUTES
> > +:Architectures: x86
> > +:Type: vm ioctl
> > +:Parameters: struct kvm_memory_attributes(in/out)
> > +:Returns: 0 on success, <0 on error
> > +
> > +Sets memory attributes for pages in a guest memory range. Parameters are
> > +specified via the following structure::
> > +
> > + struct kvm_memory_attributes {
> > + __u64 address;
> > + __u64 size;
> > + __u64 attributes;
> > + __u64 flags;
> > + };
> > +
> > +The user sets the per-page memory attributes to a guest memory range
> > indicated
> > +by address/size, and in return KVM adjusts address and size to reflect the
> > +actual pages of the memory range have been successfully set to the
> > attributes.
>
> This wording could cause some confusion, what about a simpler:
>
> "reflect the range of pages that had its attributes successfully set"
Thanks, this is much better.
>
> > +If the call returns 0, "address" is updated to the last successful address
> > + 1
> > +and "size" is updated to the remaining address size that has not been set
> > +successfully.
>
> "address + 1 page" or "subsequent page" perhaps.
>
> In fact, wouldn't this all become simpler if size were number of pages
> instead?
It indeed becomes better if the size is number of pages and the address
is gfn, but I think we don't want to imply that the page size is 4K to
userspace.
>
> > The user should check the return value as well as the size to
> > +decide if the operation succeeded for the whole range or not. The user may
> > want
> > +to retry the operation with the returned address/size if the previous
> > range was
> > +partially successful.
> > +
> > +Both address and size should be page aligned and the supported attributes
> > can be
> > +retrieved with KVM_GET_SUPPORTED_MEMORY_ATTRIBUTES.
> > +
> > +The "flags" field may be used for future extensions and should be set to
> > 0s.
> > +
>
> ...
>
> > +static int kvm_vm_ioctl_set_mem_attributes(struct kvm *kvm,
> > + struct kvm_memory_attributes *attrs)
> > +{
> > + gfn_t start, end;
> > + unsigned long i;
> > + void *entry;
> > + u64 supported_attrs = kvm_supported_mem_attributes(kvm);
> > +
> > + /* flags is currently not used. */
> > + if (attrs->flags)
> > + return -EINVAL;
> > + if
Re: [PATCH for 7.2?] target/i386: Remove compilation errors when -Werror=maybe-uninitialized
Hi Stefan,
On 12/7/22 15:09, Stefan Hajnoczi wrote:
> On Wed, 7 Dec 2022 at 08:31, Eric Auger wrote:
>> On 12/7/22 14:24, Eric Auger wrote:
>>> Initialize r0-3 to avoid compilation errors when
>>> -Werror=maybe-uninitialized is used
>>>
>>> ../target/i386/ops_sse.h: In function ‘helper_vpermdq_ymm’:
>>> ../target/i386/ops_sse.h:2495:13: error: ‘r3’ may be used uninitialized in
>>> this function [-Werror=maybe-uninitialized]
>>> 2495 | d->Q(3) = r3;
>>> | ^~~~
>>> ../target/i386/ops_sse.h:2494:13: error: ‘r2’ may be used uninitialized in
>>> this function [-Werror=maybe-uninitialized]
>>> 2494 | d->Q(2) = r2;
>>> | ^~~~
>>> ../target/i386/ops_sse.h:2493:13: error: ‘r1’ may be used uninitialized in
>>> this function [-Werror=maybe-uninitialized]
>>> 2493 | d->Q(1) = r1;
>>> | ^~~~
>>> ../target/i386/ops_sse.h:2492:13: error: ‘r0’ may be used uninitialized in
>>> this function [-Werror=maybe-uninitialized]
>>> 2492 | d->Q(0) = r0;
>>> | ^~~~
>>>
>>> Signed-off-by: Eric Auger
>>> Fixes: 790684776861 ("target/i386: reimplement 0x0f 0x3a, add AVX")
>>>
>>> ---
>>>
>>> Am I the only one getting this? Or anything wrong in my setup.
>> With Stefan's correct address. Forgive me for the noise.
> When is -Wmaybe-uninitialized used? QEMU's build system doesn't set
> it. Unless it's automatically set by meson this must be a manual
> --extra-cflags= option you set.
I am using this configure cmd line:
./configure --prefix=/usr --sysconfdir=/etc --libexecdir=/usr/lib/qemu
--target-list=x86_64-softmmu --docdir=/usr/share/doc/qemu --enable-kvm
--extra-cflags=-O --enable-trace-backends=log --python=/usr/bin/python3
--extra-cflags=-Wall --extra-cflags=-Wundef
--extra-cflags=-Wwrite-strings --extra-cflags=-Wmissing-prototypes
--extra-cflags=-fno-strict-aliasing --extra-cflags=-fno-common
--extra-cflags=-Werror=type-limits
>
> If you added it manually then let's fix this in 8.0 since it's not
> tested/supported and very few people will see this issue.
Thanks
Eric
>
> Stefan
>
Re: [PATCH 00/18] block: Introduce a block graph rwlock
Am 07/12/2022 um 14:18 schrieb Kevin Wolf: > This series supersedes the first half of Emanuele's "Protect the block > layer with a rwlock: part 1". It introduces the basic infrastructure for > protecting the block graph (specifically parent/child links) with a > rwlock. Actually taking the reader lock in all necessary places is left > for future series. > > Compared to Emanuele's series, this one adds patches to make use of > clang's Thread Safety Analysis (TSA) feature in order to statically > check at compile time that the places where we assert that we hold the > lock actually do hold it. Once we cover all relevant places, the check > can be extended to verify that all accesses of bs->children and > bs->parents hold the lock. > > For reference, here is the more detailed version of our plan in > Emanuele's words from his series: > > The aim is to replace the current AioContext lock with much > fine-grained locks, aimed to protect only specific data. Currently > the AioContext lock is used pretty much everywhere, and it's not > even clear what it is protecting exactly. > > The aim of the rwlock is to cover graph modifications: more > precisely, when a BlockDriverState parent or child list is modified > or read, since it can be concurrently accessed by the main loop and > iothreads. > > The main assumption is that the main loop is the only one allowed to > perform graph modifications, and so far this has always been held by > the current code. > > The rwlock is inspired from cpus-common.c implementation, and aims > to reduce cacheline bouncing by having per-aiocontext counter of > readers. All details and implementation of the lock are in patch 2. > > We distinguish between writer (main loop, under BQL) that modifies > the graph, and readers (all other coroutines running in various > AioContext), that go through the graph edges, reading ->parents > and->children. The writer (main loop) has an "exclusive" access, > so it first waits for current read to finish, and then prevents > incoming ones from entering while it has the exclusive access. The > readers (coroutines in multiple AioContext) are free to access the > graph as long the writer is not modifying the graph. In case it is, > they go in a CoQueue and sleep until the writer is done. > > In this and following series, we try to follow the following locking > pattern: > > - bdrv_co_* functions that call BlockDriver callbacks always expect > the lock to be taken, therefore they assert. > > - blk_co_* functions are called from external code outside the block > layer, which should not have to care about the block layer's > internal locking. Usually they also call blk_wait_while_drained(). > Therefore they take the lock internally. > > The long term goal of this series is to eventually replace the > AioContext lock, so that we can get rid of it once and for all. > > Emanuele Giuseppe Esposito (7): > graph-lock: Implement guard macros > async: Register/unregister aiocontext in graph lock list > block: wrlock in bdrv_replace_child_noperm > block: remove unnecessary assert_bdrv_graph_writable() > block: assert that graph read and writes are performed correctly > block-coroutine-wrapper.py: introduce annotations that take the graph > rdlock > block: use co_wrapper_mixed_bdrv_rdlock in functions taking the rdlock > > Kevin Wolf (10): > block: Factor out bdrv_drain_all_begin_nopoll() > Import clang-tsa.h > clang-tsa: Add TSA_ASSERT() macro > clang-tsa: Add macros for shared locks > configure: Enable -Wthread-safety if present > test-bdrv-drain: Fix incorrrect drain assumptions > block: Fix locking in external_snapshot_prepare() > graph-lock: TSA annotations for lock/unlock functions > Mark assert_bdrv_graph_readable/writable() GRAPH_RD/WRLOCK > block: GRAPH_RDLOCK for functions only called by co_wrappers > > Paolo Bonzini (1): > graph-lock: Introduce a lock to protect block graph operations > Reviewed-by: Emanuele Giuseppe Esposito ^ I am curious to see if I am allowed to have my r-b also on my patches :) > configure | 1 + > block/coroutines.h | 19 +- > include/block/aio.h| 9 + > include/block/block-common.h | 9 +- > include/block/block-global-state.h | 1 + > include/block/block-io.h | 53 +++-- > include/block/block_int-common.h | 24 +-- > include/block/block_int-global-state.h | 17 -- > include/block/block_int.h | 1 + > include/block/graph-lock.h | 280 + > include/qemu/clang-tsa.h | 114 ++ > block.c| 24 ++- > block/graph-lock.c | 275 > block/io.c | 21 +- > blockdev.c
Re: [PATCH for 7.2?] target/i386: Remove compilation errors when -Werror=maybe-uninitialized
On Wed, 7 Dec 2022 at 08:31, Eric Auger wrote:
> On 12/7/22 14:24, Eric Auger wrote:
> > Initialize r0-3 to avoid compilation errors when
> > -Werror=maybe-uninitialized is used
> >
> > ../target/i386/ops_sse.h: In function ‘helper_vpermdq_ymm’:
> > ../target/i386/ops_sse.h:2495:13: error: ‘r3’ may be used uninitialized in
> > this function [-Werror=maybe-uninitialized]
> > 2495 | d->Q(3) = r3;
> > | ^~~~
> > ../target/i386/ops_sse.h:2494:13: error: ‘r2’ may be used uninitialized in
> > this function [-Werror=maybe-uninitialized]
> > 2494 | d->Q(2) = r2;
> > | ^~~~
> > ../target/i386/ops_sse.h:2493:13: error: ‘r1’ may be used uninitialized in
> > this function [-Werror=maybe-uninitialized]
> > 2493 | d->Q(1) = r1;
> > | ^~~~
> > ../target/i386/ops_sse.h:2492:13: error: ‘r0’ may be used uninitialized in
> > this function [-Werror=maybe-uninitialized]
> > 2492 | d->Q(0) = r0;
> > | ^~~~
> >
> > Signed-off-by: Eric Auger
> > Fixes: 790684776861 ("target/i386: reimplement 0x0f 0x3a, add AVX")
> >
> > ---
> >
> > Am I the only one getting this? Or anything wrong in my setup.
>
> With Stefan's correct address. Forgive me for the noise.
When is -Wmaybe-uninitialized used? QEMU's build system doesn't set
it. Unless it's automatically set by meson this must be a manual
--extra-cflags= option you set.
If you added it manually then let's fix this in 8.0 since it's not
tested/supported and very few people will see this issue.
Stefan
Re: [PATCH 1/1] qemu-iotests/stream-under-throttle: do not shutdown QEMU
Am 07.12.22 um 14:23 schrieb Thomas Huth:
On 07/12/2022 14.14, Christian Borntraeger wrote:
Without a kernel or boot disk a QEMU on s390 will exit (usually with a
disabled wait state). This breaks the stream-under-throttle test case.
Do not exit qemu if on s390.
Signed-off-by: Christian Borntraeger
---
tests/qemu-iotests/tests/stream-under-throttle | 2 ++
1 file changed, 2 insertions(+)
diff --git a/tests/qemu-iotests/tests/stream-under-throttle
b/tests/qemu-iotests/tests/stream-under-throttle
index 8d2d9e16840d..c24dfbcaa2f2 100755
--- a/tests/qemu-iotests/tests/stream-under-throttle
+++ b/tests/qemu-iotests/tests/stream-under-throttle
@@ -88,6 +88,8 @@ class TestStreamWithThrottle(iotests.QMPTestCase):
'x-iops-total=1,x-bps-total=104857600')
self.vm.add_blockdev(self.vm.qmp_to_opts(blockdev))
self.vm.add_device('virtio-blk,iothread=iothr0,drive=throttled-node')
+ if iotests.qemu_default_machine == 's390-ccw-virtio':
+ self.vm.add_args('-no-shutdown')
self.vm.launch()
I guess you could even add that unconditionally for all architectures?
maybe. It might even fix other architecture with the same problem. But I dont
know if thats the case.
So we can start with this fix and then remove the if at a later point in time
if necessary/useful.
Anyway:
Reviewed-by: Thomas Huth
