[Xen-devel] [Qemu-devel] [PATCH v7 01/42] configure: Define TARGET_ALIGNED_ONLY
Rename ALIGNED_ONLY to TARGET_ALIGNED_ONLY for clarity and move defines out of target/foo/cpu.h into configure, as we do with TARGET_WORDS_BIGENDIAN, so that it is always defined early. Poisoned TARGET_ALIGNED_ONLY to prevent use in common code. Signed-off-by: Tony Nguyen Reviewed-by: Philippe Mathieu-Daudé Reviewed-by: Richard Henderson Reviewed-by: Aleksandar Markovic Reviewed-by: Cornelia Huck --- configure | 10 +- include/exec/poison.h | 1 + include/qom/cpu.h | 2 +- target/alpha/cpu.h| 2 -- target/hppa/cpu.h | 1 - target/mips/cpu.h | 2 -- target/sh4/cpu.h | 2 -- target/sparc/cpu.h| 2 -- target/xtensa/cpu.h | 2 -- tcg/tcg.c | 2 +- tcg/tcg.h | 8 +--- 11 files changed, 17 insertions(+), 17 deletions(-) diff --git a/configure b/configure index 714e7fb..482ba0b 100755 --- a/configure +++ b/configure @@ -7431,8 +7431,13 @@ for target in $target_list; do target_dir="$target" config_target_mak=$target_dir/config-target.mak target_name=$(echo $target | cut -d '-' -f 1) +target_aligned_only="no" +case "$target_name" in + alpha|hppa|mips64el|mips64|mipsel|mips|mipsn32|mipsn32el|sh4|sh4eb|sparc|sparc64|sparc32plus|xtensa|xtensaeb) + target_aligned_only="yes" + ;; +esac target_bigendian="no" - case "$target_name" in armeb|aarch64_be|hppa|lm32|m68k|microblaze|mips|mipsn32|mips64|moxie|or1k|ppc|ppc64|ppc64abi32|s390x|sh4eb|sparc|sparc64|sparc32plus|xtensaeb) target_bigendian=yes @@ -7717,6 +7722,9 @@ fi if supported_whpx_target $target; then echo "CONFIG_WHPX=y" >> $config_target_mak fi +if test "$target_aligned_only" = "yes" ; then + echo "TARGET_ALIGNED_ONLY=y" >> $config_target_mak +fi if test "$target_bigendian" = "yes" ; then echo "TARGET_WORDS_BIGENDIAN=y" >> $config_target_mak fi diff --git a/include/exec/poison.h b/include/exec/poison.h index b862320..955eb86 100644 --- a/include/exec/poison.h +++ b/include/exec/poison.h @@ -35,6 +35,7 @@ #pragma GCC poison TARGET_UNICORE32 #pragma GCC poison TARGET_XTENSA +#pragma GCC poison TARGET_ALIGNED_ONLY #pragma GCC poison TARGET_HAS_BFLT #pragma GCC poison TARGET_NAME #pragma GCC poison TARGET_SUPPORTS_MTTCG diff --git a/include/qom/cpu.h b/include/qom/cpu.h index 5ee0046..9b50b73 100644 --- a/include/qom/cpu.h +++ b/include/qom/cpu.h @@ -89,7 +89,7 @@ struct TranslationBlock; * @do_unassigned_access: Callback for unassigned access handling. * (this is deprecated: new targets should use do_transaction_failed instead) * @do_unaligned_access: Callback for unaligned access handling, if - * the target defines #ALIGNED_ONLY. + * the target defines #TARGET_ALIGNED_ONLY. * @do_transaction_failed: Callback for handling failed memory transactions * (ie bus faults or external aborts; not MMU faults) * @virtio_is_big_endian: Callback to return %true if a CPU which supports diff --git a/target/alpha/cpu.h b/target/alpha/cpu.h index b3e8a82..16eb804 100644 --- a/target/alpha/cpu.h +++ b/target/alpha/cpu.h @@ -23,8 +23,6 @@ #include "cpu-qom.h" #include "exec/cpu-defs.h" -#define ALIGNED_ONLY - /* Alpha processors have a weak memory model */ #define TCG_GUEST_DEFAULT_MO (0) diff --git a/target/hppa/cpu.h b/target/hppa/cpu.h index aab251b..2be67c2 100644 --- a/target/hppa/cpu.h +++ b/target/hppa/cpu.h @@ -30,7 +30,6 @@ basis. It's probably easier to fall back to a strong memory model. */ #define TCG_GUEST_DEFAULT_MOTCG_MO_ALL -#define ALIGNED_ONLY #define MMU_KERNEL_IDX 0 #define MMU_USER_IDX 3 #define MMU_PHYS_IDX 4 diff --git a/target/mips/cpu.h b/target/mips/cpu.h index 21c0615..c13cd4e 100644 --- a/target/mips/cpu.h +++ b/target/mips/cpu.h @@ -1,8 +1,6 @@ #ifndef MIPS_CPU_H #define MIPS_CPU_H -#define ALIGNED_ONLY - #include "cpu-qom.h" #include "exec/cpu-defs.h" #include "fpu/softfloat.h" diff --git a/target/sh4/cpu.h b/target/sh4/cpu.h index aee733e..ecaa7a1 100644 --- a/target/sh4/cpu.h +++ b/target/sh4/cpu.h @@ -23,8 +23,6 @@ #include "cpu-qom.h" #include "exec/cpu-defs.h" -#define ALIGNED_ONLY - /* CPU Subtypes */ #define SH_CPU_SH7750 (1 << 0) #define SH_CPU_SH7750S (1 << 1) diff --git a/target/sparc/cpu.h b/target/sparc/cpu.h index 8ed2250..1406f0b 100644 --- a/target/sparc/cpu.h +++ b/target/sparc/cpu.h @@ -5,8 +5,6 @@ #include "cpu-qom.h" #include "exec/cpu-defs.h" -#define ALIGNED_ONLY - #if !defined(TARGET_SPARC64) #define TARGET_DPREGS 16 #else diff --git a/target/xtensa/cpu.h b/target/xtensa/cpu.h index 2c27713..0459243 100644 --- a/target/xtensa/cpu.h +++ b/target/xtensa/cpu.h @@ -32,8 +32,6 @@ #include "exec/cpu-defs.h" #include "xtensa-isa.h" -#define ALIGNED_ONLY - /* Xtensa processors have a weak memory model */ #define TCG_GUEST_DEFAULT_MO (0) diff --git a/tcg/tcg.c b/tcg/tcg.c index be2c33c..8d23fb0 100644 --- a/tcg/tcg.c +++ b/tcg/tcg.c @@ -1926,7 +1926,7 @@ static const char * const ldst_name[] = }; static const char * const alignment_
[Xen-devel] [Qemu-devel] [PATCH v7 03/42] memory: Introduce size_memop
The memory_region_dispatch_{read|write} operand "unsigned size" is
being converted into a "MemOp op".
Introduce no-op size_memop to aid preparatory conversion of
interfaces.
Once interfaces are converted, size_memop will be implemented to
return a MemOp from size in bytes.
Signed-off-by: Tony Nguyen
Reviewed-by: Richard Henderson
---
include/exec/memop.h | 10 ++
1 file changed, 10 insertions(+)
diff --git a/include/exec/memop.h b/include/exec/memop.h
index 7262ca3..dfd76a1 100644
--- a/include/exec/memop.h
+++ b/include/exec/memop.h
@@ -107,4 +107,14 @@ typedef enum MemOp {
MO_SSIZE = MO_SIZE | MO_SIGN,
} MemOp;
+/* Size in bytes to MemOp. */
+static inline unsigned size_memop(unsigned size)
+{
+/*
+ * FIXME: No-op to aid conversion of memory_region_dispatch_{read|write}
+ * "unsigned size" operand into a "MemOp op".
+ */
+return size;
+}
+
#endif
--
1.8.3.1
?
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [Qemu-devel] [PATCH v7 05/42] hw/s390x: Access MemoryRegion with MemOp
The memory_region_dispatch_{read|write} operand "unsigned size" is
being converted into a "MemOp op".
Convert interfaces by using no-op size_memop.
After all interfaces are converted, size_memop will be implemented
and the memory_region_dispatch_{read|write} operand "unsigned size"
will be converted into a "MemOp op".
As size_memop is a no-op, this patch does not change any behaviour.
Signed-off-by: Tony Nguyen
Reviewed-by: Richard Henderson
Reviewed-by: Cornelia Huck
---
hw/s390x/s390-pci-inst.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/hw/s390x/s390-pci-inst.c b/hw/s390x/s390-pci-inst.c
index 0023514..0c958fc 100644
--- a/hw/s390x/s390-pci-inst.c
+++ b/hw/s390x/s390-pci-inst.c
@@ -15,6 +15,7 @@
#include "cpu.h"
#include "s390-pci-inst.h"
#include "s390-pci-bus.h"
+#include "exec/memop.h"
#include "exec/memory-internal.h"
#include "qemu/error-report.h"
#include "sysemu/hw_accel.h"
@@ -372,7 +373,7 @@ static MemTxResult zpci_read_bar(S390PCIBusDevice *pbdev,
uint8_t pcias,
mr = pbdev->pdev->io_regions[pcias].memory;
mr = s390_get_subregion(mr, offset, len);
offset -= mr->addr;
-return memory_region_dispatch_read(mr, offset, data, len,
+return memory_region_dispatch_read(mr, offset, data, size_memop(len),
MEMTXATTRS_UNSPECIFIED);
}
@@ -471,7 +472,7 @@ static MemTxResult zpci_write_bar(S390PCIBusDevice *pbdev,
uint8_t pcias,
mr = pbdev->pdev->io_regions[pcias].memory;
mr = s390_get_subregion(mr, offset, len);
offset -= mr->addr;
-return memory_region_dispatch_write(mr, offset, data, len,
+return memory_region_dispatch_write(mr, offset, data, size_memop(len),
MEMTXATTRS_UNSPECIFIED);
}
@@ -780,7 +781,8 @@ int pcistb_service_call(S390CPU *cpu, uint8_t r1, uint8_t
r3, uint64_t gaddr,
for (i = 0; i < len / 8; i++) {
result = memory_region_dispatch_write(mr, offset + i * 8,
- ldq_p(buffer + i * 8), 8,
+ ldq_p(buffer + i * 8),
+ size_memop(8),
MEMTXATTRS_UNSPECIFIED);
if (result != MEMTX_OK) {
s390_program_interrupt(env, PGM_OPERAND, 6, ra);
--
1.8.3.1
?
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [Qemu-devel] [PATCH v7 04/42] target/mips: Access MemoryRegion with MemOp
The memory_region_dispatch_{read|write} operand "unsigned size" is
being converted into a "MemOp op".
Convert interfaces by using no-op size_memop.
After all interfaces are converted, size_memop will be implemented
and the memory_region_dispatch_{read|write} operand "unsigned size"
will be converted into a "MemOp op".
As size_memop is a no-op, this patch does not change any behaviour.
Signed-off-by: Tony Nguyen
Reviewed-by: Philippe Mathieu-Daudé
Reviewed-by: Richard Henderson
---
target/mips/op_helper.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/target/mips/op_helper.c b/target/mips/op_helper.c
index 9e2e02f..1c72a00 100644
--- a/target/mips/op_helper.c
+++ b/target/mips/op_helper.c
@@ -24,6 +24,7 @@
#include "exec/helper-proto.h"
#include "exec/exec-all.h"
#include "exec/cpu_ldst.h"
+#include "exec/memop.h"
#include "sysemu/kvm.h"
/*/
@@ -4740,11 +4741,11 @@ void helper_cache(CPUMIPSState *env, target_ulong addr,
uint32_t op)
if (op == 9) {
/* Index Store Tag */
memory_region_dispatch_write(env->itc_tag, index, env->CP0_TagLo,
- 8, MEMTXATTRS_UNSPECIFIED);
+ size_memop(8), MEMTXATTRS_UNSPECIFIED);
} else if (op == 5) {
/* Index Load Tag */
memory_region_dispatch_read(env->itc_tag, index, &env->CP0_TagLo,
-8, MEMTXATTRS_UNSPECIFIED);
+size_memop(8), MEMTXATTRS_UNSPECIFIED);
}
#endif
}
--
1.8.3.1
?
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [Qemu-devel] [PATCH v7 06/42] hw/intc/armv7m_nic: Access MemoryRegion with MemOp
The memory_region_dispatch_{read|write} operand "unsigned size" is
being converted into a "MemOp op".
Convert interfaces by using no-op size_memop.
After all interfaces are converted, size_memop will be implemented
and the memory_region_dispatch_{read|write} operand "unsigned size"
will be converted into a "MemOp op".
As size_memop is a no-op, this patch does not change any behaviour.
Signed-off-by: Tony Nguyen
Reviewed-by: Philippe Mathieu-Daudé
Reviewed-by: Richard Henderson
---
hw/intc/armv7m_nvic.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/hw/intc/armv7m_nvic.c b/hw/intc/armv7m_nvic.c
index 9f8f0d3..237ccef 100644
--- a/hw/intc/armv7m_nvic.c
+++ b/hw/intc/armv7m_nvic.c
@@ -18,6 +18,7 @@
#include "hw/intc/armv7m_nvic.h"
#include "target/arm/cpu.h"
#include "exec/exec-all.h"
+#include "exec/memop.h"
#include "qemu/log.h"
#include "qemu/module.h"
#include "trace.h"
@@ -2345,7 +2346,8 @@ static MemTxResult nvic_sysreg_ns_write(void *opaque,
hwaddr addr,
if (attrs.secure) {
/* S accesses to the alias act like NS accesses to the real region */
attrs.secure = 0;
-return memory_region_dispatch_write(mr, addr, value, size, attrs);
+return memory_region_dispatch_write(mr, addr, value, size_memop(size),
+attrs);
} else {
/* NS attrs are RAZ/WI for privileged, and BusFault for user */
if (attrs.user) {
@@ -2364,7 +2366,8 @@ static MemTxResult nvic_sysreg_ns_read(void *opaque,
hwaddr addr,
if (attrs.secure) {
/* S accesses to the alias act like NS accesses to the real region */
attrs.secure = 0;
-return memory_region_dispatch_read(mr, addr, data, size, attrs);
+return memory_region_dispatch_read(mr, addr, data, size_memop(size),
+ attrs);
} else {
/* NS attrs are RAZ/WI for privileged, and BusFault for user */
if (attrs.user) {
@@ -2390,7 +2393,8 @@ static MemTxResult nvic_systick_write(void *opaque,
hwaddr addr,
/* Direct the access to the correct systick */
mr = sysbus_mmio_get_region(SYS_BUS_DEVICE(&s->systick[attrs.secure]), 0);
-return memory_region_dispatch_write(mr, addr, value, size, attrs);
+return memory_region_dispatch_write(mr, addr, value, size_memop(size),
+attrs);
}
static MemTxResult nvic_systick_read(void *opaque, hwaddr addr,
@@ -2402,7 +2406,7 @@ static MemTxResult nvic_systick_read(void *opaque, hwaddr
addr,
/* Direct the access to the correct systick */
mr = sysbus_mmio_get_region(SYS_BUS_DEVICE(&s->systick[attrs.secure]), 0);
-return memory_region_dispatch_read(mr, addr, data, size, attrs);
+return memory_region_dispatch_read(mr, addr, data, size_memop(size),
attrs);
}
static const MemoryRegionOps nvic_systick_ops = {
--
1.8.3.1
?
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [Qemu-devel] [PATCH v7 07/42] hw/virtio: Access MemoryRegion with MemOp
The memory_region_dispatch_{read|write} operand "unsigned size" is
being converted into a "MemOp op".
Convert interfaces by using no-op size_memop.
After all interfaces are converted, size_memop will be implemented
and the memory_region_dispatch_{read|write} operand "unsigned size"
will be converted into a "MemOp op".
As size_memop is a no-op, this patch does not change any behaviour.
Signed-off-by: Tony Nguyen
Reviewed-by: Richard Henderson
Reviewed-by: Cornelia Huck
---
hw/virtio/virtio-pci.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/hw/virtio/virtio-pci.c b/hw/virtio/virtio-pci.c
index f6d2223..25875c8 100644
--- a/hw/virtio/virtio-pci.c
+++ b/hw/virtio/virtio-pci.c
@@ -17,6 +17,7 @@
#include "qemu/osdep.h"
+#include "exec/memop.h"
#include "standard-headers/linux/virtio_pci.h"
#include "hw/virtio/virtio.h"
#include "hw/pci/pci.h"
@@ -550,7 +551,8 @@ void virtio_address_space_write(VirtIOPCIProxy *proxy,
hwaddr addr,
/* As length is under guest control, handle illegal values. */
return;
}
-memory_region_dispatch_write(mr, addr, val, len, MEMTXATTRS_UNSPECIFIED);
+memory_region_dispatch_write(mr, addr, val, size_memop(len),
+ MEMTXATTRS_UNSPECIFIED);
}
static void
@@ -573,7 +575,8 @@ virtio_address_space_read(VirtIOPCIProxy *proxy, hwaddr
addr,
/* Make sure caller aligned buf properly */
assert(!(((uintptr_t)buf) & (len - 1)));
-memory_region_dispatch_read(mr, addr, &val, len, MEMTXATTRS_UNSPECIFIED);
+memory_region_dispatch_read(mr, addr, &val, size_memop(len),
+MEMTXATTRS_UNSPECIFIED);
switch (len) {
case 1:
pci_set_byte(buf, val);
--
1.8.3.1
?
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [Qemu-devel] [PATCH v7 09/42] exec: Access MemoryRegion with MemOp
The memory_region_dispatch_{read|write} operand "unsigned size" is
being converted into a "MemOp op".
Convert interfaces by using no-op size_memop.
After all interfaces are converted, size_memop will be implemented
and the memory_region_dispatch_{read|write} operand "unsigned size"
will be converted into a "MemOp op".
As size_memop is a no-op, this patch does not change any behaviour.
Signed-off-by: Tony Nguyen
Reviewed-by: Philippe Mathieu-Daudé
Reviewed-by: Richard Henderson
---
exec.c| 6 --
memory_ldst.inc.c | 18 +-
2 files changed, 13 insertions(+), 11 deletions(-)
diff --git a/exec.c b/exec.c
index 3e78de3..9f69197 100644
--- a/exec.c
+++ b/exec.c
@@ -3334,7 +3334,8 @@ static MemTxResult flatview_write_continue(FlatView *fv,
hwaddr addr,
/* XXX: could force current_cpu to NULL to avoid
potential bugs */
val = ldn_p(buf, l);
-result |= memory_region_dispatch_write(mr, addr1, val, l, attrs);
+result |= memory_region_dispatch_write(mr, addr1, val,
+ size_memop(l), attrs);
} else {
/* RAM case */
ptr = qemu_ram_ptr_length(mr->ram_block, addr1, &l, false);
@@ -3395,7 +3396,8 @@ MemTxResult flatview_read_continue(FlatView *fv, hwaddr
addr,
/* I/O case */
release_lock |= prepare_mmio_access(mr);
l = memory_access_size(mr, l, addr1);
-result |= memory_region_dispatch_read(mr, addr1, &val, l, attrs);
+result |= memory_region_dispatch_read(mr, addr1, &val,
+ size_memop(l), attrs);
stn_p(buf, l, val);
} else {
/* RAM case */
diff --git a/memory_ldst.inc.c b/memory_ldst.inc.c
index acf865b..1e8a2fc 100644
--- a/memory_ldst.inc.c
+++ b/memory_ldst.inc.c
@@ -38,7 +38,7 @@ static inline uint32_t glue(address_space_ldl_internal,
SUFFIX)(ARG1_DECL,
release_lock |= prepare_mmio_access(mr);
/* I/O case */
-r = memory_region_dispatch_read(mr, addr1, &val, 4, attrs);
+r = memory_region_dispatch_read(mr, addr1, &val, size_memop(4), attrs);
#if defined(TARGET_WORDS_BIGENDIAN)
if (endian == DEVICE_LITTLE_ENDIAN) {
val = bswap32(val);
@@ -114,7 +114,7 @@ static inline uint64_t glue(address_space_ldq_internal,
SUFFIX)(ARG1_DECL,
release_lock |= prepare_mmio_access(mr);
/* I/O case */
-r = memory_region_dispatch_read(mr, addr1, &val, 8, attrs);
+r = memory_region_dispatch_read(mr, addr1, &val, size_memop(8), attrs);
#if defined(TARGET_WORDS_BIGENDIAN)
if (endian == DEVICE_LITTLE_ENDIAN) {
val = bswap64(val);
@@ -188,7 +188,7 @@ uint32_t glue(address_space_ldub, SUFFIX)(ARG1_DECL,
release_lock |= prepare_mmio_access(mr);
/* I/O case */
-r = memory_region_dispatch_read(mr, addr1, &val, 1, attrs);
+r = memory_region_dispatch_read(mr, addr1, &val, size_memop(1), attrs);
} else {
/* RAM case */
ptr = qemu_map_ram_ptr(mr->ram_block, addr1);
@@ -224,7 +224,7 @@ static inline uint32_t glue(address_space_lduw_internal,
SUFFIX)(ARG1_DECL,
release_lock |= prepare_mmio_access(mr);
/* I/O case */
-r = memory_region_dispatch_read(mr, addr1, &val, 2, attrs);
+r = memory_region_dispatch_read(mr, addr1, &val, size_memop(2), attrs);
#if defined(TARGET_WORDS_BIGENDIAN)
if (endian == DEVICE_LITTLE_ENDIAN) {
val = bswap16(val);
@@ -300,7 +300,7 @@ void glue(address_space_stl_notdirty, SUFFIX)(ARG1_DECL,
if (l < 4 || !memory_access_is_direct(mr, true)) {
release_lock |= prepare_mmio_access(mr);
-r = memory_region_dispatch_write(mr, addr1, val, 4, attrs);
+r = memory_region_dispatch_write(mr, addr1, val, size_memop(4), attrs);
} else {
ptr = qemu_map_ram_ptr(mr->ram_block, addr1);
stl_p(ptr, val);
@@ -346,7 +346,7 @@ static inline void glue(address_space_stl_internal,
SUFFIX)(ARG1_DECL,
val = bswap32(val);
}
#endif
-r = memory_region_dispatch_write(mr, addr1, val, 4, attrs);
+r = memory_region_dispatch_write(mr, addr1, val, size_memop(4), attrs);
} else {
/* RAM case */
ptr = qemu_map_ram_ptr(mr->ram_block, addr1);
@@ -408,7 +408,7 @@ void glue(address_space_stb, SUFFIX)(ARG1_DECL,
mr = TRANSLATE(addr, &addr1, &l, true, attrs);
if (!memory_access_is_direct(mr, true)) {
release_lock |= prepare_mmio_access(mr);
-r = memory_region_dispatch_write(mr, addr1, val, 1, attrs);
+r = memory_region_dispatch_write(mr, addr1, val, size_memop(1), attrs);
} else {
/* RAM case */
ptr = qemu_map_ram_ptr(mr->ram_block, addr1);
@@ -451,7 +451,7 @@ static inline void glue(address_space_stw_internal,
SUFFIX)(ARG1_DECL,
[Xen-devel] [Qemu-devel] [PATCH v7 08/42] hw/vfio: Access MemoryRegion with MemOp
The memory_region_dispatch_{read|write} operand "unsigned size" is
being converted into a "MemOp op".
Convert interfaces by using no-op size_memop.
After all interfaces are converted, size_memop will be implemented
and the memory_region_dispatch_{read|write} operand "unsigned size"
will be converted into a "MemOp op".
As size_memop is a no-op, this patch does not change any behaviour.
Signed-off-by: Tony Nguyen
Reviewed-by: Richard Henderson
Reviewed-by: Cornelia Huck
---
hw/vfio/pci-quirks.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/hw/vfio/pci-quirks.c b/hw/vfio/pci-quirks.c
index b35a640..fb3cc33 100644
--- a/hw/vfio/pci-quirks.c
+++ b/hw/vfio/pci-quirks.c
@@ -11,6 +11,7 @@
*/
#include "qemu/osdep.h"
+#include "exec/memop.h"
#include "qemu/units.h"
#include "qemu/error-report.h"
#include "qemu/main-loop.h"
@@ -1071,7 +1072,7 @@ static void vfio_rtl8168_quirk_address_write(void
*opaque, hwaddr addr,
/* Write to the proper guest MSI-X table instead */
memory_region_dispatch_write(&vdev->pdev.msix_table_mmio,
- offset, val, size,
+ offset, val, size_memop(size),
MEMTXATTRS_UNSPECIFIED);
}
return; /* Do not write guest MSI-X data to hardware */
@@ -1102,7 +1103,8 @@ static uint64_t vfio_rtl8168_quirk_data_read(void *opaque,
if (rtl->enabled && (vdev->pdev.cap_present & QEMU_PCI_CAP_MSIX)) {
hwaddr offset = rtl->addr & 0xfff;
memory_region_dispatch_read(&vdev->pdev.msix_table_mmio, offset,
-&data, size, MEMTXATTRS_UNSPECIFIED);
+&data, size_memop(size),
+MEMTXATTRS_UNSPECIFIED);
trace_vfio_quirk_rtl8168_msix_read(vdev->vbasedev.name, offset, data);
}
--
1.8.3.1
?
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [Qemu-devel] [PATCH v7 10/42] cputlb: Access MemoryRegion with MemOp
The memory_region_dispatch_{read|write} operand "unsigned size" is
being converted into a "MemOp op".
Convert interfaces by using no-op size_memop.
After all interfaces are converted, size_memop will be implemented
and the memory_region_dispatch_{read|write} operand "unsigned size"
will be converted into a "MemOp op".
As size_memop is a no-op, this patch does not change any behaviour.
Signed-off-by: Tony Nguyen
Reviewed-by: Philippe Mathieu-Daudé
Reviewed-by: Richard Henderson
---
accel/tcg/cputlb.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/accel/tcg/cputlb.c b/accel/tcg/cputlb.c
index 523be4c..6c83878 100644
--- a/accel/tcg/cputlb.c
+++ b/accel/tcg/cputlb.c
@@ -906,8 +906,8 @@ static uint64_t io_readx(CPUArchState *env, CPUIOTLBEntry
*iotlbentry,
qemu_mutex_lock_iothread();
locked = true;
}
-r = memory_region_dispatch_read(mr, mr_offset,
-&val, size, iotlbentry->attrs);
+r = memory_region_dispatch_read(mr, mr_offset, &val, size_memop(size),
+iotlbentry->attrs);
if (r != MEMTX_OK) {
hwaddr physaddr = mr_offset +
section->offset_within_address_space -
@@ -947,8 +947,8 @@ static void io_writex(CPUArchState *env, CPUIOTLBEntry
*iotlbentry,
qemu_mutex_lock_iothread();
locked = true;
}
-r = memory_region_dispatch_write(mr, mr_offset,
- val, size, iotlbentry->attrs);
+r = memory_region_dispatch_write(mr, mr_offset, val, size_memop(size),
+ iotlbentry->attrs);
if (r != MEMTX_OK) {
hwaddr physaddr = mr_offset +
section->offset_within_address_space -
--
1.8.3.1
?
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [Qemu-devel] [PATCH v7 12/42] hw/s390x: Hard code size with MO_{8|16|32|64}
Temporarily no-op size_memop was introduced to aid the conversion of
memory_region_dispatch_{read|write} operand "unsigned size" into
"MemOp op".
Now size_memop is implemented, again hard coded size but with
MO_{8|16|32|64}. This is more expressive and avoids size_memop calls.
Signed-off-by: Tony Nguyen
Reviewed-by: Richard Henderson
Reviewed-by: Cornelia Huck
---
hw/s390x/s390-pci-inst.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/hw/s390x/s390-pci-inst.c b/hw/s390x/s390-pci-inst.c
index 0c958fc..0e92a37 100644
--- a/hw/s390x/s390-pci-inst.c
+++ b/hw/s390x/s390-pci-inst.c
@@ -782,8 +782,7 @@ int pcistb_service_call(S390CPU *cpu, uint8_t r1, uint8_t
r3, uint64_t gaddr,
for (i = 0; i < len / 8; i++) {
result = memory_region_dispatch_write(mr, offset + i * 8,
ldq_p(buffer + i * 8),
- size_memop(8),
- MEMTXATTRS_UNSPECIFIED);
+ MO_64, MEMTXATTRS_UNSPECIFIED);
if (result != MEMTX_OK) {
s390_program_interrupt(env, PGM_OPERAND, 6, ra);
return 0;
--
1.8.3.1
?
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [Qemu-devel] [PATCH v7 11/42] memory: Access MemoryRegion with MemOp
Convert memory_region_dispatch_{read|write} operand "unsigned size"
into a "MemOp op".
Signed-off-by: Tony Nguyen
Reviewed-by: Richard Henderson
---
include/exec/memop.h | 20 ++--
include/exec/memory.h | 9 +
memory.c | 7 +--
3 files changed, 24 insertions(+), 12 deletions(-)
diff --git a/include/exec/memop.h b/include/exec/memop.h
index dfd76a1..0a610b7 100644
--- a/include/exec/memop.h
+++ b/include/exec/memop.h
@@ -12,6 +12,8 @@
#ifndef MEMOP_H
#define MEMOP_H
+#include "qemu/host-utils.h"
+
typedef enum MemOp {
MO_8 = 0,
MO_16= 1,
@@ -107,14 +109,20 @@ typedef enum MemOp {
MO_SSIZE = MO_SIZE | MO_SIGN,
} MemOp;
+/* MemOp to size in bytes. */
+static inline unsigned memop_size(MemOp op)
+{
+return 1 << (op & MO_SIZE);
+}
+
/* Size in bytes to MemOp. */
-static inline unsigned size_memop(unsigned size)
+static inline MemOp size_memop(unsigned size)
{
-/*
- * FIXME: No-op to aid conversion of memory_region_dispatch_{read|write}
- * "unsigned size" operand into a "MemOp op".
- */
-return size;
+#ifdef CONFIG_DEBUG_TCG
+/* Power of 2 up to 8. */
+assert((size & (size - 1)) == 0 && size >= 1 && size <= 8);
+#endif
+return ctz32(size);
}
#endif
diff --git a/include/exec/memory.h b/include/exec/memory.h
index bb0961d..975b86a 100644
--- a/include/exec/memory.h
+++ b/include/exec/memory.h
@@ -19,6 +19,7 @@
#include "exec/cpu-common.h"
#include "exec/hwaddr.h"
#include "exec/memattrs.h"
+#include "exec/memop.h"
#include "exec/ramlist.h"
#include "qemu/queue.h"
#include "qemu/int128.h"
@@ -1731,13 +1732,13 @@ void mtree_info(bool flatview, bool dispatch_tree, bool
owner);
* @mr: #MemoryRegion to access
* @addr: address within that region
* @pval: pointer to uint64_t which the data is written to
- * @size: size of the access in bytes
+ * @op: size, sign, and endianness of the memory operation
* @attrs: memory transaction attributes to use for the access
*/
MemTxResult memory_region_dispatch_read(MemoryRegion *mr,
hwaddr addr,
uint64_t *pval,
-unsigned size,
+MemOp op,
MemTxAttrs attrs);
/**
* memory_region_dispatch_write: perform a write directly to the specified
@@ -1746,13 +1747,13 @@ MemTxResult memory_region_dispatch_read(MemoryRegion
*mr,
* @mr: #MemoryRegion to access
* @addr: address within that region
* @data: data to write
- * @size: size of the access in bytes
+ * @op: size, sign, and endianness of the memory operation
* @attrs: memory transaction attributes to use for the access
*/
MemTxResult memory_region_dispatch_write(MemoryRegion *mr,
hwaddr addr,
uint64_t data,
- unsigned size,
+ MemOp op,
MemTxAttrs attrs);
/**
diff --git a/memory.c b/memory.c
index 5d8c9a9..89ea4fb 100644
--- a/memory.c
+++ b/memory.c
@@ -1439,9 +1439,10 @@ static MemTxResult
memory_region_dispatch_read1(MemoryRegion *mr,
MemTxResult memory_region_dispatch_read(MemoryRegion *mr,
hwaddr addr,
uint64_t *pval,
-unsigned size,
+MemOp op,
MemTxAttrs attrs)
{
+unsigned size = memop_size(op);
MemTxResult r;
if (!memory_region_access_valid(mr, addr, size, false, attrs)) {
@@ -1483,9 +1484,11 @@ static bool
memory_region_dispatch_write_eventfds(MemoryRegion *mr,
MemTxResult memory_region_dispatch_write(MemoryRegion *mr,
hwaddr addr,
uint64_t data,
- unsigned size,
+ MemOp op,
MemTxAttrs attrs)
{
+unsigned size = memop_size(op);
+
if (!memory_region_access_valid(mr, addr, size, true, attrs)) {
unassigned_mem_write(mr, addr, data, size);
return MEMTX_DECODE_ERROR;
--
1.8.3.1
?
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [Qemu-devel] [PATCH v7 13/42] target/mips: Hard code size with MO_{8|16|32|64}
Temporarily no-op size_memop was introduced to aid the conversion of
memory_region_dispatch_{read|write} operand "unsigned size" into
"MemOp op".
Now size_memop is implemented, again hard coded size but with
MO_{8|16|32|64}. This is more expressive and avoids size_memop calls.
Signed-off-by: Tony Nguyen
Reviewed-by: Richard Henderson
---
target/mips/op_helper.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/target/mips/op_helper.c b/target/mips/op_helper.c
index 1c72a00..e79f99d 100644
--- a/target/mips/op_helper.c
+++ b/target/mips/op_helper.c
@@ -4741,11 +4741,11 @@ void helper_cache(CPUMIPSState *env, target_ulong addr,
uint32_t op)
if (op == 9) {
/* Index Store Tag */
memory_region_dispatch_write(env->itc_tag, index, env->CP0_TagLo,
- size_memop(8), MEMTXATTRS_UNSPECIFIED);
+ MO_64, MEMTXATTRS_UNSPECIFIED);
} else if (op == 5) {
/* Index Load Tag */
memory_region_dispatch_read(env->itc_tag, index, &env->CP0_TagLo,
-size_memop(8), MEMTXATTRS_UNSPECIFIED);
+MO_64, MEMTXATTRS_UNSPECIFIED);
}
#endif
}
--
1.8.3.1
?
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [Qemu-devel] [PATCH v7 14/42] exec: Hard code size with MO_{8|16|32|64}
Temporarily no-op size_memop was introduced to aid the conversion of
memory_region_dispatch_{read|write} operand "unsigned size" into
"MemOp op".
Now size_memop is implemented, again hard coded size but with
MO_{8|16|32|64}. This is more expressive and avoids size_memop calls.
Signed-off-by: Tony Nguyen
Reviewed-by: Richard Henderson
---
memory_ldst.inc.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/memory_ldst.inc.c b/memory_ldst.inc.c
index 1e8a2fc..de658c4 100644
--- a/memory_ldst.inc.c
+++ b/memory_ldst.inc.c
@@ -38,7 +38,7 @@ static inline uint32_t glue(address_space_ldl_internal,
SUFFIX)(ARG1_DECL,
release_lock |= prepare_mmio_access(mr);
/* I/O case */
-r = memory_region_dispatch_read(mr, addr1, &val, size_memop(4), attrs);
+r = memory_region_dispatch_read(mr, addr1, &val, MO_32, attrs);
#if defined(TARGET_WORDS_BIGENDIAN)
if (endian == DEVICE_LITTLE_ENDIAN) {
val = bswap32(val);
@@ -114,7 +114,7 @@ static inline uint64_t glue(address_space_ldq_internal,
SUFFIX)(ARG1_DECL,
release_lock |= prepare_mmio_access(mr);
/* I/O case */
-r = memory_region_dispatch_read(mr, addr1, &val, size_memop(8), attrs);
+r = memory_region_dispatch_read(mr, addr1, &val, MO_64, attrs);
#if defined(TARGET_WORDS_BIGENDIAN)
if (endian == DEVICE_LITTLE_ENDIAN) {
val = bswap64(val);
@@ -188,7 +188,7 @@ uint32_t glue(address_space_ldub, SUFFIX)(ARG1_DECL,
release_lock |= prepare_mmio_access(mr);
/* I/O case */
-r = memory_region_dispatch_read(mr, addr1, &val, size_memop(1), attrs);
+r = memory_region_dispatch_read(mr, addr1, &val, MO_8, attrs);
} else {
/* RAM case */
ptr = qemu_map_ram_ptr(mr->ram_block, addr1);
@@ -224,7 +224,7 @@ static inline uint32_t glue(address_space_lduw_internal,
SUFFIX)(ARG1_DECL,
release_lock |= prepare_mmio_access(mr);
/* I/O case */
-r = memory_region_dispatch_read(mr, addr1, &val, size_memop(2), attrs);
+r = memory_region_dispatch_read(mr, addr1, &val, MO_16, attrs);
#if defined(TARGET_WORDS_BIGENDIAN)
if (endian == DEVICE_LITTLE_ENDIAN) {
val = bswap16(val);
@@ -300,7 +300,7 @@ void glue(address_space_stl_notdirty, SUFFIX)(ARG1_DECL,
if (l < 4 || !memory_access_is_direct(mr, true)) {
release_lock |= prepare_mmio_access(mr);
-r = memory_region_dispatch_write(mr, addr1, val, size_memop(4), attrs);
+r = memory_region_dispatch_write(mr, addr1, val, MO_32, attrs);
} else {
ptr = qemu_map_ram_ptr(mr->ram_block, addr1);
stl_p(ptr, val);
@@ -346,7 +346,7 @@ static inline void glue(address_space_stl_internal,
SUFFIX)(ARG1_DECL,
val = bswap32(val);
}
#endif
-r = memory_region_dispatch_write(mr, addr1, val, size_memop(4), attrs);
+r = memory_region_dispatch_write(mr, addr1, val, MO_32, attrs);
} else {
/* RAM case */
ptr = qemu_map_ram_ptr(mr->ram_block, addr1);
@@ -408,7 +408,7 @@ void glue(address_space_stb, SUFFIX)(ARG1_DECL,
mr = TRANSLATE(addr, &addr1, &l, true, attrs);
if (!memory_access_is_direct(mr, true)) {
release_lock |= prepare_mmio_access(mr);
-r = memory_region_dispatch_write(mr, addr1, val, size_memop(1), attrs);
+r = memory_region_dispatch_write(mr, addr1, val, MO_8, attrs);
} else {
/* RAM case */
ptr = qemu_map_ram_ptr(mr->ram_block, addr1);
@@ -451,7 +451,7 @@ static inline void glue(address_space_stw_internal,
SUFFIX)(ARG1_DECL,
val = bswap16(val);
}
#endif
-r = memory_region_dispatch_write(mr, addr1, val, size_memop(2), attrs);
+r = memory_region_dispatch_write(mr, addr1, val, MO_16, attrs);
} else {
/* RAM case */
ptr = qemu_map_ram_ptr(mr->ram_block, addr1);
@@ -524,7 +524,7 @@ static void glue(address_space_stq_internal,
SUFFIX)(ARG1_DECL,
val = bswap64(val);
}
#endif
-r = memory_region_dispatch_write(mr, addr1, val, size_memop(8), attrs);
+r = memory_region_dispatch_write(mr, addr1, val, MO_64, attrs);
} else {
/* RAM case */
ptr = qemu_map_ram_ptr(mr->ram_block, addr1);
--
1.8.3.1
?
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [Qemu-devel] [PATCH v7 15/42] hw/audio: Declare device little or big endian
For each device declared with DEVICE_NATIVE_ENDIAN, find the set of
targets from the set of target/hw/*/device.o.
If the set of targets are all little or all big endian, re-declare
the device endianness as DEVICE_LITTLE_ENDIAN or DEVICE_BIG_ENDIAN
respectively.
This *naive* deduction may result in genuinely native endian devices
being incorrectly declared as little or big endian, but should not
introduce regressions for current targets.
These devices should be re-declared as DEVICE_NATIVE_ENDIAN if 1) it
has a new target with an opposite endian or 2) someone informed knows
better =)
Signed-off-by: Tony Nguyen
---
hw/audio/cs4231.c | 2 +-
hw/audio/marvell_88w8618.c | 2 +-
hw/audio/milkymist-ac97.c | 2 +-
hw/audio/pl041.c | 2 +-
4 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/hw/audio/cs4231.c b/hw/audio/cs4231.c
index 8372299..8946648 100644
--- a/hw/audio/cs4231.c
+++ b/hw/audio/cs4231.c
@@ -132,7 +132,7 @@ static void cs_mem_write(void *opaque, hwaddr addr,
static const MemoryRegionOps cs_mem_ops = {
.read = cs_mem_read,
.write = cs_mem_write,
-.endianness = DEVICE_NATIVE_ENDIAN,
+.endianness = DEVICE_BIG_ENDIAN,
};
static const VMStateDescription vmstate_cs4231 = {
diff --git a/hw/audio/marvell_88w8618.c b/hw/audio/marvell_88w8618.c
index ff1a0d0..a79e0b1 100644
--- a/hw/audio/marvell_88w8618.c
+++ b/hw/audio/marvell_88w8618.c
@@ -240,7 +240,7 @@ static void mv88w8618_audio_reset(DeviceState *d)
static const MemoryRegionOps mv88w8618_audio_ops = {
.read = mv88w8618_audio_read,
.write = mv88w8618_audio_write,
-.endianness = DEVICE_NATIVE_ENDIAN,
+.endianness = DEVICE_LITTLE_ENDIAN,
};
static void mv88w8618_audio_init(Object *obj)
diff --git a/hw/audio/milkymist-ac97.c b/hw/audio/milkymist-ac97.c
index bf6a5a6..56feca2 100644
--- a/hw/audio/milkymist-ac97.c
+++ b/hw/audio/milkymist-ac97.c
@@ -176,7 +176,7 @@ static const MemoryRegionOps ac97_mmio_ops = {
.min_access_size = 4,
.max_access_size = 4,
},
-.endianness = DEVICE_NATIVE_ENDIAN,
+.endianness = DEVICE_BIG_ENDIAN,
};
static void ac97_in_cb(void *opaque, int avail_b)
diff --git a/hw/audio/pl041.c b/hw/audio/pl041.c
index 59c6ce1..b59a4f8 100644
--- a/hw/audio/pl041.c
+++ b/hw/audio/pl041.c
@@ -519,7 +519,7 @@ static void pl041_device_reset(DeviceState *d)
static const MemoryRegionOps pl041_ops = {
.read = pl041_read,
.write = pl041_write,
-.endianness = DEVICE_NATIVE_ENDIAN,
+.endianness = DEVICE_LITTLE_ENDIAN,
};
static void pl041_init(Object *obj)
--
1.8.3.1
?
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [Qemu-devel] [PATCH v7 17/42] hw/char: Declare device little or big endian
For each device declared with DEVICE_NATIVE_ENDIAN, find the set of
targets from the set of target/hw/*/device.o.
If the set of targets are all little or all big endian, re-declare
the device endianness as DEVICE_LITTLE_ENDIAN or DEVICE_BIG_ENDIAN
respectively.
This *naive* deduction may result in genuinely native endian devices
being incorrectly declared as little or big endian, but should not
introduce regressions for current targets.
These devices should be re-declared as DEVICE_NATIVE_ENDIAN if 1) it
has a new target with an opposite endian or 2) someone informed knows
better =)
Signed-off-by: Tony Nguyen
---
hw/char/cadence_uart.c | 2 +-
hw/char/escc.c | 2 +-
hw/char/etraxfs_ser.c| 2 +-
hw/char/grlib_apbuart.c | 2 +-
hw/char/imx_serial.c | 2 +-
hw/char/lm32_uart.c | 2 +-
hw/char/milkymist-uart.c | 2 +-
hw/char/pl011.c | 2 +-
8 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/hw/char/cadence_uart.c b/hw/char/cadence_uart.c
index fa25fe2..6c7b904 100644
--- a/hw/char/cadence_uart.c
+++ b/hw/char/cadence_uart.c
@@ -457,7 +457,7 @@ static uint64_t uart_read(void *opaque, hwaddr offset,
static const MemoryRegionOps uart_ops = {
.read = uart_read,
.write = uart_write,
-.endianness = DEVICE_NATIVE_ENDIAN,
+.endianness = DEVICE_LITTLE_ENDIAN,
};
static void cadence_uart_reset(DeviceState *dev)
diff --git a/hw/char/escc.c b/hw/char/escc.c
index 8ddbb4b..36182d9 100644
--- a/hw/char/escc.c
+++ b/hw/char/escc.c
@@ -574,7 +574,7 @@ static uint64_t escc_mem_read(void *opaque, hwaddr addr,
static const MemoryRegionOps escc_mem_ops = {
.read = escc_mem_read,
.write = escc_mem_write,
-.endianness = DEVICE_NATIVE_ENDIAN,
+.endianness = DEVICE_BIG_ENDIAN,
.valid = {
.min_access_size = 1,
.max_access_size = 1,
diff --git a/hw/char/etraxfs_ser.c b/hw/char/etraxfs_ser.c
index 9745bca..cda687b 100644
--- a/hw/char/etraxfs_ser.c
+++ b/hw/char/etraxfs_ser.c
@@ -155,7 +155,7 @@ ser_write(void *opaque, hwaddr addr,
static const MemoryRegionOps ser_ops = {
.read = ser_read,
.write = ser_write,
-.endianness = DEVICE_NATIVE_ENDIAN,
+.endianness = DEVICE_LITTLE_ENDIAN,
.valid = {
.min_access_size = 4,
.max_access_size = 4
diff --git a/hw/char/grlib_apbuart.c b/hw/char/grlib_apbuart.c
index c2bb3ac..119fc84 100644
--- a/hw/char/grlib_apbuart.c
+++ b/hw/char/grlib_apbuart.c
@@ -237,7 +237,7 @@ static void grlib_apbuart_write(void *opaque, hwaddr addr,
static const MemoryRegionOps grlib_apbuart_ops = {
.write = grlib_apbuart_write,
.read = grlib_apbuart_read,
-.endianness = DEVICE_NATIVE_ENDIAN,
+.endianness = DEVICE_BIG_ENDIAN,
};
static void grlib_apbuart_realize(DeviceState *dev, Error **errp)
diff --git a/hw/char/imx_serial.c b/hw/char/imx_serial.c
index 0655a95..7c66551 100644
--- a/hw/char/imx_serial.c
+++ b/hw/char/imx_serial.c
@@ -332,7 +332,7 @@ static void imx_event(void *opaque, int event)
static const struct MemoryRegionOps imx_serial_ops = {
.read = imx_serial_read,
.write = imx_serial_write,
-.endianness = DEVICE_NATIVE_ENDIAN,
+.endianness = DEVICE_LITTLE_ENDIAN,
};
static void imx_serial_realize(DeviceState *dev, Error **errp)
diff --git a/hw/char/lm32_uart.c b/hw/char/lm32_uart.c
index d047a44..2fe5f60 100644
--- a/hw/char/lm32_uart.c
+++ b/hw/char/lm32_uart.c
@@ -205,7 +205,7 @@ static void uart_write(void *opaque, hwaddr addr,
static const MemoryRegionOps uart_ops = {
.read = uart_read,
.write = uart_write,
-.endianness = DEVICE_NATIVE_ENDIAN,
+.endianness = DEVICE_BIG_ENDIAN,
.valid = {
.min_access_size = 4,
.max_access_size = 4,
diff --git a/hw/char/milkymist-uart.c b/hw/char/milkymist-uart.c
index 8a78fcc..bdb8282 100644
--- a/hw/char/milkymist-uart.c
+++ b/hw/char/milkymist-uart.c
@@ -156,7 +156,7 @@ static const MemoryRegionOps uart_mmio_ops = {
.min_access_size = 4,
.max_access_size = 4,
},
-.endianness = DEVICE_NATIVE_ENDIAN,
+.endianness = DEVICE_BIG_ENDIAN,
};
static void uart_rx(void *opaque, const uint8_t *buf, int size)
diff --git a/hw/char/pl011.c b/hw/char/pl011.c
index c1ae2f3..5fb95d2 100644
--- a/hw/char/pl011.c
+++ b/hw/char/pl011.c
@@ -287,7 +287,7 @@ static void pl011_event(void *opaque, int event)
static const MemoryRegionOps pl011_ops = {
.read = pl011_read,
.write = pl011_write,
-.endianness = DEVICE_NATIVE_ENDIAN,
+.endianness = DEVICE_LITTLE_ENDIAN,
};
static const VMStateDescription vmstate_pl011 = {
--
1.8.3.1
?
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [Qemu-devel] [PATCH v7 16/42] hw/block: Declare device little or big endian
For each device declared with DEVICE_NATIVE_ENDIAN, find the set of
targets from the set of target/hw/*/device.o.
If the set of targets are all little or all big endian, re-declare
the device endianness as DEVICE_LITTLE_ENDIAN or DEVICE_BIG_ENDIAN
respectively.
This *naive* deduction may result in genuinely native endian devices
being incorrectly declared as little or big endian, but should not
introduce regressions for current targets.
These devices should be re-declared as DEVICE_NATIVE_ENDIAN if 1) it
has a new target with an opposite endian or 2) someone informed knows
better =)
Signed-off-by: Tony Nguyen
---
hw/block/onenand.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/block/onenand.c b/hw/block/onenand.c
index b3644f7..66152e7 100644
--- a/hw/block/onenand.c
+++ b/hw/block/onenand.c
@@ -769,7 +769,7 @@ static void onenand_write(void *opaque, hwaddr addr,
static const MemoryRegionOps onenand_ops = {
.read = onenand_read,
.write = onenand_write,
-.endianness = DEVICE_NATIVE_ENDIAN,
+.endianness = DEVICE_LITTLE_ENDIAN,
};
static void onenand_realize(DeviceState *dev, Error **errp)
--
1.8.3.1
?
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [Qemu-devel] [PATCH v7 18/42] hw/display: Declare device little or big endian
For each device declared with DEVICE_NATIVE_ENDIAN, find the set of
targets from the set of target/hw/*/device.o.
If the set of targets are all little or all big endian, re-declare
the device endianness as DEVICE_LITTLE_ENDIAN or DEVICE_BIG_ENDIAN
respectively.
This *naive* deduction may result in genuinely native endian devices
being incorrectly declared as little or big endian, but should not
introduce regressions for current targets.
These devices should be re-declared as DEVICE_NATIVE_ENDIAN if 1) it
has a new target with an opposite endian or 2) someone informed knows
better =)
Signed-off-by: Tony Nguyen
---
hw/display/pl110.c| 2 +-
hw/display/tc6393xb.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/hw/display/pl110.c b/hw/display/pl110.c
index 2bdfc3c..d0c6317 100644
--- a/hw/display/pl110.c
+++ b/hw/display/pl110.c
@@ -471,7 +471,7 @@ static void pl110_write(void *opaque, hwaddr offset,
static const MemoryRegionOps pl110_ops = {
.read = pl110_read,
.write = pl110_write,
-.endianness = DEVICE_NATIVE_ENDIAN,
+.endianness = DEVICE_LITTLE_ENDIAN,
};
static void pl110_mux_ctrl_set(void *opaque, int line, int level)
diff --git a/hw/display/tc6393xb.c b/hw/display/tc6393xb.c
index 0b7c59c..6bc3360 100644
--- a/hw/display/tc6393xb.c
+++ b/hw/display/tc6393xb.c
@@ -547,7 +547,7 @@ TC6393xbState *tc6393xb_init(MemoryRegion *sysmem, uint32_t
base, qemu_irq irq)
static const MemoryRegionOps tc6393xb_ops = {
.read = tc6393xb_readb,
.write = tc6393xb_writeb,
-.endianness = DEVICE_NATIVE_ENDIAN,
+.endianness = DEVICE_LITTLE_ENDIAN,
.impl = {
.min_access_size = 1,
.max_access_size = 1,
--
1.8.3.1
?
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [Qemu-devel] [PATCH v7 19/42] hw/dma: Declare device little or big endian
For each device declared with DEVICE_NATIVE_ENDIAN, find the set of
targets from the set of target/hw/*/device.o.
If the set of targets are all little or all big endian, re-declare
the device endianness as DEVICE_LITTLE_ENDIAN or DEVICE_BIG_ENDIAN
respectively.
This *naive* deduction may result in genuinely native endian devices
being incorrectly declared as little or big endian, but should not
introduce regressions for current targets.
These devices should be re-declared as DEVICE_NATIVE_ENDIAN if 1) it
has a new target with an opposite endian or 2) someone informed knows
better =)
Signed-off-by: Tony Nguyen
---
hw/dma/bcm2835_dma.c | 4 ++--
hw/dma/etraxfs_dma.c | 2 +-
hw/dma/pl080.c | 2 +-
hw/dma/pl330.c | 2 +-
hw/dma/puv3_dma.c| 2 +-
hw/dma/sparc32_dma.c | 2 +-
6 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/hw/dma/bcm2835_dma.c b/hw/dma/bcm2835_dma.c
index a39e8f4..907d25c 100644
--- a/hw/dma/bcm2835_dma.c
+++ b/hw/dma/bcm2835_dma.c
@@ -288,7 +288,7 @@ static void bcm2835_dma15_write(void *opaque, hwaddr
offset, uint64_t value,
static const MemoryRegionOps bcm2835_dma0_ops = {
.read = bcm2835_dma0_read,
.write = bcm2835_dma0_write,
-.endianness = DEVICE_NATIVE_ENDIAN,
+.endianness = DEVICE_LITTLE_ENDIAN,
.valid.min_access_size = 4,
.valid.max_access_size = 4,
};
@@ -296,7 +296,7 @@ static const MemoryRegionOps bcm2835_dma0_ops = {
static const MemoryRegionOps bcm2835_dma15_ops = {
.read = bcm2835_dma15_read,
.write = bcm2835_dma15_write,
-.endianness = DEVICE_NATIVE_ENDIAN,
+.endianness = DEVICE_LITTLE_ENDIAN,
.valid.min_access_size = 4,
.valid.max_access_size = 4,
};
diff --git a/hw/dma/etraxfs_dma.c b/hw/dma/etraxfs_dma.c
index 85783eb..df3ba09 100644
--- a/hw/dma/etraxfs_dma.c
+++ b/hw/dma/etraxfs_dma.c
@@ -697,7 +697,7 @@ dma_write(void *opaque, hwaddr addr,
static const MemoryRegionOps dma_ops = {
.read = dma_read,
.write = dma_write,
- .endianness = DEVICE_NATIVE_ENDIAN,
+ .endianness = DEVICE_LITTLE_ENDIAN,
.valid = {
.min_access_size = 1,
.max_access_size = 4
diff --git a/hw/dma/pl080.c b/hw/dma/pl080.c
index 7e57624..644eadb 100644
--- a/hw/dma/pl080.c
+++ b/hw/dma/pl080.c
@@ -346,7 +346,7 @@ static void pl080_write(void *opaque, hwaddr offset,
static const MemoryRegionOps pl080_ops = {
.read = pl080_read,
.write = pl080_write,
-.endianness = DEVICE_NATIVE_ENDIAN,
+.endianness = DEVICE_LITTLE_ENDIAN,
};
static void pl080_reset(DeviceState *dev)
diff --git a/hw/dma/pl330.c b/hw/dma/pl330.c
index a56a3e7..4c51f2d 100644
--- a/hw/dma/pl330.c
+++ b/hw/dma/pl330.c
@@ -1493,7 +1493,7 @@ static uint64_t pl330_iomem_read(void *opaque, hwaddr
offset,
static const MemoryRegionOps pl330_ops = {
.read = pl330_iomem_read,
.write = pl330_iomem_write,
-.endianness = DEVICE_NATIVE_ENDIAN,
+.endianness = DEVICE_LITTLE_ENDIAN,
.impl = {
.min_access_size = 4,
.max_access_size = 4,
diff --git a/hw/dma/puv3_dma.c b/hw/dma/puv3_dma.c
index 122f87a..7002373 100644
--- a/hw/dma/puv3_dma.c
+++ b/hw/dma/puv3_dma.c
@@ -75,7 +75,7 @@ static const MemoryRegionOps puv3_dma_ops = {
.min_access_size = 4,
.max_access_size = 4,
},
-.endianness = DEVICE_NATIVE_ENDIAN,
+.endianness = DEVICE_LITTLE_ENDIAN,
};
static void puv3_dma_realize(DeviceState *dev, Error **errp)
diff --git a/hw/dma/sparc32_dma.c b/hw/dma/sparc32_dma.c
index 88765d0..6b32372 100644
--- a/hw/dma/sparc32_dma.c
+++ b/hw/dma/sparc32_dma.c
@@ -224,7 +224,7 @@ static void dma_mem_write(void *opaque, hwaddr addr,
static const MemoryRegionOps dma_mem_ops = {
.read = dma_mem_read,
.write = dma_mem_write,
-.endianness = DEVICE_NATIVE_ENDIAN,
+.endianness = DEVICE_BIG_ENDIAN,
.valid = {
.min_access_size = 4,
.max_access_size = 4,
--
1.8.3.1
?
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [Qemu-devel] [PATCH v7 20/42] hw/gpio: Declare device little or big endian
For each device declared with DEVICE_NATIVE_ENDIAN, find the set of
targets from the set of target/hw/*/device.o.
If the set of targets are all little or all big endian, re-declare
the device endianness as DEVICE_LITTLE_ENDIAN or DEVICE_BIG_ENDIAN
respectively.
This *naive* deduction may result in genuinely native endian devices
being incorrectly declared as little or big endian, but should not
introduce regressions for current targets.
These devices should be re-declared as DEVICE_NATIVE_ENDIAN if 1) it
has a new target with an opposite endian or 2) someone informed knows
better =)
Signed-off-by: Tony Nguyen
---
hw/gpio/pl061.c | 2 +-
hw/gpio/zaurus.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/hw/gpio/pl061.c b/hw/gpio/pl061.c
index 02c01fd..da6ff6a 100644
--- a/hw/gpio/pl061.c
+++ b/hw/gpio/pl061.c
@@ -339,7 +339,7 @@ static void pl061_set_irq(void * opaque, int irq, int level)
static const MemoryRegionOps pl061_ops = {
.read = pl061_read,
.write = pl061_write,
-.endianness = DEVICE_NATIVE_ENDIAN,
+.endianness = DEVICE_LITTLE_ENDIAN,
};
static void pl061_luminary_init(Object *obj)
diff --git a/hw/gpio/zaurus.c b/hw/gpio/zaurus.c
index f2f1f67..599d862 100644
--- a/hw/gpio/zaurus.c
+++ b/hw/gpio/zaurus.c
@@ -156,7 +156,7 @@ static void scoop_write(void *opaque, hwaddr addr,
static const MemoryRegionOps scoop_ops = {
.read = scoop_read,
.write = scoop_write,
-.endianness = DEVICE_NATIVE_ENDIAN,
+.endianness = DEVICE_LITTLE_ENDIAN,
};
static void scoop_gpio_set(void *opaque, int line, int level)
--
1.8.3.1
?
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [Qemu-devel] [PATCH v7 21/42] hw/i2c: Declare device little or big endian
For each device declared with DEVICE_NATIVE_ENDIAN, find the set of
targets from the set of target/hw/*/device.o.
If the set of targets are all little or all big endian, re-declare
the device endianness as DEVICE_LITTLE_ENDIAN or DEVICE_BIG_ENDIAN
respectively.
This *naive* deduction may result in genuinely native endian devices
being incorrectly declared as little or big endian, but should not
introduce regressions for current targets.
These devices should be re-declared as DEVICE_NATIVE_ENDIAN if 1) it
has a new target with an opposite endian or 2) someone informed knows
better =)
Signed-off-by: Tony Nguyen
---
hw/i2c/imx_i2c.c | 2 +-
hw/i2c/mpc_i2c.c | 2 +-
hw/i2c/versatile_i2c.c | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/hw/i2c/imx_i2c.c b/hw/i2c/imx_i2c.c
index ce7a94c..de1107b 100644
--- a/hw/i2c/imx_i2c.c
+++ b/hw/i2c/imx_i2c.c
@@ -276,7 +276,7 @@ static const MemoryRegionOps imx_i2c_ops = {
.write = imx_i2c_write,
.valid.min_access_size = 1,
.valid.max_access_size = 2,
-.endianness = DEVICE_NATIVE_ENDIAN,
+.endianness = DEVICE_LITTLE_ENDIAN,
};
static const VMStateDescription imx_i2c_vmstate = {
diff --git a/hw/i2c/mpc_i2c.c b/hw/i2c/mpc_i2c.c
index e9a1127..181228d 100644
--- a/hw/i2c/mpc_i2c.c
+++ b/hw/i2c/mpc_i2c.c
@@ -304,7 +304,7 @@ static const MemoryRegionOps i2c_ops = {
.read = mpc_i2c_read,
.write = mpc_i2c_write,
.valid.max_access_size = 1,
-.endianness = DEVICE_NATIVE_ENDIAN,
+.endianness = DEVICE_BIG_ENDIAN,
};
static const VMStateDescription mpc_i2c_vmstate = {
diff --git a/hw/i2c/versatile_i2c.c b/hw/i2c/versatile_i2c.c
index 1ac2a6f..c92d3b1 100644
--- a/hw/i2c/versatile_i2c.c
+++ b/hw/i2c/versatile_i2c.c
@@ -77,7 +77,7 @@ static void versatile_i2c_write(void *opaque, hwaddr offset,
static const MemoryRegionOps versatile_i2c_ops = {
.read = versatile_i2c_read,
.write = versatile_i2c_write,
-.endianness = DEVICE_NATIVE_ENDIAN,
+.endianness = DEVICE_LITTLE_ENDIAN,
};
static void versatile_i2c_init(Object *obj)
--
1.8.3.1
?
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [Qemu-devel] [PATCH v7 23/42] hw/intc: Declare device little or big endian
For each device declared with DEVICE_NATIVE_ENDIAN, find the set of
targets from the set of target/hw/*/device.o.
If the set of targets are all little or all big endian, re-declare
the device endianness as DEVICE_LITTLE_ENDIAN or DEVICE_BIG_ENDIAN
respectively.
This *naive* deduction may result in genuinely native endian devices
being incorrectly declared as little or big endian, but should not
introduce regressions for current targets.
These devices should be re-declared as DEVICE_NATIVE_ENDIAN if 1) it
has a new target with an opposite endian or 2) someone informed knows
better =)
Signed-off-by: Tony Nguyen
---
hw/intc/arm_gic.c | 12 ++--
hw/intc/arm_gicv3.c | 4 ++--
hw/intc/etraxfs_pic.c | 2 +-
hw/intc/imx_avic.c| 2 +-
hw/intc/imx_gpcv2.c | 2 +-
hw/intc/pl190.c | 2 +-
hw/intc/puv3_intc.c | 2 +-
7 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/hw/intc/arm_gic.c b/hw/intc/arm_gic.c
index 77427a4..283a63a 100644
--- a/hw/intc/arm_gic.c
+++ b/hw/intc/arm_gic.c
@@ -1999,38 +1999,38 @@ static const MemoryRegionOps gic_ops[2] = {
{
.read_with_attrs = gic_dist_read,
.write_with_attrs = gic_dist_write,
-.endianness = DEVICE_NATIVE_ENDIAN,
+.endianness = DEVICE_LITTLE_ENDIAN,
},
{
.read_with_attrs = gic_thiscpu_read,
.write_with_attrs = gic_thiscpu_write,
-.endianness = DEVICE_NATIVE_ENDIAN,
+.endianness = DEVICE_LITTLE_ENDIAN,
}
};
static const MemoryRegionOps gic_cpu_ops = {
.read_with_attrs = gic_do_cpu_read,
.write_with_attrs = gic_do_cpu_write,
-.endianness = DEVICE_NATIVE_ENDIAN,
+.endianness = DEVICE_LITTLE_ENDIAN,
};
static const MemoryRegionOps gic_virt_ops[2] = {
{
.read_with_attrs = gic_thiscpu_hyp_read,
.write_with_attrs = gic_thiscpu_hyp_write,
-.endianness = DEVICE_NATIVE_ENDIAN,
+.endianness = DEVICE_LITTLE_ENDIAN,
},
{
.read_with_attrs = gic_thisvcpu_read,
.write_with_attrs = gic_thisvcpu_write,
-.endianness = DEVICE_NATIVE_ENDIAN,
+.endianness = DEVICE_LITTLE_ENDIAN,
}
};
static const MemoryRegionOps gic_viface_ops = {
.read_with_attrs = gic_do_hyp_read,
.write_with_attrs = gic_do_hyp_write,
-.endianness = DEVICE_NATIVE_ENDIAN,
+.endianness = DEVICE_LITTLE_ENDIAN,
};
static void arm_gic_realize(DeviceState *dev, Error **errp)
diff --git a/hw/intc/arm_gicv3.c b/hw/intc/arm_gicv3.c
index 66eaa97..9b4d5ba 100644
--- a/hw/intc/arm_gicv3.c
+++ b/hw/intc/arm_gicv3.c
@@ -352,12 +352,12 @@ static const MemoryRegionOps gic_ops[] = {
{
.read_with_attrs = gicv3_dist_read,
.write_with_attrs = gicv3_dist_write,
-.endianness = DEVICE_NATIVE_ENDIAN,
+.endianness = DEVICE_LITTLE_ENDIAN,
},
{
.read_with_attrs = gicv3_redist_read,
.write_with_attrs = gicv3_redist_write,
-.endianness = DEVICE_NATIVE_ENDIAN,
+.endianness = DEVICE_LITTLE_ENDIAN,
}
};
diff --git a/hw/intc/etraxfs_pic.c b/hw/intc/etraxfs_pic.c
index 20e1391..d4a27d1 100644
--- a/hw/intc/etraxfs_pic.c
+++ b/hw/intc/etraxfs_pic.c
@@ -111,7 +111,7 @@ static void pic_write(void *opaque, hwaddr addr,
static const MemoryRegionOps pic_ops = {
.read = pic_read,
.write = pic_write,
-.endianness = DEVICE_NATIVE_ENDIAN,
+.endianness = DEVICE_LITTLE_ENDIAN,
.valid = {
.min_access_size = 4,
.max_access_size = 4
diff --git a/hw/intc/imx_avic.c b/hw/intc/imx_avic.c
index 83a4101..4bef842 100644
--- a/hw/intc/imx_avic.c
+++ b/hw/intc/imx_avic.c
@@ -308,7 +308,7 @@ static void imx_avic_write(void *opaque, hwaddr offset,
static const MemoryRegionOps imx_avic_ops = {
.read = imx_avic_read,
.write = imx_avic_write,
-.endianness = DEVICE_NATIVE_ENDIAN,
+.endianness = DEVICE_LITTLE_ENDIAN,
};
static void imx_avic_reset(DeviceState *dev)
diff --git a/hw/intc/imx_gpcv2.c b/hw/intc/imx_gpcv2.c
index a8b..f37e6b5 100644
--- a/hw/intc/imx_gpcv2.c
+++ b/hw/intc/imx_gpcv2.c
@@ -64,7 +64,7 @@ static void imx_gpcv2_write(void *opaque, hwaddr offset,
static const struct MemoryRegionOps imx_gpcv2_ops = {
.read = imx_gpcv2_read,
.write = imx_gpcv2_write,
-.endianness = DEVICE_NATIVE_ENDIAN,
+.endianness = DEVICE_LITTLE_ENDIAN,
.impl = {
/*
* Our device would not work correctly if the guest was doing
diff --git a/hw/intc/pl190.c b/hw/intc/pl190.c
index b4f31ef..e6eab1e 100644
--- a/hw/intc/pl190.c
+++ b/hw/intc/pl190.c
@@ -220,7 +220,7 @@ static void pl190_write(void *opaque, hwaddr offset,
static const MemoryRegionOps pl190_ops = {
.read = pl190_read,
.write = pl190_write,
-.endianness = DEVICE_NATIVE_ENDIAN,
+.endianness = DEVICE_LITTLE_ENDIAN,
};
static void pl190_reset(DeviceState *d)
diff --git a/hw/intc/puv3_intc.c b/hw/intc/puv3_intc.c
index e2f6d98..97999cc 100644
--- a/hw/intc/
[Xen-devel] [Qemu-devel] [PATCH v7 22/42] hw/input: Declare device little or big endian
For each device declared with DEVICE_NATIVE_ENDIAN, find the set of
targets from the set of target/hw/*/device.o.
If the set of targets are all little or all big endian, re-declare
the device endianness as DEVICE_LITTLE_ENDIAN or DEVICE_BIG_ENDIAN
respectively.
This *naive* deduction may result in genuinely native endian devices
being incorrectly declared as little or big endian, but should not
introduce regressions for current targets.
These devices should be re-declared as DEVICE_NATIVE_ENDIAN if 1) it
has a new target with an opposite endian or 2) someone informed knows
better =)
Signed-off-by: Tony Nguyen
---
hw/input/pl050.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/input/pl050.c b/hw/input/pl050.c
index b79bf16..4c0fe0b 100644
--- a/hw/input/pl050.c
+++ b/hw/input/pl050.c
@@ -137,7 +137,7 @@ static void pl050_write(void *opaque, hwaddr offset,
static const MemoryRegionOps pl050_ops = {
.read = pl050_read,
.write = pl050_write,
-.endianness = DEVICE_NATIVE_ENDIAN,
+.endianness = DEVICE_LITTLE_ENDIAN,
};
static void pl050_realize(DeviceState *dev, Error **errp)
--
1.8.3.1
?
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [Qemu-devel] [PATCH v7 24/42] hw/isa: Declare device little or big endian
For each device declared with DEVICE_NATIVE_ENDIAN, find the set of
targets from the set of target/hw/*/device.o.
If the set of targets are all little or all big endian, re-declare
the device endianness as DEVICE_LITTLE_ENDIAN or DEVICE_BIG_ENDIAN
respectively.
This *naive* deduction may result in genuinely native endian devices
being incorrectly declared as little or big endian, but should not
introduce regressions for current targets.
These devices should be re-declared as DEVICE_NATIVE_ENDIAN if 1) it
has a new target with an opposite endian or 2) someone informed knows
better =)
Signed-off-by: Tony Nguyen
---
hw/isa/vt82c686.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/isa/vt82c686.c b/hw/isa/vt82c686.c
index 12c460590..adf65d3 100644
--- a/hw/isa/vt82c686.c
+++ b/hw/isa/vt82c686.c
@@ -108,7 +108,7 @@ static uint64_t superio_ioport_readb(void *opaque, hwaddr
addr, unsigned size)
static const MemoryRegionOps superio_ops = {
.read = superio_ioport_readb,
.write = superio_ioport_writeb,
-.endianness = DEVICE_NATIVE_ENDIAN,
+.endianness = DEVICE_LITTLE_ENDIAN,
.impl = {
.min_access_size = 1,
.max_access_size = 1,
--
1.8.3.1
?
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [Qemu-devel] [PATCH v7 27/42] hw/pci-host: Declare device little or big endian
For each device declared with DEVICE_NATIVE_ENDIAN, find the set of
targets from the set of target/hw/*/device.o.
If the set of targets are all little or all big endian, re-declare
the device endianness as DEVICE_LITTLE_ENDIAN or DEVICE_BIG_ENDIAN
respectively.
This *naive* deduction may result in genuinely native endian devices
being incorrectly declared as little or big endian, but should not
introduce regressions for current targets.
These devices should be re-declared as DEVICE_NATIVE_ENDIAN if 1) it
has a new target with an opposite endian or 2) someone informed knows
better =)
Signed-off-by: Tony Nguyen
---
hw/pci-host/q35.c | 2 +-
hw/pci-host/versatile.c | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/hw/pci-host/q35.c b/hw/pci-host/q35.c
index 0a010be..fd20f72 100644
--- a/hw/pci-host/q35.c
+++ b/hw/pci-host/q35.c
@@ -288,7 +288,7 @@ static void tseg_blackhole_write(void *opaque, hwaddr addr,
uint64_t val,
static const MemoryRegionOps tseg_blackhole_ops = {
.read = tseg_blackhole_read,
.write = tseg_blackhole_write,
-.endianness = DEVICE_NATIVE_ENDIAN,
+.endianness = DEVICE_LITTLE_ENDIAN,
.valid.min_access_size = 1,
.valid.max_access_size = 4,
.impl.min_access_size = 4,
diff --git a/hw/pci-host/versatile.c b/hw/pci-host/versatile.c
index 791b321..e7017f3 100644
--- a/hw/pci-host/versatile.c
+++ b/hw/pci-host/versatile.c
@@ -240,7 +240,7 @@ static uint64_t pci_vpb_reg_read(void *opaque, hwaddr addr,
static const MemoryRegionOps pci_vpb_reg_ops = {
.read = pci_vpb_reg_read,
.write = pci_vpb_reg_write,
-.endianness = DEVICE_NATIVE_ENDIAN,
+.endianness = DEVICE_LITTLE_ENDIAN,
.valid = {
.min_access_size = 4,
.max_access_size = 4,
@@ -306,7 +306,7 @@ static uint64_t pci_vpb_config_read(void *opaque, hwaddr
addr,
static const MemoryRegionOps pci_vpb_config_ops = {
.read = pci_vpb_config_read,
.write = pci_vpb_config_write,
-.endianness = DEVICE_NATIVE_ENDIAN,
+.endianness = DEVICE_LITTLE_ENDIAN,
};
static int pci_vpb_map_irq(PCIDevice *d, int irq_num)
--
1.8.3.1
?
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [Qemu-devel] [PATCH v7 25/42] hw/misc: Declare device little or big endian
For each device declared with DEVICE_NATIVE_ENDIAN, find the set of
targets from the set of target/hw/*/device.o.
If the set of targets are all little or all big endian, re-declare
the device endianness as DEVICE_LITTLE_ENDIAN or DEVICE_BIG_ENDIAN
respectively.
This *naive* deduction may result in genuinely native endian devices
being incorrectly declared as little or big endian, but should not
introduce regressions for current targets.
These devices should be re-declared as DEVICE_NATIVE_ENDIAN if 1) it
has a new target with an opposite endian or 2) someone informed knows
better =)
Signed-off-by: Tony Nguyen
---
hw/misc/a9scu.c| 2 +-
hw/misc/applesmc.c | 6 +++---
hw/misc/arm11scu.c | 2 +-
hw/misc/arm_l2x0.c | 2 +-
hw/misc/puv3_pm.c | 2 +-
5 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/hw/misc/a9scu.c b/hw/misc/a9scu.c
index 4307f00..3de8cd3 100644
--- a/hw/misc/a9scu.c
+++ b/hw/misc/a9scu.c
@@ -94,7 +94,7 @@ static void a9_scu_write(void *opaque, hwaddr offset,
static const MemoryRegionOps a9_scu_ops = {
.read = a9_scu_read,
.write = a9_scu_write,
-.endianness = DEVICE_NATIVE_ENDIAN,
+.endianness = DEVICE_LITTLE_ENDIAN,
};
static void a9_scu_reset(DeviceState *dev)
diff --git a/hw/misc/applesmc.c b/hw/misc/applesmc.c
index 2d7eb3c..6c91f29 100644
--- a/hw/misc/applesmc.c
+++ b/hw/misc/applesmc.c
@@ -285,7 +285,7 @@ static void qdev_applesmc_isa_reset(DeviceState *dev)
static const MemoryRegionOps applesmc_data_io_ops = {
.write = applesmc_io_data_write,
.read = applesmc_io_data_read,
-.endianness = DEVICE_NATIVE_ENDIAN,
+.endianness = DEVICE_LITTLE_ENDIAN,
.impl = {
.min_access_size = 1,
.max_access_size = 1,
@@ -295,7 +295,7 @@ static const MemoryRegionOps applesmc_data_io_ops = {
static const MemoryRegionOps applesmc_cmd_io_ops = {
.write = applesmc_io_cmd_write,
.read = applesmc_io_cmd_read,
-.endianness = DEVICE_NATIVE_ENDIAN,
+.endianness = DEVICE_LITTLE_ENDIAN,
.impl = {
.min_access_size = 1,
.max_access_size = 1,
@@ -305,7 +305,7 @@ static const MemoryRegionOps applesmc_cmd_io_ops = {
static const MemoryRegionOps applesmc_err_io_ops = {
.write = applesmc_io_err_write,
.read = applesmc_io_err_read,
-.endianness = DEVICE_NATIVE_ENDIAN,
+.endianness = DEVICE_LITTLE_ENDIAN,
.impl = {
.min_access_size = 1,
.max_access_size = 1,
diff --git a/hw/misc/arm11scu.c b/hw/misc/arm11scu.c
index 84275df..59fd7c0 100644
--- a/hw/misc/arm11scu.c
+++ b/hw/misc/arm11scu.c
@@ -57,7 +57,7 @@ static void mpcore_scu_write(void *opaque, hwaddr offset,
static const MemoryRegionOps mpcore_scu_ops = {
.read = mpcore_scu_read,
.write = mpcore_scu_write,
-.endianness = DEVICE_NATIVE_ENDIAN,
+.endianness = DEVICE_LITTLE_ENDIAN,
};
static void arm11_scu_realize(DeviceState *dev, Error **errp)
diff --git a/hw/misc/arm_l2x0.c b/hw/misc/arm_l2x0.c
index b88f40a..72ecf46 100644
--- a/hw/misc/arm_l2x0.c
+++ b/hw/misc/arm_l2x0.c
@@ -157,7 +157,7 @@ static void l2x0_priv_reset(DeviceState *dev)
static const MemoryRegionOps l2x0_mem_ops = {
.read = l2x0_priv_read,
.write = l2x0_priv_write,
-.endianness = DEVICE_NATIVE_ENDIAN,
+.endianness = DEVICE_LITTLE_ENDIAN,
};
static void l2x0_priv_init(Object *obj)
diff --git a/hw/misc/puv3_pm.c b/hw/misc/puv3_pm.c
index b538b4a..cd82b69 100644
--- a/hw/misc/puv3_pm.c
+++ b/hw/misc/puv3_pm.c
@@ -118,7 +118,7 @@ static const MemoryRegionOps puv3_pm_ops = {
.min_access_size = 4,
.max_access_size = 4,
},
-.endianness = DEVICE_NATIVE_ENDIAN,
+.endianness = DEVICE_LITTLE_ENDIAN,
};
static void puv3_pm_realize(DeviceState *dev, Error **errp)
--
1.8.3.1
?
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [Qemu-devel] [PATCH v7 28/42] hw/sd: Declare device little or big endian
For each device declared with DEVICE_NATIVE_ENDIAN, find the set of
targets from the set of target/hw/*/device.o.
If the set of targets are all little or all big endian, re-declare
the device endianness as DEVICE_LITTLE_ENDIAN or DEVICE_BIG_ENDIAN
respectively.
This *naive* deduction may result in genuinely native endian devices
being incorrectly declared as little or big endian, but should not
introduce regressions for current targets.
These devices should be re-declared as DEVICE_NATIVE_ENDIAN if 1) it
has a new target with an opposite endian or 2) someone informed knows
better =)
Signed-off-by: Tony Nguyen
---
hw/sd/pl181.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/sd/pl181.c b/hw/sd/pl181.c
index 81b406d..f2027aa 100644
--- a/hw/sd/pl181.c
+++ b/hw/sd/pl181.c
@@ -449,7 +449,7 @@ static void pl181_write(void *opaque, hwaddr offset,
static const MemoryRegionOps pl181_ops = {
.read = pl181_read,
.write = pl181_write,
-.endianness = DEVICE_NATIVE_ENDIAN,
+.endianness = DEVICE_LITTLE_ENDIAN,
};
static void pl181_reset(DeviceState *d)
--
1.8.3.1
?
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [Qemu-devel] [PATCH v7 26/42] hw/net: Declare device little or big endian
For each device declared with DEVICE_NATIVE_ENDIAN, find the set of
targets from the set of target/hw/*/device.o.
If the set of targets are all little or all big endian, re-declare
the device endianness as DEVICE_LITTLE_ENDIAN or DEVICE_BIG_ENDIAN
respectively.
This *naive* deduction may result in genuinely native endian devices
being incorrectly declared as little or big endian, but should not
introduce regressions for current targets.
These devices should be re-declared as DEVICE_NATIVE_ENDIAN if 1) it
has a new target with an opposite endian or 2) someone informed knows
better =)
Signed-off-by: Tony Nguyen
---
hw/net/allwinner_emac.c | 2 +-
hw/net/imx_fec.c| 2 +-
hw/net/lan9118.c| 4 ++--
hw/net/lance.c | 2 +-
hw/net/smc91c111.c | 2 +-
hw/net/stellaris_enet.c | 2 +-
6 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/hw/net/allwinner_emac.c b/hw/net/allwinner_emac.c
index eecda52..97e22e7 100644
--- a/hw/net/allwinner_emac.c
+++ b/hw/net/allwinner_emac.c
@@ -418,7 +418,7 @@ static void aw_emac_set_link(NetClientState *nc)
static const MemoryRegionOps aw_emac_mem_ops = {
.read = aw_emac_read,
.write = aw_emac_write,
-.endianness = DEVICE_NATIVE_ENDIAN,
+.endianness = DEVICE_LITTLE_ENDIAN,
.valid = {
.min_access_size = 4,
.max_access_size = 4,
diff --git a/hw/net/imx_fec.c b/hw/net/imx_fec.c
index 404154e..76d42c8 100644
--- a/hw/net/imx_fec.c
+++ b/hw/net/imx_fec.c
@@ -1278,7 +1278,7 @@ static const MemoryRegionOps imx_eth_ops = {
.write = imx_eth_write,
.valid.min_access_size = 4,
.valid.max_access_size = 4,
-.endianness= DEVICE_NATIVE_ENDIAN,
+.endianness= DEVICE_LITTLE_ENDIAN,
};
static void imx_eth_cleanup(NetClientState *nc)
diff --git a/hw/net/lan9118.c b/hw/net/lan9118.c
index f6120be..bb1bbb3 100644
--- a/hw/net/lan9118.c
+++ b/hw/net/lan9118.c
@@ -1304,13 +1304,13 @@ static uint64_t lan9118_16bit_mode_read(void *opaque,
hwaddr offset,
static const MemoryRegionOps lan9118_mem_ops = {
.read = lan9118_readl,
.write = lan9118_writel,
-.endianness = DEVICE_NATIVE_ENDIAN,
+.endianness = DEVICE_LITTLE_ENDIAN,
};
static const MemoryRegionOps lan9118_16bit_mem_ops = {
.read = lan9118_16bit_mode_read,
.write = lan9118_16bit_mode_write,
-.endianness = DEVICE_NATIVE_ENDIAN,
+.endianness = DEVICE_LITTLE_ENDIAN,
};
static NetClientInfo net_lan9118_info = {
diff --git a/hw/net/lance.c b/hw/net/lance.c
index 2978c01..d95f170 100644
--- a/hw/net/lance.c
+++ b/hw/net/lance.c
@@ -74,7 +74,7 @@ static uint64_t lance_mem_read(void *opaque, hwaddr addr,
static const MemoryRegionOps lance_mem_ops = {
.read = lance_mem_read,
.write = lance_mem_write,
-.endianness = DEVICE_NATIVE_ENDIAN,
+.endianness = DEVICE_BIG_ENDIAN,
.valid = {
.min_access_size = 2,
.max_access_size = 2,
diff --git a/hw/net/smc91c111.c b/hw/net/smc91c111.c
index 4a612ee..49e4bf5 100644
--- a/hw/net/smc91c111.c
+++ b/hw/net/smc91c111.c
@@ -757,7 +757,7 @@ static const MemoryRegionOps smc91c111_mem_ops = {
.write = smc91c111_writefn,
.valid.min_access_size = 1,
.valid.max_access_size = 4,
-.endianness = DEVICE_NATIVE_ENDIAN,
+.endianness = DEVICE_LITTLE_ENDIAN,
};
static NetClientInfo net_smc91c111_info = {
diff --git a/hw/net/stellaris_enet.c b/hw/net/stellaris_enet.c
index 2f645bf..15ec227 100644
--- a/hw/net/stellaris_enet.c
+++ b/hw/net/stellaris_enet.c
@@ -456,7 +456,7 @@ static void stellaris_enet_write(void *opaque, hwaddr
offset,
static const MemoryRegionOps stellaris_enet_ops = {
.read = stellaris_enet_read,
.write = stellaris_enet_write,
-.endianness = DEVICE_NATIVE_ENDIAN,
+.endianness = DEVICE_LITTLE_ENDIAN,
};
static void stellaris_enet_reset(DeviceState *dev)
--
1.8.3.1
?
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [Qemu-devel] [PATCH v7 29/42] hw/ssi: Declare device little or big endian
For each device declared with DEVICE_NATIVE_ENDIAN, find the set of
targets from the set of target/hw/*/device.o.
If the set of targets are all little or all big endian, re-declare
the device endianness as DEVICE_LITTLE_ENDIAN or DEVICE_BIG_ENDIAN
respectively.
This *naive* deduction may result in genuinely native endian devices
being incorrectly declared as little or big endian, but should not
introduce regressions for current targets.
These devices should be re-declared as DEVICE_NATIVE_ENDIAN if 1) it
has a new target with an opposite endian or 2) someone informed knows
better =)
Signed-off-by: Tony Nguyen
---
hw/ssi/mss-spi.c | 2 +-
hw/ssi/pl022.c | 2 +-
hw/ssi/stm32f2xx_spi.c | 2 +-
hw/ssi/xilinx_spips.c | 2 +-
4 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/hw/ssi/mss-spi.c b/hw/ssi/mss-spi.c
index 4c9da5d..71fd138 100644
--- a/hw/ssi/mss-spi.c
+++ b/hw/ssi/mss-spi.c
@@ -359,7 +359,7 @@ static void spi_write(void *opaque, hwaddr addr,
static const MemoryRegionOps spi_ops = {
.read = spi_read,
.write = spi_write,
-.endianness = DEVICE_NATIVE_ENDIAN,
+.endianness = DEVICE_LITTLE_ENDIAN,
.valid = {
.min_access_size = 1,
.max_access_size = 4
diff --git a/hw/ssi/pl022.c b/hw/ssi/pl022.c
index fec73ca..10d1995 100644
--- a/hw/ssi/pl022.c
+++ b/hw/ssi/pl022.c
@@ -226,7 +226,7 @@ static void pl022_reset(DeviceState *dev)
static const MemoryRegionOps pl022_ops = {
.read = pl022_read,
.write = pl022_write,
-.endianness = DEVICE_NATIVE_ENDIAN,
+.endianness = DEVICE_LITTLE_ENDIAN,
};
static int pl022_post_load(void *opaque, int version_id)
diff --git a/hw/ssi/stm32f2xx_spi.c b/hw/ssi/stm32f2xx_spi.c
index 4249101..e1e5ab5 100644
--- a/hw/ssi/stm32f2xx_spi.c
+++ b/hw/ssi/stm32f2xx_spi.c
@@ -166,7 +166,7 @@ static void stm32f2xx_spi_write(void *opaque, hwaddr addr,
static const MemoryRegionOps stm32f2xx_spi_ops = {
.read = stm32f2xx_spi_read,
.write = stm32f2xx_spi_write,
-.endianness = DEVICE_NATIVE_ENDIAN,
+.endianness = DEVICE_LITTLE_ENDIAN,
};
static const VMStateDescription vmstate_stm32f2xx_spi = {
diff --git a/hw/ssi/xilinx_spips.c b/hw/ssi/xilinx_spips.c
index b29e0a4..8cadc4e 100644
--- a/hw/ssi/xilinx_spips.c
+++ b/hw/ssi/xilinx_spips.c
@@ -1238,7 +1238,7 @@ static MemTxResult lqspi_write(void *opaque, hwaddr
offset, uint64_t value,
static const MemoryRegionOps lqspi_ops = {
.read_with_attrs = lqspi_read,
.write_with_attrs = lqspi_write,
-.endianness = DEVICE_NATIVE_ENDIAN,
+.endianness = DEVICE_LITTLE_ENDIAN,
.impl = {
.min_access_size = 4,
.max_access_size = 4,
--
1.8.3.1
?
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [Qemu-devel] [PATCH v7 30/42] hw/timer: Declare device little or big endian
For each device declared with DEVICE_NATIVE_ENDIAN, find the set of
targets from the set of target/hw/*/device.o.
If the set of targets are all little or all big endian, re-declare
the device endianness as DEVICE_LITTLE_ENDIAN or DEVICE_BIG_ENDIAN
respectively.
This *naive* deduction may result in genuinely native endian devices
being incorrectly declared as little or big endian, but should not
introduce regressions for current targets.
These devices should be re-declared as DEVICE_NATIVE_ENDIAN if 1) it
has a new target with an opposite endian or 2) someone informed knows
better =)
Signed-off-by: Tony Nguyen
---
hw/timer/a9gtimer.c | 4 ++--
hw/timer/arm_mptimer.c | 4 ++--
hw/timer/arm_timer.c| 4 ++--
hw/timer/armv7m_systick.c | 2 +-
hw/timer/aspeed_rtc.c | 2 +-
hw/timer/cadence_ttc.c | 2 +-
hw/timer/grlib_gptimer.c| 2 +-
hw/timer/hpet.c | 2 +-
hw/timer/imx_epit.c | 2 +-
hw/timer/imx_gpt.c | 2 +-
hw/timer/lm32_timer.c | 2 +-
hw/timer/milkymist-sysctl.c | 2 +-
hw/timer/mss-timer.c| 2 +-
hw/timer/pl031.c| 2 +-
hw/timer/stm32f2xx_timer.c | 2 +-
hw/timer/sun4v-rtc.c| 2 +-
16 files changed, 19 insertions(+), 19 deletions(-)
diff --git a/hw/timer/a9gtimer.c b/hw/timer/a9gtimer.c
index 09e2a7b..8bb5f6e 100644
--- a/hw/timer/a9gtimer.c
+++ b/hw/timer/a9gtimer.c
@@ -254,7 +254,7 @@ static const MemoryRegionOps a9_gtimer_this_ops = {
.min_access_size = 4,
.max_access_size = 4,
},
-.endianness = DEVICE_NATIVE_ENDIAN,
+.endianness = DEVICE_LITTLE_ENDIAN,
};
static const MemoryRegionOps a9_gtimer_ops = {
@@ -264,7 +264,7 @@ static const MemoryRegionOps a9_gtimer_ops = {
.min_access_size = 4,
.max_access_size = 4,
},
-.endianness = DEVICE_NATIVE_ENDIAN,
+.endianness = DEVICE_LITTLE_ENDIAN,
};
static void a9_gtimer_reset(DeviceState *dev)
diff --git a/hw/timer/arm_mptimer.c b/hw/timer/arm_mptimer.c
index 93044aa..9397218 100644
--- a/hw/timer/arm_mptimer.c
+++ b/hw/timer/arm_mptimer.c
@@ -190,7 +190,7 @@ static const MemoryRegionOps arm_thistimer_ops = {
.min_access_size = 4,
.max_access_size = 4,
},
-.endianness = DEVICE_NATIVE_ENDIAN,
+.endianness = DEVICE_LITTLE_ENDIAN,
};
static const MemoryRegionOps timerblock_ops = {
@@ -200,7 +200,7 @@ static const MemoryRegionOps timerblock_ops = {
.min_access_size = 4,
.max_access_size = 4,
},
-.endianness = DEVICE_NATIVE_ENDIAN,
+.endianness = DEVICE_LITTLE_ENDIAN,
};
static void timerblock_reset(TimerBlock *tb)
diff --git a/hw/timer/arm_timer.c b/hw/timer/arm_timer.c
index f0a7534..22ce3ff 100644
--- a/hw/timer/arm_timer.c
+++ b/hw/timer/arm_timer.c
@@ -265,7 +265,7 @@ static void sp804_write(void *opaque, hwaddr offset,
static const MemoryRegionOps sp804_ops = {
.read = sp804_read,
.write = sp804_write,
-.endianness = DEVICE_NATIVE_ENDIAN,
+.endianness = DEVICE_LITTLE_ENDIAN,
};
static const VMStateDescription vmstate_sp804 = {
@@ -346,7 +346,7 @@ static void icp_pit_write(void *opaque, hwaddr offset,
static const MemoryRegionOps icp_pit_ops = {
.read = icp_pit_read,
.write = icp_pit_write,
-.endianness = DEVICE_NATIVE_ENDIAN,
+.endianness = DEVICE_LITTLE_ENDIAN,
};
static void icp_pit_init(Object *obj)
diff --git a/hw/timer/armv7m_systick.c b/hw/timer/armv7m_systick.c
index 9464074..3c34fd0 100644
--- a/hw/timer/armv7m_systick.c
+++ b/hw/timer/armv7m_systick.c
@@ -191,7 +191,7 @@ static MemTxResult systick_write(void *opaque, hwaddr addr,
static const MemoryRegionOps systick_ops = {
.read_with_attrs = systick_read,
.write_with_attrs = systick_write,
-.endianness = DEVICE_NATIVE_ENDIAN,
+.endianness = DEVICE_LITTLE_ENDIAN,
.valid.min_access_size = 4,
.valid.max_access_size = 4,
};
diff --git a/hw/timer/aspeed_rtc.c b/hw/timer/aspeed_rtc.c
index 19f061c..c528e47 100644
--- a/hw/timer/aspeed_rtc.c
+++ b/hw/timer/aspeed_rtc.c
@@ -130,7 +130,7 @@ static void aspeed_rtc_reset(DeviceState *d)
static const MemoryRegionOps aspeed_rtc_ops = {
.read = aspeed_rtc_read,
.write = aspeed_rtc_write,
-.endianness = DEVICE_NATIVE_ENDIAN,
+.endianness = DEVICE_LITTLE_ENDIAN,
};
static const VMStateDescription vmstate_aspeed_rtc = {
diff --git a/hw/timer/cadence_ttc.c b/hw/timer/cadence_ttc.c
index 115d935..d422efe 100644
--- a/hw/timer/cadence_ttc.c
+++ b/hw/timer/cadence_ttc.c
@@ -389,7 +389,7 @@ static void cadence_ttc_write(void *opaque, hwaddr offset,
static const MemoryRegionOps cadence_ttc_ops = {
.read = cadence_ttc_read,
.write = cadence_ttc_write,
-.endianness = DEVICE_NATIVE_ENDIAN,
+.endianness = DEVICE_LITTLE_ENDIAN,
};
static void cadence_timer_reset(CadenceTimerState *s)
diff --git a/hw/timer/grlib_gptimer.c b/hw/timer/grlib_gptimer.c
index e45a490..dc3b028 100644
--- a/hw/timer/grlib_gptimer.c
+++ b/hw/time
[Xen-devel] [Qemu-devel] [PATCH v7 32/42] exec: Map device_endian onto MemOp
Preparation to replace device_endian with MemOp.
Mapping device_endian onto MemOp limits behaviour changes to this
relatively smaller patch.
The next patch will replace all device_endian usages with the
equivalent MemOp. That patch will be large but have no behaviour
changes.
A subsequent patch will then delete unused device_endian.
Signed-off-by: Tony Nguyen
Reviewed-by: Richard Henderson
---
hw/char/serial.c | 18 ++
include/exec/cpu-common.h | 10 +++---
2 files changed, 13 insertions(+), 15 deletions(-)
diff --git a/hw/char/serial.c b/hw/char/serial.c
index 7c42a2a..521c76b 100644
--- a/hw/char/serial.c
+++ b/hw/char/serial.c
@@ -1012,22 +1012,15 @@ static void serial_mm_write(void *opaque, hwaddr addr,
serial_ioport_write(s, addr >> s->it_shift, value, 1);
}
-static const MemoryRegionOps serial_mm_ops[3] = {
-[DEVICE_NATIVE_ENDIAN] = {
-.read = serial_mm_read,
-.write = serial_mm_write,
-.endianness = DEVICE_NATIVE_ENDIAN,
-.valid.max_access_size = 8,
-.impl.max_access_size = 8,
-},
-[DEVICE_LITTLE_ENDIAN] = {
+static const MemoryRegionOps serial_mm_ops[2] = {
+[0] = {
.read = serial_mm_read,
.write = serial_mm_write,
.endianness = DEVICE_LITTLE_ENDIAN,
.valid.max_access_size = 8,
.impl.max_access_size = 8,
},
-[DEVICE_BIG_ENDIAN] = {
+[1] = {
.read = serial_mm_read,
.write = serial_mm_write,
.endianness = DEVICE_BIG_ENDIAN,
@@ -1053,8 +1046,9 @@ SerialState *serial_mm_init(MemoryRegion *address_space,
serial_realize_core(s, &error_fatal);
vmstate_register(NULL, base, &vmstate_serial, s);
-memory_region_init_io(&s->io, NULL, &serial_mm_ops[end], s,
- "serial", 8 << it_shift);
+memory_region_init_io(&s->io, NULL,
+ &serial_mm_ops[end == DEVICE_BIG_ENDIAN],
+ s, "serial", 8 << it_shift);
memory_region_add_subregion(address_space, base, &s->io);
return s;
}
diff --git a/include/exec/cpu-common.h b/include/exec/cpu-common.h
index f7dbe75..c388453 100644
--- a/include/exec/cpu-common.h
+++ b/include/exec/cpu-common.h
@@ -16,10 +16,14 @@ void tcg_flush_softmmu_tlb(CPUState *cs);
#if !defined(CONFIG_USER_ONLY)
+#include "exec/memop.h"
+
enum device_endian {
-DEVICE_NATIVE_ENDIAN,
-DEVICE_BIG_ENDIAN,
-DEVICE_LITTLE_ENDIAN,
+#ifdef NEED_CPU_H
+DEVICE_NATIVE_ENDIAN = MO_TE,
+#endif
+DEVICE_BIG_ENDIAN = MO_BE,
+DEVICE_LITTLE_ENDIAN = MO_LE,
};
#if defined(HOST_WORDS_BIGENDIAN)
--
1.8.3.1
?
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [Qemu-devel] [PATCH v7 31/42] build: Correct non-common common-obj-* to obj-*
Preparation for replacing device_endian with MemOp. Device realizing code with MemorRegionOps endianness as DEVICE_NATIVE_ENDIAN is not common code. Corrected devices were identified by making the declaration of DEVICE_NATIVE_ENDIAN conditional upon NEED_CPU_H and then listing what failed to compile. Signed-off-by: Tony Nguyen --- hw/audio/Makefile.objs| 3 ++- hw/block/Makefile.objs| 6 +++--- hw/char/Makefile.objs | 4 ++-- hw/core/Makefile.objs | 2 +- hw/display/Makefile.objs | 6 +++--- hw/dma/Makefile.objs | 6 +++--- hw/gpio/Makefile.objs | 2 +- hw/i2c/Makefile.objs | 2 +- hw/input/Makefile.objs| 2 +- hw/intc/Makefile.objs | 6 +++--- hw/ipack/Makefile.objs| 2 +- hw/misc/Makefile.objs | 10 +- hw/net/Makefile.objs | 2 +- hw/pci-host/Makefile.objs | 2 +- hw/scsi/Makefile.objs | 2 +- hw/ssi/Makefile.objs | 2 +- hw/timer/Makefile.objs| 6 +++--- hw/virtio/Makefile.objs | 2 +- 18 files changed, 34 insertions(+), 33 deletions(-) diff --git a/hw/audio/Makefile.objs b/hw/audio/Makefile.objs index 63db383..13133b4 100644 --- a/hw/audio/Makefile.objs +++ b/hw/audio/Makefile.objs @@ -5,7 +5,8 @@ common-obj-$(CONFIG_AC97) += ac97.o common-obj-$(CONFIG_ADLIB) += fmopl.o adlib.o common-obj-$(CONFIG_GUS) += gus.o gusemu_hal.o gusemu_mixer.o common-obj-$(CONFIG_CS4231A) += cs4231a.o -common-obj-$(CONFIG_HDA) += intel-hda.o hda-codec.o +common-obj-$(CONFIG_HDA) += hda-codec.o +obj-$(CONFIG_HDA) += intel-hda.o common-obj-$(CONFIG_PCSPK) += pcspk.o common-obj-$(CONFIG_WM8750) += wm8750.o diff --git a/hw/block/Makefile.objs b/hw/block/Makefile.objs index f5f643f..04ed4d7 100644 --- a/hw/block/Makefile.objs +++ b/hw/block/Makefile.objs @@ -1,9 +1,9 @@ common-obj-y += block.o cdrom.o hd-geometry.o -common-obj-$(CONFIG_FDC) += fdc.o +obj-$(CONFIG_FDC) += fdc.o common-obj-$(CONFIG_SSI_M25P80) += m25p80.o common-obj-$(CONFIG_NAND) += nand.o -common-obj-$(CONFIG_PFLASH_CFI01) += pflash_cfi01.o -common-obj-$(CONFIG_PFLASH_CFI02) += pflash_cfi02.o +obj-$(CONFIG_PFLASH_CFI01) += pflash_cfi01.o +obj-$(CONFIG_PFLASH_CFI02) += pflash_cfi02.o common-obj-$(CONFIG_XEN) += xen-block.o common-obj-$(CONFIG_ECC) += ecc.o common-obj-$(CONFIG_ONENAND) += onenand.o diff --git a/hw/char/Makefile.objs b/hw/char/Makefile.objs index 02d8a66..215c02b 100644 --- a/hw/char/Makefile.objs +++ b/hw/char/Makefile.objs @@ -1,7 +1,6 @@ common-obj-$(CONFIG_IPACK) += ipoctal232.o common-obj-$(CONFIG_ESCC) += escc.o common-obj-$(CONFIG_NRF51_SOC) += nrf51_uart.o -common-obj-$(CONFIG_PARALLEL) += parallel.o common-obj-$(CONFIG_ISA_BUS) += parallel-isa.o common-obj-$(CONFIG_PL011) += pl011.o common-obj-$(CONFIG_SERIAL) += serial.o @@ -9,7 +8,6 @@ common-obj-$(CONFIG_SERIAL_ISA) += serial-isa.o common-obj-$(CONFIG_SERIAL_PCI) += serial-pci.o common-obj-$(CONFIG_SERIAL_PCI_MULTI) += serial-pci-multi.o common-obj-$(CONFIG_VIRTIO_SERIAL) += virtio-console.o -common-obj-$(CONFIG_XILINX) += xilinx_uartlite.o common-obj-$(CONFIG_XEN) += xen_console.o common-obj-$(CONFIG_CADENCE) += cadence_uart.o @@ -21,6 +19,8 @@ obj-$(CONFIG_PSERIES) += spapr_vty.o obj-$(CONFIG_DIGIC) += digic-uart.o obj-$(CONFIG_STM32F2XX_USART) += stm32f2xx_usart.o obj-$(CONFIG_RASPI) += bcm2835_aux.o +obj-$(CONFIG_PARALLEL) += parallel.o +obj-$(CONFIG_XILINX) += xilinx_uartlite.o common-obj-$(CONFIG_CMSDK_APB_UART) += cmsdk-apb-uart.o common-obj-$(CONFIG_ETRAXFS) += etraxfs_ser.o diff --git a/hw/core/Makefile.objs b/hw/core/Makefile.objs index f8481d9..1b336c6 100644 --- a/hw/core/Makefile.objs +++ b/hw/core/Makefile.objs @@ -9,7 +9,7 @@ common-obj-y += hotplug.o common-obj-$(CONFIG_SOFTMMU) += nmi.o common-obj-$(CONFIG_SOFTMMU) += vm-change-state-handler.o -common-obj-$(CONFIG_EMPTY_SLOT) += empty_slot.o +obj-$(CONFIG_EMPTY_SLOT) += empty_slot.o common-obj-$(CONFIG_XILINX_AXI) += stream.o common-obj-$(CONFIG_PTIMER) += ptimer.o common-obj-$(CONFIG_SOFTMMU) += sysbus.o diff --git a/hw/display/Makefile.objs b/hw/display/Makefile.objs index a64998f..facc1d4 100644 --- a/hw/display/Makefile.objs +++ b/hw/display/Makefile.objs @@ -8,7 +8,7 @@ common-obj-$(CONFIG_ADS7846) += ads7846.o common-obj-$(CONFIG_VGA_CIRRUS) += cirrus_vga.o common-obj-$(call land,$(CONFIG_VGA_CIRRUS),$(CONFIG_VGA_ISA))+=cirrus_vga_isa.o common-obj-$(CONFIG_G364FB) += g364fb.o -common-obj-$(CONFIG_JAZZ_LED) += jazz_led.o +obj-$(CONFIG_JAZZ_LED) += jazz_led.o common-obj-$(CONFIG_PL110) += pl110.o common-obj-$(CONFIG_SII9022) += sii9022.o common-obj-$(CONFIG_SSD0303) += ssd0303.o @@ -17,12 +17,12 @@ common-obj-$(CONFIG_XEN) += xenfb.o common-obj-$(CONFIG_VGA_PCI) += vga-pci.o common-obj-$(CONFIG_VGA_ISA) += vga-isa.o -common-obj-$(CONFIG_VGA_ISA_MM) += vga-isa-mm.o +obj-$(CONFIG_VGA_ISA_MM) += vga-isa-mm.o common-obj-$(CONFIG_VMWARE_VGA) += vmware_vga.o common-obj-$(CONFIG_BOCHS_DISPLAY) += bochs-display.o common-obj-$(CONFIG_BLIZZARD) += blizzard.o -common-obj-$(CONFIG_E
[Xen-devel] [Qemu-devel] [PATCH v7 34/42] exec: Delete device_endian
device_endian has been made redundant by MemOp.
Signed-off-by: Tony Nguyen
Reviewed-by: Richard Henderson
---
include/exec/cpu-common.h | 8
1 file changed, 8 deletions(-)
diff --git a/include/exec/cpu-common.h b/include/exec/cpu-common.h
index 01a29ba..7eeb78c 100644
--- a/include/exec/cpu-common.h
+++ b/include/exec/cpu-common.h
@@ -18,14 +18,6 @@ void tcg_flush_softmmu_tlb(CPUState *cs);
#include "exec/memop.h"
-enum device_endian {
-#ifdef NEED_CPU_H
-DEVICE_NATIVE_ENDIAN = MO_TE,
-#endif
-DEVICE_BIG_ENDIAN = MO_BE,
-DEVICE_LITTLE_ENDIAN = MO_LE,
-};
-
#if defined(HOST_WORDS_BIGENDIAN)
#define DEVICE_HOST_ENDIAN MO_BE
#else
--
1.8.3.1
?
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [Qemu-devel] [PATCH v7 36/42] memory: Access MemoryRegion with endianness
Preparation for collapsing the two byte swaps adjust_endianness and
handle_bswap into the former.
Call memory_region_dispatch_{read|write} with endianness encoded into
the "MemOp op" operand.
This patch does not change any behaviour as
memory_region_dispatch_{read|write} is yet to handle the endianness.
Once it does handle endianness, callers with byte swaps can collapse
them into adjust_endianness.
Signed-off-by: Tony Nguyen
---
accel/tcg/cputlb.c | 6 --
exec.c | 5 +++--
hw/intc/armv7m_nvic.c| 15 ---
hw/s390x/s390-pci-inst.c | 6 --
hw/vfio/pci-quirks.c | 5 +++--
hw/virtio/virtio-pci.c | 6 --
memory_ldst.inc.c| 18 --
7 files changed, 38 insertions(+), 23 deletions(-)
diff --git a/accel/tcg/cputlb.c b/accel/tcg/cputlb.c
index 6c83878..0aff6a3 100644
--- a/accel/tcg/cputlb.c
+++ b/accel/tcg/cputlb.c
@@ -906,7 +906,8 @@ static uint64_t io_readx(CPUArchState *env, CPUIOTLBEntry
*iotlbentry,
qemu_mutex_lock_iothread();
locked = true;
}
-r = memory_region_dispatch_read(mr, mr_offset, &val, size_memop(size),
+r = memory_region_dispatch_read(mr, mr_offset, &val,
+size_memop(size) | MO_TE,
iotlbentry->attrs);
if (r != MEMTX_OK) {
hwaddr physaddr = mr_offset +
@@ -947,7 +948,8 @@ static void io_writex(CPUArchState *env, CPUIOTLBEntry
*iotlbentry,
qemu_mutex_lock_iothread();
locked = true;
}
-r = memory_region_dispatch_write(mr, mr_offset, val, size_memop(size),
+r = memory_region_dispatch_write(mr, mr_offset, val,
+ size_memop(size) | MO_TE,
iotlbentry->attrs);
if (r != MEMTX_OK) {
hwaddr physaddr = mr_offset +
diff --git a/exec.c b/exec.c
index 303f9a7..562fb5b 100644
--- a/exec.c
+++ b/exec.c
@@ -3335,7 +3335,8 @@ static MemTxResult flatview_write_continue(FlatView *fv,
hwaddr addr,
potential bugs */
val = ldn_p(buf, l);
result |= memory_region_dispatch_write(mr, addr1, val,
- size_memop(l), attrs);
+ size_memop(l) | MO_TE,
+ attrs);
} else {
/* RAM case */
ptr = qemu_ram_ptr_length(mr->ram_block, addr1, &l, false);
@@ -3397,7 +3398,7 @@ MemTxResult flatview_read_continue(FlatView *fv, hwaddr
addr,
release_lock |= prepare_mmio_access(mr);
l = memory_access_size(mr, l, addr1);
result |= memory_region_dispatch_read(mr, addr1, &val,
- size_memop(l), attrs);
+ size_memop(l) | MO_TE,
attrs);
stn_p(buf, l, val);
} else {
/* RAM case */
diff --git a/hw/intc/armv7m_nvic.c b/hw/intc/armv7m_nvic.c
index 975d7cc..e150f9a 100644
--- a/hw/intc/armv7m_nvic.c
+++ b/hw/intc/armv7m_nvic.c
@@ -2346,8 +2346,8 @@ static MemTxResult nvic_sysreg_ns_write(void *opaque,
hwaddr addr,
if (attrs.secure) {
/* S accesses to the alias act like NS accesses to the real region */
attrs.secure = 0;
-return memory_region_dispatch_write(mr, addr, value, size_memop(size),
-attrs);
+return memory_region_dispatch_write(mr, addr, value,
+size_memop(size) | MO_TE, attrs);
} else {
/* NS attrs are RAZ/WI for privileged, and BusFault for user */
if (attrs.user) {
@@ -2366,8 +2366,8 @@ static MemTxResult nvic_sysreg_ns_read(void *opaque,
hwaddr addr,
if (attrs.secure) {
/* S accesses to the alias act like NS accesses to the real region */
attrs.secure = 0;
-return memory_region_dispatch_read(mr, addr, data, size_memop(size),
- attrs);
+return memory_region_dispatch_read(mr, addr, data,
+ size_memop(size) | MO_TE, attrs);
} else {
/* NS attrs are RAZ/WI for privileged, and BusFault for user */
if (attrs.user) {
@@ -2393,8 +2393,8 @@ static MemTxResult nvic_systick_write(void *opaque,
hwaddr addr,
/* Direct the access to the correct systick */
mr = sysbus_mmio_get_region(SYS_BUS_DEVICE(&s->systick[attrs.secure]), 0);
-return memory_region_dispatch_write(mr, addr, value, size_memop(size),
-attrs);
+return memory_region_dispatch_write(mr, addr, value,
+size_memop(size) | MO_TE, attrs);
}
static MemTxResult nvic_systick_read(void *opaque, hwaddr addr,
@@ -2406,7 +2406,8 @@ static MemTxResult nvic_systick_read(void *opaque, hwaddr
addr,
[Xen-devel] [Qemu-devel] [PATCH v7 35/42] exec: Delete DEVICE_HOST_ENDIAN
DEVICE_HOST_ENDIAN is conditional upon HOST_WORDS_BIGENDIAN.
Code is cleaner if the single use of DEVICE_HOST_ENDIAN is instead
directly conditional upon HOST_WORDS_BIGENDIAN.
Signed-off-by: Tony Nguyen
---
include/exec/cpu-common.h | 8
memory.c | 2 +-
2 files changed, 1 insertion(+), 9 deletions(-)
diff --git a/include/exec/cpu-common.h b/include/exec/cpu-common.h
index 7eeb78c..b33dc0c 100644
--- a/include/exec/cpu-common.h
+++ b/include/exec/cpu-common.h
@@ -16,14 +16,6 @@ void tcg_flush_softmmu_tlb(CPUState *cs);
#if !defined(CONFIG_USER_ONLY)
-#include "exec/memop.h"
-
-#if defined(HOST_WORDS_BIGENDIAN)
-#define DEVICE_HOST_ENDIAN MO_BE
-#else
-#define DEVICE_HOST_ENDIAN MO_LE
-#endif
-
/* address in the RAM (different from a physical address) */
#if defined(CONFIG_XEN_BACKEND)
typedef uint64_t ram_addr_t;
diff --git a/memory.c b/memory.c
index 3cabb52..689390f 100644
--- a/memory.c
+++ b/memory.c
@@ -1362,7 +1362,7 @@ static void memory_region_ram_device_write(void *opaque,
hwaddr addr,
static const MemoryRegionOps ram_device_mem_ops = {
.read = memory_region_ram_device_read,
.write = memory_region_ram_device_write,
-.endianness = DEVICE_HOST_ENDIAN,
+.endianness = 0, /* Host endianness */
.valid = {
.min_access_size = 1,
.max_access_size = 8,
--
1.8.3.1
?
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [Qemu-devel] [PATCH v7 37/42] cputlb: Replace size and endian operands for MemOp
Preparation for collapsing the two byte swaps adjust_endianness and
handle_bswap into the former.
Signed-off-by: Tony Nguyen
---
accel/tcg/cputlb.c | 172 +--
include/exec/memop.h | 6 ++
memory.c | 11 +---
3 files changed, 90 insertions(+), 99 deletions(-)
diff --git a/accel/tcg/cputlb.c b/accel/tcg/cputlb.c
index 0aff6a3..8022c81 100644
--- a/accel/tcg/cputlb.c
+++ b/accel/tcg/cputlb.c
@@ -881,7 +881,7 @@ static void tlb_fill(CPUState *cpu, target_ulong addr, int
size,
static uint64_t io_readx(CPUArchState *env, CPUIOTLBEntry *iotlbentry,
int mmu_idx, target_ulong addr, uintptr_t retaddr,
- MMUAccessType access_type, int size)
+ MMUAccessType access_type, MemOp op)
{
CPUState *cpu = env_cpu(env);
hwaddr mr_offset;
@@ -906,15 +906,13 @@ static uint64_t io_readx(CPUArchState *env, CPUIOTLBEntry
*iotlbentry,
qemu_mutex_lock_iothread();
locked = true;
}
-r = memory_region_dispatch_read(mr, mr_offset, &val,
-size_memop(size) | MO_TE,
-iotlbentry->attrs);
+r = memory_region_dispatch_read(mr, mr_offset, &val, op,
iotlbentry->attrs);
if (r != MEMTX_OK) {
hwaddr physaddr = mr_offset +
section->offset_within_address_space -
section->offset_within_region;
-cpu_transaction_failed(cpu, physaddr, addr, size, access_type,
+cpu_transaction_failed(cpu, physaddr, addr, memop_size(op),
access_type,
mmu_idx, iotlbentry->attrs, r, retaddr);
}
if (locked) {
@@ -926,7 +924,7 @@ static uint64_t io_readx(CPUArchState *env, CPUIOTLBEntry
*iotlbentry,
static void io_writex(CPUArchState *env, CPUIOTLBEntry *iotlbentry,
int mmu_idx, uint64_t val, target_ulong addr,
- uintptr_t retaddr, int size)
+ uintptr_t retaddr, MemOp op)
{
CPUState *cpu = env_cpu(env);
hwaddr mr_offset;
@@ -948,16 +946,15 @@ static void io_writex(CPUArchState *env, CPUIOTLBEntry
*iotlbentry,
qemu_mutex_lock_iothread();
locked = true;
}
-r = memory_region_dispatch_write(mr, mr_offset, val,
- size_memop(size) | MO_TE,
- iotlbentry->attrs);
+r = memory_region_dispatch_write(mr, mr_offset, val, op,
iotlbentry->attrs);
if (r != MEMTX_OK) {
hwaddr physaddr = mr_offset +
section->offset_within_address_space -
section->offset_within_region;
-cpu_transaction_failed(cpu, physaddr, addr, size, MMU_DATA_STORE,
- mmu_idx, iotlbentry->attrs, r, retaddr);
+cpu_transaction_failed(cpu, physaddr, addr, memop_size(op),
+ MMU_DATA_STORE, mmu_idx, iotlbentry->attrs, r,
+ retaddr);
}
if (locked) {
qemu_mutex_unlock_iothread();
@@ -1218,14 +1215,15 @@ static void *atomic_mmu_lookup(CPUArchState *env,
target_ulong addr,
* access type.
*/
-static inline uint64_t handle_bswap(uint64_t val, int size, bool big_endian)
+static inline uint64_t handle_bswap(uint64_t val, MemOp op)
{
-if ((big_endian && NEED_BE_BSWAP) || (!big_endian && NEED_LE_BSWAP)) {
-switch (size) {
-case 1: return val;
-case 2: return bswap16(val);
-case 4: return bswap32(val);
-case 8: return bswap64(val);
+if ((memop_big_endian(op) && NEED_BE_BSWAP) ||
+(!memop_big_endian(op) && NEED_LE_BSWAP)) {
+switch (op & MO_SIZE) {
+case MO_8: return val;
+case MO_16: return bswap16(val);
+case MO_32: return bswap32(val);
+case MO_64: return bswap64(val);
default:
g_assert_not_reached();
}
@@ -1248,7 +1246,7 @@ typedef uint64_t FullLoadHelper(CPUArchState *env,
target_ulong addr,
static inline uint64_t __attribute__((always_inline))
load_helper(CPUArchState *env, target_ulong addr, TCGMemOpIdx oi,
-uintptr_t retaddr, size_t size, bool big_endian, bool code_read,
+uintptr_t retaddr, MemOp op, bool code_read,
FullLoadHelper *full_load)
{
uintptr_t mmu_idx = get_mmuidx(oi);
@@ -1262,6 +1260,7 @@ load_helper(CPUArchState *env, target_ulong addr,
TCGMemOpIdx oi,
unsigned a_bits = get_alignment_bits(get_memop(oi));
void *haddr;
uint64_t res;
+size_t size = memop_size(op);
/* Handle CPU specific unaligned behaviour */
if (addr & ((1 << a_bits) - 1)) {
@@ -1307,9 +1306,10 @@ load_helper(CPUArchState *env, target_ulong addr,
TCGMemOpIdx oi,
}
}
+/* FIXME: io_readx ignores MO_BSWAP. */
res = io_readx(env, &env_tlb(env)->d[mmu_idx].iotlb[index],
- mmu_idx, addr, retaddr
[Xen-devel] [Qemu-devel] [PATCH v7 38/42] memory: Single byte swap along the I/O path
Now that MemOp has been pushed down into the memory API, and
callers are encoding endianness, we can collapse byte swaps
along the I/O path into the accelerator and target independent
adjust_endianness.
Collapsing byte swaps along the I/O path enables additional endian
inversion logic, e.g. SPARC64 Invert Endian TTE bit, with redundant
byte swaps cancelling out.
Suggested-by: Richard Henderson
Signed-off-by: Tony Nguyen
---
accel/tcg/cputlb.c | 42 +++--
hw/virtio/virtio-pci.c | 10
memory.c | 33 ++
memory_ldst.inc.c | 63 --
4 files changed, 19 insertions(+), 129 deletions(-)
diff --git a/accel/tcg/cputlb.c b/accel/tcg/cputlb.c
index 8022c81..bb2f55d 100644
--- a/accel/tcg/cputlb.c
+++ b/accel/tcg/cputlb.c
@@ -1200,38 +1200,6 @@ static void *atomic_mmu_lookup(CPUArchState *env,
target_ulong addr,
cpu_loop_exit_atomic(env_cpu(env), retaddr);
}
-#ifdef TARGET_WORDS_BIGENDIAN
-#define NEED_BE_BSWAP 0
-#define NEED_LE_BSWAP 1
-#else
-#define NEED_BE_BSWAP 1
-#define NEED_LE_BSWAP 0
-#endif
-
-/*
- * Byte Swap Helper
- *
- * This should all dead code away depending on the build host and
- * access type.
- */
-
-static inline uint64_t handle_bswap(uint64_t val, MemOp op)
-{
-if ((memop_big_endian(op) && NEED_BE_BSWAP) ||
-(!memop_big_endian(op) && NEED_LE_BSWAP)) {
-switch (op & MO_SIZE) {
-case MO_8: return val;
-case MO_16: return bswap16(val);
-case MO_32: return bswap32(val);
-case MO_64: return bswap64(val);
-default:
-g_assert_not_reached();
-}
-} else {
-return val;
-}
-}
-
/*
* Load Helpers
*
@@ -1306,10 +1274,8 @@ load_helper(CPUArchState *env, target_ulong addr,
TCGMemOpIdx oi,
}
}
-/* FIXME: io_readx ignores MO_BSWAP. */
-res = io_readx(env, &env_tlb(env)->d[mmu_idx].iotlb[index],
- mmu_idx, addr, retaddr, access_type, op);
-return handle_bswap(res, op);
+return io_readx(env, &env_tlb(env)->d[mmu_idx].iotlb[index],
+mmu_idx, addr, retaddr, access_type, op);
}
/* Handle slow unaligned access (it spans two pages or IO). */
@@ -1552,10 +1518,8 @@ store_helper(CPUArchState *env, target_ulong addr,
uint64_t val,
}
}
-/* FIXME: io_writex ignores MO_BSWAP. */
io_writex(env, &env_tlb(env)->d[mmu_idx].iotlb[index], mmu_idx,
- handle_bswap(val, op),
- addr, retaddr, op);
+ val, addr, retaddr, op);
return;
}
diff --git a/hw/virtio/virtio-pci.c b/hw/virtio/virtio-pci.c
index ad06c12..84f820d 100644
--- a/hw/virtio/virtio-pci.c
+++ b/hw/virtio/virtio-pci.c
@@ -542,16 +542,15 @@ void virtio_address_space_write(VirtIOPCIProxy *proxy,
hwaddr addr,
val = pci_get_byte(buf);
break;
case 2:
-val = cpu_to_le16(pci_get_word(buf));
+val = pci_get_word(buf);
break;
case 4:
-val = cpu_to_le32(pci_get_long(buf));
+val = pci_get_long(buf);
break;
default:
/* As length is under guest control, handle illegal values. */
return;
}
-/* FIXME: memory_region_dispatch_write ignores MO_BSWAP. */
memory_region_dispatch_write(mr, addr, val, size_memop(len) | MO_LE,
MEMTXATTRS_UNSPECIFIED);
}
@@ -576,7 +575,6 @@ virtio_address_space_read(VirtIOPCIProxy *proxy, hwaddr
addr,
/* Make sure caller aligned buf properly */
assert(!(((uintptr_t)buf) & (len - 1)));
-/* FIXME: memory_region_dispatch_read ignores MO_BSWAP. */
memory_region_dispatch_read(mr, addr, &val, size_memop(len) | MO_LE,
MEMTXATTRS_UNSPECIFIED);
switch (len) {
@@ -584,10 +582,10 @@ virtio_address_space_read(VirtIOPCIProxy *proxy, hwaddr
addr,
pci_set_byte(buf, val);
break;
case 2:
-pci_set_word(buf, le16_to_cpu(val));
+pci_set_word(buf, val);
break;
case 4:
-pci_set_long(buf, le32_to_cpu(val));
+pci_set_long(buf, val);
break;
default:
/* As length is under guest control, handle illegal values. */
diff --git a/memory.c b/memory.c
index 01fd29d..ebe0066 100644
--- a/memory.c
+++ b/memory.c
@@ -343,32 +343,23 @@ static void flatview_simplify(FlatView *view)
}
}
-static bool memory_region_wrong_endianness(MemoryRegion *mr)
+static void adjust_endianness(MemoryRegion *mr, uint64_t *data, MemOp op)
{
-#ifdef TARGET_WORDS_BIGENDIAN
-return mr->ops->endianness == MO_LE;
-#else
-return mr->ops->endianness == MO_BE;
-#endif
-}
-
-static void adjust_endianness(MemoryRegion *mr, uint64_t *data, unsigned size)
-{
-if (memory_region_wrong_endianness(mr)) {
-switch (size) {
-case 1:
+if ((op
[Xen-devel] [Qemu-devel] [PATCH v7 39/42] cpu: TLB_FLAGS_MASK bit to force memory slow path
The fast path is taken when TLB_FLAGS_MASK is all zero. TLB_FORCE_SLOW is simply a TLB_FLAGS_MASK bit to force the slow path, there are no other side effects. Signed-off-by: Tony Nguyen Reviewed-by: Richard Henderson --- include/exec/cpu-all.h | 10 -- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/include/exec/cpu-all.h b/include/exec/cpu-all.h index 536ea58..e496f99 100644 --- a/include/exec/cpu-all.h +++ b/include/exec/cpu-all.h @@ -331,12 +331,18 @@ CPUArchState *cpu_copy(CPUArchState *env); #define TLB_MMIO(1 << (TARGET_PAGE_BITS - 3)) /* Set if TLB entry must have MMU lookup repeated for every access */ #define TLB_RECHECK (1 << (TARGET_PAGE_BITS - 4)) +/* Set if TLB entry must take the slow path. */ +#define TLB_FORCE_SLOW (1 << (TARGET_PAGE_BITS - 5)) /* Use this mask to check interception with an alignment mask * in a TCG backend. */ -#define TLB_FLAGS_MASK (TLB_INVALID_MASK | TLB_NOTDIRTY | TLB_MMIO \ - | TLB_RECHECK) +#define TLB_FLAGS_MASK \ +(TLB_INVALID_MASK \ + | TLB_NOTDIRTY\ + | TLB_MMIO\ + | TLB_RECHECK \ + | TLB_FORCE_SLOW) /** * tlb_hit_page: return true if page aligned @addr is a hit against the -- 1.8.3.1 ? ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [Qemu-devel] [PATCH v7 40/42] cputlb: Byte swap memory transaction attribute
Notice new attribute, byte swap, and force the transaction through the
memory slow path.
Required by architectures that can invert endianness of memory
transaction, e.g. SPARC64 has the Invert Endian TTE bit.
Suggested-by: Richard Henderson
Signed-off-by: Tony Nguyen
Reviewed-by: Richard Henderson
---
accel/tcg/cputlb.c | 11 +++
include/exec/memattrs.h | 2 ++
2 files changed, 13 insertions(+)
diff --git a/accel/tcg/cputlb.c b/accel/tcg/cputlb.c
index bb2f55d..adfa4f2 100644
--- a/accel/tcg/cputlb.c
+++ b/accel/tcg/cputlb.c
@@ -738,6 +738,9 @@ void tlb_set_page_with_attrs(CPUState *cpu, target_ulong
vaddr,
*/
address |= TLB_RECHECK;
}
+if (attrs.byte_swap) {
+address |= TLB_FORCE_SLOW;
+}
if (!memory_region_is_ram(section->mr) &&
!memory_region_is_romd(section->mr)) {
/* IO memory case */
@@ -891,6 +894,10 @@ static uint64_t io_readx(CPUArchState *env, CPUIOTLBEntry
*iotlbentry,
bool locked = false;
MemTxResult r;
+if (iotlbentry->attrs.byte_swap) {
+op ^= MO_BSWAP;
+}
+
section = iotlb_to_section(cpu, iotlbentry->addr, iotlbentry->attrs);
mr = section->mr;
mr_offset = (iotlbentry->addr & TARGET_PAGE_MASK) + addr;
@@ -933,6 +940,10 @@ static void io_writex(CPUArchState *env, CPUIOTLBEntry
*iotlbentry,
bool locked = false;
MemTxResult r;
+if (iotlbentry->attrs.byte_swap) {
+op ^= MO_BSWAP;
+}
+
section = iotlb_to_section(cpu, iotlbentry->addr, iotlbentry->attrs);
mr = section->mr;
mr_offset = (iotlbentry->addr & TARGET_PAGE_MASK) + addr;
diff --git a/include/exec/memattrs.h b/include/exec/memattrs.h
index d4a3477..95f2d20 100644
--- a/include/exec/memattrs.h
+++ b/include/exec/memattrs.h
@@ -37,6 +37,8 @@ typedef struct MemTxAttrs {
unsigned int user:1;
/* Requester ID (for MSI for example) */
unsigned int requester_id:16;
+/* Invert endianness for this page */
+unsigned int byte_swap:1;
/*
* The following are target-specific page-table bits. These are not
* related to actual memory transactions at all. However, this structure
--
1.8.3.1
?
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [Qemu-devel] [PATCH v7 42/42] target/sparc: sun4u Invert Endian TTE bit
This bit configures endianness of PCI MMIO devices. It is used by
Solaris and OpenBSD sunhme drivers.
Tested working on OpenBSD.
Unfortunately Solaris 10 had a unrelated keyboard issue blocking
testing... another inch towards Solaris 10 on SPARC64 =)
Signed-off-by: Tony Nguyen
Reviewed-by: Richard Henderson
Tested-by: Mark Cave-Ayland
---
target/sparc/cpu.h| 2 ++
target/sparc/mmu_helper.c | 8 +++-
2 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/target/sparc/cpu.h b/target/sparc/cpu.h
index 1406f0b..c6bafa8 100644
--- a/target/sparc/cpu.h
+++ b/target/sparc/cpu.h
@@ -275,6 +275,7 @@ enum {
#define TTE_VALID_BIT (1ULL << 63)
#define TTE_NFO_BIT (1ULL << 60)
+#define TTE_IE_BIT (1ULL << 59)
#define TTE_USED_BIT(1ULL << 41)
#define TTE_LOCKED_BIT (1ULL << 6)
#define TTE_SIDEEFFECT_BIT (1ULL << 3)
@@ -291,6 +292,7 @@ enum {
#define TTE_IS_VALID(tte) ((tte) & TTE_VALID_BIT)
#define TTE_IS_NFO(tte) ((tte) & TTE_NFO_BIT)
+#define TTE_IS_IE(tte) ((tte) & TTE_IE_BIT)
#define TTE_IS_USED(tte)((tte) & TTE_USED_BIT)
#define TTE_IS_LOCKED(tte) ((tte) & TTE_LOCKED_BIT)
#define TTE_IS_SIDEEFFECT(tte) ((tte) & TTE_SIDEEFFECT_BIT)
diff --git a/target/sparc/mmu_helper.c b/target/sparc/mmu_helper.c
index 826e14b..77dc86a 100644
--- a/target/sparc/mmu_helper.c
+++ b/target/sparc/mmu_helper.c
@@ -537,6 +537,10 @@ static int get_physical_address_data(CPUSPARCState *env,
hwaddr *physical,
if (ultrasparc_tag_match(&env->dtlb[i], address, context, physical)) {
int do_fault = 0;
+if (TTE_IS_IE(env->dtlb[i].tte)) {
+attrs->byte_swap = true;
+}
+
/* access ok? */
/* multiple bits in SFSR.FT may be set on TT_DFAULT */
if (TTE_IS_PRIV(env->dtlb[i].tte) && is_user) {
@@ -792,7 +796,7 @@ void dump_mmu(CPUSPARCState *env)
}
if (TTE_IS_VALID(env->dtlb[i].tte)) {
qemu_printf("[%02u] VA: %" PRIx64 ", PA: %llx"
-", %s, %s, %s, %s, ctx %" PRId64 " %s\n",
+", %s, %s, %s, %s, ie %s, ctx %" PRId64 " %s\n",
i,
env->dtlb[i].tag & (uint64_t)~0x1fffULL,
TTE_PA(env->dtlb[i].tte),
@@ -801,6 +805,8 @@ void dump_mmu(CPUSPARCState *env)
TTE_IS_W_OK(env->dtlb[i].tte) ? "RW" : "RO",
TTE_IS_LOCKED(env->dtlb[i].tte) ?
"locked" : "unlocked",
+TTE_IS_IE(env->dtlb[i].tte) ?
+"yes" : "no",
env->dtlb[i].tag & (uint64_t)0x1fffULL,
TTE_IS_GLOBAL(env->dtlb[i].tte) ?
"global" : "local");
--
1.8.3.1
?
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [Qemu-devel] [PATCH v7 41/42] target/sparc: Add TLB entry with attributes
Append MemTxAttrs to interfaces so we can pass along up coming Invert
Endian TTE bit on SPARC64.
Signed-off-by: Tony Nguyen
Reviewed-by: Richard Henderson
---
target/sparc/mmu_helper.c | 32 ++--
1 file changed, 18 insertions(+), 14 deletions(-)
diff --git a/target/sparc/mmu_helper.c b/target/sparc/mmu_helper.c
index cbd1e91..826e14b 100644
--- a/target/sparc/mmu_helper.c
+++ b/target/sparc/mmu_helper.c
@@ -88,7 +88,7 @@ static const int perm_table[2][8] = {
};
static int get_physical_address(CPUSPARCState *env, hwaddr *physical,
-int *prot, int *access_index,
+int *prot, int *access_index, MemTxAttrs
*attrs,
target_ulong address, int rw, int mmu_idx,
target_ulong *page_size)
{
@@ -219,6 +219,7 @@ bool sparc_cpu_tlb_fill(CPUState *cs, vaddr address, int
size,
target_ulong vaddr;
target_ulong page_size;
int error_code = 0, prot, access_index;
+MemTxAttrs attrs = {};
/*
* TODO: If we ever need tlb_vaddr_to_host for this target,
@@ -229,7 +230,7 @@ bool sparc_cpu_tlb_fill(CPUState *cs, vaddr address, int
size,
assert(!probe);
address &= TARGET_PAGE_MASK;
-error_code = get_physical_address(env, &paddr, &prot, &access_index,
+error_code = get_physical_address(env, &paddr, &prot, &access_index,
&attrs,
address, access_type,
mmu_idx, &page_size);
vaddr = address;
@@ -490,8 +491,8 @@ static inline int ultrasparc_tag_match(SparcTLBEntry *tlb,
return 0;
}
-static int get_physical_address_data(CPUSPARCState *env,
- hwaddr *physical, int *prot,
+static int get_physical_address_data(CPUSPARCState *env, hwaddr *physical,
+ int *prot, MemTxAttrs *attrs,
target_ulong address, int rw, int mmu_idx)
{
CPUState *cs = env_cpu(env);
@@ -608,8 +609,8 @@ static int get_physical_address_data(CPUSPARCState *env,
return 1;
}
-static int get_physical_address_code(CPUSPARCState *env,
- hwaddr *physical, int *prot,
+static int get_physical_address_code(CPUSPARCState *env, hwaddr *physical,
+ int *prot, MemTxAttrs *attrs,
target_ulong address, int mmu_idx)
{
CPUState *cs = env_cpu(env);
@@ -686,7 +687,7 @@ static int get_physical_address_code(CPUSPARCState *env,
}
static int get_physical_address(CPUSPARCState *env, hwaddr *physical,
-int *prot, int *access_index,
+int *prot, int *access_index, MemTxAttrs
*attrs,
target_ulong address, int rw, int mmu_idx,
target_ulong *page_size)
{
@@ -716,11 +717,11 @@ static int get_physical_address(CPUSPARCState *env,
hwaddr *physical,
}
if (rw == 2) {
-return get_physical_address_code(env, physical, prot, address,
+return get_physical_address_code(env, physical, prot, attrs, address,
mmu_idx);
} else {
-return get_physical_address_data(env, physical, prot, address, rw,
- mmu_idx);
+return get_physical_address_data(env, physical, prot, attrs, address,
+ rw, mmu_idx);
}
}
@@ -734,10 +735,11 @@ bool sparc_cpu_tlb_fill(CPUState *cs, vaddr address, int
size,
target_ulong vaddr;
hwaddr paddr;
target_ulong page_size;
+MemTxAttrs attrs = {};
int error_code = 0, prot, access_index;
address &= TARGET_PAGE_MASK;
-error_code = get_physical_address(env, &paddr, &prot, &access_index,
+error_code = get_physical_address(env, &paddr, &prot, &access_index,
&attrs,
address, access_type,
mmu_idx, &page_size);
if (likely(error_code == 0)) {
@@ -747,7 +749,8 @@ bool sparc_cpu_tlb_fill(CPUState *cs, vaddr address, int
size,
env->dmmu.mmu_primary_context,
env->dmmu.mmu_secondary_context);
-tlb_set_page(cs, vaddr, paddr, prot, mmu_idx, page_size);
+tlb_set_page_with_attrs(cs, vaddr, paddr, attrs, prot, mmu_idx,
+page_size);
return true;
}
if (probe) {
@@ -849,9 +852,10 @@ static int cpu_sparc_get_phys_page(CPUSPARCState *env,
hwaddr *phys,
{
target_ulong page_size;
int prot, access_index;
+MemTxAttrs attrs = {};
-return get_physical_address(env, phys, &prot, &access_index, addr, rw,
-mmu_idx, &page_size);
+return get_physical_address(env, phys, &prot, &access_inde
[Xen-devel] [xen-unstable test] 140168: regressions - FAIL
flight 140168 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/140168/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-pvshim 18 guest-localmigrate/x10 fail REGR. vs. 139876 Tests which are failing intermittently (not blocking): test-xtf-amd64-amd64-47 xen-boot fail pass in 140145 test-amd64-i386-qemuu-rhel6hvm-intel 7 xen-boot fail pass in 140145 Tests which did not succeed, but are not blocking: test-arm64-arm64-examine 11 examine-serial/bootloaderfail like 139876 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 139876 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 139876 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 139876 test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 139876 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 139876 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 139876 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 139876 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 139876 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 139876 test-amd64-i386-xl-pvshim12 guest-start fail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 13 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit2 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-checkfail never pass test-arm64-arm64-xl 13 migrate-support-checkfail never pass test-arm64-arm64-xl 14 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit1 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass test-amd64-i386-xl-qemu
Re: [Xen-devel] [livepatch-build-tools v2 4/4] livepatch-build: Handle newly created object files
On 8/7/19 12:10 PM, Pawel Wieczorkiewicz wrote: Up to now the livepatch-build ignores newly created object files. When patch applies new .c file and augments its Makefile to build it the resulting object file is not taken into account for final linking step. Such newly created object files can be detected by comparing patched/ and original/ directories and copied over to the output directory for the final linking step. Signed-off-by: Pawel Wieczorkiewicz Reviewed-by: Andra-Irina Paraschiv Reviewed-by: Bjoern Doebel Reviewed-by: Norbert Manthey --- v2: * Fixed paths to process only hypervisor changes * Changing directory in subshells to simplified the command Reviewed-by: Ross Lagerwall Thanks ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [livepatch-build-tools part2 v2 1/6] common: Add is_standard_section() helper function
On 8/7/19 12:32 PM, Pawel Wieczorkiewicz wrote: Detect standard (always to be included) sections via their section header type. The standard sections: ".shstrtab", ".symtab", ".strtab" are either of type SHT_SYMTAB or SHT_STRTAB. Signed-off-by: Pawel Wieczorkiewicz Reviewed-by: Andra-Irina Paraschiv Reviewed-by: Bjoern Doebel Reviewed-by: Norbert Manthey --- v2: * Keep lines to 80 chars --- Reviewed-by: Ross Lagerwall Thanks ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v6 1/8] xen/arm: pass node to device_tree_for_each_node
Hi,
On 16/08/2019 00:36, Stefano Stabellini wrote:
Add a new parameter to device_tree_for_each_node: node, the node to
start the search from. Passing 0 triggers the old behavior.
Here you say 0 triggers the old behavior but...
Set min_depth to depth of the current node + 1 to avoid scanning
siblings of the initial node passed as an argument.
Don't call func() on the parent node passed as an argument. Clarify the
change in the comment on top of the function.
... here you mention that the first node will be skipped. So the behavior is now
different and should be explained in the commit message why this is fine to skip
the root node.
Signed-off-by: Stefano Stabellini
---
Changes in v6:
- fix code style
- don't call func() on the first node
Changes in v5:
- go back to v3
- code style improvement in acpi/boot.c
- improve comments and commit message
- increase min_depth to avoid parsing siblings
- replace for with do/while loop and increase min_depth to avoid
scanning siblings of the initial node
- pass only node, calculate depth
Changes in v3:
- improve commit message
- improve in-code comments
- improve code style
Changes in v2:
- new
---
xen/arch/arm/acpi/boot.c | 8 +---
xen/arch/arm/bootfdt.c| 34 --
xen/include/xen/device_tree.h | 6 +++---
3 files changed, 28 insertions(+), 20 deletions(-)
diff --git a/xen/arch/arm/acpi/boot.c b/xen/arch/arm/acpi/boot.c
index 9b29769a10..bf9c78b02c 100644
--- a/xen/arch/arm/acpi/boot.c
+++ b/xen/arch/arm/acpi/boot.c
@@ -246,9 +246,11 @@ int __init acpi_boot_table_init(void)
* - the device tree is not empty (it has more than just a /chosen node)
* and ACPI has not been force enabled (acpi=force)
*/
-if ( param_acpi_off || ( !param_acpi_force
- &&
device_tree_for_each_node(device_tree_flattened,
- dt_scan_depth1_nodes,
NULL)))
+if ( param_acpi_off)
+goto disable;
+if ( !param_acpi_force &&
+ device_tree_for_each_node(device_tree_flattened, 0,
+ dt_scan_depth1_nodes, NULL) )
goto disable;
/*
diff --git a/xen/arch/arm/bootfdt.c b/xen/arch/arm/bootfdt.c
index 891b4b66ff..f1614ef7fc 100644
--- a/xen/arch/arm/bootfdt.c
+++ b/xen/arch/arm/bootfdt.c
@@ -75,9 +75,10 @@ static u32 __init device_tree_get_u32(const void *fdt, int
node,
}
/**
- * device_tree_for_each_node - iterate over all device tree nodes
+ * device_tree_for_each_node - iterate over all device tree sub-nodes
* @fdt: flat device tree.
- * @func: function to call for each node.
+ * @node: parent node to start the search from
+ * @func: function to call for each sub-node.
* @data: data to pass to @func.
*
* Any nodes nested at DEVICE_TREE_MAX_DEPTH or deeper are ignored.
@@ -85,20 +86,18 @@ static u32 __init device_tree_get_u32(const void *fdt, int
node,
* Returns 0 if all nodes were iterated over successfully. If @func
* returns a value different from 0, that value is returned immediately.
*/
-int __init device_tree_for_each_node(const void *fdt,
+int __init device_tree_for_each_node(const void *fdt, int node,
device_tree_node_func func,
void *data)
{
-int node;
-int depth;
+int depth = fdt_node_depth(fdt, node);
Sorry I didn't spot this in the previous version. As I pointed out on v4 (and
you actually agreed!), you don't need the absolute depth...
You only need the relative depth. So this is a waste of processing as you have
to go through the FDT to calculate the depth.
This is not entirely critical so I would be willing to consider a patch on top
of this series.
+int min_depth = depth + 1;
+int first_node = node;
NIT: Anything that can't change should really be const to catch any mistake.
u32 address_cells[DEVICE_TREE_MAX_DEPTH];
u32 size_cells[DEVICE_TREE_MAX_DEPTH];
int ret;
-for ( node = 0, depth = 0;
- node >=0 && depth >= 0;
- node = fdt_next_node(fdt, node, &depth) )
-{
+do {
const char *name = fdt_get_name(fdt, node, NULL);
u32 as, ss;
@@ -117,10 +116,17 @@ int __init device_tree_for_each_node(const void *fdt,
size_cells[depth] = device_tree_get_u32(fdt, node,
"#size-cells", ss);
-ret = func(fdt, node, name, depth, as, ss, data);
-if ( ret != 0 )
-return ret;
-}
+/* skip the first node */
+if ( node != first_node )
+{
+ret = func(fdt, node, name, depth, as, ss, data);
+if ( ret != 0 )
+return ret;
+}
+
+node = fdt_next_node(fdt, node, &depth);
+} while ( node >= 0 && depth >= min_depth );
+
return 0;
}
@@ -357,7 +363,7 @@ size_t __init boot_
Re: [Xen-devel] [livepatch-build-tools part2 v2 4/6] livepatch-build: detect special section group sizes
On 8/8/19 1:29 PM, Pawel Wieczorkiewicz wrote: Hard-coding the special section group sizes is unreliable. Instead, determine them dynamically by finding the related struct definitions in the DWARF metadata. This is a livepatch backport of kpatch upstream commit [1]: kpatch-build: detect special section group sizes 170449847136a48b19fc Xen only deals with alt_instr, bug_frame and exception_table_entry structures, so sizes of these structures are obtained from xen-syms. This change is needed since with recent Xen the alt_instr structure has changed size from 12 to 14 bytes. [1] https://github.com/jpoimboe/kpatch/commit/170449847136a48b19fcceb19c1d4d257d386b56 Signed-off-by: Pawel Wieczorkiewicz Reviewed-by: Bjoern Doebel Reviewed-by: Martin Mazein --- v2: * Applied suggestions from Ross: - moved the livepatch-build hunk after build_full() call and re-using newly built xen-syms - dropped the redundant bug_frames_3_group_size() Reviewed-by: Ross Lagerwall ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v6 2/8] xen/arm: make process_memory_node a device_tree_node_func
Hi,
On 16/08/2019 00:36, Stefano Stabellini wrote:
Change the signature of process_memory_node to match
device_tree_node_func. Thanks to this change, the next patch will be
able to use device_tree_for_each_node to call process_memory_node on all
the children of a provided node.
Return error if there is no reg property or if nr_banks is reached. Let
the caller deal with the error.
This sentence does not match the change below. Only 2 of the new error paths are
described here.
Add a printk when device tree parsing fails.
Signed-off-by: Stefano Stabellini
---
Changes in v6:
- fix out of space check
- bring back printk when address_cells or size_cells are not properly set
- return -EINVAL in that case (different from reg missing)
- add printk when parsing fails
- return -ENOENT when memory size is 0
Changes in v5:
- return -ENOENT if address_cells or size_cells are not properly set
Changes in v4:
- return error if there is no reg propery, remove printk
- return error if nr_banks is reached
Changes in v3:
- improve commit message
- check return value of process_memory_node
Changes in v2:
- new
---
xen/arch/arm/bootfdt.c | 29 ++---
1 file changed, 18 insertions(+), 11 deletions(-)
diff --git a/xen/arch/arm/bootfdt.c b/xen/arch/arm/bootfdt.c
index f1614ef7fc..9dc2c1352d 100644
--- a/xen/arch/arm/bootfdt.c
+++ b/xen/arch/arm/bootfdt.c
@@ -130,9 +130,10 @@ int __init device_tree_for_each_node(const void *fdt, int
node,
return 0;
}
-static void __init process_memory_node(const void *fdt, int node,
- const char *name,
- u32 address_cells, u32 size_cells)
+static int __init process_memory_node(const void *fdt, int node,
+ const char *name, int depth,
+ u32 address_cells, u32 size_cells,
+ void *data)
{
const struct fdt_property *prop;
int i;
@@ -145,15 +146,12 @@ static void __init process_memory_node(const void *fdt,
int node,
{
printk("fdt: node `%s': invalid #address-cells or #size-cells",
name);
-return;
+return -EINVAL;
}
prop = fdt_get_property(fdt, node, "reg", NULL);
if ( !prop )
-{
-printk("fdt: node `%s': missing `reg' property\n", name);
-return;
-}
+return -ENOENT;
cell = (const __be32 *)prop->data;
banks = fdt32_to_cpu(prop->len) / (reg_cells * sizeof (u32));
@@ -162,11 +160,15 @@ static void __init process_memory_node(const void *fdt,
int node,
{
device_tree_get_reg(&cell, address_cells, size_cells, &start, &size);
if ( !size )
-continue;
+return -ENOENT;
I don't think we can treat the same way the lack of "regs" properties and a size
of 0.
The former is expected as binding allow you to do it for reserved-memory. The
latter is the user not writing the property correctly. So ignoring the latter
will result to Xen potentially missing some reserved-regions (not great!).
So, similar to #address-cells/#size-cells discussion, we should return an error
we are able to distinguish. Probably -EINVAL.
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v6 4/8] xen/arm: fix indentation in early_print_info
Hi, On 16/08/2019 00:36, Stefano Stabellini wrote: No functional changes. Signed-off-by: Stefano Stabellini Acked-by: Julien Grall Cheers, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [qemu-mainline test] 140170: tolerable FAIL - PUSHED
flight 140170 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/140170/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 140148 test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 140148 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 140148 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 140148 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 140148 test-amd64-i386-xl-pvshim12 guest-start fail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 13 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-arm64-arm64-xl 13 migrate-support-checkfail never pass test-arm64-arm64-xl 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit2 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit1 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-checkfail never pass test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass version targeted for testing: qemuu9e06029aea3b2eca1d5261352e695edc1e7d7b8b baseline version: qemuuf28ed74fd116491e31329044d140fde4aa23b2a0 Last test of basis 140148 2019-08-15 03:48:04 Z1 days Testing same since 140170 2019-08-15 18:37:06 Z0 days1 attempts People who touched revisions under test: Peter Maydell jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass bui
Re: [Xen-devel] [livepatch-build-tools part2 v2 3/6] create-diff-object: Add is_special_section() helper function function
On 8/8/19 1:23 PM, Pawel Wieczorkiewicz wrote: This function determines, based on the given section name, if the sections belongs to the special sections category. Add more special sections to special_sections[] along with a new undefined_group_size() helper function returning 0 (undefined). New special sections are: .altinstr_replacement. Is this paragraph describing patch 5/6? Signed-off-by: Pawel Wieczorkiewicz Reviewed-by: Andra-Irina Paraschiv Reviewed-by: Bjoern Doebel Reviewed-by: Norbert Manthey --- Reviewed-by: Ross Lagerwall (With the above paragraph and the duplicate word in the subject removed, which I can do during commit.) ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [livepatch-build-tools part2 v2 5/6] create-diff-object: Add new entries to special sections array array
On 8/8/19 1:35 PM, Pawel Wieczorkiewicz wrote:
Handle .livepatch.hooks* and .altinstr_replacement sections as the
special sections with assigned group_size resolution function.
By default each .livepatch.hooks* sections' entry is 8 bytes long (a
pointer). The .altinstr_replacement section has undefined group_size.
Allow to specify different .livepatch.hooks* section entry size using
shell environment variable HOOK_STRUCT_SIZE.
Signed-off-by: Pawel Wieczorkiewicz
Reviewed-by: Andra-Irina Paraschiv
Reviewed-by: Bjoern Doebel
Reviewed-by: Norbert Manthey
---
v2:
* Applied suggestions from Ross and neccessary changes enforced by
previous patch of the series:
- fixed indentation
- used log_debug() instead of printf()
- added aux. function undefined_group_size() returning 0 for a
undefined group_size
- added .altinstr_replacement to the special_sections array and
fixed its group_size to undefined (0).
---
create-diff-object.c | 30 ++
1 file changed, 30 insertions(+)
diff --git a/create-diff-object.c b/create-diff-object.c
index c6183c3..8365af0 100644
--- a/create-diff-object.c
+++ b/create-diff-object.c
@@ -995,6 +995,24 @@ static int altinstructions_group_size(struct kpatch_elf
*kelf, int offset)
return size;
}
+static int livepatch_hooks_group_size(struct kpatch_elf *kelf, int offset)
+{
+ static int size = 0;
+ char *str;
+ if (!size) {
+ str = getenv("HOOK_STRUCT_SIZE");
+ size = str ? atoi(str) : 8;
+ }
+
+ log_debug("livepatch_hooks_size=%d\n", size);
+ return size;
+}
+
+static int undefined_group_size(struct kpatch_elf *kelf, int offset)
+{
+ return 0;
+}
+
/*
* The rela groups in the .fixup section vary in size. The beginning of each
* .fixup rela group is referenced by the .ex_table section. To find the size
@@ -1072,6 +1090,18 @@ static struct special_section special_sections[] = {
.name = ".altinstructions",
.group_size = altinstructions_group_size,
},
+ {
+ .name = ".altinstr_replacement",
+ .group_size = undefined_group_size,
+ },
+ {
+ .name = ".livepatch.hooks.load",
+ .group_size = livepatch_hooks_group_size,
+ },
+ {
+ .name = ".livepatch.hooks.unload",
+ .group_size = livepatch_hooks_group_size,
+ },
{},
};
Unless I'm misunderstanding something, I can't see how
kpatch_regenerate_special_section would work with .altinstr_replacement
having a group size of 0. It looks to me like the for loop in that
function would become an infinite loop (due to incrementing by
group_size) and should_keep_rela_group would always return false.
Regards,
--
Ross Lagerwall
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v6 7/8] xen/arm: don't iomem_permit_access for reserved-memory regions
Hi,
On 16/08/2019 00:36, Stefano Stabellini wrote:
Don't allow reserved-memory regions to be remapped into any unprivileged
guests, until reserved-memory regions are properly supported in Xen. For
now, do not call iomem_permit_access on them, because giving
iomem_permit_access to dom0 means that the toolstack will be able to
assign the region to a domU.
Signed-off-by: Stefano Stabellini
---
Changes in v6:
- compare against "/reserved-memory/"
Changes in v5:
- fix check condition
- use strnicmp
- return error
- improve commit message
Changes in v4:
- compare the parent name with reserved-memory
- use dt_node_cmp
Changes in v3:
- new patch
---
xen/arch/arm/domain_build.c | 24
1 file changed, 16 insertions(+), 8 deletions(-)
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 4c8404155a..673ffa453f 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -1155,15 +1155,23 @@ static int __init map_range_to_domain(const struct
dt_device_node *dev,
bool need_mapping = !dt_device_for_passthrough(dev);
int res;
-res = iomem_permit_access(d, paddr_to_pfn(addr),
- paddr_to_pfn(PAGE_ALIGN(addr + len - 1)));
-if ( res )
+/*
+ * Don't give iomem permissions for reserved-memory ranges to domUs
In upstream Xen, this is only called for Dom0. So what are you referring to?
+ * until reserved-memory support is complete.
But as I pointed out before reserved-memory support is not going to happen via
iomem. This is an abuse of the interface.
+ */
A better comment would be:
"reserved-memory regions are RAM carved out for special purpose. They are not
MMIO and therefore a domain should not be able to manage them via the IOMEM
interface".
+if ( strnicmp(dt_node_full_name(dev), "/reserved-memory/",
+ strlen("/reserved-memory/")) != 0 )
{
-printk(XENLOG_ERR "Unable to permit to dom%d access to"
- " 0x%"PRIx64" - 0x%"PRIx64"\n",
- d->domain_id,
- addr & PAGE_MASK, PAGE_ALIGN(addr + len) - 1);
-return res;
+res = iomem_permit_access(d, paddr_to_pfn(addr),
+paddr_to_pfn(PAGE_ALIGN(addr + len - 1)));
+if ( res )
+{
+printk(XENLOG_ERR "Unable to permit to dom%d access to"
+" 0x%"PRIx64" - 0x%"PRIx64"\n",
+d->domain_id,
+addr & PAGE_MASK, PAGE_ALIGN(addr + len) - 1);
+return res;
+}
}
if ( need_mapping )
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [livepatch-build-tools part2 v2 2/6] common: Add is_referenced_section() helper function
On 8/7/19 12:49 PM, Pawel Wieczorkiewicz wrote: This function checks if given section has an included corresponding RELA section and/or any of the symbols table symbols references the section. Section associated symbols are ignored here as there is always such a symbol for every section. Signed-off-by: Pawel Wieczorkiewicz Reviewed-by: Andra-Irina Paraschiv Reviewed-by: Bjoern Doebel Reviewed-by: Norbert Manthey --- Reviewed-by: Ross Lagerwall ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [livepatch-build-tools part2 v2 6/6] create-diff-object: Do not include all .rodata sections
On 8/8/19 1:39 PM, Pawel Wieczorkiewicz wrote:
Older versions of GCC did not split .rodata.str sections by function.
Because of that, the entire section was always included.
The livepatch-build-tools commit [1] fixed patch creation and kept
including all .rodata.str sections, in order to maintain existing
behavior for GCC 6.1+.
This means all .rodata.str sections are always included by default,
regardless of whether they are needed or not.
During stacked hotpatch builds it leads to unnecessary accumulation of
the .rodata.str sections as each and every consecutive hotpatch module
contains all the .rodata.str sections of previous modules.
To prevent this situation, mark the .rodata.str sections for inclusion
only if they are referenced by any of the current hotpatch symbols (or
a corresponding RELA section).
Extend patchability verification to detect all non-standard, non-rela,
non-debug and non-special sections that are not referenced by any of
the symbols or RELA sections.
[1] 2af6f1aa6233 Fix patch creation with GCC 6.1+
Signed-off-by: Pawel Wieczorkiewicz
Reviewed-by: Andra-Irina Paraschiv
Reviewed-by: Bjoern Doebel
Reviewed-by: Norbert Manthey
---
v2:
* Made the commit message more precise and accurate (based on
Ross' comments to the v1 patch)
* Kept lines limited to 80 chars
---
create-diff-object.c | 30 --
1 file changed, 28 insertions(+), 2 deletions(-)
diff --git a/create-diff-object.c b/create-diff-object.c
index 8365af0..4252175 100644
--- a/create-diff-object.c
+++ b/create-diff-object.c
@@ -1350,8 +1350,7 @@ static void kpatch_include_standard_elements(struct
kpatch_elf *kelf)
list_for_each_entry(sec, &kelf->sections, list) {
/* include these sections even if they haven't changed */
- if (is_standard_section(sec) ||
- should_include_str_section(sec->name)) {
+ if (is_standard_section(sec)) {
sec->include = 1;
if (sec->secsym)
sec->secsym->include = 1;
@@ -1362,6 +1361,20 @@ static void kpatch_include_standard_elements(struct
kpatch_elf *kelf)
list_entry(kelf->symbols.next, struct symbol, list)->include = 1;
}
+static void kpatch_include_standard_string_elements(struct kpatch_elf *kelf)
+{
+ struct section *sec;
+
+ list_for_each_entry(sec, &kelf->sections, list) {
+ if (should_include_str_section(sec->name) &&
+ is_referenced_section(sec, kelf)) {
+ sec->include = 1;
+ if (sec->secsym)
+ sec->secsym->include = 1;
+ }
+ }
+}
+
#define inc_printf(fmt, ...) \
log_debug("%*s" fmt, recurselevel, "", ##__VA_ARGS__);
This patch looks good. There is a comment at the top of
should_include_str_section() which should probably be updated as well:
/*
* String sections are always included even if unchanged.
* The format is either:
* .rodata..str1.[0-9]+ (new in GCC 6.1.0)
* or .rodata.str1.[0-9]+ (older versions of GCC)
* For the new format we could be smarter and only include the needed
* strings sections.
*/
In fact, it is probably a good idea to rename the function to something
like "is_rodata_str_section()" since this more accurately describes what
it does now.
Thanks,
--
Ross Lagerwall
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [Qemu-devel] [PATCH v7 00/42] Invert Endian bit in SPARCv9 MMU TTE
Hi Tony, On 8/16/19 8:28 AM, tony.ngu...@bt.com wrote: > This patchset implements the IE (Invert Endian) bit in SPARCv9 MMU TTE. > > v7: [...] > - Re-declared many native endian devices as little or big endian. This is why > v7 has +16 patches. Why are you doing that? What is the rational? Anyhow if this not required by your series, you should split it out of it, and send it on your principal changes are merged. I'm worried because this these new patches involve many subsystems (thus maintainers) and reviewing them will now take a fair amount of time. > For each device declared with DEVICE_NATIVE_ENDIAN, find the set of > targets from the set of target/hw/*/device.o. > > If the set of targets are all little or all big endian, re-declare > the device endianness as DEVICE_LITTLE_ENDIAN or DEVICE_BIG_ENDIAN > respectively. If only little endian targets use a device, that doesn't mean the device is designed in little endian... Then if a big endian target plan to use this device, it will require more work and you might have introduced regressions... I'm not sure this is a safe move. > This *naive* deduction may result in genuinely native endian devices > being incorrectly declared as little or big endian, but should not > introduce regressions for current targets. Regards, Phil. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2] Allow get_maintainer.pl / add_maintainers.pl scripts to be called outside of xen.git
Hi Lars,
Thank you for the patch.
On 15/08/2019 18:22, Lars Kurth wrote:
Use-case: Allow using both scripts on xen repositories such as
mini-os.git, osstest.git,
Tool changes:
* add_maintainers.pl: $get_maintainer inherits path from $0
* get_maintainer.pl: warn (instead fo die) when called
from a different tree
Assumptions: the repository contains a MAINTAINERS file that
follows the same conventions as the file in xen.git
A suggested template
This file follows the same conventions as outlined in
xen.git:MAINTAINERS. Please refer to the file in xen.git
for more information.
THE REST
M: MAINTAINER1
M: MAINTAINER2
L: xen-devel@lists.xenproject.org
S: Supported
F: */
Signed-off-by: Lars Kurth
---
scripts/add_maintainers.pl | 4 ++--
scripts/get_maintainer.pl | 13 +++--
2 files changed, 13 insertions(+), 4 deletions(-)
diff --git a/scripts/add_maintainers.pl b/scripts/add_maintainers.pl
index 09e9f6609f..5a6d0f631b 100755
--- a/scripts/add_maintainers.pl
+++ b/scripts/add_maintainers.pl
@@ -26,9 +26,9 @@ sub insert ();
sub hastag ($$);
# Tool Variables
-my $get_maintainer = "./scripts/get_maintainer.pl";
-
my $tool = $0;
+my $get_maintainer = $tool;
+$get_maintainer =~ s/add_maintainers/get_maintainer/;
my $usage = <
if (!top_of_tree($xen_path)) {
-die "$P: The current directory does not appear to be "
- . "a Xen source tree.\n";
+# Do not exit, but print an error message to STDERR to allow calling
+# the tool from xen-related repos such as mini-os.git,
+# live patch-build-tools.git, etc
+print STDERR "$P:\n".
+ "=\n".
+ "WARNING: The current directory does not appear to be \n".
+ "the xen.git source tree.\n\n".
+ "The tool works outside of the xen.git tree, if the\n".
+ "MAINTAINERS file follows the same format as that of\n".
+ "xen.git. Use at your own peril.\n".
+ "=\n";
From my understanding, any use on mini-os.git & co will be legitimate. However,
we still print the WARNING in those cases.
Usually WARNING means something needs attention. As most of the users will
likely copy/paste from the wiki, we are going to have report asking why the
WARNING is there.
I think it would make sense to try to downgrade the message a bit when possible.
For instance, we could check if the section "THE REST" is present in the file
MAINTAINERS. If not, this is likely not a file we are able to support.
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [Qemu-devel] [PATCH v7 24/42] hw/isa: Declare device little or big endian
On 8/16/19 9:34 AM, tony.ngu...@bt.com wrote:
> For each device declared with DEVICE_NATIVE_ENDIAN, find the set of
> targets from the set of target/hw/*/device.o.
>
> If the set of targets are all little or all big endian, re-declare
> the device endianness as DEVICE_LITTLE_ENDIAN or DEVICE_BIG_ENDIAN
> respectively.
>
> This *naive* deduction may result in genuinely native endian devices
> being incorrectly declared as little or big endian, but should not
> introduce regressions for current targets.
>
> These devices should be re-declared as DEVICE_NATIVE_ENDIAN if 1) it
> has a new target with an opposite endian or 2) someone informed knows
> better =)
>
> Signed-off-by: Tony Nguyen
> ---
> hw/isa/vt82c686.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/hw/isa/vt82c686.c b/hw/isa/vt82c686.c
> index 12c460590..adf65d3 100644
> --- a/hw/isa/vt82c686.c
> +++ b/hw/isa/vt82c686.c
> @@ -108,7 +108,7 @@ static uint64_t superio_ioport_readb(void *opaque,
> hwaddr addr, unsigned size)
> static const MemoryRegionOps superio_ops = {
> .read = superio_ioport_readb,
> .write = superio_ioport_writeb,
> - .endianness = DEVICE_NATIVE_ENDIAN,
> + .endianness = DEVICE_LITTLE_ENDIAN,
Being ioport, one is probably OK.
> .impl = {
> .min_access_size = 1,
> .max_access_size = 1,
> --
> 1.8.3.1
>
>
>
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [Qemu-devel] [PATCH v7 25/42] hw/misc: Declare device little or big endian
On 8/16/19 9:34 AM, tony.ngu...@bt.com wrote:
> For each device declared with DEVICE_NATIVE_ENDIAN, find the set of
> targets from the set of target/hw/*/device.o.
>
> If the set of targets are all little or all big endian, re-declare
> the device endianness as DEVICE_LITTLE_ENDIAN or DEVICE_BIG_ENDIAN
> respectively.
>
> This *naive* deduction may result in genuinely native endian devices
> being incorrectly declared as little or big endian, but should not
> introduce regressions for current targets.
>
> These devices should be re-declared as DEVICE_NATIVE_ENDIAN if 1) it
> has a new target with an opposite endian or 2) someone informed knows
> better =)
>
> Signed-off-by: Tony Nguyen
> ---
> hw/misc/a9scu.c | 2 +-
> hw/misc/applesmc.c | 6 +++---
> hw/misc/arm11scu.c | 2 +-
> hw/misc/arm_l2x0.c | 2 +-
> hw/misc/puv3_pm.c | 2 +-
> 5 files changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/hw/misc/a9scu.c b/hw/misc/a9scu.c
> index 4307f00..3de8cd3 100644
> --- a/hw/misc/a9scu.c
> +++ b/hw/misc/a9scu.c
> @@ -94,7 +94,7 @@ static void a9_scu_write(void *opaque, hwaddr offset,
> static const MemoryRegionOps a9_scu_ops = {
> .read = a9_scu_read,
> .write = a9_scu_write,
> - .endianness = DEVICE_NATIVE_ENDIAN,
> + .endianness = DEVICE_LITTLE_ENDIAN,
Uh, I doubt that.
> };
>
> static void a9_scu_reset(DeviceState *dev)
> diff --git a/hw/misc/applesmc.c b/hw/misc/applesmc.c
> index 2d7eb3c..6c91f29 100644
> --- a/hw/misc/applesmc.c
> +++ b/hw/misc/applesmc.c
> @@ -285,7 +285,7 @@ static void qdev_applesmc_isa_reset(DeviceState *dev)
> static const MemoryRegionOps applesmc_data_io_ops = {
> .write = applesmc_io_data_write,
> .read = applesmc_io_data_read,
> - .endianness = DEVICE_NATIVE_ENDIAN,
> + .endianness = DEVICE_LITTLE_ENDIAN,
> .impl = {
> .min_access_size = 1,
> .max_access_size = 1,
> @@ -295,7 +295,7 @@ static const MemoryRegionOps applesmc_data_io_ops = {
> static const MemoryRegionOps applesmc_cmd_io_ops = {
> .write = applesmc_io_cmd_write,
> .read = applesmc_io_cmd_read,
> - .endianness = DEVICE_NATIVE_ENDIAN,
> + .endianness = DEVICE_LITTLE_ENDIAN,
> .impl = {
> .min_access_size = 1,
> .max_access_size = 1,
> @@ -305,7 +305,7 @@ static const MemoryRegionOps applesmc_cmd_io_ops = {
> static const MemoryRegionOps applesmc_err_io_ops = {
> .write = applesmc_io_err_write,
> .read = applesmc_io_err_read,
> - .endianness = DEVICE_NATIVE_ENDIAN,
> + .endianness = DEVICE_LITTLE_ENDIAN,
> .impl = {
> .min_access_size = 1,
> .max_access_size = 1,
Being ioport, this one might be OK.
> diff --git a/hw/misc/arm11scu.c b/hw/misc/arm11scu.c
> index 84275df..59fd7c0 100644
> --- a/hw/misc/arm11scu.c
> +++ b/hw/misc/arm11scu.c
> @@ -57,7 +57,7 @@ static void mpcore_scu_write(void *opaque, hwaddr offset,
> static const MemoryRegionOps mpcore_scu_ops = {
> .read = mpcore_scu_read,
> .write = mpcore_scu_write,
> - .endianness = DEVICE_NATIVE_ENDIAN,
> + .endianness = DEVICE_LITTLE_ENDIAN,
I don't think so,
> };
>
> static void arm11_scu_realize(DeviceState *dev, Error **errp)
> diff --git a/hw/misc/arm_l2x0.c b/hw/misc/arm_l2x0.c
> index b88f40a..72ecf46 100644
> --- a/hw/misc/arm_l2x0.c
> +++ b/hw/misc/arm_l2x0.c
> @@ -157,7 +157,7 @@ static void l2x0_priv_reset(DeviceState *dev)
> static const MemoryRegionOps l2x0_mem_ops = {
> .read = l2x0_priv_read,
> .write = l2x0_priv_write,
> - .endianness = DEVICE_NATIVE_ENDIAN,
> + .endianness = DEVICE_LITTLE_ENDIAN,
neither here, but Peter will confirm.
> };
>
> static void l2x0_priv_init(Object *obj)
> diff --git a/hw/misc/puv3_pm.c b/hw/misc/puv3_pm.c
> index b538b4a..cd82b69 100644
> --- a/hw/misc/puv3_pm.c
> +++ b/hw/misc/puv3_pm.c
> @@ -118,7 +118,7 @@ static const MemoryRegionOps puv3_pm_ops = {
> .min_access_size = 4,
> .max_access_size = 4,
> },
> - .endianness = DEVICE_NATIVE_ENDIAN,
> + .endianness = DEVICE_LITTLE_ENDIAN,
This one I can't tell.
> };
>
> static void puv3_pm_realize(DeviceState *dev, Error **errp)
> --
> 1.8.3.1
>
>
>
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [Qemu-devel] [PATCH v7 27/42] hw/pci-host: Declare device little or big endian
On 8/16/19 9:35 AM, tony.ngu...@bt.com wrote:
> For each device declared with DEVICE_NATIVE_ENDIAN, find the set of
> targets from the set of target/hw/*/device.o.
>
> If the set of targets are all little or all big endian, re-declare
> the device endianness as DEVICE_LITTLE_ENDIAN or DEVICE_BIG_ENDIAN
> respectively.
>
> This *naive* deduction may result in genuinely native endian devices
> being incorrectly declared as little or big endian, but should not
> introduce regressions for current targets.
>
> These devices should be re-declared as DEVICE_NATIVE_ENDIAN if 1) it
> has a new target with an opposite endian or 2) someone informed knows
> better =)
>
> Signed-off-by: Tony Nguyen
> ---
> hw/pci-host/q35.c | 2 +-
> hw/pci-host/versatile.c | 4 ++--
> 2 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/hw/pci-host/q35.c b/hw/pci-host/q35.c
> index 0a010be..fd20f72 100644
> --- a/hw/pci-host/q35.c
> +++ b/hw/pci-host/q35.c
> @@ -288,7 +288,7 @@ static void tseg_blackhole_write(void *opaque,
> hwaddr addr, uint64_t val,
> static const MemoryRegionOps tseg_blackhole_ops = {
> .read = tseg_blackhole_read,
> .write = tseg_blackhole_write,
> - .endianness = DEVICE_NATIVE_ENDIAN,
> + .endianness = DEVICE_LITTLE_ENDIAN,
OK.
> .valid.min_access_size = 1,
> .valid.max_access_size = 4,
> .impl.min_access_size = 4,
> diff --git a/hw/pci-host/versatile.c b/hw/pci-host/versatile.c
> index 791b321..e7017f3 100644
> --- a/hw/pci-host/versatile.c
> +++ b/hw/pci-host/versatile.c
> @@ -240,7 +240,7 @@ static uint64_t pci_vpb_reg_read(void *opaque,
> hwaddr addr,
> static const MemoryRegionOps pci_vpb_reg_ops = {
> .read = pci_vpb_reg_read,
> .write = pci_vpb_reg_write,
> - .endianness = DEVICE_NATIVE_ENDIAN,
> + .endianness = DEVICE_LITTLE_ENDIAN,
> .valid = {
> .min_access_size = 4,
> .max_access_size = 4,
> @@ -306,7 +306,7 @@ static uint64_t pci_vpb_config_read(void *opaque,
> hwaddr addr,
> static const MemoryRegionOps pci_vpb_config_ops = {
> .read = pci_vpb_config_read,
> .write = pci_vpb_config_write,
> - .endianness = DEVICE_NATIVE_ENDIAN,
> + .endianness = DEVICE_LITTLE_ENDIAN,
Eh hard to say, PCI is not clear about endianess...
> };
>
> static int pci_vpb_map_irq(PCIDevice *d, int irq_num)
> --
> 1.8.3.1
>
>
>
>
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [qemu-s390x] [Qemu-devel] [PATCH v7 33/42] exec: Replace device_endian with MemOp
On 8/16/19 9:37 AM, tony.ngu...@bt.com wrote: > Simplify endianness comparisons with consistent use of the more > expressive MemOp. > > Suggested-by: Richard Henderson > Signed-off-by: Tony Nguyen > Reviewed-by: Richard Henderson > Acked-by: David Gibson This patch is *huge*, more than 800kB. It keeps being stuck in the the filter of the qemu-s390x list each time you send it. Please: 1) Try to break it up in more digestible pieces, e.g. change only one subsystem at a time (this is also better reviewable by people who are interested in one area) 2) Do not send HTML emails to the mailing list. Thanks, Thomas ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] More QEMU gcc-9.1 build issues
On Fri, Aug 09, 2019 at 02:32:47PM +0200, Dario Faggioli wrote: > Hey Anthony, > > There's more of those issues related to building our QEMU with recent > (the one in openSUSE Tumbleweed) GCC: > > gcc version 9.1.1 20190723 [gcc-9-branch revision 273734] (SUSE Linux) [...] > I fixed it by manually importing the following upstream commit: > > 94932c95c10 "qxl: avoid unaligned pointer reads/writes" Done. And I've merged every single commit available upstream! I hope that's enough :-D. Joke aside, QEMU v4.1 was released today, so I merged it. I was waiting for that instead of cherry-picking the single commit you've pointed. Cheers, -- Anthony PERARD ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH] get_maintainers.pl: Enable running the script on unikraft repos
Unikraft repos follow the same syntax as xen.git with the
following exceptions:
* MAINTAINERS files are called MAINTAINERS.md
* M: ... etc blocks are preceded by whitespaces for rendering as
markup files
This change will
- load MAINTAINERS.md if MAINTAINERS is not present
- deal with indented M: ... blocks
Signed-off-by: Lars Kurth
---
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Ian Jackson
Cc: Jan Beulich
Cc: Julien Grall
Cc: Konrad Rzeszutek Wilk
Cc: Stefano Stabellini
Cc: Tim Deegan
Cc: Wei Liu
CC: Simon Kuenzer
CC: Florian Schmidt
CC: Felipe Huici
---
scripts/get_maintainer.pl | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/scripts/get_maintainer.pl b/scripts/get_maintainer.pl
index f1e9c904ee..bdb09f8f65 100755
--- a/scripts/get_maintainer.pl
+++ b/scripts/get_maintainer.pl
@@ -284,12 +284,18 @@ if (!top_of_tree($xen_path)) {
my @typevalue = ();
my %keyword_hash;
-open (my $maint, '<', "${xen_path}MAINTAINERS")
-or die "$P: Can't open MAINTAINERS: $!\n";
+my $maint;
+my $maintainers_file = "MAINTAINERS";
+if (! open ($maint, '<', ${xen_path}.$maintainers_file)) {
+$maintainers_file = "MAINTAINERS.md";
+open ($maint, '<', ${xen_path}.$maintainers_file)
+or die "$P: Can't open MAINTAINERS or MAINTAINERS.md: $!\n";
+}
+
while (<$maint>) {
my $line = $_;
-if ($line =~ m/^([A-Z]):\s*(.*)/) {
+if ($line =~ m/^\s*([A-Z]):\s*(.*)/) {
my $type = $1;
my $value = $2;
@@ -421,7 +427,7 @@ foreach my $file (@ARGV) {
}
if ($from_filename) {
push(@files, $file);
- if ($file ne "MAINTAINERS" && -f $file && ($keywords || $file_emails)) {
+ if ($file ne $maintainers_file && -f $file && ($keywords ||
$file_emails)) {
open(my $f, '<', $file)
or die "$P: Can't open $file: $!\n";
my $text = do { local($/) ; <$f> };
--
2.13.0
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] get_maintainers.pl: Enable running the script on unikraft repos
Hi Lars,
On 16/08/2019 11:42, Lars Kurth wrote:
Unikraft repos follow the same syntax as xen.git with the
following exceptions:
* MAINTAINERS files are called MAINTAINERS.md
* M: ... etc blocks are preceded by whitespaces for rendering as
markup files
There is an other difference. The "fallback" category is "UNIKRAFT GENERAL" and
not "THE REST".
This change will
- load MAINTAINERS.md if MAINTAINERS is not present
- deal with indented M: ... blocks
One process question. Does it mean Unikraft folks will have to checkout Xen in
order to use {add, get}_maintainers.pl? If so, would it make sense to have
add_maintainers.pl and script_maintainers.pl in a separate repo that can be
added as submodule?
Signed-off-by: Lars Kurth
---
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Ian Jackson
Cc: Jan Beulich
Cc: Julien Grall
Cc: Konrad Rzeszutek Wilk
Cc: Stefano Stabellini
Cc: Tim Deegan
Cc: Wei Liu
CC: Simon Kuenzer
CC: Florian Schmidt
CC: Felipe Huici
---
scripts/get_maintainer.pl | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/scripts/get_maintainer.pl b/scripts/get_maintainer.pl
index f1e9c904ee..bdb09f8f65 100755
--- a/scripts/get_maintainer.pl
+++ b/scripts/get_maintainer.pl
@@ -284,12 +284,18 @@ if (!top_of_tree($xen_path)) {
my @typevalue = ();
my %keyword_hash;
-open (my $maint, '<', "${xen_path}MAINTAINERS")
-or die "$P: Can't open MAINTAINERS: $!\n";
+my $maint;
+my $maintainers_file = "MAINTAINERS";
+if (! open ($maint, '<', ${xen_path}.$maintainers_file)) {
+$maintainers_file = "MAINTAINERS.md";
+open ($maint, '<', ${xen_path}.$maintainers_file)
+or die "$P: Can't open MAINTAINERS or MAINTAINERS.md: $!\n";
+}
+
while (<$maint>) {
my $line = $_;
-if ($line =~ m/^([A-Z]):\s*(.*)/) {
+if ($line =~ m/^\s*([A-Z]):\s*(.*)/) {
As you allow space before the blocks M:, would not this catch the example at the
beginning of the file?
M: Mail patches to: FullName
R: Designated reviewer: FullName
my $type = $1;
my $value = $2;
@@ -421,7 +427,7 @@ foreach my $file (@ARGV) {
}
if ($from_filename) {
push(@files, $file);
- if ($file ne "MAINTAINERS" && -f $file && ($keywords || $file_emails)) {
+ if ($file ne $maintainers_file && -f $file && ($keywords ||
$file_emails)) {
open(my $f, '<', $file)
or die "$P: Can't open $file: $!\n";
my $text = do { local($/) ; <$f> };
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] get_maintainers.pl: Enable running the script on unikraft repos
On Fri, Aug 16, 2019 at 11:55:16AM +0100, Julien Grall wrote:
> Hi Lars,
>
> On 16/08/2019 11:42, Lars Kurth wrote:
> > Unikraft repos follow the same syntax as xen.git with the
> > following exceptions:
> > * MAINTAINERS files are called MAINTAINERS.md
> > * M: ... etc blocks are preceded by whitespaces for rendering as
> >markup files
>
> There is an other difference. The "fallback" category is "UNIKRAFT GENERAL"
> and not "THE REST".
>
> >
> > This change will
> > - load MAINTAINERS.md if MAINTAINERS is not present
> > - deal with indented M: ... blocks
>
> One process question. Does it mean Unikraft folks will have to checkout Xen
> in order to use {add, get}_maintainers.pl? If so, would it make sense to
> have add_maintainers.pl and script_maintainers.pl in a separate repo that
> can be added as submodule?
Shouldn't instead the Unikraft repo have it's one get_maintainers
script? xen.git's script doesn't needs to have support for every single
repo available on earth and Unikraft is a different project anyway.
Usually, projects with a MAINTAINERS file have there own get_maintainers
script.
Cheers,
--
Anthony PERARD
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [RFC] Code of Conduct
On 8/15/19 6:23 PM, Rich Persaud wrote: >> On Aug 9, 2019, at 13:48, Lars Kurth wrote: >> >> Hi all, > > Hi Lars, > >> >> Following the discussion we had at the Developer Summit (see >> https://wiki.xenproject.org/wiki/Design_Sessions_2019#Community_Issues_.2F_Improvements_-_Communication.2C_Code_of_Conduct.2C_etc. >> for notes) I put together a draft for the Code of Conduct which can be >> found here as well as inlined below >> https://docs.google.com/document/d/1NnWdU_VnC1N_ZzxQG6jU9fnY2GPVCcfPJT5KY61WXJM/edit?usp=sharing >> >> >> It is based on the LF Events CoC as we agreed on (the diff is attached). I >> took the scope and enforcement sections from >> https://www.contributor-covenant.org/version/1/4/code-of-conduct.html and >> simplified it rather than inventing something new. > > Is there precedent for applying a legal contract (Code of Conduct) that was > designed for physical space (conference event) to an online context? Is > there an existing Code of Conduct that was legally designed for a similar, > online open-source community context, e.g. operating system or hypervisor or > other systems-level software dev? This is sort of a strange question. Generally speaking, there was a link Lars pointed to in an earlier thread in preparation for this, making two suggestions about adopting a CoC: 1. Don't create your own CoC from scratch. Learn from other people's experiences, mistakes, and so on, rather than re-inventing the wheel. This will hopefully reduce the chance of re-hashing mistakes other communities have made. 2. Don't copy-and-paste a CoC unmodified from another project. Consider it, adapt it to your own community culture and situation. This makes sure that the CoC is not a tick-box exercise, but that people in your community have thoughfully considered various issues and genuinely decided to commit to them. I think both of those bits of advice are good; and it appears to me that this is exactly what Lars (with input from a number of others) has done. There are two things that we want, in general: 1. To cast a vision for what ideal contributor behavior should be 2. To set a bar for minimum acceptable behavior, and a way for excluding people whose behavior consistently falls below that bar. One area in particular where Lars thought other CoCs were weak was in trying to combine #1 and #2. They need different responses. #1 needs encouragement and vision. #2 needs teeth: We need to be able to apply penalties and exclude people. As a result, Lars has suggested (and many people have agreed), that we separate the two functions. This document is about #2, not #1. We plan to do #1 after #2 is completed. >> # Expected Behavior >> All Xen Project community members are expected to behave in accordance with >> professional standards, with both the Xen Project Code of Conduct as well as >> their >> respective employer’s policies governing appropriate workplace behavior, and >> applicable laws. > > In the x86 community call where this was first discussed, I suggested that we > try to define desirable behavior, which we would like to incentivize and > promote. In this current draft, we have a single sentence on positive > behavior, with inclusion-by-reference to: We plan on doing this, but in another document. > If incorporation-by-reference is not sufficient, e.g. if we will maintain a > blacklist of unacceptable behavior for collaborative, online open-source > development, do we also need a whitelist of acceptable behavior? Within Xen > source code, we have been moving away from blacklists towards whitelists. Unlike hypercalls, all human behavior cannot be enumerated; and if it could, 100% certainty cannot be obtained about what a certain behavior is, or even exactly what did or did not happen. No matter what we write down, at some point, you're just going to have to either trust the people making the decisions. >> # Unacceptable Behavior >> Harassment will not be tolerated in the Xen Project Community in any form, >> including but not limited to harassment based on gender, gender identity and >> expression, sexual orientation, disability, physical appearance, body size, >> race, >> age, religion, ethnicity, nationality, level of experience, education, or >> socio-economic status or any other status protected by laws in jurisdictions >> in >> which community members are based. Harassment includes the use of abusive, >> offensive or degrading language, intimidation, stalking, harassing >> photography >> or recording, inappropriate physical contact, sexual imagery and unwelcome >> sexual advances, requests for sexual favors, publishing others' private >> information such as a physical or electronic address without explicit >> permission > > Picking one item at random: would a conference-originated blacklist > prohibition be appropriate for online open-source development? E.g. if > someone's email address were included in a xen-devel thr
Re: [Xen-devel] [Qemu-devel] [PATCH v7 00/42] Invert Endian bit in SPARCv9 MMU TTE
Hi Phillippe, On 8/16/19 7:58 PM, Philippe Mathieu-Daudé wrote: >On 8/16/19 8:28 AM, tony.ngu...@bt.com wrote: >> This patchset implements the IE (Invert Endian) bit in SPARCv9 MMU TTE. >> >> v7: >[...] >> - Re-declared many native endian devices as little or big endian. This is why >> v7 has +16 patches. > >Why are you doing that? What is the rational? While collapsing the byte swaps, it was suggested in patch #11 of v5 that consistent use of MemOp simplified endian comparisons. This lead to the deprecation of enum device_endian by MemOp. As MO_TE is conditional upon NEED_CPU_H, the s/DEVICE_NATIVE_ENDIAN/MO_TE/ required changing some device object files from common-obj-* to obj-*. In patch #15 of v6 Paolo noted that most devices should not of been DEVICE_NATIVE_ENDIAN and hinted at a clean up. The +16 patches in v7 is the clean up effort. >Anyhow if this not required by your series, you should split it out of >it, and send it on your principal changes are merged. >I'm worried because this these new patches involve many subsystems (thus >maintainers) and reviewing them will now take a fair amount of time. Yes, lets split these patches out. They are very much a tangent to the series purpose. >> For each device declared with DEVICE_NATIVE_ENDIAN, find the set of >> targets from the set of target/hw/*/device.o. >> >> If the set of targets are all little or all big endian, re-declare >> the device endianness as DEVICE_LITTLE_ENDIAN or DEVICE_BIG_ENDIAN >> respectively. > >If only little endian targets use a device, that doesn't mean the device >is designed in little endian... > >Then if a big endian target plan to use this device, it will require >more work and you might have introduced regressions... > >I'm not sure this is a safe move. > >> This *naive* deduction may result in genuinely native endian devices >> being incorrectly declared as little or big endian, but should not >> introduce regressions for current targets. > Roger. Evidently too naive. TBH, most devices I've never heard of... Regards, Tony ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [ovmf test] 140177: all pass - PUSHED
flight 140177 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/140177/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 48d8d4d80bb299af5422312d92b044cb10a2e790 baseline version: ovmf f5892aa8d8bfbe8e6af5c9765faad8cfe877c334 Last test of basis 140144 2019-08-15 01:39:33 Z1 days Testing same since 140162 2019-08-15 12:49:52 Z0 days2 attempts People who touched revisions under test: Chasel Chiu Eric Jin Jian J Wang Jin, Eric Leif Lindholm Michael D Kinney Sean Brogan Shenglei Zhang Wang Fan jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/osstest/ovmf.git f5892aa8d8..48d8d4d80b 48d8d4d80bb299af5422312d92b044cb10a2e790 -> xen-tested-master ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] get_maintainers.pl: Enable running the script on unikraft repos
Hi Julien,
On 16/08/2019, 11:55, "Julien Grall" wrote:
Hi Lars,
On 16/08/2019 11:42, Lars Kurth wrote:
> Unikraft repos follow the same syntax as xen.git with the
> following exceptions:
> * MAINTAINERS files are called MAINTAINERS.md
> * M: ... etc blocks are preceded by whitespaces for rendering as
>markup files
There is an other difference. The "fallback" category is "UNIKRAFT GENERAL"
and
not "THE REST".
That is right. But currently get_maintainers.pl: totally ignores the headlines.
It just reads
M: ...
R: ...
Etc.
What is different is that "UNIKRAFT GENERAL" does not contain
F: entries, which have to be added, otherwise no e-mail addresses
from the section are added. So I was going to send a patch to fix this.
> This change will
> - load MAINTAINERS.md if MAINTAINERS is not present
> - deal with indented M: ... blocks
One process question. Does it mean Unikraft folks will have to checkout Xen
in
order to use {add, get}_maintainers.pl? If so, would it make sense to have
add_maintainers.pl and script_maintainers.pl in a separate repo that can be
added as submodule?
The way how the code is written they would either have to check out the
repo or just get the two scripts and put them in the same directory somewhere
on the path.
For things like mini-os, xtf, osstest, ... you would always have a xen.git
somewhere
In the unikraft case that is different. We could break it out, but maybe we can
do this
at a later point in time.
> Signed-off-by: Lars Kurth
> ---
> Cc: Andrew Cooper
> Cc: George Dunlap
> Cc: Ian Jackson
> Cc: Jan Beulich
> Cc: Julien Grall
> Cc: Konrad Rzeszutek Wilk
> Cc: Stefano Stabellini
> Cc: Tim Deegan
> Cc: Wei Liu
>
> CC: Simon Kuenzer
> CC: Florian Schmidt
> CC: Felipe Huici
> ---
> scripts/get_maintainer.pl | 14 ++
> 1 file changed, 10 insertions(+), 4 deletions(-)
>
> diff --git a/scripts/get_maintainer.pl b/scripts/get_maintainer.pl
> index f1e9c904ee..bdb09f8f65 100755
> --- a/scripts/get_maintainer.pl
> +++ b/scripts/get_maintainer.pl
> @@ -284,12 +284,18 @@ if (!top_of_tree($xen_path)) {
> my @typevalue = ();
> my %keyword_hash;
>
> -open (my $maint, '<', "${xen_path}MAINTAINERS")
> -or die "$P: Can't open MAINTAINERS: $!\n";
> +my $maint;
> +my $maintainers_file = "MAINTAINERS";
> +if (! open ($maint, '<', ${xen_path}.$maintainers_file)) {
> +$maintainers_file = "MAINTAINERS.md";
> +open ($maint, '<', ${xen_path}.$maintainers_file)
> +or die "$P: Can't open MAINTAINERS or MAINTAINERS.md: $!\n";
> +}
> +
> while (<$maint>) {
> my $line = $_;
>
> -if ($line =~ m/^([A-Z]):\s*(.*)/) {
> +if ($line =~ m/^\s*([A-Z]):\s*(.*)/) {
As you allow space before the blocks M:, would not this catch the example
at the
beginning of the file?
M: Mail patches to: FullName
R: Designated reviewer: FullName
Good point. When I tested it (I sent the last few patches with the change in
it),
it didn't pick up the e-mail addresses. However, when I check with regex101.com
it is picked up.
Which means that the values are pushed to @typevalue, aka
{ "R", "Designated reviewer: FullName " }
Etc.
@typevalue seem to be processed by find_first_section(),
find_starting_index(), find_ending_index()
And then basically the entries are not processed because the
block in the example is not consistent and fails the validation
further down the line
For example:
./scripts/get_maintainer.pl --email --git -f .
Etc.
Don't list the e-mail addresses in the examples
So, what I proposed is probably far too fragile to make sense.
And doing something which is more accurate will probably
require major surgery to the scripts.
I can look at this in a bit more detail and see whether there
is a way to handle this.
But I don't want to invest the time to do this really as this
is probably rather complex.
@Simon, @Florian, @Felipe: would you be willing to
change the MAINTAINERS files in your repos such that
we don't have to implement lots of magic to make the
patch sending helper scripts work for you?
Regards
Lars
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [Qemu-devel] [PATCH v7 00/42] Invert Endian bit in SPARCv9 MMU TTE
On Fri, 16 Aug 2019 at 12:37, wrote: > > Hi Phillippe, > > On 8/16/19 7:58 PM, Philippe Mathieu-Daudé wrote: > >On 8/16/19 8:28 AM, tony.ngu...@bt.com wrote: > >> For each device declared with DEVICE_NATIVE_ENDIAN, find the set of > >> targets from the set of target/hw/*/device.o. > >> > >> If the set of targets are all little or all big endian, re-declare > >> the device endianness as DEVICE_LITTLE_ENDIAN or DEVICE_BIG_ENDIAN > >> respectively. > > > >If only little endian targets use a device, that doesn't mean the device > >is designed in little endian... > > > >Then if a big endian target plan to use this device, it will require > >more work and you might have introduced regressions... > > > >I'm not sure this is a safe move. > > > >> This *naive* deduction may result in genuinely native endian devices > >> being incorrectly declared as little or big endian, but should not > >> introduce regressions for current targets. > > > > Roger. Evidently too naive. TBH, most devices I've never heard of... OTOH it's worth noting that it's quite likely that most of the implementations of these DEVICE_NATIVE_ENDIAN devices picked it in an equally naive way, by just copying some other device's code... thanks -- PMM ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] get_maintainers.pl: Enable running the script on unikraft repos
Added Paul Durrant
On 16/08/2019, 12:17, "Anthony PERARD" wrote:
On Fri, Aug 16, 2019 at 11:55:16AM +0100, Julien Grall wrote:
> Hi Lars,
>
> On 16/08/2019 11:42, Lars Kurth wrote:
> > Unikraft repos follow the same syntax as xen.git with the
> > following exceptions:
> > * MAINTAINERS files are called MAINTAINERS.md
> > * M: ... etc blocks are preceded by whitespaces for rendering as
> >markup files
>
> There is an other difference. The "fallback" category is "UNIKRAFT
GENERAL"
> and not "THE REST".
>
> >
> > This change will
> > - load MAINTAINERS.md if MAINTAINERS is not present
> > - deal with indented M: ... blocks
>
> One process question. Does it mean Unikraft folks will have to checkout
Xen
> in order to use {add, get}_maintainers.pl? If so, would it make sense to
> have add_maintainers.pl and script_maintainers.pl in a separate repo that
> can be added as submodule?
Shouldn't instead the Unikraft repo have it's one get_maintainers
script? xen.git's script doesn't needs to have support for every single
repo available on earth and Unikraft is a different project anyway.
Usually, projects with a MAINTAINERS file have there own get_maintainers
script.
Well: Unikraft is part of the Xen Project.
When I started to clean up the contribution docs it became apparent that
there is a lot of inconsistency. Ideally our contribution guide [0] would apply
to pretty much *all* sub projects which use a mailing list based workflows
Consistency makes life for developers and also newcomers much easier. And the
number of new devs who seem to trip over inconsistencies between projects are
quite large (we had 3 cases in 3 weeks which I noticed).
If we start improving our CI infrastructure (which we are), it would be nice if
other
sub projects had the possibility to easily hook into it or replicate it. But
that does require
some consistency.
That's why I submitted [1] and [2]
Sub-projects with mail based workflows
1: Hypervisor
2: Hypervisor related repos (livepatch-build-tools, mini-os, xtf, ...)
3: Windows PV Drivers - which will require changes to their MAINTAINERS file
4: Unikraft
Supporting 1 - 3 should be straightforward because you would almost always
have xen.git checked out. 4 is more different.
When I did [1] supporting Unikraft looked quite straightforward, which is
why I submitted this patch. But, given the issues Julien highlighted maybe that
is not the case.
I think for now, maybe we should focus on 1 - 3 and let the Unikraft devs
decide
how to approach this. Then we can revisit the question of where to store these
scripts. For now, I think requiring to have xen.git checked out is OK.
Regards
Lars
[0] https://wiki.xenproject.org/wiki/Submitting_Xen_Project_Patches
[1]
https://lists.xenproject.org/archives/html/xen-devel/2019-08/threads.html#01575
[2]
https://lists.xenproject.org/archives/html/xen-devel/2019-08/threads.html#01581
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [Qemu-devel] [PATCH v7 00/42] Invert Endian bit in SPARCv9 MMU TTE
On Fri, Aug 16, 2019 at 11:58:05AM +0200, Philippe Mathieu-Daudé wrote: > Hi Tony, > > On 8/16/19 8:28 AM, tony.ngu...@bt.com wrote: > > This patchset implements the IE (Invert Endian) bit in SPARCv9 MMU TTE. > > > > v7: > [...] > > - Re-declared many native endian devices as little or big endian. This is > > why > > v7 has +16 patches. > > Why are you doing that? What is the rational? > > Anyhow if this not required by your series, you should split it out of > it, and send it on your principal changes are merged. > I'm worried because this these new patches involve many subsystems (thus > maintainers) and reviewing them will now take a fair amount of time. > > > For each device declared with DEVICE_NATIVE_ENDIAN, find the set of > > targets from the set of target/hw/*/device.o. > > > > If the set of targets are all little or all big endian, re-declare > > the device endianness as DEVICE_LITTLE_ENDIAN or DEVICE_BIG_ENDIAN > > respectively. > > If only little endian targets use a device, that doesn't mean the device > is designed in little endian... > > Then if a big endian target plan to use this device, it will require > more work and you might have introduced regressions... Uh.. only if they make the version of the device on a big endian target big endian. Which is a terrible idea - if you know a hardware designer planning to do this, please slap them. -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson signature.asc Description: PGP signature ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [livepatch-build-tools part2 v2 5/6] create-diff-object: Add new entries to special sections array array
On 16. Aug 2019, at 11:40, Ross Lagerwall
mailto:ross.lagerw...@citrix.com>> wrote:
On 8/8/19 1:35 PM, Pawel Wieczorkiewicz wrote:
…snip...
* The rela groups in the .fixup section vary in size. The beginning of each
* .fixup rela group is referenced by the .ex_table section. To find the size
@@ -1072,6 +1090,18 @@ static struct special_section special_sections[] = {
.name = ".altinstructions",
.group_size = altinstructions_group_size,
},
+ {
+ .name = ".altinstr_replacement",
+ .group_size = undefined_group_size,
+ },
+ {
+ .name = ".livepatch.hooks.load",
+ .group_size = livepatch_hooks_group_size,
+ },
+ {
+ .name = ".livepatch.hooks.unload",
+ .group_size = livepatch_hooks_group_size,
+ },
{},
};
Unless I'm misunderstanding something, I can't see how
kpatch_regenerate_special_section would work with .altinstr_replacement having
a group size of 0. It looks to me like the for loop in that function would
become an infinite loop (due to incrementing by group_size) and
should_keep_rela_group would always return false.
AFAICS, the group_size 0 sections are never actually processed by the
kpatch_regenerate_special_section().
They are not RELA sections and the following check excludes them from this
processing:
static void kpatch_process_special_sections(struct kpatch_elf *kelf)
{
[…]
for (special = special_sections; special->name; special++) {
[…]
sec = sec->rela;
if (!sec)
continue;
kpatch_regenerate_special_section(kelf, special, sec);
}
Nevertheless, you are right. It does not make much sense to rely on this
assumption.
I will add explicit checks to kpatch_regenerate_special_section() and friends
dealing with group_size 0 sections.
Regards,
--
Ross Lagerwall
Best,
Pawel Wieczorkiewicz
Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Ralf Herbrich
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] get_maintainers.pl: Enable running the script on unikraft repos
> -Original Message-
> From: Lars Kurth
> Sent: 16 August 2019 13:05
> To: Anthony Perard ; Julien Grall
>
> Cc: xen-devel@lists.xenproject.org; Felipe Huici ;
> Stefano Stabellini
> ; Wei Liu ; Konrad Rzeszutek Wilk
> ; George
> Dunlap ; Andrew Cooper ;
> Ian Jackson
> ; Tim (Xen.org) ; Florian Schmidt
> ;
> Jan Beulich ; Simon Kuenzer ;
> Paul Durrant
>
> Subject: Re: [Xen-devel] [PATCH] get_maintainers.pl: Enable running the
> script on unikraft repos
>
> Added Paul Durrant
>
> On 16/08/2019, 12:17, "Anthony PERARD" wrote:
>
> On Fri, Aug 16, 2019 at 11:55:16AM +0100, Julien Grall wrote:
> > Hi Lars,
> >
> > On 16/08/2019 11:42, Lars Kurth wrote:
> > > Unikraft repos follow the same syntax as xen.git with the
> > > following exceptions:
> > > * MAINTAINERS files are called MAINTAINERS.md
> > > * M: ... etc blocks are preceded by whitespaces for rendering as
> > >markup files
> >
> > There is an other difference. The "fallback" category is "UNIKRAFT
> GENERAL"
> > and not "THE REST".
> >
> > >
> > > This change will
> > > - load MAINTAINERS.md if MAINTAINERS is not present
> > > - deal with indented M: ... blocks
> >
> > One process question. Does it mean Unikraft folks will have to checkout
> Xen
> > in order to use {add, get}_maintainers.pl? If so, would it make sense to
> > have add_maintainers.pl and script_maintainers.pl in a separate repo
> that
> > can be added as submodule?
>
> Shouldn't instead the Unikraft repo have it's one get_maintainers
> script? xen.git's script doesn't needs to have support for every single
> repo available on earth and Unikraft is a different project anyway.
>
> Usually, projects with a MAINTAINERS file have there own get_maintainers
> script.
>
> Well: Unikraft is part of the Xen Project.
>
> When I started to clean up the contribution docs it became apparent that
> there is a lot of inconsistency. Ideally our contribution guide [0] would
> apply
> to pretty much *all* sub projects which use a mailing list based workflows
>
> Consistency makes life for developers and also newcomers much easier. And the
> number of new devs who seem to trip over inconsistencies between projects are
> quite large (we had 3 cases in 3 weeks which I noticed).
>
> If we start improving our CI infrastructure (which we are), it would be nice
> if other
> sub projects had the possibility to easily hook into it or replicate it. But
> that does require
> some consistency.
>
> That's why I submitted [1] and [2]
>
> Sub-projects with mail based workflows
> 1: Hypervisor
> 2: Hypervisor related repos (livepatch-build-tools, mini-os, xtf, ...)
> 3: Windows PV Drivers - which will require changes to their MAINTAINERS file
> 4: Unikraft
>
> Supporting 1 - 3 should be straightforward because you would almost always
> have xen.git checked out. 4 is more different.
I'd say that folks building 3 are unlikely to have xen.git checked out.
Paul
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [livepatch-build-tools part2 v2 6/6] create-diff-object: Do not include all .rodata sections
> On 16. Aug 2019, at 11:57, Ross Lagerwall wrote:
>
> On 8/8/19 1:39 PM, Pawel Wieczorkiewicz wrote:
>>
…snip...
>> #define inc_printf(fmt, ...) \
>> log_debug("%*s" fmt, recurselevel, "", ##__VA_ARGS__);
> This patch looks good. There is a comment at the top of
> should_include_str_section() which should probably be updated as well:
>
> /*
> * String sections are always included even if unchanged.
> * The format is either:
> * .rodata..str1.[0-9]+ (new in GCC 6.1.0)
> * or .rodata.str1.[0-9]+ (older versions of GCC)
> * For the new format we could be smarter and only include the needed
> * strings sections.
> */
>
Oh yes, right. Let me update the comment. Thanks!
> In fact, it is probably a good idea to rename the function to something like
> "is_rodata_str_section()" since this more accurately describes what it does
> now.
ACK, will do.
>
> Thanks,
> --
> Ross Lagerwall
Best Regards,
Pawel Wieczorkiewicz
signature.asc
Description: Message signed with OpenPGP
Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Ralf Herbrich
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2] Allow get_maintainer.pl / add_maintainers.pl scripts to be called outside of xen.git
On 16/08/2019, 11:01, "Julien Grall" wrote:
Hi Lars,
Thank you for the patch.
On 15/08/2019 18:22, Lars Kurth wrote:
> Use-case: Allow using both scripts on xen repositories such as
> mini-os.git, osstest.git,
>
> Tool changes:
> * add_maintainers.pl: $get_maintainer inherits path from $0
> * get_maintainer.pl: warn (instead fo die) when called
>from a different tree
>
> Assumptions: the repository contains a MAINTAINERS file that
> follows the same conventions as the file in xen.git
>
> A suggested template
>
>
> This file follows the same conventions as outlined in
> xen.git:MAINTAINERS. Please refer to the file in xen.git
> for more information.
>
> THE REST
> M:MAINTAINER1
> M: MAINTAINER2
> L:xen-devel@lists.xenproject.org
> S:Supported
> F:*/
>
>
> Signed-off-by: Lars Kurth
> ---
> scripts/add_maintainers.pl | 4 ++--
> scripts/get_maintainer.pl | 13 +++--
> 2 files changed, 13 insertions(+), 4 deletions(-)
>
> diff --git a/scripts/add_maintainers.pl b/scripts/add_maintainers.pl
> index 09e9f6609f..5a6d0f631b 100755
> --- a/scripts/add_maintainers.pl
> +++ b/scripts/add_maintainers.pl
> @@ -26,9 +26,9 @@ sub insert ();
> sub hastag ($$);
>
> # Tool Variables
> -my $get_maintainer = "./scripts/get_maintainer.pl";
> -
> my $tool = $0;
> +my $get_maintainer = $tool;
> +$get_maintainer =~ s/add_maintainers/get_maintainer/;
> my $usage = < OPTIONS:
>
> diff --git a/scripts/get_maintainer.pl b/scripts/get_maintainer.pl
> index 174dfb7e40..f1e9c904ee 100755
> --- a/scripts/get_maintainer.pl
> +++ b/scripts/get_maintainer.pl
> @@ -266,8 +266,17 @@ if ($email &&
> }
>
> if (!top_of_tree($xen_path)) {
> -die "$P: The current directory does not appear to be "
> - . "a Xen source tree.\n";
> +# Do not exit, but print an error message to STDERR to allow calling
> +# the tool from xen-related repos such as mini-os.git,
> +# live patch-build-tools.git, etc
> +print STDERR "$P:\n".
> + "=\n".
> + "WARNING: The current directory does not appear to be \n".
> + "the xen.git source tree.\n\n".
> + "The tool works outside of the xen.git tree, if the\n".
> + "MAINTAINERS file follows the same format as that of\n".
> + "xen.git. Use at your own peril.\n".
> + "=\n";
From my understanding, any use on mini-os.git & co will be legitimate.
However,
we still print the WARNING in those cases.
Usually WARNING means something needs attention. As most of the users will
likely copy/paste from the wiki, we are going to have report asking why the
WARNING is there.
I think it would make sense to try to downgrade the message a bit when
possible.
For instance, we could check if the section "THE REST" is present in the
file
MAINTAINERS. If not, this is likely not a file we are able to support.
I thought about this and it is not as easy as it seems, because the script only
parses
M: ... &c lines
Maybe the best way to address this would be to include some identifier into the
MAINTAINERS file (after the header with all the definitions).
FORMAT: xen-project-maintainers
(note that this is not currently picked up by the tool)
Or
V: xen-project-maintainers
(note that this would be picked up by the tool)
Then any compliant version is easily identifiable and the warning can be
supressed.
That would make maintainers look like
V: xen-project-maintainers 1.6
ACPI
M: Jan Beulich
...
This seems to be more of a can of worms than I thought.
Cheers
Lars
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] get_maintainers.pl: Enable running the script on unikraft repos
On 16/08/2019, 13:09, "Paul Durrant" wrote:
> -Original Message-
> From: Lars Kurth
> Sent: 16 August 2019 13:05
> To: Anthony Perard ; Julien Grall
> Cc: xen-devel@lists.xenproject.org; Felipe Huici
; Stefano Stabellini
> ; Wei Liu ; Konrad Rzeszutek Wilk
; George
> Dunlap ; Andrew Cooper
; Ian Jackson
> ; Tim (Xen.org) ; Florian Schmidt
;
> Jan Beulich ; Simon Kuenzer ;
Paul Durrant
>
> Subject: Re: [Xen-devel] [PATCH] get_maintainers.pl: Enable running the
script on unikraft repos
>
> Added Paul Durrant
>
> On 16/08/2019, 12:17, "Anthony PERARD" wrote:
>
> On Fri, Aug 16, 2019 at 11:55:16AM +0100, Julien Grall wrote:
> > Hi Lars,
> >
> > On 16/08/2019 11:42, Lars Kurth wrote:
> > > Unikraft repos follow the same syntax as xen.git with the
> > > following exceptions:
> > > * MAINTAINERS files are called MAINTAINERS.md
> > > * M: ... etc blocks are preceded by whitespaces for rendering as
> > >markup files
> >
> > There is an other difference. The "fallback" category is "UNIKRAFT
GENERAL"
> > and not "THE REST".
> >
> > >
> > > This change will
> > > - load MAINTAINERS.md if MAINTAINERS is not present
> > > - deal with indented M: ... blocks
> >
> > One process question. Does it mean Unikraft folks will have to
checkout Xen
> > in order to use {add, get}_maintainers.pl? If so, would it make
sense to
> > have add_maintainers.pl and script_maintainers.pl in a separate
repo that
> > can be added as submodule?
>
> Shouldn't instead the Unikraft repo have it's one get_maintainers
> script? xen.git's script doesn't needs to have support for every
single
> repo available on earth and Unikraft is a different project anyway.
>
> Usually, projects with a MAINTAINERS file have there own
get_maintainers
> script.
>
> Well: Unikraft is part of the Xen Project.
>
> When I started to clean up the contribution docs it became apparent that
> there is a lot of inconsistency. Ideally our contribution guide [0] would
apply
> to pretty much *all* sub projects which use a mailing list based workflows
>
> Consistency makes life for developers and also newcomers much easier. And
the
> number of new devs who seem to trip over inconsistencies between projects
are
> quite large (we had 3 cases in 3 weeks which I noticed).
>
> If we start improving our CI infrastructure (which we are), it would be
nice if other
> sub projects had the possibility to easily hook into it or replicate it.
But that does require
> some consistency.
>
> That's why I submitted [1] and [2]
>
> Sub-projects with mail based workflows
> 1: Hypervisor
> 2: Hypervisor related repos (livepatch-build-tools, mini-os, xtf, ...)
> 3: Windows PV Drivers - which will require changes to their MAINTAINERS
file
> 4: Unikraft
>
> Supporting 1 - 3 should be straightforward because you would almost always
> have xen.git checked out. 4 is more different.
I'd say that folks building 3 are unlikely to have xen.git checked out.
Good to know
If there was tooling available that simplifies your workflow, would
members of the Windows PV Drivers sub-project be willing to use them?
It maybe that for Windows PV Drivers the workflow is not at all command
line based and people tend to use an IDE instead.
Lars
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] get_maintainers.pl: Enable running the script on unikraft repos
> -Original Message-
> From: Lars Kurth
> Sent: 16 August 2019 13:20
> To: Paul Durrant ; Anthony Perard
> ; Julien Grall
>
> Cc: xen-devel@lists.xenproject.org; Felipe Huici ;
> Stefano Stabellini
> ; Wei Liu ; Konrad Rzeszutek Wilk
> ; George
> Dunlap ; Andrew Cooper ;
> Ian Jackson
> ; Tim (Xen.org) ; Florian Schmidt
> ;
> Jan Beulich ; Simon Kuenzer
> Subject: Re: [Xen-devel] [PATCH] get_maintainers.pl: Enable running the
> script on unikraft repos
>
>
>
> On 16/08/2019, 13:09, "Paul Durrant" wrote:
>
> > -Original Message-
> > From: Lars Kurth
> > Sent: 16 August 2019 13:05
> > To: Anthony Perard ; Julien Grall
>
> > Cc: xen-devel@lists.xenproject.org; Felipe Huici
> ; Stefano Stabellini
> > ; Wei Liu ; Konrad Rzeszutek Wilk
> ;
> George
> > Dunlap ; Andrew Cooper
> ; Ian Jackson
> > ; Tim (Xen.org) ; Florian Schmidt
> ;
> > Jan Beulich ; Simon Kuenzer
> ; Paul Durrant
> >
> > Subject: Re: [Xen-devel] [PATCH] get_maintainers.pl: Enable running the
> script on unikraft repos
> >
> > Added Paul Durrant
> >
> > On 16/08/2019, 12:17, "Anthony PERARD"
> wrote:
> >
> > On Fri, Aug 16, 2019 at 11:55:16AM +0100, Julien Grall wrote:
> > > Hi Lars,
> > >
> > > On 16/08/2019 11:42, Lars Kurth wrote:
> > > > Unikraft repos follow the same syntax as xen.git with the
> > > > following exceptions:
> > > > * MAINTAINERS files are called MAINTAINERS.md
> > > > * M: ... etc blocks are preceded by whitespaces for rendering as
> > > >markup files
> > >
> > > There is an other difference. The "fallback" category is
> "UNIKRAFT GENERAL"
> > > and not "THE REST".
> > >
> > > >
> > > > This change will
> > > > - load MAINTAINERS.md if MAINTAINERS is not present
> > > > - deal with indented M: ... blocks
> > >
> > > One process question. Does it mean Unikraft folks will have to
> checkout Xen
> > > in order to use {add, get}_maintainers.pl? If so, would it make
> sense to
> > > have add_maintainers.pl and script_maintainers.pl in a separate
> repo that
> > > can be added as submodule?
> >
> > Shouldn't instead the Unikraft repo have it's one get_maintainers
> > script? xen.git's script doesn't needs to have support for every
> single
> > repo available on earth and Unikraft is a different project anyway.
> >
> > Usually, projects with a MAINTAINERS file have there own
> get_maintainers
> > script.
> >
> > Well: Unikraft is part of the Xen Project.
> >
> > When I started to clean up the contribution docs it became apparent that
> > there is a lot of inconsistency. Ideally our contribution guide [0]
> would apply
> > to pretty much *all* sub projects which use a mailing list based
> workflows
> >
> > Consistency makes life for developers and also newcomers much easier.
> And the
> > number of new devs who seem to trip over inconsistencies between
> projects are
> > quite large (we had 3 cases in 3 weeks which I noticed).
> >
> > If we start improving our CI infrastructure (which we are), it would be
> nice if other
> > sub projects had the possibility to easily hook into it or replicate
> it. But that does require
> > some consistency.
> >
> > That's why I submitted [1] and [2]
> >
> > Sub-projects with mail based workflows
> > 1: Hypervisor
> > 2: Hypervisor related repos (livepatch-build-tools, mini-os, xtf, ...)
> > 3: Windows PV Drivers - which will require changes to their MAINTAINERS
> file
> > 4: Unikraft
> >
> > Supporting 1 - 3 should be straightforward because you would almost
> always
> > have xen.git checked out. 4 is more different.
>
> I'd say that folks building 3 are unlikely to have xen.git checked out.
>
> Good to know
>
> If there was tooling available that simplifies your workflow, would
> members of the Windows PV Drivers sub-project be willing to use them?
>
Sure, but our MAINTAINERS files are trivial, and most code changes are made by
Owen and myself anyway. Not sure there's really a need for any extra tooling.
> It maybe that for Windows PV Drivers the workflow is not at all command
> line based and people tend to use an IDE instead.
>
Some folks may use the Visual Studio IDE. I don't, and the Jenkins build
workers do rely on the python (pre-9.0) or powershell (9.0 onwards) scripts so
building via command line does need to be tested by contributors.
Paul
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH livepatch-python 1/1] livepatch: Add python bindings for livepatch operations
On Thu, Aug 15, 2019 at 11:36:46AM +, Pawel Wieczorkiewicz wrote: > Extend the XC python bindings library to support also all common > livepatch operations and actions. > > Add the python bindings for the following operations: > - status (pyxc_livepatch_status): > Requires a payload name as an input. > Returns a status dict containing a state string and a return code > integer. > - action (pyxc_livepatch_action): > Requires a payload name and an action id as an input. Timeout and > flags are optional parameters. > Returns a return code integer. > - upload (pyxc_livepatch_upload): > Requires a payload name and a module's filename as an input. > Returns a return code integer. > - list (pyxc_livepatch_list): > Takes no parameters. > Returns a list of dicts containing each payload's: > * name as a string > * state as a string > * return code as an integer > * list of metadata key=value strings > > Each functions throws an exception error based on the errno value > received from its corresponding libxc function call. > > Signed-off-by: Pawel Wieczorkiewicz > Reviewed-by: Martin Mazein > Reviewed-by: Andra-Irina Paraschiv > Reviewed-by: Leonard Foerster > Reviewed-by: Norbert Manthey I haven't looked in details, but I'm fine with these new functionalities in general. Let's see if Marek has any objections. Which version of Python do you use to build these? The requirement here is the code should build with both Python 2.5 and Python 3. Wei. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH lp-metadata 3/3] livepatch: Add metadata runtime retrieval mechanism
On Thu, Aug 15, 2019 at 11:27:50AM +, Pawel Wieczorkiewicz wrote: > Extend the livepatch list operation to fetch also payloads' metadata. > This is achieved by extending the sysctl list interface with 2 extra > guest handles: > * metadata - an array of arbitrary size strings > * metadata_len - an array of metadata strings' lengths (uin32_t each) > > Payloads' metadata is a string of arbitrary size and does not have an > upper bound limit. It may also vary in size between payloads. > > In order to let the userland allocate enough space for the incoming > data add a metadata total size field to the list sysctl operation and > fill it with total size of all payloads' metadata. > > Extend the libxc to handle the metadata back-to-back data transfers > as well as metadata length array data transfers. > > The xen-livepatch userland tool is extended to always display the > metadata for each received module. The metadata is received with the > following format: key=value\0key=value\0...key=value\0. The format is > modified to the following one: key=value;key=value;...key=value. > The new format allows to easily parse the metadata for a given module > by a machine. > > Signed-off-by: Pawel Wieczorkiewicz > Reviewed-by: Andra-Irina Paraschiv > Reviewed-by: Martin Pohlack > Reviewed-by: Norbert Manthey > --- > tools/libxc/include/xenctrl.h | 22 +++ > tools/libxc/xc_misc.c | 66 > +++ > tools/misc/xen-livepatch.c| 43 ++-- > xen/common/livepatch.c| 22 +++ > xen/include/public/sysctl.h | 19 + Mostly look good. One comment below... > diff --git a/xen/include/public/sysctl.h b/xen/include/public/sysctl.h > index b86804b7a6..e4c8f4fe63 100644 > --- a/xen/include/public/sysctl.h > +++ b/xen/include/public/sysctl.h If it hasn't been done for this release already, changing sysctl interface requires bumping the version number in this header. Wei. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] libxlu: Handle += in config files
On Tue, Aug 13, 2019 at 05:42:15PM +0100, Anthony PERARD wrote: > On Tue, Aug 13, 2019 at 04:47:23PM +0100, Andrew Cooper wrote: > > Error between user and terminal. :) > > > > I'd sync'd xl and libxl.so, but not libxlu.so > > I actually made the same mistake first time I tried. > > > Ok, so that is working now. I think 'cmdline+=" dom0=pvh > > dom0-iommu=none"' is slightly less tortured syntax, but I guess there is > > no way that this isn't going to be horrible. > > > > As for the general mechanism, how usable is += for anything other than > > cmdline? Most strings in config files can't usefully be extended in > > this matter - if they need changing, they need changing wholesale. > > That's true, but one could imaging some maybe bad example like adding a > suffix to the name of the guest: "name+='-ovmf';". > Going through `man xl.cfg', maybe a good example other than cmdline > could be "cpus+=',^1'" but maybe a space is fine here, or one could use > a list instead. > Other potential uses could be for "PATH", but in this case it would be > better reset the setting rather that attempting to add a suffix to an > existing one. > > I wonder if instead of doing += on all strings, we should instead have > `xl' whitelist the few options where += would make sense. (and at that > point, it would be easy to add a ' ' where is make sense, like > "cmdline"s. But then, how to tell users that it can't do "name+='-new'"? > because xlu would just print a warning, and xl would keep going with > name="". Try "xl create memory+=42" ;-). Not sure I follow. Can you limit this in xl? Isn't += handled in libxlu already? Wei. > > -- > Anthony PERARD ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [livepatch: independ. modules 3/3] python: Add XC binding for Xen build ID
On Thu, Aug 15, 2019 at 09:44:00AM +, Pawel Wieczorkiewicz wrote: > Extend the list of xc() object methods with additional one to display > Xen's buildid. The implementation follows the libxl implementation > (e.g. max buildid size assumption being XC_PAGE_SIZE). > > Signed-off-by: Pawel Wieczorkiewicz > Reviewed-by: Martin Mazein > Reviewed-by: Andra-Irina Paraschiv > Reviewed-by: Norbert Manthey I'm a bit confused by the tag in the subject line. Which series does this patch belong to? Wei. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [livepatch: independ. modules 3/3] python: Add XC binding for Xen build ID
On 16. Aug 2019, at 14:47, Wei Liu mailto:w...@xen.org>> wrote: On Thu, Aug 15, 2019 at 09:44:00AM +, Pawel Wieczorkiewicz wrote: Extend the list of xc() object methods with additional one to display Xen's buildid. The implementation follows the libxl implementation (e.g. max buildid size assumption being XC_PAGE_SIZE). Signed-off-by: Pawel Wieczorkiewicz mailto:wipa...@amazon.de>> Reviewed-by: Martin Mazein mailto:amaz...@amazon.de>> Reviewed-by: Andra-Irina Paraschiv mailto:andra...@amazon.com>> Reviewed-by: Norbert Manthey mailto:nmant...@amazon.de>> I'm a bit confused by the tag in the subject line. Which series does this patch belong to? Wei. Thanks for taking a look. This is the series: https://marc.info/?t=15554198232&r=1&w=4 Best Regards, Pawel Wieczorkiewicz Amazon Development Center Germany GmbH Krausenstr. 38 10117 Berlin Geschaeftsfuehrung: Christian Schlaeger, Ralf Herbrich Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B Sitz: Berlin Ust-ID: DE 289 237 879 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH lp-metadata 3/3] livepatch: Add metadata runtime retrieval mechanism
> On 16. Aug 2019, at 14:44, Wei Liu wrote: > > On Thu, Aug 15, 2019 at 11:27:50AM +, Pawel Wieczorkiewicz wrote: >> Extend the livepatch list operation to fetch also payloads' metadata. >> This is achieved by extending the sysctl list interface with 2 extra >> guest handles: >> * metadata - an array of arbitrary size strings >> * metadata_len - an array of metadata strings' lengths (uin32_t each) …snip... >> Signed-off-by: Pawel Wieczorkiewicz >> Reviewed-by: Andra-Irina Paraschiv >> Reviewed-by: Martin Pohlack >> Reviewed-by: Norbert Manthey >> --- >> tools/libxc/include/xenctrl.h | 22 +++ >> tools/libxc/xc_misc.c | 66 >> +++ >> tools/misc/xen-livepatch.c| 43 ++-- >> xen/common/livepatch.c| 22 +++ >> xen/include/public/sysctl.h | 19 + > > Mostly look good. One comment below... > >> diff --git a/xen/include/public/sysctl.h b/xen/include/public/sysctl.h >> index b86804b7a6..e4c8f4fe63 100644 >> --- a/xen/include/public/sysctl.h >> +++ b/xen/include/public/sysctl.h > > If it hasn't been done for this release already, changing sysctl interface > requires > bumping the version number in this header. > ACK. Will do (also for earlier patches…). > Wei. Best Regards, Pawel Wieczorkiewicz signature.asc Description: Message signed with OpenPGP Amazon Development Center Germany GmbH Krausenstr. 38 10117 Berlin Geschaeftsfuehrung: Christian Schlaeger, Ralf Herbrich Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B Sitz: Berlin Ust-ID: DE 289 237 879 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH lp-metadata 3/3] livepatch: Add metadata runtime retrieval mechanism
On Fri, Aug 16, 2019 at 12:54:12PM +, Wieczorkiewicz, Pawel wrote: > > > On 16. Aug 2019, at 14:44, Wei Liu wrote: > > > > On Thu, Aug 15, 2019 at 11:27:50AM +, Pawel Wieczorkiewicz wrote: > >> Extend the livepatch list operation to fetch also payloads' metadata. > >> This is achieved by extending the sysctl list interface with 2 extra > >> guest handles: > >> * metadata - an array of arbitrary size strings > >> * metadata_len - an array of metadata strings' lengths (uin32_t each) > > …snip... > > >> Signed-off-by: Pawel Wieczorkiewicz > >> Reviewed-by: Andra-Irina Paraschiv > >> Reviewed-by: Martin Pohlack > >> Reviewed-by: Norbert Manthey > >> --- > >> tools/libxc/include/xenctrl.h | 22 +++ > >> tools/libxc/xc_misc.c | 66 > >> +++ > >> tools/misc/xen-livepatch.c| 43 ++-- > >> xen/common/livepatch.c| 22 +++ > >> xen/include/public/sysctl.h | 19 + > > > > Mostly look good. One comment below... > > > >> diff --git a/xen/include/public/sysctl.h b/xen/include/public/sysctl.h > >> index b86804b7a6..e4c8f4fe63 100644 > >> --- a/xen/include/public/sysctl.h > >> +++ b/xen/include/public/sysctl.h > > > > If it hasn't been done for this release already, changing sysctl interface > > requires > > bumping the version number in this header. > > > > ACK. Will do (also for earlier patches…). > We only need to do it once per release. :-) Wei. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [linux-4.19 test] 140173: regressions - FAIL
flight 140173 linux-4.19 real [real] http://logs.test-lab.xenproject.org/osstest/logs/140173/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf-pvops 6 kernel-build fail REGR. vs. 129313 Tests which are failing intermittently (not blocking): test-arm64-arm64-examine 11 examine-serial/bootloader fail in 139883 pass in 140173 test-amd64-i386-qemut-rhel6hvm-amd 12 guest-start/redhat.repeat fail pass in 139883 Tests which did not succeed, but are not blocking: test-armhf-armhf-xl-cubietruck 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-raw 1 build-check(1) blocked n/a test-armhf-armhf-xl-credit2 1 build-check(1) blocked n/a test-armhf-armhf-xl-vhd 1 build-check(1) blocked n/a test-armhf-armhf-xl 1 build-check(1) blocked n/a test-armhf-armhf-examine 1 build-check(1) blocked n/a test-armhf-armhf-libvirt 1 build-check(1) blocked n/a test-armhf-armhf-xl-arndale 1 build-check(1) blocked n/a test-armhf-armhf-xl-credit1 1 build-check(1) blocked n/a test-armhf-armhf-xl-rtds 1 build-check(1) blocked n/a test-armhf-armhf-xl-multivcpu 1 build-check(1) blocked n/a test-amd64-i386-xl-pvshim12 guest-start fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-arm64-arm64-xl 13 migrate-support-checkfail never pass test-arm64-arm64-xl 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit2 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit1 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-checkfail never pass test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass version targeted for testing: linux893af1c79e42e53af0da22165b46eea135af0613 baseline version: linux84df9525b0c27f3ebc2ebb1864fa62a97fdedb7d Last test of basis 129313 2018-11-02 05:39:08 Z 287 days Failing since129412 2018-11-04 14:10:15 Z 284 days 200 attempts Testing same since 139883 2019-08-09 23:10:54 Z6 days9 attempts 2437 people touched revisions under test, not listing them all jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64
Re: [Xen-devel] [PATCH livepatch-python 1/1] livepatch: Add python bindings for livepatch operations
> On 16. Aug 2019, at 14:37, Wei Liu wrote: > > On Thu, Aug 15, 2019 at 11:36:46AM +, Pawel Wieczorkiewicz wrote: >> Extend the XC python bindings library to support also all common >> livepatch operations and actions. >> >> …snip... >> >> Signed-off-by: Pawel Wieczorkiewicz >> Reviewed-by: Martin Mazein >> Reviewed-by: Andra-Irina Paraschiv >> Reviewed-by: Leonard Foerster >> Reviewed-by: Norbert Manthey > > I haven't looked in details, but I'm fine with these new functionalities > in general. Let's see if Marek has any objections. Thanks. > > Which version of Python do you use to build these? The requirement here > is the code should build with both Python 2.5 and Python 3. > Ah, I see. Thanks for pointing this out. We’re planing to upstream the tool using those bindings as well. But, it still requires some work. Let us add the python versions support for the tool. > Wei. Best Regards, Pawel Wieczorkiewicz signature.asc Description: Message signed with OpenPGP Amazon Development Center Germany GmbH Krausenstr. 38 10117 Berlin Geschaeftsfuehrung: Christian Schlaeger, Ralf Herbrich Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B Sitz: Berlin Ust-ID: DE 289 237 879 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] swiotlb-xen cleanups
Hi Xen maintainers and friends, please take a look at this series that cleans up the parts of swiotlb-xen that deal with non-coherent caches. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 02/11] xen/arm: use dev_is_dma_coherent
Use the dma-noncoherent dev_is_dma_coherent helper instead of the home
grown variant.
Signed-off-by: Christoph Hellwig
---
arch/arm/include/asm/dma-mapping.h | 6 --
arch/arm/xen/mm.c| 12 ++--
arch/arm64/include/asm/dma-mapping.h | 9 -
3 files changed, 6 insertions(+), 21 deletions(-)
diff --git a/arch/arm/include/asm/dma-mapping.h
b/arch/arm/include/asm/dma-mapping.h
index dba9355e2484..bdd80ddbca34 100644
--- a/arch/arm/include/asm/dma-mapping.h
+++ b/arch/arm/include/asm/dma-mapping.h
@@ -91,12 +91,6 @@ static inline dma_addr_t virt_to_dma(struct device *dev,
void *addr)
}
#endif
-/* do not use this function in a driver */
-static inline bool is_device_dma_coherent(struct device *dev)
-{
- return dev->archdata.dma_coherent;
-}
-
/**
* arm_dma_alloc - allocate consistent memory for DMA
* @dev: valid struct device pointer, or NULL for ISA and EISA-like devices
diff --git a/arch/arm/xen/mm.c b/arch/arm/xen/mm.c
index d33b77e9add3..90574d89d0d4 100644
--- a/arch/arm/xen/mm.c
+++ b/arch/arm/xen/mm.c
@@ -1,6 +1,6 @@
// SPDX-License-Identifier: GPL-2.0-only
#include
-#include
+#include
#include
#include
#include
@@ -99,7 +99,7 @@ void __xen_dma_map_page(struct device *hwdev, struct page
*page,
dma_addr_t dev_addr, unsigned long offset, size_t size,
enum dma_data_direction dir, unsigned long attrs)
{
- if (is_device_dma_coherent(hwdev))
+ if (dev_is_dma_coherent(hwdev))
return;
if (attrs & DMA_ATTR_SKIP_CPU_SYNC)
return;
@@ -112,7 +112,7 @@ void __xen_dma_unmap_page(struct device *hwdev, dma_addr_t
handle,
unsigned long attrs)
{
- if (is_device_dma_coherent(hwdev))
+ if (dev_is_dma_coherent(hwdev))
return;
if (attrs & DMA_ATTR_SKIP_CPU_SYNC)
return;
@@ -123,7 +123,7 @@ void __xen_dma_unmap_page(struct device *hwdev, dma_addr_t
handle,
void __xen_dma_sync_single_for_cpu(struct device *hwdev,
dma_addr_t handle, size_t size, enum dma_data_direction dir)
{
- if (is_device_dma_coherent(hwdev))
+ if (dev_is_dma_coherent(hwdev))
return;
__xen_dma_page_dev_to_cpu(hwdev, handle, size, dir);
}
@@ -131,7 +131,7 @@ void __xen_dma_sync_single_for_cpu(struct device *hwdev,
void __xen_dma_sync_single_for_device(struct device *hwdev,
dma_addr_t handle, size_t size, enum dma_data_direction dir)
{
- if (is_device_dma_coherent(hwdev))
+ if (dev_is_dma_coherent(hwdev))
return;
__xen_dma_page_cpu_to_dev(hwdev, handle, size, dir);
}
@@ -159,7 +159,7 @@ bool xen_arch_need_swiotlb(struct device *dev,
* memory and we are not able to flush the cache.
*/
return (!hypercall_cflush && (xen_pfn != bfn) &&
- !is_device_dma_coherent(dev));
+ !dev_is_dma_coherent(dev));
}
int xen_create_contiguous_region(phys_addr_t pstart, unsigned int order,
diff --git a/arch/arm64/include/asm/dma-mapping.h
b/arch/arm64/include/asm/dma-mapping.h
index bdcb0922a40c..67243255a858 100644
--- a/arch/arm64/include/asm/dma-mapping.h
+++ b/arch/arm64/include/asm/dma-mapping.h
@@ -18,14 +18,5 @@ static inline const struct dma_map_ops
*get_arch_dma_ops(struct bus_type *bus)
return NULL;
}
-/*
- * Do not use this function in a driver, it is only provided for
- * arch/arm/mm/xen.c, which is used by arm64 as well.
- */
-static inline bool is_device_dma_coherent(struct device *dev)
-{
- return dev->dma_coherent;
-}
-
#endif /* __KERNEL__ */
#endif /* __ASM_DMA_MAPPING_H */
--
2.20.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 03/11] xen/arm: pass one less argument to dma_cache_maint
Instead of taking apart the dma address in both callers do it inside
dma_cache_maint itself.
Signed-off-by: Christoph Hellwig
---
arch/arm/xen/mm.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/arch/arm/xen/mm.c b/arch/arm/xen/mm.c
index 90574d89d0d4..d9da24fda2f7 100644
--- a/arch/arm/xen/mm.c
+++ b/arch/arm/xen/mm.c
@@ -43,13 +43,15 @@ static bool hypercall_cflush = false;
/* functions called by SWIOTLB */
-static void dma_cache_maint(dma_addr_t handle, unsigned long offset,
- size_t size, enum dma_data_direction dir, enum dma_cache_op op)
+static void dma_cache_maint(dma_addr_t handle, size_t size,
+ enum dma_data_direction dir, enum dma_cache_op op)
{
struct gnttab_cache_flush cflush;
unsigned long xen_pfn;
+ unsigned long offset = handle & ~PAGE_MASK;
size_t left = size;
+ offset &= PAGE_MASK;
xen_pfn = (handle >> XEN_PAGE_SHIFT) + offset / XEN_PAGE_SIZE;
offset %= XEN_PAGE_SIZE;
@@ -86,13 +88,13 @@ static void dma_cache_maint(dma_addr_t handle, unsigned
long offset,
static void __xen_dma_page_dev_to_cpu(struct device *hwdev, dma_addr_t handle,
size_t size, enum dma_data_direction dir)
{
- dma_cache_maint(handle & PAGE_MASK, handle & ~PAGE_MASK, size, dir,
DMA_UNMAP);
+ dma_cache_maint(handle, size, dir, DMA_UNMAP);
}
static void __xen_dma_page_cpu_to_dev(struct device *hwdev, dma_addr_t handle,
size_t size, enum dma_data_direction dir)
{
- dma_cache_maint(handle & PAGE_MASK, handle & ~PAGE_MASK, size, dir,
DMA_MAP);
+ dma_cache_maint(handle, size, dir, DMA_MAP);
}
void __xen_dma_map_page(struct device *hwdev, struct page *page,
--
2.20.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 10/11] swiotlb-xen: merge xen_unmap_single into xen_swiotlb_unmap_page
No need for a no-op wrapper.
Signed-off-by: Christoph Hellwig
---
drivers/xen/swiotlb-xen.c | 15 ---
1 file changed, 4 insertions(+), 11 deletions(-)
diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index c3c383033ae4..b6b9c4c1b397 100644
--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -414,9 +414,8 @@ static dma_addr_t xen_swiotlb_map_page(struct device *dev,
struct page *page,
* After this call, reads by the cpu to the buffer are guaranteed to see
* whatever the device wrote there.
*/
-static void xen_unmap_single(struct device *hwdev, dma_addr_t dev_addr,
-size_t size, enum dma_data_direction dir,
-unsigned long attrs)
+static void xen_swiotlb_unmap_page(struct device *hwdev, dma_addr_t dev_addr,
+ size_t size, enum dma_data_direction dir, unsigned long attrs)
{
phys_addr_t paddr = xen_bus_to_phys(dev_addr);
@@ -430,13 +429,6 @@ static void xen_unmap_single(struct device *hwdev,
dma_addr_t dev_addr,
swiotlb_tbl_unmap_single(hwdev, paddr, size, dir, attrs);
}
-static void xen_swiotlb_unmap_page(struct device *hwdev, dma_addr_t dev_addr,
- size_t size, enum dma_data_direction dir,
- unsigned long attrs)
-{
- xen_unmap_single(hwdev, dev_addr, size, dir, attrs);
-}
-
static void
xen_swiotlb_sync_single_for_cpu(struct device *dev, dma_addr_t dma_addr,
size_t size, enum dma_data_direction dir)
@@ -477,7 +469,8 @@ xen_swiotlb_unmap_sg(struct device *hwdev, struct
scatterlist *sgl, int nelems,
BUG_ON(dir == DMA_NONE);
for_each_sg(sgl, sg, nelems, i)
- xen_unmap_single(hwdev, sg->dma_address, sg_dma_len(sg), dir,
attrs);
+ xen_swiotlb_unmap_page(hwdev, sg->dma_address, sg_dma_len(sg),
+ dir, attrs);
}
--
2.20.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 01/11] xen/arm: use dma-noncoherent.h calls for xen-swiotlb cache maintainance
Reuse the arm64 code that uses the dma-direct/swiotlb helpers for DMA
non-coherent devices.
Signed-off-by: Christoph Hellwig
---
arch/arm/Kconfig | 4 +
arch/arm/include/asm/device.h | 3 -
arch/arm/include/asm/xen/page-coherent.h | 93 --
arch/arm/mm/Kconfig| 4 -
arch/arm/mm/dma-mapping.c | 8 +-
arch/arm64/include/asm/xen/page-coherent.h | 75 -
drivers/xen/swiotlb-xen.c | 49 +---
include/xen/arm/page-coherent.h| 71 +
8 files changed, 78 insertions(+), 229 deletions(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 33b00579beff..24360211534a 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -7,6 +7,8 @@ config ARM
select ARCH_HAS_BINFMT_FLAT
select ARCH_HAS_DEBUG_VIRTUAL if MMU
select ARCH_HAS_DEVMEM_IS_ALLOWED
+ select ARCH_HAS_DMA_COHERENT_TO_PFN if SWIOTLB
+ select ARCH_HAS_DMA_MMAP_PGPROT if SWIOTLB
select ARCH_HAS_ELF_RANDOMIZE
select ARCH_HAS_FORTIFY_SOURCE
select ARCH_HAS_KEEPINITRD
@@ -18,6 +20,8 @@ config ARM
select ARCH_HAS_SET_MEMORY
select ARCH_HAS_STRICT_KERNEL_RWX if MMU && !XIP_KERNEL
select ARCH_HAS_STRICT_MODULE_RWX if MMU
+ select ARCH_HAS_SYNC_DMA_FOR_DEVICE if SWIOTLB
+ select ARCH_HAS_SYNC_DMA_FOR_CPU if SWIOTLB
select ARCH_HAS_TEARDOWN_DMA_OPS if MMU
select ARCH_HAS_TICK_BROADCAST if GENERIC_CLOCKEVENTS_BROADCAST
select ARCH_HAVE_CUSTOM_GPIO_H
diff --git a/arch/arm/include/asm/device.h b/arch/arm/include/asm/device.h
index f6955b55c544..c675bc0d5aa8 100644
--- a/arch/arm/include/asm/device.h
+++ b/arch/arm/include/asm/device.h
@@ -14,9 +14,6 @@ struct dev_archdata {
#endif
#ifdef CONFIG_ARM_DMA_USE_IOMMU
struct dma_iommu_mapping*mapping;
-#endif
-#ifdef CONFIG_XEN
- const struct dma_map_ops *dev_dma_ops;
#endif
unsigned int dma_coherent:1;
unsigned int dma_ops_setup:1;
diff --git a/arch/arm/include/asm/xen/page-coherent.h
b/arch/arm/include/asm/xen/page-coherent.h
index 2c403e7c782d..27e984977402 100644
--- a/arch/arm/include/asm/xen/page-coherent.h
+++ b/arch/arm/include/asm/xen/page-coherent.h
@@ -1,95 +1,2 @@
/* SPDX-License-Identifier: GPL-2.0 */
-#ifndef _ASM_ARM_XEN_PAGE_COHERENT_H
-#define _ASM_ARM_XEN_PAGE_COHERENT_H
-
-#include
-#include
#include
-
-static inline const struct dma_map_ops *xen_get_dma_ops(struct device *dev)
-{
- if (dev && dev->archdata.dev_dma_ops)
- return dev->archdata.dev_dma_ops;
- return get_arch_dma_ops(NULL);
-}
-
-static inline void *xen_alloc_coherent_pages(struct device *hwdev, size_t size,
- dma_addr_t *dma_handle, gfp_t flags, unsigned long attrs)
-{
- return xen_get_dma_ops(hwdev)->alloc(hwdev, size, dma_handle, flags,
attrs);
-}
-
-static inline void xen_free_coherent_pages(struct device *hwdev, size_t size,
- void *cpu_addr, dma_addr_t dma_handle, unsigned long attrs)
-{
- xen_get_dma_ops(hwdev)->free(hwdev, size, cpu_addr, dma_handle, attrs);
-}
-
-static inline void xen_dma_map_page(struct device *hwdev, struct page *page,
-dma_addr_t dev_addr, unsigned long offset, size_t size,
-enum dma_data_direction dir, unsigned long attrs)
-{
- unsigned long page_pfn = page_to_xen_pfn(page);
- unsigned long dev_pfn = XEN_PFN_DOWN(dev_addr);
- unsigned long compound_pages =
- (1unmap_page)
- xen_get_dma_ops(hwdev)->unmap_page(hwdev, handle, size,
dir, attrs);
- } else
- __xen_dma_unmap_page(hwdev, handle, size, dir, attrs);
-}
-
-static inline void xen_dma_sync_single_for_cpu(struct device *hwdev,
- dma_addr_t handle, size_t size, enum dma_data_direction dir)
-{
- unsigned long pfn = PFN_DOWN(handle);
- if (pfn_valid(pfn)) {
- if (xen_get_dma_ops(hwdev)->sync_single_for_cpu)
- xen_get_dma_ops(hwdev)->sync_single_for_cp
[Xen-devel] [PATCH 04/11] xen/arm: remove xen_dma_ops
arm and arm64 can just use xen_swiotlb_dma_ops directly like x86, no
need for a pointer indirection.
Signed-off-by: Christoph Hellwig
---
arch/arm/mm/dma-mapping.c| 3 ++-
arch/arm/xen/mm.c| 4
arch/arm64/mm/dma-mapping.c | 3 ++-
include/xen/arm/hypervisor.h | 2 --
4 files changed, 4 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index 738097396445..2661cad36359 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -35,6 +35,7 @@
#include
#include
#include
+#include
#include "dma.h"
#include "mm.h"
@@ -2360,7 +2361,7 @@ void arch_setup_dma_ops(struct device *dev, u64 dma_base,
u64 size,
#ifdef CONFIG_XEN
if (xen_initial_domain())
- dev->dma_ops = xen_dma_ops;
+ dev->dma_ops = &xen_swiotlb_dma_ops;
#endif
dev->archdata.dma_ops_setup = true;
}
diff --git a/arch/arm/xen/mm.c b/arch/arm/xen/mm.c
index d9da24fda2f7..388a45002bad 100644
--- a/arch/arm/xen/mm.c
+++ b/arch/arm/xen/mm.c
@@ -183,16 +183,12 @@ void xen_destroy_contiguous_region(phys_addr_t pstart,
unsigned int order)
}
EXPORT_SYMBOL_GPL(xen_destroy_contiguous_region);
-const struct dma_map_ops *xen_dma_ops;
-EXPORT_SYMBOL(xen_dma_ops);
-
int __init xen_mm_init(void)
{
struct gnttab_cache_flush cflush;
if (!xen_initial_domain())
return 0;
xen_swiotlb_init(1, false);
- xen_dma_ops = &xen_swiotlb_dma_ops;
cflush.op = 0;
cflush.a.dev_bus_addr = 0;
diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c
index bd2b039f43a6..4b244a037349 100644
--- a/arch/arm64/mm/dma-mapping.c
+++ b/arch/arm64/mm/dma-mapping.c
@@ -8,6 +8,7 @@
#include
#include
#include
+#include
#include
@@ -64,6 +65,6 @@ void arch_setup_dma_ops(struct device *dev, u64 dma_base, u64
size,
#ifdef CONFIG_XEN
if (xen_initial_domain())
- dev->dma_ops = xen_dma_ops;
+ dev->dma_ops = &xen_swiotlb_dma_ops;
#endif
}
diff --git a/include/xen/arm/hypervisor.h b/include/xen/arm/hypervisor.h
index 2982571f7cc1..43ef24dd030e 100644
--- a/include/xen/arm/hypervisor.h
+++ b/include/xen/arm/hypervisor.h
@@ -19,8 +19,6 @@ static inline enum paravirt_lazy_mode
paravirt_get_lazy_mode(void)
return PARAVIRT_LAZY_NONE;
}
-extern const struct dma_map_ops *xen_dma_ops;
-
#ifdef CONFIG_XEN
void __init xen_early_init(void);
#else
--
2.20.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 08/11] swiotlb-xen: use the same foreign page check everywhere
xen_dma_map_page uses a different and more complicated check for
foreign pages than the other three cache maintainance helpers.
Switch it to the simpler pfn_vali method a well.
Signed-off-by: Christoph Hellwig
---
include/xen/page-coherent.h | 9 ++---
1 file changed, 2 insertions(+), 7 deletions(-)
diff --git a/include/xen/page-coherent.h b/include/xen/page-coherent.h
index 7c32944de051..0f4d468e7a89 100644
--- a/include/xen/page-coherent.h
+++ b/include/xen/page-coherent.h
@@ -43,14 +43,9 @@ static inline void xen_dma_map_page(struct device *hwdev,
struct page *page,
dma_addr_t dev_addr, unsigned long offset, size_t size,
enum dma_data_direction dir, unsigned long attrs)
{
- unsigned long page_pfn = page_to_xen_pfn(page);
- unsigned long dev_pfn = XEN_PFN_DOWN(dev_addr);
- unsigned long compound_pages =
- (1
[Xen-devel] [PATCH 06/11] swiotlb-xen: always use dma-direct helpers to alloc coherent pages
x86 currently calls alloc_pages, but using dma-direct works as well
there, with the added benefit of using the CMA pool if available.
The biggest advantage is of course to remove a pointless bit of
architecture specific code.
Signed-off-by: Christoph Hellwig
---
arch/x86/include/asm/xen/page-coherent.h | 16
drivers/xen/swiotlb-xen.c| 7 +++
include/xen/arm/page-coherent.h | 12
3 files changed, 3 insertions(+), 32 deletions(-)
diff --git a/arch/x86/include/asm/xen/page-coherent.h
b/arch/x86/include/asm/xen/page-coherent.h
index 116777e7f387..8ee33c5edded 100644
--- a/arch/x86/include/asm/xen/page-coherent.h
+++ b/arch/x86/include/asm/xen/page-coherent.h
@@ -5,22 +5,6 @@
#include
#include
-static inline void *xen_alloc_coherent_pages(struct device *hwdev, size_t size,
- dma_addr_t *dma_handle, gfp_t flags,
- unsigned long attrs)
-{
- void *vstart = (void*)__get_free_pages(flags, get_order(size));
- *dma_handle = virt_to_phys(vstart);
- return vstart;
-}
-
-static inline void xen_free_coherent_pages(struct device *hwdev, size_t size,
- void *cpu_addr, dma_addr_t dma_handle,
- unsigned long attrs)
-{
- free_pages((unsigned long) cpu_addr, get_order(size));
-}
-
static inline void xen_dma_map_page(struct device *hwdev, struct page *page,
dma_addr_t dev_addr, unsigned long offset, size_t size,
enum dma_data_direction dir, unsigned long attrs) { }
diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index b8808677ae1d..f9dd4cb6e4b3 100644
--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -299,8 +299,7 @@ xen_swiotlb_alloc_coherent(struct device *hwdev, size_t
size,
* address. In fact on ARM virt_to_phys only works for kernel direct
* mapped RAM memory. Also see comment below.
*/
- ret = xen_alloc_coherent_pages(hwdev, size, dma_handle, flags, attrs);
-
+ ret = dma_direct_alloc(hwdev, size, dma_handle, flags, attrs);
if (!ret)
return ret;
@@ -319,7 +318,7 @@ xen_swiotlb_alloc_coherent(struct device *hwdev, size_t
size,
else {
if (xen_create_contiguous_region(phys, order,
fls64(dma_mask), dma_handle)
!= 0) {
- xen_free_coherent_pages(hwdev, size, ret,
(dma_addr_t)phys, attrs);
+ dma_direct_free(hwdev, size, ret, (dma_addr_t)phys,
attrs);
return NULL;
}
SetPageXenRemapped(virt_to_page(ret));
@@ -351,7 +350,7 @@ xen_swiotlb_free_coherent(struct device *hwdev, size_t
size, void *vaddr,
TestClearPageXenRemapped(virt_to_page(vaddr)))
xen_destroy_contiguous_region(phys, order);
- xen_free_coherent_pages(hwdev, size, vaddr, (dma_addr_t)phys, attrs);
+ dma_direct_free(hwdev, size, vaddr, (dma_addr_t)phys, attrs);
}
/*
diff --git a/include/xen/arm/page-coherent.h b/include/xen/arm/page-coherent.h
index da2cc09c8eda..4294a31305ca 100644
--- a/include/xen/arm/page-coherent.h
+++ b/include/xen/arm/page-coherent.h
@@ -16,18 +16,6 @@ void __xen_dma_sync_single_for_cpu(struct device *hwdev,
void __xen_dma_sync_single_for_device(struct device *hwdev,
dma_addr_t handle, size_t size, enum dma_data_direction dir);
-static inline void *xen_alloc_coherent_pages(struct device *hwdev, size_t size,
- dma_addr_t *dma_handle, gfp_t flags, unsigned long attrs)
-{
- return dma_direct_alloc(hwdev, size, dma_handle, flags, attrs);
-}
-
-static inline void xen_free_coherent_pages(struct device *hwdev, size_t size,
- void *cpu_addr, dma_addr_t dma_handle, unsigned long attrs)
-{
- dma_direct_free(hwdev, size, cpu_addr, dma_handle, attrs);
-}
-
static inline void xen_dma_sync_single_for_cpu(struct device *hwdev,
dma_addr_t handle, size_t size, enum dma_data_direction dir)
{
--
2.20.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 07/11] swiotlb-xen: provide a single page-coherent.h header
Merge the various page-coherent.h files into a single one that either
provides prototypes or stubs depending on the need for cache
maintainance.
For extra benefits alo include in the file
actually implementing the interfaces provided.
Signed-off-by: Christoph Hellwig
---
arch/arm/include/asm/xen/page-coherent.h | 2 --
arch/arm/xen/mm.c | 1 +
arch/arm64/include/asm/xen/page-coherent.h | 2 --
arch/x86/include/asm/xen/page-coherent.h | 22 --
drivers/xen/swiotlb-xen.c | 4 +---
include/Kbuild | 2 +-
include/xen/{arm => }/page-coherent.h | 27 +++---
7 files changed, 27 insertions(+), 33 deletions(-)
delete mode 100644 arch/arm/include/asm/xen/page-coherent.h
delete mode 100644 arch/arm64/include/asm/xen/page-coherent.h
delete mode 100644 arch/x86/include/asm/xen/page-coherent.h
rename include/xen/{arm => }/page-coherent.h (76%)
diff --git a/arch/arm/include/asm/xen/page-coherent.h
b/arch/arm/include/asm/xen/page-coherent.h
deleted file mode 100644
index 27e984977402..
--- a/arch/arm/include/asm/xen/page-coherent.h
+++ /dev/null
@@ -1,2 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0 */
-#include
diff --git a/arch/arm/xen/mm.c b/arch/arm/xen/mm.c
index a59980f1aa54..85482cdda1e5 100644
--- a/arch/arm/xen/mm.c
+++ b/arch/arm/xen/mm.c
@@ -15,6 +15,7 @@
#include
#include
#include
+#include
#include
#include
diff --git a/arch/arm64/include/asm/xen/page-coherent.h
b/arch/arm64/include/asm/xen/page-coherent.h
deleted file mode 100644
index 27e984977402..
--- a/arch/arm64/include/asm/xen/page-coherent.h
+++ /dev/null
@@ -1,2 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0 */
-#include
diff --git a/arch/x86/include/asm/xen/page-coherent.h
b/arch/x86/include/asm/xen/page-coherent.h
deleted file mode 100644
index 8ee33c5edded..
--- a/arch/x86/include/asm/xen/page-coherent.h
+++ /dev/null
@@ -1,22 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0 */
-#ifndef _ASM_X86_XEN_PAGE_COHERENT_H
-#define _ASM_X86_XEN_PAGE_COHERENT_H
-
-#include
-#include
-
-static inline void xen_dma_map_page(struct device *hwdev, struct page *page,
-dma_addr_t dev_addr, unsigned long offset, size_t size,
-enum dma_data_direction dir, unsigned long attrs) { }
-
-static inline void xen_dma_unmap_page(struct device *hwdev, dma_addr_t handle,
- size_t size, enum dma_data_direction dir,
- unsigned long attrs) { }
-
-static inline void xen_dma_sync_single_for_cpu(struct device *hwdev,
- dma_addr_t handle, size_t size, enum dma_data_direction dir) { }
-
-static inline void xen_dma_sync_single_for_device(struct device *hwdev,
- dma_addr_t handle, size_t size, enum dma_data_direction dir) { }
-
-#endif /* _ASM_X86_XEN_PAGE_COHERENT_H */
diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index f9dd4cb6e4b3..7b23929854e7 100644
--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -31,12 +31,10 @@
#include
#include
#include
+#include
#include
#include
-#include
-#include
-
#include
/*
* Used to do a quick range check in swiotlb_tbl_unmap_single and
diff --git a/include/Kbuild b/include/Kbuild
index c38f0d46b267..e2ae52ef9e1e 100644
--- a/include/Kbuild
+++ b/include/Kbuild
@@ -1189,7 +1189,6 @@ header-test- += video/vga.h
header-test- += video/w100fb.h
header-test- += xen/acpi.h
header-test- += xen/arm/hypercall.h
-header-test- += xen/arm/page-coherent.h
header-test- += xen/arm/page.h
header-test- += xen/balloon.h
header-test- += xen/events.h
@@ -1231,6 +1230,7 @@ header-test- += xen/interface/xen.h
header-test- += xen/interface/xenpmu.h
header-test- += xen/mem-reservation.h
header-test- += xen/page.h
+header-test- += xen/page-coherent.h
header-test- += xen/platform_pci.h
header-test- += xen/swiotlb-xen.h
header-test- += xen/xen-front-pgdir-shbuf.h
diff --git a/include/xen/arm/page-coherent.h b/include/xen/page-coherent.h
similarity index 76%
rename from include/xen/arm/page-coherent.h
rename to include/xen/page-coherent.h
index 4294a31305ca..7c32944de051 100644
--- a/include/xen/arm/page-coherent.h
+++ b/include/xen/page-coherent.h
@@ -1,10 +1,12 @@
/* SPDX-License-Identifier: GPL-2.0 */
-#ifndef _XEN_ARM_PAGE_COHERENT_H
-#define _XEN_ARM_PAGE_COHERENT_H
+#ifndef _XEN_PAGE_COHERENT_H
+#define _XEN_PAGE_COHERENT_H
#include
#include
+#if defined(CONFIG_ARCH_HAS_SYNC_DMA_FOR_DEVICE) || \
+defined(CONFIG_ARCH_HAS_SYNC_DMA_FOR_CPU)
void __xen_dma_map_page(struct device *hwdev, struct page *page,
dma_addr_t dev_addr, unsigned long offse
[Xen-devel] [PATCH 05/11] xen: remove the exports for xen_{create, destroy}_contiguous_region
These routines are only used by swiotlb-xen, which cannot be modular.
Signed-off-by: Christoph Hellwig
---
arch/arm/xen/mm.c | 2 --
arch/x86/xen/mmu_pv.c | 2 --
2 files changed, 4 deletions(-)
diff --git a/arch/arm/xen/mm.c b/arch/arm/xen/mm.c
index 388a45002bad..a59980f1aa54 100644
--- a/arch/arm/xen/mm.c
+++ b/arch/arm/xen/mm.c
@@ -175,13 +175,11 @@ int xen_create_contiguous_region(phys_addr_t pstart,
unsigned int order,
*dma_handle = pstart;
return 0;
}
-EXPORT_SYMBOL_GPL(xen_create_contiguous_region);
void xen_destroy_contiguous_region(phys_addr_t pstart, unsigned int order)
{
return;
}
-EXPORT_SYMBOL_GPL(xen_destroy_contiguous_region);
int __init xen_mm_init(void)
{
diff --git a/arch/x86/xen/mmu_pv.c b/arch/x86/xen/mmu_pv.c
index 26e8b326966d..c8dbee62ec2a 100644
--- a/arch/x86/xen/mmu_pv.c
+++ b/arch/x86/xen/mmu_pv.c
@@ -2625,7 +2625,6 @@ int xen_create_contiguous_region(phys_addr_t pstart,
unsigned int order,
*dma_handle = virt_to_machine(vstart).maddr;
return success ? 0 : -ENOMEM;
}
-EXPORT_SYMBOL_GPL(xen_create_contiguous_region);
void xen_destroy_contiguous_region(phys_addr_t pstart, unsigned int order)
{
@@ -2660,7 +2659,6 @@ void xen_destroy_contiguous_region(phys_addr_t pstart,
unsigned int order)
spin_unlock_irqrestore(&xen_reservation_lock, flags);
}
-EXPORT_SYMBOL_GPL(xen_destroy_contiguous_region);
static noinline void xen_flush_tlb_all(void)
{
--
2.20.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 09/11] swiotlb-xen: simplify cache maintainance
Now that we know we always have the dma-noncoherent.h helpers available
if we are on an architecture with support for non-coherent devices,
we can just call them directly, and remove the calls to the dma-direct
routines, including the fact that we call the dma_direct_map_page
routines but ignore the value returned from it. Instead we now have
Xen wrappers for the arch_sync_dma_for_{device,cpu} helpers that call
the special Xen versions of those routines for foreign pages.
Signed-off-by: Christoph Hellwig
---
arch/arm/xen/mm.c | 47 ++---
drivers/xen/swiotlb-xen.c | 19 ---
include/xen/page-coherent.h | 100 +++-
3 files changed, 42 insertions(+), 124 deletions(-)
diff --git a/arch/arm/xen/mm.c b/arch/arm/xen/mm.c
index 85482cdda1e5..0eb88f1355c2 100644
--- a/arch/arm/xen/mm.c
+++ b/arch/arm/xen/mm.c
@@ -86,59 +86,18 @@ static void dma_cache_maint(dma_addr_t handle, size_t size,
} while (left);
}
-static void __xen_dma_page_dev_to_cpu(struct device *hwdev, dma_addr_t handle,
- size_t size, enum dma_data_direction dir)
+void __xen_dma_sync_for_cpu(struct device *dev, dma_addr_t handle, size_t size,
+ enum dma_data_direction dir)
{
dma_cache_maint(handle, size, dir, DMA_UNMAP);
}
-static void __xen_dma_page_cpu_to_dev(struct device *hwdev, dma_addr_t handle,
+void __xen_dma_sync_for_device(struct device *dev, dma_addr_t handle,
size_t size, enum dma_data_direction dir)
{
dma_cache_maint(handle, size, dir, DMA_MAP);
}
-void __xen_dma_map_page(struct device *hwdev, struct page *page,
-dma_addr_t dev_addr, unsigned long offset, size_t size,
-enum dma_data_direction dir, unsigned long attrs)
-{
- if (dev_is_dma_coherent(hwdev))
- return;
- if (attrs & DMA_ATTR_SKIP_CPU_SYNC)
- return;
-
- __xen_dma_page_cpu_to_dev(hwdev, dev_addr, size, dir);
-}
-
-void __xen_dma_unmap_page(struct device *hwdev, dma_addr_t handle,
- size_t size, enum dma_data_direction dir,
- unsigned long attrs)
-
-{
- if (dev_is_dma_coherent(hwdev))
- return;
- if (attrs & DMA_ATTR_SKIP_CPU_SYNC)
- return;
-
- __xen_dma_page_dev_to_cpu(hwdev, handle, size, dir);
-}
-
-void __xen_dma_sync_single_for_cpu(struct device *hwdev,
- dma_addr_t handle, size_t size, enum dma_data_direction dir)
-{
- if (dev_is_dma_coherent(hwdev))
- return;
- __xen_dma_page_dev_to_cpu(hwdev, handle, size, dir);
-}
-
-void __xen_dma_sync_single_for_device(struct device *hwdev,
- dma_addr_t handle, size_t size, enum dma_data_direction dir)
-{
- if (dev_is_dma_coherent(hwdev))
- return;
- __xen_dma_page_cpu_to_dev(hwdev, handle, size, dir);
-}
-
bool xen_arch_need_swiotlb(struct device *dev,
phys_addr_t phys,
dma_addr_t dev_addr)
diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index 7b23929854e7..c3c383033ae4 100644
--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -388,6 +388,7 @@ static dma_addr_t xen_swiotlb_map_page(struct device *dev,
struct page *page,
if (map == (phys_addr_t)DMA_MAPPING_ERROR)
return DMA_MAPPING_ERROR;
+ phys = map;
dev_addr = xen_phys_to_bus(map);
/*
@@ -399,14 +400,9 @@ static dma_addr_t xen_swiotlb_map_page(struct device *dev,
struct page *page,
return DMA_MAPPING_ERROR;
}
- page = pfn_to_page(map >> PAGE_SHIFT);
- offset = map & ~PAGE_MASK;
done:
- /*
-* we are not interested in the dma_addr returned by xen_dma_map_page,
-* only in the potential cache flushes executed by the function.
-*/
- xen_dma_map_page(dev, page, dev_addr, offset, size, dir, attrs);
+ if (!dev_is_dma_coherent(dev) && !(attrs & DMA_ATTR_SKIP_CPU_SYNC))
+ xen_dma_sync_for_device(dev, dev_addr, phys, size, dir);
return dev_addr;
}
@@ -426,7 +422,8 @@ static void xen_unmap_single(struct device *hwdev,
dma_addr_t dev_addr,
BUG_ON(dir == DMA_NONE);
- xen_dma_unmap_page(hwdev, dev_addr, size, dir, attrs);
+ if (!dev_is_dma_coherent(hwdev) && !(attrs & DMA_ATTR_SKIP_CPU_SYNC))
+ xen_dma_sync_for_cpu(hwdev, dev_addr, paddr, size, dir);
/* NOTE: We use dev_addr here, not paddr! */
if (is_xen_swiotlb_buffer(dev_addr))
@@ -446,7 +443,8 @@ xen_swiotlb_sync_single_for_cpu(struct device *dev,
dma_addr_t dma_addr,
{
phys_addr_t paddr = xen_bus_to_phys(dma_addr);
- xen_dma_sync_single_for_cpu(dev, dma_addr, size, dir);
+ if (!dev_is_dma_coherent(dev))
+ xen_dma_sync_for_cpu(dev, dma_addr, paddr, size, dir);
if (is_xen_swiotlb_buffer(dma_addr))
swiotlb_tbl_sync_sing
[Xen-devel] [PATCH 11/11] arm64: use asm-generic/dma-mapping.h
Now that the Xen special cases are gone nothing worth mentioning is
left in the arm64 file, so switch to use the
asm-generic version instead.
Signed-off-by: Christoph Hellwig
---
arch/arm64/include/asm/Kbuild| 1 +
arch/arm64/include/asm/dma-mapping.h | 22 --
arch/arm64/mm/dma-mapping.c | 1 +
3 files changed, 2 insertions(+), 22 deletions(-)
delete mode 100644 arch/arm64/include/asm/dma-mapping.h
diff --git a/arch/arm64/include/asm/Kbuild b/arch/arm64/include/asm/Kbuild
index c52e151afab0..98a5405c8558 100644
--- a/arch/arm64/include/asm/Kbuild
+++ b/arch/arm64/include/asm/Kbuild
@@ -4,6 +4,7 @@ generic-y += delay.h
generic-y += div64.h
generic-y += dma.h
generic-y += dma-contiguous.h
+generic-y += dma-mapping.h
generic-y += early_ioremap.h
generic-y += emergency-restart.h
generic-y += hw_irq.h
diff --git a/arch/arm64/include/asm/dma-mapping.h
b/arch/arm64/include/asm/dma-mapping.h
deleted file mode 100644
index 67243255a858..
--- a/arch/arm64/include/asm/dma-mapping.h
+++ /dev/null
@@ -1,22 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0-only */
-/*
- * Copyright (C) 2012 ARM Ltd.
- */
-#ifndef __ASM_DMA_MAPPING_H
-#define __ASM_DMA_MAPPING_H
-
-#ifdef __KERNEL__
-
-#include
-#include
-
-#include
-#include
-
-static inline const struct dma_map_ops *get_arch_dma_ops(struct bus_type *bus)
-{
- return NULL;
-}
-
-#endif /* __KERNEL__ */
-#endif /* __ASM_DMA_MAPPING_H */
diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c
index 4b244a037349..6578abcfbbc7 100644
--- a/arch/arm64/mm/dma-mapping.c
+++ b/arch/arm64/mm/dma-mapping.c
@@ -8,6 +8,7 @@
#include
#include
#include
+#include
#include
#include
--
2.20.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [libvirt test] 140186: regressions - FAIL
flight 140186 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/140186/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 139829 build-i386-libvirt6 libvirt-buildfail REGR. vs. 139829 build-arm64-libvirt 6 libvirt-buildfail REGR. vs. 139829 build-armhf-libvirt 6 libvirt-buildfail REGR. vs. 139829 Tests which did not succeed, but are not blocking: test-arm64-arm64-libvirt-qcow2 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-pair 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-raw 1 build-check(1) blocked n/a test-amd64-i386-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-i386-libvirt-pair 1 build-check(1) blocked n/a test-amd64-i386-libvirt 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-vhd 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-armhf-armhf-libvirt 1 build-check(1) blocked n/a test-arm64-arm64-libvirt 1 build-check(1) blocked n/a version targeted for testing: libvirt 49520e9e7d1c8e309ca71ccc49811fcfc1f26bb7 baseline version: libvirt 086764748e1a6b9aaf968db68145e05837eae3bd Last test of basis 139829 2019-08-08 04:19:02 Z8 days Failing since139853 2019-08-09 04:24:11 Z7 days8 attempts Testing same since 140186 2019-08-16 04:19:11 Z0 days1 attempts People who touched revisions under test: Andrea Bolognani Daniel Henrique Barboza Daniel P. Berrangé Eric Blake Han Han Ilias Stamatis Jiri Denemark Ján Tomko Laine Stump Marc-André Lureau Maxiwell S. Garcia Menno Lageman Michal Privoznik Paolo Bonzini Peter Krempa Roman Bolshakov Wim ten Have jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt fail build-arm64-libvirt fail build-armhf-libvirt fail build-i386-libvirt fail build-amd64-pvopspass build-arm64-pvopspass build-armhf-pvopspass build-i386-pvops pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm blocked test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmblocked test-amd64-amd64-libvirt-xsm blocked test-arm64-arm64-libvirt-xsm blocked test-amd64-i386-libvirt-xsm blocked test-amd64-amd64-libvirt blocked test-arm64-arm64-libvirt blocked test-armhf-armhf-libvirt blocked test-amd64-i386-libvirt blocked test-amd64-amd64-libvirt-pairblocked test-amd64-i386-libvirt-pair blocked test-arm64-arm64-libvirt-qcow2 blocked test-armhf-armhf-libvirt-raw blocked test-amd64-amd64-libvirt-vhd blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be fo
Re: [Xen-devel] [PATCH] libxlu: Handle += in config files
On Fri, Aug 16, 2019 at 12:47:07PM +, Wei Liu wrote: > On Tue, Aug 13, 2019 at 05:42:15PM +0100, Anthony PERARD wrote: > > On Tue, Aug 13, 2019 at 04:47:23PM +0100, Andrew Cooper wrote: > > > Error between user and terminal. :) > > > > > > I'd sync'd xl and libxl.so, but not libxlu.so > > > > I actually made the same mistake first time I tried. > > > > > Ok, so that is working now. I think 'cmdline+=" dom0=pvh > > > dom0-iommu=none"' is slightly less tortured syntax, but I guess there is > > > no way that this isn't going to be horrible. > > > > > > As for the general mechanism, how usable is += for anything other than > > > cmdline? Most strings in config files can't usefully be extended in > > > this matter - if they need changing, they need changing wholesale. > > > > That's true, but one could imaging some maybe bad example like adding a > > suffix to the name of the guest: "name+='-ovmf';". > > Going through `man xl.cfg', maybe a good example other than cmdline > > could be "cpus+=',^1'" but maybe a space is fine here, or one could use > > a list instead. > > Other potential uses could be for "PATH", but in this case it would be > > better reset the setting rather that attempting to add a suffix to an > > existing one. > > > > I wonder if instead of doing += on all strings, we should instead have > > `xl' whitelist the few options where += would make sense. (and at that > > point, it would be easy to add a ' ' where is make sense, like > > "cmdline"s. But then, how to tell users that it can't do "name+='-new'"? > > because xlu would just print a warning, and xl would keep going with > > name="". Try "xl create memory+=42" ;-). > > Not sure I follow. Can you limit this in xl? With a patch to xl, yes ;-). What could be done is to add a new API in libxlu. The original function get_string() could return an error if += was used on a specific setting. A new function get_appended_string() (working title), could return return a string with the += computation done. That way, xl can choose which setting are allowed to have += used (and it could even use how to do it, i.e. add spaces between strings or not). > Isn't += handled in libxlu already? It's not, this patch adds the capability into libxlu. Cheers, -- Anthony PERARD ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] get_maintainers.pl: Enable running the script on unikraft repos
On 16/08/2019 12:41, Lars Kurth wrote:
Hi Julien,
Hi Lars,
On 16/08/2019, 11:55, "Julien Grall" wrote:
Hi Lars,
On 16/08/2019 11:42, Lars Kurth wrote:
> Unikraft repos follow the same syntax as xen.git with the
> following exceptions:
> * MAINTAINERS files are called MAINTAINERS.md
> * M: ... etc blocks are preceded by whitespaces for rendering as
>markup files
There is an other difference. The "fallback" category is "UNIKRAFT GENERAL" and
not "THE REST".
That is right. But currently get_maintainers.pl: totally ignores the headlines.
It just reads
M: ...
R: ...
Etc.
Not really, get_maintainer_role() will return the headline. This is for instance
used to avoid CC "THE REST" when there are other maintainers:
# Check the role, if it is not "THE REST" then the file is not
# only maintained by "THE REST".
if ( get_maintainer_role($line) ne "supporter:THE REST" ) {
$file_maintained_by_the_rest = 0;
}
From my understanding "UNIKRAFT GENERAL" behaves exactly the same way.
The roles can also be printed with the option --roles.
What is different is that "UNIKRAFT GENERAL" does not contain
F: entries, which have to be added, otherwise no e-mail addresses
from the section are added. So I was going to send a patch to fix this.
> This change will
> - load MAINTAINERS.md if MAINTAINERS is not present
> - deal with indented M: ... blocks
One process question. Does it mean Unikraft folks will have to checkout Xen in
order to use {add, get}_maintainers.pl? If so, would it make sense to have
add_maintainers.pl and script_maintainers.pl in a separate repo that can be
added as submodule?
The way how the code is written they would either have to check out the
repo or just get the two scripts and put them in the same directory somewhere
on the path.
For things like mini-os, xtf, osstest, ... you would always have a xen.git
somewhere
In the unikraft case that is different. We could break it out, but maybe we can
do this
at a later point in time.
Fair point.
> Signed-off-by: Lars Kurth
> ---
> Cc: Andrew Cooper
> Cc: George Dunlap
> Cc: Ian Jackson
> Cc: Jan Beulich
> Cc: Julien Grall
> Cc: Konrad Rzeszutek Wilk
> Cc: Stefano Stabellini
> Cc: Tim Deegan
> Cc: Wei Liu
>
> CC: Simon Kuenzer
> CC: Florian Schmidt
> CC: Felipe Huici
> ---
> scripts/get_maintainer.pl | 14 ++
> 1 file changed, 10 insertions(+), 4 deletions(-)
>
> diff --git a/scripts/get_maintainer.pl b/scripts/get_maintainer.pl
> index f1e9c904ee..bdb09f8f65 100755
> --- a/scripts/get_maintainer.pl
> +++ b/scripts/get_maintainer.pl
> @@ -284,12 +284,18 @@ if (!top_of_tree($xen_path)) {
> my @typevalue = ();
> my %keyword_hash;
>
> -open (my $maint, '<', "${xen_path}MAINTAINERS")
> -or die "$P: Can't open MAINTAINERS: $!\n";
> +my $maint;
> +my $maintainers_file = "MAINTAINERS";
> +if (! open ($maint, '<', ${xen_path}.$maintainers_file)) {
> +$maintainers_file = "MAINTAINERS.md";
> +open ($maint, '<', ${xen_path}.$maintainers_file)
> +or die "$P: Can't open MAINTAINERS or MAINTAINERS.md: $!\n";
> +}
> +
> while (<$maint>) {
> my $line = $_;
>
> -if ($line =~ m/^([A-Z]):\s*(.*)/) {
> +if ($line =~ m/^\s*([A-Z]):\s*(.*)/) {
As you allow space before the blocks M:, would not this catch the example at the
beginning of the file?
M: Mail patches to: FullName
R: Designated reviewer: FullName
Good point. When I tested it (I sent the last few patches with the change in
it),
it didn't pick up the e-mail addresses. However, when I check with regex101.com
it is picked up.
Which means that the values are pushed to @typevalue, aka
{ "R", "Designated reviewer: FullName " }
Etc.
@typevalue seem to be processed by find_first_section(),
find_starting_index(), find_ending_index()
And then basically the entries are not processed because the
block in the example is not consistent and fails the validation
further down the line
For example:
./scripts/get_maintainer.pl --email --git -f .
Etc.
Don't list the e-mail addresses in the examples
So, what I proposed is probably far too fragile to make sense.
And doing something which is more accurate will probably
require major surgery to the scripts.
I can look at this in a bit more detail and see whether there
is a way to handle this.
But I don't want to invest the time to do this really as this
is probably rather complex.
@Simon, @Florian, @Felipe: would you be willing to
change the MAINTAINERS files in your repos such that
we don't have to implement lots of magic to make the
patch sending helper scripts work
