[Qemu-devel] Re: sparc32 fix np dereference in do_unassigned_access
Thanks, applied.
On Fri, Jan 22, 2010 at 9:31 PM, Artyom Tarasenko
atar4q...@googlemail.com wrote:
fix a potential null pointer dereference introduced in
commit 576c2cdc767ab9e2dc038fa4c99f22e53287a3de
Signed-off-by: Artyom Tarasenko atar4q...@gmail.com
---
diff --git a/target-sparc/op_helper.c b/target-sparc/op_helper.c
index ce8c6f1..eb4f5a4 100644
--- a/target-sparc/op_helper.c
+++ b/target-sparc/op_helper.c
@@ -3761,13 +3761,14 @@ void do_unassigned_access(target_phys_addr_t addr,
int is_write, int is_exec,
else
raise_exception(TT_DATA_ACCESS);
}
- env = saved_env;
/* flush neverland mappings created during no-fault mode,
so the sequential MMU faults report proper fault types */
if (env-mmuregs[0] MMU_NF) {
tlb_flush(env, 1);
}
+
+ env = saved_env;
}
#else
void do_unassigned_access(target_phys_addr_t addr, int is_write, int is_exec,
[Qemu-devel] no sound in MusicPal with qemu 0.12.2
Hi there, I have compiled qemu 0.12.2 on an x64 ubuntu (8.10) and run MusicPal in it with SDL. MusicPal works OK but there is no sound. I have done essentially the same with qemu 0.11.1. The sound is there (thanks jki for suggesting a previous version). Please find below the configs and logs contact me if additional info is needed. Cheers, Ondrej 1) qemu-0.12.2 === config === ./configure --enable-mixemu --audio-drv-list=alsa oss sdl esd --target-list=arm-softmmu Install prefix /usr/local BIOS directory /usr/local/share/qemu binary directory /usr/local/bin Manual directory /usr/local/share/man ELF interp prefix /usr/gnemul/qemu-%M Source path /home/ondrej/private/musicpal/qemu-0.12.2 C compiler gcc Host C compiler gcc CFLAGS -O2 -g QEMU_CFLAGS -m64 -Wold-style-definition -Wold-style-declaration -I. -I$(SRC_PATH) -U_FORTIFY_SOURCE -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wendif-labels -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing LDFLAGS -Wl,--warn-common -m64 -g make make install install host CPU x86_64 host big endian no target list arm-softmmu tcg debug enabled no gprof enabled no sparse enabled no strip binaries yes profiler no static build no -Werror enabled no SDL support yes curses support yes curl support no check support no mingw32 support no Audio drivers alsa oss sdl esd Extra audio cards ac97 es1370 sb16 Block whitelist Mixer emulation yes VNC TLS support no VNC SASL support no xen support no brlapi support no bluez support no Documentation yes NPTL support yes GUEST_BASE yes PIE user targets no vde support no IO thread no Linux AIO support no Install blobs yes KVM support no fdt support no preadv support no fdatasync yes uuid support no === make and install === === run it === export QEMU_AUDIO_DRV=sdl export SDL_VIDEODRIVER=x11 ##export SDL_AUDIODRIVER= qemu-system-arm -M musicpal -pflash flash.image -kernel u-boot.bin -serial stdio -m 128 -redir tcp:8080::80 -redir tcp:2323::23 __ __ _ _ | \/ | __ _ _ _| | | | |\/| |/ _` | '__\ \ / / _ \ | | | | | | (_| | | \ V / __/ | | |_| |_|\__,_|_| \_/ \___|_|_| _ _ _ | | | | | __ ) ___ ___ | |_ | | | |___| _ \ / _ \ / _ \| __| | |_| |___| |_) | (_) | (_) | |_ \___/ |/ \___/ \___/ \__| MARVELL MV88W8618 Rev 0x31 SOC Validation Board. Based on Feroceon Core with ARM926 LE CPU. U-Boot 1.1.1 (Apr 7 2008 - 13:51:47) Marvell Version: Maryland 23 Freecom Version: Nashville 1.47 U-Boot code: 00F0 - 00F2B9E0 BSS: - 00F627CC RAM Configuration: Bank #0: 32 MB Flash: 8 MB No environment found on flash, using default. In: serial Out: serial Err: serial Waiting for USB connection USB not connected Net: Please wait, this takes a while... ethernetPhyInit at 0 Port LINK FAILS, Check line connection eth0 [PRIME] No mac address set, using random mac address 00:01:DB:FF:68:56. Hit any key to stop autoboot: 0 JFFS2 loading 'uImage' to 0x40 Scanning JFFS2 FS: .. done. JFFS2 load complete: 1203756 bytes loaded to 0x40 Booting image at 0040 ... Image Name: Linux-2.6.16.16-88w8xx8 Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 1203692 Bytes = 1.1 MB Load Address: 8000 Entry Point: 8000 Verifying Checksum ... OK OK Starting kernel... Uncompressing Linux... done, booting the kernel. Linux version 2.6.16.16-88w8xx8 (r...@freecom.com) (gcc version 3.3.3 (DENX ELDK 3.1.1 3.3.3-9)) #393 PREEMPT Thu Apr 3 05:56:25 UTC 2008 CPU: ARM926EJ-Sid(wb) [41069265] revision 5 (ARMv5TEJ) Machine: MV88W8618-HS35 Using U-Boot release 1.1.1.23 Memory policy: ECC disabled, Data cache writeback CPU0: D VIVT write-through cache CPU0: I cache: 4096 bytes, associativity 4, 32 byte lines, 32 sets CPU0: D cache: 65536 bytes, associativity 4, 32 byte lines, 512 sets Built 1 zonelists Kernel command line: console=ttyS0,38400 root=/dev/mtdblock0 ro rootfstype=jffs2 ethaddr=00:01:DB:FF:68:56 PID hash table entries: 256 (order: 8, 4096 bytes) Console: colour dummy device 80x30 Dentry cache hash table entries: 8192 (order: 3, 32768 bytes) Inode-cache hash table entries: 4096 (order: 2, 16384 bytes) Memory: 32MB = 32MB total Memory: 29268KB available (2100K code, 911K data, 92K init) Mount-cache hash table entries: 512 CPU: Testing write buffer coherency: ok NET: Registered protocol family 16 Reserved 64 pages (page size 4096) starting from c03c for WLAN buffer pool audio_init, major is 254 ... audio set to DMA mode fc00 fc001000 2048 Rx c000 0 0 Marvell USB EHCI Host controller SCSI subsystem initialized usbcore: registered new driver usbfs
Re: [Qemu-devel] Luvalley-5 has been released (with whitepaper!): enables arbitrary OS to run VMs without any modification
On 23.01.2010, at 13:07, Xiaodong Yi wrote: Thanks for your advice. I'm now preparing to update the Qemu for Windows (not started yet). I originally though it should be better to use Qemu-KVM in Linux because, for example, Qemu-KVM supports SMP guests. I will review the newest Qemu version before updating Qemu for Linux. Well, SMP support is definitely coming to upstream Qemu as well. IMHO the best integration strategy would really be a simple kvm_*_ioctl wrapper that sends it off to Luvally in upstream Qemu. But please coordinate with Avi and Anthony before you start the real work on what they think is best. After all, they'll be the two people committing it. Alex
Re: [Qemu-devel] no sound in MusicPal with qemu 0.12.2
On Sat, 23 Jan 2010, ondrej drbohlav wrote: Hi there, I have compiled qemu 0.12.2 on an x64 ubuntu (8.10) and run MusicPal in it with SDL. MusicPal works OK but there is no sound. Confirmed. I have done essentially the same with qemu 0.11.1. The sound is there (thanks jki for suggesting a previous version). Please find below the configs and logs contact me if additional info is needed. Cheers, Ondrej 1) qemu-0.12.2 [..snip..] Someone would have to bisect it. BTW, Jan, 2e87c5b937444c1155073f7b10d630e0e383e5d8 doesn't quite do what i said helps[1] and conseqently musicpal enters an infinite loop again... [1] http://lists.gnu.org/archive/html/qemu-devel/2009-09/msg00920.html -- mailto:av1...@comtv.ru
[Qemu-devel] Re: no sound in MusicPal with qemu 0.12.2
malc wrote: On Sat, 23 Jan 2010, ondrej drbohlav wrote: Hi there, I have compiled qemu 0.12.2 on an x64 ubuntu (8.10) and run MusicPal in it with SDL. MusicPal works OK but there is no sound. Confirmed. I have done essentially the same with qemu 0.11.1. The sound is there (thanks jki for suggesting a previous version). Please find below the configs and logs contact me if additional info is needed. Cheers, Ondrej 1) qemu-0.12.2 [..snip..] Someone would have to bisect it. Already done: it's b3a219883ebe21f55a8ee5e7e5b38b9eb309e9c0. But that patch looks sane. I guess it just revealed a hidden bug in Musicpal's i2c use. Need to dig deeper. BTW, Jan, 2e87c5b937444c1155073f7b10d630e0e383e5d8 doesn't quite do what i said helps[1] and conseqently musicpal enters an infinite loop again... [1] http://lists.gnu.org/archive/html/qemu-devel/2009-09/msg00920.html OK, I will have to look into the Linux driver code to check the loop termination conditions again. Jan signature.asc Description: OpenPGP digital signature
Re: [Qemu-devel] Compiling ppc64-softmmu/translate.c breaks with --enable-debug
Sepp Holzmayr schrieb: Hi all, when building git HEAD on an Ubuntu 9.10/64 with --enable-debug, it breaks with CCppc64-softmmu/translate.o /home/jd/qemu/target-ppc/translate.c: In function ‘gen_mfdcr’: /home/jd/qemu/target-ppc/translate.c:5568: error: incompatible type for argument 1 of ‘gen_helper_load_dcr’ Hi, this is a know bug. See http://lists.gnu.org/archive/html/qemu-devel/2009-12/msg02577.html There is also a patch which fixes it, but it still needs some improvements, so it was not commited up to now. Regards, Stefan Weil
[Qemu-devel] Re: sparc32 do_unassigned_access overhaul
2010/1/23 Blue Swirl blauwir...@gmail.com: On Fri, Jan 22, 2010 at 8:51 PM, Artyom Tarasenko atar4q...@googlemail.com wrote: 2010/1/22 Blue Swirl blauwir...@gmail.com: On Tue, Jan 19, 2010 at 9:44 PM, Artyom Tarasenko atar4q...@googlemail.com wrote: 2010/1/19 Blue Swirl blauwir...@gmail.com: On Tue, Jan 19, 2010 at 5:30 PM, Artyom Tarasenko atar4q...@googlemail.com wrote: 2010/1/15 Artyom Tarasenko atar4q...@googlemail.com: 2010/1/15 Blue Swirl blauwir...@gmail.com: On Fri, Jan 15, 2010 at 9:11 PM, Artyom Tarasenko atar4q...@googlemail.com wrote: 2010/1/15 Blue Swirl blauwir...@gmail.com: On Fri, Jan 15, 2010 at 6:46 PM, Artyom Tarasenko atar4q...@googlemail.com wrote: According to pages 9-31 - 9-34 of SuperSPARC MultiCache Controller User's Manual: 1. A lower priority fault may not overwrite the MFSR status of a higher priority fault. 2. The MFAR is overwritten according to the policy defined for the MFSR 3. The overwrite bit is asserted if the fault status register (MFSR) has been written more than once by faults of the same class 4. SuperSPARC will never place instruction fault addresses in the MFAR. Implementation of points 1-3 allows booting Solaris 2.6 and 2.5.1. Nice work! This also passes my tests. I'm afraid we still are not there yet though: Solaris 7 fails potentially due to another bug in the MMU emulation, and the initial [missing-] RAM detection in OBP fails very probably due to a bug in in the MMU emulation. Some guesses: - Access to unassigned RAM area may be handled by the memory controller differently (no faults, different faults etc.) than unassigned access to SBus or other area. You are right! It seems to be true for the area larger than max RAM though. On a real SS-5 with 32M in the first bank, no fault is produced at least for the areas 0-0x2fff, 0x7000-0xafff (ha, this would solve problems with SS-20 OBP too) and 0xf000-0xf6ff. The fault may still be recorded somewhere else (MXCC, RAM/ECC controller or IOMMU). sfar and sfsr were empty, so it's definitely not MXCC. Don't know where to look for the other two. But how the fault would be generated? Don't know about Sun simms, but PC ones don't have any handshake. IMHO the ECC can be the only possibility. OBP may have disabled the fault, or it has not enabled fault generation. NF bit is not set. Also, you can see the other faults. On SS-5, the physical address space should be only 31 bits, so you should see RAM aliased at 0x8000. No. The RAM can be aliased only within one bank or completely outside the RAM area. Otherwise different banks would have interfered. Would you like to implement it? For RAM, there could be a new device which implements generic address space wrapping (base, length, AND mask, OR mask), it should be useful for embedded boards. Shouldn't be too difficult, want to try? :-) Minutes for you, days for me. :) Here's my patch. It implements mapping of bottom 2G to upper 2G. Could you play with the patch and try to implement RAM aliasing so that OBP is content? It's a nice patch, but I'm confused. I thought that in my last mail I proved that we don't observe any RAM aliasing on SS-5. We see some ROM aliasing, but I'm not sure whether it's worth implementing. I'd still expect some aliasing if a bank has smaller chips than others. For example, if you have 40M of memory and bank size is 16M, there are two full banks and one bank with 8M. This 8M should be aliased within the 16MB area twice. Otherwise the DRAM controller must somehow know or be told the chip size. So, the aliasing code could be useful to emulate more arbitrary memory sizes (with OBP), not just multiples of bank sizes. Yes, but do we need it? Nowadays 32M is small enough (and Classic/X/LX have even smaller memory banks: 16M. Of course if we going to support the Ross Technologies SS-20, it will make sense again, as it has larger memory banks (128M iirc). But for now wouldn't it be better to focus on fully supporting full banks? Also we see no synchronous faults on SS-5 when accessing missing memory. Haven't tested it on SS-20 yet. I'll try to get an access to a real SS-20 next week (can't have a simultaneous access to the both of them). Is memory parity enabled? ok mcr@ . 43d1b01 ok The 12th bit is set. Are there further parity switches on SS-5? -- Regards, Artyom Tarasenko solaris/sparc under qemu blog: http://tyom.blogspot.com/
[Qemu-devel] [PATCH 1/2] ARMv7: Initialize SCTLR on v7 so that it reads RAO bits as one.
If left uninitialized, read/update/write style access causes QEMU to interpret the architecture as non-v7 since bit 23 reads 0. Signed-off-by: Bahadir Balban bbal...@b-labs.co.uk --- target-arm/helper.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/target-arm/helper.c b/target-arm/helper.c index b3aec99..0098053 100644 --- a/target-arm/helper.c +++ b/target-arm/helper.c @@ -101,6 +101,7 @@ static void cpu_reset_model_id(CPUARMState *env, uint32_t id) env-vfp.xregs[ARM_VFP_MVFR1] = 0x00011100; memcpy(env-cp15.c0_c1, cortexa8_cp15_c0_c1, 8 * sizeof(uint32_t)); memcpy(env-cp15.c0_c2, cortexa8_cp15_c0_c2, 8 * sizeof(uint32_t)); +env-cp15.c1_sys = (1 23) | (1 22) | (1 18) | (1 16) | (0xF 3); env-cp15.c0_cachetype = 0x82048004; env-cp15.c0_clid = (1 27) | (2 24) | 3; env-cp15.c0_ccsid[0] = 0xe007e01a; /* 16k L1 dcache. */ @@ -123,6 +124,7 @@ static void cpu_reset_model_id(CPUARMState *env, uint32_t id) env-vfp.xregs[ARM_VFP_MVFR1] = 0x0111; memcpy(env-cp15.c0_c1, cortexa9_cp15_c0_c1, 8 * sizeof(uint32_t)); memcpy(env-cp15.c0_c2, cortexa9_cp15_c0_c2, 8 * sizeof(uint32_t)); +env-cp15.c1_sys = (1 23) | (1 22) | (1 18) | (1 16) | (0xF 3); env-cp15.c0_cachetype = 0x80038003; env-cp15.c0_clid = (1 27) | (1 24) | 3; env-cp15.c0_ccsid[0] = 0xe00fe015; /* 16k L1 dcache. */ -- 1.6.3.3
[Qemu-devel] [PATCH 2/2] [RFC] ARMv7: Enable hardware management of access flags
ARMv7 SCTLR bit 17 enables hardware management of access flags
where the hardware sets AP0 bit of a section or second level
table entry upon first access and does not generate a fault.
The issue is this had to introduce an extra ldl_phys_ptr call
that returns the pointer to page table entry for writing. A
better way to do it?
Signed-off-by: Bahadir Balban bbal...@b-labs.co.uk
---
cpu-common.h|1 +
exec.c | 16
target-arm/helper.c | 13 ++---
3 files changed, 27 insertions(+), 3 deletions(-)
diff --git a/cpu-common.h b/cpu-common.h
index 6302372..96cf67d 100644
--- a/cpu-common.h
+++ b/cpu-common.h
@@ -64,6 +64,7 @@ void cpu_unregister_map_client(void *cookie);
uint32_t ldub_phys(target_phys_addr_t addr);
uint32_t lduw_phys(target_phys_addr_t addr);
uint32_t ldl_phys(target_phys_addr_t addr);
+uint32_t *ldl_phys_ptr(target_phys_addr_t addr);
uint64_t ldq_phys(target_phys_addr_t addr);
void stl_phys_notdirty(target_phys_addr_t addr, uint32_t val);
void stq_phys_notdirty(target_phys_addr_t addr, uint64_t val);
diff --git a/exec.c b/exec.c
index 1190591..cc19586 100644
--- a/exec.c
+++ b/exec.c
@@ -3346,6 +3346,22 @@ uint32_t ldl_phys(target_phys_addr_t addr)
return val;
}
+uint32_t *ldl_phys_ptr(target_phys_addr_t addr)
+{
+unsigned long pd;
+PhysPageDesc *p;
+
+p = phys_page_find(addr TARGET_PAGE_BITS);
+if (!p) {
+pd = IO_MEM_UNASSIGNED;
+} else {
+pd = p-phys_offset;
+}
+/* RAM case */
+return qemu_get_ram_ptr(pd TARGET_PAGE_MASK) +
+(addr ~TARGET_PAGE_MASK);
+}
+
/* warning: addr must be aligned */
uint64_t ldq_phys(target_phys_addr_t addr)
{
diff --git a/target-arm/helper.c b/target-arm/helper.c
index 0098053..5cebd8c 100644
--- a/target-arm/helper.c
+++ b/target-arm/helper.c
@@ -1065,9 +1065,16 @@ static int get_phys_addr_v6(CPUState *env, uint32_t
address, int access_type,
/* The simplified model uses AP[0] as an access control bit. */
if ((env-cp15.c1_sys (1 29)) (ap 1) == 0) {
-/* Access flag fault. */
-code = (code == 15) ? 6 : 3;
-goto do_fault;
+/* Is hardware management enabled? */
+if (!(env-cp15.c1_sys (1 17))) {
+ /* No, access flag fault. */
+ code = (code == 15) ? 6 : 3;
+ goto do_fault;
+ } else {
+/* Set the access flag */
+ uint32_t *desc_ptr = ldl_phys_ptr(table);
+*desc_ptr |= (1 10);
+ }
}
*prot = check_ap(env, ap, domain, access_type, is_user);
if (!*prot) {
--
1.6.3.3
[Qemu-devel] Re: no sound in MusicPal with qemu 0.12.2
Jan Kiszka wrote: malc wrote: On Sat, 23 Jan 2010, ondrej drbohlav wrote: Hi there, I have compiled qemu 0.12.2 on an x64 ubuntu (8.10) and run MusicPal in it with SDL. MusicPal works OK but there is no sound. Confirmed. I have done essentially the same with qemu 0.11.1. The sound is there (thanks jki for suggesting a previous version). Please find below the configs and logs contact me if additional info is needed. Cheers, Ondrej 1) qemu-0.12.2 [..snip..] Someone would have to bisect it. Already done: it's b3a219883ebe21f55a8ee5e7e5b38b9eb309e9c0. But that patch looks sane. I guess it just revealed a hidden bug in Musicpal's i2c use. Need to dig deeper. Found, trivial patch on the way. BTW, Jan, 2e87c5b937444c1155073f7b10d630e0e383e5d8 doesn't quite do what i said helps[1] and conseqently musicpal enters an infinite loop again... [1] http://lists.gnu.org/archive/html/qemu-devel/2009-09/msg00920.html OK, I will have to look into the Linux driver code to check the loop termination conditions again. This still makes no sense, at least based on available driver sources and so far observed behavior with existing firmware images: the TX queue is always setup to form a ring, at no point the driver destroys this ring before triggering a TX. So we are only left with a potentially undefined (NULL) ring entry pointer, and that is what my commit tried to catch. I rather suspect we see a subtle memory corruption here. Malc, when do you get this? Could you instrument the loop to check if we get off-track before, scanning random guest memory? Jan signature.asc Description: OpenPGP digital signature
[Qemu-devel] Re: no sound in MusicPal with qemu 0.12.2
On Sat, 23 Jan 2010, Jan Kiszka wrote: Jan Kiszka wrote: malc wrote: On Sat, 23 Jan 2010, ondrej drbohlav wrote: Hi there, I have compiled qemu 0.12.2 on an x64 ubuntu (8.10) and run MusicPal in it with SDL. MusicPal works OK but there is no sound. Confirmed. I have done essentially the same with qemu 0.11.1. The sound is there (thanks jki for suggesting a previous version). Please find below the configs and logs contact me if additional info is needed. Cheers, Ondrej 1) qemu-0.12.2 [..snip..] Someone would have to bisect it. Already done: it's b3a219883ebe21f55a8ee5e7e5b38b9eb309e9c0. But that patch looks sane. I guess it just revealed a hidden bug in Musicpal's i2c use. Need to dig deeper. Found, trivial patch on the way. Will test... BTW, Jan, 2e87c5b937444c1155073f7b10d630e0e383e5d8 doesn't quite do what i said helps[1] and conseqently musicpal enters an infinite loop again... [1] http://lists.gnu.org/archive/html/qemu-devel/2009-09/msg00920.html OK, I will have to look into the Linux driver code to check the loop termination conditions again. This still makes no sense, at least based on available driver sources and so far observed behavior with existing firmware images: the TX queue is always setup to form a ring, at no point the driver destroys this ring before triggering a TX. So we are only left with a potentially undefined (NULL) ring entry pointer, and that is what my commit tried to catch. I rather suspect we see a subtle memory corruption here. Malc, when do you get this? Could you instrument the loop to check if we get off-track before, scanning random guest memory? I asked some questions before[1] but nobody answered them.. Anyhow i'm happy to do stuff, just need to be instructed what is this stuff that needs to be done.. [1] http://lists.gnu.org/archive/html/qemu-devel/2009-10/msg00292.html -- mailto:av1...@comtv.ru
[Qemu-devel] [PATCH] Musicpal: Fix wm8750 I2C address
Commit b3a219883e uncovered that we attached the Wolfson with an I2C address shifted left by one. Fixing this makes sound work again for the Musicpal. Signed-off-by: Jan Kiszka jan.kis...@web.de --- hw/musicpal.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/hw/musicpal.c b/hw/musicpal.c index 4a33e28..e424a7d 100644 --- a/hw/musicpal.c +++ b/hw/musicpal.c @@ -67,7 +67,7 @@ #define MP_AUDIO_IRQ30 /* Wolfson 8750 I2C address */ -#define MP_WM_ADDR 0x34 +#define MP_WM_ADDR 0x1A /* Ethernet register offsets */ #define MP_ETH_SMIR 0x010 signature.asc Description: OpenPGP digital signature
[Qemu-devel] Re: sparc32 do_unassigned_access overhaul
On Sat, Jan 23, 2010 at 4:46 PM, Artyom Tarasenko atar4q...@googlemail.com wrote: 2010/1/23 Blue Swirl blauwir...@gmail.com: On Fri, Jan 22, 2010 at 8:51 PM, Artyom Tarasenko atar4q...@googlemail.com wrote: 2010/1/22 Blue Swirl blauwir...@gmail.com: On Tue, Jan 19, 2010 at 9:44 PM, Artyom Tarasenko atar4q...@googlemail.com wrote: 2010/1/19 Blue Swirl blauwir...@gmail.com: On Tue, Jan 19, 2010 at 5:30 PM, Artyom Tarasenko atar4q...@googlemail.com wrote: 2010/1/15 Artyom Tarasenko atar4q...@googlemail.com: 2010/1/15 Blue Swirl blauwir...@gmail.com: On Fri, Jan 15, 2010 at 9:11 PM, Artyom Tarasenko atar4q...@googlemail.com wrote: 2010/1/15 Blue Swirl blauwir...@gmail.com: On Fri, Jan 15, 2010 at 6:46 PM, Artyom Tarasenko atar4q...@googlemail.com wrote: According to pages 9-31 - 9-34 of SuperSPARC MultiCache Controller User's Manual: 1. A lower priority fault may not overwrite the MFSR status of a higher priority fault. 2. The MFAR is overwritten according to the policy defined for the MFSR 3. The overwrite bit is asserted if the fault status register (MFSR) has been written more than once by faults of the same class 4. SuperSPARC will never place instruction fault addresses in the MFAR. Implementation of points 1-3 allows booting Solaris 2.6 and 2.5.1. Nice work! This also passes my tests. I'm afraid we still are not there yet though: Solaris 7 fails potentially due to another bug in the MMU emulation, and the initial [missing-] RAM detection in OBP fails very probably due to a bug in in the MMU emulation. Some guesses: - Access to unassigned RAM area may be handled by the memory controller differently (no faults, different faults etc.) than unassigned access to SBus or other area. You are right! It seems to be true for the area larger than max RAM though. On a real SS-5 with 32M in the first bank, no fault is produced at least for the areas 0-0x2fff, 0x7000-0xafff (ha, this would solve problems with SS-20 OBP too) and 0xf000-0xf6ff. The fault may still be recorded somewhere else (MXCC, RAM/ECC controller or IOMMU). sfar and sfsr were empty, so it's definitely not MXCC. Don't know where to look for the other two. But how the fault would be generated? Don't know about Sun simms, but PC ones don't have any handshake. IMHO the ECC can be the only possibility. OBP may have disabled the fault, or it has not enabled fault generation. NF bit is not set. Also, you can see the other faults. On SS-5, the physical address space should be only 31 bits, so you should see RAM aliased at 0x8000. No. The RAM can be aliased only within one bank or completely outside the RAM area. Otherwise different banks would have interfered. Would you like to implement it? For RAM, there could be a new device which implements generic address space wrapping (base, length, AND mask, OR mask), it should be useful for embedded boards. Shouldn't be too difficult, want to try? :-) Minutes for you, days for me. :) Here's my patch. It implements mapping of bottom 2G to upper 2G. Could you play with the patch and try to implement RAM aliasing so that OBP is content? It's a nice patch, but I'm confused. I thought that in my last mail I proved that we don't observe any RAM aliasing on SS-5. We see some ROM aliasing, but I'm not sure whether it's worth implementing. I'd still expect some aliasing if a bank has smaller chips than others. For example, if you have 40M of memory and bank size is 16M, there are two full banks and one bank with 8M. This 8M should be aliased within the 16MB area twice. Otherwise the DRAM controller must somehow know or be told the chip size. So, the aliasing code could be useful to emulate more arbitrary memory sizes (with OBP), not just multiples of bank sizes. Yes, but do we need it? Nowadays 32M is small enough (and Classic/X/LX have even smaller memory banks: 16M. Of course if we going to support the Ross Technologies SS-20, it will make sense again, as it has larger memory banks (128M iirc). But for now wouldn't it be better to focus on fully supporting full banks? Right, it's not unreasonable to fix some limits for OBP use case, like 'you must use 256M only'. Also we see no synchronous faults on SS-5 when accessing missing memory. Haven't tested it on SS-20 yet. I'll try to get an access to a real SS-20 next week (can't have a simultaneous access to the both of them). Is memory parity enabled? ok mcr@ . 43d1b01 ok The 12th bit is set. Are there further parity switches on SS-5? Not that I know of.
Re: [Qemu-devel] Merge qemu android
On 01/21/2010 10:27 AM, Bastien ROUCARIES wrote: Hi, What is the step in order to get qemu android merged mainline ? http://android.git.kernel.org/?p=platform/external/qemu.git;a=summary Send patches. It's very difficult to merge downstream code unless that entire downstream is committed to working through upstream. I'd suggest encouraging the Android developers to commit to pushing all of the functionality upstream before going down this path. Regards, Anthony Liguori Regards Bastien
Re: [Qemu-devel] Spice project is now open
On Fri, 11 Dec 2009 17:07:13 -0200 Glauber Costa glom...@gmail.com wrote: Spice is a library, it is library for remote display, it handle by itself all the connection between the spice client to the host that run the guest, it include: sound, display, keyboard, usb, network tunneling (for printers) and so on... I want to add that qemu is not the sole user of spice, Spice will be used as a protocol to connect into physical windows/linux machines So how can we change the library just for qemu? I don't fully understand spice yet, but what's the difficulty here? libraries changes every single day to try to acomodate for the needs of specific users, be it through generalizations, shims, or whatever. This is just another day in the OSS world. We are working on physical machines support for spice. the library contain all what need for remote display.
[Qemu-devel] sparc solaris guest, hsfs_putpage: dirty HSFS page
All solaris versions which currently boot (from cd) regularly produce buckets of
hsfs_putpage: dirty HSFS page messages.
High Sierra is a pretty old and stable stuff, so it is possible that
the code is similar to OpenSolaris.
I looked in debugger, and the function calls hierarchy looks pretty similar.
Now in the OpenSolaris source code there is a nice comment:
http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/fs/hsfs/hsfs_vnops.c#1758
/*
* Normally pvn_getdirty() should return 0, which
* impies that it has done the job for us.
* The shouldn't-happen scenario is when it returns 1.
* This means that the page has been modified and
* needs to be put back.
* Since we can't write on a CD, we fake a failed
* I/O and force pvn_write_done() to destroy the page.
*/
if (pvn_getdirty(pp, flags) == 1) {
cmn_err(CE_NOTE,
hsfs_putpage: dirty HSFS page);
Now the question: does the problem have to do with qemu caches (non-)emulation?
Can it be that we mark non-dirty pages dirty? Or does qemu always mark
pages dirty exactly to avoid cache emulation?
Otherwise it means something else goes astray and Solaris guest really
modifies the pages it shouldn't.
Just wonder what to dig first, MMU or IRQ emulation (the two most
obvious suspects).
--
Regards,
Artyom Tarasenko
solaris/sparc under qemu blog: http://tyom.blogspot.com/
