* [Qemu-devel] [PULL 20/25] hw/block/pflash_cfi*.c: fix confusing assert fail message
From: Paolo Bonzini @ 2016-12-22 15:22 UTC (permalink / raw)
To: qemu-devel; +Cc: Ziyue Yang, Ziyue Yang
In-Reply-To: <20161222152300.32395-1-pbonzini@redhat.com>
From: Ziyue Yang <yzylivezh@hotmail.com>
The patch is to fix the confusing assert fail message caused by
un-initialized device structure (from bite sized tasks).
The bug can be reproduced by
./qemu-system-x86_64 -nographic -device cfi.pflash01
The CFI hardware is dynamically loaded by QOM realizing mechanism,
however the realizing function in pflash_cfi01_realize function
requires the device being initialized manually before calling, like
./qemu-system-x86_64 -nographic
-device cfi.pflash01,num-blocks=1024,sector-length=4096,name=testcard
Once the initializing parameters are left off in the command, it will
leave the device structure not initialized, which makes
pflash_cfi01_realize try to realize a zero-volume card, causing
/mnt/EXT_volume/projects/qemu/qemu-dev/exec.c:1378:
find_ram_offset: Assertion `size != 0\' failed.
Through my test, at least the flash device's block-number, sector-length
and its name is needed for pflash_cfi01_realize to behave correctly. So
I think the new asserts are needed to hint the QEMU user to specify
the device's parameters correctly.
Signed-off-by: Ziyue Yang <skiver.cloud.yzy@gmail.com>
Message-Id: <1481810693-13733-1-git-send-email-skiver.cloud.yzy@gmail.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Ziyue Yang <yzylivezh@hotmail.com>
---
hw/block/pflash_cfi01.c | 13 +++++++++++++
hw/block/pflash_cfi02.c | 13 +++++++++++++
2 files changed, 26 insertions(+)
diff --git a/hw/block/pflash_cfi01.c b/hw/block/pflash_cfi01.c
index 62d7a56..5f0ee9d 100644
--- a/hw/block/pflash_cfi01.c
+++ b/hw/block/pflash_cfi01.c
@@ -707,6 +707,19 @@ static void pflash_cfi01_realize(DeviceState *dev, Error **errp)
int num_devices;
Error *local_err = NULL;
+ if (pfl->sector_len == 0) {
+ error_setg(errp, "attribute \"sector-length\" not specified or zero.");
+ return;
+ }
+ if (pfl->nb_blocs == 0) {
+ error_setg(errp, "attribute \"num-blocks\" not specified or zero.");
+ return;
+ }
+ if (pfl->name == NULL) {
+ error_setg(errp, "attribute \"name\" not specified.");
+ return;
+ }
+
total_len = pfl->sector_len * pfl->nb_blocs;
/* These are only used to expose the parameters of each device
diff --git a/hw/block/pflash_cfi02.c b/hw/block/pflash_cfi02.c
index 4f6105c..ef71322 100644
--- a/hw/block/pflash_cfi02.c
+++ b/hw/block/pflash_cfi02.c
@@ -600,6 +600,19 @@ static void pflash_cfi02_realize(DeviceState *dev, Error **errp)
int ret;
Error *local_err = NULL;
+ if (pfl->sector_len == 0) {
+ error_setg(errp, "attribute \"sector-length\" not specified or zero.");
+ return;
+ }
+ if (pfl->nb_blocs == 0) {
+ error_setg(errp, "attribute \"num-blocks\" not specified or zero.");
+ return;
+ }
+ if (pfl->name == NULL) {
+ error_setg(errp, "attribute \"name\" not specified.");
+ return;
+ }
+
chip_len = pfl->sector_len * pfl->nb_blocs;
/* XXX: to be fixed */
#if 0
--
2.9.3
^ permalink raw reply related
* [Qemu-devel] [PULL 18/25] x86: Fix x86_64 'g' packet response to gdb from 32-bit mode.
From: Paolo Bonzini @ 2016-12-22 15:22 UTC (permalink / raw)
To: qemu-devel; +Cc: Doug Evans
In-Reply-To: <20161222152300.32395-1-pbonzini@redhat.com>
From: Doug Evans <dje@google.com>
The remote protocol can't handle flipping back and forth
between 32-bit and 64-bit regs. To compensate, pretend "as if"
on 64-bit cpu when in 32-bit mode.
Signed-off-by: Doug Evans <dje@google.com>
Reviewed-by: Richard Henderson <rth@twiddle.net>
Message-Id: <001a113dca8274572005406e03c3@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
---
target/i386/gdbstub.c | 52 ++++++++++++++++++++++++++++++++++++++-------------
1 file changed, 39 insertions(+), 13 deletions(-)
diff --git a/target/i386/gdbstub.c b/target/i386/gdbstub.c
index c494535..9b94ab8 100644
--- a/target/i386/gdbstub.c
+++ b/target/i386/gdbstub.c
@@ -44,10 +44,22 @@ int x86_cpu_gdb_read_register(CPUState *cs, uint8_t *mem_buf, int n)
X86CPU *cpu = X86_CPU(cs);
CPUX86State *env = &cpu->env;
+ /* N.B. GDB can't deal with changes in registers or sizes in the middle
+ of a session. So if we're in 32-bit mode on a 64-bit cpu, still act
+ as if we're on a 64-bit cpu. */
+
if (n < CPU_NB_REGS) {
- if (TARGET_LONG_BITS == 64 && env->hflags & HF_CS64_MASK) {
- return gdb_get_reg64(mem_buf, env->regs[gpr_map[n]]);
- } else if (n < CPU_NB_REGS32) {
+ if (TARGET_LONG_BITS == 64) {
+ if (env->hflags & HF_CS64_MASK) {
+ return gdb_get_reg64(mem_buf, env->regs[gpr_map[n]]);
+ } else if (n < CPU_NB_REGS32) {
+ return gdb_get_reg64(mem_buf,
+ env->regs[gpr_map[n]] & 0xffffffffUL);
+ } else {
+ memset(mem_buf, 0, sizeof(target_ulong));
+ return sizeof(target_ulong);
+ }
+ } else {
return gdb_get_reg32(mem_buf, env->regs[gpr_map32[n]]);
}
} else if (n >= IDX_FP_REGS && n < IDX_FP_REGS + 8) {
@@ -60,8 +72,7 @@ int x86_cpu_gdb_read_register(CPUState *cs, uint8_t *mem_buf, int n)
return 10;
} else if (n >= IDX_XMM_REGS && n < IDX_XMM_REGS + CPU_NB_REGS) {
n -= IDX_XMM_REGS;
- if (n < CPU_NB_REGS32 ||
- (TARGET_LONG_BITS == 64 && env->hflags & HF_CS64_MASK)) {
+ if (n < CPU_NB_REGS32 || TARGET_LONG_BITS == 64) {
stq_p(mem_buf, env->xmm_regs[n].ZMM_Q(0));
stq_p(mem_buf + 8, env->xmm_regs[n].ZMM_Q(1));
return 16;
@@ -69,8 +80,12 @@ int x86_cpu_gdb_read_register(CPUState *cs, uint8_t *mem_buf, int n)
} else {
switch (n) {
case IDX_IP_REG:
- if (TARGET_LONG_BITS == 64 && env->hflags & HF_CS64_MASK) {
- return gdb_get_reg64(mem_buf, env->eip);
+ if (TARGET_LONG_BITS == 64) {
+ if (env->hflags & HF_CS64_MASK) {
+ return gdb_get_reg64(mem_buf, env->eip);
+ } else {
+ return gdb_get_reg64(mem_buf, env->eip & 0xffffffffUL);
+ }
} else {
return gdb_get_reg32(mem_buf, env->eip);
}
@@ -151,9 +166,17 @@ int x86_cpu_gdb_write_register(CPUState *cs, uint8_t *mem_buf, int n)
CPUX86State *env = &cpu->env;
uint32_t tmp;
+ /* N.B. GDB can't deal with changes in registers or sizes in the middle
+ of a session. So if we're in 32-bit mode on a 64-bit cpu, still act
+ as if we're on a 64-bit cpu. */
+
if (n < CPU_NB_REGS) {
- if (TARGET_LONG_BITS == 64 && env->hflags & HF_CS64_MASK) {
- env->regs[gpr_map[n]] = ldtul_p(mem_buf);
+ if (TARGET_LONG_BITS == 64) {
+ if (env->hflags & HF_CS64_MASK) {
+ env->regs[gpr_map[n]] = ldtul_p(mem_buf);
+ } else if (n < CPU_NB_REGS32) {
+ env->regs[gpr_map[n]] = ldtul_p(mem_buf) & 0xffffffffUL;
+ }
return sizeof(target_ulong);
} else if (n < CPU_NB_REGS32) {
n = gpr_map32[n];
@@ -169,8 +192,7 @@ int x86_cpu_gdb_write_register(CPUState *cs, uint8_t *mem_buf, int n)
return 10;
} else if (n >= IDX_XMM_REGS && n < IDX_XMM_REGS + CPU_NB_REGS) {
n -= IDX_XMM_REGS;
- if (n < CPU_NB_REGS32 ||
- (TARGET_LONG_BITS == 64 && env->hflags & HF_CS64_MASK)) {
+ if (n < CPU_NB_REGS32 || TARGET_LONG_BITS == 64) {
env->xmm_regs[n].ZMM_Q(0) = ldq_p(mem_buf);
env->xmm_regs[n].ZMM_Q(1) = ldq_p(mem_buf + 8);
return 16;
@@ -178,8 +200,12 @@ int x86_cpu_gdb_write_register(CPUState *cs, uint8_t *mem_buf, int n)
} else {
switch (n) {
case IDX_IP_REG:
- if (TARGET_LONG_BITS == 64 && env->hflags & HF_CS64_MASK) {
- env->eip = ldq_p(mem_buf);
+ if (TARGET_LONG_BITS == 64) {
+ if (env->hflags & HF_CS64_MASK) {
+ env->eip = ldq_p(mem_buf);
+ } else {
+ env->eip = ldq_p(mem_buf) & 0xffffffffUL;
+ }
return 8;
} else {
env->eip &= ~0xffffffffUL;
--
2.9.3
^ permalink raw reply related
* [Qemu-devel] [PULL 21/25] scsi-disk: fix VERIFY for scsi-block
From: Paolo Bonzini @ 2016-12-22 15:22 UTC (permalink / raw)
To: qemu-devel
In-Reply-To: <20161222152300.32395-1-pbonzini@redhat.com>
When a scsi-disk object receives VERIFY command with BYTCHK bit being zero,
scsi_block_is_passthrough returns false and finally makes req being proceeded
by scsi_block_dma_command. Because scsi_block_dma_command has removed process
of VERIFY, QEMU will abort in this function.
Reported-by: Junlian Bell <zhongjun@sangfor.com.cn>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
---
hw/scsi/scsi-disk.c | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/hw/scsi/scsi-disk.c b/hw/scsi/scsi-disk.c
index a963191..bdd1e5f 100644
--- a/hw/scsi/scsi-disk.c
+++ b/hw/scsi/scsi-disk.c
@@ -2157,6 +2157,13 @@ static int32_t scsi_disk_dma_command(SCSIRequest *req, uint8_t *buf)
DPRINTF("Write %s(sector %" PRId64 ", count %u)\n",
(command & 0xe) == 0xe ? "And Verify " : "",
r->req.cmd.lba, len);
+ case VERIFY_10:
+ case VERIFY_12:
+ case VERIFY_16:
+ /* We get here only for BYTCHK == 0x01 and only for scsi-block.
+ * As far as DMA is concerned, we can treat it the same as a write;
+ * scsi_block_do_sgio will send VERIFY commands.
+ */
if (r->req.cmd.buf[1] & 0xe0) {
goto illegal_request;
}
@@ -2712,7 +2719,7 @@ static bool scsi_block_is_passthrough(SCSIDiskState *s, uint8_t *buf)
case WRITE_VERIFY_16:
/* MMC writing cannot be done via DMA helpers, because it sometimes
* involves writing beyond the maximum LBA or to negative LBA (lead-in).
- * We might use scsi_disk_dma_reqops as long as no writing commands are
+ * We might use scsi_block_dma_reqops as long as no writing commands are
* seen, but performance usually isn't paramount on optical media. So,
* just make scsi-block operate the same as scsi-generic for them.
*/
--
2.9.3
^ permalink raw reply related
* [Qemu-devel] [PULL 22/25] kvm: sync linux headers
From: Paolo Bonzini @ 2016-12-22 15:22 UTC (permalink / raw)
To: qemu-devel; +Cc: Marcelo Tosatti
In-Reply-To: <20161222152300.32395-1-pbonzini@redhat.com>
From: Marcelo Tosatti <mtosatti@redhat.com>
Import KVM_CLOCK_TSC_STABLE.
Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
Message-Id: <20161210172324.402794293@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
---
include/standard-headers/linux/input.h | 1 +
include/standard-headers/linux/pci_regs.h | 15 ++++++++++++++-
| 7 +++++++
| 3 +++
| 3 +++
| 3 +++
| 7 +++++++
7 files changed, 38 insertions(+), 1 deletion(-)
diff --git a/include/standard-headers/linux/input.h b/include/standard-headers/linux/input.h
index 7361a16..b472b85 100644
--- a/include/standard-headers/linux/input.h
+++ b/include/standard-headers/linux/input.h
@@ -245,6 +245,7 @@ struct input_mask {
#define BUS_SPI 0x1C
#define BUS_RMI 0x1D
#define BUS_CEC 0x1E
+#define BUS_INTEL_ISHTP 0x1F
/*
* MT_TOOL types
diff --git a/include/standard-headers/linux/pci_regs.h b/include/standard-headers/linux/pci_regs.h
index 4040951..e5a2e68 100644
--- a/include/standard-headers/linux/pci_regs.h
+++ b/include/standard-headers/linux/pci_regs.h
@@ -612,6 +612,8 @@
*/
#define PCI_EXP_DEVCAP2 36 /* Device Capabilities 2 */
#define PCI_EXP_DEVCAP2_ARI 0x00000020 /* Alternative Routing-ID */
+#define PCI_EXP_DEVCAP2_ATOMIC_ROUTE 0x00000040 /* Atomic Op routing */
+#define PCI_EXP_DEVCAP2_ATOMIC_COMP64 0x00000100 /* Atomic 64-bit compare */
#define PCI_EXP_DEVCAP2_LTR 0x00000800 /* Latency tolerance reporting */
#define PCI_EXP_DEVCAP2_OBFF_MASK 0x000c0000 /* OBFF support mechanism */
#define PCI_EXP_DEVCAP2_OBFF_MSG 0x00040000 /* New message signaling */
@@ -619,6 +621,7 @@
#define PCI_EXP_DEVCTL2 40 /* Device Control 2 */
#define PCI_EXP_DEVCTL2_COMP_TIMEOUT 0x000f /* Completion Timeout Value */
#define PCI_EXP_DEVCTL2_ARI 0x0020 /* Alternative Routing-ID */
+#define PCI_EXP_DEVCTL2_ATOMIC_REQ 0x0040 /* Set Atomic requests */
#define PCI_EXP_DEVCTL2_IDO_REQ_EN 0x0100 /* Allow IDO for requests */
#define PCI_EXP_DEVCTL2_IDO_CMP_EN 0x0200 /* Allow IDO for completions */
#define PCI_EXP_DEVCTL2_LTR_EN 0x0400 /* Enable LTR mechanism */
@@ -671,7 +674,8 @@
#define PCI_EXT_CAP_ID_PMUX 0x1A /* Protocol Multiplexing */
#define PCI_EXT_CAP_ID_PASID 0x1B /* Process Address Space ID */
#define PCI_EXT_CAP_ID_DPC 0x1D /* Downstream Port Containment */
-#define PCI_EXT_CAP_ID_MAX PCI_EXT_CAP_ID_DPC
+#define PCI_EXT_CAP_ID_PTM 0x1F /* Precision Time Measurement */
+#define PCI_EXT_CAP_ID_MAX PCI_EXT_CAP_ID_PTM
#define PCI_EXT_CAP_DSN_SIZEOF 12
#define PCI_EXT_CAP_MCAST_ENDPOINT_SIZEOF 40
@@ -964,4 +968,13 @@
#define PCI_EXP_DPC_SOURCE_ID 10 /* DPC Source Identifier */
+/* Precision Time Measurement */
+#define PCI_PTM_CAP 0x04 /* PTM Capability */
+#define PCI_PTM_CAP_REQ 0x00000001 /* Requester capable */
+#define PCI_PTM_CAP_ROOT 0x00000004 /* Root capable */
+#define PCI_PTM_GRANULARITY_MASK 0x0000FF00 /* Clock granularity */
+#define PCI_PTM_CTRL 0x08 /* PTM Control */
+#define PCI_PTM_CTRL_ENABLE 0x00000001 /* PTM enable */
+#define PCI_PTM_CTRL_ROOT 0x00000002 /* Root select */
+
#endif /* LINUX_PCI_REGS_H */
--git a/linux-headers/asm-arm/kvm.h b/linux-headers/asm-arm/kvm.h
index 541268c..2fb7859 100644
--- a/linux-headers/asm-arm/kvm.h
+++ b/linux-headers/asm-arm/kvm.h
@@ -84,6 +84,13 @@ struct kvm_regs {
#define KVM_VGIC_V2_DIST_SIZE 0x1000
#define KVM_VGIC_V2_CPU_SIZE 0x2000
+/* Supported VGICv3 address types */
+#define KVM_VGIC_V3_ADDR_TYPE_DIST 2
+#define KVM_VGIC_V3_ADDR_TYPE_REDIST 3
+
+#define KVM_VGIC_V3_DIST_SIZE SZ_64K
+#define KVM_VGIC_V3_REDIST_SIZE (2 * SZ_64K)
+
#define KVM_ARM_VCPU_POWER_OFF 0 /* CPU is started in OFF state */
#define KVM_ARM_VCPU_PSCI_0_2 1 /* CPU uses PSCI v0.2 */
--git a/linux-headers/asm-x86/unistd_32.h b/linux-headers/asm-x86/unistd_32.h
index abeaf40..d45ea28 100644
--- a/linux-headers/asm-x86/unistd_32.h
+++ b/linux-headers/asm-x86/unistd_32.h
@@ -377,5 +377,8 @@
#define __NR_copy_file_range 377
#define __NR_preadv2 378
#define __NR_pwritev2 379
+#define __NR_pkey_mprotect 380
+#define __NR_pkey_alloc 381
+#define __NR_pkey_free 382
#endif /* _ASM_X86_UNISTD_32_H */
--git a/linux-headers/asm-x86/unistd_64.h b/linux-headers/asm-x86/unistd_64.h
index 73c3d1f..e22db91 100644
--- a/linux-headers/asm-x86/unistd_64.h
+++ b/linux-headers/asm-x86/unistd_64.h
@@ -330,5 +330,8 @@
#define __NR_copy_file_range 326
#define __NR_preadv2 327
#define __NR_pwritev2 328
+#define __NR_pkey_mprotect 329
+#define __NR_pkey_alloc 330
+#define __NR_pkey_free 331
#endif /* _ASM_X86_UNISTD_64_H */
--git a/linux-headers/asm-x86/unistd_x32.h b/linux-headers/asm-x86/unistd_x32.h
index e5aea76..84e58b2 100644
--- a/linux-headers/asm-x86/unistd_x32.h
+++ b/linux-headers/asm-x86/unistd_x32.h
@@ -283,6 +283,9 @@
#define __NR_membarrier (__X32_SYSCALL_BIT + 324)
#define __NR_mlock2 (__X32_SYSCALL_BIT + 325)
#define __NR_copy_file_range (__X32_SYSCALL_BIT + 326)
+#define __NR_pkey_mprotect (__X32_SYSCALL_BIT + 329)
+#define __NR_pkey_alloc (__X32_SYSCALL_BIT + 330)
+#define __NR_pkey_free (__X32_SYSCALL_BIT + 331)
#define __NR_rt_sigaction (__X32_SYSCALL_BIT + 512)
#define __NR_rt_sigreturn (__X32_SYSCALL_BIT + 513)
#define __NR_ioctl (__X32_SYSCALL_BIT + 514)
--git a/linux-headers/linux/kvm.h b/linux-headers/linux/kvm.h
index 4806e06..bb0ed71 100644
--- a/linux-headers/linux/kvm.h
+++ b/linux-headers/linux/kvm.h
@@ -972,12 +972,19 @@ struct kvm_irqfd {
__u8 pad[16];
};
+/* For KVM_CAP_ADJUST_CLOCK */
+
+/* Do not use 1, KVM_CHECK_EXTENSION returned it before we had flags. */
+#define KVM_CLOCK_TSC_STABLE 2
+
struct kvm_clock_data {
__u64 clock;
__u32 flags;
__u32 pad[9];
};
+/* For KVM_CAP_SW_TLB */
+
#define KVM_MMU_FSL_BOOKE_NOHV 0
#define KVM_MMU_FSL_BOOKE_HV 1
--
2.9.3
^ permalink raw reply related
* [Qemu-devel] [PULL 24/25] target-i386: Fix eflags.TF/#DB handling of syscall/sysret insns
From: Paolo Bonzini @ 2016-12-22 15:22 UTC (permalink / raw)
To: qemu-devel; +Cc: Doug Evans
In-Reply-To: <20161222152300.32395-1-pbonzini@redhat.com>
From: Doug Evans <dje@google.com>
The syscall and sysret instructions behave a bit differently:
TF is checked after the instruction completes.
This allows the o/s to disable #DB at a syscall by adding TF to FMASK.
And then when the sysret is executed the #DB is taken "as if" the
syscall insn just completed.
Signed-off-by: Doug Evans <dje@google.com>
Message-Id: <94eb2c0bfa1c6a9fec0543057483@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
---
target/i386/bpt_helper.c | 7 +++++++
target/i386/helper.h | 1 +
target/i386/translate.c | 29 ++++++++++++++++++++++++-----
3 files changed, 32 insertions(+), 5 deletions(-)
diff --git a/target/i386/bpt_helper.c b/target/i386/bpt_helper.c
index 6fd7fe0..b3efdc7 100644
--- a/target/i386/bpt_helper.c
+++ b/target/i386/bpt_helper.c
@@ -244,6 +244,13 @@ void helper_single_step(CPUX86State *env)
raise_exception(env, EXCP01_DB);
}
+void helper_rechecking_single_step(CPUX86State *env)
+{
+ if ((env->eflags & TF_MASK) != 0) {
+ helper_single_step(env);
+ }
+}
+
void helper_set_dr(CPUX86State *env, int reg, target_ulong t0)
{
#ifndef CONFIG_USER_ONLY
diff --git a/target/i386/helper.h b/target/i386/helper.h
index 4e859eb..bd9b2cf 100644
--- a/target/i386/helper.h
+++ b/target/i386/helper.h
@@ -79,6 +79,7 @@ DEF_HELPER_2(cmpxchg16b_unlocked, void, env, tl)
DEF_HELPER_2(cmpxchg16b, void, env, tl)
#endif
DEF_HELPER_1(single_step, void, env)
+DEF_HELPER_1(rechecking_single_step, void, env)
DEF_HELPER_1(cpuid, void, env)
DEF_HELPER_1(rdtsc, void, env)
DEF_HELPER_1(rdtscp, void, env)
diff --git a/target/i386/translate.c b/target/i386/translate.c
index 324103c..59e11fc 100644
--- a/target/i386/translate.c
+++ b/target/i386/translate.c
@@ -2500,8 +2500,10 @@ static void gen_bnd_jmp(DisasContext *s)
}
/* Generate an end of block. Trace exception is also generated if needed.
- If IIM, set HF_INHIBIT_IRQ_MASK if it isn't already set. */
-static void gen_eob_inhibit_irq(DisasContext *s, bool inhibit)
+ If INHIBIT, set HF_INHIBIT_IRQ_MASK if it isn't already set.
+ If RECHECK_TF, emit a rechecking helper for #DB, ignoring the state of
+ S->TF. This is used by the syscall/sysret insns. */
+static void gen_eob_worker(DisasContext *s, bool inhibit, bool recheck_tf)
{
gen_update_cc_op(s);
@@ -2517,6 +2519,9 @@ static void gen_eob_inhibit_irq(DisasContext *s, bool inhibit)
}
if (s->singlestep_enabled) {
gen_helper_debug(cpu_env);
+ } else if (recheck_tf) {
+ gen_helper_rechecking_single_step(cpu_env);
+ tcg_gen_exit_tb(0);
} else if (s->tf) {
gen_helper_single_step(cpu_env);
} else {
@@ -2525,10 +2530,17 @@ static void gen_eob_inhibit_irq(DisasContext *s, bool inhibit)
s->is_jmp = DISAS_TB_JUMP;
}
+/* End of block.
+ If INHIBIT, set HF_INHIBIT_IRQ_MASK if it isn't already set. */
+static void gen_eob_inhibit_irq(DisasContext *s, bool inhibit)
+{
+ gen_eob_worker(s, inhibit, false);
+}
+
/* End of block, resetting the inhibit irq flag. */
static void gen_eob(DisasContext *s)
{
- gen_eob_inhibit_irq(s, false);
+ gen_eob_worker(s, false, false);
}
/* generate a jump to eip. No segment change must happen before as a
@@ -6423,7 +6435,10 @@ static target_ulong disas_insn(CPUX86State *env, DisasContext *s,
tcg_const_i32(s->pc - s->cs_base));
set_cc_op(s, CC_OP_EFLAGS);
}
- gen_eob(s);
+ /* TF handling for the syscall insn is different. The TF bit is checked
+ after the syscall insn completes. This allows #DB to not be
+ generated after one has entered CPL0 if TF is set in FMASK. */
+ gen_eob_worker(s, false, true);
break;
case 0xe8: /* call im */
{
@@ -7115,7 +7130,11 @@ static target_ulong disas_insn(CPUX86State *env, DisasContext *s,
if (s->lma) {
set_cc_op(s, CC_OP_EFLAGS);
}
- gen_eob(s);
+ /* TF handling for the sysret insn is different. The TF bit is
+ checked after the sysret insn completes. This allows #DB to be
+ generated "as if" the syscall insn in userspace has just
+ completed. */
+ gen_eob_worker(s, false, true);
}
break;
#endif
--
2.9.3
^ permalink raw reply related
* [Qemu-devel] [PULL 23/25] kvmclock: reduce kvmclock difference on migration
From: Paolo Bonzini @ 2016-12-22 15:22 UTC (permalink / raw)
To: qemu-devel; +Cc: Marcelo Tosatti
In-Reply-To: <20161222152300.32395-1-pbonzini@redhat.com>
From: Marcelo Tosatti <mtosatti@redhat.com>
Check for KVM_CAP_ADJUST_CLOCK capability KVM_CLOCK_TSC_STABLE, which
indicates that KVM_GET_CLOCK returns a value as seen by the guest at
that moment.
For new machine types, use this value rather than reading
from guest memory.
This reduces kvmclock difference on migration from 5s to 0.1s
(when max_downtime == 5s).
Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
Message-Id: <20161121105052.598267440@redhat.com>
[Add comment explaining what is going on. - Paolo]
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
---
hw/i386/kvm/clock.c | 142 +++++++++++++++++++++++++++++++++++++++++++------
include/hw/i386/pc.h | 5 ++
target/i386/kvm.c | 7 +++
target/i386/kvm_i386.h | 1 +
4 files changed, 140 insertions(+), 15 deletions(-)
diff --git a/hw/i386/kvm/clock.c b/hw/i386/kvm/clock.c
index 0f75dd3..ef9d560 100644
--- a/hw/i386/kvm/clock.c
+++ b/hw/i386/kvm/clock.c
@@ -36,6 +36,13 @@ typedef struct KVMClockState {
uint64_t clock;
bool clock_valid;
+
+ /* whether machine type supports reliable KVM_GET_CLOCK */
+ bool mach_use_reliable_get_clock;
+
+ /* whether the 'clock' value was obtained in a host with
+ * reliable KVM_GET_CLOCK */
+ bool clock_is_reliable;
} KVMClockState;
struct pvclock_vcpu_time_info {
@@ -81,6 +88,60 @@ static uint64_t kvmclock_current_nsec(KVMClockState *s)
return nsec + time.system_time;
}
+static void kvm_update_clock(KVMClockState *s)
+{
+ struct kvm_clock_data data;
+ int ret;
+
+ ret = kvm_vm_ioctl(kvm_state, KVM_GET_CLOCK, &data);
+ if (ret < 0) {
+ fprintf(stderr, "KVM_GET_CLOCK failed: %s\n", strerror(ret));
+ abort();
+ }
+ s->clock = data.clock;
+
+ /* If kvm_has_adjust_clock_stable() is false, KVM_GET_CLOCK returns
+ * essentially CLOCK_MONOTONIC plus a guest-specific adjustment. This
+ * can drift from the TSC-based value that is computed by the guest,
+ * so we need to go through kvmclock_current_nsec(). If
+ * kvm_has_adjust_clock_stable() is true, and the flags contain
+ * KVM_CLOCK_TSC_STABLE, then KVM_GET_CLOCK returns a TSC-based value
+ * and kvmclock_current_nsec() is not necessary.
+ *
+ * Here, however, we need not check KVM_CLOCK_TSC_STABLE. This is because:
+ *
+ * - if the host has disabled the kvmclock master clock, the guest already
+ * has protection against time going backwards. This "safety net" is only
+ * absent when kvmclock is stable;
+ *
+ * - therefore, we can replace a check like
+ *
+ * if last KVM_GET_CLOCK was not reliable then
+ * read from memory
+ *
+ * with
+ *
+ * if last KVM_GET_CLOCK was not reliable && masterclock is enabled
+ * read from memory
+ *
+ * However:
+ *
+ * - if kvm_has_adjust_clock_stable() returns false, the left side is
+ * always true (KVM_GET_CLOCK is never reliable), and the right side is
+ * unknown (because we don't have data.flags). We must assume it's true
+ * and read from memory.
+ *
+ * - if kvm_has_adjust_clock_stable() returns true, the result of the &&
+ * is always false (masterclock is enabled iff KVM_GET_CLOCK is reliable)
+ *
+ * So we can just use this instead:
+ *
+ * if !kvm_has_adjust_clock_stable() then
+ * read from memory
+ */
+ s->clock_is_reliable = kvm_has_adjust_clock_stable();
+}
+
static void kvmclock_vm_state_change(void *opaque, int running,
RunState state)
{
@@ -91,15 +152,21 @@ static void kvmclock_vm_state_change(void *opaque, int running,
if (running) {
struct kvm_clock_data data = {};
- uint64_t time_at_migration = kvmclock_current_nsec(s);
-
- s->clock_valid = false;
- /* We can't rely on the migrated clock value, just discard it */
- if (time_at_migration) {
- s->clock = time_at_migration;
+ /*
+ * If the host where s->clock was read did not support reliable
+ * KVM_GET_CLOCK, read kvmclock value from memory.
+ */
+ if (!s->clock_is_reliable) {
+ uint64_t pvclock_via_mem = kvmclock_current_nsec(s);
+ /* We can't rely on the saved clock value, just discard it */
+ if (pvclock_via_mem) {
+ s->clock = pvclock_via_mem;
+ }
}
+ s->clock_valid = false;
+
data.clock = s->clock;
ret = kvm_vm_ioctl(kvm_state, KVM_SET_CLOCK, &data);
if (ret < 0) {
@@ -120,8 +187,6 @@ static void kvmclock_vm_state_change(void *opaque, int running,
}
}
} else {
- struct kvm_clock_data data;
- int ret;
if (s->clock_valid) {
return;
@@ -129,13 +194,7 @@ static void kvmclock_vm_state_change(void *opaque, int running,
kvm_synchronize_all_tsc();
- ret = kvm_vm_ioctl(kvm_state, KVM_GET_CLOCK, &data);
- if (ret < 0) {
- fprintf(stderr, "KVM_GET_CLOCK failed: %s\n", strerror(ret));
- abort();
- }
- s->clock = data.clock;
-
+ kvm_update_clock(s);
/*
* If the VM is stopped, declare the clock state valid to
* avoid re-reading it on next vmsave (which would return
@@ -149,25 +208,78 @@ static void kvmclock_realize(DeviceState *dev, Error **errp)
{
KVMClockState *s = KVM_CLOCK(dev);
+ kvm_update_clock(s);
+
qemu_add_vm_change_state_handler(kvmclock_vm_state_change, s);
}
+static bool kvmclock_clock_is_reliable_needed(void *opaque)
+{
+ KVMClockState *s = opaque;
+
+ return s->mach_use_reliable_get_clock;
+}
+
+static const VMStateDescription kvmclock_reliable_get_clock = {
+ .name = "kvmclock/clock_is_reliable",
+ .version_id = 1,
+ .minimum_version_id = 1,
+ .needed = kvmclock_clock_is_reliable_needed,
+ .fields = (VMStateField[]) {
+ VMSTATE_BOOL(clock_is_reliable, KVMClockState),
+ VMSTATE_END_OF_LIST()
+ }
+};
+
+/*
+ * When migrating, read the clock just before migration,
+ * so that the guest clock counts during the events
+ * between:
+ *
+ * * vm_stop()
+ * *
+ * * pre_save()
+ *
+ * This reduces kvmclock difference on migration from 5s
+ * to 0.1s (when max_downtime == 5s), because sending the
+ * final pages of memory (which happens between vm_stop()
+ * and pre_save()) takes max_downtime.
+ */
+static void kvmclock_pre_save(void *opaque)
+{
+ KVMClockState *s = opaque;
+
+ kvm_update_clock(s);
+}
+
static const VMStateDescription kvmclock_vmsd = {
.name = "kvmclock",
.version_id = 1,
.minimum_version_id = 1,
+ .pre_save = kvmclock_pre_save,
.fields = (VMStateField[]) {
VMSTATE_UINT64(clock, KVMClockState),
VMSTATE_END_OF_LIST()
+ },
+ .subsections = (const VMStateDescription * []) {
+ &kvmclock_reliable_get_clock,
+ NULL
}
};
+static Property kvmclock_properties[] = {
+ DEFINE_PROP_BOOL("x-mach-use-reliable-get-clock", KVMClockState,
+ mach_use_reliable_get_clock, true),
+ DEFINE_PROP_END_OF_LIST(),
+};
+
static void kvmclock_class_init(ObjectClass *klass, void *data)
{
DeviceClass *dc = DEVICE_CLASS(klass);
dc->realize = kvmclock_realize;
dc->vmsd = &kvmclock_vmsd;
+ dc->props = kvmclock_properties;
}
static const TypeInfo kvmclock_info = {
diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h
index b37bc5b..b22e699 100644
--- a/include/hw/i386/pc.h
+++ b/include/hw/i386/pc.h
@@ -379,6 +379,11 @@ bool e820_get_entry(int, uint32_t, uint64_t *, uint64_t *);
#define PC_COMPAT_2_7 \
HW_COMPAT_2_7 \
{\
+ .driver = "kvmclock",\
+ .property = "x-mach-use-reliable-get-clock",\
+ .value = "off",\
+ },\
+ {\
.driver = TYPE_X86_CPU,\
.property = "l3-cache",\
.value = "off",\
diff --git a/target/i386/kvm.c b/target/i386/kvm.c
index f62264a..10a9cd8 100644
--- a/target/i386/kvm.c
+++ b/target/i386/kvm.c
@@ -117,6 +117,13 @@ bool kvm_has_smm(void)
return kvm_check_extension(kvm_state, KVM_CAP_X86_SMM);
}
+bool kvm_has_adjust_clock_stable(void)
+{
+ int ret = kvm_check_extension(kvm_state, KVM_CAP_ADJUST_CLOCK);
+
+ return (ret == KVM_CLOCK_TSC_STABLE);
+}
+
bool kvm_allows_irq0_override(void)
{
return !kvm_irqchip_in_kernel() || kvm_has_gsi_routing();
diff --git a/target/i386/kvm_i386.h b/target/i386/kvm_i386.h
index 7607929..bfce427 100644
--- a/target/i386/kvm_i386.h
+++ b/target/i386/kvm_i386.h
@@ -17,6 +17,7 @@
bool kvm_allows_irq0_override(void);
bool kvm_has_smm(void);
+bool kvm_has_adjust_clock_stable(void);
void kvm_synchronize_all_tsc(void);
void kvm_arch_reset_vcpu(X86CPU *cs);
void kvm_arch_do_init_vcpu(X86CPU *cs);
--
2.9.3
^ permalink raw reply related
* [Qemu-devel] [PULL 25/25] x86: implement la57 paging mode
From: Paolo Bonzini @ 2016-12-22 15:23 UTC (permalink / raw)
To: qemu-devel; +Cc: Kirill A. Shutemov
In-Reply-To: <20161222152300.32395-1-pbonzini@redhat.com>
From: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
The new paging more is extension of IA32e mode with more additional page
table level.
It brings support of 57-bit vitrual address space (128PB) and 52-bit
physical address space (4PB).
The structure of new page table level is identical to pml4.
The feature is enumerated with CPUID.(EAX=07H, ECX=0):ECX[bit 16].
CR4.LA57[bit 12] need to be set when pageing enables to activate 5-level
paging mode.
Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Message-Id: <20161215001305.146807-1-kirill.shutemov@linux.intel.com>
[Drop changes to target-i386/translate.c. - Paolo]
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
---
target/i386/arch_memory_mapping.c | 42 ++++++-
target/i386/cpu.c | 16 ++-
target/i386/cpu.h | 2 +
target/i386/helper.c | 54 +++++++--
target/i386/monitor.c | 234 +++++++++++++++++++++++++++++---------
5 files changed, 274 insertions(+), 74 deletions(-)
diff --git a/target/i386/arch_memory_mapping.c b/target/i386/arch_memory_mapping.c
index 88f341e..826aee5 100644
--- a/target/i386/arch_memory_mapping.c
+++ b/target/i386/arch_memory_mapping.c
@@ -220,7 +220,8 @@ static void walk_pdpe(MemoryMappingList *list, AddressSpace *as,
/* IA-32e Paging */
static void walk_pml4e(MemoryMappingList *list, AddressSpace *as,
- hwaddr pml4e_start_addr, int32_t a20_mask)
+ hwaddr pml4e_start_addr, int32_t a20_mask,
+ target_ulong start_line_addr)
{
hwaddr pml4e_addr, pdpe_start_addr;
uint64_t pml4e;
@@ -236,11 +237,34 @@ static void walk_pml4e(MemoryMappingList *list, AddressSpace *as,
continue;
}
- line_addr = ((i & 0x1ffULL) << 39) | (0xffffULL << 48);
+ line_addr = start_line_addr | ((i & 0x1ffULL) << 39);
pdpe_start_addr = (pml4e & PLM4_ADDR_MASK) & a20_mask;
walk_pdpe(list, as, pdpe_start_addr, a20_mask, line_addr);
}
}
+
+static void walk_pml5e(MemoryMappingList *list, AddressSpace *as,
+ hwaddr pml5e_start_addr, int32_t a20_mask)
+{
+ hwaddr pml5e_addr, pml4e_start_addr;
+ uint64_t pml5e;
+ target_ulong line_addr;
+ int i;
+
+ for (i = 0; i < 512; i++) {
+ pml5e_addr = (pml5e_start_addr + i * 8) & a20_mask;
+ pml5e = address_space_ldq(as, pml5e_addr, MEMTXATTRS_UNSPECIFIED,
+ NULL);
+ if (!(pml5e & PG_PRESENT_MASK)) {
+ /* not present */
+ continue;
+ }
+
+ line_addr = (0x7fULL << 57) | ((i & 0x1ffULL) << 48);
+ pml4e_start_addr = (pml5e & PLM4_ADDR_MASK) & a20_mask;
+ walk_pml4e(list, as, pml4e_start_addr, a20_mask, line_addr);
+ }
+}
#endif
void x86_cpu_get_memory_mapping(CPUState *cs, MemoryMappingList *list,
@@ -257,10 +281,18 @@ void x86_cpu_get_memory_mapping(CPUState *cs, MemoryMappingList *list,
if (env->cr[4] & CR4_PAE_MASK) {
#ifdef TARGET_X86_64
if (env->hflags & HF_LMA_MASK) {
- hwaddr pml4e_addr;
+ if (env->cr[4] & CR4_LA57_MASK) {
+ hwaddr pml5e_addr;
+
+ pml5e_addr = (env->cr[3] & PLM4_ADDR_MASK) & env->a20_mask;
+ walk_pml5e(list, cs->as, pml5e_addr, env->a20_mask);
+ } else {
+ hwaddr pml4e_addr;
- pml4e_addr = (env->cr[3] & PLM4_ADDR_MASK) & env->a20_mask;
- walk_pml4e(list, cs->as, pml4e_addr, env->a20_mask);
+ pml4e_addr = (env->cr[3] & PLM4_ADDR_MASK) & env->a20_mask;
+ walk_pml4e(list, cs->as, pml4e_addr, env->a20_mask,
+ 0xffffULL << 48);
+ }
} else
#endif
{
diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index 993f825..b0640f1 100644
--- a/target/i386/cpu.c
+++ b/target/i386/cpu.c
@@ -238,7 +238,8 @@ static void x86_cpu_vendor_words2str(char *dst, uint32_t vendor1,
CPUID_7_0_EBX_HLE, CPUID_7_0_EBX_AVX2,
CPUID_7_0_EBX_INVPCID, CPUID_7_0_EBX_RTM,
CPUID_7_0_EBX_RDSEED */
-#define TCG_7_0_ECX_FEATURES (CPUID_7_0_ECX_PKU | CPUID_7_0_ECX_OSPKE)
+#define TCG_7_0_ECX_FEATURES (CPUID_7_0_ECX_PKU | CPUID_7_0_ECX_OSPKE | \
+ CPUID_7_0_ECX_LA57)
#define TCG_7_0_EDX_FEATURES 0
#define TCG_APM_FEATURES 0
#define TCG_6_EAX_FEATURES CPUID_6_EAX_ARAT
@@ -435,7 +436,7 @@ static FeatureWordInfo feature_word_info[FEATURE_WORDS] = {
"ospke", NULL, NULL, NULL,
NULL, NULL, NULL, NULL,
NULL, NULL, NULL, NULL,
- NULL, NULL, NULL, NULL,
+ "la57", NULL, NULL, NULL,
NULL, NULL, "rdpid", NULL,
NULL, NULL, NULL, NULL,
NULL, NULL, NULL, NULL,
@@ -2742,10 +2743,13 @@ void cpu_x86_cpuid(CPUX86State *env, uint32_t index, uint32_t count,
case 0x80000008:
/* virtual & phys address size in low 2 bytes. */
if (env->features[FEAT_8000_0001_EDX] & CPUID_EXT2_LM) {
- /* 64 bit processor, 48 bits virtual, configurable
- * physical bits.
- */
- *eax = 0x00003000 + cpu->phys_bits;
+ /* 64 bit processor */
+ *eax = cpu->phys_bits; /* configurable physical bits */
+ if (env->features[FEAT_7_0_ECX] & CPUID_7_0_ECX_LA57) {
+ *eax |= 0x00003900; /* 57 bits virtual */
+ } else {
+ *eax |= 0x00003000; /* 48 bits virtual */
+ }
} else {
*eax = cpu->phys_bits;
}
diff --git a/target/i386/cpu.h b/target/i386/cpu.h
index d0bf624..a7f2f60 100644
--- a/target/i386/cpu.h
+++ b/target/i386/cpu.h
@@ -224,6 +224,7 @@
#define CR4_OSFXSR_SHIFT 9
#define CR4_OSFXSR_MASK (1U << CR4_OSFXSR_SHIFT)
#define CR4_OSXMMEXCPT_MASK (1U << 10)
+#define CR4_LA57_MASK (1U << 12)
#define CR4_VMXE_MASK (1U << 13)
#define CR4_SMXE_MASK (1U << 14)
#define CR4_FSGSBASE_MASK (1U << 16)
@@ -629,6 +630,7 @@ typedef uint32_t FeatureWordArray[FEATURE_WORDS];
#define CPUID_7_0_ECX_UMIP (1U << 2)
#define CPUID_7_0_ECX_PKU (1U << 3)
#define CPUID_7_0_ECX_OSPKE (1U << 4)
+#define CPUID_7_0_ECX_LA57 (1U << 16)
#define CPUID_7_0_ECX_RDPID (1U << 22)
#define CPUID_7_0_EDX_AVX512_4VNNIW (1U << 2) /* AVX512 Neural Network Instructions */
diff --git a/target/i386/helper.c b/target/i386/helper.c
index 4ecc091..43e87dd 100644
--- a/target/i386/helper.c
+++ b/target/i386/helper.c
@@ -651,11 +651,11 @@ void cpu_x86_update_cr4(CPUX86State *env, uint32_t new_cr4)
uint32_t hflags;
#if defined(DEBUG_MMU)
- printf("CR4 update: CR4=%08x\n", (uint32_t)env->cr[4]);
+ printf("CR4 update: %08x -> %08x\n", (uint32_t)env->cr[4], new_cr4);
#endif
if ((new_cr4 ^ env->cr[4]) &
(CR4_PGE_MASK | CR4_PAE_MASK | CR4_PSE_MASK |
- CR4_SMEP_MASK | CR4_SMAP_MASK)) {
+ CR4_SMEP_MASK | CR4_SMAP_MASK | CR4_LA57_MASK)) {
tlb_flush(CPU(cpu), 1);
}
@@ -757,19 +757,41 @@ int x86_cpu_handle_mmu_fault(CPUState *cs, vaddr addr,
#ifdef TARGET_X86_64
if (env->hflags & HF_LMA_MASK) {
+ bool la57 = env->cr[4] & CR4_LA57_MASK;
+ uint64_t pml5e_addr, pml5e;
uint64_t pml4e_addr, pml4e;
int32_t sext;
/* test virtual address sign extension */
- sext = (int64_t)addr >> 47;
+ sext = la57 ? (int64_t)addr >> 56 : (int64_t)addr >> 47;
if (sext != 0 && sext != -1) {
env->error_code = 0;
cs->exception_index = EXCP0D_GPF;
return 1;
}
- pml4e_addr = ((env->cr[3] & ~0xfff) + (((addr >> 39) & 0x1ff) << 3)) &
- env->a20_mask;
+ if (la57) {
+ pml5e_addr = ((env->cr[3] & ~0xfff) +
+ (((addr >> 48) & 0x1ff) << 3)) & env->a20_mask;
+ pml5e = x86_ldq_phys(cs, pml5e_addr);
+ if (!(pml5e & PG_PRESENT_MASK)) {
+ goto do_fault;
+ }
+ if (pml5e & (rsvd_mask | PG_PSE_MASK)) {
+ goto do_fault_rsvd;
+ }
+ if (!(pml5e & PG_ACCESSED_MASK)) {
+ pml5e |= PG_ACCESSED_MASK;
+ x86_stl_phys_notdirty(cs, pml5e_addr, pml5e);
+ }
+ ptep = pml5e ^ PG_NX_MASK;
+ } else {
+ pml5e = env->cr[3];
+ ptep = PG_NX_MASK | PG_USER_MASK | PG_RW_MASK;
+ }
+
+ pml4e_addr = ((pml5e & PG_ADDRESS_MASK) +
+ (((addr >> 39) & 0x1ff) << 3)) & env->a20_mask;
pml4e = x86_ldq_phys(cs, pml4e_addr);
if (!(pml4e & PG_PRESENT_MASK)) {
goto do_fault;
@@ -781,7 +803,7 @@ int x86_cpu_handle_mmu_fault(CPUState *cs, vaddr addr,
pml4e |= PG_ACCESSED_MASK;
x86_stl_phys_notdirty(cs, pml4e_addr, pml4e);
}
- ptep = pml4e ^ PG_NX_MASK;
+ ptep &= pml4e ^ PG_NX_MASK;
pdpe_addr = ((pml4e & PG_ADDRESS_MASK) + (((addr >> 30) & 0x1ff) << 3)) &
env->a20_mask;
pdpe = x86_ldq_phys(cs, pdpe_addr);
@@ -1024,16 +1046,30 @@ hwaddr x86_cpu_get_phys_page_debug(CPUState *cs, vaddr addr)
#ifdef TARGET_X86_64
if (env->hflags & HF_LMA_MASK) {
+ bool la57 = env->cr[4] & CR4_LA57_MASK;
+ uint64_t pml5e_addr, pml5e;
uint64_t pml4e_addr, pml4e;
int32_t sext;
/* test virtual address sign extension */
- sext = (int64_t)addr >> 47;
+ sext = la57 ? (int64_t)addr >> 56 : (int64_t)addr >> 47;
if (sext != 0 && sext != -1) {
return -1;
}
- pml4e_addr = ((env->cr[3] & ~0xfff) + (((addr >> 39) & 0x1ff) << 3)) &
- env->a20_mask;
+
+ if (la57) {
+ pml5e_addr = ((env->cr[3] & ~0xfff) +
+ (((addr >> 48) & 0x1ff) << 3)) & env->a20_mask;
+ pml5e = x86_ldq_phys(cs, pml5e_addr);
+ if (!(pml5e & PG_PRESENT_MASK)) {
+ return -1;
+ }
+ } else {
+ pml5e = env->cr[3];
+ }
+
+ pml4e_addr = ((pml5e & PG_ADDRESS_MASK) +
+ (((addr >> 39) & 0x1ff) << 3)) & env->a20_mask;
pml4e = x86_ldq_phys(cs, pml4e_addr);
if (!(pml4e & PG_PRESENT_MASK)) {
return -1;
diff --git a/target/i386/monitor.c b/target/i386/monitor.c
index 9a3b4d7..468aa07 100644
--- a/target/i386/monitor.c
+++ b/target/i386/monitor.c
@@ -30,13 +30,18 @@
#include "hmp.h"
-static void print_pte(Monitor *mon, hwaddr addr,
- hwaddr pte,
- hwaddr mask)
+static void print_pte(Monitor *mon, CPUArchState *env, hwaddr addr,
+ hwaddr pte, hwaddr mask)
{
#ifdef TARGET_X86_64
- if (addr & (1ULL << 47)) {
- addr |= -1LL << 48;
+ if (env->cr[4] & CR4_LA57_MASK) {
+ if (addr & (1ULL << 56)) {
+ addr |= -1LL << 57;
+ }
+ } else {
+ if (addr & (1ULL << 47)) {
+ addr |= -1LL << 48;
+ }
}
#endif
monitor_printf(mon, TARGET_FMT_plx ": " TARGET_FMT_plx
@@ -66,13 +71,13 @@ static void tlb_info_32(Monitor *mon, CPUArchState *env)
if (pde & PG_PRESENT_MASK) {
if ((pde & PG_PSE_MASK) && (env->cr[4] & CR4_PSE_MASK)) {
/* 4M pages */
- print_pte(mon, (l1 << 22), pde, ~((1 << 21) - 1));
+ print_pte(mon, env, (l1 << 22), pde, ~((1 << 21) - 1));
} else {
for(l2 = 0; l2 < 1024; l2++) {
cpu_physical_memory_read((pde & ~0xfff) + l2 * 4, &pte, 4);
pte = le32_to_cpu(pte);
if (pte & PG_PRESENT_MASK) {
- print_pte(mon, (l1 << 22) + (l2 << 12),
+ print_pte(mon, env, (l1 << 22) + (l2 << 12),
pte & ~PG_PSE_MASK,
~0xfff);
}
@@ -100,7 +105,7 @@ static void tlb_info_pae32(Monitor *mon, CPUArchState *env)
if (pde & PG_PRESENT_MASK) {
if (pde & PG_PSE_MASK) {
/* 2M pages with PAE, CR4.PSE is ignored */
- print_pte(mon, (l1 << 30 ) + (l2 << 21), pde,
+ print_pte(mon, env, (l1 << 30) + (l2 << 21), pde,
~((hwaddr)(1 << 20) - 1));
} else {
pt_addr = pde & 0x3fffffffff000ULL;
@@ -108,7 +113,7 @@ static void tlb_info_pae32(Monitor *mon, CPUArchState *env)
cpu_physical_memory_read(pt_addr + l3 * 8, &pte, 8);
pte = le64_to_cpu(pte);
if (pte & PG_PRESENT_MASK) {
- print_pte(mon, (l1 << 30 ) + (l2 << 21)
+ print_pte(mon, env, (l1 << 30) + (l2 << 21)
+ (l3 << 12),
pte & ~PG_PSE_MASK,
~(hwaddr)0xfff);
@@ -122,61 +127,82 @@ static void tlb_info_pae32(Monitor *mon, CPUArchState *env)
}
#ifdef TARGET_X86_64
-static void tlb_info_64(Monitor *mon, CPUArchState *env)
+static void tlb_info_la48(Monitor *mon, CPUArchState *env,
+ uint64_t l0, uint64_t pml4_addr)
{
uint64_t l1, l2, l3, l4;
uint64_t pml4e, pdpe, pde, pte;
- uint64_t pml4_addr, pdp_addr, pd_addr, pt_addr;
+ uint64_t pdp_addr, pd_addr, pt_addr;
- pml4_addr = env->cr[3] & 0x3fffffffff000ULL;
for (l1 = 0; l1 < 512; l1++) {
cpu_physical_memory_read(pml4_addr + l1 * 8, &pml4e, 8);
pml4e = le64_to_cpu(pml4e);
- if (pml4e & PG_PRESENT_MASK) {
- pdp_addr = pml4e & 0x3fffffffff000ULL;
- for (l2 = 0; l2 < 512; l2++) {
- cpu_physical_memory_read(pdp_addr + l2 * 8, &pdpe, 8);
- pdpe = le64_to_cpu(pdpe);
- if (pdpe & PG_PRESENT_MASK) {
- if (pdpe & PG_PSE_MASK) {
- /* 1G pages, CR4.PSE is ignored */
- print_pte(mon, (l1 << 39) + (l2 << 30), pdpe,
- 0x3ffffc0000000ULL);
- } else {
- pd_addr = pdpe & 0x3fffffffff000ULL;
- for (l3 = 0; l3 < 512; l3++) {
- cpu_physical_memory_read(pd_addr + l3 * 8, &pde, 8);
- pde = le64_to_cpu(pde);
- if (pde & PG_PRESENT_MASK) {
- if (pde & PG_PSE_MASK) {
- /* 2M pages, CR4.PSE is ignored */
- print_pte(mon, (l1 << 39) + (l2 << 30) +
- (l3 << 21), pde,
- 0x3ffffffe00000ULL);
- } else {
- pt_addr = pde & 0x3fffffffff000ULL;
- for (l4 = 0; l4 < 512; l4++) {
- cpu_physical_memory_read(pt_addr
- + l4 * 8,
- &pte, 8);
- pte = le64_to_cpu(pte);
- if (pte & PG_PRESENT_MASK) {
- print_pte(mon, (l1 << 39) +
- (l2 << 30) +
- (l3 << 21) + (l4 << 12),
- pte & ~PG_PSE_MASK,
- 0x3fffffffff000ULL);
- }
- }
- }
- }
- }
+ if (!(pml4e & PG_PRESENT_MASK)) {
+ continue;
+ }
+
+ pdp_addr = pml4e & 0x3fffffffff000ULL;
+ for (l2 = 0; l2 < 512; l2++) {
+ cpu_physical_memory_read(pdp_addr + l2 * 8, &pdpe, 8);
+ pdpe = le64_to_cpu(pdpe);
+ if (!(pdpe & PG_PRESENT_MASK)) {
+ continue;
+ }
+
+ if (pdpe & PG_PSE_MASK) {
+ /* 1G pages, CR4.PSE is ignored */
+ print_pte(mon, env, (l0 << 48) + (l1 << 39) + (l2 << 30),
+ pdpe, 0x3ffffc0000000ULL);
+ continue;
+ }
+
+ pd_addr = pdpe & 0x3fffffffff000ULL;
+ for (l3 = 0; l3 < 512; l3++) {
+ cpu_physical_memory_read(pd_addr + l3 * 8, &pde, 8);
+ pde = le64_to_cpu(pde);
+ if (!(pde & PG_PRESENT_MASK)) {
+ continue;
+ }
+
+ if (pde & PG_PSE_MASK) {
+ /* 2M pages, CR4.PSE is ignored */
+ print_pte(mon, env, (l0 << 48) + (l1 << 39) + (l2 << 30) +
+ (l3 << 21), pde, 0x3ffffffe00000ULL);
+ continue;
+ }
+
+ pt_addr = pde & 0x3fffffffff000ULL;
+ for (l4 = 0; l4 < 512; l4++) {
+ cpu_physical_memory_read(pt_addr
+ + l4 * 8,
+ &pte, 8);
+ pte = le64_to_cpu(pte);
+ if (pte & PG_PRESENT_MASK) {
+ print_pte(mon, env, (l0 << 48) + (l1 << 39) +
+ (l2 << 30) + (l3 << 21) + (l4 << 12),
+ pte & ~PG_PSE_MASK, 0x3fffffffff000ULL);
}
}
}
}
}
}
+
+static void tlb_info_la57(Monitor *mon, CPUArchState *env)
+{
+ uint64_t l0;
+ uint64_t pml5e;
+ uint64_t pml5_addr;
+
+ pml5_addr = env->cr[3] & 0x3fffffffff000ULL;
+ for (l0 = 0; l0 < 512; l0++) {
+ cpu_physical_memory_read(pml5_addr + l0 * 8, &pml5e, 8);
+ pml5e = le64_to_cpu(pml5e);
+ if (pml5e & PG_PRESENT_MASK) {
+ tlb_info_la48(mon, env, l0, pml5e & 0x3fffffffff000ULL);
+ }
+ }
+}
#endif /* TARGET_X86_64 */
void hmp_info_tlb(Monitor *mon, const QDict *qdict)
@@ -192,7 +218,11 @@ void hmp_info_tlb(Monitor *mon, const QDict *qdict)
if (env->cr[4] & CR4_PAE_MASK) {
#ifdef TARGET_X86_64
if (env->hflags & HF_LMA_MASK) {
- tlb_info_64(mon, env);
+ if (env->cr[4] & CR4_LA57_MASK) {
+ tlb_info_la57(mon, env);
+ } else {
+ tlb_info_la48(mon, env, 0, env->cr[3] & 0x3fffffffff000ULL);
+ }
} else
#endif
{
@@ -324,7 +354,7 @@ static void mem_info_pae32(Monitor *mon, CPUArchState *env)
#ifdef TARGET_X86_64
-static void mem_info_64(Monitor *mon, CPUArchState *env)
+static void mem_info_la48(Monitor *mon, CPUArchState *env)
{
int prot, last_prot;
uint64_t l1, l2, l3, l4;
@@ -400,6 +430,98 @@ static void mem_info_64(Monitor *mon, CPUArchState *env)
/* Flush last range */
mem_print(mon, &start, &last_prot, (hwaddr)1 << 48, 0);
}
+
+static void mem_info_la57(Monitor *mon, CPUArchState *env)
+{
+ int prot, last_prot;
+ uint64_t l0, l1, l2, l3, l4;
+ uint64_t pml5e, pml4e, pdpe, pde, pte;
+ uint64_t pml5_addr, pml4_addr, pdp_addr, pd_addr, pt_addr, start, end;
+
+ pml5_addr = env->cr[3] & 0x3fffffffff000ULL;
+ last_prot = 0;
+ start = -1;
+ for (l0 = 0; l0 < 512; l0++) {
+ cpu_physical_memory_read(pml5_addr + l0 * 8, &pml5e, 8);
+ pml4e = le64_to_cpu(pml5e);
+ end = l0 << 48;
+ if (!(pml5e & PG_PRESENT_MASK)) {
+ prot = 0;
+ mem_print(mon, &start, &last_prot, end, prot);
+ continue;
+ }
+
+ pml4_addr = pml5e & 0x3fffffffff000ULL;
+ for (l1 = 0; l1 < 512; l1++) {
+ cpu_physical_memory_read(pml4_addr + l1 * 8, &pml4e, 8);
+ pml4e = le64_to_cpu(pml4e);
+ end = (l0 << 48) + (l1 << 39);
+ if (!(pml4e & PG_PRESENT_MASK)) {
+ prot = 0;
+ mem_print(mon, &start, &last_prot, end, prot);
+ continue;
+ }
+
+ pdp_addr = pml4e & 0x3fffffffff000ULL;
+ for (l2 = 0; l2 < 512; l2++) {
+ cpu_physical_memory_read(pdp_addr + l2 * 8, &pdpe, 8);
+ pdpe = le64_to_cpu(pdpe);
+ end = (l0 << 48) + (l1 << 39) + (l2 << 30);
+ if (pdpe & PG_PRESENT_MASK) {
+ prot = 0;
+ mem_print(mon, &start, &last_prot, end, prot);
+ continue;
+ }
+
+ if (pdpe & PG_PSE_MASK) {
+ prot = pdpe & (PG_USER_MASK | PG_RW_MASK |
+ PG_PRESENT_MASK);
+ prot &= pml4e;
+ mem_print(mon, &start, &last_prot, end, prot);
+ continue;
+ }
+
+ pd_addr = pdpe & 0x3fffffffff000ULL;
+ for (l3 = 0; l3 < 512; l3++) {
+ cpu_physical_memory_read(pd_addr + l3 * 8, &pde, 8);
+ pde = le64_to_cpu(pde);
+ end = (l0 << 48) + (l1 << 39) + (l2 << 30) + (l3 << 21);
+ if (pde & PG_PRESENT_MASK) {
+ prot = 0;
+ mem_print(mon, &start, &last_prot, end, prot);
+ continue;
+ }
+
+ if (pde & PG_PSE_MASK) {
+ prot = pde & (PG_USER_MASK | PG_RW_MASK |
+ PG_PRESENT_MASK);
+ prot &= pml4e & pdpe;
+ mem_print(mon, &start, &last_prot, end, prot);
+ continue;
+ }
+
+ pt_addr = pde & 0x3fffffffff000ULL;
+ for (l4 = 0; l4 < 512; l4++) {
+ cpu_physical_memory_read(pt_addr + l4 * 8, &pte, 8);
+ pte = le64_to_cpu(pte);
+ end = (l0 << 48) + (l1 << 39) + (l2 << 30) +
+ (l3 << 21) + (l4 << 12);
+ if (pte & PG_PRESENT_MASK) {
+ prot = pte & (PG_USER_MASK | PG_RW_MASK |
+ PG_PRESENT_MASK);
+ prot &= pml4e & pdpe & pde;
+ } else {
+ prot = 0;
+ }
+ mem_print(mon, &start, &last_prot, end, prot);
+ }
+ }
+ }
+ }
+ }
+ /* Flush last range */
+ mem_print(mon, &start, &last_prot, (hwaddr)1 << 57, 0);
+}
#endif /* TARGET_X86_64 */
void hmp_info_mem(Monitor *mon, const QDict *qdict)
@@ -415,7 +537,11 @@ void hmp_info_mem(Monitor *mon, const QDict *qdict)
if (env->cr[4] & CR4_PAE_MASK) {
#ifdef TARGET_X86_64
if (env->hflags & HF_LMA_MASK) {
- mem_info_64(mon, env);
+ if (env->cr[4] & CR4_LA57_MASK) {
+ mem_info_la57(mon, env);
+ } else {
+ mem_info_la48(mon, env);
+ }
} else
#endif
{
--
2.9.3
^ permalink raw reply related
* [PATCH] arm64: defconfig: enable XORv2 for Marvell Armada 7K/8K
From: Thomas Petazzoni @ 2016-12-22 15:24 UTC (permalink / raw)
To: linux-arm-kernel
This commit enables the XORv2 DMA driver, which is used on the ARM64
Marvell Armada 7K and 8K platforms.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
arch/arm64/configs/defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index dab2cb0..f8b6435 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -371,6 +371,7 @@ CONFIG_RTC_DRV_TEGRA=y
CONFIG_RTC_DRV_XGENE=y
CONFIG_RTC_DRV_S3C=y
CONFIG_DMADEVICES=y
+CONFIG_MV_XOR_V2=y
CONFIG_PL330_DMA=y
CONFIG_TEGRA20_APB_DMA=y
CONFIG_QCOM_BAM_DMA=y
--
2.7.4
^ permalink raw reply related
* Re: [Qemu-devel] [PATCH] smbios: filter based on CONFIG_SMBIOS rather than TARGET
From: Paolo Bonzini @ 2016-12-22 15:25 UTC (permalink / raw)
To: Leif Lindholm, qemu-devel
Cc: Igor Mammedov, Michael S . Tsirkin, Peter Maydell
In-Reply-To: <20161222151828.28292-1-leif.lindholm@linaro.org>
On 22/12/2016 16:18, Leif Lindholm wrote:
> -smbios command line options were accepted but silently ignored on
> TARGET_ARM, due to a test for TARGET_I386 in arch_init.c.
>
> Copy the mechanism of hw/pci/pci-stub.c to implement an smbios-stub
> instead, enabled for all targets without CONFIG_SMBIOS.
>
> Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org>
> ---
>
> Not sure if Suggested-by: Paolo Bonzini <pbonzini@redhat.com>
> is semantically correct in this instance, but if it is, please
> add it.
>
> arch_init.c | 8 --------
> hw/Makefile.objs | 2 +-
> hw/smbios/Makefile.objs | 3 +++
> hw/smbios/smbios-stub.c | 31 +++++++++++++++++++++++++++++++
> hw/smbios/smbios.c | 2 +-
> include/hw/smbios/smbios.h | 2 +-
> vl.c | 2 +-
> 7 files changed, 38 insertions(+), 12 deletions(-)
> create mode 100644 hw/smbios/smbios-stub.c
>
> diff --git a/arch_init.c b/arch_init.c
> index 5cc58b2..34e7694 100644
> --- a/arch_init.c
> +++ b/arch_init.c
> @@ -28,7 +28,6 @@
> #include "sysemu/arch_init.h"
> #include "hw/pci/pci.h"
> #include "hw/audio/audio.h"
> -#include "hw/smbios/smbios.h"
> #include "qemu/config-file.h"
> #include "qemu/error-report.h"
> #include "qmp-commands.h"
> @@ -248,13 +247,6 @@ void do_acpitable_option(const QemuOpts *opts)
> #endif
> }
>
> -void do_smbios_option(QemuOpts *opts)
> -{
> -#ifdef TARGET_I386
> - smbios_entry_add(opts);
> -#endif
> -}
> -
> int kvm_available(void)
> {
> #ifdef CONFIG_KVM
> diff --git a/hw/Makefile.objs b/hw/Makefile.objs
> index 0ffd281..2a73ae5 100644
> --- a/hw/Makefile.objs
> +++ b/hw/Makefile.objs
> @@ -33,7 +33,7 @@ devices-dirs-$(CONFIG_VIRTIO) += virtio/
> devices-dirs-$(CONFIG_SOFTMMU) += watchdog/
> devices-dirs-$(CONFIG_SOFTMMU) += xen/
> devices-dirs-$(CONFIG_MEM_HOTPLUG) += mem/
> -devices-dirs-$(CONFIG_SMBIOS) += smbios/
> +devices-dirs-$(CONFIG_SOFTMMU) += smbios/
> devices-dirs-y += core/
> common-obj-y += $(devices-dirs-y)
> obj-y += $(devices-dirs-y)
> diff --git a/hw/smbios/Makefile.objs b/hw/smbios/Makefile.objs
> index c3d3753..ee0712b 100644
> --- a/hw/smbios/Makefile.objs
> +++ b/hw/smbios/Makefile.objs
> @@ -1,2 +1,5 @@
> common-obj-$(CONFIG_SMBIOS) += smbios.o
> common-obj-$(call land,$(CONFIG_SMBIOS),$(CONFIG_IPMI)) += smbios_type_38.o
> +
> +common-obj-$(call lnot,$(CONFIG_SMBIOS)) += smbios-stub.o
> +common-obj-$(CONFIG_ALL) += smbios-stub.o
> diff --git a/hw/smbios/smbios-stub.c b/hw/smbios/smbios-stub.c
> new file mode 100644
> index 0000000..3087394
> --- /dev/null
> +++ b/hw/smbios/smbios-stub.c
> @@ -0,0 +1,31 @@
> +/*
> + * SMBIOS stubs for platforms that don't support SMBIOS.
> + *
> + * Copyright (c) 2010 Isaku Yamahata <yamahata at valinux co jp>
> + * VA Linux Systems Japan K.K.
> + * Copyright (c) 2016 Leif Lindholm <leif.lindholm@linaro.org>
> + * Linaro Ltd.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License along
> + * with this program; if not, see <http://www.gnu.org/licenses/>.
> + */
> +
> +#include "qemu/osdep.h"
> +#include "qapi/qmp/qerror.h"
> +#include "qmp-commands.h"
> +#include "hw/smbios/smbios.h"
> +
> +void smbios_entry_add(QemuOpts *opts, Error **errp)
> +{
> + error_setg(errp, QERR_UNSUPPORTED);
> +}
> diff --git a/hw/smbios/smbios.c b/hw/smbios/smbios.c
> index 3a96ced..1a5437a 100644
> --- a/hw/smbios/smbios.c
> +++ b/hw/smbios/smbios.c
> @@ -882,7 +882,7 @@ static void save_opt(const char **dest, QemuOpts *opts, const char *name)
> }
> }
>
> -void smbios_entry_add(QemuOpts *opts)
> +void smbios_entry_add(QemuOpts *opts, Error **errp)
> {
> const char *val;
>
> diff --git a/include/hw/smbios/smbios.h b/include/hw/smbios/smbios.h
> index 1cd53cc..31e8d5f 100644
> --- a/include/hw/smbios/smbios.h
> +++ b/include/hw/smbios/smbios.h
> @@ -257,7 +257,7 @@ struct smbios_type_127 {
> struct smbios_structure_header header;
> } QEMU_PACKED;
>
> -void smbios_entry_add(QemuOpts *opts);
> +void smbios_entry_add(QemuOpts *opts, Error **errp);
> void smbios_set_cpuid(uint32_t version, uint32_t features);
> void smbios_set_defaults(const char *manufacturer, const char *product,
> const char *version, bool legacy_mode,
> diff --git a/vl.c b/vl.c
> index d77dd86..d2a0d75 100644
> --- a/vl.c
> +++ b/vl.c
> @@ -3711,7 +3711,7 @@ int main(int argc, char **argv, char **envp)
> if (!opts) {
> exit(1);
> }
> - do_smbios_option(opts);
> + smbios_entry_add(opts, &error_abort);
This should be error_fatal. Will fix and apply.
Paolo
> break;
> case QEMU_OPTION_fwcfg:
> opts = qemu_opts_parse_noisily(qemu_find_opts("fw_cfg"),
>
^ permalink raw reply
* Re: [PATCH v4 00/23] Decouple ethdev from PCI device
From: Thomas Monjalon @ 2016-12-22 15:26 UTC (permalink / raw)
To: Jan Blunck; +Cc: dev, shreyansh.jain, david.marchand, stephen
In-Reply-To: <1482332986-7599-1-git-send-email-jblunck@infradead.org>
2016-12-21 16:09, Jan Blunck:
> This is a partial merge of Stephens and my patches to make the rte_eth_dev
> independent of the rte_pci_device.
Thanks for the hard work.
> Jan Blunck (17):
> eal: define container_of macro
> eal: Allow passing const rte_intr_handle
> virtio: Don't fill dev_info->driver_name
> virtio: Add vtpci_intr_handle() helper to get rte_intr_handle
> virtio: Don't depend on struct rte_eth_dev's pci_dev
> bnx2x: localize mapping from eth_dev to pci
> fm10k: localize mapping from eth_dev to pci
> qede: localize mapping of eth_dev to pci
> szedata2: localize handling of pci resources
> nfp: localize rte_pci_device handling
> vmxnet3: use eth_dev->data->drv_name instead of pci_drv name
> ethdev: Helper to map to struct rte_pci_device
> drivers: Replace per-PMD macros with rte_eth_dev_to_pci() helper
> drivers: Use rte_eth_dev_to_pci() helper
> ethdev: Move filling of rte_eth_dev_info->pci_dev to dev_infos_get()
> ethdev: Decouple interrupt handling from PCI device
> ethdev: Decouple struct rte_eth_dev from struct rte_pci_device
>
> Stephen Hemminger (6):
> rte_device: make driver pointer const
> pmd: remove useless reset of dev_info->dev_pci
> e1000: localize mapping from eth_dev to pci
> ixgbe: localize mapping from eth_dev to pci_device
> i40e: localize mapping of eth_dev to pci
> broadcom: localize mapping from eth_dev to pci
I think it would easier to read if RTE_PCI_DEV macro was introduced at
the beginning with container_of macro and used in the "localize patches".
So the patches
[PATCH v4 19/23] drivers: Replace per-PMD macros with rte_eth_dev_to_pci() helper
and
[PATCH v4 20/23] drivers: Use rte_eth_dev_to_pci() helper
could be squashed in the "localize patches".
^ permalink raw reply
* Re: [PATCH] drm/i915: Revoke partial fences when installing on the scanout
From: Chris Wilson @ 2016-12-22 15:26 UTC (permalink / raw)
To: intel-gfx; +Cc: Daniel Vetter, Zanoni, Paulo R
In-Reply-To: <20161222135224.11886-1-chris@chris-wilson.co.uk>
On Thu, Dec 22, 2016 at 01:52:24PM +0000, Chris Wilson wrote:
> In commit 50349247ea80 ("drm/i915: Drop ORIGIN_GTT for untracked GTT
> writes") partial mmaps were updated to indicate that writes through them
> were not tracked automatically by the hardware and that the expected
> subsequent manual invalidations by the application (on calling dirtyfb at
> the end of the frame) take over from the hardware tracking. However, not
> all applications actually call dirtyfb on the scanout after they dirty it
> and so those writes through partial GTT mmaps are not being tracked and
> triggering FBC updates.
>
> Fixes: a61007a83a46 ("drm/i915: Fix partial GGTT faulting")
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> Cc: Daniel Vetter <daniel.vetter@intel.com>
> Cc: "Zanoni, Paulo R" <paulo.r.zanoni@intel.com>
> ---
> drivers/gpu/drm/i915/i915_gem.c | 25 ++++++++++++++++++++-----
> drivers/gpu/drm/i915/i915_gem_object.h | 2 ++
> drivers/gpu/drm/i915/intel_display.c | 10 +++++++++-
> 3 files changed, 31 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index f379c5484a84..d51c9b209837 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -1882,11 +1882,6 @@ int i915_gem_fault(struct vm_area_struct *area, struct vm_fault *vmf)
> compute_partial_view(obj, area,
> page_offset, MIN_CHUNK_PAGES);
>
> - /* Userspace is now writing through an untracked VMA, abandon
> - * all hope that the hardware is able to track future writes.
> - */
> - obj->frontbuffer_ggtt_origin = ORIGIN_CPU;
> -
> vma = i915_gem_object_ggtt_pin(obj, &view, 0, 0, PIN_MAPPABLE);
> }
> if (IS_ERR(vma)) {
> @@ -2015,6 +2010,26 @@ i915_gem_release_mmap(struct drm_i915_gem_object *obj)
> intel_runtime_pm_put(i915);
> }
>
> +bool i915_gem_object_has_partial_fences(struct drm_i915_gem_object *obj)
> +{
> + struct i915_vma *vma;
> +
> + lockdep_assert_held(&obj->base.dev->struct_mutex);
> +
> + list_for_each_entry(vma, &obj->vma_list, obj_link) {
> + if (!i915_vma_is_ggtt(vma))
> + break;
> +
> + if (vma->ggtt_view.type != I915_GGTT_VIEW_NORMAL)
if (vma->ggtt_view.type == I915_GGTT_VIEW_NORMAL)
> + continue;
Ofc.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* [PATCH RFC] tools/xenlight: Create xenlight Makefile
From: Ronald Rojas @ 2016-12-22 15:26 UTC (permalink / raw)
Cc: Wei Liu, Ronald Rojas, George Dunlap, Ian Jackson, George Dunlap,
xen-devel
Create a basic Makefile to build and install libxenlight Golang
bindings. Also add a stub package.
---
Eventually this patch will contain the actual bindings package; for
now it just includes a stub package.
To Do:
- Have configure detect golang bindings properly
CC: xen-devel <xen-devel@lists.xen.org>
CC: Ian Jackson <ian.jackson@eu.citrix.com>
CC: Wei Liu <wei.liu2@citrix.com>
CC: George Dunlap <george.dunlap@citrix.com>
CC: George Dunlap <dunlapg@umich.edu>
---
tools/Makefile | 16 ++++++++++++++++
tools/golang/Makefile | 29 +++++++++++++++++++++++++++++
tools/golang/xenlight/xenlight.go | 7 +++++++
3 files changed, 52 insertions(+)
create mode 100644 tools/golang/Makefile
create mode 100644 tools/golang/xenlight/xenlight.go
diff --git a/tools/Makefile b/tools/Makefile
index 71515b4..f2198e0 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -11,6 +11,8 @@ SUBDIRS-y += misc
SUBDIRS-y += examples
SUBDIRS-y += hotplug
SUBDIRS-y += xentrace
+SUBDIRS-y += golang
+#FIXME: Have golang controlled by a configure variable
SUBDIRS-$(CONFIG_XCUTILS) += xcutils
SUBDIRS-$(CONFIG_X86) += firmware
SUBDIRS-y += console
@@ -311,6 +313,20 @@ subdir-install-debugger/gdbsx: .phony
subdir-all-debugger/gdbsx: .phony
$(MAKE) -C debugger/gdbsx all
+subdir-all-golang/xenlight: .phony
+ $(MAKE) -C golang all
+
+subdir-clean-golang/xenlight: .phony
+ $(MAKE) -C golang clean
+
+subdir-install-golang/xenlight: .phony
+ $(MAKE) -C golang install
+
+subdir-build-golang/xenlight: .phony
+ $(MAKE) -C golang build
+
+subdir-distclean-golang/xenlight: .phony
+ $(MAKE) -C golang distclean
subdir-clean-debugger/kdd subdir-distclean-debugger/kdd: .phony
$(MAKE) -C debugger/kdd clean
diff --git a/tools/golang/Makefile b/tools/golang/Makefile
new file mode 100644
index 0000000..96589c8
--- /dev/null
+++ b/tools/golang/Makefile
@@ -0,0 +1,29 @@
+XEN_ROOT=$(CURDIR)/../..
+GOLANG_SRC=$(GOPATH)/src/xenproject.org/xenlight
+include $(XEN_ROOT)/tools/Rules.mk
+
+BINARY = xenlight.a
+GO ?= go
+
+.PHONY: all
+all: build
+
+.PHONY: build
+build: xenlight/xenlight.a
+
+.PHONY: install
+install: build
+ $(INSTALL_DIR) $(DESTDIR)$(GOLANG_SRC)
+ $(INSTALL_DATA) xenlight/xenlight.go $(DESTDIR)$(GOLANG_SRC)
+
+.PHONY: clean
+clean:
+ $(RM) xenlight/$(BINARY)
+
+.PHONY: distclean
+distclean: clean
+
+xenlight/xenlight.a: xenlight/xenlight.go
+ $(GO) build -o $@ $<
+
+-include $(DEPS)
diff --git a/tools/golang/xenlight/xenlight.go b/tools/golang/xenlight/xenlight.go
new file mode 100644
index 0000000..9136676
--- /dev/null
+++ b/tools/golang/xenlight/xenlight.go
@@ -0,0 +1,7 @@
+package xenlight
+
+import "fmt"
+
+func main() {
+ fmt.Println("go")
+}
--
2.7.4
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply related
* Re: [PATCHSET v4] blk-mq-scheduling framework
From: Paolo Valente @ 2016-12-22 15:28 UTC (permalink / raw)
To: Jens Axboe
Cc: Jens Axboe, linux-block, Linux-Kernal, Omar Sandoval,
Linus Walleij, Ulf Hansson, Mark Brown
In-Reply-To: <f5303f81-811a-8d0a-b271-d091d8839778@fb.com>
> Il giorno 19 dic 2016, alle ore 22:05, Jens Axboe <axboe@fb.com> ha =
scritto:
>=20
> On 12/19/2016 11:21 AM, Paolo Valente wrote:
>>=20
>>> Il giorno 19 dic 2016, alle ore 16:20, Jens Axboe <axboe@fb.com> ha =
scritto:
>>>=20
>>> On 12/19/2016 04:32 AM, Paolo Valente wrote:
>>>>=20
>>>>> Il giorno 17 dic 2016, alle ore 01:12, Jens Axboe <axboe@fb.com> =
ha scritto:
>>>>>=20
>>>>> This is version 4 of this patchset, version 3 was posted here:
>>>>>=20
>>>>> https://marc.info/?l=3Dlinux-block&m=3D148178513407631&w=3D2
>>>>>=20
>>>>> =46rom the discussion last time, I looked into the feasibility of =
having
>>>>> two sets of tags for the same request pool, to avoid having to =
copy
>>>>> some of the request fields at dispatch and completion time. To do =
that,
>>>>> we'd have to replace the driver tag map(s) with our own, and =
augment
>>>>> that with tag map(s) on the side representing the device queue =
depth.
>>>>> Queuing IO with the scheduler would allocate from the new map, and
>>>>> dispatching would acquire the "real" tag. We would need to change
>>>>> drivers to do this, or add an extra indirection table to map a =
real
>>>>> tag to the scheduler tag. We would also need a 1:1 mapping between
>>>>> scheduler and hardware tag pools, or additional info to track it.
>>>>> Unless someone can convince me otherwise, I think the current =
approach
>>>>> is cleaner.
>>>>>=20
>>>>> I wasn't going to post v4 so soon, but I discovered a bug that led
>>>>> to drastically decreased merging. Especially on rotating storage,
>>>>> this release should be fast, and on par with the merging that we
>>>>> get through the legacy schedulers.
>>>>>=20
>>>>=20
>>>> I'm to modifying bfq. You mentioned other missing pieces to come. =
Do
>>>> you already have an idea of what they are, so that I am somehow
>>>> prepared to what won't work even if my changes are right?
>>>=20
>>> I'm mostly talking about elevator ops hooks that aren't there in the =
new
>>> framework, but exist in the old one. There should be no hidden
>>> surprises, if that's what you are worried about.
>>>=20
>>> On the ops side, the only ones I can think of are the activate and
>>> deactivate, and those can be done in the dispatch_request hook for
>>> activate, and put/requeue for deactivate.
>>>=20
>>=20
>> You mean that there is no conceptual problem in moving the code of =
the
>> activate interface function into the dispatch function, and the code
>> of the deactivate into the put_request? (for a requeue it is a little
>> less clear to me, so one step at a time) Or am I missing
>> something more complex?
>=20
> Yes, what I mean is that there isn't a 1:1 mapping between the old ops
> and the new ops. So you'll have to consider the cases.
>=20
>=20
Problem: whereas it seems easy and safe to do somewhere else the
simple increment that was done in activate_request, I wonder if it may
happen that a request is deactivate before being completed. In it may
happen, then, without a deactivate_request hook, the increments would
remain unbalanced. Or are request completions always guaranteed till
no hw/sw components breaks?
Thanks,
Paolo=20
> --=20
> Jens Axboe
>=20
> --
> To unsubscribe from this list: send the line "unsubscribe linux-block" =
in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] tools/tests/x86_emulate: #define unlikely in x86 emulator test harness
From: Jan Beulich @ 2016-12-22 15:28 UTC (permalink / raw)
To: Ian Jackson; +Cc: Andrew Cooper, xen-devel
In-Reply-To: <22619.60674.552999.879417@mariner.uk.xensource.com>
>>> On 22.12.16 at 16:10, <ian.jackson@eu.citrix.com> wrote:
> I did not find this important build fix for a regression in 4.8.0
> because:
I wonder why you consider this important - the harness doesn't
get built by default, and is of little use for other than smoke
testing a limited set of changes to the insn emulator.
> Backporting this is made more awkward by the decision to make the fix
> a portmanteau. Do the x86 maintainers intend to provide a
> ready-to-use backport or shall I try to prepare one ?
I've pushed one a minute ago to 4.8-staging.
> For now, is there any reason why I should not use my change
> +#define unlikely(x) (x)
> in an upload to Debian ?
I don't see anything speaking against that.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply
* Re: [PATCHSET v4] blk-mq-scheduling framework
From: Paolo Valente @ 2016-12-22 15:28 UTC (permalink / raw)
To: Jens Axboe
Cc: Jens Axboe, linux-block, Linux-Kernal, Omar Sandoval,
Linus Walleij, Ulf Hansson, Mark Brown
In-Reply-To: <f5303f81-811a-8d0a-b271-d091d8839778@fb.com>
> Il giorno 19 dic 2016, alle ore 22:05, Jens Axboe <axboe@fb.com> ha scritto:
>
> On 12/19/2016 11:21 AM, Paolo Valente wrote:
>>
>>> Il giorno 19 dic 2016, alle ore 16:20, Jens Axboe <axboe@fb.com> ha scritto:
>>>
>>> On 12/19/2016 04:32 AM, Paolo Valente wrote:
>>>>
>>>>> Il giorno 17 dic 2016, alle ore 01:12, Jens Axboe <axboe@fb.com> ha scritto:
>>>>>
>>>>> This is version 4 of this patchset, version 3 was posted here:
>>>>>
>>>>> https://marc.info/?l=linux-block&m=148178513407631&w=2
>>>>>
>>>>> From the discussion last time, I looked into the feasibility of having
>>>>> two sets of tags for the same request pool, to avoid having to copy
>>>>> some of the request fields at dispatch and completion time. To do that,
>>>>> we'd have to replace the driver tag map(s) with our own, and augment
>>>>> that with tag map(s) on the side representing the device queue depth.
>>>>> Queuing IO with the scheduler would allocate from the new map, and
>>>>> dispatching would acquire the "real" tag. We would need to change
>>>>> drivers to do this, or add an extra indirection table to map a real
>>>>> tag to the scheduler tag. We would also need a 1:1 mapping between
>>>>> scheduler and hardware tag pools, or additional info to track it.
>>>>> Unless someone can convince me otherwise, I think the current approach
>>>>> is cleaner.
>>>>>
>>>>> I wasn't going to post v4 so soon, but I discovered a bug that led
>>>>> to drastically decreased merging. Especially on rotating storage,
>>>>> this release should be fast, and on par with the merging that we
>>>>> get through the legacy schedulers.
>>>>>
>>>>
>>>> I'm to modifying bfq. You mentioned other missing pieces to come. Do
>>>> you already have an idea of what they are, so that I am somehow
>>>> prepared to what won't work even if my changes are right?
>>>
>>> I'm mostly talking about elevator ops hooks that aren't there in the new
>>> framework, but exist in the old one. There should be no hidden
>>> surprises, if that's what you are worried about.
>>>
>>> On the ops side, the only ones I can think of are the activate and
>>> deactivate, and those can be done in the dispatch_request hook for
>>> activate, and put/requeue for deactivate.
>>>
>>
>> You mean that there is no conceptual problem in moving the code of the
>> activate interface function into the dispatch function, and the code
>> of the deactivate into the put_request? (for a requeue it is a little
>> less clear to me, so one step at a time) Or am I missing
>> something more complex?
>
> Yes, what I mean is that there isn't a 1:1 mapping between the old ops
> and the new ops. So you'll have to consider the cases.
>
>
Problem: whereas it seems easy and safe to do somewhere else the
simple increment that was done in activate_request, I wonder if it may
happen that a request is deactivate before being completed. In it may
happen, then, without a deactivate_request hook, the increments would
remain unbalanced. Or are request completions always guaranteed till
no hw/sw components breaks?
Thanks,
Paolo
> --
> Jens Axboe
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-block" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v3] ethdev: cleanup device ops struct whitespace
From: Thomas Monjalon @ 2016-12-22 15:28 UTC (permalink / raw)
To: Ferruh Yigit; +Cc: Jan Blunck, dev
In-Reply-To: <26b1177f-93c3-d3c3-fa63-e971af8dd139@intel.com>
2016-12-22 15:16, Ferruh Yigit:
> On 12/22/2016 3:10 PM, Jan Blunck wrote:
> > On Thu, Dec 22, 2016 at 2:10 PM, Ferruh Yigit <ferruh.yigit@intel.com> wrote:
> >> - Grouped related items using empty lines
> >
> > Reordering fields of a struct is breaking ABI. We should bump the
> > library version now.
>
> You are right, sorry missed that.
> Intention was not to break the ABI, but cleanup.
>
> Thomas,
> If it is too late, do you want me prepare a revert patch?
No
Please check doc/guides/rel_notes/deprecation.rst
We are going to break the ethdev ABI anyway.
^ permalink raw reply
* [PATCH] xfsprogs: fix a couple 32-bit build warnings
From: Eric Sandeen @ 2016-12-22 15:28 UTC (permalink / raw)
To: linux-xfs
on 32-bit builds:
mremap_f can't turn a long long into a pointer, and
dump_dirent needs proper %llx & a cast for u64 args
as is done elsewhere.
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
---
diff --git a/io/mmap.c b/io/mmap.c
index dc188d0..6f1d330 100644
--- a/io/mmap.c
+++ b/io/mmap.c
@@ -628,8 +628,8 @@ mremap_f(
switch (c) {
case 'f':
flags = MREMAP_FIXED|MREMAP_MAYMOVE;
- new_addr = (void *)cvtnum(blocksize, sectsize,
- optarg);
+ new_addr = (void *)(unsigned long)cvtnum(blocksize,
+ sectsize, optarg);
break;
case 'm':
flags = MREMAP_MAYMOVE;
diff --git a/io/readdir.c b/io/readdir.c
index 151b72e..b868d1b 100644
--- a/io/readdir.c
+++ b/io/readdir.c
@@ -71,9 +71,10 @@ dump_dirent(
long long offset,
struct dirent *dirent)
{
- printf("%08llx: d_ino: 0x%08lx", offset, dirent->d_ino);
+ printf("%08llx: d_ino: 0x%08llx", offset,
+ (unsigned long long)dirent->d_ino);
#ifdef _DIRENT_HAVE_D_OFF
- printf(" d_off: 0x%08lx", dirent->d_off);
+ printf(" d_off: 0x%08llx", (unsigned long long)dirent->d_off);
#endif
#ifdef _DIRENT_HAVE_D_RECLEN
printf(" d_reclen: 0x%x", dirent->d_reclen);
^ permalink raw reply related
* Re: [PATCH] xsm: allow relevant permission during migrate and gpu-passthrough.
From: Doug Goldstein @ 2016-12-22 15:28 UTC (permalink / raw)
To: Anshul Makkar, Daniel De Graaf, xen-devel
Cc: wei.liu2, ian.jackson, Jan Beulich
In-Reply-To: <bd9338f4-f6f0-5554-6d45-aab7962005f7@citrix.com>
[-- Attachment #1.1.1: Type: text/plain, Size: 1175 bytes --]
On 12/20/16 3:37 AM, Anshul Makkar wrote:
> On 20/12/2016 04:03, Doug Goldstein wrote:
>> On 12/19/16 10:02 AM, Doug Goldstein wrote:
>>> On 12/14/16 3:09 PM, Daniel De Graaf wrote:
>>>> On 12/12/2016 09:00 AM, Anshul Makkar wrote:
>>>>> During guest migrate allow permission to prevent
>>>>> spurious page faults.
>>>>> Prevents these errors:
>>>>> d73: Non-privileged (73) attempt to map I/O space 00000000
>>>>>
>>>>> avc: denied { set_misc_info } for domid=0 target=11
>>>>> scontext=system_u:system_r:dom0_t
>>>>> tcontext=system_u:system_r:domU_t tclass=domain
>>>>>
>>>>> GPU passthrough for hvm guest:
>>>>> avc: denied { send_irq } for domid=0 target=10
>>>>> scontext=system_u:system_r:dom0_t
>>>>> tcontext=system_u:system_r:domU_t tclass=hvm
>>>>>
>>>>> Signed-off-by: Anshul Makkar <anshul.makkar@citrix.com>
>>>>
>>>> Acked-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
>>>>
>>>
>>> Daniel,
>>>
>>> Should this be backported to 4.8?
>>>
>>
>> FWIW, Daniel's email is bouncing. Anshul, do you want to test/confirm?
>>
>
> Doug, yes, will backport and test.
>
> Anshul
CCing Jan for the backport.
--
Doug Goldstein
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 959 bytes --]
[-- Attachment #2: Type: text/plain, Size: 127 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply
* Re: [PATCH v4 3/5] i2c: designware: Add slave definitions
From: Andy Shevchenko @ 2016-12-22 15:29 UTC (permalink / raw)
To: Luis Oliveira, Rob Herring
Cc: wsa@the-dreams.de, mark.rutland@arm.com,
jarkko.nikula@linux.intel.com, mika.westerberg@linux.intel.com,
linux-i2c@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, Ramiro.Oliveira@synopsys.com,
Joao.Pinto@synopsys.com, CARLOS.PALMINHA@synopsys.com
In-Reply-To: <3ef11852-8dc5-dbb3-7dc3-1ec8f4fc58da@synopsys.com>
On Thu, 2016-12-22 at 14:59 +0000, Luis Oliveira wrote:
> On 13-Dec-16 14:11, Rob Herring wrote:
> > Something like this:
> >
> > of_for_each_child_node(child) {
> > of_property_read_u32(child, "reg", ®);
> > if (reg & I2C_OWN_SLAVE_ADDRESS))
> > im_a_slave = true;
> > }
> >
> > ...rather than testing "mode" is equal to "slave".
> >
> > Rob
> >
>
> Hi Rob, Andy,
>
> I'm struggling to implement your suggestion @Rob. I checked the
> tegra124-jetson-tk1.dts that uses that approach but I have some
> doubts.
>
> My DT is as follows
>
> i2c@0x2000 {
> compatible = "snps,designware-i2c";
> reg = <0x2000 0x100>;
> clock-frequency = <400000>;
> clocks = <&i2cclk>;
> interrupts = <0>;
>
> I could add something like this:
>
> eeprom@64 {
> compatible = "linux,slave-24c02";
> reg = <(I2C_OWN_SLAVE_ADDRESS | 0x64)>;
> }
>
> But I think this is different form what I was doing before. I have two
> questions:
>
> - This way the I2C controller is identified as a slave controller or
> just the
> subnode eeprom?
> - This way looks like my slave address will be fixed
>
> In the previous Patch v3 submission @Andy suggested a property that
> selects mode
> that I did and it's working. And you @Rob suggested to do it a common
> property.
> It is implemented in the DT like:
>
> mode = "slave";
>
> So before I do this changes can you please agree both if you still
> think this is
> the best approach?
I'm a bit lost in the discussion (and TBH busy by something else), so I
would agree on whatever you and Rob make an agreement on.
--
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Intel Finland Oy
^ permalink raw reply
* Re: [kernel-hardening] Re: [PATCH v7 3/6] random: use SipHash in place of MD5
From: Jason A. Donenfeld @ 2016-12-22 15:29 UTC (permalink / raw)
To: Hannes Frederic Sowa
Cc: kernel-hardening, Theodore Ts'o, Andy Lutomirski, Netdev,
LKML, Linux Crypto Mailing List, David Laight, Eric Dumazet,
Linus Torvalds, Eric Biggers, Tom Herbert, Andi Kleen,
David S. Miller, Jean-Philippe Aumasson
In-Reply-To: <CAHmME9qZviooxOW+e=khazG0phSEWwZyKj=eayre_7hs8d+cQw@mail.gmail.com>
On Thu, Dec 22, 2016 at 4:12 PM, Jason A. Donenfeld <Jason@zx2c4.com> wrote:
> As a first step, I'm considering adding a patch to move halfmd4.c
> inside the ext4 domain, or at the very least, simply remove it from
> linux/cryptohash.h. That'll then leave the handful of bizarre sha1
> usages to consider.
Specifically something like this:
https://git.zx2c4.com/linux-dev/commit/?h=siphash&id=978213351f9633bd1e3d1fdc3f19d28e36eeac90
That only leaves two more uses of "cryptohash" to consider, but they
require a bit of help. First, sha_transform in net/ipv6/addrconf.c.
That might be a straight-forward conversion to SipHash, but perhaps
not; I need to look closely and think about it. The next is
sha_transform in kernel/bpf/core.c. I really have no idea what's going
on with the eBPF stuff, so that will take a bit longer to study. Maybe
sha1 is fine in the end there? I'm not sure yet.
^ permalink raw reply
* Re: [PATCH] docs: Clarify scope of reboot= and noreboot Xen command line options
From: Jan Beulich @ 2016-12-22 15:30 UTC (permalink / raw)
To: Ian Jackson; +Cc: xen-devel
In-Reply-To: <1482418973-26941-1-git-send-email-ian.jackson@eu.citrix.com>
>>> On 22.12.16 at 16:02, <ian.jackson@eu.citrix.com> wrote:
> @@ -1356,7 +1357,9 @@ The following resources are available:
>
> > Default: `0`
>
> -Specify the host reboot method.
> +Specify the host reboot method,
> +used when Xen crashes.
> +(This does not affect deliberate reboots initiated by dom0.)
This should be moved down to where `no` is being described, as
it affects only that sub-option. The reboot methods, otoh, affect
all kinds of reboots.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply
* Re: [PATCH v2 0/5] example/ethtool: add bus info and fw version get
From: Thomas Monjalon @ 2016-12-22 15:31 UTC (permalink / raw)
To: Ferruh Yigit; +Cc: Qiming Yang, dev, Remy Horton
In-Reply-To: <095d7632-fbb7-a72b-8a48-163ed2b32cb4@intel.com>
2016-12-22 15:05, Ferruh Yigit:
> On 12/22/2016 2:47 PM, Thomas Monjalon wrote:
> > 2016-12-22 14:36, Ferruh Yigit:
> >> On 12/22/2016 11:07 AM, Thomas Monjalon wrote:
> >>> I think it is OK to add a new dev_ops and a new API function for firmware
> >>> query. Generally speaking, it is a good thing to avoid putting all
> >>> informations in the same structure (e.g. rte_eth_dev_info).
> >>
> >> OK.
> >>
> >>> However, there
> >>> is a balance to find. Could we plan to add more info to this new query?
> >>> Instead of
> >>> rte_eth_dev_fwver_get(uint8_t port_id, char *fw_version, int fw_length)
> > [...]
> >>> could it fill a struct?
> >>> rte_eth_dev_fw_info_get(uint8_t port_id, struct rte_eth_dev_fw_info *fw_info)
> >>
> >> I believe this is better. But the problem we are having with this usage
> >> is: ABI breakage.
> >>
> >> Since this struct will be a public structure, in the future if we want
> >> to add a new field to the struct, it will break the ABI, and just this
> >> change will cause a new version for whole ethdev library!
> >>
> >> When all required fields received via arguments, one by one, instead of
> >> struct, at least ABI versioning can be done on the API when new field
> >> added, and can be possible to escape from ABI breakage. But this will be
> >> ugly when number of arguments increased.
> >>
> >> Or any other opinion on how to define API to reduce ABI breakage?
> >
> > You're right.
> > But I don't think we should have a function per data. Just because it would
> > be ugly :)
>
> I am no suggesting function per data, instead something like:
>
> rte_eth_dev_fw_info_get(uint8_t port_id, uint32_t maj, uint32_t min);
>
> And in the future if we need etrack_id too, we can have both in
> versioned manner:
>
> rte_eth_dev_fw_info_get(uint8_t port_id, uint32_t maj, uint32_t min);
>
> rte_eth_dev_fw_info_get(uint8_t port_id, uint32_t maj, uint32_t min,
> uint32_t etrack_id);
Oh I see. So it can be versioned with compat macros.
> So my concern was if the number of the arguments becomes too many by time.
It looks to be a good proposal. We should not have a dozen of arguments.
^ permalink raw reply
* Re: [PATCH 02/22] inotify: Remove inode pointers from debug messages
From: Amir Goldstein @ 2016-12-22 15:31 UTC (permalink / raw)
To: Jan Kara; +Cc: linux-fsdevel, Lino Sanfilippo, Miklos Szeredi, Paul Moore
In-Reply-To: <20161222091538.28702-3-jack@suse.cz>
On Thu, Dec 22, 2016 at 11:15 AM, Jan Kara <jack@suse.cz> wrote:
> Printing inode pointers in warnings has dubious value and with future
> changes we won't be able to easily get them without either locking or
> chances we oops along the way. So just remove inode pointers from the
> warning messages.
>
> Signed-off-by: Jan Kara <jack@suse.cz>
Reviewed-by: Amir Goldstein <amir73il@gmail.com>
^ permalink raw reply
* Re: [PATCH 2/3] fs/pstore: fs/squashfs: Change lz4 compressor functions to work with new version
From: Sven Schmidt @ 2016-12-22 15:31 UTC (permalink / raw)
To: sergey.senozhatsky
Cc: akpm, bongkyu.kim, gregkh, ccross, keescook, anton, linux-kernel,
tony.luck, Sven Schmidt
In-Reply-To: <20161222132109.GA413@tigerII.localdomain>
On 12/22/2016 02:21 PM, Sergey Senozhatsky wrote:
> On (12/20/16 19:53), Sven Schmidt wrote:
>> @@ -366,7 +366,7 @@ static int decompress_lz4(void *in, void *out, size_t inlen, size_t outlen)
>>
>> static void allocate_lz4(void)
>> {
>> - big_oops_buf_sz = lz4_compressbound(psinfo->bufsize);
>> + big_oops_buf_sz = LZ4_compressBound(psinfo->bufsize);
>> big_oops_buf = kmalloc(big_oops_buf_sz, GFP_KERNEL);
>> if (big_oops_buf) {
>> workspace = kmalloc(LZ4_MEM_COMPRESS, GFP_KERNEL);
>> @@ -493,7 +493,6 @@ static void pstore_dump(struct kmsg_dumper *dumper,
>> if (!is_locked) {
>> pr_err("pstore dump routine blocked in %s path, may corrupt error record\n"
>> , in_nmi() ? "NMI" : why);
>> - return;
>
> why did you remove this "failed to lock buf in critical path" return?
>
>
>> }
>> } else {
>> spin_lock_irqsave(&psinfo->buf_lock, flags);
>> @@ -585,8 +584,8 @@ static void pstore_console_write(struct console *con, const char *s, unsigned c)
>> } else {
>> spin_lock_irqsave(&psinfo->buf_lock, flags);
>> }
>> - psinfo->write_buf(PSTORE_TYPE_CONSOLE, 0, &id, 0,
>> - s, 0, c, psinfo);
>> + memcpy(psinfo->buf, s, c);
>> + psinfo->write(PSTORE_TYPE_CONSOLE, 0, &id, 0, 0, 0, c, psinfo);
>
> why extra memcpy()?
>
> -ss
>
>> spin_unlock_irqrestore(&psinfo->buf_lock, flags);
>> s += c;
>> c = e - s;
>> diff --git a/fs/squashfs/lz4_wrapper.c b/fs/squashfs/lz4_wrapper.c
>> index ff4468b..c087a63 100644
>> --- a/fs/squashfs/lz4_wrapper.c
>> +++ b/fs/squashfs/lz4_wrapper.c
>> @@ -108,8 +108,7 @@ static int lz4_uncompress(struct squashfs_sb_info *msblk, void *strm,
>> put_bh(bh[i]);
>> }
>>
>> - res = lz4_decompress_unknownoutputsize(stream->input, length,
>> - stream->output, &dest_len);
>> + res = LZ4_decompress_safe(stream->input, stream->output, length, (int)dest_len);
>> if (res)
>> return -EIO;
>
Hey Sergey and thanks for your time. I'm afraid I messed up the diffstat on this.
Actually I just replaced the function calls and corrected the use of return values.
I will send an updated patchset later since there also have been errors
reported from the buildbots.
Sven
^ permalink raw reply
* Re: [kernel-hardening] Re: [PATCH v7 3/6] random: use SipHash in place of MD5
From: Hannes Frederic Sowa @ 2016-12-22 15:33 UTC (permalink / raw)
To: Jason A. Donenfeld
Cc: kernel-hardening, Theodore Ts'o, Andy Lutomirski, Netdev,
LKML, Linux Crypto Mailing List, David Laight, Eric Dumazet,
Linus Torvalds, Eric Biggers, Tom Herbert, Andi Kleen,
David S. Miller, Jean-Philippe Aumasson
In-Reply-To: <CAHmME9pu-2CY2WRHevnpwo-9qnZcTpqQgC2voGFOpSjo+LPiUA@mail.gmail.com>
On Thu, 2016-12-22 at 16:29 +0100, Jason A. Donenfeld wrote:
> On Thu, Dec 22, 2016 at 4:12 PM, Jason A. Donenfeld <Jason@zx2c4.com> wrote:
> > As a first step, I'm considering adding a patch to move halfmd4.c
> > inside the ext4 domain, or at the very least, simply remove it from
> > linux/cryptohash.h. That'll then leave the handful of bizarre sha1
> > usages to consider.
>
> Specifically something like this:
>
> https://git.zx2c4.com/linux-dev/commit/?h=siphash&id=978213351f9633bd1e3d1fdc3f19d28e36eeac90
>
> That only leaves two more uses of "cryptohash" to consider, but they
> require a bit of help. First, sha_transform in net/ipv6/addrconf.c.
> That might be a straight-forward conversion to SipHash, but perhaps
> not; I need to look closely and think about it. The next is
> sha_transform in kernel/bpf/core.c. I really have no idea what's going
> on with the eBPF stuff, so that will take a bit longer to study. Maybe
> sha1 is fine in the end there? I'm not sure yet.
IPv6 you cannot touch anymore. The hashing algorithm is part of uAPI.
You don't want to give people new IPv6 addresses with the same stable
secret (across reboots) after a kernel upgrade. Maybe they lose
connectivity then and it is extra work?
The bpf hash stuff can be changed during this merge window, as it is
not yet in a released kernel. Albeit I would probably have preferred
something like sha256 here, which can be easily replicated by user
space tools (minus the problem of patching out references to not
hashable data, which must be zeroed).
Bye,
Hannes
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.