Re: [Qemu-devel] [PATCH, RFC] More than 2G of memory on 64-bit hosts
Karl Magdsick wrote: [snip] With proper support from the compiler, it's theoretically possible on x86-64 systems to use 32-bit pointers in long mode (16 general purpose 64-bit registers). (There's an instruction prefix that will cause the CPU to perform 32-bit pointer calculations in the 64-bit address space.) I'm not aware of any systems that use this, however. (Getting the speed boost from fewer register spills while not paying the space cost of 64-bit pointers sounds very attractive in many applications, though.) FYI, the MIPS N32 ABI does that (64bit wide registers, 32bit address space, data type sizes compatible to pure 32bit programs). Thiemo
[Qemu-devel] qemu/target-i386 exec.h helper.c op.c translate.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer ths 07/06/26 08:35:18 Modified files: target-i386: exec.h helper.c op.c translate.c Log message: DR6 single step exception status bit, by Juergen Keil. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/target-i386/exec.h?cvsroot=qemur1=1.33r2=1.34 http://cvs.savannah.gnu.org/viewcvs/qemu/target-i386/helper.c?cvsroot=qemur1=1.83r2=1.84 http://cvs.savannah.gnu.org/viewcvs/qemu/target-i386/op.c?cvsroot=qemur1=1.47r2=1.48 http://cvs.savannah.gnu.org/viewcvs/qemu/target-i386/translate.c?cvsroot=qemur1=1.66r2=1.67
Re: [Qemu-devel] [PATCH] starting qemu vnc session on a pre-allocated port
Anthony Liguori wrote: Here are the reasons why the Unix domain socket approach is superior: Sharing a file descriptor implies a parent/child relationship. True. It also implies that the daemon will be running for the entire lifetime of the VM. No. In fact, running an extra daemon for the entire life time of the VM is exactly what I'm trying to avoid (one of the things, anyway). Now I see why you think the unix domain socket option solves the problem already. Our use case is actully a little different. Let me explain: The machine running qemu has a web based interface to start VMs. A user asks for a new VM to start by browsing to a URL. The CGI implmenting that URL will start a new qemu instance, send to the user web browser an HTML page with a JAVA VNC viewer embedded and terminate. Here is the problem: the HTML page needs to have the port number for the JAVA VNC viewer to connect to embedded in it. Of course, the CGI can pick a free port and ask qemu to start the VNC server on it, but it means CGI needs to maintain a list of free/used port ranges in some shared data structue, track the qemu instance to know when it is termianted and the port is free again and of course, hope that not non related proccess will snatch a port in the port range and generally duplicate the ifnormation the operating system already has on free/in use ports. In our suggested solution, our CGI simply opens a listening socket on an ethermal port, letting the OS do the allocation, hands the file descriptor to qemu to use and *terminates* (after sending the HTML page). No long running daemons. Having a daemon sit around just to shove the data from the Unix domain socket to the TCP socket and back and needing to track it and all really puts an ugly dent on the whole idea and, more important - I think what we are doing is a rather general concept, certainly not unique to us (just look at qemudo, only of course, they got it wrong... :-) Hope this explains things a little better. Since VM's are meant to run for very long periods of time, this is quite limiting. By utilizing a domain socket, you gain the ability to record on disk the state of the daemon and then restart. The layer of redirection also allows you to let your uses change the VNC server properties while the VM is running (so you change the listening vnc display from localhost:3 to :22 without restarting the VM). All the above are really nice to have, but nit with the cost of extra management overhead, as explained above. Also, our VM life time is typically 15 minutes long... :-) Plus, live migration has no hope of working if you're passing file descriptors on the command line as they're meaningless once you've migrated. That, I have no answer for. What do you do with the Unix domain socket? open it by path/filename on the new machines? Gilad -- Gilad Ben-Yossef [EMAIL PROTECTED] Codefidence. A name you can trust(tm) http://www.codefidence.com Phone: +972.3.7515563 ext. 201 | Cellular: +972.52.8260388 SIP: [EMAIL PROTECTED] | Fax: +972.3.7515503 Lacking fins or tail the gefilte fish swims with great difficulty. -- A Jewish Haiku
Re: [Qemu-devel] [PATCH] starting qemu vnc session on a pre-allocated port
On 6/26/07, Gilad Ben-Yossef [EMAIL PROTECTED] wrote: Anthony Liguori wrote: It also implies that the daemon will be running for the entire lifetime of the VM. No. In fact, running an extra daemon for the entire life time of the VM is exactly what I'm trying to avoid (one of the things, anyway). Now I see why you think the unix domain socket option solves the problem already. Our use case is actully a little different. Let me explain: The machine running qemu has a web based interface to start VMs. A user asks for a new VM to start by browsing to a URL. The CGI implmenting that URL will start a new qemu instance, send to the user web browser an HTML page with a JAVA VNC viewer embedded and terminate. Here is the problem: the HTML page needs to have the port number for the JAVA VNC viewer to connect to embedded in it. Of course, the CGI can pick a free port and ask qemu to start the VNC server on it, but it means CGI needs to maintain a list of free/used port ranges in some shared data structue, track the qemu instance to know when it is termianted and the port is free again and of course, hope that not non related proccess will snatch a port in the port range and generally duplicate the ifnormation the operating system already has on free/in use ports. In our suggested solution, our CGI simply opens a listening socket on an ethermal port, letting the OS do the allocation, hands the file descriptor to qemu to use and *terminates* (after sending the HTML page). No long running daemons. Having a daemon sit around just to shove the data from the Unix domain socket to the TCP socket and back and needing to track it and all really puts an ugly dent on the whole idea and, more important - I think what we are doing is a rather general concept, certainly not unique to us (just look at qemudo, only of course, they got it wrong... :-) Hope this explains things a little better. Isn't your suggestion also how xinetd works? I guess starting qemu from an xinetd could be useful as well in some use cases. A client can simply VNC to a server (on the standard port). xinetd listens on that port, starts a qemu passing it the connection handle. I guess the disadvantage would be that as soon as you loose the VNC connection you can't get it back anymore. Gilad -- Jannes Faber
Re: [Qemu-devel] qemu-i386 segfaults running hello world.
On Sun, Jun 24 2007, Rob Landley wrote: On Saturday 23 June 2007 07:00:03 Jens Axboe wrote: I realize releases are a bit out of fashion, but is there any way to go through cvs to track down which checkin broke this stuff? I can do it in git, mercurial, or subversion. But cvs isn't really set up for this sort of thing... git clone git://git.kernel.dk/data/git/qemu.git and bisect on that then. It's a continued git import of the cvs repo, gets updated every night. Oh _cool_. Any way to get a mention of that on the qemu web page? I don't mind, it's already mentioned on some japanese qemu-win page for quite some time. -- Jens Axboe
Re: [Qemu-devel] [PATCH, RFC] More than 2G of memory on 64-bit hosts
With proper support from the compiler, it's theoretically possible on x86-64 systems to use 32-bit pointers in long mode. I'm not aware of any systems that use this, however. Vxworks does. We just finished doing the gcc port. From a software point of view ILP32 mode on a 64-bit CPU/OS is indistinguishable from regular 32-bit mode. I'm not sure how big longs are on those systems, but I wouldn't be surprised if longs are 32-bits or 64-bits and pointers 128-bits. I really hope not. One from me, if you like... Just don't use the unsigned long type. The intptr_t type would be better (it's 32-bit on 32-bit systems and 64-bit on 64-bit systems). Nice, I didn't know about that. But how is this any different from unsigned long? The story behind this is that ISO C89 requires that long be at least as big as a pointer (ie. void *). The actual requirement is that it be possible to store a pointer in a standard integer type, and long is the largest standard integer type. Unfortunately C99 relaxed this requirement, and allowed abominations like the win64 ABI. This means you have a choice: Write standard conforming code (long) that works on all known systems except win64, or use features that do't exist on many systems. IIRC C99 types like intptr_t are not supported on several fairly common unix systems. It's ironic that the one system that requires C99 features explicitly does not (and probably never will) have full C99 support. Paul
Re: [Qemu-devel] Linux 2.6.21 doesn't work with qemu-arm SCSI controller anymore.
On 07/06/07, Rob Landley [EMAIL PROTECTED] wrote: In the 2.6.21 kernel the sym53c8xx_2 SCSI controller changed in a way that QEMU's virtual SCSI controller doesn't handle this properly: I spent some time yesterday trying to find out what was happening and the results are below. QEMU's virtual SCSI controller does handle it properly and the kernel sym53c8xx_2 driver changes are not at fault. The first surprising fact, and one which took me long to figure out, was that all the SCSI errors are a result of a case of simple interrupts from the controller not reaching the SCSI driver, hence the timeouts and whatnot. The sym53c8xx_2 driver gets irq 0 instead of 27, from the tiwsted PCI irq number assignment logic. This was because the VersatilePB PCI driver was reading the irq pin number from a wrong address in the scsi controller's (which is a pci device) config structure, and the read always returned a 0 which normally means that the device uses no interrupts (actually all 8-bit accesses were broken). I corrected the versatile PCI code and sent a patch to linux. However, the funny part is that this code had not changed since 2.6.18, so how did it break in 2.6.21? Well, it was broken all the time, but there was a bug in generic PCI code in drivers/pci/setup-irq.c, which effectively caused the value read from the device's supplied config, to be discarded, which got fixed in 2.6.21. If you definitely must use 2.6.21, this qemu workaround also works (need to do the same for any other PCI device you want to use): diff --git a/hw/lsi53c895a.c b/hw/lsi53c895a.c index 19bf2a1..eedbc1d 100644 --- a/hw/lsi53c895a.c +++ b/hw/lsi53c895a.c @@ -1845,6 +1845,7 @@ void *lsi_scsi_init(PCIBus *bus, int devfn) s-pci_dev.config[0x02] = 0x12; s-pci_dev.config[0x03] = 0x00; s-pci_dev.config[0x0b] = 0x01; +s-pci_dev.config[0x3c] = 0x01; /* ugly workaround */ s-pci_dev.config[0x3d] = 0x01; /* interrupt pin 1 */ s-mmio_io_addr = cpu_register_io_memory(0, lsi_mmio_readfn, Regards
Re: [Qemu-devel] [PATCH] Fix two typos
Hi,
here is another patch which changes additionnal - additional.
Please apply this new patch and my last one to CVS HEAD.
Thank you,
Stefan
Stefan Weil schrieb:
Aurelien Jarno schrieb:
Hi,
The patch below, taken from the Debian package, fixes two typos:
...
- formating - formatting
Bye,
Aurelien
Here is one more formating patch.
Regards,
Stefan
Index: hw/fdc.c
===
RCS file: /sources/qemu/qemu/hw/fdc.c,v
retrieving revision 1.24
diff -u -b -B -r1.24 fdc.c
--- hw/fdc.c 19 May 2007 12:58:29 - 1.24
+++ hw/fdc.c 23 Jun 2007 20:37:54 -
@@ -1268,7 +1268,7 @@
memset(fdctrl-fifo, 0, FD_SECTOR_LEN);
if (cur_drv-bs == NULL ||
bdrv_write(cur_drv-bs, fd_sector(cur_drv), fdctrl-fifo, 1) 0) {
- FLOPPY_ERROR(formating sector %d\n, fd_sector(cur_drv));
+ FLOPPY_ERROR(formatting sector %d\n, fd_sector(cur_drv));
fdctrl_stop_transfer(fdctrl, 0x60, 0x00, 0x00);
} else {
if (cur_drv-sect == cur_drv-last_sect) {
Index: block-raw.c
===
RCS file: /sources/qemu/qemu/block-raw.c,v
retrieving revision 1.17
diff -u -b -B -r1.17 block-raw.c
--- block-raw.c 18 Jan 2007 00:22:11 - 1.17
+++ block-raw.c 26 Jun 2007 17:09:12 -
@@ -1295,7 +1295,7 @@
#if 0
/***/
-/* removable device additionnal commands */
+/* removable device additional commands */
static int raw_is_inserted(BlockDriverState *bs)
{
Index: hw/ide.c
===
RCS file: /sources/qemu/qemu/hw/ide.c,v
retrieving revision 1.62
diff -u -b -B -r1.62 ide.c
--- hw/ide.c 6 Jun 2007 16:26:13 - 1.62
+++ hw/ide.c 26 Jun 2007 17:09:14 -
@@ -1567,7 +1567,7 @@
buf[1] = 0x80; /* removable */
buf[2] = 0x00; /* ISO */
buf[3] = 0x21; /* ATAPI-2 (XXX: put ATAPI-4 ?) */
-buf[4] = 31; /* additionnal length */
+buf[4] = 31; /* additional length */
buf[5] = 0; /* reserved */
buf[6] = 0; /* reserved */
buf[7] = 0; /* reserved */
Index: hw/usb.c
===
RCS file: /sources/qemu/qemu/hw/usb.c,v
retrieving revision 1.9
diff -u -b -B -r1.9 usb.c
--- hw/usb.c 12 Aug 2006 01:04:27 - 1.9
+++ hw/usb.c 26 Jun 2007 17:09:14 -
@@ -140,7 +140,7 @@
s-setup_state = SETUP_STATE_IDLE;
/* transfer OK */
} else {
-/* ignore additionnal output */
+/* ignore additional output */
}
break;
case SETUP_STATE_DATA:
Index: linux-user/signal.c
===
RCS file: /sources/qemu/qemu/linux-user/signal.c,v
retrieving revision 1.37
diff -u -b -B -r1.37 signal.c
--- linux-user/signal.c 13 May 2007 13:58:00 - 1.37
+++ linux-user/signal.c 26 Jun 2007 17:09:15 -
@@ -244,7 +244,7 @@
}
/* XXX: we support only POSIX RT signals are used. */
-/* XXX: find a solution for 64 bit (additionnal malloced data is needed) */
+/* XXX: find a solution for 64 bit (additional malloced data is needed) */
void target_to_host_siginfo(siginfo_t *info, const target_siginfo_t *tinfo)
{
info-si_signo = tswap32(tinfo-si_signo);
Index: target-i386/cpu.h
===
RCS file: /sources/qemu/qemu/target-i386/cpu.h,v
retrieving revision 1.44
diff -u -b -B -r1.44 cpu.h
--- target-i386/cpu.h 3 Jun 2007 21:02:37 - 1.44
+++ target-i386/cpu.h 26 Jun 2007 17:09:16 -
@@ -121,7 +121,7 @@
#define VIP_MASK0x0010
#define ID_MASK 0x0020
-/* hidden flags - used internally by qemu to represent additionnal cpu
+/* hidden flags - used internally by qemu to represent additional cpu
states. Only the CPL, INHIBIT_IRQ and HALTED are not redundant. We avoid
using the IOPL_MASK, TF_MASK and VM_MASK bit position to ease oring
with eflags. */
Re: [Qemu-devel] [PATCH] Fix two typos
On Tue, Jun 26, 2007 at 07:19:53PM +0200, Stefan Weil wrote: Hi, here is another patch which changes additionnal - additional. Please apply this new patch and my last one to CVS HEAD. A few others, fwiw: s/recieve/receive/g s/seperat/separat/g /[[:space:]]teh[[:space:]]/ the /g cheers,
[Qemu-devel] qemu cpu-defs.h exec.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Andrzej Zaborowski balrog 07/06/26 20:01:13 Modified files: . : cpu-defs.h exec.c Log message: Fix writes to pages containing watchpoints for the RAM not at 0x0 cases. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/cpu-defs.h?cvsroot=qemur1=1.21r2=1.22 http://cvs.savannah.gnu.org/viewcvs/qemu/exec.c?cvsroot=qemur1=1.100r2=1.101
Re: [Qemu-devel] [PATCH] Fix two typos
The appended patch fixes recieve - receive, seperat - separat and
teh - the. Maybe this makes addition to CVS HEAD easier...
Stefan
Bernhard Fischer schrieb:
On Tue, Jun 26, 2007 at 07:19:53PM +0200, Stefan Weil wrote:
Hi,
here is another patch which changes additionnal - additional.
Please apply this new patch and my last one to CVS HEAD.
A few others, fwiw:
s/recieve/receive/g
s/seperat/separat/g
/[[:space:]]teh[[:space:]]/ the /g
cheers,
Index: m68k-dis.c
===
--- m68k-dis.c (Revision 727)
+++ m68k-dis.c (Arbeitskopie)
@@ -560,7 +560,7 @@
};
/* Name of register halves for MAC/EMAC.
- Seperate from reg_names since 'spu', 'fpl' look weird. */
+ Separate from reg_names since 'spu', 'fpl' look weird. */
static char *const reg_half_names[] =
{
%d0, %d1, %d2, %d3, %d4, %d5, %d6, %d7,
Index: dis-asm.h
===
--- dis-asm.h (Revision 727)
+++ dis-asm.h (Arbeitskopie)
@@ -421,7 +421,7 @@
/* Call this macro to initialize only the internal variables for the
disassembler. Architecture dependent things such as byte order, or machine
variant are not touched by this macro. This makes things much easier for
- GDB which must initialize these things seperatly. */
+ GDB which must initialize these things separatly. */
#define INIT_DISASSEMBLE_INFO_NO_ARCH(INFO, STREAM, FPRINTF_FUNC) \
(INFO).fprintf_func = (FPRINTF_FUNC), \
Index: hw/pl181.c
===
--- hw/pl181.c (Revision 727)
+++ hw/pl181.c (Arbeitskopie)
@@ -160,7 +160,7 @@
s-response[2] = RWORD(8);
s-response[3] = RWORD(12) ~1;
}
-DPRINTF(Response recieved\n);
+DPRINTF(Response received\n);
s-status |= PL181_STATUS_CMDRESPEND;
#undef RWORD
} else {
@@ -174,7 +174,7 @@
s-status |= PL181_STATUS_CMDTIMEOUT;
}
-/* Transfer data between teh card and the FIFO. This is complicated by
+/* Transfer data between the card and the FIFO. This is complicated by
the FIFO holding 32-bit words and the card taking data in single byte
chunks. FIFO bytes are transferred in little-endian order. */
Index: hw/i2c.h
===
--- hw/i2c.h (Revision 727)
+++ hw/i2c.h (Arbeitskopie)
@@ -10,7 +10,7 @@
I2C_START_RECV,
I2C_START_SEND,
I2C_FINISH,
-I2C_NACK /* Masker NACKed a recieve byte. */
+I2C_NACK /* Masker NACKed a receive byte. */
};
typedef struct i2c_slave i2c_slave;
Index: hw/rtl8139.c
===
--- hw/rtl8139.c (Revision 727)
+++ hw/rtl8139.c (Arbeitskopie)
@@ -790,7 +790,7 @@
RTL8139State *s = opaque;
int avail;
-/* Recieve (drop) packets if card is disabled. */
+/* Receive (drop) packets if card is disabled. */
if (!s-clock_enabled)
return 1;
if (!rtl8139_receiver_enabled(s))
Index: hw/pl011.c
===
--- hw/pl011.c (Revision 727)
+++ hw/pl011.c (Arbeitskopie)
@@ -176,7 +176,7 @@
}
}
-static int pl011_can_recieve(void *opaque)
+static int pl011_can_receive(void *opaque)
{
pl011_state *s = (pl011_state *)opaque;
@@ -186,7 +186,7 @@
return s-read_count 1;
}
-static void pl011_recieve(void *opaque, const uint8_t *buf, int size)
+static void pl011_receive(void *opaque, const uint8_t *buf, int size)
{
pl011_state *s = (pl011_state *)opaque;
int slot;
@@ -241,7 +241,7 @@
s-cr = 0x300;
s-flags = 0x90;
if (chr){
-qemu_chr_add_handlers(chr, pl011_can_recieve, pl011_recieve,
+qemu_chr_add_handlers(chr, pl011_can_receive, pl011_receive,
pl011_event, s);
}
/* ??? Save/restore. */
Index: gdbstub.c
===
--- gdbstub.c (Revision 727)
+++ gdbstub.c (Arbeitskopie)
@@ -1238,12 +1238,12 @@
return 0;
}
#else
-static int gdb_chr_can_recieve(void *opaque)
+static int gdb_chr_can_receive(void *opaque)
{
return 1;
}
-static void gdb_chr_recieve(void *opaque, const uint8_t *buf, int size)
+static void gdb_chr_receive(void *opaque, const uint8_t *buf, int size)
{
GDBState *s = opaque;
int i;
@@ -1294,7 +1294,7 @@
}
s-env = first_cpu; /* XXX: allow to change CPU */
s-chr = chr;
-qemu_chr_add_handlers(chr, gdb_chr_can_recieve, gdb_chr_recieve,
+qemu_chr_add_handlers(chr, gdb_chr_can_receive, gdb_chr_receive,
gdb_chr_event, s);
qemu_add_vm_stop_handler(gdb_vm_stopped, s);
return 0;
[Qemu-devel] qemu/target-mips op_helper.c translate.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer ths 07/06/26 20:26:03 Modified files: target-mips: op_helper.c translate.c Log message: Implement recip1/recip2/rsqrt1/rsqrt2. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/op_helper.c?cvsroot=qemur1=1.53r2=1.54 http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/translate.c?cvsroot=qemur1=1.93r2=1.94
[Qemu-devel] [PATCH] Implement ACPI specs 3.0, 4.7.2.5
The patch below implements ACPI_ENABLE and ACPI_DISABLE as described in
section 4.7.2.5 of the ACPI 3.0 specs.
Signed-off-by: Michael Hanselmann [EMAIL PROTECTED]
Greets,
Michael
---
Index: hw/acpi.c
===
RCS file: /sources/qemu/qemu/hw/acpi.c,v
retrieving revision 1.12
diff -u -b -B -r1.12 acpi.c
--- hw/acpi.c 28 May 2007 21:01:02 - 1.12
+++ hw/acpi.c 26 Jun 2007 20:29:19 -
@@ -54,6 +54,9 @@
#define SUS_EN (1 13)
+#define ACPI_ENABLE 0xf1
+#define ACPI_DISABLE 0xf0
+
#define SMBHSTSTS 0x00
#define SMBHSTCNT 0x02
#define SMBHSTCMD 0x03
@@ -216,6 +219,14 @@
#endif
if (addr == 0) {
s-apmc = val;
+
+/* ACPI specs 3.0, 4.7.2.5 */
+if (val == ACPI_ENABLE) {
+s-pmcntrl |= SCI_EN;
+} else if (val == ACPI_DISABLE) {
+s-pmcntrl = ~SCI_EN;
+}
+
if (s-dev.config[0x5b] (1 1)) {
cpu_interrupt(first_cpu, CPU_INTERRUPT_SMI);
}
Re: [Qemu-devel] [PATCH] Fix two typos
Since when is teh a typo??? It's teh [EMAIL PROTECTED] On 6/26/07, Stefan Weil [EMAIL PROTECTED] wrote: The appended patch fixes recieve - receive, seperat - separat and teh - the. Maybe this makes addition to CVS HEAD easier... Stefan Bernhard Fischer schrieb: On Tue, Jun 26, 2007 at 07:19:53PM +0200, Stefan Weil wrote: Hi, here is another patch which changes additionnal - additional. Please apply this new patch and my last one to CVS HEAD. A few others, fwiw: s/recieve/receive/g s/seperat/separat/g /[[:space:]]teh[[:space:]]/ the /g cheers, -- -- Jonathan Kalbfeld +1 323 620 6682
Re: [Qemu-devel] [PATCH] Fix two typos
On 26/06/07, Jonathan Kalbfeld [EMAIL PROTECTED] wrote: Since when is teh a typo??? It's teh [EMAIL PROTECTED] It even has a wikipedia page, http://en.wikipedia.org/wiki/Teh On 6/26/07, Stefan Weil [EMAIL PROTECTED] wrote: The appended patch fixes recieve - receive, seperat - separat and teh - the. Maybe this makes addition to CVS HEAD easier... Stefan Bernhard Fischer schrieb: On Tue, Jun 26, 2007 at 07:19:53PM +0200, Stefan Weil wrote: Hi, here is another patch which changes additionnal - additional. Please apply this new patch and my last one to CVS HEAD. A few others, fwiw: s/recieve/receive/g s/seperat/separat/g /[[:space:]]teh[[:space:]]/ the /g cheers, -- -- Jonathan Kalbfeld +1 323 620 6682 Regards,
[Qemu-devel] rtl8139 not working with VISTA 32bit
I have posted/read other posts regarding rtl8139 in qemu not working with VISTA 32bit. Does any one know if there is a fix for this one? I have tried to debug this, but not sure what is VISTA 32bit driver is expecting. Qemu writes rx buffers to guest memory, but it looks like they are ignored by the guest rtl8139 driver. Any Ideas of what is going on? Regards Adnan
[Qemu-devel] Emulation: Building solid files
Hi beastcoders, My question is if you are thinking in improve Qemu to add singular characteristics whose aren't implemented in any VM sofware: I.E.: Building virtual machines taking only one big binary file (merging Qemu engine and HD image file). It could be good for future portable aplications. I thought this because I'm triying to do the simplest-ultra-secure Internet navigatior. The idea is to generate a VM (with the lightest/functional O.S. posibility and increase speed at top) to content a Firefox installation (with the most used complements into it). The main is to load all this VM into the RAM and when it will turn off, it never has to save the session changes, it allways must start at the beginning point. Sorry, allways not. Sessions only will be modified in security-updates and/or Firefox-complements. Troyans, virus, spyware... will be better managed by people who hasn't any idea in computers, because I wan't to transmit the simplest concept: If you want to use the Internet to do critical operations and you are very scared by hackers, virus... because you hasn't any idea of manage security in computers, you only have to run another VM-Firefox to enter in I.E: bank sites and don't worry because you are keeped by the security of a castle I only want if you will implement that kind of emulation. REGARDS
Re: [Qemu-devel] Emulation: Building solid files
you could pack the binaries and the image into a 7-zip sfx (but that is for windows hosts only). just google for it and you'll get the procedure. I've done it a few times already. what is your host ? linux or windows ? On 6/27/07, NetAudi [EMAIL PROTECTED] wrote: Hi beastcoders, My question is if you are thinking in improve Qemu to add singular characteristics whose aren't implemented in any VM sofware: I.E.: Building virtual machines taking only one big binary file (merging Qemu engine and HD image file). It could be good for future portable aplications. I thought this because I'm triying to do the simplest-ultra-secure Internet navigatior. The idea is to generate a VM (with the lightest/functional O.S. posibility and increase speed at top) to content a Firefox installation (with the most used complements into it). The main is to load all this VM into the RAM and when it will turn off, it never has to save the session changes, it allways must start at the beginning point. Sorry, allways not. Sessions only will be modified in security-updates and/or Firefox-complements. Troyans, virus, spyware... will be better managed by people who hasn't any idea in computers, because I wan't to transmit the simplest concept: If you want to use the Internet to do critical operations and you are very scared by hackers, virus... because you hasn't any idea of manage security in computers, you only have to run another VM-Firefox to enter in I.E: bank sites and don't worry because you are keeped by the security of a castle I only want if you will implement that kind of emulation. REGARDS -- Christian -- http://detaolb.sourceforge.net/, a linux distribution for Qemu
Re: [Qemu-devel] sparc guest
Blue Swirl wrote: On 6/25/07, Thiemo Seufer [EMAIL PROTECTED] wrote: Nigel Horne wrote: Good news, sparc emulation with -nographic no longer core dumps. The bad news, networking still fails: FYI, I see a transmit error for ne2k_isa on mips r4k. Maybe that's related. On my test cases the network is still fine. What was the setup again? What I see is apparently not triggered by a change in Qemu. An older 2.6.16 kernel works with current Qemu, but 2.6.21 breaks networking. The setup is basically the big endian mips regression test initrd with a newer kernel. Thiemo
Re: [Qemu-devel] Emulation: Building solid files
You could do that with a shar. That's sick and wrong, but cool. Problem I have with anything else is that in Solaris 10, you can't statically link anything any more so it would have to unarchive itself to a separate location and run. On 6/26/07, NetAudi [EMAIL PROTECTED] wrote: Hi beastcoders, My question is if you are thinking in improve Qemu to add singular characteristics whose aren't implemented in any VM sofware: I.E.: Building virtual machines taking only one big binary file (merging Qemu engine and HD image file). It could be good for future portable aplications. I thought this because I'm triying to do the simplest-ultra-secure Internet navigatior. The idea is to generate a VM (with the lightest/functional O.S. posibility and increase speed at top) to content a Firefox installation (with the most used complements into it). The main is to load all this VM into the RAM and when it will turn off, it never has to save the session changes, it allways must start at the beginning point. Sorry, allways not. Sessions only will be modified in security-updates and/or Firefox-complements. Troyans, virus, spyware... will be better managed by people who hasn't any idea in computers, because I wan't to transmit the simplest concept: If you want to use the Internet to do critical operations and you are very scared by hackers, virus... because you hasn't any idea of manage security in computers, you only have to run another VM-Firefox to enter in I.E: bank sites and don't worry because you are keeped by the security of a castle I only want if you will implement that kind of emulation. REGARDS -- -- Jonathan Kalbfeld +1 323 620 6682
