[Qemu-devel] qemu/target-ppc cpu.h translate_init.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Jocelyn Mayer 07/12/10 07:40:16 Modified files: target-ppc : cpu.h translate_init.c Log message: Fix PowerPC 74xx definitions. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/cpu.h?cvsroot=qemu&r1=1.108&r2=1.109 http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/translate_init.c?cvsroot=qemu&r1=1.70&r2=1.71
[Qemu-devel] qemu/hw esp.c lsi53c895a.c scsi-disk.c scsi-dis...
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer 07/12/10 02:58:34 Modified files: hw : esp.c lsi53c895a.c scsi-disk.c scsi-disk.h usb-msd.c Log message: SCSI cleanup, by Laurent Vivier. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/hw/esp.c?cvsroot=qemu&r1=1.30&r2=1.31 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/lsi53c895a.c?cvsroot=qemu&r1=1.12&r2=1.13 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/scsi-disk.c?cvsroot=qemu&r1=1.16&r2=1.17 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/scsi-disk.h?cvsroot=qemu&r1=1.1&r2=1.2 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/usb-msd.c?cvsroot=qemu&r1=1.12&r2=1.13
Re: [Qemu-devel] [Patch][update] Mainstone re-org plus flash
andrzej zaborowski wrote: On 10/12/2007, andrzej zaborowski <[EMAIL PROTECTED]> wrote: On 02/12/2007, Armin <[EMAIL PROTECTED]> wrote: Thiemo, Thiemo Seufer wrote: Armin wrote: Hello, This includes the previous Mainstone re-org patch I sent earlier plus flash support. This adds two 32MiB flash devices. Mounts from mtdblock2 on flash device 0 fine at boot. I did some guesswork on the flash initialization to make it build with Laurent's -disk patch. Please check if it is still correct. works fine. Note that both chips get mapped at the same offset in phys_ram_base, I'm quite sure this is a bug and not intentional? It may corrupt data if the OS reads from both chips. I wanted to convert mainstone.c to use qemu_ram_alloc like other pxa boards but I want to make sure this is not intentional. The value of mainstone_rom indicates this too. Sorry, mainstone_rom is not related to this issue, but that means that the ram_size check allows too low values and qemu may crash. It also means that the two flash chips *and* the ROM all overlap. I think gumstix.c registers the flash correctly, you may wnat to look in it. Regards will do. I seem to remember that the two mappings are mutually exclusive and possible controlled by an external switch.. I will need to double check that. sorry for the trouble. -Armin
Re: [Qemu-devel] [Patch][update] Mainstone re-org plus flash
On 10/12/2007, andrzej zaborowski <[EMAIL PROTECTED]> wrote: > On 02/12/2007, Armin <[EMAIL PROTECTED]> wrote: > > Thiemo, > > > > Thiemo Seufer wrote: > > > Armin wrote: > > > > > >> Hello, > > >> > > >> This includes the previous Mainstone re-org patch I sent earlier plus > > >> flash > > >> support. > > >> This adds two 32MiB flash devices. Mounts from mtdblock2 on flash device > > >> 0 > > >> fine at boot. > > >> > > > > > > I did some guesswork on the flash initialization to make it build with > > > Laurent's -disk patch. Please check if it is still correct. > > > > > > > works fine. > > Note that both chips get mapped at the same offset in phys_ram_base, > I'm quite sure this is a bug and not intentional? It may corrupt data > if the OS reads from both chips. I wanted to convert mainstone.c to > use qemu_ram_alloc like other pxa boards but I want to make sure this > is not intentional. > > The value of mainstone_rom indicates this too. Sorry, mainstone_rom is not related to this issue, but that means that the ram_size check allows too low values and qemu may crash. It also means that the two flash chips *and* the ROM all overlap. I think gumstix.c registers the flash correctly, you may wnat to look in it. Regards
[Qemu-devel] [PATCH] sparc32 add SPARCstation 20 machine type
Index: vl.c
===
RCS file: /sources/qemu/qemu/vl.c,v
retrieving revision 1.377
diff -p -u -r1.377 vl.c
--- vl.c6 Dec 2007 22:11:20 - 1.377
+++ vl.c10 Dec 2007 01:17:59 -
@@ -7838,6 +7838,7 @@ static void register_machines(void)
qemu_register_machine(&ss5_machine);
qemu_register_machine(&ss10_machine);
qemu_register_machine(&ss600mp_machine);
+qemu_register_machine(&ss20_machine);
#endif
#elif defined(TARGET_ARM)
qemu_register_machine(&integratorcp_machine);
Index: hw/boards.h
===
RCS file: /sources/qemu/qemu/hw/boards.h,v
retrieving revision 1.4
diff -p -u -r1.4 boards.h
--- hw/boards.h 25 Nov 2007 01:57:38 - 1.4
+++ hw/boards.h 10 Dec 2007 01:17:59 -
@@ -52,7 +52,7 @@ extern QEMUMachine shix_machine;
extern QEMUMachine r2d_machine;
/* sun4m.c */
-extern QEMUMachine ss5_machine, ss10_machine, ss600mp_machine;
+extern QEMUMachine ss5_machine, ss10_machine, ss600mp_machine, ss20_machine;
/* sun4u.c */
extern QEMUMachine sun4u_machine;
Index: hw/sun4m.c
===
RCS file: /sources/qemu/qemu/hw/sun4m.c,v
retrieving revision 1.68
diff -p -u -r1.68 sun4m.c
--- hw/sun4m.c 9 Dec 2007 17:03:50 - 1.68
+++ hw/sun4m.c 10 Dec 2007 01:17:59 -
@@ -600,6 +600,44 @@ static const struct hwdef hwdefs[] = {
.max_mem = 0x, // XXX actually first 62GB ok
.default_cpu_model = "TI SuperSparc II",
},
+/* SS-20 */
+{
+.iommu_base = 0xfe000ULL,
+.tcx_base = 0xe2000ULL,
+.cs_base = -1,
+.slavio_base = 0xff000ULL,
+.ms_kb_base = 0xff100ULL,
+.serial_base = 0xff110ULL,
+.nvram_base = 0xff120ULL,
+.fd_base = 0xff170ULL,
+.counter_base = 0xff130ULL,
+.intctl_base = 0xff140ULL,
+.dma_base = 0xef040ULL,
+.esp_base = 0xef080ULL,
+.le_base = 0xef0c0ULL,
+.power_base = 0xefa00ULL,
+.ecc_base = 0xfULL,
+.ecc_version = 0x2000, // version 0, implementation 2
+.vram_size= 0x0010,
+.nvram_size = 0x2000,
+.esp_irq = 18,
+.le_irq = 16,
+.clock_irq = 7,
+.clock1_irq = 19,
+.ms_kb_irq = 14,
+.ser_irq = 15,
+.fd_irq = 22,
+.me_irq = 30,
+.cs_irq = -1,
+.machine_id = 0x72,
+.iommu_version = 0x1300,
+.intbit_to_level = {
+2, 3, 5, 7, 9, 11, 0, 14, 3, 5, 7, 9, 11, 13, 12, 12,
+6, 0, 4, 10, 8, 0, 11, 0, 0, 0, 0, 0, 15, 0, 15, 0,
+},
+.max_mem = 0x, // XXX actually first 62GB ok
+.default_cpu_model = "TI SuperSparc II",
+},
};
/* SPARCstation 5 hardware initialisation */
@@ -632,6 +670,16 @@ static void ss600mp_init(int RAM_size, i
kernel_cmdline, initrd_filename, cpu_model);
}
+/* SPARCstation 20 hardware initialisation */
+static void ss20_init(int RAM_size, int vga_ram_size,
+ const char *boot_device, DisplayState *ds,
+ const char *kernel_filename, const char *kernel_cmdline,
+ const char *initrd_filename, const char *cpu_model)
+{
+sun4m_hw_init(&hwdefs[3], RAM_size, boot_device, ds, kernel_filename,
+ kernel_cmdline, initrd_filename, cpu_model);
+}
+
QEMUMachine ss5_machine = {
"SS-5",
"Sun4m platform, SPARCstation 5",
@@ -649,3 +697,10 @@ QEMUMachine ss600mp_machine = {
"Sun4m platform, SPARCserver 600MP",
ss600mp_init,
};
+
+QEMUMachine ss20_machine = {
+"SS-20",
+"Sun4m platform, SPARCstation 20",
+ss20_init,
+};
+
[Qemu-devel] qemu/hw flash.h omap.c pflash_cfi02.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Andrzej Zaborowski 07/12/10 01:07:47 Modified files: hw : flash.h omap.c pflash_cfi02.c Log message: Fix OMAP1 MPUI/O keyboard interrupt masking. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/hw/flash.h?cvsroot=qemu&r1=1.3&r2=1.4 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/omap.c?cvsroot=qemu&r1=1.32&r2=1.33 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/pflash_cfi02.c?cvsroot=qemu&r1=1.10&r2=1.11
[Qemu-devel] qemu/hw flash.h
CVSROOT:/sources/qemu Module name:qemu Changes by: Andrzej Zaborowski 07/12/10 00:33:13 Modified files: hw : flash.h Log message: Fix incompatible declaration in previous commit. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/hw/flash.h?cvsroot=qemu&r1=1.2&r2=1.3
[Qemu-devel] qemu/hw flash.h gumstix.c mainstone.c pflash_cf...
CVSROOT:/sources/qemu Module name:qemu Changes by: Andrzej Zaborowski 07/12/10 00:28:27 Modified files: hw : flash.h gumstix.c mainstone.c pflash_cfi01.c pflash_cfi02.c ppc405_boards.c Log message: Desambiguate pflash_register(). pflash_t is still ambiguous... perhaps both emulations should sit in a single file. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/hw/flash.h?cvsroot=qemu&r1=1.1&r2=1.2 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/gumstix.c?cvsroot=qemu&r1=1.7&r2=1.8 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/mainstone.c?cvsroot=qemu&r1=1.6&r2=1.7 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/pflash_cfi01.c?cvsroot=qemu&r1=1.3&r2=1.4 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/pflash_cfi02.c?cvsroot=qemu&r1=1.9&r2=1.10 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/ppc405_boards.c?cvsroot=qemu&r1=1.11&r2=1.12
Re: [Qemu-devel] [Patch][update] Mainstone re-org plus flash
On 02/12/2007, Armin <[EMAIL PROTECTED]> wrote: > Thiemo, > > Thiemo Seufer wrote: > > Armin wrote: > > > >> Hello, > >> > >> This includes the previous Mainstone re-org patch I sent earlier plus flash > >> support. > >> This adds two 32MiB flash devices. Mounts from mtdblock2 on flash device 0 > >> fine at boot. > >> > > > > I did some guesswork on the flash initialization to make it build with > > Laurent's -disk patch. Please check if it is still correct. > > > > works fine. Note that both chips get mapped at the same offset in phys_ram_base, I'm quite sure this is a bug and not intentional? It may corrupt data if the OS reads from both chips. I wanted to convert mainstone.c to use qemu_ram_alloc like other pxa boards but I want to make sure this is not intentional. The value of mainstone_rom indicates this too. Regards
Re: [Qemu-devel] saving/loading PCI irq related state
Hi, On 27/11/2007, Uri Lublin <[EMAIL PROTECTED]> wrote: > Hello, > > If one is not lucky he/she may lose PCI interrupts when saving and > loading a VM. > It seems PCI irq related state is not being saved. > When this happens, the guest hangs/spins and the cpu usage of the > process stays around 100%. > > Attached are three patches to fix this: >01 -- when saving/loading a pci device, save/load its irq_state >02 -- save/load PCI-Bus irq related state >03 -- save/load PCI-bridge (i440FX/PIIX3) irq related state > > There are two alternatives, both recalculate PCI irq related state upon > loadvm instead of saving/loading it: > (a) Make every PCI device DEV (e.g. rtl8139, ne2000, usb-uhci, etc) call > its DEV_update_irq() from its state-load-function. or > (b) Keep patch 01 and recalculate 02 and 03 by going over all > PCI-devices on the specific Bus/Bridge. I committed the three patches together but I changed the put/get functions used to ones that don't assume on sizeof(int) == 4. Compile tested only, please check if I've not screwed this up. Regards
[Qemu-devel] qemu/hw pci.c piix_pci.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Andrzej Zaborowski 07/12/09 23:56:13 Modified files: hw : pci.c piix_pci.c Log message: Save/load PCI-device, PCI-bus and PIIX3 irq-related state (patches by Uri Lublin. Note that other PCI bridges are not fixed here. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/hw/pci.c?cvsroot=qemu&r1=1.43&r2=1.44 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/piix_pci.c?cvsroot=qemu&r1=1.15&r2=1.16
[Qemu-devel] qemu/target-i386 helper.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Andrzej Zaborowski 07/12/09 23:39:23 Modified files: target-i386: helper.c Log message: Make SVM IOIO intercept check all needed bits, by Bernhard Kauer. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/target-i386/helper.c?cvsroot=qemu&r1=1.96&r2=1.97
[Qemu-devel] qemu/target-i386 exec.h helper.c op.c translate.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Andrzej Zaborowski 07/12/09 23:35:28 Modified files: target-i386: exec.h helper.c op.c translate.c Log message: Add rdpmc SVM intercept, by Bernhard Kauer. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/target-i386/exec.h?cvsroot=qemu&r1=1.39&r2=1.40 http://cvs.savannah.gnu.org/viewcvs/qemu/target-i386/helper.c?cvsroot=qemu&r1=1.95&r2=1.96 http://cvs.savannah.gnu.org/viewcvs/qemu/target-i386/op.c?cvsroot=qemu&r1=1.51&r2=1.52 http://cvs.savannah.gnu.org/viewcvs/qemu/target-i386/translate.c?cvsroot=qemu&r1=1.74&r2=1.75
[Qemu-devel] qemu/hw mainstone.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Andrzej Zaborowski 07/12/09 23:29:35 Modified files: hw : mainstone.c Log message: No write-protect detect diode on Mainstone II. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/hw/mainstone.c?cvsroot=qemu&r1=1.5&r2=1.6
[Qemu-devel] qemu/hw omap.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Andrzej Zaborowski 07/12/09 23:23:02 Modified files: hw : omap.c Log message: Use pointers to channels rather than channel numbers in the DMA. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/hw/omap.c?cvsroot=qemu&r1=1.31&r2=1.32
Re: [Qemu-devel] [PATCH 0/2] Real SCSI device passthrough
Laurent Vivier wrote: > > This series of patches allows to connect real SCSI device to the virtual > SCSI controller of Qemu using the SCSI Generic interface (/dev/sg) > > for instance: > > qemu -hda my_disk.qcow2 -drive file=/dev/sg3,if=scsi Please update also the documentation to mention this example. > [PATCH 1/2] SCSI cleanup > > This patch reworks the interface between SCSI controller and SCSI device. > > [PATCH 2/2] Real SCSI device passthrough (v3) > > This patch allows to connect the virtual SCSI interface of Qemu to > a real SCSI device of the host. > > Laurent > > > >
[Qemu-devel] qemu/linux-user syscall.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer 07/12/09 23:12:56 Modified files: linux-user : syscall.c Log message: Fix execve argc/envc counting, by Takashi Yoshii. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/syscall.c?cvsroot=qemu&r1=1.156&r2=1.157
[Qemu-devel] qemu/hw piix_pci.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer 07/12/09 23:02:39 Modified files: hw : piix_pci.c Log message: Remove leftover support for 82371FB (Step A1), by Carlo Marcelo Arenas Belon. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/hw/piix_pci.c?cvsroot=qemu&r1=1.14&r2=1.15
[Qemu-devel] qemu/hw omap.c omap.h
CVSROOT:/sources/qemu Module name:qemu Changes by: Andrzej Zaborowski 07/12/09 22:32:42 Modified files: hw : omap.c omap.h Log message: OMAP DMA 3.2 support by Lauro Ramos Venancio. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/hw/omap.c?cvsroot=qemu&r1=1.30&r2=1.31 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/omap.h?cvsroot=qemu&r1=1.20&r2=1.21
[Qemu-devel] [PATCH] linux-user, Fix execve argc/envc counting.
In execve code for linux-user emulation, address increment steps seems to be
wrong when counting argc/envc.
/yoshii
Index: linux-user/syscall.c
===
RCS file: /sources/qemu/qemu/linux-user/syscall.c,v
retrieving revision 1.156
diff -u -p -r1.156 syscall.c
--- a/linux-user/syscall.c 9 Dec 2007 02:37:05 - 1.156
+++ b/linux-user/syscall.c 9 Dec 2007 20:44:05 -
@@ -3190,7 +3189,7 @@ abi_long do_syscall(void *cpu_env, int n
argc = 0;
guest_argp = arg2;
-for (gp = guest_argp; ; gp++) {
+for (gp = guest_argp; ; gp += sizeof(abi_ulong)) {
if (get_user_ual(addr, gp))
goto efault;
if (!addr)
@@ -3199,7 +3198,7 @@ abi_long do_syscall(void *cpu_env, int n
}
envc = 0;
guest_envp = arg3;
-for (gp = guest_envp; ; gp++) {
+for (gp = guest_envp; ; gp += sizeof(abi_ulong)) {
if (get_user_ual(addr, gp))
goto efault;
if (!addr)
[Qemu-devel] [PATCH] sparc32 add a few more ASI
diff -p -u -r1.60 op_helper.c --- target-sparc/op_helper.c28 Nov 2007 18:08:28 - 1.60 +++ target-sparc/op_helper.c9 Dec 2007 20:33:02 - @@ -411,6 +411,9 @@ void helper_ld_asi(int asi, int size, in break; } break; +case 0x39: /* data cache diagnostic register */ +ret = 0; +break; case 0x21 ... 0x2d: /* MMU passthrough, unassigned */ default: do_unassigned_access(T0, 0, 0, 1); @@ -703,9 +706,13 @@ void helper_st_asi(int asi, int size) } } return; -case 0x31: /* Ross RT620 I-cache flush */ +case 0x30: /* store buffer tags */ +case 0x31: /* store buffer data or Ross RT620 I-cache flush */ +case 0x32: /* store buffer control */ case 0x36: /* I-cache flash clear */ case 0x37: /* D-cache flash clear */ +case 0x38: /* breakpoint diagnostics */ +case 0x4c: /* breakpoint action */ break; case 9: /* Supervisor code access, XXX */ case 0x21 ... 0x2d: /* MMU passthrough, unassigned */
Re: [Qemu-devel] [PATCH] Allow setting the vendor_id string with x86's -cpu option
On Sun, Dec 09, 2007 at 08:58:34PM +0200, Dan Kenigsberg wrote: > On Sun, Dec 09, 2007 at 07:29:49PM +0100, Andreas Schwab wrote: > > Dan Kenigsberg <[EMAIL PROTECTED]> writes: > > > > > +x86_cpu_def->vendor1 = val[0] + (val[1] << 8) > > > + + (val[2] << 16) + (val[3] << 24); > > > +x86_cpu_def->vendor2 = val[4] + (val[5] << 8) > > > + + (val[6] << 16) + (val[7] << 24); > > > +x86_cpu_def->vendor3 = val[8] + (val[9] << 8) > > > + + (val[10] << 16) + (val[11] << 24); > > > > That will do the wrong thing with the sign bit. > > > > Please tell me when I'm done making a fool of myself. > Apparently, I was not done. So I'll just shut up now. Sorry for the noise. Dan.
Re: [Qemu-devel] [PATCH] Allow setting the vendor_id string with x86's -cpu option
On Sun, Dec 09, 2007 at 07:29:49PM +0100, Andreas Schwab wrote:
> Dan Kenigsberg <[EMAIL PROTECTED]> writes:
>
> > +x86_cpu_def->vendor1 = val[0] + (val[1] << 8)
> > + + (val[2] << 16) + (val[3] << 24);
> > +x86_cpu_def->vendor2 = val[4] + (val[5] << 8)
> > + + (val[6] << 16) + (val[7] << 24);
> > +x86_cpu_def->vendor3 = val[8] + (val[9] << 8)
> > + + (val[10] << 16) + (val[11] << 24);
>
> That will do the wrong thing with the sign bit.
>
Please tell me when I'm done making a fool of myself.
diff --git a/target-i386/helper2.c b/target-i386/helper2.c
index 67658e2..98c03cc 100644
--- a/target-i386/helper2.c
+++ b/target-i386/helper2.c
@@ -254,6 +254,18 @@ static int cpu_x86_find_by_name(x86_def_t *x86_cpu_def,
const char *cpu_model)
goto error;
}
x86_cpu_def->stepping = stepping;
+} else if (!strcmp(featurestr, "vendor")) {
+if (strlen(val) != 12) {
+fprintf(stderr, "vendor string must be 12 chars long\n");
+x86_cpu_def = 0;
+goto error;
+}
+x86_cpu_def->vendor1 = val[0] ^ (val[1] << 8)
+ ^ (val[2] << 16) ^ (val[3] << 24);
+x86_cpu_def->vendor2 = val[4] ^ (val[5] << 8)
+ ^ (val[6] << 16) ^ (val[7] << 24);
+x86_cpu_def->vendor3 = val[8] ^ (val[9] << 8)
+ ^ (val[10] << 16) ^ (val[11] << 24);
} else {
fprintf(stderr, "unrecognized feature %s\n", featurestr);
x86_cpu_def = 0;
Re: [Qemu-devel] [PATCH] Allow setting the vendor_id string with x86's -cpu option
Dan Kenigsberg <[EMAIL PROTECTED]> writes: > +x86_cpu_def->vendor1 = val[0] + (val[1] << 8) > + + (val[2] << 16) + (val[3] << 24); > +x86_cpu_def->vendor2 = val[4] + (val[5] << 8) > + + (val[6] << 16) + (val[7] << 24); > +x86_cpu_def->vendor3 = val[8] + (val[9] << 8) > + + (val[10] << 16) + (val[11] << 24); That will do the wrong thing with the sign bit. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: [Qemu-devel] [PATCH] OSX x86_64 host support
Hi, On Dec 9, 2007, at 5:52 PM, Mike Kronenberg wrote: Hi from Q, Yes we have a OpenGL, CG and in dev a Core Animation version for vga output. Quickdraw is depreciated since Tiger. But as QEMU has never added gcc4 to the tool-chain, there was never a official running version on any Intel machine :) There still isn't. Sadly there have been no comments on my x86_64 darwin patch, but that one seems to be the least intrusive and fastest intel mac qemu patch I've seen so far. Our OpenGL and CG implementation offer fullscreen and tablet support as-well. Fullscreen is very slow on the CG implementation, but was speeded up by Core-Animation. I'd going with the OpenGL implementation, if the "true" opengl implementation for QEMU was coming ;). Else the partial screen-redrawing of CG is faster than OpenGL. My CG implementation is a mere "hack". There is no partion screen- redraw, as I push the full CGImage contents to the context on every repaint. So any of these sound way better. On the other hand, the QT implementation is and remains the fastest solution, as no of the other allows directly accessing the video- buffer, which results in way more copying. I thought CG allows for storing images on the video card's buffer as well? At least that's what I've read somewhere in the Apple documentation. If there is need for back-porting any of this stuff, that would be no problem. Everything is better than what there is right now. Currently qemu is ppc 32-bit only with (maybe) 10.5 being the last supported version, as I personally believe that Apple will remove QuickDraw in 10.6. So I'm fine with whatever you feel like worth backporting. I'm not in a position to decide on what to do, don't know who is either though. So if anyone with commit rights feels interested in Mac OS X Host support, I'd love to hear some words on this. For the new Q front-end, we are going with a CG approach only, but we bypass cocoa.m altogether and mmap (shmem allows only 4mb on OS X) everything to the viewer app. Mike Cheers, Alex
Re: [Qemu-devel] [PATCH] sparc32 sun4m eccmemctl
On 12/9/07, Robert Reif <[EMAIL PROTECTED]> wrote: > This patch adds sparc32 sun4m SMP ECC memory controller support. Thanks, applied. I just moved the ecc_base after the other bases. > Three files are attached: > > The first is a diff to existing code. > The second is a diff for the new eccmemctl.c. Please use same level diff for all, this was suitable for patch -p1 and the first one for patch -p0. I'd recommend using quilt (or maybe git) for patch management, it will make your life easier. > The third is the openboot outputs for the 3 systems that support this chip. > > This patch is necessary for using sun openboot prom images because they > expect the device to be present and will fault when it's not there. > > A prom node will need to be added to openbios for this chip. Thanks, I used these attributes to define the node, mc-type is probed from the device. It seems that Linux and OpenBSD don't care about this device but NetBSD driver at least reads and prints the version.
Re: [Qemu-devel] [Patch][Pxa2xx] Mainstone mmc support
Andrzej, andrzej zaborowski wrote: On 08/12/2007, Armin <[EMAIL PROTECTED]> wrote: Hello, Please consider this patch for inclusion. This adds MMC and the rest of the FPGA irq definitions for the Mainstone II Why are both the write-protect and card-detect signals being connected to one input? If one of the inputs doesn't exist then just pass NULL for the parameter, The write protect does not exist so I will change it to a "NULL" thanks, - Armin
[Qemu-devel] qemu Makefile.target hw/sun4m.c hw/sun4m.h hw/e...
CVSROOT:/cvsroot/qemu Module name:qemu Changes by: Blue Swirl 07/12/09 17:03:50 Modified files: . : Makefile.target hw : sun4m.c sun4m.h Added files: hw : eccmemctl.c Log message: Add support for eccmemctl (Robert Reif) CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/Makefile.target?cvsroot=qemu&r1=1.230&r2=1.231 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/sun4m.c?cvsroot=qemu&r1=1.67&r2=1.68 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/sun4m.h?cvsroot=qemu&r1=1.3&r2=1.4 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/eccmemctl.c?cvsroot=qemu&rev=1.1
Re: [Qemu-devel] [PATCH] OSX x86_64 host support
Hi from Q, Yes we have a OpenGL, CG and in dev a Core Animation version for vga output. Quickdraw is depreciated since Tiger. But as QEMU has never added gcc4 to the tool-chain, there was never a official running version on any Intel machine :) Our OpenGL and CG implementation offer fullscreen and tablet support as-well. Fullscreen is very slow on the CG implementation, but was speeded up by Core-Animation. I'd going with the OpenGL implementation, if the "true" opengl implementation for QEMU was coming ;). Else the partial screen-redrawing of CG is faster than OpenGL. On the other hand, the QT implementation is and remains the fastest solution, as no of the other allows directly accessing the video- buffer, which results in way more copying. If there is need for back-porting any of this stuff, that would be no problem. For the new Q front-end, we are going with a CG approach only, but we bypass cocoa.m altogether and mmap (shmem allows only 4mb on OS X) everything to the viewer app. Mike On 07.12.2007, at 21:19, Andreas Färber wrote: Am 07.12.2007 um 21:12 schrieb Alexander Graf: On Dec 7, 2007, at 6:43 PM, Pierre d'Herbemont wrote: On Dec 7, 2007, at 1:42 PM, Alexander Graf wrote: Right now there is no graphical output available except for VNC, as the cocoa output depends on deprecated APIs that are no longer available in 64-bit mode and SDL does not compile on x86_64 Darwin yet. This is the QuickDraw API? If so, it should be quite straight forward to use OpenGL or CoreGraphics instead... What about not disabling Cocoa, and simply print a nice #error or #warning that explains that the quickdraw part needs fixing? Pierre. Yes, it's the QuickDraw API. I'm currently looking into this, so if you know anything about the transition to CoreGraphics, please let me know or point me to some documentation on that. I'd rather have a proper patch for the cocoa output than anything else. Disabling it is only a temporary workaround to have it build at all. Doesn't Q offer all three? I'm pretty sure I've been using its OpenGL option with success. Andreas Cheers, Alex smime.p7s Description: S/MIME cryptographic signature
[Qemu-devel] [PATCH] sparc32 sun4m eccmemctl
This patch adds sparc32 sun4m SMP ECC memory controller support.
Three files are attached:
The first is a diff to existing code.
The second is a diff for the new eccmemctl.c.
The third is the openboot outputs for the 3 systems that support this chip.
This patch is necessary for using sun openboot prom images because they
expect the device to be present and will fault when it's not there.
A prom node will need to be added to openbios for this chip.
Index: Makefile.target
===
RCS file: /sources/qemu/qemu/Makefile.target,v
retrieving revision 1.230
diff -p -u -r1.230 Makefile.target
--- Makefile.target 2 Dec 2007 02:20:02 - 1.230
+++ Makefile.target 9 Dec 2007 14:03:20 -
@@ -482,7 +482,7 @@ VL_OBJS+= cirrus_vga.o parallel.o ptimer
else
VL_OBJS+= sun4m.o tcx.o pcnet.o iommu.o m48t59.o slavio_intctl.o
VL_OBJS+= slavio_timer.o slavio_serial.o slavio_misc.o fdc.o esp.o
sparc32_dma.o
-VL_OBJS+= cs4231.o ptimer.o
+VL_OBJS+= cs4231.o ptimer.o eccmemctl.o
endif
endif
ifeq ($(TARGET_BASE_ARCH), arm)
Index: hw/sun4m.c
===
RCS file: /sources/qemu/qemu/hw/sun4m.c,v
retrieving revision 1.67
diff -p -u -r1.67 sun4m.c
--- hw/sun4m.c 4 Dec 2007 20:58:31 - 1.67
+++ hw/sun4m.c 9 Dec 2007 14:03:24 -
@@ -82,6 +82,8 @@ struct hwdef {
uint32_t intbit_to_level[32];
uint64_t max_mem;
const char * const default_cpu_model;
+target_phys_addr_t ecc_base;
+uint32_t ecc_version;
};
/* TSC handling */
@@ -479,6 +481,9 @@ static void sun4m_hw_init(const struct h
nvram_init(nvram, (uint8_t *)&nd_table[0].macaddr, kernel_cmdline,
boot_device, RAM_size, kernel_size, graphic_width,
graphic_height, graphic_depth, hwdef->machine_id);
+
+if (hwdef->ecc_base != (target_phys_addr_t)-1)
+ecc_init(hwdef->ecc_base, hwdef->ecc_version);
}
static const struct hwdef hwdefs[] = {
@@ -517,6 +522,7 @@ static const struct hwdef hwdefs[] = {
},
.max_mem = 0x1000,
.default_cpu_model = "Fujitsu MB86904",
+.ecc_base = -1,
},
/* SS-10 */
{
@@ -553,6 +559,8 @@ static const struct hwdef hwdefs[] = {
},
.max_mem = 0x, // XXX actually first 62GB ok
.default_cpu_model = "TI SuperSparc II",
+.ecc_base = 0xfULL,
+.ecc_version = 0x1000, // version 0, implementation 1
},
/* SS-600MP */
{
@@ -589,6 +597,8 @@ static const struct hwdef hwdefs[] = {
},
.max_mem = 0x, // XXX actually first 62GB ok
.default_cpu_model = "TI SuperSparc II",
+.ecc_base = 0xfULL,
+.ecc_version = 0x, // version 0, implementation 0
},
};
Index: hw/sun4m.h
===
RCS file: /sources/qemu/qemu/hw/sun4m.h,v
retrieving revision 1.3
diff -p -u -r1.3 sun4m.h
--- hw/sun4m.h 4 Dec 2007 20:58:31 - 1.3
+++ hw/sun4m.h 9 Dec 2007 14:03:24 -
@@ -72,4 +72,7 @@ void espdma_memory_write(void *opaque, u
void lance_init(NICInfo *nd, target_phys_addr_t leaddr, void *dma_opaque,
qemu_irq irq, qemu_irq *reset);
+/* eccmemctl.c */
+void *ecc_init(target_phys_addr_t base, uint32_t version);
+
#endif
--- qemu/hw/eccmemctl.c 1969-12-31 19:00:00.0 -0500
+++ qemu.ecc/hw/eccmemctl.c 2007-12-09 09:12:16.0 -0500
@@ -0,0 +1,266 @@
+/*
+ * QEMU Sparc Sun4m ECC memory controller emulation
+ *
+ * Copyright (c) 2007 Robert Reif
+ *
+ * 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 "sun4m.h"
+#include "sysemu.h"
+
+//#define DEBUG_ECC
+
+#ifdef DEBUG_ECC
+#define DPRINTF(fmt, args...) \
+do { printf("ECC: " fmt , ##args); } while (0)
+#else
+#define DPRINTF(fmt, args...)
+#endif
+
+/
Re: [Qemu-devel] [PATCH] Allow setting the vendor_id string with x86's -cpu option
On Sun, Dec 09, 2007 at 11:36:34AM +, Paul Brook wrote:
> > +x86_cpu_def->vendor1 = cpu_to_le32(*(uint32_t *)val);
> > +x86_cpu_def->vendor2 = cpu_to_le32(*(uint32_t *)(val +
> > 4)); +x86_cpu_def->vendor3 = cpu_to_le32(*(uint32_t *)(val
>
> Still not good enough. val might not be aligned.
>
So, is it that my only hope is going back to basics?
diff --git a/target-i386/helper2.c b/target-i386/helper2.c
index 67658e2..2ef4be3 100644
--- a/target-i386/helper2.c
+++ b/target-i386/helper2.c
@@ -254,6 +254,18 @@ static int cpu_x86_find_by_name(x86_def_t *x86_cpu_def,
const char *cpu_model)
goto error;
}
x86_cpu_def->stepping = stepping;
+} else if (!strcmp(featurestr, "vendor")) {
+if (strlen(val) != 12) {
+fprintf(stderr, "vendor string must be 12 chars long\n");
+x86_cpu_def = 0;
+goto error;
+}
+x86_cpu_def->vendor1 = val[0] + (val[1] << 8)
+ + (val[2] << 16) + (val[3] << 24);
+x86_cpu_def->vendor2 = val[4] + (val[5] << 8)
+ + (val[6] << 16) + (val[7] << 24);
+x86_cpu_def->vendor3 = val[8] + (val[9] << 8)
+ + (val[10] << 16) + (val[11] << 24);
} else {
fprintf(stderr, "unrecognized feature %s\n", featurestr);
x86_cpu_def = 0;
Re: [Qemu-devel] [PATCH] Allow setting the vendor_id string with x86's -cpu option
> +x86_cpu_def->vendor1 = cpu_to_le32(*(uint32_t *)val); > +x86_cpu_def->vendor2 = cpu_to_le32(*(uint32_t *)(val + > 4)); +x86_cpu_def->vendor3 = cpu_to_le32(*(uint32_t *)(val Still not good enough. val might not be aligned. Paul
Re: [Qemu-devel] [PATCH] Allow setting the vendor_id string with x86's -cpu option
On Sun, Dec 09, 2007 at 03:02:44AM +, Thiemo Seufer wrote:
> Dan Kenigsberg wrote:
> > Having AuthenticAMD hard-coded is nice, but allowing the user to impersonate
> > whatever CPU she wants is even nicer.
> >
> > Also, an English typo (due to me) is corrected.
> >
> > Dan.
> >
> > --- a/target-i386/helper2.c
> > +++ b/target-i386/helper2.c
> > @@ -254,8 +254,17 @@ static int cpu_x86_find_by_name(x86_def_t
> > *x86_cpu_def, const char *cpu_model)
> > goto error;
> > }
> > x86_cpu_def->stepping = stepping;
> > +} else if (!strcmp(featurestr, "vendor")) {
> > +if (strlen(val) != 12) {
> > +fprintf(stderr, "vendor string must be 12 chars
> > long\n");
> > +x86_cpu_def = 0;
> > +goto error;
> > +}
> > +x86_cpu_def->vendor1 = *(uint32_t *)val;
> > +x86_cpu_def->vendor2 = *(uint32_t *)(val + 4);
> > +x86_cpu_def->vendor3 = *(uint32_t *)(val + 8);
>
> Endianness bug.
>
Indeed. Please consider the following:
diff --git a/target-i386/helper2.c b/target-i386/helper2.c
index 67658e2..6109283 100644
--- a/target-i386/helper2.c
+++ b/target-i386/helper2.c
@@ -254,6 +254,15 @@ static int cpu_x86_find_by_name(x86_def_t *x86_cpu_def,
const char *cpu_model)
goto error;
}
x86_cpu_def->stepping = stepping;
+} else if (!strcmp(featurestr, "vendor")) {
+if (strlen(val) != 12) {
+fprintf(stderr, "vendor string must be 12 chars long\n");
+x86_cpu_def = 0;
+goto error;
+}
+x86_cpu_def->vendor1 = cpu_to_le32(*(uint32_t *)val);
+x86_cpu_def->vendor2 = cpu_to_le32(*(uint32_t *)(val + 4));
+x86_cpu_def->vendor3 = cpu_to_le32(*(uint32_t *)(val + 8));
} else {
fprintf(stderr, "unrecognized feature %s\n", featurestr);
x86_cpu_def = 0;
Re: [Qemu-devel] [security bug]code_gen_buffer can be overflowed
On 12/1/07, Blue Swirl <[EMAIL PROTECTED]> wrote: > On 12/1/07, TeLeMan <[EMAIL PROTECTED]> wrote: > > > > > > Blue Swirl-2 wrote: > > > > > > On 11/28/07, TeLeMan <[EMAIL PROTECTED]> wrote: > > >> > > >> dyngen_code() can generate more than CODE_GEN_MAX_SIZE bytes, > > >> code_gen_buffer > > >> can be overflowed. I hope this security bug will be fixed soon. > > > > > > Thank you for the analysis. It's true that cpu_gen_code does not pass > > > CODE_GEN_MAX_SIZE (65536) on to gen_intermediate_code and that should > > > be fixed. But gen_intermediate_code can only add OPC_MAX_SIZE (512 - > > > 32) instructions more, so there is no security bug. > > > > > > > > > > This POC is a windows exe and was tested on QEMU v0.9.0 (Guest OS is Windows > > XP SP2). > > This overflow will overwrite the TranslationBlock buffer. > > > > http://www.nabble.com/file/p14101223/qemu-dos.rar qemu-dos.rar > > I see my error, gen_intermediate_code produces ops, not host > instructions. For each op several host instructions are generated, for > Sparc32 maximum on my machine is 170 but for ARM this can be 840. In > the worst case, (512 - 32) * 840 = 403200 bytes are generated, thus a > buffer overflow is indeed possible. > > I can see a few possible fixes for this. > > The buffer size can be increased from 64k to 512k or the buffer can be > allocated dynamically after calculating the maximum instruction size. > > OPC_BUF_SIZE can be decreased from 512 to 50. > > All ops can be made smaller by introducing more helpers. > > dyngen_code loop could check for buffer size. Actually the buffer size is OK, but the safety margin was not large enough. In this patch the margin is calculated from maximum block size. GCC could calculate the maximum on compile time, but it doesn't, so the code is not optimal. Any suggestions for more advanced CPP magic to calculate the maximum of a list of constants? The patch works for Sparc target on x86_64 host. I didn't test other combinations, so especially ARM target on RISC hosts with larger generated code (ia64?) and/or smaller CODE_GEN_BUFFER_SIZE (alpha) should be checked. The maximum should not exceed the buffer size or no code can be generated. In that case, also OPC_BUF_SIZE should be decreased. Because of the security aspects, I think it's better to commit this pretty soon and not wait for the confirmation for all host/target combinations. If some combination happens to break, it can be fixed quickly. Index: qemu/cpu-exec.c === --- qemu.orig/cpu-exec.c 2007-12-09 07:30:36.0 + +++ qemu/cpu-exec.c 2007-12-09 07:32:56.0 + @@ -133,7 +133,7 @@ tb->tc_ptr = tc_ptr; tb->cs_base = cs_base; tb->flags = flags; -cpu_gen_code(env, tb, CODE_GEN_MAX_SIZE, &code_gen_size); +cpu_gen_code(env, tb, &code_gen_size); code_gen_ptr = (void *)(((unsigned long)code_gen_ptr + code_gen_size + CODE_GEN_ALIGN - 1) & ~(CODE_GEN_ALIGN - 1)); /* check next page if needed */ Index: qemu/exec-all.h === --- qemu.orig/exec-all.h 2007-12-09 07:14:24.0 + +++ qemu/exec-all.h 2007-12-09 08:03:57.0 + @@ -64,8 +64,9 @@ int gen_intermediate_code(CPUState *env, struct TranslationBlock *tb); int gen_intermediate_code_pc(CPUState *env, struct TranslationBlock *tb); void dump_ops(const uint16_t *opc_buf, const uint32_t *opparam_buf); +unsigned long code_gen_max_block_size(void); int cpu_gen_code(CPUState *env, struct TranslationBlock *tb, - int max_code_size, int *gen_code_size_ptr); + int *gen_code_size_ptr); int cpu_restore_state(struct TranslationBlock *tb, CPUState *env, unsigned long searched_pc, void *puc); @@ -94,7 +95,6 @@ return tlb_set_page_exec(env, vaddr, paddr, prot, mmu_idx, is_softmmu); } -#define CODE_GEN_MAX_SIZE65536 #define CODE_GEN_ALIGN 16 /* must be >= of the size of a icache line */ #define CODE_GEN_PHYS_HASH_BITS 15 Index: qemu/exec.c === --- qemu.orig/exec.c 2007-12-09 07:13:43.0 + +++ qemu/exec.c 2007-12-09 07:58:53.0 + @@ -56,7 +56,7 @@ #endif /* threshold to flush the translated code buffer */ -#define CODE_GEN_BUFFER_MAX_SIZE (CODE_GEN_BUFFER_SIZE - CODE_GEN_MAX_SIZE) +#define CODE_GEN_BUFFER_MAX_SIZE (CODE_GEN_BUFFER_SIZE - code_gen_max_block_size()) #define SMC_BITMAP_USE_THRESHOLD 10 @@ -622,7 +622,7 @@ tb->cs_base = cs_base; tb->flags = flags; tb->cflags = cflags; -cpu_gen_code(env, tb, CODE_GEN_MAX_SIZE, &code_gen_size); +cpu_gen_code(env, tb, &code_gen_size); code_gen_ptr = (void *)(((unsigned long)code_gen_ptr + code_gen_size + CODE_GEN_ALIGN - 1) & ~(CODE_GEN_ALIGN - 1)); /* check next page if needed */ Index: qemu/translate-all.c ==
