[Qemu-devel] qemu/slirp misc.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Andrzej Zaborowski 07/11/13 01:56:12 Modified files: slirp : misc.c Log message: Revert an accidental change in previous commit. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/slirp/misc.c?cvsroot=qemu&r1=1.14&r2=1.15
[Qemu-devel] qemu slirp/misc.c target-arm/cpu.h target-arm/h...
CVSROOT:/sources/qemu Module name:qemu Changes by: Andrzej Zaborowski 07/11/13 01:50:16 Modified files: slirp : misc.c target-arm : cpu.h helper.c Log message: Prevent cpsr_write/_read be put out of line in op.o (fixes a segfault on some platforms). CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/slirp/misc.c?cvsroot=qemu&r1=1.13&r2=1.14 http://cvs.savannah.gnu.org/viewcvs/qemu/target-arm/cpu.h?cvsroot=qemu&r1=1.38&r2=1.39 http://cvs.savannah.gnu.org/viewcvs/qemu/target-arm/helper.c?cvsroot=qemu&r1=1.26&r2=1.27
[Qemu-devel] Release: VMKNOPPIX for X86/X86_64 with Xen3.1.1, KVM48, UML, QEMU, VirtualBox
Dear, We released new VMKNOPPIX for x86/x86_64. http://unit.aist.go.jp/itri/knoppix/vmknoppix/index-en.html VMKNOPPIX-CD for x86(20071101) VMKNOPPIX-CD for x86_64 (20071107) This version includes Xen3.1.1, KVM48, x86_64 kernel with IA32 emulator, etc. The included software is as follows. KNOPPIX 5.1.1 (kernel 2.6.19) with Xen3.1.1 (DomU&HVM) http://www.cl.cam.ac.uk/research/srg/netos/xen/ KVM (48-x86) (16-x86_64) http://sourceforge.net/projects/kvm QEMU090 http://fabrice.bellard.free.fr/qemu/ KQEMU (x86 only) http://fabrice.bellard.free.fr/qemu/kqemu-doc.html UML http://user-mode-linux.sourceforge.net/ Virtual Box (x86 only)http://www.virtualbox.org/ The guide for VMKNOPPIX x86/x86_64 is available at the following URL. VMKNOPPIX x86 (20071101) http://unit.aist.go.jp/itri/knoppix/vmknoppix/VMKNOPPIX-x86-20071101J.pdf VMKNOPPIX x86_64 (20071101) http://unit.aist.go.jp/itri/knoppix/vmknoppix/VMKNOPPIX-x86_64-20071107.pdf ISO Download X86 version File name : knoppix_v5.1.1CD_20070104_xen3.1.1_vbox-20071101.iso MD5:bb2058814423c74667991ab23dc5ad9a FTP: ftp://unit.aist.go.jp/itri/knoppix/iso/knoppix_v5.1.1CD_20070104_xen3.1.1_vbox-20071101.iso HTTP (Ring Servers): http://www.ring.gr.jp/archives/linux/knoppix/iso/ Bittorrent: http://unit.aist.go.jp/itri/knoppix/vmknoppix/knoppix_v5.1.1CD_20070104_xen3.1.1_vbox-20071101.iso.torrent X86_64 version File name : knoppix-x86_64-v5.1.1CD-20071107_xen3.1.1.iso MD5:c1a167eff22177a7ba89fc91fac7f494 FTP: ftp://unit.aist.go.jp/itri/knoppix/iso/knoppix-x86_64-v5.1.1CD-20071107_xen3.1.1.iso HTTP (Ring Servers): http://www.ring.gr.jp/archives/linux/knoppix/iso/ Bittorrent: http://unit.aist.go.jp/itri/knoppix/vmknoppix/knoppix-x86_64-v5.1.1CD-20071107_xen3.1.1.iso.torrent -- suzaki
Re: [Qemu-devel] Remote guest VBD
Kaushik Bhandankar wrote: Hello, I am trying to implement remote VBD functionality for HVM guests is fully-virtualized Xen 3.0 unstable. Consider 2 machines: machine 1 and machine 2, booth Intel-VT capable machines hosting fully-virtualized Xen 3.0-unstable. Lets say the HVM guest sitting on machine 1 has its VBD located on machine 2 (same/different LAN) For this, I have established a 9P communication channel (similar to socket communication) between the Dom0's of machine 1 and machine 2 with the 9P server thread running on machine 2 and 9P client thread running on machine 1. Whenever the HVM guest tries to access its VBD, my 9P client needs tointercept this invocation and send it to the 9P server which does the necessary stuff with the VBD and sends back the response to the 9P client. But I am not sure about following details: 1) The code path followed when a guest tries to access its VBD before it lands me into tools/ioemu/hw/ide.c:ide_ioport_read() or tools/ioemu/hw/ide.c:ide_ioport_write() 2) Where exactly should the 9P client intercept the call by guest to access its VBD? 3) When the 9P server sends the response back to the 9P client, how should this response be forwarded by the client? Any help about this will be appreciated. -Kaushik I found out the following info about how a IO request by a DomU is handled in Dom0 (All methods are in drivers/xen/blkback/blkback.c) 1) blkif_schedule() invokes do_block_io_op() 2) do_block_io_op copies the request from the corresponding 'blk_rings' (based on blkif->blk_protocol) and if the request is for BLK_OP_READ or BLK_OP_WRITE, invokes dispatch_rw_block_io() 3) dispatch_rw_block_io() makes a hypercall to "map the referred page into the Dom0's address space", does a 'whole bunch of other stuff' and sets end_block_io_op() as the callback routine when this block I/O finishes. 4) end_block_io_op() invokes __end_block_io_op() which invokes make_response() 5) make_response() creates a blkif_response_t structure (filling in appropriate id, status values from pending request) and copies this response on the 'response ring' for the appropriate DomU and notifies the front-end (FE) using RING_PUSH_RESPONSES_AND_CHECK_NOTIFY() 6) The FE takes appropriate action. Now, for remote VBD implementation, I feel that when the guest fomain makes a block I/O request and we land in dispatch_rw_block_io(), the 9P client thread should be invoked to send the block IO request to the 9P server and the 9P server should send back the response to the 9P client which should invoke make_response() to enqueue the response to the appropriate DomU's shared ring. Can somebody please verify whether this will work? -- Kaushik Bhandankar Graduate Student College of Computing Georgia Tech 206.94.4189 www.cc.gatech.edu/~kaushikb
[Qemu-devel] qemu/target-ppc translate_init.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Jocelyn Mayer 07/11/12 23:40:49 Modified files: target-ppc : translate_init.c Log message: Add PVR and SPR definition for most embedded PowerPC from Freescale. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/translate_init.c?cvsroot=qemu&r1=1.58&r2=1.59
[Qemu-devel] qemu/target-ppc cpu.h op_template.h translate.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Jocelyn Mayer 07/11/12 23:29:14 Modified files: target-ppc : cpu.h op_template.h translate.c Log message: PowerPC SPE extension fix: must always preserve GPR high bits when running in 32 bits mode. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/cpu.h?cvsroot=qemu&r1=1.91&r2=1.92 http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/op_template.h?cvsroot=qemu&r1=1.14&r2=1.15 http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/translate.c?cvsroot=qemu&r1=1.105&r2=1.106
[Qemu-devel] Linux user mode tests updated
I put new architectures in the Linux user mode regression tests available at http://bellard.org/qemu/download.html . The interested developpers can try to fix the following targets: x86_64 sh4 alpha ppc64 hppa. The challenge is to make a dynamically linked "ls -l" work ! I might spend some time on x86_64. Fabrice.
[Qemu-devel] qemu/target-m68k helper.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Fabrice Bellard07/11/12 23:12:17 Modified files: target-m68k: helper.c Log message: added missing return CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/target-m68k/helper.c?cvsroot=qemu&r1=1.9&r2=1.10
[Qemu-devel] [PATCH] add iommu version to sparc32
Add iommu version to sparc32. Also reset iommu after initialization.
Index: hw/iommu.c
===
RCS file: /sources/qemu/qemu/hw/iommu.c,v
retrieving revision 1.17
diff -p -u -r1.17 iommu.c
--- hw/iommu.c 6 Oct 2007 11:28:21 - 1.17
+++ hw/iommu.c 12 Nov 2007 22:54:57 -
@@ -37,7 +37,6 @@ do { printf("IOMMU: " fmt , ##args); } w
#define IOMMU_CTRL (0x >> 2)
#define IOMMU_CTRL_IMPL 0xf000 /* Implementation */
#define IOMMU_CTRL_VERS 0x0f00 /* Version */
-#define IOMMU_VERSION 0x0400
#define IOMMU_CTRL_RNGE 0x001c /* Mapping RANGE */
#define IOMMU_RNGE_16MB 0x /* 0xff00 -> 0x */
#define IOMMU_RNGE_32MB 0x0004 /* 0xfe00 -> 0x */
@@ -104,6 +103,7 @@ typedef struct IOMMUState {
target_phys_addr_t addr;
uint32_t regs[IOMMU_NREGS];
target_phys_addr_t iostart;
+uint32_t version;
} IOMMUState;
static uint32_t iommu_mem_readw(void *opaque, target_phys_addr_t addr)
@@ -158,7 +158,7 @@ static void iommu_mem_writew(void *opaqu
break;
}
DPRINTF("iostart = " TARGET_FMT_plx "\n", s->iostart);
-s->regs[saddr] = ((val & IOMMU_CTRL_MASK) | IOMMU_VERSION);
+s->regs[saddr] = ((val & IOMMU_CTRL_MASK) | s->version);
break;
case IOMMU_BASE:
s->regs[saddr] = val & IOMMU_BASE_MASK;
@@ -308,10 +308,11 @@ static void iommu_reset(void *opaque)
memset(s->regs, 0, IOMMU_NREGS * 4);
s->iostart = 0;
-s->regs[IOMMU_CTRL] = IOMMU_VERSION;
+s->regs[IOMMU_CTRL] = s->version;
+s->regs[IOMMU_ARBEN] = IOMMU_MID;
}
-void *iommu_init(target_phys_addr_t addr)
+void *iommu_init(target_phys_addr_t addr, uint32_t version)
{
IOMMUState *s;
int iommu_io_memory;
@@ -321,12 +322,14 @@ void *iommu_init(target_phys_addr_t addr
return NULL;
s->addr = addr;
+s->version = version;
iommu_io_memory = cpu_register_io_memory(0, iommu_mem_read,
iommu_mem_write, s);
cpu_register_physical_memory(addr, IOMMU_NREGS * 4, iommu_io_memory);
register_savevm("iommu", addr, 2, iommu_save, iommu_load, s);
qemu_register_reset(iommu_reset, s);
+iommu_reset(s);
return s;
}
Index: hw/sun4m.c
===
RCS file: /sources/qemu/qemu/hw/sun4m.c,v
retrieving revision 1.60
diff -p -u -r1.60 sun4m.c
--- hw/sun4m.c 11 Nov 2007 17:56:38 - 1.60
+++ hw/sun4m.c 12 Nov 2007 22:54:57 -
@@ -69,6 +69,7 @@ struct hwdef {
int intctl_g_intr, esp_irq, le_irq, clock_irq, clock1_irq;
int ser_irq, ms_kb_irq, fd_irq, me_irq, cs_irq;
int machine_id; // For NVRAM
+uint32_t iommu_version;
uint32_t intbit_to_level[32];
};
@@ -343,7 +344,7 @@ static void *sun4m_hw_init(const struct
/* allocate RAM */
cpu_register_physical_memory(0, RAM_size, 0);
-iommu = iommu_init(hwdef->iommu_base);
+iommu = iommu_init(hwdef->iommu_base, hwdef->iommu_version);
slavio_intctl = slavio_intctl_init(hwdef->intctl_base,
hwdef->intctl_base + 0x1ULL,
&hwdef->intbit_to_level[0],
@@ -509,6 +510,7 @@ static const struct hwdef hwdefs[] = {
.me_irq = 30,
.cs_irq = 5,
.machine_id = 0x80,
+.iommu_version = 0x0400,
.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,
@@ -542,6 +544,7 @@ static const struct hwdef hwdefs[] = {
.me_irq = 30,
.cs_irq = -1,
.machine_id = 0x72,
+.iommu_version = 0x0300,
.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,
@@ -575,6 +578,7 @@ static const struct hwdef hwdefs[] = {
.me_irq = 30,
.cs_irq = -1,
.machine_id = 0x71,
+.iommu_version = 0x0100,
.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,
[Qemu-devel] qemu/target-alpha op_mem.h
CVSROOT:/sources/qemu Module name:qemu Changes by: Fabrice Bellard07/11/12 21:16:08 Modified files: target-alpha : op_mem.h Log message: reduce verbosity CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/target-alpha/op_mem.h?cvsroot=qemu&r1=1.3&r2=1.4
Re: [Qemu-devel] Latest CVS
Hi, did you compile for a MIPS target? Then running "configure" will help. (Re-running configure with the original parameters when the configure script changed is a missing dependency which is still on my personal to-do list...) Regards Stefan Nigel Horne schrieb: > I can't get the latest CVS version to build on Fedora 7/x86: > > /usr/include/signal.h:380: warning: shadowed declaration is here > In file included from /home/njh/src/qemu/linux-user/qemu.h:26, > from /home/njh/src/qemu/linux-user/main.c:27: > /home/njh/src/qemu/linux-user/syscall_defs.h:1478:2: #error > unsupported CPU > In file included from /home/njh/src/qemu/linux-user/qemu.h:26, > > -Nigel
Re: [Qemu-devel] s390 host support
On Saturday 10 November 2007, Bastian Blank wrote: > Thimo Seufer asked me to check if the s390 host supports works at all. > It did not even build, dyngen failed. A 31-bit build of the CVS code works fine for me. (At least if I add the br %rANY fix that is also in your patch and the jcc patch that Thiemo has not committed yet.) A 31-bit build using your patch works as well, but it also needs the jcc patch. The only reason it needs to be compiled with -march=z900 is the use of larl in the inline assembly code, which can be avoided by simply omitting it in the PARAMx macros (the bras already writes the address to the register) and reverting to the code currently in CVS for GOTO_LABEL_PARAM. (The GOTO_TB hack does not seem to be necessary any more.) > I digged into the problem and > found the following: > gcc for s390 generates a data table after each function if necessary > instead of immediate loads. It actually generates it inline, doing something like op_something: bras %r13, 8 .long ... In other words, it branches over the data, storing the "return address" (which is actually a pointer to the data) in r13. > (g5, the oldest supported processor only > suports one halfword immediate load.) dyngen is not prepared for that > and fails. > I found that gcc moves this data into the .rodata section > if generating code for z900 and above, which looked like a possible > way to support this. (My) GCC only does this when generating 64-bit code. > - Support R_390_PC32DBL relocation, including relocations into > sections. Again, my GCC only generates this relocation when compiling 64-bit code. With your patch and some obvious fixes (ELFCLASS64, GETPC, $hostlongbits)) it builds as 64-bit, but it segfaults in the first translation block. CU Uli -- Heute ist - Dr. Sun Yat-sens Geburtstag (in Taiwan) - Gedenktag (in Bermuda, Cayman-Inseln) - Tag der Veteranen (in den USA (26 Staaten)) - Unabhängigkeit von Cartagena (in Kolumbien) SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)
Re: [Qemu-devel] [PATCH 1/2][UPDATE] remove unused parameters from QEMUMachineInitFunc
Find attached an updated^2 patch.
Laurent
Le lundi 12 novembre 2007 à 17:36 +0100, Laurent Vivier a écrit :
> Le lundi 12 novembre 2007 à 18:23 +0200, Blue Swirl a écrit :
> > On 11/12/07, Laurent Vivier <[EMAIL PROTECTED]> wrote:
> > >
> > > It appears that fd_filename and snapshot are not needed/used by machine
> > > init functions (QEMUMachineInitFunc).
> > >
> > > This patch removes them.
> >
> > I don't know what was the idea for these parameters, so I can't
> > comment on the correctness of the patch in general.
>
> fd_filename cannot be managed because I suppressed the array in vl.c
> and Fabrice (when he commented the first revision of this patch)
> proposed to remove "snapshot" too:
>
> "- While modifying the machine init function, you can suppress the
> snapshot parameter."
>
> > > /* SPARCstation 5 hardware initialisation */
> > > -static void ss5_init(int RAM_size, int vga_ram_size, const char
> > > *boot_device,
> > > - DisplayState *ds, const char **fd_filename, int
> > > snapshot,
> > > +static void ss5_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)
> > > {
> > > @@ -616,8 +616,8 @@ static void ss5_init(int RAM_size, int v
> > > }
> > >
> > > /* SPARCstation 10 hardware initialisation */
> > > -static void ss10_init(int RAM_size, int vga_ram_size, const char
> > > *boot_device,
> > > -DisplayState *ds, const char **fd_filename,
> > > int snapshot,
> > > +static void ss10_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)
> >
> > You didn't fix ss600mp_init, which was added yesterday.
>
> Oops, sorry, I missed it.
>
> Thank you for your comments,
> Laurent
--
- [EMAIL PROTECTED] --
"In short: just say NO TO DRUGS and maybe you won't
end up like the Hurd people." -- Linus Torvald
It appears that fd_filename and snapshot are not needed/used by machine
init functions (QEMUMachineInitFunc).
This patch removes them.
---
hw/an5206.c|4 ++--
hw/dummy_m68k.c|1 -
hw/etraxfs.c |4 ++--
hw/integratorcp.c |1 -
hw/mcf5208.c |1 -
hw/mips_malta.c|4 ++--
hw/mips_mipssim.c |4 ++--
hw/mips_pica61.c |4 ++--
hw/mips_r4k.c |4 ++--
hw/palm.c |1 -
hw/pc.c| 20
hw/ppc405_boards.c |2 --
hw/ppc_chrp.c |1 -
hw/ppc_oldworld.c |1 -
hw/ppc_prep.c |5 ++---
hw/r2d.c |4 ++--
hw/realview.c |1 -
hw/shix.c |4 ++--
hw/spitz.c |4
hw/stellaris.c |2 --
hw/sun4m.c | 12 ++--
hw/sun4u.c |4 ++--
hw/versatilepb.c | 17 -
vl.c |3 +--
vl.h |3 +--
25 files changed, 44 insertions(+), 67 deletions(-)
Index: qemu/vl.h
===
--- qemu.orig/vl.h 2007-11-12 17:56:00.0 +0100
+++ qemu/vl.h 2007-11-12 17:56:31.0 +0100
@@ -582,8 +582,7 @@ extern uint8_t _translate_keycode(const
#ifdef NEED_CPU_H
typedef void QEMUMachineInitFunc(int ram_size, int vga_ram_size,
- const char *boot_device,
- DisplayState *ds, const char **fd_filename, int snapshot,
+ const char *boot_device, DisplayState *ds,
const char *kernel_filename, const char *kernel_cmdline,
const char *initrd_filename, const char *cpu_model);
Index: qemu/hw/an5206.c
===
--- qemu.orig/hw/an5206.c 2007-11-12 17:56:00.0 +0100
+++ qemu/hw/an5206.c 2007-11-12 17:56:31.0 +0100
@@ -27,8 +27,8 @@ void DMA_run (void)
/* Board init. */
-static void an5206_init(int ram_size, int vga_ram_size, const char *boot_device,
- DisplayState *ds, const char **fd_filename, int snapshot,
+static void an5206_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)
{
Index: qemu/hw/etraxfs.c
===
--- qemu.orig/hw/etraxfs.c 2007-11-12 17:56:00.0 +0100
+++ qemu/hw/etraxfs.c 2007-11-12 17:56:31.0 +0100
@@ -107,8 +107,8 @@ static void dummy_cpu_set_irq(void *opaq
}
static
-void
Re: [Qemu-devel] [PATCH 2/2][UPDATE] Add arg -drive to define new drive with more features
Le lundi 12 novembre 2007 à 18:44 +0200, Blue Swirl a écrit :
> On 11/12/07, Laurent Vivier <[EMAIL PROTECTED]> wrote:
> > It also defines the default interface type to "scsi" for targets
> > "realview", "SS-5", "SS-10", "versatilepb", "versatileab"
> > to keep old behavior, where "-hda" is a SCSI disk.
>
> For maximal compatibility, I'd like the following mappings for SS-5,
> SS-10, and SS-600MP:
> -hda = SCSI ID 0
> -hdb = SCSI ID 1
> -hdc = -cdrom = SCSI ID 2
> -hdd = SCSI ID 3
Yes, there is mistake there.
> There is no bus 1, only 0. Maybe a warning should be issued for bus=1.
> I didn't find where this was implemented, so is the above in line with
> the patch?
See following lines:
...
#define HD_ALIAS "file=%s,bus=%d,unit=%d,media=disk"
...
if (!strcmp(machine->name, "realview") ||
!strcmp(machine->name, "SS-5") ||
!strcmp(machine->name, "SS-10") ||
!strcmp(machine->name, "versatilepb") ||
!strcmp(machine->name, "versatileab")) {
interface = IF_SCSI;
max_devs = MAX_SCSI_DEVS;
} else {
interface = IF_IDE;
max_devs = MAX_IDE_DEVS;
}
...
case QEMU_OPTION_hdb:
case QEMU_OPTION_hdc:
case QEMU_OPTION_hdd:
drive_add(HD_ALIAS, optarg, hd_index / MAX_IDE_DEVS,
hd_index % MAX_IDE_DEVS);
...
Of course this last line is wrong...
> > Index: qemu/hw/sun4m.c
>
> > -if (hwdef->fd_base != (target_phys_addr_t)-1)
> > -sun4m_fdctrl_init(slavio_irq[hwdef->fd_irq], hwdef->fd_base,
> > fd_table);
> > +if (hwdef->fd_base != (target_phys_addr_t)-1) {
> > +for(i = 0; i < MAX_FD; i++) {
> > +index = drive_get_index(IF_FLOPPY, 0, i);
> > +if (index != -1)
> > +fd[i] = drives_table[index].bdrv;
> > +else
> > +fd[i] = NULL;
> > +}
> > +
> > +sun4m_fdctrl_init(slavio_irq[hwdef->fd_irq], hwdef->fd_base, fd);
> > +}
>
> This is broken, there are zero or one floppy drives, never more.
I just try to mimic original behavior.
I'll correct this.
> > Index: qemu/hw/sun4u.c
>
> > -floppy_controller = fdctrl_init(NULL/*6*/, 2, 0, 0x3f0, fd_table);
> > +for(i = 0; i < MAX_FD; i++) {
> > +index = drive_get_index(IF_FLOPPY, 0, i);
> > + if (index != -1)
> > + fd[i] = drives_table[index].bdrv;
> > + else
> > + fd[i] = NULL;
> > +}
> > +floppy_controller = fdctrl_init(NULL/*6*/, 2, 0, 0x3f0, fd);
>
> I think same applies here (0 to 1 drives), but as the hardware is
> PC-like, technically it may be possible that someone could replace the
> cables and insert additional floppy drives.
ditto
Laurent
--
- [EMAIL PROTECTED] --
"In short: just say NO TO DRUGS and maybe you won't
end up like the Hurd people." -- Linus Torvald
signature.asc
Description: Ceci est une partie de message numériquement signée
Re: [Qemu-devel] RFC: x86_64 Best way to fix 'cast to pointer from integer of different size' problems?
On Wed, 2007-11-07 at 20:18 +0100, Fabrice Bellard wrote:
> - Fix page_check_range() so that it handles writes to pages containing
> code by calling page_unprotect when necessary (the current code can fail
> in this case !).
>
> - Suppress no longer needed page_unprotect_range() call in syscall.c.
Something like this?
Looks like exec.c needs some attention regarding target_ulong/abi_ulong.
Index: qemu/linux-user/syscall.c
===
--- qemu.orig/linux-user/syscall.c 2007-11-12 09:56:01.0 -0700
+++ qemu/linux-user/syscall.c 2007-11-12 09:56:12.0 -0700
@@ -2745,7 +2745,6 @@
ret = 0; /* avoid warning */
break;
case TARGET_NR_read:
-page_unprotect_range(arg2, arg3);
if (!(p = lock_user(VERIFY_WRITE, arg2, arg3, 0)))
goto efault;
ret = get_errno(read(arg1, p, arg3));
@@ -4538,7 +4537,6 @@
break;
#ifdef TARGET_NR_pread
case TARGET_NR_pread:
-page_unprotect_range(arg2, arg3);
if (!(p = lock_user(VERIFY_WRITE, arg2, arg3, 0)))
goto efault;
ret = get_errno(pread(arg1, p, arg3, arg4));
Index: qemu/exec.c
===
--- qemu.orig/exec.c 2007-11-12 09:56:01.0 -0700
+++ qemu/exec.c 2007-11-12 10:00:41.0 -0700
@@ -1898,6 +1898,9 @@
return -1;
if (!(p->flags & PAGE_WRITE) && (flags & PAGE_WRITE) )
return -1;
+if ((p->flags & PAGE_EXEC) && (flags & PAGE_WRITE)
+&& page_unprotect(addr, 0, NULL))
+return -1;
}
return 0;
}
@@ -1942,21 +1945,6 @@
return 0;
}
-/* call this function when system calls directly modify a memory area */
-/* ??? This should be redundant now we have lock_user. */
-void page_unprotect_range(target_ulong data, target_ulong data_size)
-{
-target_ulong start, end, addr;
-
-start = data;
-end = start + data_size;
-start &= TARGET_PAGE_MASK;
-end = TARGET_PAGE_ALIGN(end);
-for(addr = start; addr < end; addr += TARGET_PAGE_SIZE) {
-page_unprotect(addr, 0, NULL);
-}
-}
-
static inline void tlb_set_dirty(CPUState *env,
unsigned long addr, target_ulong vaddr)
{
Re: [Qemu-devel] [PATCH 2/2][UPDATE] Add arg -drive to define new drive with more features
On 11/12/07, Laurent Vivier <[EMAIL PROTECTED]> wrote:
> It also defines the default interface type to "scsi" for targets
> "realview", "SS-5", "SS-10", "versatilepb", "versatileab"
> to keep old behavior, where "-hda" is a SCSI disk.
For maximal compatibility, I'd like the following mappings for SS-5,
SS-10, and SS-600MP:
-hda = SCSI ID 0
-hdb = SCSI ID 1
-hdc = -cdrom = SCSI ID 2
-hdd = SCSI ID 3
There is no bus 1, only 0. Maybe a warning should be issued for bus=1.
I didn't find where this was implemented, so is the above in line with
the patch?
> Index: qemu/hw/sun4m.c
> -if (hwdef->fd_base != (target_phys_addr_t)-1)
> -sun4m_fdctrl_init(slavio_irq[hwdef->fd_irq], hwdef->fd_base,
> fd_table);
> +if (hwdef->fd_base != (target_phys_addr_t)-1) {
> +for(i = 0; i < MAX_FD; i++) {
> +index = drive_get_index(IF_FLOPPY, 0, i);
> +if (index != -1)
> +fd[i] = drives_table[index].bdrv;
> +else
> +fd[i] = NULL;
> +}
> +
> +sun4m_fdctrl_init(slavio_irq[hwdef->fd_irq], hwdef->fd_base, fd);
> +}
This is broken, there are zero or one floppy drives, never more.
> Index: qemu/hw/sun4u.c
> -floppy_controller = fdctrl_init(NULL/*6*/, 2, 0, 0x3f0, fd_table);
> +for(i = 0; i < MAX_FD; i++) {
> +index = drive_get_index(IF_FLOPPY, 0, i);
> + if (index != -1)
> + fd[i] = drives_table[index].bdrv;
> + else
> + fd[i] = NULL;
> +}
> +floppy_controller = fdctrl_init(NULL/*6*/, 2, 0, 0x3f0, fd);
I think same applies here (0 to 1 drives), but as the hardware is
PC-like, technically it may be possible that someone could replace the
cables and insert additional floppy drives.
Re: [Qemu-devel] [PATCH 1/2][UPDATE] remove unused parameters from QEMUMachineInitFunc
Le lundi 12 novembre 2007 à 18:23 +0200, Blue Swirl a écrit :
> On 11/12/07, Laurent Vivier <[EMAIL PROTECTED]> wrote:
> >
> > It appears that fd_filename and snapshot are not needed/used by machine
> > init functions (QEMUMachineInitFunc).
> >
> > This patch removes them.
>
> I don't know what was the idea for these parameters, so I can't
> comment on the correctness of the patch in general.
fd_filename cannot be managed because I suppressed the array in vl.c
and Fabrice (when he commented the first revision of this patch)
proposed to remove "snapshot" too:
"- While modifying the machine init function, you can suppress the
snapshot parameter."
> > /* SPARCstation 5 hardware initialisation */
> > -static void ss5_init(int RAM_size, int vga_ram_size, const char
> > *boot_device,
> > - DisplayState *ds, const char **fd_filename, int
> > snapshot,
> > +static void ss5_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)
> > {
> > @@ -616,8 +616,8 @@ static void ss5_init(int RAM_size, int v
> > }
> >
> > /* SPARCstation 10 hardware initialisation */
> > -static void ss10_init(int RAM_size, int vga_ram_size, const char
> > *boot_device,
> > -DisplayState *ds, const char **fd_filename,
> > int snapshot,
> > +static void ss10_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)
>
> You didn't fix ss600mp_init, which was added yesterday.
Oops, sorry, I missed it.
Thank you for your comments,
Laurent
--
- [EMAIL PROTECTED] --
"In short: just say NO TO DRUGS and maybe you won't
end up like the Hurd people." -- Linus Torvald
signature.asc
Description: Ceci est une partie de message numériquement signée
Re: [Qemu-devel] [PATCH 1/2][UPDATE] remove unused parameters from QEMUMachineInitFunc
On 11/12/07, Laurent Vivier <[EMAIL PROTECTED]> wrote:
>
> It appears that fd_filename and snapshot are not needed/used by machine
> init functions (QEMUMachineInitFunc).
>
> This patch removes them.
I don't know what was the idea for these parameters, so I can't
comment on the correctness of the patch in general.
> /* SPARCstation 5 hardware initialisation */
> -static void ss5_init(int RAM_size, int vga_ram_size, const char *boot_device,
> - DisplayState *ds, const char **fd_filename, int
> snapshot,
> +static void ss5_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)
> {
> @@ -616,8 +616,8 @@ static void ss5_init(int RAM_size, int v
> }
>
> /* SPARCstation 10 hardware initialisation */
> -static void ss10_init(int RAM_size, int vga_ram_size, const char
> *boot_device,
> -DisplayState *ds, const char **fd_filename, int
> snapshot,
> +static void ss10_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)
You didn't fix ss600mp_init, which was added yesterday.
[Qemu-devel] Latest CVS
I can't get the latest CVS version to build on Fedora 7/x86: /usr/include/signal.h:380: warning: shadowed declaration is here In file included from /home/njh/src/qemu/linux-user/qemu.h:26, from /home/njh/src/qemu/linux-user/main.c:27: /home/njh/src/qemu/linux-user/syscall_defs.h:1478:2: #error unsupported CPU In file included from /home/njh/src/qemu/linux-user/qemu.h:26, -Nigel begin:vcard fn:Nigel Horne n:Horne;Nigel org:NJH Music adr:Pogmoor;;28 Wharfedale Road;Barnsley;South Yorkshire;S75 2LJ;UK email;internet:[EMAIL PROTECTED] tel;fax:+44 870 705 9334 note:Skype: nigelhorne x-mozilla-html:FALSE url:http://www.bandsman.co.uk version:2.1 end:vcard
[Qemu-devel] [PATCH 1/2][UPDATE] remove unused parameters from QEMUMachineInitFunc
It appears that fd_filename and snapshot are not needed/used by machine
init functions (QEMUMachineInitFunc).
This patch removes them.
---
hw/an5206.c|4 ++--
hw/etraxfs.c |4 ++--
hw/integratorcp.c |1 -
hw/mcf5208.c |1 -
hw/mips_malta.c|4 ++--
hw/mips_mipssim.c |4 ++--
hw/mips_pica61.c |4 ++--
hw/mips_r4k.c |4 ++--
hw/palm.c |1 -
hw/pc.c| 20
hw/ppc405_boards.c |2 --
hw/ppc_chrp.c |1 -
hw/ppc_oldworld.c |1 -
hw/ppc_prep.c |5 ++---
hw/r2d.c |4 ++--
hw/realview.c |1 -
hw/shix.c |4 ++--
hw/spitz.c |4
hw/sun4m.c |8
hw/sun4u.c |4 ++--
hw/versatilepb.c | 17 -
vl.c |3 +--
vl.h |3 +--
23 files changed, 42 insertions(+), 62 deletions(-)
Index: qemu/vl.h
===
--- qemu.orig/vl.h 2007-11-12 14:59:25.0 +0100
+++ qemu/vl.h 2007-11-12 14:59:27.0 +0100
@@ -582,8 +582,7 @@ extern uint8_t _translate_keycode(const
#ifdef NEED_CPU_H
typedef void QEMUMachineInitFunc(int ram_size, int vga_ram_size,
- const char *boot_device,
- DisplayState *ds, const char **fd_filename, int snapshot,
+ const char *boot_device, DisplayState *ds,
const char *kernel_filename, const char *kernel_cmdline,
const char *initrd_filename, const char *cpu_model);
Index: qemu/hw/an5206.c
===
--- qemu.orig/hw/an5206.c 2007-11-12 14:59:25.0 +0100
+++ qemu/hw/an5206.c2007-11-12 14:59:27.0 +0100
@@ -27,8 +27,8 @@ void DMA_run (void)
/* Board init. */
-static void an5206_init(int ram_size, int vga_ram_size, const char
*boot_device,
- DisplayState *ds, const char **fd_filename, int snapshot,
+static void an5206_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)
{
Index: qemu/hw/etraxfs.c
===
--- qemu.orig/hw/etraxfs.c 2007-11-12 14:59:25.0 +0100
+++ qemu/hw/etraxfs.c 2007-11-12 14:59:27.0 +0100
@@ -107,8 +107,8 @@ static void dummy_cpu_set_irq(void *opaq
}
static
-void bareetraxfs_init (int ram_size, int vga_ram_size, const char *boot_device,
- DisplayState *ds, const char **fd_filename, int
snapshot,
+void bareetraxfs_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)
{
Index: qemu/hw/integratorcp.c
===
--- qemu.orig/hw/integratorcp.c 2007-11-12 14:59:25.0 +0100
+++ qemu/hw/integratorcp.c 2007-11-12 14:59:27.0 +0100
@@ -466,7 +466,6 @@ static void icp_control_init(uint32_t ba
static void integratorcp_init(int ram_size, int vga_ram_size,
const char *boot_device, DisplayState *ds,
- const char **fd_filename, int snapshot,
const char *kernel_filename, const char *kernel_cmdline,
const char *initrd_filename, const char *cpu_model)
{
Index: qemu/hw/mcf5208.c
===
--- qemu.orig/hw/mcf5208.c 2007-11-12 14:59:25.0 +0100
+++ qemu/hw/mcf5208.c 2007-11-12 14:59:27.0 +0100
@@ -199,7 +199,6 @@ static void mcf5208_sys_init(qemu_irq *p
static void mcf5208evb_init(int ram_size, int vga_ram_size,
const char *boot_device, DisplayState *ds,
- const char **fd_filename, int snapshot,
const char *kernel_filename, const char *kernel_cmdline,
const char *initrd_filename, const char *cpu_model)
{
Index: qemu/hw/mips_malta.c
===
--- qemu.orig/hw/mips_malta.c 2007-11-12 14:59:25.0 +0100
+++ qemu/hw/mips_malta.c2007-11-12 14:59:27.0 +0100
@@ -746,8 +746,8 @@ static void main_cpu_reset(void *opaque)
}
static
-void mips_malta_init (int ram_size, int vga_ram_size, const char *boot_device,
- DisplayState *ds, const char **fd_filename, int snapshot,
+void mips_malta_init (int ram_size, int vga_ram_size,
+ const char *boot_device, DisplayState *ds,
const char *kernel_filename, const c
[Qemu-devel] [PATCH 0/2][UPDATE] Add "-drive" parameter
These two patches are update of the patches previously sent. [PATCH 1/2][UPDATE] remove unused parameters from QEMUMachineInitFunc [PATCH 2/2][UPDATED] Add arg -drive to define new drive with more features Laurent
