Re: [Qemu-devel] [PATCH, RFT] monitor: implement x86 info tlb for PAE and long modes
On Tue, Dec 7, 2010 at 10:08 AM, Alexander Graf ag...@suse.de wrote: On 06.12.2010, at 19:38, Blue Swirl wrote: On Mon, Dec 6, 2010 at 11:12 AM, Alexander Graf ag...@suse.de wrote: On 05.12.2010, at 17:25, Blue Swirl wrote: 'info tlb' didn't show correct information for PAE mode and x86_64 long mode. Implement the missing modes. Also print NX bit for PAE and long modes. Fix off-by-one error in 32 bit mode mask. Signed-off-by: Blue Swirl blauwir...@gmail.com --- I didn't find an OS that enabled PAE, please test and report. Xen does. Just take a random recent xen kernel and run it with -kernel :). Thanks, it does (CR4 is 0xb0). I'm not sure all is correct, after 0x100 the dump looks messy: 00c0: 00c0 --PDA---W 00e0: 00e0 --PDA---W 0100: f000ff53f000f000 XG-D-C--W 01001000: f000ff53f000e000 X--DW 01002000: f000ff53f000f000 XG-D-C--W 01003000: f000ff53f000f000 XG-D-C--W 01004000: f000e987f000f000 X---A--U- Good question XD. I guess the best way to find out if those numbers are right would be to trace the page tables manually. Those were actually caused by a bug of not checking the P bit for intermediate tables, this was fixed in the second version. info tlb shows PA : VA, right? No, VA : PA.
Re: [Qemu-devel] [PATCH 0/6] usb-ccid (v8)
On Tue, Dec 7, 2010 at 10:20 AM, Alon Levy al...@redhat.com wrote: ping. I don't think Anthony's concerns (or mine) have been addressed. Blue Swirl - one patch I forgot is in a later message titled ..v8.1.. with the removal of the libcaccard build. This should be merged with 4/6.
Re: [Qemu-devel] [PATCH 5/6] [RFC] Emulation of Leon3.
On Tue, Dec 7, 2010 at 11:40 AM, Fabien Chouteau chout...@adacore.com wrote:
On 12/06/2010 06:53 PM, Blue Swirl wrote:
On Mon, Dec 6, 2010 at 9:26 AM, Fabien Chouteauchout...@adacore.com
wrote:
Signed-off-by: Fabien Chouteauchout...@adacore.com
---
Makefile.target | 5 +-
hw/leon3.c | 310
++
target-sparc/cpu.h | 10 ++
target-sparc/helper.c | 2 +-
target-sparc/op_helper.c | 30 -
5 files changed, 353 insertions(+), 4 deletions(-)
diff --git a/Makefile.target b/Makefile.target
index 2800f47..f40e04f 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -290,7 +290,10 @@ obj-sparc-y += cirrus_vga.o
else
obj-sparc-y = sun4m.o lance.o tcx.o sun4m_iommu.o slavio_intctl.o
obj-sparc-y += slavio_timer.o slavio_misc.o sparc32_dma.o
-obj-sparc-y += cs4231.o eccmemctl.o sbi.o sun4c_intctl.o
+obj-sparc-y += cs4231.o eccmemctl.o sbi.o sun4c_intctl.o leon3.o
+
+# GRLIB
+obj-sparc-y += grlib_gptimer.o grlib_irqmp.o grlib_apbuart.o
endif
obj-arm-y = integratorcp.o versatilepb.o arm_pic.o arm_timer.o
diff --git a/hw/leon3.c b/hw/leon3.c
new file mode 100644
index 000..ba61081
--- /dev/null
+++ b/hw/leon3.c
@@ -0,0 +1,310 @@
+/*
+ * QEMU Leon3 System Emulator
+ *
+ * Copyright (c) 2010 AdaCore
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining
a copy
+ * of this software and associated documentation files (the Software),
to deal
+ * in the Software without restriction, including without limitation the
rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or
sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be
included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND,
EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT
SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR
OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
ARISING FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
DEALINGS IN
+ * THE SOFTWARE.
+ */
+#include hw.h
+#include qemu-timer.h
+#include qemu-char.h
+#include sysemu.h
+#include boards.h
+#include loader.h
+#include elf.h
+
+#include grlib.h
+
+/* #define DEBUG_LEON3 */
+
+#ifdef DEBUG_LEON3
+#define DPRINTF(fmt, ...) \
+ do { printf(Leon3: fmt , ## __VA_ARGS__); } while (0)
+#else
+#define DPRINTF(fmt, ...)
+#endif
+
+/* Default system clock. */
+#define CPU_CLK (40 * 1000 * 1000)
+
+#define PROM_FILENAME u-boot.bin
+
+#define MAX_PILS 16
+
+typedef struct Leon3State
+{
+ uint32_t cache_control;
+ uint32_t inst_cache_conf;
+ uint32_t data_cache_conf;
+
+ uint64_t entry; /* save kernel entry in case of reset */
+} Leon3State;
+
+Leon3State leon3_state;
Again global state, please refactor. Perhaps most of the cache
handling code belong to target-sparc/op_helper.c and this structure to
CPUSPARCState.
I will try to find a solution for that.
Is it OK to add some Leon3 specific stuff in the CPUSPARCState?
Yes, no problem. You can also drop the intermediate Leon3State
structure if there is no benefit.
+
+/* Cache control: emulate the behavior of cache control registers but
without
+ any effect on the emulated CPU */
+
+#define CACHE_DISABLED 0x0
+#define CACHE_FROZEN 0x1
+#define CACHE_ENABLED 0x3
+
+/* Cache Control register fields */
+
+#define CACHE_CTRL_IF (1 4) /* Instruction Cache Freeze on
Interrupt */
+#define CACHE_CTRL_DF (1 5) /* Data Cache Freeze on Interrupt */
+#define CACHE_CTRL_DP (1 14) /* Data cache flush pending */
+#define CACHE_CTRL_IP (1 15) /* Instruction cache flush pending */
+#define CACHE_CTRL_IB (1 16) /* Instruction burst fetch */
+#define CACHE_CTRL_FI (1 21) /* Flush Instruction cache (Write only)
*/
+#define CACHE_CTRL_FD (1 22) /* Flush Data cache (Write only) */
+#define CACHE_CTRL_DS (1 23) /* Data cache snoop enable */
+
+void leon3_cache_control_int(void)
+{
+ uint32_t state = 0;
+
+ if (leon3_state.cache_control CACHE_CTRL_IF) {
+ /* Instruction cache state */
+ state = leon3_state.cache_control 0x3;
Please add a new define CACHE_CTRL_xxx to replace 0x3.
Done.
+ if (state == CACHE_ENABLED) {
+ state = CACHE_FROZEN;
+ DPRINTF(Instruction cache: freeze\n);
+ }
+
+ leon3_state.cache_control= ~0x3;
+ leon3_state.cache_control |= state;
+ }
+
+ if (leon3_state.cache_control
Re: [Qemu-devel] [PATCH 6/6] [RFC] SPARCV8 asr17 register support.
On Tue, Dec 7, 2010 at 11:51 AM, Fabien Chouteau chout...@adacore.com wrote:
On 12/06/2010 07:01 PM, Blue Swirl wrote:
On Mon, Dec 6, 2010 at 9:26 AM, Fabien Chouteauchout...@adacore.com
wrote:
Signed-off-by: Fabien Chouteauchout...@adacore.com
---
hw/leon3.c | 6 ++
target-sparc/cpu.h | 1 +
target-sparc/machine.c | 2 ++
target-sparc/translate.c | 10 ++
4 files changed, 19 insertions(+), 0 deletions(-)
diff --git a/hw/leon3.c b/hw/leon3.c
index ba61081..9605ce8 100644
--- a/hw/leon3.c
+++ b/hw/leon3.c
@@ -187,6 +187,12 @@ static void main_cpu_reset(void *opaque)
values */
leon3_state.inst_cache_conf = 0x1022;
leon3_state.data_cache_conf = 0x1822;
+
+ /* Asr17 for Leon3 mono-processor */
+ env-asr17= 0 28; /* CPU id */
+ env-asr17= 1 8; /* SPARC V8 multiply and divide
available */
+ env-asr17= env-nwindows -1; /* Number of implemented registers
+ windows */
This is constant...
}
static void leon3_generic_hw_init(ram_addr_t ram_size,
diff --git a/target-sparc/cpu.h b/target-sparc/cpu.h
index 6020ffd..36d49fc 100644
--- a/target-sparc/cpu.h
+++ b/target-sparc/cpu.h
@@ -341,6 +341,7 @@ typedef struct CPUSPARCState {
from PSR) */
#if !defined(TARGET_SPARC64) || defined(TARGET_ABI32)
uint32_t wim; /* window invalid mask */
+ uint32_t asr17; /* asr17 */
... so no new env fields are needed...
#endif
target_ulong tbr; /* trap base register */
#if !defined(TARGET_SPARC64)
diff --git a/target-sparc/machine.c b/target-sparc/machine.c
index 752e431..c530bd3 100644
--- a/target-sparc/machine.c
+++ b/target-sparc/machine.c
@@ -42,6 +42,7 @@ void cpu_save(QEMUFile *f, void *opaque)
qemu_put_be32s(f,env-pil_in);
#ifndef TARGET_SPARC64
qemu_put_be32s(f,env-wim);
+ qemu_put_be32s(f,env-asr17);
... there's also nothing to save/load...
/* MMU */
for (i = 0; i 32; i++)
qemu_put_be32s(f,env-mmuregs[i]);
@@ -138,6 +139,7 @@ int cpu_load(QEMUFile *f, void *opaque, int
version_id)
qemu_get_be32s(f,env-pil_in);
#ifndef TARGET_SPARC64
qemu_get_be32s(f,env-wim);
+ qemu_get_be32s(f,env-asr17);
/* MMU */
for (i = 0; i 32; i++)
qemu_get_be32s(f,env-mmuregs[i]);
diff --git a/target-sparc/translate.c b/target-sparc/translate.c
index 23f9519..65de614 100644
--- a/target-sparc/translate.c
+++ b/target-sparc/translate.c
@@ -58,6 +58,7 @@ static TCGv cpu_hintp, cpu_htba, cpu_hver, cpu_ssr,
cpu_ver;
static TCGv_i32 cpu_softint;
#else
static TCGv cpu_wim;
+static TCGv cpu_asr17;
#endif
/* local register indexes (only used inside old micro ops) */
static TCGv cpu_tmp0;
@@ -2049,6 +2050,8 @@ static void disas_sparc_insn(DisasContext * dc)
rs1 = GET_FIELD(insn, 13, 17);
switch(rs1) {
case 0: /* rdy */
+ gen_movl_TN_reg(rd, cpu_y);
+ break;
#ifndef TARGET_SPARC64
case 0x01 ... 0x0e: /* undefined in the SPARCv8
manual, rdy on the microSPARC
@@ -2058,6 +2061,11 @@ static void disas_sparc_insn(DisasContext * dc)
case 0x10 ... 0x1f: /* implementation-dependent in the
SPARCv8 manual, rdy on the
microSPARC II */
+
+ if (rs1 == 0x11) { /* Read %asr17 */
+ gen_movl_TN_reg(rd, cpu_asr17);
Instead:
r_const = tcg_const_tl(asr constants | dc-def-nwindows - 1);
gen_movl_TN_reg(rd, r_const);
tcg_temp_free(r_const);
OK for me, if it is acceptable to have this Leon3's specific behavior for
all the SPARC32 CPUs.
This will not affect other CPUs when you use CPU feature bits to make
the ASR only available to Leon3.
Re: [Qemu-devel] [PATCH 2/6] [RFC] Emulation of GRLIB IRQMP as defined in GRLIB IP Core User's Manual.
On Tue, Dec 7, 2010 at 10:43 AM, Fabien Chouteau chout...@adacore.com wrote:
On 12/06/2010 06:25 PM, Blue Swirl wrote:
On Mon, Dec 6, 2010 at 9:26 AM, Fabien Chouteauchout...@adacore.com
wrote:
Signed-off-by: Fabien Chouteauchout...@adacore.com
---
hw/grlib_irqmp.c | 416
++
1 files changed, 416 insertions(+), 0 deletions(-)
diff --git a/hw/grlib_irqmp.c b/hw/grlib_irqmp.c
new file mode 100644
index 000..69e1553
--- /dev/null
+++ b/hw/grlib_irqmp.c
@@ -0,0 +1,416 @@
+/*
+ * QEMU GRLIB IRQMP Emulator
+ *
+ * (Multiprocessor and extended interrupt not supported)
+ *
+ * Copyright (c) 2010 AdaCore
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining
a copy
+ * of this software and associated documentation files (the Software),
to deal
+ * in the Software without restriction, including without limitation the
rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or
sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be
included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND,
EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT
SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR
OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
ARISING FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
DEALINGS IN
+ * THE SOFTWARE.
+ */
+
+#include sysbus.h
+#include cpu.h
+
+#include grlib.h
+
+/* #define DEBUG_IRQ */
+
+#ifdef DEBUG_IRQ
+#define DPRINTF(fmt, ...) \
+ do { printf(IRQMP: fmt , ## __VA_ARGS__); } while (0)
+#else
+#define DPRINTF(fmt, ...)
+#endif
+
+#define IRQMP_MAX_CPU 16
+#define IRQMP_REG_SIZE 256 /* Size of memory mapped registers */
+
+/* Memory mapped register offsets */
+#define LEVEL_OFFSET 0x00
+#define PENDING_OFFSET 0x04
+#define FORCE0_OFFSET 0x08
+#define CLEAR_OFFSET 0x0C
+#define MP_STATUS_OFFSET 0x10
+#define BROADCAST_OFFSET 0x14
+#define MASK_OFFSET 0x40
+#define FORCE_OFFSET 0x80
+#define EXTENDED_OFFSET 0xC0
+
+typedef struct IRQMP
+{
+ SysBusDevice busdev;
+
+ CPUSPARCState *env;
Devices should never access CPUState directly. Instead, board level
should create CPU irqs and these should then be passed here.
This case is special, Leon3 is a System-On-Chip and some of the components
are very close to the processor.
IRQMP is not really a peripheral nor a part of the CPU, it's both...
It's not a special case, it could be easily implemented separately.
MMUs, FPUs or co-processors could be special even if they have been
implemented as separate chips with real hardware. But we are actually
not looking at the (historical or current) chip boundaries but more
like what makes sense from QEMU architecture point of view.
+} IRQMP;
+
+typedef struct IRQMPState
+{
+ uint32_t level;
+ uint32_t pending;
+ uint32_t clear;
+ uint32_t broadcast;
+
+ uint32_t mask[IRQMP_MAX_CPU];
+ uint32_t force[IRQMP_MAX_CPU];
+ uint32_t extended[IRQMP_MAX_CPU];
+
+ IRQMP *parent;
+} IRQMPState;
+
+IRQMPState grlib_irqmp_state;
Global state indicates poor design. Why separate IRQMP and IRQMPState?
I have to access IRQMPState in grlib_irqmp_ack and grlib_irqmp_check_irqs,
but I don't see how I can do it without a global variable.
Again, I think that it's related to the special case of IRQMP.
Adding another set of signals for ack, going from board level to the
device should solve the problem cleanly.
+
+void grlib_irqmp_set_irq(void *opaque, int irq, int level);
This should not be global. Again, creating qemu_irqs or moving some of
the code to board level should help.
This one should be static indeed.
+
+DeviceState *grlib_irqmp_create(target_phys_addr_t base,
+ CPUState *env,
+ qemu_irq **cpu_irqs,
+ uint32_t nr_irqs)
+{
+ DeviceState *dev;
+
+ assert(cpu_irqs != NULL);
+
+ dev = qdev_create(NULL, grlib,irqmp);
+ qdev_prop_set_ptr(dev, cpustate, env);
+
+ if (qdev_init(dev)) {
+ return NULL;
+ }
+
+ sysbus_mmio_map(sysbus_from_qdev(dev), 0, base);
+
+ *cpu_irqs = qemu_allocate_irqs(grlib_irqmp_set_irq,
+grlib_irqmp_state,
+ nr_irqs);
+
+ return dev;
+}
+
+static void grlib_irqmp_check_irqs(CPUState *env)
+{
+ uint32_t pend = 0;
+ uint32_t level0 = 0;
+
Re: [Qemu-devel] State of EHCI emulation for QEMU
On Thu, Dec 9, 2010 at 8:32 PM, David S. Ahern daah...@cisco.com wrote: On 12/09/10 06:05, Gerd Hoffmann wrote: Hi, New features developed for the kernel are done in a separate git trees. When a feature is ready for inclusion into the main kernel tree, a pull request is sent. That workflow maintains a complete change history for the feature. Take performance events for example: you can go into Linus' git tree and see the complete history of changes. There's no reason the same methodology cannot be done for qemu. It is done for qemu, pci and block are maintained that way for example. The key difference is that the patches which are accepted into the subsystem branches and then are pulled go through a full review @ qemu-devel before. Yes, I know I've been following qemu and kvm for 3 years now. And there is no reason the same process cannot be done for usb as a subsystem or ehci as a feature branch. Jan already has that started. I realize this is most likely a moot point given that xhci appears better suited for virtualization than ehci, nonetheless it bugs me that you are not wanting to take the time to maintain the code change and sign-off histories. The problem with that approach is that the introduction of new features becomes a single commit. From bisectability point of view this is bad, especially with big features. So I'm much more interested in having a lot of small commits than huge commits or merges, even at the expense of loss of some history information. If we can have both, for example by doing some kind of partial pull, that would be the best of both. I may as well be ignorant about some great git features.
Re: [Qemu-devel] TCG flow vs dyngen
On Fri, Dec 10, 2010 at 9:26 PM, Stefano Bonifazi stefboombas...@gmail.com wrote: Hi all! From the technical documentation (http://www.usenix.org/publications/library/proceedings/usenix05/tech/freenix/bellard.html) I read: The first step is to split each target CPU instruction into fewer simpler instructions called micro operations. Each micro operation is implemented by a small piece of C code. This small C source code is compiled by GCC to an object file. The micro operations are chosen so that their number is much smaller (typically a few hundreds) than all the combinations of instructions and operands of the target CPU. The translation from target CPU instructions to micro operations is done entirely with hand coded code. A compile time tool called dyngen uses the object file containing the micro operations as input to generate a dynamic code generator. This dynamic code generator is invoked at runtime to generate a complete host function which concatenates several micro operations. instead from wikipedia(http://en.wikipedia.org/wiki/QEMU) and other sources I read: The Tiny Code Generator (TCG) aims to remove the shortcoming of relying on a particular version of GCC or any compiler, instead incorporating the compiler (code generator) into other tasks performed by QEMU in run-time. The whole translation task thus consists of two parts: blocks of target code (TBs) being rewritten in TCG ops - a kind of machine-independent intermediate notation, and subsequently this notation being compiled for the host's architecture by TCG. Optional optimisation passes are performed between them. - So, I think that the technical documentation is now obsolete, isn't it? At least we shouldn't link to that paper anymore. There's also documentation generated from qemu-tech.texi that should be up to date. - The old way used much offline (compile time) work compiling the micro operations into host machine code, while if I understand well, TCG does everything in run-time(please correct me if I am wrong!).. so I wonder, how can it be as fast as the previous method (or even faster)? The dyngen way was to extract machine instructions for each micro-op from an object file (op.o) compiled by GCC during QEMU build. TCG instead generates the instructions directly. Since the whole host register set is available for the micro-ops (in contrast to fixed T0/T1/T2 used by dyngen), TCG should outperform dyngen in some cases. In other cases, GCC may have used some optimization when generating the op which would be too complex to implement by the TCG generator so the dyngen op may have been more optimal. The old way was not portable to GCC 4.x series. Now it might be even possible to replace GCC extensions with something else and use other compilers. - If I understand well, TGC runtime flow is the following: - TCG takes the target binary, and splits it into target blocks - if the TB is not cached, TGC translates it (or better the target instructions it is composed by) into TCG micro ops, The above is not the job of TCG (which is host specific), but the target specific translators (target-*/translate.c). - TGC compiles TGC uops into host object code, OK. - TGC caches the TB, - TGC tries to chain the block with others, The above is part of the CPU execution loop (cpu-exec.c), TCG is not involved anymore. - TGC copies the TB into the execution buffer There is no copying. - TGC runs it Am I right? Please correct me, whether I am wrong, as I wanna use that flow scheme for trying to understand the code.. Otherwise right.
Re: [Qemu-devel] TCG flow vs dyngen
Thank you very very much! I'd take months for understanding everything myself from the source code! :) On 12/11/2010 12:02 PM, Blue Swirl wrote: On Fri, Dec 10, 2010 at 9:26 PM, Stefano Bonifazi stefboombas...@gmail.com wrote: [..] - So, I think that the technical documentation is now obsolete, isn't it? At least we shouldn't link to that paper anymore. There's also documentation generated from qemu-tech.texi that should be up to date. Do you mean this: http://www.weilnetz.de/qemu-tech.html ? - If I understand well, TCG runtime flow is the following: - TCG takes the target binary, and splits it into target blocks - if the TB is not cached, TCG translates it (or better the target instructions it is composed by) into TCG micro ops, The above is not the job of TCG (which is host specific), but the target specific translators (target-*/translate.c). Ok, then considering QEMU flow instead of simply TCG, do those steps take place in the order I considered? - TCG caches the TB, - TCG tries to chain the block with others, The above is part of the CPU execution loop (cpu-exec.c), TCG is not involved anymore. Ok! Thank you, now I have a clearer idea of where different operations are implemented.. but again considering the whole QEMU flow, are the steps I reported executed in the order I put them? - TCG copies the TB into the execution buffer There is no copying. Does that mean TCG produces the host object code directly into the emulator's memory for it to fetch? Or does TCG make the emulator even execute that object code as soon as it is produced? But, if the object code is consumed on the fly, it means there is no cashing of it, is it there? What is actually cached? Only target blocks? Their translation into TCG uops? Host binary code generated by TCG? Again many many thanks!!! Stefano B.
Re: [Qemu-devel] [PATCH 1/5] block: add discard support
On Thu, Dec 02, 2010 at 01:12:13PM +0100, Kevin Wolf wrote: DEFINE_PROP_UINT16(physical_block_size, _state, \ _conf.physical_block_size, 512), \ DEFINE_PROP_UINT16(min_io_size, _state, _conf.min_io_size, 0), \ -DEFINE_PROP_UINT32(opt_io_size, _state, _conf.opt_io_size, 0) +DEFINE_PROP_UINT32(opt_io_size, _state, _conf.opt_io_size, 0), \ +DEFINE_PROP_UINT32(discard_granularity, _state, \ + _conf.discard_granularity, 0) Is there no way to get this value automatically? At least for non-raw images (and it should be trivial to implement this in qcow2) I guess we'll want to set it to the cluster size of the image instead of requiring the user to set this value. It's guest visible state, so it must not change due to migrations. For the current implementation all values for it work anyway - if it's smaller than the block size we'll zero out the remainder of the block. That sounds wrong. Surely we should leave partial blocks untouched. Paul
[Qemu-devel] DPRINTF vs tracing
Historically, QEMU code has defined per-file DPRINTF() macros for debug logging. A lot of recent patches continue to use this technique. I want to draw attention to tracing support and its advantages over DPRINTF(). Tracing is an alternative that solves limitations of the DPRINTF() approach: 1. DPRINTF() requires editing a specific source file and recompiling. While fine for the original author during development, DPRINTF() are not available to users hitting issues in production. I have not seen any bug report threads where users are urged to recompile with a DPRINTF() enabled. That's because it just isn't practical and we're losing out on a great source of debug information. With tracing it is now possible for distros to ship with SystemTap support (although LTTng Userspace Tracer and a portable built-in tracer are also supported). I hope we'll soon be able to take advantage of this to get detailed information from users experiencing bugs. Let's start adding useful trace events now so we can ask users to report detailed information in the future. 2. DPRINTF() is file-wide and not selectively filtered. DPRINTF() can only be enabled/disabled for an entire source file at compile time. This leads to noisy outputs that need to be post-filtered for the specific DPRINTF() you were looking for. Trace events can be enabled on a per-event basis. They can be toggled at run-time without recompiling. Less noise and less recompiling makes debugging easier. 3. DPRINTF() duplicates code. People have recently pointed out that the number of copy-pasted DPRINTF() definitions are ridiculous. Tracing allows you to focus on defining and calling specific events without the boilerplate. Add one line to the trace-events file and call it from your source file, that's it. You don't need to know LTTng UST or SystemTap/DTrace. For more information on tracing: http://git.qemu.org/qemu.git/plain/docs/tracing.txt See all existing trace events today: http://git.qemu.org/qemu.git/plain/trace-events Stefan
Re: [Qemu-devel] TCG flow vs dyngen
On Sat, Dec 11, 2010 at 12:29 PM, Stefano Bonifazi stefboombas...@gmail.com wrote: Thank you very very much! I'd take months for understanding everything myself from the source code! :) On 12/11/2010 12:02 PM, Blue Swirl wrote: On Fri, Dec 10, 2010 at 9:26 PM, Stefano Bonifazi stefboombas...@gmail.com wrote: [..] - So, I think that the technical documentation is now obsolete, isn't it? At least we shouldn't link to that paper anymore. There's also documentation generated from qemu-tech.texi that should be up to date. Do you mean this: http://www.weilnetz.de/qemu-tech.html ? Yes. - If I understand well, TCG runtime flow is the following: - TCG takes the target binary, and splits it into target blocks - if the TB is not cached, TCG translates it (or better the target instructions it is composed by) into TCG micro ops, The above is not the job of TCG (which is host specific), but the target specific translators (target-*/translate.c). Ok, then considering QEMU flow instead of simply TCG, do those steps take place in the order I considered? Yes, that's about it. - TCG caches the TB, - TCG tries to chain the block with others, The above is part of the CPU execution loop (cpu-exec.c), TCG is not involved anymore. Ok! Thank you, now I have a clearer idea of where different operations are implemented.. but again considering the whole QEMU flow, are the steps I reported executed in the order I put them? - TCG copies the TB into the execution buffer There is no copying. Does that mean TCG produces the host object code directly into the emulator's memory for it to fetch? Or does TCG make the emulator even execute that object code as soon as it is produced? But, if the object code is consumed on the fly, it means there is no cashing of it, is it there? What is actually cached? Only target blocks? Their translation into TCG uops? Host binary code generated by TCG? There's a large buffer for generated code, allocated in exec.c. This is filled with host code by TCG, when full it is flushed. The CPU execution loop generates new TBs when needed, otherwise the old code can be executed. TCG also uses intermediate ops but those are used only once during translation.
Re: [Qemu-devel] DPRINTF vs tracing
On Sat, Dec 11, 2010 at 1:03 PM, Stefan Hajnoczi stefa...@gmail.com wrote: Historically, QEMU code has defined per-file DPRINTF() macros for debug logging. A lot of recent patches continue to use this technique. I want to draw attention to tracing support and its advantages over DPRINTF(). Tracing is an alternative that solves limitations of the DPRINTF() approach: 1. DPRINTF() requires editing a specific source file and recompiling. While fine for the original author during development, DPRINTF() are not available to users hitting issues in production. I have not seen any bug report threads where users are urged to recompile with a DPRINTF() enabled. That's because it just isn't practical and we're losing out on a great source of debug information. With tracing it is now possible for distros to ship with SystemTap support (although LTTng Userspace Tracer and a portable built-in tracer are also supported). I hope we'll soon be able to take advantage of this to get detailed information from users experiencing bugs. Let's start adding useful trace events now so we can ask users to report detailed information in the future. 2. DPRINTF() is file-wide and not selectively filtered. DPRINTF() can only be enabled/disabled for an entire source file at compile time. This leads to noisy outputs that need to be post-filtered for the specific DPRINTF() you were looking for. Trace events can be enabled on a per-event basis. They can be toggled at run-time without recompiling. Less noise and less recompiling makes debugging easier. 3. DPRINTF() duplicates code. People have recently pointed out that the number of copy-pasted DPRINTF() definitions are ridiculous. Tracing allows you to focus on defining and calling specific events without the boilerplate. Add one line to the trace-events file and call it from your source file, that's it. You don't need to know LTTng UST or SystemTap/DTrace. For more information on tracing: http://git.qemu.org/qemu.git/plain/docs/tracing.txt See all existing trace events today: http://git.qemu.org/qemu.git/plain/trace-events Fully agree and I'd also add: 4. DPRINTF() is slow. Tracing moves formatting of data outside of QEMU execution phase to post processing phase. The overhead of buffering and batch writing of unformatted binary data is much lower.
[Qemu-devel] [Bug 671831] Re: Sparc guest assert error
Found out how to change the bug's status. I've marked it as fixed. Thanks again. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/671831 Title: Sparc guest assert error Status in QEMU: Fix Released Bug description: The latest version in git (d33ea50a958b2e050d2b28e5f17e3b55e91c6d74) crashes with an assert error when booting a Sparc/Linux guest. The last time I tried it (about a week ago) it worked fine. Yesterdai, I did a git pull, make clean, reran configure and compiled. Host OS: Debian Linux/x86_64 5.0 C Compiler: 4.4.5 Guest OS: Linux/Sparc (2.4) Command Line: qemu-system-sparc -hda ~njh/qemu/sparc/debian.img -nographic -m 128 Build Configure: ./configure --enable-linux-aio --enable-io-thread --enable-kvm GIT commit: d33ea50a958b2e050d2b28e5f17e3b55e91c6d74 Output: Adding Swap: 122532k swap-space (priority -1) . Will now check root file system:fsck 1.40-WIP (14-Nov-2006) [/sbin/fsck.ext3 (1) -- /] fsck.ext3 -a -C0 /dev/sda2 qemu-system-sparc: /home/njh/src/qemu/hw/scsi-disk.c:201: scsi_read_data: Assertion `r-req.aiocb == ((void *)0)' failed. It crashes in the same place every time. (gdb) thread apply all bt: Thread 3 (Thread 17643): #0 0x7f4db21bc8d3 in select () at ../sysdeps/unix/syscall-template.S:82 #1 0x004d02c4 in main_loop_wait (nonblocking=value optimized out) at /home/njh/src/qemu/vl.c:1246 #2 0x004d0e57 in main_loop (argc=value optimized out, argv=value optimized out, envp=value optimized out) at /home/njh/src/qemu/vl.c:1309 #3 main (argc=value optimized out, argv=value optimized out, envp=value optimized out) at /home/njh/src/qemu/vl.c:2999 Thread 2 (Thread 17645): #0 pthread_cond_timedwait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:211 #1 0x0042450b in cond_timedwait (unused=value optimized out) at posix-aio-compat.c:104 #2 aio_thread (unused=value optimized out) at posix-aio-compat.c:325 #3 0x7f4db3b818ba in start_thread (arg=value optimized out) at pthread_create.c:300 #4 0x7f4db21c302d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112 #5 0x in ?? () Current language: auto The current source language is auto; currently asm. Thread 1 (Thread 17644): #0 0x7f4db2126165 in *__GI_raise (sig=value optimized out) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 #1 0x7f4db2128f70 in *__GI_abort () at abort.c:92 #2 0x7f4db211f2b1 in *__GI___assert_fail ( assertion=0x52690a r-req.aiocb == ((void *)0), file=value optimized out, line=201, function=0x527480 scsi_read_data) at assert.c:81 #3 0x0044f363 in scsi_read_data (d=value optimized out, tag=0) at /home/njh/src/qemu/hw/scsi-disk.c:201 #4 0x004ebd6c in esp_do_dma (s=0x20679d0) at /home/njh/src/qemu/hw/esp.c:377 #5 0x004ec781 in handle_ti (opaque=0x20679d0, addr=value optimized out, val=value optimized out) at /home/njh/src/qemu/hw/esp.c:443 #6 esp_mem_writeb (opaque=0x20679d0, addr=value optimized out, val=value optimized out) at /home/njh/src/qemu/hw/esp.c:595 #7 0x41b2d971 in ?? () #8 0x in ?? () #9 0x031ad000 in ?? () #10 0x000301adfa20 in ?? () #11 0x1007 in ?? () #12 0x7f4daf80e8a0 in ?? () #13 0x0001 in ?? () #14 0x in ?? ()
[Qemu-devel] [Bug 671831] Re: Sparc guest assert error
It's been fixed now, thanks. There seems to be no way to close this bug, but you can assume, now, that it is closed. Thanks for your help in tracking it down and fixing it quickly. ** Changed in: qemu Status: In Progress = Fix Released -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/671831 Title: Sparc guest assert error Status in QEMU: Fix Released Bug description: The latest version in git (d33ea50a958b2e050d2b28e5f17e3b55e91c6d74) crashes with an assert error when booting a Sparc/Linux guest. The last time I tried it (about a week ago) it worked fine. Yesterdai, I did a git pull, make clean, reran configure and compiled. Host OS: Debian Linux/x86_64 5.0 C Compiler: 4.4.5 Guest OS: Linux/Sparc (2.4) Command Line: qemu-system-sparc -hda ~njh/qemu/sparc/debian.img -nographic -m 128 Build Configure: ./configure --enable-linux-aio --enable-io-thread --enable-kvm GIT commit: d33ea50a958b2e050d2b28e5f17e3b55e91c6d74 Output: Adding Swap: 122532k swap-space (priority -1) . Will now check root file system:fsck 1.40-WIP (14-Nov-2006) [/sbin/fsck.ext3 (1) -- /] fsck.ext3 -a -C0 /dev/sda2 qemu-system-sparc: /home/njh/src/qemu/hw/scsi-disk.c:201: scsi_read_data: Assertion `r-req.aiocb == ((void *)0)' failed. It crashes in the same place every time. (gdb) thread apply all bt: Thread 3 (Thread 17643): #0 0x7f4db21bc8d3 in select () at ../sysdeps/unix/syscall-template.S:82 #1 0x004d02c4 in main_loop_wait (nonblocking=value optimized out) at /home/njh/src/qemu/vl.c:1246 #2 0x004d0e57 in main_loop (argc=value optimized out, argv=value optimized out, envp=value optimized out) at /home/njh/src/qemu/vl.c:1309 #3 main (argc=value optimized out, argv=value optimized out, envp=value optimized out) at /home/njh/src/qemu/vl.c:2999 Thread 2 (Thread 17645): #0 pthread_cond_timedwait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:211 #1 0x0042450b in cond_timedwait (unused=value optimized out) at posix-aio-compat.c:104 #2 aio_thread (unused=value optimized out) at posix-aio-compat.c:325 #3 0x7f4db3b818ba in start_thread (arg=value optimized out) at pthread_create.c:300 #4 0x7f4db21c302d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112 #5 0x in ?? () Current language: auto The current source language is auto; currently asm. Thread 1 (Thread 17644): #0 0x7f4db2126165 in *__GI_raise (sig=value optimized out) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 #1 0x7f4db2128f70 in *__GI_abort () at abort.c:92 #2 0x7f4db211f2b1 in *__GI___assert_fail ( assertion=0x52690a r-req.aiocb == ((void *)0), file=value optimized out, line=201, function=0x527480 scsi_read_data) at assert.c:81 #3 0x0044f363 in scsi_read_data (d=value optimized out, tag=0) at /home/njh/src/qemu/hw/scsi-disk.c:201 #4 0x004ebd6c in esp_do_dma (s=0x20679d0) at /home/njh/src/qemu/hw/esp.c:377 #5 0x004ec781 in handle_ti (opaque=0x20679d0, addr=value optimized out, val=value optimized out) at /home/njh/src/qemu/hw/esp.c:443 #6 esp_mem_writeb (opaque=0x20679d0, addr=value optimized out, val=value optimized out) at /home/njh/src/qemu/hw/esp.c:595 #7 0x41b2d971 in ?? () #8 0x in ?? () #9 0x031ad000 in ?? () #10 0x000301adfa20 in ?? () #11 0x1007 in ?? () #12 0x7f4daf80e8a0 in ?? () #13 0x0001 in ?? () #14 0x in ?? ()
RE: [Qemu-devel] TCG flow vs dyngen
-Original Message- From: Blue Swirl [mailto:blauwir...@gmail.com] Sent: sabato 11 dicembre 2010 14:12 To: Stefano Bonifazi Cc: qemu-devel@nongnu.org Subject: Re: [Qemu-devel] TCG flow vs dyngen There's a large buffer for generated code, allocated in exec.c. This is filled with host code by TCG, when full it is flushed. The CPU execution loop generates new TBs when needed, otherwise the old code can be executed. TCG also uses intermediate ops but those are used only once during translation. So if I understand well the flow is the following: 1) the CPU execution loop at runtime takes a new TB from the target code 2) I guess some hash function is computed on this TB for getting a key for searching into the buffer of generated code that probably should store the binary as a map key-binary 3) if the search is successful the binary is given to the translator(how? You said no copy involved) and we return to point 1) otherwise: 4) the target specific translator generates TCG uops from the TB 5) TCG uses uops for generating host binary code 6) this new binary code is cached by TGC if there is enough storage place Is that all correct? Where does the execution of host binary take place in the previous list of events? Between point 5) and 6) ? After 6) ? In what QEMU source code file/function does the final execution of host binary take place? In the previous list of events, when does the translator try to chain the current TB with previous ones? Before TCG generates the binary in order to feed it with linked micro code? Thank you very very much! :) Stefano B.
[Qemu-devel] RE: [PATCH] fix qruncom compilation problems
-Original Message- From: Paolo Bonzini [mailto:pbonz...@redhat.com] Sent: venerdì 10 dicembre 2010 22:49 To: Stefano Bonifazi Subject: Re: [PATCH] fix qruncom compilation problems For runcom (without the q) this wouldn't work, because it runs the code in vm86 mode. It's possible that this is ok for qruncom with other changes to let the TCG backend know about vm86_mem. So informing the interpreter with page_set_flags(0x+vm86_mem, 0x11+vm86_mem, PAGE_WRITE | PAGE_READ | PAGE_EXEC | PAGE_VALID); Would be not enough? I was looking at this in my free time and it seriously shrunk later, so I'm afraid I cannot help. Surely I do understand you! Your help has been very very useful and appreciated already thank you! May you direct me to somebody who's working on it? Some TCG guru who could understand immediately what's wrong? :) I noticed, far now, that each question on this mailing list is answered only by one QEMU developer, is that a sort of policy or just a coincidence? Again thank you! Best regards! Stefano B.
Re: [Qemu-devel] TCG flow vs dyngen
On Sat, Dec 11, 2010 at 2:32 PM, Stefano Bonifazi stefboombas...@gmail.com wrote: -Original Message- From: Blue Swirl [mailto:blauwir...@gmail.com] Sent: sabato 11 dicembre 2010 14:12 To: Stefano Bonifazi Cc: qemu-devel@nongnu.org Subject: Re: [Qemu-devel] TCG flow vs dyngen There's a large buffer for generated code, allocated in exec.c. This is filled with host code by TCG, when full it is flushed. The CPU execution loop generates new TBs when needed, otherwise the old code can be executed. TCG also uses intermediate ops but those are used only once during translation. So if I understand well the flow is the following: 1) the CPU execution loop at runtime takes a new TB from the target code 2) I guess some hash function is computed on this TB for getting a key for searching into the buffer of generated code that probably should store the binary as a map key-binary 3) if the search is successful the binary is given to the translator(how? You said no copy involved) and we return to point 1) otherwise: 1-3) Please see tb_find_fast() and its caller in cpu-exec.c. Only pointer passing is involved. 4) the target specific translator generates TCG uops from the TB 5) TCG uses uops for generating host binary code 6) this new binary code is cached by TGC if there is enough storage place Is that all correct? 4-5) OK. 6) If there is no space, all previously generated code is thrown away. Where does the execution of host binary take place in the previous list of events? Between point 5) and 6) ? After 6) ? In what QEMU source code file/function does the final execution of host binary take place? In the previous list of events, when does the translator try to chain the current TB with previous ones? Before TCG generates the binary in order to feed it with linked micro code? All of this happens in cpu-exec.c:581 to 618.
[Qemu-devel] Re: [PATCHv8 00/16] boot order specification
On Wed, Dec 8, 2010 at 11:34 AM, Gleb Natapov g...@redhat.com wrote:
Forget to save a couple of buffers before sending version 7 :(
Anthony, Blue can this be applied now?
I made some more tests, this time with PPC. I modified OpenBIOS to
print out the boot device list:
$ qemu-system-ppc -drive if=none,id=hda,file=/dev/null -device
ide-drive,drive=hda,bootindex=1 -drive if=none,id=cd,file=/dev/null
-device ide-drive,drive=cd,bootindex=0 -nographic -prom-env
'auto-boot?=false' -L .
qemu-system-ppc: pci_add_option_rom: failed to find romfile vgabios-stdvga.bin
Could not open option rom 'pxe-ne2k_pci.bin': No such file or directory
=
OpenBIOS 1.0 [Nov 28 2010 19:37]
Configuration device id QEMU version 1 machine id 2
CPUs: 1
Memory: 128M
UUID: ----
CPU type PowerPC,750
bootindex /grac...@fec0/i...@3/dr...@1/d...@1
/grac...@fec0/i...@3/dr...@1/d...@0
Welcome to OpenBIOS v1.0 built on Nov 28 2010 19:37
0 show-devs
7be6324 /
7be6440 /aliases
7be64e4 /openprom (BootROM)
7bebfa0 /openprom/client-services
7be668c /options
7be6704 /chosen
7be67e8 /builtin
7be688c /builtin/console
7bebcac /packages
7becda8 /packages/cmdline
7becee8 /packages/disk-label
7bedb58 /packages/terminal-emulator
7bee548 /packages/deblocker
7bee89c /packages/hfsplus-files
7beeb3c /packages/hfs-files
7beedd8 /packages/ext2-files
7bef010 /packages/iso9660-files
7bef248 /packages/grubfs-files
7bef480 /packages/mac-parts
7bef6b8 /packages/pc-parts
7bef8ec /packages/xcoff-loader
7bef9b8 /packages/elf-loader
7befa80 /packages/bootinfo-loader
7bed958 /cpus
7bf2fe8 /cpus/PowerPC,7...@0 (cpu)
7beda58 /mem...@0 (memory)
7befb4c /p...@8000 (pci)
7beff64 /p...@8000/QEMU,v...@1 (display)
7bf0438 /p...@8000/ne2...@2 (network)
7bf0814 /p...@8000/pci-...@3 (pci-ide)
7bf0c50 /p...@8000/pci-...@3/at...@500 (ata)
7bf0dd0 /p...@8000/pci-...@3/at...@600 (ata)
7bf0f50 /p...@8000/pci-...@3/at...@600/d...@1 (block)
7bf131c /p...@8000/pci-...@3/at...@600/d...@0 (block)
7bf1674 /p...@8000/mac...@4 (mac-io)
7bf1b54 /p...@8000/mac...@4/via-c...@16000 (via-cuda)
7bf1d70 /p...@8000/mac...@4/via-c...@16000/adb (adb)
7bf1ed8 /p...@8000/mac...@4/via-c...@16000/adb/keybo...@8 (keyboard)
7bf2080 /p...@8000/mac...@4/via-c...@16000/adb/mo...@9 (mouse)
7bf220c /p...@8000/mac...@4/via-c...@16000/rtc (rtc)
7bf23f4 /p...@8000/mac...@4/nv...@6 (nvram)
7bf2614 /p...@8000/mac...@4/e...@13000 (escc)
7bf271c /p...@8000/mac...@4/e...@13000/c...@13020 (serial)
7bf29b4 /p...@8000/mac...@4/e...@13000/c...@13000 (serial)
7bf2c20 /p...@8000/mac...@4/at...@2 (ata)
ok
/grac...@fec0/i...@3/dr...@1/d...@1 does not match
/p...@8000/pci-...@3/at...@600/d...@1.
I wonder where '@8000' comes from. A dump of original g3beige
device tree is here:
http://penguinppc.org/historical/dev-trees-html/g3_beige_300.html
But actually the tree generated by OpenBIOS looks more like g3bw one:
http://penguinppc.org/historical/dev-trees-html/g3bw_400.html
How can we get the names to be more compatible? At least
s/grackle/pci/ is easy to do in QEMU, but which instance (QEMU or
OpenBIOS) should handle pci-ata vs ide change? What should we do with
at...@600 vs dr...@1?
From 640a93145fd830b225b5f9865a9cfe6e32b9bf66 Mon Sep 17 00:00:00 2001
From: Blue Swirl blauwirbel@gmail.com
Date: Sat, 11 Dec 2010 14:48:53 +
Subject: [PATCH] Use bootindex
Signed-off-by: Blue Swirl blauwirbel@gmail.com
---
arch/ppc/qemu/init.c| 30 ++
arch/sparc32/openbios.c | 31 +++
2 files changed, 61 insertions(+), 0 deletions(-)
diff --git a/arch/ppc/qemu/init.c b/arch/ppc/qemu/init.c
index 5118eb1..1cadcf0 100644
--- a/arch/ppc/qemu/init.c
+++ b/arch/ppc/qemu/init.c
@@ -601,6 +601,34 @@ static void kvm_of_init(void)
fword(finish-device);
}
+typedef struct FWCfgFile {
+uint32_t size;
+uint16_t select;
+uint16_t reserved;
+char name[56];
+} FWCfgFile;
+
+static void check_fw_cfg_bootindex(void)
+{
+char *dir, *bootindex;
+int dirlen, dirsize, i;
+FWCfgFile *file;
+
+dirlen = __le32_to_cpu(fw_cfg_read_i32(FW_CFG_FILE_DIR));
+dirsize = sizeof(uint32_t) + sizeof(FWCfgFile) * dirlen;
+dir = malloc(dirsize);
+fw_cfg_read(FW_CFG_FILE_DIR, dir, dirsize);
+
+for (i = 0; i dirlen; i++) {
+file = (FWCfgFile *)dir[i + sizeof(uint32_t)];
+if (file-size !strcmp(file-name, bootorder)) {
+bootindex = malloc(file-size);
+fw_cfg_read(file-select, bootindex, file-size);
+printk(bootindex %s\n, bootindex);
+}
+}
+}
+
void
arch_of_init(void)
{
@@ -807,6 +835,8 @@ arch_of_init(void)
push_str(/options);
fword(find-device);
+check_fw_cfg_bootindex();
+
uint16_t boot_device = fw_cfg_read_i16(FW_CFG_BOOT_DEVICE);
switch (boot_device) {
Re: [Qemu-devel] [PATCH 0/6] usb-ccid (v8)
Hi, On 12/11/2010 10:43 AM, Blue Swirl wrote: On Tue, Dec 7, 2010 at 10:20 AM, Alon Levyal...@redhat.com wrote: ping. I don't think Anthony's concerns (or mine) have been addressed. Could you be a bit more verbose please ? Thanks Regards, Hans
[Qemu-devel] Re: [PATCHv8 00/16] boot order specification
On Sat, Dec 11, 2010 at 03:13:35PM +, Blue Swirl wrote: On Wed, Dec 8, 2010 at 11:34 AM, Gleb Natapov g...@redhat.com wrote: Forget to save a couple of buffers before sending version 7 :( Anthony, Blue can this be applied now? I made some more tests, this time with PPC. I modified OpenBIOS to print out the boot device list: $ qemu-system-ppc -drive if=none,id=hda,file=/dev/null -device ide-drive,drive=hda,bootindex=1 -drive if=none,id=cd,file=/dev/null -device ide-drive,drive=cd,bootindex=0 -nographic -prom-env 'auto-boot?=false' -L . qemu-system-ppc: pci_add_option_rom: failed to find romfile vgabios-stdvga.bin Could not open option rom 'pxe-ne2k_pci.bin': No such file or directory = OpenBIOS 1.0 [Nov 28 2010 19:37] Configuration device id QEMU version 1 machine id 2 CPUs: 1 Memory: 128M UUID: ---- CPU type PowerPC,750 bootindex /grac...@fec0/i...@3/dr...@1/d...@1 /grac...@fec0/i...@3/dr...@1/d...@0 Welcome to OpenBIOS v1.0 built on Nov 28 2010 19:37 0 show-devs 7be6324 / 7be6440 /aliases 7be64e4 /openprom (BootROM) 7bebfa0 /openprom/client-services 7be668c /options 7be6704 /chosen 7be67e8 /builtin 7be688c /builtin/console 7bebcac /packages 7becda8 /packages/cmdline 7becee8 /packages/disk-label 7bedb58 /packages/terminal-emulator 7bee548 /packages/deblocker 7bee89c /packages/hfsplus-files 7beeb3c /packages/hfs-files 7beedd8 /packages/ext2-files 7bef010 /packages/iso9660-files 7bef248 /packages/grubfs-files 7bef480 /packages/mac-parts 7bef6b8 /packages/pc-parts 7bef8ec /packages/xcoff-loader 7bef9b8 /packages/elf-loader 7befa80 /packages/bootinfo-loader 7bed958 /cpus 7bf2fe8 /cpus/PowerPC,7...@0 (cpu) 7beda58 /mem...@0 (memory) 7befb4c /p...@8000 (pci) 7beff64 /p...@8000/QEMU,v...@1 (display) 7bf0438 /p...@8000/ne2...@2 (network) 7bf0814 /p...@8000/pci-...@3 (pci-ide) 7bf0c50 /p...@8000/pci-...@3/at...@500 (ata) 7bf0dd0 /p...@8000/pci-...@3/at...@600 (ata) 7bf0f50 /p...@8000/pci-...@3/at...@600/d...@1 (block) 7bf131c /p...@8000/pci-...@3/at...@600/d...@0 (block) 7bf1674 /p...@8000/mac...@4 (mac-io) 7bf1b54 /p...@8000/mac...@4/via-c...@16000 (via-cuda) 7bf1d70 /p...@8000/mac...@4/via-c...@16000/adb (adb) 7bf1ed8 /p...@8000/mac...@4/via-c...@16000/adb/keybo...@8 (keyboard) 7bf2080 /p...@8000/mac...@4/via-c...@16000/adb/mo...@9 (mouse) 7bf220c /p...@8000/mac...@4/via-c...@16000/rtc (rtc) 7bf23f4 /p...@8000/mac...@4/nv...@6 (nvram) 7bf2614 /p...@8000/mac...@4/e...@13000 (escc) 7bf271c /p...@8000/mac...@4/e...@13000/c...@13020 (serial) 7bf29b4 /p...@8000/mac...@4/e...@13000/c...@13000 (serial) 7bf2c20 /p...@8000/mac...@4/at...@2 (ata) ok /grac...@fec0/i...@3/dr...@1/d...@1 does not match /p...@8000/pci-...@3/at...@600/d...@1. hw/ppc_oldworld.c has: pci_bus = pci_grackle_init(0xfec0, pic); i.e it registers pci controller at MMIO address 0xfec0. 0x8000 is isa mmio base. Why OpenBIOS uses 8000 as address of pci controller? May be on real HW all memory access above 0x8000 is redirected to pci controller and it emulates isa? Then we should fix qemu to do the same. I wonder where '@8000' comes from. A dump of original g3beige device tree is here: http://penguinppc.org/historical/dev-trees-html/g3_beige_300.html But actually the tree generated by OpenBIOS looks more like g3bw one: http://penguinppc.org/historical/dev-trees-html/g3bw_400.html How can we get the names to be more compatible? At least s/grackle/pci/ is easy to do in QEMU, but which instance (QEMU or OpenBIOS) should handle pci-ata vs ide change? http://playground.sun.com/pub/p1275/bindings/pci/pci2_1.pdf has table on page 10 that defines how pci class code should be translated into OF name. This is what my patch is using. pci-ata does not look spec compliant (or is there more up-to-date spec?) What should we do with at...@600 vs dr...@1? There is no available IDE OF binding spec, so I when with the way OpenBIOS reports ata on qemu-x86. I have no idea what 600 in at...@600 may mean, but looking at g3_beige_300.html there is no such node there and looking at any other device tree in http://penguinppc.org/historical/dev-trees-html/ I haven't found one that use this kind of addressing for pci-ata. http://penguinppc.org/historical/dev-trees-html/g3bw_400.html for instance has p...@8000/pci-bri...@d/pci-...@1/ata-4. at...@600 kind of addressing is used by devices on mac-io bus which I do not think we emulate in qemu. So it looks like OpneBIOS is wrong here. -- Gleb.
[Qemu-devel] Re: [PATCHv8 00/16] boot order specification
On Sat, Dec 11, 2010 at 4:06 PM, Gleb Natapov g...@redhat.com wrote: On Sat, Dec 11, 2010 at 03:13:35PM +, Blue Swirl wrote: On Wed, Dec 8, 2010 at 11:34 AM, Gleb Natapov g...@redhat.com wrote: Forget to save a couple of buffers before sending version 7 :( Anthony, Blue can this be applied now? I made some more tests, this time with PPC. I modified OpenBIOS to print out the boot device list: $ qemu-system-ppc -drive if=none,id=hda,file=/dev/null -device ide-drive,drive=hda,bootindex=1 -drive if=none,id=cd,file=/dev/null -device ide-drive,drive=cd,bootindex=0 -nographic -prom-env 'auto-boot?=false' -L . qemu-system-ppc: pci_add_option_rom: failed to find romfile vgabios-stdvga.bin Could not open option rom 'pxe-ne2k_pci.bin': No such file or directory = OpenBIOS 1.0 [Nov 28 2010 19:37] Configuration device id QEMU version 1 machine id 2 CPUs: 1 Memory: 128M UUID: ---- CPU type PowerPC,750 bootindex /grac...@fec0/i...@3/dr...@1/d...@1 /grac...@fec0/i...@3/dr...@1/d...@0 Welcome to OpenBIOS v1.0 built on Nov 28 2010 19:37 0 show-devs 7be6324 / 7be6440 /aliases 7be64e4 /openprom (BootROM) 7bebfa0 /openprom/client-services 7be668c /options 7be6704 /chosen 7be67e8 /builtin 7be688c /builtin/console 7bebcac /packages 7becda8 /packages/cmdline 7becee8 /packages/disk-label 7bedb58 /packages/terminal-emulator 7bee548 /packages/deblocker 7bee89c /packages/hfsplus-files 7beeb3c /packages/hfs-files 7beedd8 /packages/ext2-files 7bef010 /packages/iso9660-files 7bef248 /packages/grubfs-files 7bef480 /packages/mac-parts 7bef6b8 /packages/pc-parts 7bef8ec /packages/xcoff-loader 7bef9b8 /packages/elf-loader 7befa80 /packages/bootinfo-loader 7bed958 /cpus 7bf2fe8 /cpus/PowerPC,7...@0 (cpu) 7beda58 /mem...@0 (memory) 7befb4c /p...@8000 (pci) 7beff64 /p...@8000/QEMU,v...@1 (display) 7bf0438 /p...@8000/ne2...@2 (network) 7bf0814 /p...@8000/pci-...@3 (pci-ide) 7bf0c50 /p...@8000/pci-...@3/at...@500 (ata) 7bf0dd0 /p...@8000/pci-...@3/at...@600 (ata) 7bf0f50 /p...@8000/pci-...@3/at...@600/d...@1 (block) 7bf131c /p...@8000/pci-...@3/at...@600/d...@0 (block) 7bf1674 /p...@8000/mac...@4 (mac-io) 7bf1b54 /p...@8000/mac...@4/via-c...@16000 (via-cuda) 7bf1d70 /p...@8000/mac...@4/via-c...@16000/adb (adb) 7bf1ed8 /p...@8000/mac...@4/via-c...@16000/adb/keybo...@8 (keyboard) 7bf2080 /p...@8000/mac...@4/via-c...@16000/adb/mo...@9 (mouse) 7bf220c /p...@8000/mac...@4/via-c...@16000/rtc (rtc) 7bf23f4 /p...@8000/mac...@4/nv...@6 (nvram) 7bf2614 /p...@8000/mac...@4/e...@13000 (escc) 7bf271c /p...@8000/mac...@4/e...@13000/c...@13020 (serial) 7bf29b4 /p...@8000/mac...@4/e...@13000/c...@13000 (serial) 7bf2c20 /p...@8000/mac...@4/at...@2 (ata) ok /grac...@fec0/i...@3/dr...@1/d...@1 does not match /p...@8000/pci-...@3/at...@600/d...@1. hw/ppc_oldworld.c has: pci_bus = pci_grackle_init(0xfec0, pic); i.e it registers pci controller at MMIO address 0xfec0. 0x8000 is isa mmio base. Why OpenBIOS uses 8000 as address of pci controller? May be on real HW all memory access above 0x8000 is redirected to pci controller and it emulates isa? Then we should fix qemu to do the same. I wonder where '@8000' comes from. A dump of original g3beige device tree is here: http://penguinppc.org/historical/dev-trees-html/g3_beige_300.html But actually the tree generated by OpenBIOS looks more like g3bw one: http://penguinppc.org/historical/dev-trees-html/g3bw_400.html How can we get the names to be more compatible? At least s/grackle/pci/ is easy to do in QEMU, but which instance (QEMU or OpenBIOS) should handle pci-ata vs ide change? http://playground.sun.com/pub/p1275/bindings/pci/pci2_1.pdf has table on page 10 that defines how pci class code should be translated into OF name. This is what my patch is using. pci-ata does not look spec compliant (or is there more up-to-date spec?) There could be a FCode Program which sets the name. What should we do with at...@600 vs dr...@1? There is no available IDE OF binding spec, so I when with the way OpenBIOS reports ata on qemu-x86. I have no idea what 600 in at...@600 may mean, but looking at g3_beige_300.html there is no such node there and looking at any other device tree in http://penguinppc.org/historical/dev-trees-html/ I haven't found one that use this kind of addressing for pci-ata. http://penguinppc.org/historical/dev-trees-html/g3bw_400.html for instance has p...@8000/pci-bri...@d/pci-...@1/ata-4. at...@600 kind of addressing is used by devices on mac-io bus which I do not think we emulate in qemu. So it looks like OpneBIOS is wrong here. We have PMAC IDE, but this device is CMD646, so mac-io bus addressing rules should not be
[Qemu-devel] Re: [PATCHv8 00/16] boot order specification
On Sat, Dec 11, 2010 at 05:19:01PM +, Blue Swirl wrote: What should we do with at...@600 vs dr...@1? There is no available IDE OF binding spec, so I when with the way OpenBIOS reports ata on qemu-x86. I have no idea what 600 in at...@600 may mean, but looking at g3_beige_300.html there is no such node there and looking at any other device tree in http://penguinppc.org/historical/dev-trees-html/ I haven't found one that use this kind of addressing for pci-ata. http://penguinppc.org/historical/dev-trees-html/g3bw_400.html for instance has p...@8000/pci-bri...@d/pci-...@1/ata-4. at...@600 kind of addressing is used by devices on mac-io bus which I do not think we emulate in qemu. So it looks like OpneBIOS is wrong here. We have PMAC IDE, but this device is CMD646, so mac-io bus addressing rules should not be used. So you agree that OpenBIOS is wrong here? In this tree there are two disks connected to CMD646, named /p...@8000/pci-bri...@d/pci-...@1/ata-4/disk and /p...@8000/pci-bri...@d/pci-...@1/ata-4/d...@1: http://penguinppc.org/historical/dev-trees-html/g4_pci_350.html You are saying that qemu creates paths like: /grac...@fec0/i...@3/dr...@1/d...@0 /grac...@fec0/i...@3/dr...@1/d...@1 I do not understand why qemu creates node dr...@1. It should be dr...@0 according to the code. I'll look at why unit-address is incorrect for the node. But assuming that this problem is fixed then paths created by qemu is very similar to the paths in g4_pci_350.html. It looks like in g4_pci_350.html they omit unit address if it is zero. -- Gleb.
[Qemu-devel] Re: [PATCH 00/15] MMIO endianness cleanup v2
Thanks, applied. On Wed, Dec 8, 2010 at 11:05 AM, Alexander Graf ag...@suse.de wrote: The way mmio endianness is currently implemented is horrifying. In the real world, CPUs have an endianness and write out data to the memory bus. Instead of RAM, a receiving side here can be a device. This device gets a byte stream again and needs to make sense of it. Since big endian systems write big endian numbers into memory while little endian systems write little endian numbers there, the device and software on the CPU need to be aware of this. In practice, most devices these days (ISA, PCI) assume that the data is little endian. So to communicate with such a device from the CPU's side, the OS byte swaps all MMIO. In qemu however, we simply pass the register value we find on to the device. So any byte mangling the guest does to compensate for the transfer screw us up by exposing byte swapped MMIO on the device's side. The way this has been fixed historically is by constructs like this one: #ifdef TARGET_WORDS_BIGENDIAN val = bswap32(val); #endif With the move to get device code only compiled once, this has become harder and harder to justify though, since we don't know the target endianness during compile time. It's especially bad since it doesn't make any sense at all to clutter all the device code with endianness workarounds, aside from the fact that about 80% of the device code currently does the wrong thing :). So my solution to the issue is to make every device define if it's a little, big or native (target) endianness device. This basically tells the layers below what endianness the device expects mmio to occur in. Little endian devices on little endian hosts don't swap. On big endian hosts they do. Same the other way around. The only reason I added native endianness is that we have some PV devices like the fw_cfg that expect qemu's broken behavior. These devices are the minority though. In the long run I'd expect to see most code be committed with either of the two endianness choices. The patch set also includes a bunch of conversions for devices that were already aware of endianness. For easy testing or pulling, please use this repo: git://repo.or.cz/qemu/agraf.git qemu-endian-fix-v2 v0-v1: - make LE targets compile - add one missing conversion - make endian choice be an enum v1 - v2: - rebase (this thing bitrots _fast_!) Alexander Graf (15): exec: introduce endianness swapped mmio Add endianness as io mem parameter Make simple io mem handler endian aware dbdma: Make little endian pci-host: Delegate bswap to mmio layer uninorth: Get rid of bswap e1000: Make little endian prep: Declare as little endian versatile_pci: Declare as little endian ppc4xx_pci: Declare as little endian openpic: Replace explicit byte swap with endian hints rtl8139: Declare as little endian heathrow_pic: Declare as little endian isa_mmio: Always use little endian usb_ohci: Always use little endian Makefile.objs | 3 + Makefile.target | 7 -- cpu-common.h | 8 ++- exec.c | 142 +--- hw/apb_pci.c | 9 ++- hw/apic.c | 3 +- hw/arm_gic.c | 3 +- hw/arm_sysctl.c | 3 +- hw/arm_timer.c | 5 +- hw/armv7m.c | 2 +- hw/axis_dev88.c | 6 +- hw/bonito.c | 19 -- hw/cirrus_vga.c | 12 +++- hw/cs4231.c | 3 +- hw/cuda.c | 3 +- hw/dec_pci.c | 6 +- hw/dp8393x.c | 3 +- hw/ds1225y.c | 6 +- hw/e1000.c | 11 +--- hw/eccmemctl.c | 6 +- hw/eepro100.c | 3 +- hw/empty_slot.c | 3 +- hw/escc.c | 3 +- hw/esp.c | 3 +- hw/etraxfs_dma.c | 2 +- hw/etraxfs_eth.c | 3 +- hw/etraxfs_pic.c | 3 +- hw/etraxfs_ser.c | 3 +- hw/etraxfs_timer.c | 3 +- hw/fdc.c | 6 +- hw/fw_cfg.c | 6 +- hw/g364fb.c | 3 +- hw/grackle_pci.c | 6 +- hw/gt64xxx.c | 9 +-- hw/heathrow_pic.c | 5 +- hw/hpet.c | 3 +- hw/ide/macio.c | 3 +- hw/ide/mmio.c | 6 +- hw/integratorcp.c | 9 ++- hw/intel-hda.c | 3 +- hw/ioapic.c | 3 +- hw/isa.h | 2 +- hw/isa_mmio.c | 100 ++- hw/ivshmem.c | 2 +- hw/jazz_led.c | 3 +- hw/lan9118.c | 3 +- hw/lance.c | 3 +- hw/lsi53c895a.c | 6 +- hw/m48t59.c
Re: [Qemu-devel] Re: [PATCHv8 00/16] boot order specification
On Sat, Dec 11, 2010 at 08:02:23PM +0200, Gleb Natapov wrote: On Sat, Dec 11, 2010 at 05:19:01PM +, Blue Swirl wrote: What should we do with at...@600 vs dr...@1? There is no available IDE OF binding spec, so I when with the way OpenBIOS reports ata on qemu-x86. I have no idea what 600 in at...@600 may mean, but looking at g3_beige_300.html there is no such node there and looking at any other device tree in http://penguinppc.org/historical/dev-trees-html/ I haven't found one that use this kind of addressing for pci-ata. http://penguinppc.org/historical/dev-trees-html/g3bw_400.html for instance has p...@8000/pci-bri...@d/pci-...@1/ata-4. at...@600 kind of addressing is used by devices on mac-io bus which I do not think we emulate in qemu. So it looks like OpneBIOS is wrong here. We have PMAC IDE, but this device is CMD646, so mac-io bus addressing rules should not be used. So you agree that OpenBIOS is wrong here? In this tree there are two disks connected to CMD646, named /p...@8000/pci-bri...@d/pci-...@1/ata-4/disk and /p...@8000/pci-bri...@d/pci-...@1/ata-4/d...@1: http://penguinppc.org/historical/dev-trees-html/g4_pci_350.html You are saying that qemu creates paths like: /grac...@fec0/i...@3/dr...@1/d...@0 /grac...@fec0/i...@3/dr...@1/d...@1 I do not understand why qemu creates node dr...@1. It should be dr...@0 according to the code. I'll look at why unit-address is incorrect for the node. But assuming that this problem is fixed then paths created by qemu is very similar to the paths in g4_pci_350.html. It looks like in g4_pci_350.html they omit unit address if it is zero. Ah the problem is that we have not qdevified mac io bus. Since first to ide disks are automatically attached to mac-io bus device paths for them are incorrect. Next two ide devices will be attached to CMD646 and qemu will generate correct device paths for them: qemu-system-ppc -drive if=none,id=hda,file=/dev/null -device ide-drive,drive=hda,bootindex=1 -drive if=none,id=cd,file=/dev/null -device ide-drive,drive=cd,bootindex=0 -nographic -drive if=none,id=hdb,file=/dev/null -device ide-drive,drive=hdb,bus=ide.0,bootindex=2 -drive if=none,id=hdc,file=/dev/null -device ide-drive,drive=hdc,bus=ide.0,bootindex=3 adding '/grac...@fec0/i...@3/dr...@1/d...@1' at index 0 adding '/grac...@fec0/i...@3/dr...@1/d...@0' at index 1 adding '/grac...@fec0/i...@3/dr...@0/d...@0' at index 2 adding '/grac...@fec0/i...@3/dr...@0/d...@1' at index 3 So the fix is to qdevify mac io bus. -- Gleb.
Re: [Qemu-devel] [PATCH] isa-bus.c: use hw_error instead of fprintf
Thanks, applied.
On Fri, Dec 3, 2010 at 11:05 AM, Tristan Gingold ging...@adacore.com wrote:
Minor clean-up in isa-bus.c. Using hw_error is more consistent.
There is a difference however: hw_error dumps the cpu state.
Signed-off-by: Tristan Gingold ging...@adacore.com
---
hw/isa-bus.c | 11 ---
1 files changed, 4 insertions(+), 7 deletions(-)
diff --git a/hw/isa-bus.c b/hw/isa-bus.c
index 4e306de..3a6c961 100644
--- a/hw/isa-bus.c
+++ b/hw/isa-bus.c
@@ -68,12 +68,10 @@ void isa_bus_irqs(qemu_irq *irqs)
qemu_irq isa_reserve_irq(int isairq)
{
if (isairq 0 || isairq 15) {
- fprintf(stderr, isa irq %d invalid\n, isairq);
- exit(1);
+ hw_error(isa irq %d invalid, isairq);
}
if (isabus-assigned (1 isairq)) {
- fprintf(stderr, isa irq %d already assigned\n, isairq);
- exit(1);
+ hw_error(isa irq %d already assigned, isairq);
}
isabus-assigned |= (1 isairq);
return isabus-irqs[isairq];
@@ -83,8 +81,7 @@ void isa_init_irq(ISADevice *dev, qemu_irq *p, int isairq)
{
assert(dev-nirqs ARRAY_SIZE(dev-isairq));
if (isabus-assigned (1 isairq)) {
- fprintf(stderr, isa irq %d already assigned\n, isairq);
- exit(1);
+ hw_error(isa irq %d already assigned, isairq);
}
isabus-assigned |= (1 isairq);
dev-isairq[dev-nirqs] = isairq;
@@ -115,7 +112,7 @@ ISADevice *isa_create(const char *name)
DeviceState *dev;
if (!isabus) {
- hw_error(Tried to create isa device %s with no isa bus present.\n,
+ hw_error(Tried to create isa device %s with no isa bus present.,
name);
}
dev = qdev_create(isabus-qbus, name);
--
1.7.3.GIT
Re: [Qemu-devel] [PATCH] wdt_i6300esb: register a reset function
Thanks, applied.
On Wed, Dec 8, 2010 at 2:59 PM, Bernhard Kohl bernhard.k...@nsn.com wrote:
The device shall set its default hardware state after each reset.
This includes that the timer is stopped which is especially important
if the guest does a reboot independantly of a watchdog bite. I moved
the initialization of the state variables completely from the init
to the reset function which is called right after init during the
first boot and afterwards during each reboot.
Signed-off-by: Bernhard Kohl bernhard.k...@nsn.com
---
hw/wdt_i6300esb.c | 39 +--
1 files changed, 21 insertions(+), 18 deletions(-)
diff --git a/hw/wdt_i6300esb.c b/hw/wdt_i6300esb.c
index 46e1df8..2408710 100644
--- a/hw/wdt_i6300esb.c
+++ b/hw/wdt_i6300esb.c
@@ -140,14 +140,26 @@ static void i6300esb_disable_timer(I6300State *d)
qemu_del_timer(d-timer);
}
-static void i6300esb_reset(I6300State *d)
+static void i6300esb_reset(DeviceState *dev)
{
- /* XXX We should probably reset other parts of the state here,
- * but we should also reset our state on general machine reset
- * too. For now just disable the timer so it doesn't fire
- * again after the reboot.
- */
+ PCIDevice *pdev = DO_UPCAST(PCIDevice, qdev, dev);
+ I6300State *d = DO_UPCAST(I6300State, dev, pdev);
+
+ i6300esb_debug(I6300State = %p\n, d);
+
i6300esb_disable_timer(d);
+
+ d-reboot_enabled = 1;
+ d-clock_scale = CLOCK_SCALE_1KHZ;
+ d-int_type = INT_TYPE_IRQ;
+ d-free_run = 0;
+ d-locked = 0;
+ d-enabled = 0;
+ d-timer1_preload = 0xf;
+ d-timer2_preload = 0xf;
+ d-stage = 1;
+ d-unlock_state = 0;
+ d-previous_reboot_flag = 0;
}
/* This function is called when the watchdog expires. Note that
@@ -181,7 +193,6 @@ static void i6300esb_timer_expired(void *vp)
if (d-reboot_enabled) {
d-previous_reboot_flag = 1;
watchdog_perform_action(); /* This reboots, exits, etc */
- i6300esb_reset(d);
}
/* In free running mode we start stage 1 again. */
@@ -394,18 +405,9 @@ static int i6300esb_init(PCIDevice *dev)
I6300State *d = DO_UPCAST(I6300State, dev, dev);
uint8_t *pci_conf;
- d-reboot_enabled = 1;
- d-clock_scale = CLOCK_SCALE_1KHZ;
- d-int_type = INT_TYPE_IRQ;
- d-free_run = 0;
- d-locked = 0;
- d-enabled = 0;
+ i6300esb_debug(I6300State = %p\n, d);
+
d-timer = qemu_new_timer(vm_clock, i6300esb_timer_expired, d);
- d-timer1_preload = 0xf;
- d-timer2_preload = 0xf;
- d-stage = 1;
- d-unlock_state = 0;
- d-previous_reboot_flag = 0;
pci_conf = d-dev.config;
pci_config_set_vendor_id(pci_conf, PCI_VENDOR_ID_INTEL);
@@ -427,6 +429,7 @@ static PCIDeviceInfo i6300esb_info = {
.qdev.name = i6300esb,
.qdev.size = sizeof(I6300State),
.qdev.vmsd = vmstate_i6300esb,
+ .qdev.reset = i6300esb_reset,
.config_read = i6300esb_config_read,
.config_write = i6300esb_config_write,
.init = i6300esb_init,
--
1.7.2.3
Re: [Qemu-devel] Re: [PATCHv8 00/16] boot order specification
On Sat, Dec 11, 2010 at 07:06:04PM +, Blue Swirl wrote: 2010/12/11 Gleb Natapov g...@redhat.com: On Sat, Dec 11, 2010 at 08:02:23PM +0200, Gleb Natapov wrote: On Sat, Dec 11, 2010 at 05:19:01PM +, Blue Swirl wrote: What should we do with at...@600 vs dr...@1? There is no available IDE OF binding spec, so I when with the way OpenBIOS reports ata on qemu-x86. I have no idea what 600 in at...@600 may mean, but looking at g3_beige_300.html there is no such node there and looking at any other device tree in http://penguinppc.org/historical/dev-trees-html/ I haven't found one that use this kind of addressing for pci-ata. http://penguinppc.org/historical/dev-trees-html/g3bw_400.html for instance has p...@8000/pci-bri...@d/pci-...@1/ata-4. at...@600 kind of addressing is used by devices on mac-io bus which I do not think we emulate in qemu. So it looks like OpneBIOS is wrong here. We have PMAC IDE, but this device is CMD646, so mac-io bus addressing rules should not be used. So you agree that OpenBIOS is wrong here? In this tree there are two disks connected to CMD646, named /p...@8000/pci-bri...@d/pci-...@1/ata-4/disk and /p...@8000/pci-bri...@d/pci-...@1/ata-4/d...@1: http://penguinppc.org/historical/dev-trees-html/g4_pci_350.html You are saying that qemu creates paths like: /grac...@fec0/i...@3/dr...@1/d...@0 /grac...@fec0/i...@3/dr...@1/d...@1 I do not understand why qemu creates node dr...@1. It should be dr...@0 according to the code. I'll look at why unit-address is incorrect for the node. But assuming that this problem is fixed then paths created by qemu is very similar to the paths in g4_pci_350.html. It looks like in g4_pci_350.html they omit unit address if it is zero. Ah the problem is that we have not qdevified mac io bus. Since first to ide disks are automatically attached to mac-io bus device paths for them are incorrect. Next two ide devices will be attached to CMD646 and qemu will generate correct device paths for them: qemu-system-ppc -drive if=none,id=hda,file=/dev/null -device ide-drive,drive=hda,bootindex=1 -drive if=none,id=cd,file=/dev/null -device ide-drive,drive=cd,bootindex=0 -nographic -drive if=none,id=hdb,file=/dev/null -device ide-drive,drive=hdb,bus=ide.0,bootindex=2 -drive if=none,id=hdc,file=/dev/null -device ide-drive,drive=hdc,bus=ide.0,bootindex=3 adding '/grac...@fec0/i...@3/dr...@1/d...@1' at index 0 adding '/grac...@fec0/i...@3/dr...@1/d...@0' at index 1 adding '/grac...@fec0/i...@3/dr...@0/d...@0' at index 2 adding '/grac...@fec0/i...@3/dr...@0/d...@1' at index 3 But why is the path almost the same as CMD646, shouldn't 'i...@3' be different since the PCI device is not the same? It should, but since the mac io is not qdevified there is no qdev pci device for it. So the fix is to qdevify mac io bus. OK. -- Gleb.
[Qemu-devel] Re: [PATCHv8 00/16] boot order specification
2010/12/11 Gleb Natapov g...@redhat.com: On Sat, Dec 11, 2010 at 05:19:01PM +, Blue Swirl wrote: What should we do with at...@600 vs dr...@1? There is no available IDE OF binding spec, so I when with the way OpenBIOS reports ata on qemu-x86. I have no idea what 600 in at...@600 may mean, but looking at g3_beige_300.html there is no such node there and looking at any other device tree in http://penguinppc.org/historical/dev-trees-html/ I haven't found one that use this kind of addressing for pci-ata. http://penguinppc.org/historical/dev-trees-html/g3bw_400.html for instance has p...@8000/pci-bri...@d/pci-...@1/ata-4. at...@600 kind of addressing is used by devices on mac-io bus which I do not think we emulate in qemu. So it looks like OpneBIOS is wrong here. We have PMAC IDE, but this device is CMD646, so mac-io bus addressing rules should not be used. So you agree that OpenBIOS is wrong here? I think so.
Re: [Qemu-devel] Re: [PATCHv8 00/16] boot order specification
2010/12/11 Gleb Natapov g...@redhat.com: On Sat, Dec 11, 2010 at 08:02:23PM +0200, Gleb Natapov wrote: On Sat, Dec 11, 2010 at 05:19:01PM +, Blue Swirl wrote: What should we do with at...@600 vs dr...@1? There is no available IDE OF binding spec, so I when with the way OpenBIOS reports ata on qemu-x86. I have no idea what 600 in at...@600 may mean, but looking at g3_beige_300.html there is no such node there and looking at any other device tree in http://penguinppc.org/historical/dev-trees-html/ I haven't found one that use this kind of addressing for pci-ata. http://penguinppc.org/historical/dev-trees-html/g3bw_400.html for instance has p...@8000/pci-bri...@d/pci-...@1/ata-4. at...@600 kind of addressing is used by devices on mac-io bus which I do not think we emulate in qemu. So it looks like OpneBIOS is wrong here. We have PMAC IDE, but this device is CMD646, so mac-io bus addressing rules should not be used. So you agree that OpenBIOS is wrong here? In this tree there are two disks connected to CMD646, named /p...@8000/pci-bri...@d/pci-...@1/ata-4/disk and /p...@8000/pci-bri...@d/pci-...@1/ata-4/d...@1: http://penguinppc.org/historical/dev-trees-html/g4_pci_350.html You are saying that qemu creates paths like: /grac...@fec0/i...@3/dr...@1/d...@0 /grac...@fec0/i...@3/dr...@1/d...@1 I do not understand why qemu creates node dr...@1. It should be dr...@0 according to the code. I'll look at why unit-address is incorrect for the node. But assuming that this problem is fixed then paths created by qemu is very similar to the paths in g4_pci_350.html. It looks like in g4_pci_350.html they omit unit address if it is zero. Ah the problem is that we have not qdevified mac io bus. Since first to ide disks are automatically attached to mac-io bus device paths for them are incorrect. Next two ide devices will be attached to CMD646 and qemu will generate correct device paths for them: qemu-system-ppc -drive if=none,id=hda,file=/dev/null -device ide-drive,drive=hda,bootindex=1 -drive if=none,id=cd,file=/dev/null -device ide-drive,drive=cd,bootindex=0 -nographic -drive if=none,id=hdb,file=/dev/null -device ide-drive,drive=hdb,bus=ide.0,bootindex=2 -drive if=none,id=hdc,file=/dev/null -device ide-drive,drive=hdc,bus=ide.0,bootindex=3 adding '/grac...@fec0/i...@3/dr...@1/d...@1' at index 0 adding '/grac...@fec0/i...@3/dr...@1/d...@0' at index 1 adding '/grac...@fec0/i...@3/dr...@0/d...@0' at index 2 adding '/grac...@fec0/i...@3/dr...@0/d...@1' at index 3 But why is the path almost the same as CMD646, shouldn't 'i...@3' be different since the PCI device is not the same? So the fix is to qdevify mac io bus. OK.
[Qemu-devel] Re: [PATCHv8 00/16] boot order specification
Thanks, applied all. On Wed, Dec 8, 2010 at 11:34 AM, Gleb Natapov g...@redhat.com wrote: Forget to save a couple of buffers before sending version 7 :( Anthony, Blue can this be applied now? Gleb Natapov (16): Introduce fw_name field to DeviceInfo structure. Introduce new BusInfo callback get_fw_dev_path. Keep track of ISA ports ISA device is using in qdev. Add get_fw_dev_path callback to ISA bus in qdev. Store IDE bus id in IDEBus structure for easy access. Add get_fw_dev_path callback to IDE bus. Add get_fw_dev_path callback for system bus. Add get_fw_dev_path callback for pci bus. Record which USBDevice USBPort belongs too. Add get_fw_dev_path callback for usb bus. Add get_fw_dev_path callback to scsi bus. Add bootindex parameter to net/block/fd device Change fw_cfg_add_file() to get full file path as a parameter. Add bootindex for option roms. Add notifier that will be called when machine is fully created. Pass boot device list to firmware. block_int.h | 4 +- hw/cs4231a.c | 1 + hw/e1000.c | 4 ++ hw/eepro100.c | 3 + hw/fdc.c | 12 ++ hw/fw_cfg.c | 30 -- hw/fw_cfg.h | 4 +- hw/gus.c | 4 ++ hw/ide/cmd646.c | 4 +- hw/ide/internal.h | 3 +- hw/ide/isa.c | 5 ++- hw/ide/piix.c | 4 +- hw/ide/qdev.c | 22 ++- hw/ide/via.c | 4 +- hw/isa-bus.c | 42 +++ hw/isa.h | 4 ++ hw/lance.c | 1 + hw/loader.c | 32 --- hw/loader.h | 8 ++-- hw/m48t59.c | 1 + hw/mc146818rtc.c | 1 + hw/multiboot.c | 3 +- hw/ne2000-isa.c | 3 + hw/ne2000.c | 5 ++- hw/nseries.c | 4 +- hw/palm.c | 6 +- hw/parallel.c | 5 ++ hw/pc.c | 7 ++- hw/pci.c | 110 --- hw/pci_host.c | 2 + hw/pckbd.c | 3 + hw/pcnet-pci.c | 2 +- hw/pcnet.c | 4 ++ hw/piix_pci.c | 1 + hw/qdev.c | 32 +++ hw/qdev.h | 14 ++ hw/rtl8139.c | 4 ++ hw/sb16.c | 4 ++ hw/scsi-bus.c | 23 +++ hw/scsi-disk.c | 2 + hw/serial.c | 1 + hw/sysbus.c | 30 ++ hw/sysbus.h | 4 ++ hw/usb-bus.c | 45 - hw/usb-hub.c | 3 +- hw/usb-musb.c | 2 +- hw/usb-net.c | 3 + hw/usb-ohci.c | 2 +- hw/usb-uhci.c | 2 +- hw/usb.h | 3 +- hw/virtio-blk.c | 2 + hw/virtio-net.c | 2 + hw/virtio-pci.c | 1 + net.h | 4 +- qemu-config.c | 17 sysemu.h | 11 +- vl.c | 114 - 57 files changed, 593 insertions(+), 80 deletions(-) -- 1.7.2.3
[Qemu-devel] [PATCH] vga: Declare as little endian
This patch replaces explicit bswaps with endianness hints to the
mmio layer.
CC: Alexander Graf ag...@suse.de
Signed-off-by: Blue Swirl blauwir...@gmail.com
---
hw/vga.c | 26 +-
1 files changed, 1 insertions(+), 25 deletions(-)
diff --git a/hw/vga.c b/hw/vga.c
index b5c8741..c632fd7 100644
--- a/hw/vga.c
+++ b/hw/vga.c
@@ -767,30 +767,18 @@ uint32_t vga_mem_readb(void *opaque,
target_phys_addr_t addr)
static uint32_t vga_mem_readw(void *opaque, target_phys_addr_t addr)
{
uint32_t v;
-#ifdef TARGET_WORDS_BIGENDIAN
-v = vga_mem_readb(opaque, addr) 8;
-v |= vga_mem_readb(opaque, addr + 1);
-#else
v = vga_mem_readb(opaque, addr);
v |= vga_mem_readb(opaque, addr + 1) 8;
-#endif
return v;
}
static uint32_t vga_mem_readl(void *opaque, target_phys_addr_t addr)
{
uint32_t v;
-#ifdef TARGET_WORDS_BIGENDIAN
-v = vga_mem_readb(opaque, addr) 24;
-v |= vga_mem_readb(opaque, addr + 1) 16;
-v |= vga_mem_readb(opaque, addr + 2) 8;
-v |= vga_mem_readb(opaque, addr + 3);
-#else
v = vga_mem_readb(opaque, addr);
v |= vga_mem_readb(opaque, addr + 1) 8;
v |= vga_mem_readb(opaque, addr + 2) 16;
v |= vga_mem_readb(opaque, addr + 3) 24;
-#endif
return v;
}
@@ -931,28 +919,16 @@ void vga_mem_writeb(void *opaque,
target_phys_addr_t addr, uint32_t val)
static void vga_mem_writew(void *opaque, target_phys_addr_t addr, uint32_t val)
{
-#ifdef TARGET_WORDS_BIGENDIAN
-vga_mem_writeb(opaque, addr, (val 8) 0xff);
-vga_mem_writeb(opaque, addr + 1, val 0xff);
-#else
vga_mem_writeb(opaque, addr, val 0xff);
vga_mem_writeb(opaque, addr + 1, (val 8) 0xff);
-#endif
}
static void vga_mem_writel(void *opaque, target_phys_addr_t addr, uint32_t val)
{
-#ifdef TARGET_WORDS_BIGENDIAN
-vga_mem_writeb(opaque, addr, (val 24) 0xff);
-vga_mem_writeb(opaque, addr + 1, (val 16) 0xff);
-vga_mem_writeb(opaque, addr + 2, (val 8) 0xff);
-vga_mem_writeb(opaque, addr + 3, val 0xff);
-#else
vga_mem_writeb(opaque, addr, val 0xff);
vga_mem_writeb(opaque, addr + 1, (val 8) 0xff);
vga_mem_writeb(opaque, addr + 2, (val 16) 0xff);
vga_mem_writeb(opaque, addr + 3, (val 24) 0xff);
-#endif
}
typedef void vga_draw_glyph8_func(uint8_t *d, int linesize,
@@ -2321,7 +2297,7 @@ void vga_init(VGACommonState *s)
#endif /* CONFIG_BOCHS_VBE */
vga_io_memory = cpu_register_io_memory(vga_mem_read, vga_mem_write, s,
- DEVICE_NATIVE_ENDIAN);
+ DEVICE_LITTLE_ENDIAN);
cpu_register_physical_memory(isa_mem_base + 0x000a, 0x2,
vga_io_memory);
qemu_register_coalesced_mmio(isa_mem_base + 0x000a, 0x2);
--
1.6.2.4
Re: [Qemu-devel] Re: [PATCHv8 00/16] boot order specification
On Sat, 2010-12-11 at 18:06 +0200, Gleb Natapov wrote: http://playground.sun.com/pub/p1275/bindings/pci/pci2_1.pdf has table on page 10 that defines how pci class code should be translated into OF name. This is what my patch is using. pci-ata does not look spec compliant (or is there more up-to-date spec?) What should we do with at...@600 vs dr...@1? There is no available IDE OF binding spec, so I when with the way OpenBIOS reports ata on qemu-x86. I have no idea what 600 in at...@600 may mean, but looking at g3_beige_300.html there is no such node there and looking at any other device tree in http://penguinppc.org/historical/dev-trees-html/ Those are old and I wouldn't look too closely at what Apple does. ATA doesn't really need anything complex, mostly the ata controller, generally named ata nowadays with a #address-cells of 1 and a #size-cells of 0. Children are then typically disk, cdrom, ... (ie block devices) with a unit address of 0 for master and 1 for slave. In the case of controllers with multiple ports, typically you have one such ata node per bus. pci-ata is a liberal use by Apple here representing the actual host controller PCI device. In any case, what matters is the compatible property. This is what defines the programming interface of a device. I haven't found one that use this kind of addressing for pci-ata. http://penguinppc.org/historical/dev-trees-html/g3bw_400.html for instance has p...@8000/pci-bri...@d/pci-...@1/ata-4. at...@600 kind of addressing is used by devices on mac-io bus which I do not think we emulate in qemu. So it looks like OpneBIOS is wrong here. Well, it's possible that the @600 represents a register offset within pci-ata, this is entirely up to pci-ata to do as it wishes there to define it's own internal binding. Is there a ranges property defining translation accross pci-ata ? Cheers, Ben.
Re: [Qemu-devel] Re: [PATCHv8 00/16] boot order specification
Ah the problem is that we have not qdevified mac io bus. Since first to ide disks are automatically attached to mac-io bus device paths for them are incorrect. Next two ide devices will be attached to CMD646 and qemu will generate correct device paths for them: qemu-system-ppc -drive if=none,id=hda,file=/dev/null -device ide-drive,drive=hda,bootindex=1 -drive if=none,id=cd,file=/dev/null -device ide-drive,drive=cd,bootindex=0 -nographic -drive if=none,id=hdb,file=/dev/null -device ide-drive,drive=hdb,bus=ide.0,bootindex=2 -drive if=none,id=hdc,file=/dev/null -device ide-drive,drive=hdc,bus=ide.0,bootindex=3 adding '/grac...@fec0/i...@3/dr...@1/d...@1' at index 0 adding '/grac...@fec0/i...@3/dr...@1/d...@0' at index 1 adding '/grac...@fec0/i...@3/dr...@0/d...@0' at index 2 adding '/grac...@fec0/i...@3/dr...@0/d...@1' at index 3 But why is the path almost the same as CMD646, shouldn't 'i...@3' be different since the PCI device is not the same? It should, but since the mac io is not qdevified there is no qdev pci device for it. Note that a better long term solution for all these is to have qemu maintain the device-tree, using libfdt, and pass it to the firmware. I have a port of SLOF that I can't release just yet (soon hopefully) on top of another ppc machine for qemu that will also hopefully be soon out there, but basically, what I do there is pass the FDT to SLOF, in which I use forth code to expand it into a real OF device-tree. Then, my SLOF code populates methods for known devices. The only problem with that approach is the phandles. OpenBIOS/SLOF/OFW will assign it's own phandle to nodes it creates, ignoring the phandle properties created by libfdt. That means that linkage within the device-tree will be potentially broken accross the transition (ie, interrupt-parent, interrupt-map etc... all contain phandle values to reference another node). The way I get away with it right now is that I never use such linkage in SLOF and I preserve the original phandle properties, which Linux will then pickup and use instead of the SLOF native phandle when parsing the tree. A better long run option would be to have OF itself (whichever variant) use some remapping on the phandles (instead of making them just pointers) so it can create nodes with specific phandles. Once you have your device-tree in qemu, everything looks simpler, you no longer have to play guess work as to what the path will look like inside the firmware. It also opens the door for passing bits of the device-tree dynamically to the kernel for hotplug etc... Cheers, Ben.
[Qemu-devel] sparc OBP psr value
Under qemu-system-sparc, I found a problem with OBP's psr commands. On an real SS-20, I get: ok .psr CWP: 4 ET: 1 PS: 1 S: 1 PIL: f EF: 1 EC: 0 ICC: nZvc VER: 0 IMPL: 4 ok %psr . 40401fe4 But with qemu, it all shows up as 0, such as: ok .psr CWP: 0 ET: 0 PS: 0 S: 0 PIL: 0 EF: 0 EC: 0 ICC: nzvc VER: 0 IMPL: 0 ok %psr . 0 while info registers says the psr should be 40001de0. Any suggestion of how to debug this? Bob
