Re: [Qemu-devel] [PATCH v3 2/4] firmware: use acpi to detect QEMU fw_cfg device for sysfs fw_cfg driver
On Sat, Oct 03, 2015 at 07:28:07PM -0400, Gabriel L. Somlo wrote:
> From: Gabriel Somlo
>
> Instead of blindly probing fw_cfg registers at known IOport and MMIO
> locations, use the ACPI subsystem to determine whether a QEMU fw_cfg
> device is present, and, if found, to initialize it.
>
> This limits portability to architectures which support ACPI (x86 and
> UEFI-enabled aarch64), but avoids touching hardware registers before
> being certain that our device is present.
>
> NOTE: The standard way to verify the presence of fw_cfg on arm VMs
> would have been to use the device tree, but that would have left out
> x86, which is the primary architecture targeted by this patch.
>
> Signed-off-by: Gabriel Somlo
IMHO it's not a good idea to probe registers provided
by CRS like this.
It seems quite reasonable that we'd want to add some
extra registers in the future, and this probing will break.
Further, accessing registers directly means that there's
no way to have ACPI code access them as that would
cause race conditions.
Maybe we should provide access methods in ACPI instead?
> ---
> .../ABI/testing/sysfs-firmware-qemu_fw_cfg | 4 +
> drivers/firmware/Kconfig | 2 +-
> drivers/firmware/qemu_fw_cfg.c | 201
> +++--
> 3 files changed, 113 insertions(+), 94 deletions(-)
>
> diff --git a/Documentation/ABI/testing/sysfs-firmware-qemu_fw_cfg
> b/Documentation/ABI/testing/sysfs-firmware-qemu_fw_cfg
> index f1ef44e..e9761bf 100644
> --- a/Documentation/ABI/testing/sysfs-firmware-qemu_fw_cfg
> +++ b/Documentation/ABI/testing/sysfs-firmware-qemu_fw_cfg
> @@ -76,6 +76,10 @@ Description:
> the port number of the control register. I.e., the two ports
> are overlapping, and can not be mapped separately.
>
> + NOTE 2. QEMU publishes the register details in the device tree
> + on arm guests, and in ACPI (under _HID "QEMU0002") on x86 and
> + select arm (aarch64) VM types.
> +
> === Firmware Configuration Items of Interest ===
>
> Originally, the index key, size, and formatting of blobs in
> diff --git a/drivers/firmware/Kconfig b/drivers/firmware/Kconfig
> index 0466e80..bc12d31 100644
> --- a/drivers/firmware/Kconfig
> +++ b/drivers/firmware/Kconfig
> @@ -137,7 +137,7 @@ config ISCSI_IBFT
>
> config FW_CFG_SYSFS
> tristate "QEMU fw_cfg device support in sysfs"
> - depends on SYSFS
> + depends on SYSFS && ACPI
> default n
> help
> Say Y or M here to enable the exporting of the QEMU firmware
> diff --git a/drivers/firmware/qemu_fw_cfg.c b/drivers/firmware/qemu_fw_cfg.c
> index 3a67a16..f935afb 100644
> --- a/drivers/firmware/qemu_fw_cfg.c
> +++ b/drivers/firmware/qemu_fw_cfg.c
> @@ -8,6 +8,7 @@
> */
>
> #include
> +#include
> #include
> #include
> #include
> @@ -35,53 +36,10 @@ struct fw_cfg_file {
> char name[FW_CFG_MAX_FILE_PATH];
> };
>
> -/* fw_cfg device i/o access options type */
> -struct fw_cfg_access {
> - const char *name;
> - phys_addr_t base;
> - u8 size;
> - u8 ctrl_offset;
> - u8 data_offset;
> - bool is_mmio;
> -};
> -
> -/* table of fw_cfg device i/o access options for known architectures */
> -static struct fw_cfg_access fw_cfg_modes[] = {
> - {
> - .name = "fw_cfg IOport on i386, sun4u",
> - .base = 0x510,
> - .size = 0x02,
> - .ctrl_offset = 0x00,
> - .data_offset = 0x01,
> - .is_mmio = false,
> - }, {
> - .name = "fw_cfg MMIO on arm",
> - .base = 0x902,
> - .size = 0x0a,
> - .ctrl_offset = 0x08,
> - .data_offset = 0x00,
> - .is_mmio = true,
> - }, {
> - .name = "fw_cfg MMIO on sun4m",
> - .base = 0xd0510,
> - .size = 0x03,
> - .ctrl_offset = 0x00,
> - .data_offset = 0x02,
> - .is_mmio = true,
> - }, {
> - .name = "fw_cfg MMIO on ppc/mac",
> - .base = 0xf510,
> - .size = 0x03,
> - .ctrl_offset = 0x00,
> - .data_offset = 0x02,
> - .is_mmio = true,
> - }, { } /* END */
> -};
> -
> -/* fw_cfg device i/o currently selected option set */
> -static struct fw_cfg_access *fw_cfg_mode;
> -
> /* fw_cfg device i/o register addresses */
> +static bool fw_cfg_is_mmio;
> +static phys_addr_t fw_cfg_phys_base;
> +static u32 fw_cfg_phys_size;
> static void __iomem *fw_cfg_dev_base;
> static void __iomem *fw_cfg_reg_ctrl;
> static void __iomem *fw_cfg_reg_data;
> @@ -92,7 +50,7 @@ static DEFINE_MUTEX(fw_cfg_dev_lock);
> /* pick appropriate endianness for selector key */
> static inline u16 fw_cfg_sel_endianness(u16 key)
> {
> - return fw_cfg_mode->is_mmio ? cpu_to_be16(key) : cpu_to_le16(key);
> + return fw_cfg_is_mmio ? cpu_to_be16(key)
Re: [Qemu-devel] [PATCH v2] exec: factor out duplicate mmap code
On Fri, Oct 02, 2015 at 10:48:13AM +1000, Richard Henderson wrote:
> On 10/01/2015 10:58 PM, Michael S. Tsirkin wrote:
> >Anonymous and file-backed RAM allocation are now almost exactly the same.
> >
> >Reduce code duplication by moving RAM mmap code out of oslib-posix.c and
> >exec.c.
> >
> >Reported-by: Marc-André Lureau
> >Signed-off-by: Michael S. Tsirkin
> >Reviewed-by: Paolo Bonzini
> >Acked-by: Paolo Bonzini
> >---
> >
> >Changes from v1: add shared flag to get MAP_SHARED mappings
> >(for vhost-user), only set MAP_ANONYMOUS for anonymous RAM.
> >
> > include/qemu/mmap-alloc.h | 10 +++
> > exec.c| 47 +++
> > util/mmap-alloc.c | 71
> > +++
> > util/oslib-posix.c| 28 +++
> > util/Makefile.objs| 2 +-
> > 5 files changed, 96 insertions(+), 62 deletions(-)
> > create mode 100644 include/qemu/mmap-alloc.h
> > create mode 100644 util/mmap-alloc.c
> >
> >diff --git a/include/qemu/mmap-alloc.h b/include/qemu/mmap-alloc.h
> >new file mode 100644
> >index 000..56388e6
> >--- /dev/null
> >+++ b/include/qemu/mmap-alloc.h
> >@@ -0,0 +1,10 @@
> >+#ifndef QEMU_MMAP_ALLOC
> >+#define QEMU_MMAP_ALLOC
> >+
> >+#include "qemu-common.h"
> >+
> >+void *qemu_ram_mmap(int fd, size_t size, size_t align, bool shared);
> >+
> >+void qemu_ram_munmap(void *ptr, size_t size);
> >+
> >+#endif
> >diff --git a/exec.c b/exec.c
> >index 7d90a52..4505dc7 100644
> >--- a/exec.c
> >+++ b/exec.c
> >@@ -55,6 +55,9 @@
> > #include "exec/ram_addr.h"
> >
> > #include "qemu/range.h"
> >+#ifndef _WIN32
> >+#include "qemu/mmap-alloc.h"
> >+#endif
> >
> > //#define DEBUG_SUBPAGE
> >
> >@@ -84,9 +87,9 @@ static MemoryRegion io_mem_unassigned;
> > */
> > #define RAM_RESIZEABLE (1 << 2)
> >
> >-/* An extra page is mapped on top of this RAM.
> >+/* RAM is backed by an mmapped file.
> > */
> >-#define RAM_EXTRA (1 << 3)
> >+#define RAM_FILE (1 << 3)
> > #endif
> >
> > struct CPUTailQ cpus = QTAILQ_HEAD_INITIALIZER(cpus);
> >@@ -1188,13 +1191,10 @@ static void *file_ram_alloc(RAMBlock *block,
> > char *filename;
> > char *sanitized_name;
> > char *c;
> >-void *ptr;
> >-void *area = NULL;
> >+void *area;
> > int fd;
> > uint64_t hpagesize;
> >-uint64_t total;
> > Error *local_err = NULL;
> >-size_t offset;
> >
> > hpagesize = gethugepagesize(path, &local_err);
> > if (local_err) {
> >@@ -1238,7 +1238,6 @@ static void *file_ram_alloc(RAMBlock *block,
> > g_free(filename);
> >
> > memory = ROUND_UP(memory, hpagesize);
> >-total = memory + hpagesize;
> >
> > /*
> > * ftruncate is not supported by hugetlbfs in older
> >@@ -1250,40 +1249,14 @@ static void *file_ram_alloc(RAMBlock *block,
> > perror("ftruncate");
> > }
> >
> >-ptr = mmap(0, total, PROT_NONE, MAP_PRIVATE | MAP_ANONYMOUS,
> >--1, 0);
> >-if (ptr == MAP_FAILED) {
> >-error_setg_errno(errp, errno,
> >- "unable to allocate memory range for hugepages");
> >-close(fd);
> >-goto error;
> >-}
> >-
> >-offset = QEMU_ALIGN_UP((uintptr_t)ptr, hpagesize) - (uintptr_t)ptr;
> >-
> >-area = mmap(ptr + offset, memory, PROT_READ | PROT_WRITE,
> >-(block->flags & RAM_SHARED ? MAP_SHARED : MAP_PRIVATE) |
> >-MAP_FIXED,
> >-fd, 0);
> >+area = qemu_ram_mmap(fd, memory, hpagesize, block->flags & RAM_SHARED);
> > if (area == MAP_FAILED) {
> > error_setg_errno(errp, errno,
> > "unable to map backing store for hugepages");
> >-munmap(ptr, total);
> > close(fd);
> > goto error;
> > }
> >
> >-if (offset > 0) {
> >-munmap(ptr, offset);
> >-}
> >-ptr += offset;
> >-total -= offset;
> >-
> >-if (total > memory + getpagesize()) {
> >-munmap(ptr + memory + getpagesize(),
> >- total - memory - getpagesize());
> >-}
> >-
> > if (mem_prealloc) {
> > os_mem_prealloc(fd, area, memory);
> > }
> >@@ -1601,7 +1574,7 @@ ram_addr_t qemu_ram_alloc_from_file(ram_addr_t size,
> >MemoryRegion *mr,
> > new_block->used_length = size;
> > new_block->max_length = size;
> > new_block->flags = share ? RAM_SHARED : 0;
> >-new_block->flags |= RAM_EXTRA;
> >+new_block->flags |= RAM_FILE;
> > new_block->host = file_ram_alloc(new_block, size,
> > mem_path, errp);
> > if (!new_block->host) {
> >@@ -1703,8 +1676,8 @@ static void reclaim_ramblock(RAMBlock *block)
> > xen_invalidate_map_cache_entry(block->host);
> > #ifndef _WIN32
> > } else if (block->fd >= 0) {
> >-if (block->flags & RAM_EXTRA) {
> >-munmap(block->host, block->max_length + getpagesize());
> >+if (block->flags & RAM_FILE) {
> >+
Re: [Qemu-devel] [PATCH v7 03/24] util: add linux-only memfd fallback
On Fri, Oct 02, 2015 at 05:57:34PM +0200, Paolo Bonzini wrote: > > Will be easier to apply if this refactoring is a separate patch. > > Is someone doing anything conflicting in this area? (My answer: not > that I know of). Yes - I'm trying to refactor mmap-alloc, that's why I asked for this. Conflicts between file additions are easier for me to resolve. And btw compatfd.o is already separate, this would just make everything consistent. -- MST
[Qemu-devel] [Bug 921208] Re: win7/x64 installer hangs on startup with 0x0000005d.
Any news regarding this issue ? I applied the first patch, but I'm unsure how to apply the second patch. I get either DRIVER_IRQL_NOT_LESS_OR_EQUAL or KMODE_EXCEPTION_NOT_HANDLED during the Windows 7 x64 install. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/921208 Title: win7/x64 installer hangs on startup with 0x005d. Status in QEMU: Confirmed Status in qemu package in Ubuntu: Triaged Bug description: hi, during booting win7/x64 installer i'm observing a bsod with 0x005d ( msdn: unsupported_processor ). used command line: qemu-system-x86_64 -m 2048 -hda w7-system.img -cdrom win7_x64.iso -boot d adding '-machine accel=kvm' instead of default tcg accel helps to boot. installed software: qemu-1.0 linux-3.2.1 glibc-2.14.1 gcc-4.6.2 hw cpu: processor : 0..7 vendor_id : GenuineIntel cpu family : 6 model : 42 model name : Intel(R) Core(TM) i7-2630QM CPU @ 2.00GHz stepping: 7 microcode : 0x14 cpu MHz : 1995.739 cache size : 6144 KB physical id : 0 siblings: 8 core id : 3 cpu cores : 4 apicid : 7 initial apicid : 7 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer xsave avx lahf_lm ida arat epb xsaveopt pln pts dts tpr_shadow vnmi flexpriority ept vpid bogomips: 3992.23 clflush size: 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/921208/+subscriptions
Re: [Qemu-devel] QEMU+Linux ARMv7A current state
On 3 October 2015 at 23:14, Peter Crosthwaite wrote: > On Sat, Oct 3, 2015 at 2:51 PM, Peter Maydell > wrote: >> Did you build your kernel with LPAE or not? I think an LPAE >> config ought to avoid the PCI highmem bug (and it's definitely >> what you want for anything that's Cortex-A15 based). >> > > No. Although any missing configs I consider to be our problem, or a > bug in the multi_v7_defconfig in upstream Linux. That defconfig really > should work for us. IIRC you can't build a kernel for both LPAE and non-LPAE at once -- the two are mutually exclusive. >> For real hardware I expect people will be using USB disks. >> We don't currently model the USB controller in QEMU, though. > > Looks like a custom job too. Not much chance here unless this is a > rebadging of one of the existing HCIs? It's a Philips ISP1761. I think it's EHCI + USB OTG + probably some minor registers. It could be modelled in theory... >> "realview" is not really a very helpful term to use here, because >> it's a generic label applied to a whole slew of ARM devboards. >> What QEMU models is: >> "realview-eb" -- the RealView Emulation Baseboard with an ARM926 >> "realview-eb-mpcore" -- the RealView Emulation Baseboard with an 11MPCore >> "realview-pb-a8" -- the RealView Platform Baseboard for Cortex A8 >> "realview-pbx-a9" -- the RealView Platform Baseboard Explore for Cortex A9 >> >> The DT in the kernel tree is for the Realview Platform Baseboard >> for 1176, ie PB1176. That's a different board from EB1176, as >> you've found. This is why "realview" on its own (or with a CPU >> name) is not sufficient to identify a board and why we have those >> -eb- and -pb(x)- infixes in our board names :-) >> > > So does this mean that the EB memory maps are consistent but perhaps > not the PB? Can we reliably gen all combinations with EB vs PB with > just two memory maps, then add 1176 both ways? I think the PB1176 looks more like the PB926 (which we model as "versatilepb") than the PBA8 or PBXA9 -- for instance the latter two have a completely different PCI controller. You'd need to cross-check all the board manuals to be sure. Regardless, rather than implementing a model of yet another old ARM devboard nobody really cares about, it seems to me that the effort would be better spent in converting the kernel support for the boards we already model to use device tree... thanks -- PMM
Re: [Qemu-devel] [Qemu-discuss] TCP options ipv4 and ipv6 have no effect
On 03/10/2015 00:36, Peter Maydell wrote:
>
> I agree about the (!ipv4 || !ipv6) condition though.
> The three states I listed above ought to correspond
> to "qemu_opt not set", "qemu_opt set to false" and
> "qemu_opt set to true",
The problem is that the underlying QemuOpts-based code treats "qemu_opt not
set" and "qemu_opt set to false" the same way:
ipv4 ipv6
Y Y PF_INET6
Y N PF_INET
N Y PF_INET6
N N PF_UNSPEC
We want:
ipv4 ipv6
YY PF_INET6
YN PF_INET
Y- PF_INET (ipv6 = N)
NY PF_INET6
NN PF_UNSPEC
N- PF_INET6(ipv6 = Y)
-Y PF_INET6(ipv4 = N)
-N PF_INET (ipv4 = Y)
-- PF_UNSPEC
I think this patch gets the desired semantics:
diff --git a/util/qemu-sockets.c b/util/qemu-sockets.c
index 2add83a..fdcf3fa 100644
--- a/util/qemu-sockets.c
+++ b/util/qemu-sockets.c
@@ -586,12 +586,15 @@ fail:
static void inet_addr_to_opts(QemuOpts *opts, const InetSocketAddress *addr)
{
-bool ipv4 = addr->ipv4 || !addr->has_ipv4;
-bool ipv6 = addr->ipv6 || !addr->has_ipv6;
+bool ipv4 = addr->has_ipv4 && addr->ipv4;
+bool ipv6 = addr->has_ipv6 && addr->ipv6;
-if (!ipv4 || !ipv6) {
+if (ipv4 || ipv6) {
qemu_opt_set_bool(opts, "ipv4", ipv4, &error_abort);
qemu_opt_set_bool(opts, "ipv6", ipv6, &error_abort);
+} else if (addr->has_ipv4 || addr->has_ipv6) {
+qemu_opt_set_bool(opts, "ipv4", !addr->has_ipv4, &error_abort);
+qemu_opt_set_bool(opts, "ipv6", !addr->has_ipv6, &error_abort);
}
if (addr->has_to) {
qemu_opt_set_number(opts, "to", addr->to, &error_abort);
The first if handles the "default to N" case, the second handles
"default to Y", the (absent) else case handles "default to
PF_UNSPEC".
Paolo
[Qemu-devel] [PATCH v2] target-tilegx: Implement v2mults instruction
From: Chen Gang
Just according to v1multu instruction implementation.
Signed-off-by: Chen Gang
---
target-tilegx/helper.h | 1 +
target-tilegx/simd_helper.c | 13 +
target-tilegx/translate.c | 4
3 files changed, 18 insertions(+)
diff --git a/target-tilegx/helper.h b/target-tilegx/helper.h
index c58ee20..bbcc476 100644
--- a/target-tilegx/helper.h
+++ b/target-tilegx/helper.h
@@ -16,6 +16,7 @@ DEF_HELPER_FLAGS_2(v2int_h, TCG_CALL_NO_RWG_SE, i64, i64, i64)
DEF_HELPER_FLAGS_2(v2int_l, TCG_CALL_NO_RWG_SE, i64, i64, i64)
DEF_HELPER_FLAGS_2(v1multu, TCG_CALL_NO_RWG_SE, i64, i64, i64)
+DEF_HELPER_FLAGS_2(v2mults, TCG_CALL_NO_RWG_SE, i64, i64, i64)
DEF_HELPER_FLAGS_2(v1shl, TCG_CALL_NO_RWG_SE, i64, i64, i64)
DEF_HELPER_FLAGS_2(v1shru, TCG_CALL_NO_RWG_SE, i64, i64, i64)
DEF_HELPER_FLAGS_2(v1shrs, TCG_CALL_NO_RWG_SE, i64, i64, i64)
diff --git a/target-tilegx/simd_helper.c b/target-tilegx/simd_helper.c
index 6fa6318..4f226eb 100644
--- a/target-tilegx/simd_helper.c
+++ b/target-tilegx/simd_helper.c
@@ -41,6 +41,19 @@ uint64_t helper_v1multu(uint64_t a, uint64_t b)
return r;
}
+uint64_t helper_v2mults(uint64_t a, uint64_t b)
+{
+uint64_t r = 0;
+int i;
+
+for (i = 0; i < 64; i += 16) {
+int64_t ae = (int16_t)(a >> i);
+int64_t be = (int16_t)(b >> i);
+r |= ((ae * be) & 0x) << i;
+}
+return r;
+}
+
uint64_t helper_v1shl(uint64_t a, uint64_t b)
{
uint64_t m;
diff --git a/target-tilegx/translate.c b/target-tilegx/translate.c
index 034cbc2..eb2d0b1 100644
--- a/target-tilegx/translate.c
+++ b/target-tilegx/translate.c
@@ -1355,7 +1355,11 @@ static TileExcp gen_rrr_opcode(DisasContext *dc,
unsigned opext,
case OE_RRR(V2MNZ, 0, X1):
case OE_RRR(V2MULFSC, 0, X0):
case OE_RRR(V2MULS, 0, X0):
+return TILEGX_EXCP_OPCODE_UNIMPLEMENTED;
case OE_RRR(V2MULTS, 0, X0):
+gen_helper_v2mults(tdest, tsrca, tsrcb);
+mnemonic = "v2mults";
+break;
case OE_RRR(V2MZ, 0, X0):
case OE_RRR(V2MZ, 0, X1):
case OE_RRR(V2PACKH, 0, X0):
--
1.9.3
[Qemu-devel] [PATCH v2] target-tilegx: Use TILEGX_EXCP_OPCODE_UNKNOWN and TILEGX_EXCP_OPCODE_UNIMPLEMENTED correctly
From: Chen Gang
For some cases, they are for TILEGX_EXCP_OPCODE_UNKNOWN, not for
TILEGX_EXCP_OPCODE_UNIMPLEMENTED.
Also for some cases, they are for TILEGX_EXCP_OPCODE_UNIMPLEMENTED, not
for TILEGX_EXCP_OPCODE_UNKNOWN.
When analyzing issues, the correct printing information is necessary,
e.g. grep UIMP in gcc testsuite output log for finding qemu tilegx
umimplementation issues, grep UNKNOWN for finding unknown instructions.
Signed-off-by: Chen Gang
---
target-tilegx/translate.c | 41 -
1 file changed, 24 insertions(+), 17 deletions(-)
diff --git a/target-tilegx/translate.c b/target-tilegx/translate.c
index eb2d0b1..ab3fc81 100644
--- a/target-tilegx/translate.c
+++ b/target-tilegx/translate.c
@@ -291,7 +291,7 @@ static TileExcp gen_st_opcode(DisasContext *dc, unsigned
dest, unsigned srca,
unsigned srcb, TCGMemOp memop, const char *name)
{
if (dest) {
-return TILEGX_EXCP_OPCODE_UNIMPLEMENTED;
+return TILEGX_EXCP_OPCODE_UNKNOWN;
}
tcg_gen_qemu_st_tl(load_gr(dc, srcb), load_gr(dc, srca),
@@ -538,7 +538,7 @@ static TileExcp gen_rr_opcode(DisasContext *dc, unsigned
opext,
mnemonic = "swint1";
done0:
if (srca || dest) {
-return TILEGX_EXCP_OPCODE_UNIMPLEMENTED;
+return TILEGX_EXCP_OPCODE_UNKNOWN;
}
qemu_log_mask(CPU_LOG_TB_IN_ASM, "%s", mnemonic);
return ret;
@@ -584,7 +584,7 @@ static TileExcp gen_rr_opcode(DisasContext *dc, unsigned
opext,
tcg_gen_andi_tl(dc->jmp.dest, load_gr(dc, srca), ~7);
done1:
if (dest) {
-return TILEGX_EXCP_OPCODE_UNIMPLEMENTED;
+return TILEGX_EXCP_OPCODE_UNKNOWN;
}
qemu_log_mask(CPU_LOG_TB_IN_ASM, "%s %s", mnemonic, reg_names[srca]);
return ret;
@@ -679,7 +679,7 @@ static TileExcp gen_rr_opcode(DisasContext *dc, unsigned
opext,
case OE_RR_X1(LNK):
case OE_RR_Y1(LNK):
if (srca) {
-return TILEGX_EXCP_OPCODE_UNIMPLEMENTED;
+return TILEGX_EXCP_OPCODE_UNKNOWN;
}
tcg_gen_movi_tl(tdest, dc->pc + TILEGX_BUNDLE_SIZE_IN_BYTES);
mnemonic = "lnk";
@@ -723,7 +723,7 @@ static TileExcp gen_rr_opcode(DisasContext *dc, unsigned
opext,
mnemonic = "tblidxb3";
break;
default:
-return TILEGX_EXCP_OPCODE_UNIMPLEMENTED;
+return TILEGX_EXCP_OPCODE_UNKNOWN;
}
qemu_log_mask(CPU_LOG_TB_IN_ASM, "%s %s, %s", mnemonic,
@@ -1453,7 +1453,7 @@ static TileExcp gen_rrr_opcode(DisasContext *dc, unsigned
opext,
mnemonic = "xor";
break;
default:
-return TILEGX_EXCP_OPCODE_UNIMPLEMENTED;
+return TILEGX_EXCP_OPCODE_UNKNOWN;
}
qemu_log_mask(CPU_LOG_TB_IN_ASM, "%s %s, %s, %s", mnemonic,
@@ -1745,7 +1745,7 @@ static TileExcp gen_rri_opcode(DisasContext *dc, unsigned
opext,
break;
default:
-return TILEGX_EXCP_OPCODE_UNIMPLEMENTED;
+return TILEGX_EXCP_OPCODE_UNKNOWN;
}
qemu_log_mask(CPU_LOG_TB_IN_ASM, "%s %s, %s, %d", mnemonic,
@@ -1839,7 +1839,7 @@ static TileExcp gen_bf_opcode_x0(DisasContext *dc,
unsigned ext,
break;
default:
-return TILEGX_EXCP_OPCODE_UNIMPLEMENTED;
+return TILEGX_EXCP_OPCODE_UNKNOWN;
}
qemu_log_mask(CPU_LOG_TB_IN_ASM, "%s %s, %s, %u, %u", mnemonic,
@@ -1895,7 +1895,7 @@ static TileExcp gen_branch_opcode_x1(DisasContext *dc,
unsigned ext,
mnemonic = "blbs";
break;
default:
-return TILEGX_EXCP_OPCODE_UNIMPLEMENTED;
+return TILEGX_EXCP_OPCODE_UNKNOWN;
}
if (qemu_loglevel_mask(CPU_LOG_TB_IN_ASM)) {
@@ -1962,7 +1962,7 @@ static TileExcp gen_mtspr_x1(DisasContext *dc, unsigned
spr, unsigned srca)
if (def == NULL) {
qemu_log_mask(CPU_LOG_TB_IN_ASM, "mtspr spr[%u], %s", spr,
reg_names[srca]);
-return TILEGX_EXCP_OPCODE_UNKNOWN;
+return TILEGX_EXCP_OPCODE_UNIMPLEMENTED;
}
tsrca = load_gr(dc, srca);
@@ -1982,7 +1982,7 @@ static TileExcp gen_mfspr_x1(DisasContext *dc, unsigned
dest, unsigned spr)
if (def == NULL) {
qemu_log_mask(CPU_LOG_TB_IN_ASM, "mtspr %s, spr[%u]", reg_names[dest],
spr);
-return TILEGX_EXCP_OPCODE_UNKNOWN;
+return TILEGX_EXCP_OPCODE_UNIMPLEMENTED;
}
tdest = dest_gr(dc, dest);
@@ -2037,7 +2037,7 @@ static TileExcp decode_y0(DisasContext *dc,
tilegx_bundle_bits bundle)
return gen_rri_opcode(dc, OE(opc, 0, Y0), dest, srca, imm);
default:
-return TILEGX_EXCP_OPCODE_UNIMPLEMENTED;
+return TILEGX_EXCP_OPCODE_UNKNOWN;
}
}
@@ -2081,7 +2081,7 @@ static TileExcp decode_y1(DisasContext *dc,
tilegx_bundle_bits bundle)
return gen_rri_opcode(dc, OE(opc, 0, Y1), dest, srca, imm);
default:
-return TILEGX_EXCP_OPCODE_UNIMPLEMENTED;
+return TILEGX_EXCP_OPCODE_UNKNOWN;
}
}
@@ -
[Qemu-devel] [PATCH v2] target-tilegx: Implement v2sh* instructions
From: Chen Gang It is just according to v1sh* instructions implementation. Signed-off-by: Chen Gang --- target-tilegx/translate.c | 18 +- 1 file changed, 17 insertions(+), 1 deletion(-) diff --git a/target-tilegx/translate.c b/target-tilegx/translate.c index 6ab66f9..9bb8857 100644 --- a/target-tilegx/translate.c +++ b/target-tilegx/translate.c @@ -1686,11 +1686,27 @@ static TileExcp gen_rri_opcode(DisasContext *dc, unsigned opext, break; case OE_SH(V2SHLI, X0): case OE_SH(V2SHLI, X1): +i2 = imm & 15; +i3 = 0x >> i2; +tcg_gen_andi_tl(tdest, tsrca, V2_IMM(i3)); +tcg_gen_shli_tl(tdest, tdest, i2); +mnemonic = "v2shli"; +break; case OE_SH(V2SHRSI, X0): case OE_SH(V2SHRSI, X1): +t0 = tcg_const_tl(imm & 15); +gen_helper_v2shrs(tdest, tsrca, t0); +tcg_temp_free(t0); +mnemonic = "v2shrsi"; +break; case OE_SH(V2SHRUI, X0): case OE_SH(V2SHRUI, X1): -return TILEGX_EXCP_OPCODE_UNIMPLEMENTED; +i2 = imm & 15; +i3 = (0x << i2) & 0x; +tcg_gen_andi_tl(tdest, tsrca, V2_IMM(i3)); +tcg_gen_shri_tl(tdest, tdest, i2); +mnemonic = "v2shrui"; +break; case OE(ADDLI_OPCODE_X0, 0, X0): case OE(ADDLI_OPCODE_X1, 0, X1): -- 1.9.3
[Qemu-devel] [PATCH v2] target-tilegx: Implement v?int_* instructions.
From: Chen Gang
Signed-off-by: Chen Gang
---
target-tilegx/helper.h | 5
target-tilegx/simd_helper.c | 56 +
target-tilegx/translate.c | 14
3 files changed, 75 insertions(+)
diff --git a/target-tilegx/helper.h b/target-tilegx/helper.h
index 82d84f1..c58ee20 100644
--- a/target-tilegx/helper.h
+++ b/target-tilegx/helper.h
@@ -10,6 +10,11 @@ DEF_HELPER_FLAGS_3(cmula, TCG_CALL_NO_RWG_SE, i64, i64, i64,
i64)
DEF_HELPER_FLAGS_3(cmulaf, TCG_CALL_NO_RWG_SE, i64, i64, i64, i64)
DEF_HELPER_FLAGS_4(cmul2, TCG_CALL_NO_RWG_SE, i64, i64, i64, int, int)
+DEF_HELPER_FLAGS_2(v1int_h, TCG_CALL_NO_RWG_SE, i64, i64, i64)
+DEF_HELPER_FLAGS_2(v1int_l, TCG_CALL_NO_RWG_SE, i64, i64, i64)
+DEF_HELPER_FLAGS_2(v2int_h, TCG_CALL_NO_RWG_SE, i64, i64, i64)
+DEF_HELPER_FLAGS_2(v2int_l, TCG_CALL_NO_RWG_SE, i64, i64, i64)
+
DEF_HELPER_FLAGS_2(v1multu, TCG_CALL_NO_RWG_SE, i64, i64, i64)
DEF_HELPER_FLAGS_2(v1shl, TCG_CALL_NO_RWG_SE, i64, i64, i64)
DEF_HELPER_FLAGS_2(v1shru, TCG_CALL_NO_RWG_SE, i64, i64, i64)
diff --git a/target-tilegx/simd_helper.c b/target-tilegx/simd_helper.c
index 23c20bd..6fa6318 100644
--- a/target-tilegx/simd_helper.c
+++ b/target-tilegx/simd_helper.c
@@ -102,3 +102,59 @@ uint64_t helper_v2shrs(uint64_t a, uint64_t b)
}
return r;
}
+
+uint64_t helper_v1int_h(uint64_t a, uint64_t b)
+{
+uint64_t r = 0, tmp;
+int i;
+
+for (i = 0; i < 32; i += 8) {
+tmp = (uint8_t)(a >> (i + 32));
+r |= tmp << (2 * i + 8);
+tmp = (uint8_t)(b >> (i + 32));
+r |= tmp << 2 * i;
+}
+return r;
+}
+
+uint64_t helper_v1int_l(uint64_t a, uint64_t b)
+{
+uint64_t r = 0, tmp;
+int i;
+
+for (i = 0; i < 32; i += 8) {
+tmp = (uint8_t)(a >> i);
+r |= tmp << (2 * i + 8);
+tmp = (uint8_t)(b >> i);
+r |= tmp << 2 * i;
+}
+return r;
+}
+
+uint64_t helper_v2int_h(uint64_t a, uint64_t b)
+{
+uint64_t r = 0, tmp;
+int i;
+
+for (i = 0; i < 32; i += 16) {
+tmp = (uint16_t)(a >> (i + 32));
+r |= tmp << (2 * i + 16);
+tmp = (uint16_t)(b >> (i + 32));
+r |= tmp << 2 * i;
+}
+return r;
+}
+
+uint64_t helper_v2int_l(uint64_t a, uint64_t b)
+{
+uint64_t r = 0, tmp;
+int i;
+
+for (i = 0; i < 32; i += 16) {
+tmp = (uint16_t)(a >> i);
+r |= tmp << (2 * i + 16);
+tmp = (uint16_t)(b >> i);
+r |= tmp << 2 * i;
+}
+return r;
+}
diff --git a/target-tilegx/translate.c b/target-tilegx/translate.c
index 9bb8857..034cbc2 100644
--- a/target-tilegx/translate.c
+++ b/target-tilegx/translate.c
@@ -1260,10 +1260,17 @@ static TileExcp gen_rrr_opcode(DisasContext *dc,
unsigned opext,
case OE_RRR(V1DOTPUS, 0, X0):
case OE_RRR(V1DOTPU, 0, X0):
case OE_RRR(V1DOTP, 0, X0):
+return TILEGX_EXCP_OPCODE_UNIMPLEMENTED;
case OE_RRR(V1INT_H, 0, X0):
case OE_RRR(V1INT_H, 0, X1):
+gen_helper_v1int_h(tdest, tsrca, tsrcb);
+mnemonic = "v1int_h";
+break;
case OE_RRR(V1INT_L, 0, X0):
case OE_RRR(V1INT_L, 0, X1):
+gen_helper_v1int_l(tdest, tsrca, tsrcb);
+mnemonic = "v1int_l";
+break;
case OE_RRR(V1MAXU, 0, X0):
case OE_RRR(V1MAXU, 0, X1):
case OE_RRR(V1MINU, 0, X0):
@@ -1329,10 +1336,17 @@ static TileExcp gen_rrr_opcode(DisasContext *dc,
unsigned opext,
case OE_RRR(V2CMPNE, 0, X1):
case OE_RRR(V2DOTPA, 0, X0):
case OE_RRR(V2DOTP, 0, X0):
+return TILEGX_EXCP_OPCODE_UNIMPLEMENTED;
case OE_RRR(V2INT_H, 0, X0):
case OE_RRR(V2INT_H, 0, X1):
+gen_helper_v2int_h(tdest, tsrca, tsrcb);
+mnemonic = "v2int_h";
+break;
case OE_RRR(V2INT_L, 0, X0):
case OE_RRR(V2INT_L, 0, X1):
+gen_helper_v2int_l(tdest, tsrca, tsrcb);
+mnemonic = "v2int_l";
+break;
case OE_RRR(V2MAXS, 0, X0):
case OE_RRR(V2MAXS, 0, X1):
case OE_RRR(V2MINS, 0, X0):
--
1.9.3
[Qemu-devel] [PATCH v2] target-tilegx: Implement v2sh* instructions
>From be4b6be54c79d9ca22431f749f31e0c7b9fdd091 Mon Sep 17 00:00:00 2001 From: Chen Gang Date: Fri, 2 Oct 2015 09:19:56 +0800 Subject: [PATCH v2] target-tilegx: Implement v2sh* instructions It is just according to v1sh* instructions implementation. Signed-off-by: Chen Gang --- target-tilegx/translate.c | 18 +- 1 file changed, 17 insertions(+), 1 deletion(-) diff --git a/target-tilegx/translate.c b/target-tilegx/translate.c index 6ab66f9..9bb8857 100644 --- a/target-tilegx/translate.c +++ b/target-tilegx/translate.c @@ -1686,11 +1686,27 @@ static TileExcp gen_rri_opcode(DisasContext *dc, unsigned opext, break; case OE_SH(V2SHLI, X0): case OE_SH(V2SHLI, X1): + i2 = imm & 15; + i3 = 0x>> i2; + tcg_gen_andi_tl(tdest, tsrca, V2_IMM(i3)); + tcg_gen_shli_tl(tdest, tdest, i2); + mnemonic = "v2shli"; + break; case OE_SH(V2SHRSI, X0): case OE_SH(V2SHRSI, X1): + t0 = tcg_const_tl(imm & 15); + gen_helper_v2shrs(tdest, tsrca, t0); + tcg_temp_free(t0); + mnemonic = "v2shrsi"; + break; case OE_SH(V2SHRUI, X0): case OE_SH(V2SHRUI, X1): - return TILEGX_EXCP_OPCODE_UNIMPLEMENTED; + i2 = imm & 15; + i3 = (0x << i2) & 0x; + tcg_gen_andi_tl(tdest, tsrca, V2_IMM(i3)); + tcg_gen_shri_tl(tdest, tdest, i2); + mnemonic = "v2shrui"; + break; case OE(ADDLI_OPCODE_X0, 0, X0): case OE(ADDLI_OPCODE_X1, 0, X1): -- 1.9.3 0001-target-tilegx-Implement-v2sh-instructions.patch Description: Binary data
[Qemu-devel] [PATCH v2] target-tilegx: Implement v?int_* instructions
>From 418c1600c481f0acbde42987db286b48f1848399 Mon Sep 17 00:00:00 2001
From: Chen Gang
Date: Fri, 2 Oct 2015 11:00:37 +0800
Subject: [PATCH v2] target-tilegx: Implement v?int_* instructions.
Signed-off-by: Chen Gang
---
target-tilegx/helper.h | 5
target-tilegx/simd_helper.c | 56 +
target-tilegx/translate.c | 14
3 files changed, 75 insertions(+)
diff --git a/target-tilegx/helper.h b/target-tilegx/helper.h
index 82d84f1..c58ee20 100644
--- a/target-tilegx/helper.h
+++ b/target-tilegx/helper.h
@@ -10,6 +10,11 @@ DEF_HELPER_FLAGS_3(cmula, TCG_CALL_NO_RWG_SE, i64, i64, i64,
i64)
DEF_HELPER_FLAGS_3(cmulaf, TCG_CALL_NO_RWG_SE, i64, i64, i64, i64)
DEF_HELPER_FLAGS_4(cmul2, TCG_CALL_NO_RWG_SE, i64, i64, i64, int, int)
+DEF_HELPER_FLAGS_2(v1int_h, TCG_CALL_NO_RWG_SE, i64, i64, i64)
+DEF_HELPER_FLAGS_2(v1int_l, TCG_CALL_NO_RWG_SE, i64, i64, i64)
+DEF_HELPER_FLAGS_2(v2int_h, TCG_CALL_NO_RWG_SE, i64, i64, i64)
+DEF_HELPER_FLAGS_2(v2int_l, TCG_CALL_NO_RWG_SE, i64, i64, i64)
+
DEF_HELPER_FLAGS_2(v1multu, TCG_CALL_NO_RWG_SE, i64, i64, i64)
DEF_HELPER_FLAGS_2(v1shl, TCG_CALL_NO_RWG_SE, i64, i64, i64)
DEF_HELPER_FLAGS_2(v1shru, TCG_CALL_NO_RWG_SE, i64, i64, i64)
diff --git a/target-tilegx/simd_helper.c b/target-tilegx/simd_helper.c
index 23c20bd..6fa6318 100644
--- a/target-tilegx/simd_helper.c
+++ b/target-tilegx/simd_helper.c
@@ -102,3 +102,59 @@ uint64_t helper_v2shrs(uint64_t a, uint64_t b)
}
return r;
}
+
+uint64_t helper_v1int_h(uint64_t a, uint64_t b)
+{
+ uint64_t r = 0, tmp;
+ int i;
+
+ for (i = 0; i < 32; i += 8) {
+ tmp = (uint8_t)(a>> (i + 32));
+ r |= tmp << (2 * i + 8);
+ tmp = (uint8_t)(b>> (i + 32));
+ r |= tmp << 2 * i;
+ }
+ return r;
+}
+
+uint64_t helper_v1int_l(uint64_t a, uint64_t b)
+{
+ uint64_t r = 0, tmp;
+ int i;
+
+ for (i = 0; i < 32; i += 8) {
+ tmp = (uint8_t)(a>> i);
+ r |= tmp << (2 * i + 8);
+ tmp = (uint8_t)(b>> i);
+ r |= tmp << 2 * i;
+ }
+ return r;
+}
+
+uint64_t helper_v2int_h(uint64_t a, uint64_t b)
+{
+ uint64_t r = 0, tmp;
+ int i;
+
+ for (i = 0; i < 32; i += 16) {
+ tmp = (uint16_t)(a>> (i + 32));
+ r |= tmp << (2 * i + 16);
+ tmp = (uint16_t)(b>> (i + 32));
+ r |= tmp << 2 * i;
+ }
+ return r;
+}
+
+uint64_t helper_v2int_l(uint64_t a, uint64_t b)
+{
+ uint64_t r = 0, tmp;
+ int i;
+
+ for (i = 0; i < 32; i += 16) {
+ tmp = (uint16_t)(a>> i);
+ r |= tmp << (2 * i + 16);
+ tmp = (uint16_t)(b>> i);
+ r |= tmp << 2 * i;
+ }
+ return r;
+}
diff --git a/target-tilegx/translate.c b/target-tilegx/translate.c
index 9bb8857..034cbc2 100644
--- a/target-tilegx/translate.c
+++ b/target-tilegx/translate.c
@@ -1260,10 +1260,17 @@ static TileExcp gen_rrr_opcode(DisasContext *dc,
unsigned opext,
case OE_RRR(V1DOTPUS, 0, X0):
case OE_RRR(V1DOTPU, 0, X0):
case OE_RRR(V1DOTP, 0, X0):
+ return TILEGX_EXCP_OPCODE_UNIMPLEMENTED;
case OE_RRR(V1INT_H, 0, X0):
case OE_RRR(V1INT_H, 0, X1):
+ gen_helper_v1int_h(tdest, tsrca, tsrcb);
+ mnemonic = "v1int_h";
+ break;
case OE_RRR(V1INT_L, 0, X0):
case OE_RRR(V1INT_L, 0, X1):
+ gen_helper_v1int_l(tdest, tsrca, tsrcb);
+ mnemonic = "v1int_l";
+ break;
case OE_RRR(V1MAXU, 0, X0):
case OE_RRR(V1MAXU, 0, X1):
case OE_RRR(V1MINU, 0, X0):
@@ -1329,10 +1336,17 @@ static TileExcp gen_rrr_opcode(DisasContext *dc,
unsigned opext,
case OE_RRR(V2CMPNE, 0, X1):
case OE_RRR(V2DOTPA, 0, X0):
case OE_RRR(V2DOTP, 0, X0):
+ return TILEGX_EXCP_OPCODE_UNIMPLEMENTED;
case OE_RRR(V2INT_H, 0, X0):
case OE_RRR(V2INT_H, 0, X1):
+ gen_helper_v2int_h(tdest, tsrca, tsrcb);
+ mnemonic = "v2int_h";
+ break;
case OE_RRR(V2INT_L, 0, X0):
case OE_RRR(V2INT_L, 0, X1):
+ gen_helper_v2int_l(tdest, tsrca, tsrcb);
+ mnemonic = "v2int_l";
+ break;
case OE_RRR(V2MAXS, 0, X0):
case OE_RRR(V2MAXS, 0, X1):
case OE_RRR(V2MINS, 0, X0):
--
1.9.3
0002-target-tilegx-Implement-v-int_-instructions.patch
Description: Binary data
[Qemu-devel] [PATCH v2] target-tilegx: Implement v2mults instruction
>From 298aa5e9be6373fea7b30236bd3e90352c6e693a Mon Sep 17 00:00:00 2001
From: Chen Gang
Date: Sat, 3 Oct 2015 10:42:01 +0800
Subject: [PATCH v2] target-tilegx: Implement v2mults instruction
Just according to v1multu instruction implementation.
Signed-off-by: Chen Gang
---
target-tilegx/helper.h | 1 +
target-tilegx/simd_helper.c | 13 +
target-tilegx/translate.c | 4
3 files changed, 18 insertions(+)
diff --git a/target-tilegx/helper.h b/target-tilegx/helper.h
index c58ee20..bbcc476 100644
--- a/target-tilegx/helper.h
+++ b/target-tilegx/helper.h
@@ -16,6 +16,7 @@ DEF_HELPER_FLAGS_2(v2int_h, TCG_CALL_NO_RWG_SE, i64, i64, i64)
DEF_HELPER_FLAGS_2(v2int_l, TCG_CALL_NO_RWG_SE, i64, i64, i64)
DEF_HELPER_FLAGS_2(v1multu, TCG_CALL_NO_RWG_SE, i64, i64, i64)
+DEF_HELPER_FLAGS_2(v2mults, TCG_CALL_NO_RWG_SE, i64, i64, i64)
DEF_HELPER_FLAGS_2(v1shl, TCG_CALL_NO_RWG_SE, i64, i64, i64)
DEF_HELPER_FLAGS_2(v1shru, TCG_CALL_NO_RWG_SE, i64, i64, i64)
DEF_HELPER_FLAGS_2(v1shrs, TCG_CALL_NO_RWG_SE, i64, i64, i64)
diff --git a/target-tilegx/simd_helper.c b/target-tilegx/simd_helper.c
index 6fa6318..4f226eb 100644
--- a/target-tilegx/simd_helper.c
+++ b/target-tilegx/simd_helper.c
@@ -41,6 +41,19 @@ uint64_t helper_v1multu(uint64_t a, uint64_t b)
return r;
}
+uint64_t helper_v2mults(uint64_t a, uint64_t b)
+{
+ uint64_t r = 0;
+ int i;
+
+ for (i = 0; i < 64; i += 16) {
+ int64_t ae = (int16_t)(a>> i);
+ int64_t be = (int16_t)(b>> i);
+ r |= ((ae * be) & 0x) << i;
+ }
+ return r;
+}
+
uint64_t helper_v1shl(uint64_t a, uint64_t b)
{
uint64_t m;
diff --git a/target-tilegx/translate.c b/target-tilegx/translate.c
index 034cbc2..eb2d0b1 100644
--- a/target-tilegx/translate.c
+++ b/target-tilegx/translate.c
@@ -1355,7 +1355,11 @@ static TileExcp gen_rrr_opcode(DisasContext *dc,
unsigned opext,
case OE_RRR(V2MNZ, 0, X1):
case OE_RRR(V2MULFSC, 0, X0):
case OE_RRR(V2MULS, 0, X0):
+ return TILEGX_EXCP_OPCODE_UNIMPLEMENTED;
case OE_RRR(V2MULTS, 0, X0):
+ gen_helper_v2mults(tdest, tsrca, tsrcb);
+ mnemonic = "v2mults";
+ break;
case OE_RRR(V2MZ, 0, X0):
case OE_RRR(V2MZ, 0, X1):
case OE_RRR(V2PACKH, 0, X0):
--
1.9.3
0003-target-tilegx-Implement-v2mults-instruction.patch
Description: Binary data
[Qemu-devel] [PATCH v2] target-tilegx: Use TILEGX_EXCP_OPCODE_UNKNOWN and TILEGX_EXCP_OPCODE_UNIMPLEMENTED correctly
>From 0f53a45b3c29e3355cc6b2183ee084e62b86e5fe Mon Sep 17 00:00:00 2001
From: Chen Gang
Date: Sun, 4 Oct 2015 13:34:33 +0800
Subject: [PATCH v2] target-tilegx: Use TILEGX_EXCP_OPCODE_UNKNOWN and
TILEGX_EXCP_OPCODE_UNIMPLEMENTED correctly
For some cases, they are for TILEGX_EXCP_OPCODE_UNKNOWN, not for
TILEGX_EXCP_OPCODE_UNIMPLEMENTED.
Also for some cases, they are for TILEGX_EXCP_OPCODE_UNIMPLEMENTED, not
for TILEGX_EXCP_OPCODE_UNKNOWN.
When analyzing issues, the correct printing information is necessary,
e.g. grep UIMP in gcc testsuite output log for finding qemu tilegx
umimplementation issues, grep UNKNOWN for finding unknown instructions.
Signed-off-by: Chen Gang
---
target-tilegx/translate.c | 41 -
1 file changed, 24 insertions(+), 17 deletions(-)
diff --git a/target-tilegx/translate.c b/target-tilegx/translate.c
index eb2d0b1..ab3fc81 100644
--- a/target-tilegx/translate.c
+++ b/target-tilegx/translate.c
@@ -291,7 +291,7 @@ static TileExcp gen_st_opcode(DisasContext *dc, unsigned
dest, unsigned srca,
unsigned srcb, TCGMemOp memop, const char *name)
{
if (dest) {
- return TILEGX_EXCP_OPCODE_UNIMPLEMENTED;
+ return TILEGX_EXCP_OPCODE_UNKNOWN;
}
tcg_gen_qemu_st_tl(load_gr(dc, srcb), load_gr(dc, srca),
@@ -538,7 +538,7 @@ static TileExcp gen_rr_opcode(DisasContext *dc, unsigned
opext,
mnemonic = "swint1";
done0:
if (srca || dest) {
- return TILEGX_EXCP_OPCODE_UNIMPLEMENTED;
+ return TILEGX_EXCP_OPCODE_UNKNOWN;
}
qemu_log_mask(CPU_LOG_TB_IN_ASM, "%s", mnemonic);
return ret;
@@ -584,7 +584,7 @@ static TileExcp gen_rr_opcode(DisasContext *dc, unsigned
opext,
tcg_gen_andi_tl(dc->jmp.dest, load_gr(dc, srca), ~7);
done1:
if (dest) {
- return TILEGX_EXCP_OPCODE_UNIMPLEMENTED;
+ return TILEGX_EXCP_OPCODE_UNKNOWN;
}
qemu_log_mask(CPU_LOG_TB_IN_ASM, "%s %s", mnemonic, reg_names[srca]);
return ret;
@@ -679,7 +679,7 @@ static TileExcp gen_rr_opcode(DisasContext *dc, unsigned
opext,
case OE_RR_X1(LNK):
case OE_RR_Y1(LNK):
if (srca) {
- return TILEGX_EXCP_OPCODE_UNIMPLEMENTED;
+ return TILEGX_EXCP_OPCODE_UNKNOWN;
}
tcg_gen_movi_tl(tdest, dc->pc + TILEGX_BUNDLE_SIZE_IN_BYTES);
mnemonic = "lnk";
@@ -723,7 +723,7 @@ static TileExcp gen_rr_opcode(DisasContext *dc, unsigned
opext,
mnemonic = "tblidxb3";
break;
default:
- return TILEGX_EXCP_OPCODE_UNIMPLEMENTED;
+ return TILEGX_EXCP_OPCODE_UNKNOWN;
}
qemu_log_mask(CPU_LOG_TB_IN_ASM, "%s %s, %s", mnemonic,
@@ -1453,7 +1453,7 @@ static TileExcp gen_rrr_opcode(DisasContext *dc, unsigned
opext,
mnemonic = "xor";
break;
default:
- return TILEGX_EXCP_OPCODE_UNIMPLEMENTED;
+ return TILEGX_EXCP_OPCODE_UNKNOWN;
}
qemu_log_mask(CPU_LOG_TB_IN_ASM, "%s %s, %s, %s", mnemonic,
@@ -1745,7 +1745,7 @@ static TileExcp gen_rri_opcode(DisasContext *dc, unsigned
opext,
break;
default:
- return TILEGX_EXCP_OPCODE_UNIMPLEMENTED;
+ return TILEGX_EXCP_OPCODE_UNKNOWN;
}
qemu_log_mask(CPU_LOG_TB_IN_ASM, "%s %s, %s, %d", mnemonic,
@@ -1839,7 +1839,7 @@ static TileExcp gen_bf_opcode_x0(DisasContext *dc,
unsigned ext,
break;
default:
- return TILEGX_EXCP_OPCODE_UNIMPLEMENTED;
+ return TILEGX_EXCP_OPCODE_UNKNOWN;
}
qemu_log_mask(CPU_LOG_TB_IN_ASM, "%s %s, %s, %u, %u", mnemonic,
@@ -1895,7 +1895,7 @@ static TileExcp gen_branch_opcode_x1(DisasContext *dc,
unsigned ext,
mnemonic = "blbs";
break;
default:
- return TILEGX_EXCP_OPCODE_UNIMPLEMENTED;
+ return TILEGX_EXCP_OPCODE_UNKNOWN;
}
if (qemu_loglevel_mask(CPU_LOG_TB_IN_ASM)) {
@@ -1962,7 +1962,7 @@ static TileExcp gen_mtspr_x1(DisasContext *dc, unsigned
spr, unsigned srca)
if (def == NULL) {
qemu_log_mask(CPU_LOG_TB_IN_ASM, "mtspr spr[%u], %s", spr,
reg_names[srca]);
- return TILEGX_EXCP_OPCODE_UNKNOWN;
+ return TILEGX_EXCP_OPCODE_UNIMPLEMENTED;
}
tsrca = load_gr(dc, srca);
@@ -1982,7 +1982,7 @@ static TileExcp gen_mfspr_x1(DisasContext *dc, unsigned
dest, unsigned spr)
if (def == NULL) {
qemu_log_mask(CPU_LOG_TB_IN_ASM, "mtspr %s, spr[%u]", reg_names[dest],
spr);
- return TILEGX_EXCP_OPCODE_UNKNOWN;
+ return TILEGX_EXCP_OPCODE_UNIMPLEMENTED;
}
tdest = dest_gr(dc, dest);
@@ -2037,7 +2037,7 @@ static TileExcp decode_y0(DisasContext *dc,
tilegx_bundle_bits bundle)
return gen_rri_opcode(dc, OE(opc, 0, Y0), dest, srca, imm);
default:
- return TILEGX_EXCP_OPCODE_UNIMPLEMENTED;
+ return TILEGX_EXCP_OPCODE_UNKNOWN;
}
}
@@ -2081,7 +2081,7 @@ static TileExcp decode_y1(DisasContext *dc,
[Qemu-devel] [PATCH v4] target-tilegx: Support iret instruction and related special registers
>From 8e8d35fffd735df997c78324b301f22cf270b515 Mon Sep 17 00:00:00 2001
From: Chen Gang
Date: Sun, 4 Oct 2015 17:41:14 +0800
Subject: [PATCH v4] target-tilegx: Support iret instruction and related special
registers
Acording to the __longjmp tilegx libc implementation, and reference from
tilegx ISA document, and suggested by tilegx architecture member, we can
treat iret instruction as "jrp lr". The related code is below:
ENTRY (__longjmp)
FEEDBACK_ENTER(__longjmp)
#define RESTORE(r) { LD r, r0 ; ADDI_PTR r0, r0, REGSIZE }
FOR_EACH_CALLEE_SAVED_REG(RESTORE)
{
LD r2, r0 ; retrieve ICS bit from jmp_buf
movei r3, 1
CMPEQI r0, r1, 0
}
{
mtspr INTERRUPT_CRITICAL_SECTION, r3
shli r2, r2, SPR_EX_CONTEXT_0_1__ICS_SHIFT
}
{
mtspr EX_CONTEXT_0_0, lr
ori r2, r2, RETURN_PL
}
{
or r0, r1, r0
mtspr EX_CONTEXT_0_1, r2
}
iret
jrp lr
EX_CONTEXT_0_0 is used for jumping address, and EX_CONTEXT_0_1 is for
INTERRUPT_CRITICAL_SECTION, which should only be 0 or 1 in user mode, or
it will cause target SEGV (and the patch doesn't implement system mode).
"jrp lr" in __longjmp is for historical reasons, and might get removed
in the future.
Signed-off-by: Chen Gang
---
target-tilegx/cpu.h | 2 ++
target-tilegx/helper.c | 22 ++
target-tilegx/helper.h | 1 +
target-tilegx/translate.c | 14 +-
4 files changed, 38 insertions(+), 1 deletion(-)
diff --git a/target-tilegx/cpu.h b/target-tilegx/cpu.h
index 6f04fe7..6c0fd53 100644
--- a/target-tilegx/cpu.h
+++ b/target-tilegx/cpu.h
@@ -53,6 +53,8 @@ enum {
TILEGX_SPR_CMPEXCH = 0,
TILEGX_SPR_CRITICAL_SEC = 1,
TILEGX_SPR_SIM_CONTROL = 2,
+ TILEGX_SPR_EX_CONTEXT_0_0 = 3,
+ TILEGX_SPR_EX_CONTEXT_0_1 = 4,
TILEGX_SPR_COUNT
};
diff --git a/target-tilegx/helper.c b/target-tilegx/helper.c
index 36b287f..3c043f8 100644
--- a/target-tilegx/helper.c
+++ b/target-tilegx/helper.c
@@ -22,6 +22,7 @@
#include "qemu-common.h"
#include "exec/helper-proto.h"
#include /* For crc32 */
+#include "syscall_defs.h"
void helper_exception(CPUTLGState *env, uint32_t excp)
{
@@ -31,6 +32,27 @@ void helper_exception(CPUTLGState *env, uint32_t excp)
cpu_loop_exit(cs);
}
+void helper_ext01_ics(CPUTLGState *env)
+{
+ uint64_t val = env->spregs[TILEGX_SPR_EX_CONTEXT_0_1];
+
+ switch (val) {
+ case 0:
+ case 1:
+ env->spregs[TILEGX_SPR_CRITICAL_SEC] = val;
+ break;
+ default:
+#if defined(CONFIG_USER_ONLY)
+ env->signo = TARGET_SIGSEGV;
+ env->sigcode = 0;
+ helper_exception(env, TILEGX_EXCP_SIGNAL);
+#else
+ helper_exception(env, TILEGX_EXCP_OPCODE_UNIMPLEMENTED);
+#endif
+ break;
+ }
+}
+
uint64_t helper_cntlz(uint64_t arg)
{
return clz64(arg);
diff --git a/target-tilegx/helper.h b/target-tilegx/helper.h
index bbcc476..9281d0f 100644
--- a/target-tilegx/helper.h
+++ b/target-tilegx/helper.h
@@ -1,4 +1,5 @@
DEF_HELPER_2(exception, noreturn, env, i32)
+DEF_HELPER_1(ext01_ics, void, env)
DEF_HELPER_FLAGS_1(cntlz, TCG_CALL_NO_RWG_SE, i64, i64)
DEF_HELPER_FLAGS_1(cnttz, TCG_CALL_NO_RWG_SE, i64, i64)
DEF_HELPER_FLAGS_1(pcnt, TCG_CALL_NO_RWG_SE, i64, i64)
diff --git a/target-tilegx/translate.c b/target-tilegx/translate.c
index ab3fc81..acb9ec4 100644
--- a/target-tilegx/translate.c
+++ b/target-tilegx/translate.c
@@ -529,6 +529,15 @@ static TileExcp gen_rr_opcode(DisasContext *dc, unsigned
opext,
/* ??? This should yield, especially in system mode. */
mnemonic = "nap";
goto done0;
+ case OE_RR_X1(IRET):
+ gen_helper_ext01_ics(cpu_env);
+ dc->jmp.cond = TCG_COND_ALWAYS;
+ dc->jmp.dest = tcg_temp_new();
+ tcg_gen_ld_tl(dc->jmp.dest, cpu_env,
+ offsetof(CPUTLGState,
spregs[TILEGX_SPR_EX_CONTEXT_0_0]));
+ tcg_gen_andi_tl(dc->jmp.dest, dc->jmp.dest, ~7);
+ mnemonic = "iret";
+ goto done0;
case OE_RR_X1(SWINT0):
case OE_RR_X1(SWINT2):
case OE_RR_X1(SWINT3):
@@ -606,7 +615,6 @@ static TileExcp gen_rr_opcode(DisasContext *dc, unsigned
opext,
break;
case OE_RR_X0(FSINGLE_PACK1):
case OE_RR_Y0(FSINGLE_PACK1):
- case OE_RR_X1(IRET):
return TILEGX_EXCP_OPCODE_UNIMPLEMENTED;
case OE_RR_X1(LD1S):
memop = MO_SB;
@@ -1947,6 +1955,10 @@ static const TileSPR *find_spr(unsigned spr)
offsetof(CPUTLGState, spregs[TILEGX_SPR_CRITICAL_SEC]), 0, 0)
D(SIM_CONTROL,
offsetof(CPUTLGState, spregs[TILEGX_SPR_SIM_CONTROL]), 0, 0)
+ D(EX_CONTEXT_0_0,
+ offsetof(CPUTLGState, spregs[TILEGX_SPR_EX_CONTEXT_0_0]), 0, 0)
+ D(EX_CONTEXT_0_1,
+ offsetof(CPUTLGState, spregs[TILEGX_SPR_EX_CONTEXT_0_1]), 0, 0)
}
#undef D
--
1.9.3
0005-target
[Qemu-devel] [PATCH] target-tilegx: Let prefetch nop instructions return before allocating dest temporary register
>From 40ec3f1c75b4c97e3e0495c9e465be898f48a652 Mon Sep 17 00:00:00 2001
From: Chen Gang
Date: Sun, 4 Oct 2015 17:34:17 +0800
Subject: [PATCH] target-tilegx: Let prefetch nop instructions return before
allocating dest temporary register
Or it will cause issue by the dest temporary registers.
Signed-off-by: Chen Gang
---
target-tilegx/translate.c | 85 +--
1 file changed, 46 insertions(+), 39 deletions(-)
diff --git a/target-tilegx/translate.c b/target-tilegx/translate.c
index acb9ec4..2913902 100644
--- a/target-tilegx/translate.c
+++ b/target-tilegx/translate.c
@@ -496,7 +496,6 @@ static TileExcp gen_rr_opcode(DisasContext *dc, unsigned
opext,
const char *mnemonic;
TCGMemOp memop;
TileExcp ret = TILEGX_EXCP_NONE;
- bool prefetch_nofault = false;
/* Eliminate instructions with no output before doing anything else. */
switch (opext) {
@@ -597,6 +596,26 @@ static TileExcp gen_rr_opcode(DisasContext *dc, unsigned
opext,
}
qemu_log_mask(CPU_LOG_TB_IN_ASM, "%s %s", mnemonic, reg_names[srca]);
return ret;
+
+ case OE_RR_X1(LD1U):
+ memop = MO_UB;
+ mnemonic = "ld1u"; /* prefetch, prefetch_l1 */
+ goto do_load_nofault;
+ case OE_RR_X1(LD2U):
+ memop = MO_TEUW;
+ mnemonic = "ld2u"; /* prefetch_l2 */
+ goto do_load_nofault;
+ case OE_RR_X1(LD4U):
+ memop = MO_TEUL;
+ mnemonic = "ld4u"; /* prefetch_l3 */
+ do_load_nofault:
+ if (dest != TILEGX_R_ZERO) {
+ tcg_gen_qemu_ld_tl(dest_gr(dc, dest), load_gr(dc, srca),
+ dc->mmuidx, memop);
+ }
+ qemu_log_mask(CPU_LOG_TB_IN_ASM, "%s %s, %s", mnemonic,
+ reg_names[dest], reg_names[srca]);
+ return ret;
}
tdest = dest_gr(dc, dest);
@@ -620,29 +639,14 @@ static TileExcp gen_rr_opcode(DisasContext *dc, unsigned
opext,
memop = MO_SB;
mnemonic = "ld1s"; /* prefetch_l1_fault */
goto do_load;
- case OE_RR_X1(LD1U):
- memop = MO_UB;
- mnemonic = "ld1u"; /* prefetch, prefetch_l1 */
- prefetch_nofault = (dest == TILEGX_R_ZERO);
- goto do_load;
case OE_RR_X1(LD2S):
memop = MO_TESW;
mnemonic = "ld2s"; /* prefetch_l2_fault */
goto do_load;
- case OE_RR_X1(LD2U):
- memop = MO_TEUW;
- mnemonic = "ld2u"; /* prefetch_l2 */
- prefetch_nofault = (dest == TILEGX_R_ZERO);
- goto do_load;
case OE_RR_X1(LD4S):
memop = MO_TESL;
mnemonic = "ld4s"; /* prefetch_l3_fault */
goto do_load;
- case OE_RR_X1(LD4U):
- memop = MO_TEUL;
- mnemonic = "ld4u"; /* prefetch_l3 */
- prefetch_nofault = (dest == TILEGX_R_ZERO);
- goto do_load;
case OE_RR_X1(LDNT1S):
memop = MO_SB;
mnemonic = "ldnt1s";
@@ -675,9 +679,7 @@ static TileExcp gen_rr_opcode(DisasContext *dc, unsigned
opext,
memop = MO_TEQ;
mnemonic = "ld";
do_load:
- if (!prefetch_nofault) {
- tcg_gen_qemu_ld_tl(tdest, tsrca, dc->mmuidx, memop);
- }
+ tcg_gen_qemu_ld_tl(tdest, tsrca, dc->mmuidx, memop);
break;
case OE_RR_X1(LDNA):
tcg_gen_andi_tl(tdest, tsrca, ~7);
@@ -1472,15 +1474,36 @@ static TileExcp gen_rrr_opcode(DisasContext *dc,
unsigned opext,
static TileExcp gen_rri_opcode(DisasContext *dc, unsigned opext,
unsigned dest, unsigned srca, int imm)
{
- TCGv tdest = dest_gr(dc, dest);
+ TCGv tdest;
TCGv tsrca = load_gr(dc, srca);
- bool prefetch_nofault = false;
const char *mnemonic;
TCGMemOp memop;
int i2, i3;
TCGv t0;
switch (opext) {
+ case OE_IM(LD1U_ADD, X1):
+ memop = MO_UB;
+ mnemonic = "ld1u_add"; /* prefetch_add_l1 */
+ goto do_load_add_nofault;
+ case OE_IM(LD2U_ADD, X1):
+ memop = MO_TEUW;
+ mnemonic = "ld2u_add"; /* prefetch_add_l2 */
+ goto do_load_add_nofault;
+ case OE_IM(LD4U_ADD, X1):
+ memop = MO_TEUL;
+ mnemonic = "ld4u_add"; /* prefetch_add_l3 */
+ do_load_add_nofault:
+ if (dest != TILEGX_R_ZERO) {
+ tcg_gen_qemu_ld_tl(dest_gr(dc, dest), tsrca, dc->mmuidx, memop);
+ }
+ tcg_gen_addi_tl(dest_gr(dc, srca), tsrca, imm);
+ goto done2;
+ }
+
+ tdest = dest_gr(dc, dest);
+
+ switch (opext) {
case OE(ADDI_OPCODE_Y0, 0, Y0):
case OE(ADDI_OPCODE_Y1, 0, Y1):
case OE_IM(ADDI, X0):
@@ -1526,29 +1549,14 @@ static TileExcp gen_rri_opcode(DisasContext *dc,
unsigned opext,
memop = MO_SB;
mnemonic = "ld1s_add"; /* prefetch_add_l1_fault */
goto do_load_add;
- case OE_IM(LD1U_ADD, X1):
- memop = MO_UB;
- mnemonic = "ld1u_add"; /* prefetch_add_l1 */
- prefetch_nofault = (dest == TILEGX_R_ZERO);
- goto do_load_add;
case OE_IM(LD2S_
[Qemu-devel] [PATCH] target-tilegx: Implement floating point temporarily
>From 4d12af14f361fb5e3a893fc68a599be9ea17d1dc Mon Sep 17 00:00:00 2001
From: Chen Gang
Date: Sun, 4 Oct 2015 18:00:53 +0800
Subject: [PATCH] target-tilegx: Implement floating point temporarily
It is a temporary implementation, but it can pass gcc testsuite.
Signed-off-by: Chen Gang
---
target-tilegx/Makefile.objs | 2 +-
target-tilegx/cpu.h | 5 +-
target-tilegx/fpu.h | 149 +
target-tilegx/fpu_helper.c | 259
target-tilegx/helper.h | 9 ++
target-tilegx/translate.c | 70 +---
6 files changed, 479 insertions(+), 15 deletions(-)
create mode 100644 target-tilegx/fpu.h
create mode 100644 target-tilegx/fpu_helper.c
diff --git a/target-tilegx/Makefile.objs b/target-tilegx/Makefile.objs
index 0db778f..1573c36 100644
--- a/target-tilegx/Makefile.objs
+++ b/target-tilegx/Makefile.objs
@@ -1 +1 @@
-obj-y += cpu.o translate.o helper.o simd_helper.o
+obj-y += cpu.o translate.o helper.o simd_helper.o fpu_helper.o
diff --git a/target-tilegx/cpu.h b/target-tilegx/cpu.h
index 6c0fd53..b752ef3 100644
--- a/target-tilegx/cpu.h
+++ b/target-tilegx/cpu.h
@@ -27,7 +27,7 @@
#define CPUArchState struct CPUTLGState
#include "exec/cpu-defs.h"
-
+#include "fpu.h"
/* TILE-Gx common register alias */
#define TILEGX_R_RE 0 /* 0 register, for function/syscall return value */
@@ -77,6 +77,7 @@ typedef enum {
TILEGX_EXCP_OPCODE_FETCHAND4 = 0x10c,
TILEGX_EXCP_OPCODE_FETCHOR = 0x10d,
TILEGX_EXCP_OPCODE_FETCHOR4 = 0x10e,
+ TILEGX_EXCP_OPCODE_INVALID_VALUE = 0x10f,
TILEGX_EXCP_REG_IDN_ACCESS = 0x181,
TILEGX_EXCP_REG_UDN_ACCESS = 0x182,
TILEGX_EXCP_UNALIGNMENT = 0x201,
@@ -88,6 +89,8 @@ typedef struct CPUTLGState {
uint64_t spregs[TILEGX_SPR_COUNT]; /* Special used registers by outside */
uint64_t pc; /* Current pc */
+ FPUTLGState fpu; /* fpu context */
+
#if defined(CONFIG_USER_ONLY)
uint64_t excaddr; /* exception address */
uint64_t atomic_srca; /* Arguments to atomic "exceptions" */
diff --git a/target-tilegx/fpu.h b/target-tilegx/fpu.h
new file mode 100644
index 000..41076bd
--- /dev/null
+++ b/target-tilegx/fpu.h
@@ -0,0 +1,149 @@
+/*
+ * TILE-Gx virtual FPU header
+ *
+ * Copyright (c) 2015 Chen Gang
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2 of the License, or (at your option) any later version.
+ *
+ * This library 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 Lesser General Public
+ * License along with this library; if not, see
Re: [Qemu-devel] [PATCH] target-tilegx: Implement floating point temporarily
After the temporary floating point patch, our tilegx qemu can test the
gcc testsuite successfully (no any unimplementation issues). The test
result is:
=== gcc Summary ===
# of expected passes 77012
# of unexpected failures 622
# of unexpected successes 7
# of expected failures 113
# of unresolved testcases 143
# of unsupported tests 1476
For the 622 left issues:
- Maybe still tilegx implementation issue, e.g.
the floating point single mul instruction cann't get the result which
tilegx gcc expected (it is only related with calculating: float32_mul
calculation result is not match tilegx gcc expected).
- Maybe envorintments configuration issues, e.g.
for gcc guality_check, it may call gdb outside, so I need config the
related gdb correctlly.
- Maybe tilegx gcc issues, e.g.
for some UNKNOWN instructions, probably generated by incorrect jump
instructions, one sample is "-fpic -mcmodel=large" for gcc nested-5
test.
Next, I shall:
- continue to fix the left 622 issues, and send related patches to
qemu-devel mailing list or gcc-patches mailing list.
- then rewrite the floating point instructions implementation, and try
to let the related code merged into qemu mainline with the qemu
members' help.
- at last, try to finish all left unimplemented instructions (there are
still some unimplement insns left, but at present, gcc testsuite does
not use them), and start tilegx qemu system mode, next.
Thanks
--
Chen Gang
Open, share, and attitude like air, water, and life which God blessed
> From: xili_gchen_5...@hotmail.com
> To: r...@twiddle.net; peter.mayd...@linaro.org; cmetc...@ezchip.com
> CC: qemu-devel@nongnu.org
> Subject: [PATCH] target-tilegx: Implement floating point temporarily
> Date: Sun, 4 Oct 2015 19:16:35 +0800
>
> From 4d12af14f361fb5e3a893fc68a599be9ea17d1dc Mon Sep 17 00:00:00 2001
> From: Chen Gang
> Date: Sun, 4 Oct 2015 18:00:53 +0800
> Subject: [PATCH] target-tilegx: Implement floating point temporarily
>
> It is a temporary implementation, but it can pass gcc testsuite.
>
> Signed-off-by: Chen Gang
> ---
> target-tilegx/Makefile.objs | 2 +-
> target-tilegx/cpu.h | 5 +-
> target-tilegx/fpu.h | 149 +
> target-tilegx/fpu_helper.c | 259
> target-tilegx/helper.h | 9 ++
> target-tilegx/translate.c | 70 +---
> 6 files changed, 479 insertions(+), 15 deletions(-)
> create mode 100644 target-tilegx/fpu.h
> create mode 100644 target-tilegx/fpu_helper.c
>
> diff --git a/target-tilegx/Makefile.objs b/target-tilegx/Makefile.objs
> index 0db778f..1573c36 100644
> --- a/target-tilegx/Makefile.objs
> +++ b/target-tilegx/Makefile.objs
> @@ -1 +1 @@
> -obj-y += cpu.o translate.o helper.o simd_helper.o
> +obj-y += cpu.o translate.o helper.o simd_helper.o fpu_helper.o
> diff --git a/target-tilegx/cpu.h b/target-tilegx/cpu.h
> index 6c0fd53..b752ef3 100644
> --- a/target-tilegx/cpu.h
> +++ b/target-tilegx/cpu.h
> @@ -27,7 +27,7 @@
> #define CPUArchState struct CPUTLGState
>
> #include "exec/cpu-defs.h"
> -
> +#include "fpu.h"
>
> /* TILE-Gx common register alias */
> #define TILEGX_R_RE 0 /* 0 register, for function/syscall return value */
> @@ -77,6 +77,7 @@ typedef enum {
> TILEGX_EXCP_OPCODE_FETCHAND4 = 0x10c,
> TILEGX_EXCP_OPCODE_FETCHOR = 0x10d,
> TILEGX_EXCP_OPCODE_FETCHOR4 = 0x10e,
> + TILEGX_EXCP_OPCODE_INVALID_VALUE = 0x10f,
> TILEGX_EXCP_REG_IDN_ACCESS = 0x181,
> TILEGX_EXCP_REG_UDN_ACCESS = 0x182,
> TILEGX_EXCP_UNALIGNMENT = 0x201,
> @@ -88,6 +89,8 @@ typedef struct CPUTLGState {
> uint64_t spregs[TILEGX_SPR_COUNT]; /* Special used registers by outside */
> uint64_t pc; /* Current pc */
>
> + FPUTLGState fpu; /* fpu context */
> +
> #if defined(CONFIG_USER_ONLY)
> uint64_t excaddr; /* exception address */
> uint64_t atomic_srca; /* Arguments to atomic "exceptions" */
> diff --git a/target-tilegx/fpu.h b/target-tilegx/fpu.h
> new file mode 100644
> index 000..41076bd
> --- /dev/null
> +++ b/target-tilegx/fpu.h
> @@ -0,0 +1,149 @@
> +/*
> + * TILE-Gx virtual FPU header
> + *
> + * Copyright (c) 2015 Chen Gang
> + *
> + * This library is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as published by the Free Software Foundation; either
> + * version 2 of the License, or (at your option) any later version.
> + *
> + * This library 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 Lesser General Public
> + * License along with this library; if not, see
>
Re: [Qemu-devel] [PATCH v4 1/1] intel_iommu: Add support for translation for devices behind bridges
On Sun, 2015-09-27 at 13:07 +0300, Michael S. Tsirkin wrote:
> On Sat, Sep 26, 2015 at 08:09:56AM +0200, Knut Omang wrote:
> > - Use a hash table indexed on bus pointers to store information
> > about buses
> > instead of using the bus numbers.
> > Bus pointers are stored in a new VTDBus struct together with the
> > vector
> > of device address space pointers indexed by devfn.
> > - The bus number is still used for lookup for selective SID based
> > invalidate,
> > in which case the bus number is lazily resolved from the bus hash
> > table and
> > cached in a separate index.
> >
> > Signed-off-by: Knut Omang
>
> Fails on 32 bit:
> /scm/qemu/hw/i386/intel_iommu.c: In function ‘vtd_find_add_as’:
> /scm/qemu/hw/i386/intel_iommu.c:1869:20: error: cast from pointer to
> integer of different size [-Werror=pointer-to-int-cast]
> uint64_t key = (uint64_t)bus;
> ^
> /scm/qemu/hw/i386/intel_iommu.c:1877:15: error: cast from pointer to
> integer of different size [-Werror=pointer-to-int-cast]
> key = (uint64_t)bus;
>^
>
> You need to cast things to uintptr_t.
Sorry - everything around me has become 64 bit these days, will be more
careful - I'll post a v5 with this.
Knut
> > ---
> > hw/i386/intel_iommu.c | 90
> > +++
> > hw/pci-host/q35.c | 25 ++--
> > include/hw/i386/intel_iommu.h | 16 +++-
> > 3 files changed, 91 insertions(+), 40 deletions(-)
> >
> > diff --git a/hw/i386/intel_iommu.c b/hw/i386/intel_iommu.c
> > index 08055a8..d677a28 100644
> > --- a/hw/i386/intel_iommu.c
> > +++ b/hw/i386/intel_iommu.c
> > @@ -22,6 +22,7 @@
> > #include "hw/sysbus.h"
> > #include "exec/address-spaces.h"
> > #include "intel_iommu_internal.h"
> > +#include "hw/pci/pci.h"
> >
> > /*#define DEBUG_INTEL_IOMMU*/
> > #ifdef DEBUG_INTEL_IOMMU
> > @@ -166,19 +167,17 @@ static gboolean
> > vtd_hash_remove_by_page(gpointer key, gpointer value,
> > */
> > static void vtd_reset_context_cache(IntelIOMMUState *s)
> > {
> > -VTDAddressSpace **pvtd_as;
> > VTDAddressSpace *vtd_as;
> > -uint32_t bus_it;
> > +VTDBus *vtd_bus;
> > +GHashTableIter bus_it;
> > uint32_t devfn_it;
> >
> > +g_hash_table_iter_init(&bus_it, s->vtd_as_by_busptr);
> > +
> > VTD_DPRINTF(CACHE, "global context_cache_gen=1");
> > -for (bus_it = 0; bus_it < VTD_PCI_BUS_MAX; ++bus_it) {
> > -pvtd_as = s->address_spaces[bus_it];
> > -if (!pvtd_as) {
> > -continue;
> > -}
> > +while (g_hash_table_iter_next (&bus_it, NULL,
> > (void**)&vtd_bus)) {
> > for (devfn_it = 0; devfn_it < VTD_PCI_DEVFN_MAX;
> > ++devfn_it) {
> > -vtd_as = pvtd_as[devfn_it];
> > +vtd_as = vtd_bus->dev_as[devfn_it];
> > if (!vtd_as) {
> > continue;
> > }
> > @@ -754,12 +753,13 @@ static inline bool
> > vtd_is_interrupt_addr(hwaddr addr)
> > * @is_write: The access is a write operation
> > * @entry: IOMMUTLBEntry that contain the addr to be translated
> > and result
> > */
> > -static void vtd_do_iommu_translate(VTDAddressSpace *vtd_as,
> > uint8_t bus_num,
> > +static void vtd_do_iommu_translate(VTDAddressSpace *vtd_as, PCIBus
> > *bus,
> > uint8_t devfn, hwaddr addr,
> > bool is_write,
> > IOMMUTLBEntry *entry)
> > {
> > IntelIOMMUState *s = vtd_as->iommu_state;
> > VTDContextEntry ce;
> > +uint8_t bus_num = pci_bus_num(bus);
> > VTDContextCacheEntry *cc_entry = &vtd_as->context_cache_entry;
> > uint64_t slpte;
> > uint32_t level;
> > @@ -874,6 +874,30 @@ static void
> > vtd_context_global_invalidate(IntelIOMMUState *s)
> > }
> > }
> >
> > +
> > +/* Find the VTD address space currently associated with a given
> > bus number,
> > + */
> > +static VTDBus *vtd_find_as_from_bus_num(IntelIOMMUState *s,
> > uint8_t bus_num)
> > +{
> > +VTDBus *vtd_bus = s->vtd_as_by_bus_num[bus_num];
> > +if (!vtd_bus) {
> > +/* Iterate over the registered buses to find the one
> > + * which currently hold this bus number, and update the
> > bus_num lookup table:
> > + */
> > +GHashTableIter iter;
> > +uint64_t key;
> > +
> > +g_hash_table_iter_init(&iter, s->vtd_as_by_busptr);
> > +while (g_hash_table_iter_next (&iter, (void**)&key,
> > (void**)&vtd_bus)) {
> > +if (pci_bus_num(vtd_bus->bus) == bus_num) {
> > +s->vtd_as_by_bus_num[bus_num] = vtd_bus;
> > +return vtd_bus;
> > +}
> > +}
> > +}
> > +return vtd_bus;
> > +}
> > +
> > /* Do a context-cache device-selective invalidation.
> > * @func_mask: FM field after shifting
> > */
> > @@ -882,7 +906,7 @@ static void
> > vtd_context_device_invalidate(IntelIOMMUState *s,
> >uint16_t
[Qemu-devel] [PATCH v5 1/1] intel_iommu: Add support for translation for devices behind bridges
- Use a hash table indexed on bus pointers to store information about buses
instead of using the bus numbers.
Bus pointers are stored in a new VTDBus struct together with the vector
of device address space pointers indexed by devfn.
- The bus number is still used for lookup for selective SID based invalidate,
in which case the bus number is lazily resolved from the bus hash table and
cached in a separate index.
Signed-off-by: Knut Omang
---
hw/i386/intel_iommu.c | 89 +++
hw/pci-host/q35.c | 25 ++--
include/hw/i386/intel_iommu.h | 16 +++-
3 files changed, 90 insertions(+), 40 deletions(-)
diff --git a/hw/i386/intel_iommu.c b/hw/i386/intel_iommu.c
index 08055a8..3fe27fa 100644
--- a/hw/i386/intel_iommu.c
+++ b/hw/i386/intel_iommu.c
@@ -22,6 +22,7 @@
#include "hw/sysbus.h"
#include "exec/address-spaces.h"
#include "intel_iommu_internal.h"
+#include "hw/pci/pci.h"
/*#define DEBUG_INTEL_IOMMU*/
#ifdef DEBUG_INTEL_IOMMU
@@ -166,19 +167,17 @@ static gboolean vtd_hash_remove_by_page(gpointer key,
gpointer value,
*/
static void vtd_reset_context_cache(IntelIOMMUState *s)
{
-VTDAddressSpace **pvtd_as;
VTDAddressSpace *vtd_as;
-uint32_t bus_it;
+VTDBus *vtd_bus;
+GHashTableIter bus_it;
uint32_t devfn_it;
+g_hash_table_iter_init(&bus_it, s->vtd_as_by_busptr);
+
VTD_DPRINTF(CACHE, "global context_cache_gen=1");
-for (bus_it = 0; bus_it < VTD_PCI_BUS_MAX; ++bus_it) {
-pvtd_as = s->address_spaces[bus_it];
-if (!pvtd_as) {
-continue;
-}
+while (g_hash_table_iter_next (&bus_it, NULL, (void**)&vtd_bus)) {
for (devfn_it = 0; devfn_it < VTD_PCI_DEVFN_MAX; ++devfn_it) {
-vtd_as = pvtd_as[devfn_it];
+vtd_as = vtd_bus->dev_as[devfn_it];
if (!vtd_as) {
continue;
}
@@ -754,12 +753,13 @@ static inline bool vtd_is_interrupt_addr(hwaddr addr)
* @is_write: The access is a write operation
* @entry: IOMMUTLBEntry that contain the addr to be translated and result
*/
-static void vtd_do_iommu_translate(VTDAddressSpace *vtd_as, uint8_t bus_num,
+static void vtd_do_iommu_translate(VTDAddressSpace *vtd_as, PCIBus *bus,
uint8_t devfn, hwaddr addr, bool is_write,
IOMMUTLBEntry *entry)
{
IntelIOMMUState *s = vtd_as->iommu_state;
VTDContextEntry ce;
+uint8_t bus_num = pci_bus_num(bus);
VTDContextCacheEntry *cc_entry = &vtd_as->context_cache_entry;
uint64_t slpte;
uint32_t level;
@@ -874,6 +874,29 @@ static void vtd_context_global_invalidate(IntelIOMMUState
*s)
}
}
+
+/* Find the VTD address space currently associated with a given bus number,
+ */
+static VTDBus *vtd_find_as_from_bus_num(IntelIOMMUState *s, uint8_t bus_num)
+{
+VTDBus *vtd_bus = s->vtd_as_by_bus_num[bus_num];
+if (!vtd_bus) {
+/* Iterate over the registered buses to find the one
+ * which currently hold this bus number, and update the bus_num lookup
table:
+ */
+GHashTableIter iter;
+
+g_hash_table_iter_init(&iter, s->vtd_as_by_busptr);
+while (g_hash_table_iter_next (&iter, NULL, (void**)&vtd_bus)) {
+if (pci_bus_num(vtd_bus->bus) == bus_num) {
+s->vtd_as_by_bus_num[bus_num] = vtd_bus;
+return vtd_bus;
+}
+}
+}
+return vtd_bus;
+}
+
/* Do a context-cache device-selective invalidation.
* @func_mask: FM field after shifting
*/
@@ -882,7 +905,7 @@ static void vtd_context_device_invalidate(IntelIOMMUState
*s,
uint16_t func_mask)
{
uint16_t mask;
-VTDAddressSpace **pvtd_as;
+VTDBus *vtd_bus;
VTDAddressSpace *vtd_as;
uint16_t devfn;
uint16_t devfn_it;
@@ -903,11 +926,11 @@ static void vtd_context_device_invalidate(IntelIOMMUState
*s,
}
VTD_DPRINTF(INV, "device-selective invalidation source 0x%"PRIx16
" mask %"PRIu16, source_id, mask);
-pvtd_as = s->address_spaces[VTD_SID_TO_BUS(source_id)];
-if (pvtd_as) {
+vtd_bus = vtd_find_as_from_bus_num(s, VTD_SID_TO_BUS(source_id));
+if (vtd_bus) {
devfn = VTD_SID_TO_DEVFN(source_id);
for (devfn_it = 0; devfn_it < VTD_PCI_DEVFN_MAX; ++devfn_it) {
-vtd_as = pvtd_as[devfn_it];
+vtd_as = vtd_bus->dev_as[devfn_it];
if (vtd_as && ((devfn_it & mask) == (devfn & mask))) {
VTD_DPRINTF(INV, "invalidate context-cahce of devfn 0x%"PRIx16,
devfn_it);
@@ -1805,11 +1828,11 @@ static IOMMUTLBEntry vtd_iommu_translate(MemoryRegion
*iommu, hwaddr addr,
return ret;
}
-vtd_do_iommu_translate(vtd_as, vtd_as->bus_num, vtd_as->devfn, addr,
+vtd_do_iommu_translate(vtd_as, vtd_as->bus, vtd_as->devfn, addr,
[Qemu-devel] [PATCH v5 0/1] intel_iommu: Add support for translation for devices behind bridges
This patch set has been completely reimplemented according to ideas from the discussion of v2. It still solves the same problem, but does so only within the Intel IOMMU code and Q35, without changing the IOMMU interface. This eliminates the need for any separate interface change patch. This is the thread following v2 of the patch set: http://thread.gmane.org/gmane.comp.emulators.qemu/358525 This is the thread following the initial patch set: http://thread.gmane.org/gmane.comp.emulators.qemu/302246 The patch set was also discussed in this thread: http://thread.gmane.org/gmane.comp.emulators.qemu/316949 Changes from v4: - Use uintptr_t instead of uint64_t to compile on 32 bit architectures. Changes from v3: - Replaced use of g_hash_table_add with g_hash_table_insert to support compiling on older versions of glib. Changes from v2: - Completely reimplemented fix to avoid API change and further logical deviation from how hardware works. API change no longer necessary, so just a single patch. Changes from v1: - Rebased to current master - Fixed minor syntax issues Knut Omang (1): intel_iommu: Add support for translation for devices behind bridges hw/i386/intel_iommu.c | 89 +++ hw/pci-host/q35.c | 25 ++-- include/hw/i386/intel_iommu.h | 16 +++- 3 files changed, 90 insertions(+), 40 deletions(-) -- 2.4.3
[Qemu-devel] CharUDP - Connection refused
Hi Fi With or without the patch[1] the same result - "Connection refused". UDP network console, the character device acts as a UDP netconsole service, sending and receiving packets. This is a lossy service. = HOST: virt-manager: Add New Virtual Serial Device Device Type: UDP net cosnole (udp) Host: 127.0.0.1 Port: 4555 Bind Host: Server mode (bind) Serial Device 1 (Primary Console) Device Type: udp Source host: 127.0.0.1:4555 Bind host: 127.0.0.1:4556 /etc/libvirt/qemu/domain.xml ... qemu-system-x86_64 ... \ -chardev udp,id=charserial0,host=127.0.0.1,port=4555,localaddr=127.0.0.1,localport=4556 \ -device isa-serial,chardev=charserial0,id=serial0 # netstat -an | grep 4555 udp0 0 127.0.0.1:4556 127.0.0.1:4555 ESTABLISHED # nc -vv -u 127.0.0.1 4555 Ncat: Version 6.47 ( http://nmap.org/ncat ) libnsock nsi_new2(): nsi_new (IOD #1) libnsock nsock_connect_udp(): UDP connection requested to 127.0.0.1:4555 (IOD #1) EID 8 libnsock nsock_trace_handler_callback(): Callback: CONNECT SUCCESS for EID 8 [127.0.0.1:4555] Ncat: Connected to 127.0.0.1:4555. libnsock nsi_new2(): nsi_new (IOD #2) libnsock nsock_read(): Read request from IOD #1 [127.0.0.1:4555] (timeout: -1ms) EID 18 libnsock nsock_readbytes(): Read request for 0 bytes from IOD #2 [peer unspecified] EID 26 libnsock nsock_trace_handler_callback(): Callback: READ SUCCESS for EID 26 [peer unspecified] (1 bytes): . libnsock nsock_trace_handler_callback(): Callback: WRITE SUCCESS for EID 35 [127.0.0.1:4555] libnsock nsock_readbytes(): Read request for 0 bytes from IOD #2 [peer unspecified] EID 42 libnsock nsock_trace_handler_callback(): Callback: READ ERROR [Connection refused (111)] for EID 18 [127.0.0.1:4555] Ncat: Connection refused. # nc -vv -u 127.0.0.1 4556 Ncat: Version 6.47 ( http://nmap.org/ncat ) libnsock nsi_new2(): nsi_new (IOD #1) libnsock nsock_connect_udp(): UDP connection requested to 127.0.0.1:4556 (IOD #1) EID 8 libnsock nsock_trace_handler_callback(): Callback: CONNECT SUCCESS for EID 8 [127.0.0.1:4556] Ncat: Connected to 127.0.0.1:4556. libnsock nsi_new2(): nsi_new (IOD #2) libnsock nsock_read(): Read request from IOD #1 [127.0.0.1:4556] (timeout: -1ms) EID 18 libnsock nsock_readbytes(): Read request for 0 bytes from IOD #2 [peer unspecified] EID 26 libnsock nsock_trace_handler_callback(): Callback: READ SUCCESS for EID 26 [peer unspecified] (1 bytes): . libnsock nsock_trace_handler_callback(): Callback: WRITE SUCCESS for EID 35 [127.0.0.1:4556] libnsock nsock_readbytes(): Read request for 0 bytes from IOD #2 [peer unspecified] EID 42 libnsock nsock_trace_handler_callback(): Callback: READ ERROR [Connection refused (111)] for EID 18 [127.0.0.1:4556] Ncat: Connection refused. # socat -d -d UDP:127.0.0.1:4555 - 2015/10/04 13:18:29 socat[5655] N opening connection to AF=2 127.0.0.1:4555 2015/10/04 13:18:29 socat[5655] N successfully connected from local address AF=2 127.0.0.1:40785 2015/10/04 13:18:29 socat[5655] N reading from and writing to stdio 2015/10/04 13:18:29 socat[5655] N starting data transfer loop with FDs [3,3] and [0,1] 2015/10/04 13:18:34 socat[5655] E read(3, 0x557184904210, 8192): Connection refused 2015/10/04 13:18:34 socat[5655] N exit(1) # socat -d -d UDP:127.0.0.1:4556 - 2015/10/04 13:18:47 socat[5658] N opening connection to AF=2 127.0.0.1:4556 2015/10/04 13:18:47 socat[5658] N successfully connected from local address AF=2 127.0.0.1:49650 2015/10/04 13:18:47 socat[5658] N reading from and writing to stdio 2015/10/04 13:18:47 socat[5658] N starting data transfer loop with FDs [3,3] and [0,1] 2015/10/04 13:18:51 socat[5658] E read(3, 0x561b414be210, 8192): Connection refused 2015/10/04 13:18:51 socat[5658] N exit(1) How is it supposed to work? = DOMAIN: $ hostnamectl status | egrep Chassis\|Virtualization Chassis: vm Virtualization: kvm $ cat /proc/cmdline BOOT_IMAGE=vmlinuz0 initrd=initrd0.img root=live:CDLABEL=Rawhide-Xfce-Live-1003 rootfstype=auto ro rd.live.image console=tty0 console=ttyS0 $ systemctl status serial-getty@ttyS0.service ● serial-getty@ttyS0.service - Serial Getty on ttyS0 Loaded: loaded (/usr/lib/systemd/system/serial-getty@.service; disabled; vendor preset: disabled) Active: active (running) since Sun 2015-10-04 09:02:06 EDT; 48s ago Docs: man:agetty(8) man:systemd-getty-generator(8) http://0pointer.de/blog/projects/serial-console.html Main PID: 1109 (agetty) CGroup: /system.slice/system-serial\x2dgetty.slice/serial-getty@ttyS0.service └─1109 /sbin/agetty --keep-baud 115200 38400 9600 ttyS0 vt220 Oct 04 09:02:06 localhost systemd[1]: Started Serial Getty on ttyS0. = SW VERSIONS: $ qemu-system-x86_64 -version QEMU emulator version 2.4.0.1 (qemu-2.4.0.1-2.fc24), Copyright (c) 2003-2008 Fabrice Bellard $ libvirtd --version libvirtd (libvirt) 1.2.20 $ virt-manager --version 1.2.1 $ rpm -q qemu
Re: [Qemu-devel] [PATCH v3 1/4] firmware: introduce sysfs driver for QEMU's fw_cfg device
Hi Gabriel,
[auto build test results on v4.3-rc3 -- if it's inappropriate base, please
ignore]
reproduce:
# apt-get install sparse
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__
sparse warnings: (new ones prefixed by >>)
drivers/firmware/qemu_fw_cfg.c:66:25: sparse: constant 0xd0510 is so big
it is long
>> drivers/firmware/qemu_fw_cfg.c:95:39: sparse: restricted __be16 degrades to
>> integer
>> drivers/firmware/qemu_fw_cfg.c:95:58: sparse: restricted __le16 degrades to
>> integer
>> drivers/firmware/qemu_fw_cfg.c:111:25: sparse: cast to restricted __be32
>> drivers/firmware/qemu_fw_cfg.c:111:25: sparse: cast to restricted __be32
>> drivers/firmware/qemu_fw_cfg.c:111:25: sparse: cast to restricted __be32
>> drivers/firmware/qemu_fw_cfg.c:111:25: sparse: cast to restricted __be32
>> drivers/firmware/qemu_fw_cfg.c:111:25: sparse: cast to restricted __be32
>> drivers/firmware/qemu_fw_cfg.c:111:25: sparse: cast to restricted __be32
>> drivers/firmware/qemu_fw_cfg.c:95:39: sparse: restricted __be16 degrades to
>> integer
>> drivers/firmware/qemu_fw_cfg.c:95:58: sparse: restricted __le16 degrades to
>> integer
>> drivers/firmware/qemu_fw_cfg.c:95:39: sparse: restricted __be16 degrades to
>> integer
>> drivers/firmware/qemu_fw_cfg.c:95:58: sparse: restricted __le16 degrades to
>> integer
drivers/firmware/qemu_fw_cfg.c:367:25: sparse: cast to restricted __be32
drivers/firmware/qemu_fw_cfg.c:367:25: sparse: cast to restricted __be32
drivers/firmware/qemu_fw_cfg.c:367:25: sparse: cast to restricted __be32
drivers/firmware/qemu_fw_cfg.c:367:25: sparse: cast to restricted __be32
drivers/firmware/qemu_fw_cfg.c:367:25: sparse: cast to restricted __be32
drivers/firmware/qemu_fw_cfg.c:367:25: sparse: cast to restricted __be32
>> drivers/firmware/qemu_fw_cfg.c:368:27: sparse: cast to restricted __be16
>> drivers/firmware/qemu_fw_cfg.c:368:27: sparse: cast to restricted __be16
>> drivers/firmware/qemu_fw_cfg.c:368:27: sparse: cast to restricted __be16
>> drivers/firmware/qemu_fw_cfg.c:368:27: sparse: cast to restricted __be16
>> drivers/firmware/qemu_fw_cfg.c:95:39: sparse: restricted __be16 degrades to
>> integer
>> drivers/firmware/qemu_fw_cfg.c:95:58: sparse: restricted __le16 degrades to
>> integer
>> drivers/firmware/qemu_fw_cfg.c:420:22: sparse: cast to restricted __le32
vim +95 drivers/firmware/qemu_fw_cfg.c
60 .size = 0x0a,
61 .ctrl_offset = 0x08,
62 .data_offset = 0x00,
63 .is_mmio = true,
64 }, {
65 .name = "fw_cfg MMIO on sun4m",
> 66 .base = 0xd0510,
67 .size = 0x03,
68 .ctrl_offset = 0x00,
69 .data_offset = 0x02,
70 .is_mmio = true,
71 }, {
72 .name = "fw_cfg MMIO on ppc/mac",
73 .base = 0xf510,
74 .size = 0x03,
75 .ctrl_offset = 0x00,
76 .data_offset = 0x02,
77 .is_mmio = true,
78 }, { } /* END */
79 };
80
81 /* fw_cfg device i/o currently selected option set */
82 static struct fw_cfg_access *fw_cfg_mode;
83
84 /* fw_cfg device i/o register addresses */
85 static void __iomem *fw_cfg_dev_base;
86 static void __iomem *fw_cfg_reg_ctrl;
87 static void __iomem *fw_cfg_reg_data;
88
89 /* atomic access to fw_cfg device (potentially slow i/o, so using
mutex) */
90 static DEFINE_MUTEX(fw_cfg_dev_lock);
91
92 /* pick appropriate endianness for selector key */
93 static inline u16 fw_cfg_sel_endianness(u16 key)
94 {
> 95 return fw_cfg_mode->is_mmio ? cpu_to_be16(key) :
cpu_to_le16(key);
96 }
97
98 /* type for fw_cfg "directory scan" visitor/callback function */
99 typedef int (*fw_cfg_file_callback)(const struct fw_cfg_file *f);
100
101 /* run a given callback on each fw_cfg directory entry */
102 static int fw_cfg_scan_dir(fw_cfg_file_callback callback)
103 {
104 int ret = 0;
105 u32 count, i;
106 struct fw_cfg_file f;
107
108 mutex_lock(&fw_cfg_dev_lock);
109 iowrite16(fw_cfg_sel_endianness(FW_CFG_FILE_DIR),
fw_cfg_reg_ctrl);
110 ioread8_rep(fw_cfg_reg_data, &count, sizeof(count));
> 111 for (i = 0; i < be32_to_cpu(count); i++) {
112 ioread8_rep(fw_cfg_reg_data, &f, sizeof(f));
113 ret = callback(&f);
114 if (ret)
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[Qemu-devel] [Bug 1502613] [NEW] [Feature Request] Battery Status / Virtual Battery
Public bug reported: When using virtualization on notebooks heavily then virtual machines do not realize that they're running on a notebook device causing high power consumption because they're not switching into a optimized "laptop mode". This leads to the circumstance that they are trying to do things like defragmentation / virtus scan / etc. while the host is still running on batteries. So it would be great if QEMU / KVM would have support for emulating "Virtual Batteries" to guests causing them to enable power-saving options like disabling specific services / devices / file operations automatically by OS. Optionally a great feature would be to set virtual battery's status manually. For example: Current charge rate / charging / discharging / ... ** Affects: qemu Importance: Undecided Status: New ** Tags: battery management power virtual -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1502613 Title: [Feature Request] Battery Status / Virtual Battery Status in QEMU: New Bug description: When using virtualization on notebooks heavily then virtual machines do not realize that they're running on a notebook device causing high power consumption because they're not switching into a optimized "laptop mode". This leads to the circumstance that they are trying to do things like defragmentation / virtus scan / etc. while the host is still running on batteries. So it would be great if QEMU / KVM would have support for emulating "Virtual Batteries" to guests causing them to enable power-saving options like disabling specific services / devices / file operations automatically by OS. Optionally a great feature would be to set virtual battery's status manually. For example: Current charge rate / charging / discharging / ... To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1502613/+subscriptions
Re: [Qemu-devel] [PATCH] linux-user: Remove type casts to union type
08.02.2015 17:40, Stefan Weil wrote:
> Casting to a union type is a gcc (and clang) extension. Other compilers
> might not support it. This is not a problem today, but the type casts
> can be removed easily. Smatch now no longer complains like before:
I've applied this patch with the following change:
> linux-user/syscall.c | 10 ++
> 1 file changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/linux-user/syscall.c b/linux-user/syscall.c
> index 852308e..ec137db 100644
> --- a/linux-user/syscall.c
> +++ b/linux-user/syscall.c
> @@ -2663,8 +2663,9 @@ static inline abi_long host_to_target_semarray(int
> semid, abi_ulong target_addr,
> }
>
> static inline abi_long do_semctl(int semid, int semnum, int cmd,
> - union target_semun target_su)
> + abi_ulong target_arg)
> {
> +union target_semun target_su;
union target_semun target_su = { .buf = target_arg };
> union semun arg;
> struct semid_ds dsarg;
> unsigned short *array = NULL;
> @@ -2673,6 +2674,8 @@ static inline abi_long do_semctl(int semid, int semnum,
> int cmd,
> abi_long err;
> cmd &= 0xff;
>
> +target_su.buf = target_arg;
and dropping this hunk.
Thank you!
/mjt
Re: [Qemu-devel] [PATCH] qtest/ahci: fix redundant assertion
21.09.2015 23:55, John Snow wrote: > Fixes https://bugs.launchpad.net/qemu/+bug/1497711 > > (!ncq || (ncq && lba48)) is the same as > (!ncq || lba48). Applied to -trivial too, just in case :) Thank you! /mjt
Re: [Qemu-devel] [PATCH] MAINTAINERS: Small IDE/FDC touchup
24.09.2015 20:50, John Snow wrote: > libqos/ahci and tests/fdc-test are under my purview also, > include them in the appropriate stanzas. Applied to -trivial too, just in case :) Thank you for adding more files to MAINTAINERS! /mjt
Re: [Qemu-devel] [PATCH v3] linux-user/syscall.c: malloc()/calloc() to g_malloc()/g_try_malloc()/g_new0()
On Thu, Oct 1, 2015 at 8:15 PM, Harmandeep Kaur
wrote:
> @@ -1881,7 +1881,7 @@ static struct iovec *lock_iovec(int type, abi_ulong
> target_addr,
> return NULL;
> }
>
> -vec = calloc(count, sizeof(struct iovec));
> +vec = g_try_new0(struct iovec, count);
> if (vec == NULL) {
> errno = ENOMEM;
> return NULL;
> @@ -1945,7 +1945,7 @@ static struct iovec *lock_iovec(int type, abi_ulong
> target_addr,
> }
> unlock_user(target_vec, target_addr, 0);
> fail2:
> -free(vec);
> +g_free(vec);
> errno = err;
> return NULL;
> }
unlock_iovec() must use g_free().
> @@ -2672,14 +2672,14 @@ static inline abi_long target_to_host_semarray(int
> semid, unsigned short **host_
>
> nsems = semid_ds.sem_nsems;
>
> -*host_array = malloc(nsems*sizeof(unsigned short));
> +*host_array = g_try_new(unsigned short, nsems);
> if (!*host_array) {
> return -TARGET_ENOMEM;
> }
> array = lock_user(VERIFY_READ, target_addr,
>nsems*sizeof(unsigned short), 1);
> if (!array) {
> -free(*host_array);
> +g_free(*host_array);
> return -TARGET_EFAULT;
> }
>
host_to_target_semarray() must use g_free().
[Qemu-devel] 'make check' now has "Warning: path not on HugeTLBFS: /tmp/vhost-test-MJ3mXo" warnings
I noticed that 'make check' now produces a warning while running the check-qtest-i386 and -x86_64 tests: "Warning: path not on HugeTLBFS: /tmp/vhost-test-MJ3mXo" which I think is a relatively recent development. Does anybody know what's causing this and if we can reasonably suppress it or turn it into a "skipping test X because Y" kind of message? (It's the one in exec.c that triggers.) thanks -- PMM
Re: [Qemu-devel] [PATCH 3/4] checkpatch: adapt some tests to QEMU
On 17 September 2015 at 17:32, Paolo Bonzini wrote:
>
>
> On 17/09/2015 18:16, Peter Maydell wrote:
>> On 17 September 2015 at 17:00, Paolo Bonzini wrote:
>>>
>>>
>>> On 17/09/2015 16:24, Peter Maydell wrote:
Can we revert this one, please? Checkpatch now warns about constructs
like
typedef struct MyDevice {
DeviceState parent;
int reg0, reg1, reg2;
} MyDevice;
> I think it varies depending on the maintainer. PPC, USB, SCSI, ACPI all
> use a separate typedef. I'll prepare a revert.
Ping on that revert patch? I can't find it onlist...
thanks
-- PMM
Re: [Qemu-devel] [PATCH v4] target-arm: Break the TB after ISB to execute self-modified code correctly
On 2 October 2015 at 13:38, Sergey Sorokin wrote: > If any store instruction writes the code inside the same TB > after this store insn, the execution of the TB must be stopped > to execute new code correctly. > As described in ARMv8 manual D3.4.6 a self-modified code need to do > IC invalidation to be valid, and ISB after it. So it's enough to end the TB > after ISB instruction on the code translation. > Also this TB break is necessary to take any pending interrupts immediately > according to ARMv8 ARM D1.14.4. > > Signed-off-by: Sergey Sorokin > --- > Changes since previous version: > * ARMv6 ISB was also fixed. > * Second reason for TB breaking was mentioned in comments > and the commit message. > * A compilation error was fixed. > > target-arm/helper.c| 6 +- > target-arm/translate-a64.c | 8 +++- > target-arm/translate.c | 17 +++-- > 3 files changed, 27 insertions(+), 4 deletions(-) Applied to target-arm.next, thanks. -- PMM
Re: [Qemu-devel] QEMU+Linux ARMv7A current state
On Sat, Oct 03, 2015 at 02:31:08PM -0700, Peter Crosthwaite wrote: > QEMU cubieboard has no usable storage media, but the real hardware > does have AHCI sata. I added sysbus-ahci at the right place but turns > out the SATA controller has some custom power/clock (not really > sure??) registers specific to this SoC. It sets/clears bits then polls > them back expecting them to change to the other value asynchronously. > The kernel device probe then times-out. So I subclassed sysbus-ahci > and added the missing registers and forced the polled registers to the > "I'm done" state. It works. Cool, are you going to submit patches for this? > I am using meta-sunxi Yocto-layer to build out the allwinner custom > kernel/rootfs etc, and with the clock and Sata changes I get a boot. > But when I change to the unedited kernel+dtb+rootfs I get stuck. RTC > messages are around the point of failure which is not modelled in > QEMU, so that is suspect. I don't know, this needs some investigation; on my side a recent multi_v7_defconfig kernel, unmodified sun4i-a10-cubieboard.dtb and a rootfs built with buildroot mounted through NFS work just fine, with the mentioned warnings regarding clk registers and also these: Ignoring attempt to switch CPSR_A flag from non-secure world with SCR.AW bit clear Ignoring attempt to switch CPSR_F flag from non-secure world with SCR.FW bit clear which probably would be solved by setting the property 'has_el3' of the CPU to false before realization. Beniamino
Re: [Qemu-devel] [PATCH v3 2/4] firmware: use acpi to detect QEMU fw_cfg device for sysfs fw_cfg driver
On Sun, Oct 04, 2015 at 10:54:57AM +0300, Michael S. Tsirkin wrote:
> On Sat, Oct 03, 2015 at 07:28:07PM -0400, Gabriel L. Somlo wrote:
> > From: Gabriel Somlo
> >
> > Instead of blindly probing fw_cfg registers at known IOport and MMIO
> > locations, use the ACPI subsystem to determine whether a QEMU fw_cfg
> > device is present, and, if found, to initialize it.
> >
> > This limits portability to architectures which support ACPI (x86 and
> > UEFI-enabled aarch64), but avoids touching hardware registers before
> > being certain that our device is present.
> >
> > NOTE: The standard way to verify the presence of fw_cfg on arm VMs
> > would have been to use the device tree, but that would have left out
> > x86, which is the primary architecture targeted by this patch.
> >
> > Signed-off-by: Gabriel Somlo
>
> IMHO it's not a good idea to probe registers provided
> by CRS like this.
> It seems quite reasonable that we'd want to add some
> extra registers in the future, and this probing will break.
>
> Further, accessing registers directly means that there's
> no way to have ACPI code access them as that would
> cause race conditions.
>
> Maybe we should provide access methods in ACPI instead?
OK, I think I understand what you meant by "don't poke CRS" in the
other thread...
So, you're proposing I move the follwing bits:
/* atomic access to fw_cfg device (potentially slow i/o, so using
* mutex) */
static DEFINE_MUTEX(fw_cfg_dev_lock);
/* pick appropriate endianness for selector key */
static inline u16 fw_cfg_sel_endianness(u16 key)
{
return fw_cfg_is_mmio ? cpu_to_be16(key) : cpu_to_le16(key);
}
/* type for fw_cfg "directory scan" visitor/callback function */
typedef int (*fw_cfg_file_callback)(const struct fw_cfg_file *f);
/* run a given callback on each fw_cfg directory entry */
static int fw_cfg_scan_dir(fw_cfg_file_callback callback)
{
int ret = 0;
u32 count, i;
struct fw_cfg_file f;
mutex_lock(&fw_cfg_dev_lock);
iowrite16(fw_cfg_sel_endianness(FW_CFG_FILE_DIR), fw_cfg_reg_ctrl);
ioread8_rep(fw_cfg_reg_data, &count, sizeof(count));
for (i = 0; i < be32_to_cpu(count); i++) {
ioread8_rep(fw_cfg_reg_data, &f, sizeof(f));
ret = callback(&f);
if (ret)
break;
}
mutex_unlock(&fw_cfg_dev_lock);
return ret;
}
/* read chunk of given fw_cfg blob (caller responsible for
* sanity-check) */
static inline void fw_cfg_read_blob(u16 key,
void *buf, loff_t pos, size_t count)
{
mutex_lock(&fw_cfg_dev_lock);
iowrite16(fw_cfg_sel_endianness(key), fw_cfg_reg_ctrl);
while (pos-- > 0)
ioread8(fw_cfg_reg_data);
ioread8_rep(fw_cfg_reg_data, buf, count);
mutex_unlock(&fw_cfg_dev_lock);
}
into the FWCF, "QEMU0002" node as an AML method ? Have ACPI provide
mutual exclusion against competing readers, and somehow figure out how
to call the ACPI/AML code from the guest-side kernel driver whenever
I need to call fw_cfg_read_blob() ?
I guess I could implement fw_cfg_scan_dir() using fw_cfg_read_blob():
u32 count;
size_t bufsize;
void *buf;
fw_cfg_read_blob(FW_CFG_FILE_DIR, &count, 0, sizeof(u32));
bufsize = sizeof(u32) + count * sizeof(struct fw_cfg_file);
buf = kalloc(bufsize);
fw_cfg_read_blob(FW_CFG_FILE_DIR, buf, 0, bufsize);
...
/* now read all the blob meta-data from buf ... */
It would be 100% atomic, but since we can safely assume the fw_cfg
contents never change, it'd be OK.
The atomicity of the ACPI version of fw_cfg_read_blob(), picking the
right endianness for the selector, etc. would have to be done in AML
within the QEMU host-side patch.
If you know of anything I can look at for a good ASL example, please
point it out to me. I'm going to go away now and spend some quality
time with the ACPI spec :)
Thanks,
--Gabriel
>
>
> > ---
> > .../ABI/testing/sysfs-firmware-qemu_fw_cfg | 4 +
> > drivers/firmware/Kconfig | 2 +-
> > drivers/firmware/qemu_fw_cfg.c | 201
> > +++--
> > 3 files changed, 113 insertions(+), 94 deletions(-)
> >
> > diff --git a/Documentation/ABI/testing/sysfs-firmware-qemu_fw_cfg
> > b/Documentation/ABI/testing/sysfs-firmware-qemu_fw_cfg
> > index f1ef44e..e9761bf 100644
> > --- a/Documentation/ABI/testing/sysfs-firmware-qemu_fw_cfg
> > +++ b/Documentation/ABI/testing/sysfs-firmware-qemu_fw_cfg
> > @@ -76,6 +76,10 @@ Description:
> > the port number of the control register. I.e., the two ports
> > are overlapping, and can not be mapped separately.
> >
> > + NOTE 2. QEMU publishes the register details in the device tree
> > + on arm guests, and in ACPI (under _HID "QEMU0002") on x86 and
> > + select arm (aa
Re: [Qemu-devel] [PATCH v3 2/4] firmware: use acpi to detect QEMU fw_cfg device for sysfs fw_cfg driver
On Sun, Oct 04, 2015 at 04:24:00PM -0400, Gabriel L. Somlo wrote:
> On Sun, Oct 04, 2015 at 10:54:57AM +0300, Michael S. Tsirkin wrote:
> > On Sat, Oct 03, 2015 at 07:28:07PM -0400, Gabriel L. Somlo wrote:
> > >
> > > Instead of blindly probing fw_cfg registers at known IOport and MMIO
> > > locations, use the ACPI subsystem to determine whether a QEMU fw_cfg
> > > device is present, and, if found, to initialize it.
> > >
> > > This limits portability to architectures which support ACPI (x86 and
> > > UEFI-enabled aarch64), but avoids touching hardware registers before
> > > being certain that our device is present.
> > >
> > > NOTE: The standard way to verify the presence of fw_cfg on arm VMs
> > > would have been to use the device tree, but that would have left out
> > > x86, which is the primary architecture targeted by this patch.
> > >
> > > Signed-off-by: Gabriel Somlo
> >
> > IMHO it's not a good idea to probe registers provided
> > by CRS like this.
> > It seems quite reasonable that we'd want to add some
> > extra registers in the future, and this probing will break.
> >
> > Further, accessing registers directly means that there's
> > no way to have ACPI code access them as that would
> > cause race conditions.
> >
> > Maybe we should provide access methods in ACPI instead?
>
> OK, I think I understand what you meant by "don't poke CRS" in the
> other thread...
>
> So, you're proposing I move the follwing bits:
>
> /* atomic access to fw_cfg device (potentially slow i/o, so using
>* mutex) */
> static DEFINE_MUTEX(fw_cfg_dev_lock);
>
> /* pick appropriate endianness for selector key */
> static inline u16 fw_cfg_sel_endianness(u16 key)
> {
> return fw_cfg_is_mmio ? cpu_to_be16(key) : cpu_to_le16(key);
> }
>
> /* type for fw_cfg "directory scan" visitor/callback function */
> typedef int (*fw_cfg_file_callback)(const struct fw_cfg_file *f);
>
> /* run a given callback on each fw_cfg directory entry */
> static int fw_cfg_scan_dir(fw_cfg_file_callback callback)
> {
> int ret = 0;
> u32 count, i;
> struct fw_cfg_file f;
>
> mutex_lock(&fw_cfg_dev_lock);
> iowrite16(fw_cfg_sel_endianness(FW_CFG_FILE_DIR), fw_cfg_reg_ctrl);
> ioread8_rep(fw_cfg_reg_data, &count, sizeof(count));
> for (i = 0; i < be32_to_cpu(count); i++) {
> ioread8_rep(fw_cfg_reg_data, &f, sizeof(f));
> ret = callback(&f);
> if (ret)
> break;
> }
> mutex_unlock(&fw_cfg_dev_lock);
> return ret;
> }
>
> /* read chunk of given fw_cfg blob (caller responsible for
>* sanity-check) */
> static inline void fw_cfg_read_blob(u16 key,
> void *buf, loff_t pos, size_t count)
> {
> mutex_lock(&fw_cfg_dev_lock);
> iowrite16(fw_cfg_sel_endianness(key), fw_cfg_reg_ctrl);
> while (pos-- > 0)
> ioread8(fw_cfg_reg_data);
> ioread8_rep(fw_cfg_reg_data, buf, count);
> mutex_unlock(&fw_cfg_dev_lock);
> }
>
> into the FWCF, "QEMU0002" node as an AML method ? Have ACPI provide
> mutual exclusion against competing readers, and somehow figure out how
> to call the ACPI/AML code from the guest-side kernel driver whenever
> I need to call fw_cfg_read_blob() ?
>
> I guess I could implement fw_cfg_scan_dir() using fw_cfg_read_blob():
>
> u32 count;
> size_t bufsize;
> void *buf;
> fw_cfg_read_blob(FW_CFG_FILE_DIR, &count, 0, sizeof(u32));
> bufsize = sizeof(u32) + count * sizeof(struct fw_cfg_file);
> buf = kalloc(bufsize);
> fw_cfg_read_blob(FW_CFG_FILE_DIR, buf, 0, bufsize);
> ...
> /* now read all the blob meta-data from buf ... */
>
> It would be 100% atomic, but since we can safely assume the fw_cfg
> contents never change, it'd be OK.
I meant "wouldn't be 100% atomic", as in "it would be a case of
verify-then-use"...
Sorry,
--Gabriel
>
> The atomicity of the ACPI version of fw_cfg_read_blob(), picking the
> right endianness for the selector, etc. would have to be done in AML
> within the QEMU host-side patch.
>
> If you know of anything I can look at for a good ASL example, please
> point it out to me. I'm going to go away now and spend some quality
> time with the ACPI spec :)
>
> Thanks,
> --Gabriel
Re: [Qemu-devel] QEMU+Linux ARMv7A current state
On 10/04/2015 12:56 PM, Beniamino Galvani wrote: On Sat, Oct 03, 2015 at 02:31:08PM -0700, Peter Crosthwaite wrote: QEMU cubieboard has no usable storage media, but the real hardware does have AHCI sata. I added sysbus-ahci at the right place but turns out the SATA controller has some custom power/clock (not really sure??) registers specific to this SoC. It sets/clears bits then polls them back expecting them to change to the other value asynchronously. The kernel device probe then times-out. So I subclassed sysbus-ahci and added the missing registers and forced the polled registers to the "I'm done" state. It works. Cool, are you going to submit patches for this? I am using meta-sunxi Yocto-layer to build out the allwinner custom kernel/rootfs etc, and with the clock and Sata changes I get a boot. But when I change to the unedited kernel+dtb+rootfs I get stuck. RTC messages are around the point of failure which is not modelled in QEMU, so that is suspect. I don't know, this needs some investigation; on my side a recent multi_v7_defconfig kernel, unmodified sun4i-a10-cubieboard.dtb and a rootfs built with buildroot mounted through NFS work just fine, with the mentioned warnings regarding clk registers and also these: What is your qemu command line ? Thanks, Guenter Ignoring attempt to switch CPSR_A flag from non-secure world with SCR.AW bit clear Ignoring attempt to switch CPSR_F flag from non-secure world with SCR.FW bit clear which probably would be solved by setting the property 'has_el3' of the CPU to false before realization. Beniamino
Re: [Qemu-devel] [PULL 00/10] Fix device introspection regressions
On 2 October 2015 at 18:20, Markus Armbruster wrote: > QMP command device-list-properties regressed in 2.1: it can crash or > leave dangling pointers behind. > > -device FOO,help regressed in 2.2: it no longer works for > non-pluggable devices. I tried to fix that some time ago[*], but my > fix failed review. This is my second, more comprehensive try. > > PATCH 1-3 fix one class of bugs involved in the regressions, PATCH 4-5 > are libqtest preliminaries, PATCH 6 adds tests to demonstrate the > remaining bugs, PATCH 7-9 fix them to a degree (see PATCH 8 for > limitations), and PATCH 10 cleans up. This ordering breaks bisection of 'make check', as I found out when I tried to figure out which of the patches in this pull was causing an OSX test failure. Please can you reorder them so that 'make check' works at all points in the series? > The following changes since commit ff770b07f34d28b79013a83989bd6c85f8f16b2f: > > Merge remote-tracking branch 'remotes/cody/tags/block-pull-request' into > staging (2015-10-02 11:01:18 +0100) > > are available in the git repository at: > > git://repo.or.cz/qemu/armbru.git tags/pull-monitor-2015-10-02 > > for you to fetch changes up to e927162a6fa2fa6144de9d1d11cc9448a2143671: > > Revert "qdev: Use qdev_get_device_class() for -device ,help" > (2015-10-02 16:45:53 +0200) > > > Fix device introspection regressions > > 'make check' failure on OSX: /aarch64/device/introspect/list: OK /aarch64/device/introspect/none: OK /aarch64/device/introspect/abstract: OK /aarch64/device/introspect/concrete: ** ERROR:/Users/pm215/src/qemu-for-merges/qom/object.c:333:void object_initialize_with_type(void *, size_t, TypeImpl *): assertion failed: (type != NULL) Broken pipe FAIL I have no idea why this only failed on OSX... Backtrace: (gdb) bt #0 0x7fff9145e286 in __pthread_kill () #1 0x7fff912529f9 in pthread_kill () #2 0x7fff956db9b3 in abort () #3 0x000110d21c50 in g_assertion_message () #4 0x000110d21c95 in g_assertion_message_expr () #5 0x0001102909ad in object_initialize_with_type (data=, size=, type=) at /Users/pm215/src/qemu-for-merges/qom/object.c:333 #6 0x00011007513b in virtio_instance_init_common (proxy_obj=0x7ffae2841000, data=0x7ffae2849120, vdev_size=6, vdev_name=0x0) at /Users/pm215/src/qemu-for-merges/hw/virtio/virtio.c:1468 #7 0x0001102908ee in type_get_parent [inlined] () at /Users/pm215/src/qemu-for-merges/qom/object.c:344 #8 type_get_by_name [inlined] () at /Users/pm215/src/qemu-for-merges/qom/object.c:325 #9 type_table_lookup [inlined] () at /Users/pm215/src/qemu-for-merges/qom/object.c:165 #10 type_table_get [inlined] () at /Users/pm215/src/qemu-for-merges/qom/object.c:159 #11 object_post_init_with_type [inlined] () at /Users/pm215/src/qemu-for-merges/qom/object.c:93 #12 0x0001102908ee in object_initialize_with_type (data=0x7ffae2841000, size=, type=0x7ffae1547be0) at /Users/pm215/src/qemu-for-merges/qom/object.c:345 #13 0x00011029124b in object_new_with_type [inlined] () at /Users/pm215/src/qemu-for-merges/qom/object.c:430 #14 0x00011029124b in object_new (typename=) at /Users/pm215/src/qemu-for-merges/qom/object.c:440 #15 0x00011013ec1c in qmp_device_list_properties (typename=0x7ffae1608ac0 "virtio-tablet-pci", errp=) at /Users/pm215/src/qemu-for-merges/qmp.c:529 #16 0x000110136987 in qmp_marshal_device_list_properties (args=, ret=0x7fff4fc26198, errp=0x7fff4fc261a0) at qmp-marshal.c:1693 #17 0x00011000f6c5 in handle_qmp_command (parser=, tokens=) at /Users/pm215/src/qemu-for-merges/monitor.c:3860 #18 0x0001103206ba in json_message_process_token (lexer=, token=, type=, x=, y=0) at /Users/pm215/src/qemu-for-merges/qobject/json-streamer.c:87 #19 0x000110320367 in json_lexer_feed_char () at /Users/pm215/src/qemu-for-merges/qobject/json-lexer.c:303 #20 0x0001103202ad in json_lexer_feed (lexer=0x7ffae1600d70, buffer=, size=) at /Users/pm215/src/qemu-for-merges/qobject/json-lexer.c:356 #21 0x00011000eb00 in monitor_qmp_read (opaque=, buf=0x7d , size=) at /Users/pm215/src/qemu-for-merges/monitor.c:3875 #22 0x000110126e5a in qemu_chr_be_write [inlined] () at /Users/pm215/src/qemu-for-merges/qemu-char.c:305 #23 0x000110126e5a in tcp_chr_read (chan=, cond=, opaque=0x7ffae1576ac0) at /Users/pm215/src/qemu-for-merges/qemu-char.c:2873 #24 0x000110d020bd in g_main_context_dispatch () #25 0x0001102a19a2 in main_loop_wait (nonblocking=) at /Users/pm215/src/qemu-for-merges/main-loop.c:211 #26 0x00011012f6da in qemu_main (argc=, argv=, envp=0x4fc262c0) at /Users/pm215/src/qemu-for-merges/vl.c:1880 #27 0x7fff905f75c9 in start () thanks -- PMM
Re: [Qemu-devel] QEMU+Linux ARMv7A current state
On Sun, Oct 4, 2015 at 12:56 PM, Beniamino Galvani wrote: > On Sat, Oct 03, 2015 at 02:31:08PM -0700, Peter Crosthwaite wrote: >> QEMU cubieboard has no usable storage media, but the real hardware >> does have AHCI sata. I added sysbus-ahci at the right place but turns >> out the SATA controller has some custom power/clock (not really >> sure??) registers specific to this SoC. It sets/clears bits then polls >> them back expecting them to change to the other value asynchronously. >> The kernel device probe then times-out. So I subclassed sysbus-ahci >> and added the missing registers and forced the polled registers to the >> "I'm done" state. It works. > > Cool, are you going to submit patches for this? > >> I am using meta-sunxi Yocto-layer to build out the allwinner custom >> kernel/rootfs etc, and with the clock and Sata changes I get a boot. >> But when I change to the unedited kernel+dtb+rootfs I get stuck. RTC >> messages are around the point of failure which is not modelled in >> QEMU, so that is suspect. > > I don't know, this needs some investigation; on my side a recent > multi_v7_defconfig kernel, unmodified sun4i-a10-cubieboard.dtb and a > rootfs built with buildroot mounted through NFS work just fine, with > the mentioned warnings regarding clk registers and also these: > Looks like I am hanging in userspace, here is my hang: [4.064068] scsi 0:0:0:0: Direct-Access ATA QEMU HARDDISK 50 PQ: 0 ANSI: 5 [4.075977] sd 0:0:0:0: [sda] 16464 512-byte logical blocks: (8.42 MB/8.03 MiB) [4.082427] sd 0:0:0:0: [sda] Write Protect is off [4.085379] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [4.118143] sd 0:0:0:0: [sda] Attached SCSI disk [5.972385] sun4i-emac 1c0b000.ethernet eth0: Link is Up - 100Mbps/Full - flow control off [5.988629] Sending DHCP requests ., OK [6.011625] IP-Config: Got DHCP answer from 10.0.2.2, my address is 10.0.2.15 [6.021258] IP-Config: Complete: [6.022075] device=eth0, hwaddr=0a:80:64:4f:43:ec, ipaddr=10.0.2.15, mask=255.255.255.0, gw=10.0.2.2 [6.023220] host=10.0.2.15, domain=, nis-domain=(none) [6.023751] bootserver=10.0.2.2, rootserver=10.0.2.2, rootpath= [6.024436] nameserver0=10.0.2.3 [6.025489] usb2-vbus: disabling [6.025876] usb1-vbus: disabling [6.026194] vcc5v0: disabling [6.026514] vcc3v0: disabling [6.148152] EXT4-fs (sda): recovery complete [6.150995] EXT4-fs (sda): mounted filesystem with ordered data mode. Opts: (null) [6.153751] VFS: Mounted root (ext4 filesystem) on device 8:0. [6.157800] devtmpfs: mounted [6.179159] Freeing unused kernel memory: 944K (c0d5c000 - c0e48000) [7.442057] udevd[76]: starting version 182 [ 11.549686] random: nonblocking pool is initialized [ 13.536968] EXT4-fs (sda): re-mounted. Opts: data=ordered [ 16.163781] sunxi-rtc 1c20d00.rtc: Failed to set rtc time. It is highly likely that someone from sunxi knows what is up, given the yocto meta-layer works if you have anyone you can CC. > Ignoring attempt to switch CPSR_A flag from non-secure world with SCR.AW bit > clear > Ignoring attempt to switch CPSR_F flag from non-secure world with SCR.FW bit > clear > > which probably would be solved by setting the property 'has_el3' of > the CPU to false before realization. > That sounds like a bug and should definately be fixed. We should have cpus that do support EL3 saying they dont (due to legacy and lack of testing) but not the other way round. Regards, Peter > Beniamino
Re: [Qemu-devel] QEMU+Linux ARMv7A current state
On Sun, Oct 04, 2015 at 02:11:35PM -0700, Guenter Roeck wrote: > What is your qemu command line ? qemu-system-arm \ -M cubieboard \ -kernel ../linux/zImage-dtb \ -serial stdio \ -append "console=ttyS0 rw root=/dev/nfs nfsroot=10.0.0.1:/nfs,v3 ip=10.0.0.22" \ -m 1024 \ -net nic,vlan=0,model=allwinner-emac \ -net tap,vlan=0,ifname=tap0,script=net-up.sh \ -s \ -d guest_errors Beniamino
Re: [Qemu-devel] QEMU+Linux ARMv7A current state
On 4 October 2015 at 22:39, Peter Crosthwaite wrote: > On Sun, Oct 4, 2015 at 12:56 PM, Beniamino Galvani > wrote: >> Ignoring attempt to switch CPSR_A flag from non-secure world with SCR.AW bit >> clear >> Ignoring attempt to switch CPSR_F flag from non-secure world with SCR.FW bit >> clear >> >> which probably would be solved by setting the property 'has_el3' of >> the CPU to false before realization. >> > > That sounds like a bug and should definately be fixed. We should have > cpus that do support EL3 saying they dont (due to legacy and lack of > testing) but not the other way round. The Allwinner really does have EL3, so we are correct in not setting has_el3 to false. We should figure out what's actually happening here and fix whatever the underlying problem is. (Possibly the real board firmware hands control of FIQ and Abort to an NS kernel by setting SCR.AW/FW, which our built in loader doesn't do? Or the guest really is buggy, or perhaps our GUEST_ERROR logging is a bit overenthusiastic.) thanks -- PMM
Re: [Qemu-devel] QEMU+Linux ARMv7A current state
On 10/04/2015 02:38 PM, Beniamino Galvani wrote: On Sun, Oct 04, 2015 at 02:11:35PM -0700, Guenter Roeck wrote: What is your qemu command line ? qemu-system-arm \ -M cubieboard \ -kernel ../linux/zImage-dtb \ -serial stdio \ -append "console=ttyS0 rw root=/dev/nfs nfsroot=10.0.0.1:/nfs,v3 ip=10.0.0.22" \ -m 1024 \ -net nic,vlan=0,model=allwinner-emac \ -net tap,vlan=0,ifname=tap0,script=net-up.sh \ -s \ -d guest_errors Beniamino With the mainline kernel and sun4i-a10-cubieboard.dtb, this gives me lots of [2.480983] Division by zero in kernel. [2.481074] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.3.0-rc3-00055-gdd36d7393d63 #1 [2.481250] Hardware name: Allwinner A1X (Device Tree) [2.481376] [] (unwind_backtrace) from [] (show_stack+0x10/0x14) [2.481544] [] (show_stack) from [] (dump_stack+0x78/0x94) [2.481700] [] (dump_stack) from [] (Ldiv0+0x8/0x10) [2.481848] [] (Ldiv0) from [] (sun4i_a10_get_mod0_factors+0x74/0xb8) [2.482024] [] (sun4i_a10_get_mod0_factors) from [] (clk_factors_determine_rate+0x68/0xfc) [2.482231] [] (clk_factors_determine_rate) from [] (clk_composite_determine_rate+0x94/0x1d0) [2.482443] [] (clk_composite_determine_rate) from [] (clk_core_round_rate_nolock+0x84/0xa8) [2.482654] [] (clk_core_round_rate_nolock) from [] (clk_round_rate+0x38/0x54) [2.482845] [] (clk_round_rate) from [] (sunxi_mmc_set_ios+0x9c/0x314) [2.483023] [] (sunxi_mmc_set_ios) from [] (mmc_power_up+0xf8/0x104) [2.483197] [] (mmc_power_up) from [] (mmc_start_host+0x44/0x6c) [2.483363] [] (mmc_start_host) from [] (mmc_add_host+0x58/0x7c) [2.483528] [] (mmc_add_host) from [] (sunxi_mmc_probe+0x488/0x590) [2.483701] [] (sunxi_mmc_probe) from [] (platform_drv_probe+0x48/0xa4) Do you have a special devicetree file ? It also doesn't seem to accept the qemu "initrd" argument, which is unexpected. Any idea what might be wrong ? Here is the command line I tried. qemu-system-arm \ -M cubieboard -kernel arch/arm/boot/zImage -no-reboot \ -initrd core-image-minimal-qemuarm.cpio \ -append "rdinit=/sbin/init console=ttyS0" \ -nographic -monitor none -serial stdio \ -dtb arch/arm/boot/dts/sun4i-a10-cubieboard.dtb Thanks, Guenter
Re: [Qemu-devel] QEMU+Linux ARMv7A current state
On Sun, Oct 4, 2015 at 6:08 PM, Guenter Roeck wrote: > On 10/04/2015 02:38 PM, Beniamino Galvani wrote: >> >> On Sun, Oct 04, 2015 at 02:11:35PM -0700, Guenter Roeck wrote: >>> >>> What is your qemu command line ? >> >> >> qemu-system-arm \ >> -M cubieboard \ >> -kernel ../linux/zImage-dtb \ >> -serial stdio \ >> -append "console=ttyS0 rw root=/dev/nfs >> nfsroot=10.0.0.1:/nfs,v3 ip=10.0.0.22" \ >> -m 1024 \ >> -net nic,vlan=0,model=allwinner-emac \ >> -net tap,vlan=0,ifname=tap0,script=net-up.sh \ >> -s \ >> -d guest_errors >> >> Beniamino >> > > With the mainline kernel and sun4i-a10-cubieboard.dtb, this gives me lots of > > [2.480983] Division by zero in kernel. > [2.481074] CPU: 0 PID: 1 Comm: swapper/0 Not tainted > 4.3.0-rc3-00055-gdd36d7393d63 #1 > [2.481250] Hardware name: Allwinner A1X (Device Tree) > [2.481376] [] (unwind_backtrace) from [] > (show_stack+0x10/0x14) > [2.481544] [] (show_stack) from [] > (dump_stack+0x78/0x94) > [2.481700] [] (dump_stack) from [] (Ldiv0+0x8/0x10) > [2.481848] [] (Ldiv0) from [] > (sun4i_a10_get_mod0_factors+0x74/0xb8) > [2.482024] [] (sun4i_a10_get_mod0_factors) from [] > (clk_factors_determine_rate+0x68/0xfc) > [2.482231] [] (clk_factors_determine_rate) from [] > (clk_composite_determine_rate+0x94/0x1d0) > [2.482443] [] (clk_composite_determine_rate) from [] > (clk_core_round_rate_nolock+0x84/0xa8) > [2.482654] [] (clk_core_round_rate_nolock) from [] > (clk_round_rate+0x38/0x54) > [2.482845] [] (clk_round_rate) from [] > (sunxi_mmc_set_ios+0x9c/0x314) > [2.483023] [] (sunxi_mmc_set_ios) from [] > (mmc_power_up+0xf8/0x104) > [2.483197] [] (mmc_power_up) from [] > (mmc_start_host+0x44/0x6c) > [2.483363] [] (mmc_start_host) from [] > (mmc_add_host+0x58/0x7c) > [2.483528] [] (mmc_add_host) from [] > (sunxi_mmc_probe+0x488/0x590) > [2.483701] [] (sunxi_mmc_probe) from [] > (platform_drv_probe+0x48/0xa4) > I think that's the expected warnings we have been ignoring. I have a hack to make them go away. > Do you have a special devicetree file ? > > It also doesn't seem to accept the qemu "initrd" argument, which is > unexpected. > Yes I noticed the same and went to the SATA solution. Regards, Peter > Any idea what might be wrong ? Here is the command line I tried. > > qemu-system-arm \ > -M cubieboard -kernel arch/arm/boot/zImage -no-reboot \ > -initrd core-image-minimal-qemuarm.cpio \ > -append "rdinit=/sbin/init console=ttyS0" \ > -nographic -monitor none -serial stdio \ > -dtb arch/arm/boot/dts/sun4i-a10-cubieboard.dtb > > Thanks, > Guenter >
[Qemu-devel] [PATCH v4] linux-user/syscall.c: malloc()/calloc() to g_malloc()/g_try_malloc()/g_new0()
Convert malloc()/calloc() calls to g_malloc()/g_try_malloc()/g_new0()
in linux-user/syscall.c file
Signed-off-by: Harmandeep Kaur
---
v1->v2 convert the free() call in host_to_target_semarray()
to g_free() and calls g_try_malloc(count) instead of
g_try_malloc(sizeof(count))
v2->v3 used g_try_new() and friends to avoid overflow issues
v3->v4 use g_free for unlock_iovec() and host_to_target_semarray().
linux-user/syscall.c | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/linux-user/syscall.c b/linux-user/syscall.c
index 98b5766..6e90141 100644
--- a/linux-user/syscall.c
+++ b/linux-user/syscall.c
@@ -1559,7 +1559,7 @@ set_timeout:
}
fprog.len = tswap16(tfprog->len);
-filter = malloc(fprog.len * sizeof(*filter));
+filter = g_try_new(struct sock_filter, fprog.len);
if (filter == NULL) {
unlock_user_struct(tfilter, tfprog->filter, 1);
unlock_user_struct(tfprog, optval_addr, 1);
@@ -1575,7 +1575,7 @@ set_timeout:
ret = get_errno(setsockopt(sockfd, SOL_SOCKET,
SO_ATTACH_FILTER, &fprog, sizeof(fprog)));
-free(filter);
+g_free(filter);
unlock_user_struct(tfilter, tfprog->filter, 1);
unlock_user_struct(tfprog, optval_addr, 1);
@@ -1886,7 +1886,7 @@ static struct iovec *lock_iovec(int type, abi_ulong
target_addr,
return NULL;
}
-vec = calloc(count, sizeof(struct iovec));
+vec = g_try_new0(struct iovec, count);
if (vec == NULL) {
errno = ENOMEM;
return NULL;
@@ -1950,7 +1950,7 @@ static struct iovec *lock_iovec(int type, abi_ulong
target_addr,
}
unlock_user(target_vec, target_addr, 0);
fail2:
-free(vec);
+g_free(vec);
errno = err;
return NULL;
}
@@ -1975,7 +1975,7 @@ static void unlock_iovec(struct iovec *vec, abi_ulong
target_addr,
unlock_user(target_vec, target_addr, 0);
}
-free(vec);
+g_free(vec);
}
static inline int target_to_host_sock_type(int *type)
@@ -2677,14 +2677,14 @@ static inline abi_long target_to_host_semarray(int
semid, unsigned short **host_
nsems = semid_ds.sem_nsems;
-*host_array = malloc(nsems*sizeof(unsigned short));
+*host_array = g_try_new(unsigned short, nsems);
if (!*host_array) {
return -TARGET_ENOMEM;
}
array = lock_user(VERIFY_READ, target_addr,
nsems*sizeof(unsigned short), 1);
if (!array) {
-free(*host_array);
+g_free(*host_array);
return -TARGET_EFAULT;
}
@@ -2721,7 +2721,7 @@ static inline abi_long host_to_target_semarray(int
semid, abi_ulong target_addr,
for(i=0; imtype = (abi_long) tswapal(target_mb->mtype);
memcpy(host_mb->mtext, target_mb->mtext, msgsz);
ret = get_errno(msgsnd(msqid, host_mb, msgsz, msgflg));
-free(host_mb);
+g_free(host_mb);
unlock_user_struct(target_mb, msgp, 0);
return ret;
@@ -7723,7 +7723,7 @@ abi_long do_syscall(void *cpu_env, int num, abi_long
arg1,
struct linux_dirent *dirp;
abi_long count = arg3;
-dirp = malloc(count);
+dirp = g_try_malloc(sizeof(count));
if (!dirp) {
ret = -TARGET_ENOMEM;
goto fail;
@@ -7760,7 +7760,7 @@ abi_long do_syscall(void *cpu_env, int num, abi_long
arg1,
ret = count1;
unlock_user(target_dirp, arg2, ret);
}
-free(dirp);
+g_free(dirp);
}
#else
{
--
1.9.1
Re: [Qemu-devel] QEMU+Linux ARMv7A current state
On 10/04/2015 07:21 PM, Peter Crosthwaite wrote: On Sun, Oct 4, 2015 at 6:08 PM, Guenter Roeck wrote: On 10/04/2015 02:38 PM, Beniamino Galvani wrote: On Sun, Oct 04, 2015 at 02:11:35PM -0700, Guenter Roeck wrote: What is your qemu command line ? qemu-system-arm \ -M cubieboard \ -kernel ../linux/zImage-dtb \ -serial stdio \ -append "console=ttyS0 rw root=/dev/nfs nfsroot=10.0.0.1:/nfs,v3 ip=10.0.0.22" \ -m 1024 \ -net nic,vlan=0,model=allwinner-emac \ -net tap,vlan=0,ifname=tap0,script=net-up.sh \ -s \ -d guest_errors Beniamino With the mainline kernel and sun4i-a10-cubieboard.dtb, this gives me lots of [2.480983] Division by zero in kernel. [2.481074] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.3.0-rc3-00055-gdd36d7393d63 #1 [2.481250] Hardware name: Allwinner A1X (Device Tree) [2.481376] [] (unwind_backtrace) from [] (show_stack+0x10/0x14) [2.481544] [] (show_stack) from [] (dump_stack+0x78/0x94) [2.481700] [] (dump_stack) from [] (Ldiv0+0x8/0x10) [2.481848] [] (Ldiv0) from [] (sun4i_a10_get_mod0_factors+0x74/0xb8) [2.482024] [] (sun4i_a10_get_mod0_factors) from [] (clk_factors_determine_rate+0x68/0xfc) [2.482231] [] (clk_factors_determine_rate) from [] (clk_composite_determine_rate+0x94/0x1d0) [2.482443] [] (clk_composite_determine_rate) from [] (clk_core_round_rate_nolock+0x84/0xa8) [2.482654] [] (clk_core_round_rate_nolock) from [] (clk_round_rate+0x38/0x54) [2.482845] [] (clk_round_rate) from [] (sunxi_mmc_set_ios+0x9c/0x314) [2.483023] [] (sunxi_mmc_set_ios) from [] (mmc_power_up+0xf8/0x104) [2.483197] [] (mmc_power_up) from [] (mmc_start_host+0x44/0x6c) [2.483363] [] (mmc_start_host) from [] (mmc_add_host+0x58/0x7c) [2.483528] [] (mmc_add_host) from [] (sunxi_mmc_probe+0x488/0x590) [2.483701] [] (sunxi_mmc_probe) from [] (platform_drv_probe+0x48/0xa4) I think that's the expected warnings we have been ignoring. I have a hack to make them go away. Division by zero isn't something that should be ignored. Any idea where it is coming from ? Also, is your hack in the kernel or in qemu ? Do you have a special devicetree file ? It also doesn't seem to accept the qemu "initrd" argument, which is unexpected. Yes I noticed the same and went to the SATA solution. Here is a one-line qemu fix for the initrd problem. diff --git a/hw/arm/cubieboard.c b/hw/arm/cubieboard.c index 1582250..db3ec40 100644 --- a/hw/arm/cubieboard.c +++ b/hw/arm/cubieboard.c @@ -71,6 +71,7 @@ static void cubieboard_init(MachineState *machine) cubieboard_binfo.ram_size = machine->ram_size; cubieboard_binfo.kernel_filename = machine->kernel_filename; cubieboard_binfo.kernel_cmdline = machine->kernel_cmdline; +cubieboard_binfo.initrd_filename = machine->initrd_filename; arm_load_kernel(&s->a10->cpu, &cubieboard_binfo); } Guess that is less complex than getting sata to work ? Thanks, Guenter
Re: [Qemu-devel] [PATCH v8 00/54] Postcopy implementation
On Mon, Sep 28, 2015 at 05:51:39PM +0100, Dr. David Alan Gilbert (git) wrote: > From: "Dr. David Alan Gilbert" > > This is the 8th cut of my version of postcopy. > > The userfaultfd linux kernel code is now in the upstream kernel > tree, and so 4.3-rc3 can be used without modification. > > This qemu series can be found at: > https://github.com/orbitfp7/qemu.git > on the wp3-postcopy-v8 tag > > > Testing status: > * Tested heavily on x86 > * Smoke tested on aarch64 (so it does work on different page sizes) > * Power is unhappy for me (but gets further than the htab problem > v7 used to have) (I get a kvm run failed) As I said earlier, postcopy migration works on Power, but memory hotplug seems to have some problem. qemu-system-ppc64 ... -object memory-backend-ram,id=ram0,size=2G -device pc-dimm,memdev=ram0 qemu/exec.c:1278: find_ram_offset: Assertion `size != 0' failed. Does this happen on x86 too ? Regards, Bharata.
Re: [Qemu-devel] [PATCH 21/36] misc: spelling
Michael Tokarev writes: > 25.09.2015 19:08, Eric Blake wrote: >> On 09/25/2015 08:03 AM, marcandre.lur...@redhat.com wrote: >>> From: Marc-André Lureau >>> >>> --- >>> monitor.c | 2 +- >>> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> Trivial, can be applied now without waiting for pending qapi patches. >> >> Reviewed-by: Eric Blake > > Note there's no S-o-b line in the original patch (whole series, > looks like). Hopefully it is okay for such a really trivial > patch :) > > Applied, thanks! It may be legally safe, but do we really want to engage in judging whether patches are copyrightable or not? Besides, it sets a bad example. Marc-André, please repost your patches ready for -trivial with your S-o-B, cc: qemu-trivial.
Re: [Qemu-devel] [PATCH 1/3] Target-microblaze: Remove unnecessary variable
Michael Tokarev writes: > 25.09.2015 11:37, Shraddha Barke wrote: >> Compress lines and remove the variable . > > Applied to -trivial, removing this piece of commit message: > > --- >> Change made using Coccinelle script >> >> @@ >> expression ret; >> @@ >> - if (ret) return ret; >> - return 0; >> + return ret; >> @@ >> local idexpression ret; >> expression e; >> @@ >> - ret = e; >> - return ret; >> + return e; >> @@ >> type T; identifier i; >> @@ >> - T i; >> ... when != i > --- Why? I like having the semantic patch in the commit message when there's any chance we'll want do the same mechanical change again later. You could save space and include it by reference, though: "Same Coccinelle semantic patch as is commit 74c373e".
Re: [Qemu-devel] [PATCH] Add syscalls for -runas and -chroot tothe seccomp sandbox
"Namsun Ch'o" writes: >> If we intend seccomp to protect against flaws during QEMU setup, then having >> it earlier is neccessary. eg QEMU opening a corrupt qcow2 image which might >> exploit QEMU before the guest CPUs start. > >> If the latter is the case, then we could start with a relaxed seccomp >> sandbox which included the setuid/chroot features, and then switch to a >> more restricted one which blocked them before main_loop() runs. > > That's not possible. Seccomp will not be enforced until seccomp_load(ctx) is > called, after which no new changes to the filter can be made. That's a pity. As long as it's the case, we need to pick: either we protect against rogue guests, or against rogue images. The original idea was the former, and it still makes the most sense to me.
Re: [Qemu-devel] [PATCH] Add syscalls for -runas and -chroot tothe seccomp sandbox
"Namsun Ch'o" writes:
>> Our intention since the beginning was to protect the host from the
>> illegal guest operations. But you do have an interesting point about
>> flaws on qemu itself. Perhaps this might be something I could work on to
>> improve (start a bigger whitelist and get it tighter before guest
>> launches).
>
> The seccomp filters are always passed on through execve(), so it would not be
> possible to have the parent have chroot() whitelisted to chroot, then spawn a
> child without it. As far as I know, even a root process cannot chroot another
> process, even its child, so if the process is to chroot at all, it must have
> the chroot syscall whitelisted. What can be done, however, is using the
> argument passed to -chroot as the filter. The same could be done with setuid,
> by having it only whitelist the uid which is given at -runas.
>
> An example, using chdir (I presume QEMU uses chdir(dir) then chroot(".")):
>
> sh# mkdir /tmp/chroot
> sh# cat | gcc -lseccomp -x c -
> #include
> #include
> #include
>
> void main(void)
> {
> const char *dir = "/tmp/chroot";
>
> scmp_filter_ctx ctx = seccomp_init(SCMP_ACT_TRAP);
>
> seccomp_rule_add(ctx, SCMP_ACT_ALLOW, SCMP_SYS(mkdir), 0);
> seccomp_rule_add(ctx, SCMP_ACT_ALLOW, SCMP_SYS(fchdir), 0);
> seccomp_rule_add(ctx, SCMP_ACT_ALLOW, SCMP_SYS(open), 0);
> seccomp_rule_add(ctx, SCMP_ACT_ALLOW, SCMP_SYS(brk), 0);
> seccomp_rule_add(ctx, SCMP_ACT_ALLOW, SCMP_SYS(chdir), 1,
> SCMP_A0(SCMP_CMP_EQ, dir));
> seccomp_rule_add(ctx, SCMP_ACT_ALLOW, SCMP_SYS(chroot), 1,
> SCMP_A0(SCMP_CMP_EQ, "."));
>
> seccomp_load(ctx);
>
> chdir(dir);
> chroot(".");
>
> /* evil code starts here */
> const int fd = open(".", O_DIRECTORY);
> mkdir("foo");
> chroot("foo");
> fchdir(fd);
> chdir("..");
> chdir("..");
> chdir("..");
> chroot(".");
> }^D^D
> sh# strace -qq -e open,mkdir,chdir,chroot ./a.out 2>&1 | fold -s -w 80
> chdir("/tmp/chroot")= 0
> chroot(".") = 0
> open(".", O_RDONLY|O_DIRECTORY) = 3
> mkdir("foo", 020) = 0
> --- SIGSYS {si_signo=SIGSYS, si_code=SYS_SECCOMP,
> si_call_addr=0x34400a7d397,
> si_syscall=161, si_arch=3221225534} ---
> +++ killed by SIGSYS +++
> Bad system call
> sh# grep 161 /usr/include/asm/unistd_64.h
> #define __NR_chroot 161
>
> So there's really no need to disable chroot() or setuid(), just filter the
> arguments based on command line input to make them impossible to abuse.
Drawback: complexity. If we decide to limit ourselves to the original
threat model (rogue guest), and enter the sandbox only after setup, we
can keep things simpler.
Re: [Qemu-devel] [PATCH v8 04/54] Move configuration section writing
On (Tue) 29 Sep 2015 [09:37:28], Dr. David Alan Gilbert (git) wrote: > From: "Dr. David Alan Gilbert" > > The vmstate_configuration is currently written > in 'qemu_savevm_state_begin', move it to > 'qemu_savevm_state_header' since it's got a hard > requirement that it must be the 1st thing after > the header. > (In postcopy some 'command' sections get sent > early before the saving of the main sections > and hence before qemu_savevm_state_begin). > > Signed-off-by: Dr. David Alan Gilbert Reviewed-by: Amit Shah The function name 'savevm_state_header()' isn't accurate anymore. Not serious for this series. Amit
Re: [Qemu-devel] [PULL 00/10] Fix device introspection regressions
Peter Maydell writes:
> On 2 October 2015 at 18:20, Markus Armbruster wrote:
>> QMP command device-list-properties regressed in 2.1: it can crash or
>> leave dangling pointers behind.
>>
>> -device FOO,help regressed in 2.2: it no longer works for
>> non-pluggable devices. I tried to fix that some time ago[*], but my
>> fix failed review. This is my second, more comprehensive try.
>>
>> PATCH 1-3 fix one class of bugs involved in the regressions, PATCH 4-5
>> are libqtest preliminaries, PATCH 6 adds tests to demonstrate the
>> remaining bugs, PATCH 7-9 fix them to a degree (see PATCH 8 for
>> limitations), and PATCH 10 cleans up.
>
> This ordering breaks bisection of 'make check', as I found out when
> I tried to figure out which of the patches in this pull was causing
> an OSX test failure. Please can you reorder them so that 'make check'
> works at all points in the series?
My ordering may be bad (and I'll recheck it, of course), or it may
temporarily expose a hidden bug. I better figure out what's going on
here.
>> The following changes since commit ff770b07f34d28b79013a83989bd6c85f8f16b2f:
>>
>> Merge remote-tracking branch 'remotes/cody/tags/block-pull-request' into
>> staging (2015-10-02 11:01:18 +0100)
>>
>> are available in the git repository at:
>>
>> git://repo.or.cz/qemu/armbru.git tags/pull-monitor-2015-10-02
>>
>> for you to fetch changes up to e927162a6fa2fa6144de9d1d11cc9448a2143671:
>>
>> Revert "qdev: Use qdev_get_device_class() for -device ,help"
>> (2015-10-02 16:45:53 +0200)
>>
>>
>> Fix device introspection regressions
>>
>>
>
> 'make check' failure on OSX:
>
> /aarch64/device/introspect/list: OK
> /aarch64/device/introspect/none: OK
> /aarch64/device/introspect/abstract: OK
> /aarch64/device/introspect/concrete: **
> ERROR:/Users/pm215/src/qemu-for-merges/qom/object.c:333:void
> object_initialize_with_type(void *, size_t, TypeImpl *): assertion
> failed: (type != NULL)
> Broken pipe
> FAIL
>
> I have no idea why this only failed on OSX...
Can you re-run this with valgrind spliced in?
I use something like
$ QTEST_QEMU_BINARY="valgrind --vgdb-error=1 --log-file=vg.log
qemu-system-aarch64" QTEST_QEMU_IMG=qemu-img
MALLOC_PERTURB_=${MALLOC_PERTURB_:-$((RANDOM % 255 + 1))} gtester -k --verbose
-m=quick tests/device-introspect-test
> Backtrace:
[Confusing due to inlining and other optimizations; snipped for now...]
