Re: [Qemu-devel] [PATCH 2 of 3] Optionally link against libuuid if present
Filip Navara wrote: > Hi Ryan & others, > > now I have been holding a SMBIOS patch on my hard disk for way to long it > seems. I used a different approach from yours, so I decided to publish it > for review or further ideas. What I did was to modify the bochs bios to > produce the SMBIOS tables and I get the UUID using VMware backdoor port from > the virtual machine. > > Attached are just the changed files, creating a patch will take a while > because it's against VERY OLD version of the sources. > > Oh, it also contains ACPI patch for the processor descriptors which was > needed for some Windows versions and Darwin. Similar patch was used in KVM > before, but this one dynamically detects the number of CPUs. I strongly prefer your solution (Bochs BIOS) compared to modifying QEMU: I already spent a lot of time moving the ACPI tables and other stuff to the Bochs BIOS just for that ! Regards, Fabrice.
Re: [Qemu-devel] [PATCH] arm eabi TLS
Thayne Harbaugh wrote: > I believe Paul Brook did the original patch for arm eabi TLS. The patch > has bounced around for a bit but hasn't been applied. We've been using > this patch for a while and have tweaked it to be a bit more correct as > far as code organization. > > Please let me know what else should be improved for this so that it can > be applied. - the clone() syscall must be disabled when it is used to create a thread because it cannot work reliably in its current state. - the system to intercept calls to the syscall page must be made more generic to be used at least by arm user and x86_64 user. - It would be good to limit the changes in the CPU emulation code to handle the TLS. For example, on MIPS, the TLS register must not be stored in the CPU state. Same for ARM. Regards, Fabrice.
Re: [Qemu-devel] [PATCH] arm eabi TLS
Paul Brook wrote: - It would be good to limit the changes in the CPU emulation code to handle the TLS. For example, on MIPS, the TLS register must not be stored in the CPU state. Same for ARM. I disagree. The TLS register is part of the CPU state. On many machines (including ARMv6 CPUs) it's an actual CPU register. I'm fairly sure the same is true for recent MIPS revisions. If some CPUs implement it in hardware, then I agree. Fabrice.
Re: [Qemu-devel] [PATCH 2/2 v2][UPDATED] Direct IDE I/O
Laurent Vivier wrote: > This patch enhances the "-drive ,cache=off" mode with IDE drive emulation > by removing the buffer used in the IDE emulation. > --- > block.c | 10 +++ > block.h |2 > block_int.h |1 > cpu-all.h |1 > exec.c | 19 ++ > hw/ide.c| 176 > +--- > vl.c|1 > 7 files changed, 204 insertions(+), 6 deletions(-) > [...] Unfortunately it is more complicated to write to the CPU memory. In particular, specific action should be done when translated code is present. A consistent API must include something like cpu_page_lock() / unlock(). Look at cpu_physical_memory_rw() to see the various issues which must be handled. Moreover, it would be better to add bus specific APIs (at least for PCI), but I can accept a CPU memory API for now. Fabrice.
Re: [Qemu-devel] [PATCH 1/2 v2][UPDATE] Add "cache" parameter to "-drive"
Laurent Vivier wrote: > This patch adds a new parameter to "-drive" > > Using "cache=off" with "-drive" will open the disk image file using > "O_DIRECT". > > By default, "cache" is set to "on" to keep original behavior of qemu. > > example: > > "-drive file=my_disk.qcow2,cache=off" > --- > block-raw-posix.c |8 > block-raw-win32.c |4 > block.c |2 +- > block.h |1 + > hw/fdc.c |7 ++- > hw/ide.c | 18 ++ > hw/scsi-disk.c|3 ++- > hw/sd.c | 11 ++- > osdep.c | 20 > osdep.h |1 + > vl.c | 28 > 11 files changed, 91 insertions(+), 12 deletions(-) > [...] I suggest trying to remove the malloc/free which are done at every blk_read/write for sd.c. Fabrice.
Re: [Qemu-devel] qemu cpu-all.h exec.c
Blue Swirl wrote: > CVSROOT: /cvsroot/qemu > Module name: qemu > Changes by: Blue Swirl 08/01/01 16:57:19 > > Modified files: > . : cpu-all.h exec.c > > Log message: >Support for registering address space only for some access widths > > CVSWeb URLs: > http://cvs.savannah.gnu.org/viewcvs/qemu/cpu-all.h?cvsroot=qemu&r1=1.80&r2=1.81 > http://cvs.savannah.gnu.org/viewcvs/qemu/exec.c?cvsroot=qemu&r1=1.120&r2=1.121 This patch breaks the behaviour of the memory callbacks if the callbacks are changed dynamically (see cirrus_update_memory_access() to see what I mean). You are lucky that no one does that in the subpage case ! Regards, Fabrice.
Re: [Qemu-devel] qemu cpu-all.h exec.c
Blue Swirl wrote: On 1/3/08, Paul Brook <[EMAIL PROTECTED]> wrote: On Wednesday 02 January 2008, Blue Swirl wrote: On 1/2/08, Paul Brook <[EMAIL PROTECTED]> wrote: Also the opaque parameter may need to be different for each function, it just didn't matter for the unassigned memory case. Do you really have systems where independent devices need to respond to different sized accesses to the same address? I don't think so. But one day unassigned or even normal RAM memory access may need an opaque parameter, so passing the device's opaque to unassigned memory handler is wrong. I'm not convinced. Your current implementation seems to introduce an extra level of indirection without any plausible benefit. If you're treating unassigned memory differently it needs to be handled much earlier that so you can raise CPU exceptions. Earlier, where's that? Another approach could be conditional stacked handlers, where a higher level handler could pass the access request to lower one (possibly modifying it in flight) or handle completely. Maybe this solves the longstanding generic DMA issue if taken to the device to memory direction. As I said earlier, the only correct way to handle memory accesses is to be able to consider a memory range and its associated I/O callbacks as an object which can be installed _and_ removed. It implies that there is a priority system close to what you described. It is essential to correct long standing PCI bugs for example. Regards, Fabrice.
[Qemu-devel] qemu Changelog VERSION
CVSROOT:/sources/qemu Module name:qemu Changes by: Fabrice Bellard08/01/06 17:10:54 Modified files: . : Changelog VERSION Log message: version change CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/Changelog?cvsroot=qemu&r1=1.150&r2=1.151 http://cvs.savannah.gnu.org/viewcvs/qemu/VERSION?cvsroot=qemu&r1=1.31&r2=1.32
[Qemu-devel] qemu qemu-img.c vl.c linux-user/main.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Fabrice Bellard08/01/06 17:21:49 Modified files: . : qemu-img.c vl.c linux-user : main.c Log message: copyright update CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/qemu-img.c?cvsroot=qemu&r1=1.27&r2=1.28 http://cvs.savannah.gnu.org/viewcvs/qemu/vl.c?cvsroot=qemu&r1=1.393&r2=1.394 http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/main.c?cvsroot=qemu&r1=1.158&r2=1.159
[Qemu-devel] qemu Makefile
CVSROOT:/sources/qemu Module name:qemu Changes by: Fabrice Bellard08/01/06 18:27:12 Modified files: . : Makefile Log message: update binary distribution CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/Makefile?cvsroot=qemu&r1=1.139&r2=1.140
[Qemu-devel] qemu configure Makefile.target
CVSROOT:/sources/qemu Module name:qemu Changes by: Fabrice Bellard08/01/06 18:27:58 Modified files: . : configure Makefile.target Log message: fixed ppc64abi32 executable name CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/configure?cvsroot=qemu&r1=1.177&r2=1.178 http://cvs.savannah.gnu.org/viewcvs/qemu/Makefile.target?cvsroot=qemu&r1=1.237&r2=1.238
Re: [Qemu-devel] [PATCH] SCSI passthrough: DVD support
Can you explain why you use the block layer (block-raw-posix.c) to send
your low level SCSI commands ? I suggest to remove your patches to
block-raw-posix.c and to implement all the SCSI passthough in
scsi-generic.c.
Regards,
Fabrice.
Laurent Vivier wrote:
> This patch allows to use SCSI passthrough to read movies from DVD.
> It has been tested with PowerDVD and XP.
>
> It also introduces some comments in block-raw-posix.c to explain behavior of
> negative offset and negative nb_sectors.
> It restores original value of aio_num and aio_threads.
>
> Laurent
> ---
> block-raw-posix.c |7 +--
> hw/scsi-generic.c | 14 --
> 2 files changed, 17 insertions(+), 4 deletions(-)
>
> Index: qemu/hw/scsi-generic.c
> ===
> --- qemu.orig/hw/scsi-generic.c 2008-01-06 18:43:44.0 +0100
> +++ qemu/hw/scsi-generic.c2008-01-06 18:55:46.0 +0100
> @@ -44,9 +44,12 @@ do { fprintf(stderr, "scsi-generic: " fm
> #include
> #include
>
> +#define BLANK 0xa1
> +#define SEND_KEY 0xa3
> +#define REPORT_KEY 0xa4
> #define LOAD_UNLOAD 0xa6
> +#define READ_DVD_STRUCTURE 0xad
> #define SET_CD_SPEED 0xbb
> -#define BLANK 0xa1
>
> #define SCSI_CMD_BUF_SIZE 16
> #define SCSI_SENSE_BUF_SIZE 32
> @@ -166,7 +169,7 @@ static void scsi_command_complete(void *
> sense = s->sensebuf[2] & 0x0f;
> }
>
> -DPRINTF("Command complete 0x%p tag=0x%x sense=%d\n", r, r->tag, sense);
> +DPRINTF("Command complete %p tag=0x%x sense=%d\n", r, r->tag, sense);
> tag = r->tag;
> scsi_remove_request(r);
> s->completion(s->opaque, SCSI_REASON_DONE, tag, sense);
> @@ -427,6 +430,12 @@ static int scsi_length(uint8_t *cmd, int
> case READ_12:
> *len *= blocksize;
> break;
> + case READ_DVD_STRUCTURE:
> + case SEND_KEY:
> + case REPORT_KEY:
> + *len &= 0x;
> + break;
> +
> }
> return 0;
> }
> @@ -464,6 +473,7 @@ static int is_write(int command)
> case MEDIUM_SCAN:
> case SEND_VOLUME_TAG:
> case WRITE_LONG_2:
> +case SEND_KEY:
> return 1;
> }
> return 0;
> Index: qemu/block-raw-posix.c
> ===
> --- qemu.orig/block-raw-posix.c 2008-01-06 18:43:44.0 +0100
> +++ qemu/block-raw-posix.c2008-01-06 18:45:38.0 +0100
> @@ -151,6 +151,8 @@ static int raw_pread(BlockDriverState *b
> if (ret < 0)
> return ret;
>
> +/* if offset < 0, we don't make lseek() */
> +
> if (offset >= 0 && lseek(s->fd, offset, SEEK_SET) == (off_t)-1) {
> ++(s->lseek_err_cnt);
> if(s->lseek_err_cnt <= 10) {
> @@ -276,8 +278,8 @@ void qemu_aio_init(void)
> seems to fix the problem. */
> struct aioinit ai;
> memset(&ai, 0, sizeof(ai));
> -ai.aio_threads = 16;
> -ai.aio_num = 16;
> +ai.aio_threads = 1;
> +ai.aio_num = 1;
> ai.aio_idle_time = 365 * 10;
> aio_init(&ai);
> }
> @@ -387,6 +389,7 @@ static RawAIOCB *raw_aio_setup(BlockDriv
> acb->aiocb.aio_sigevent.sigev_signo = aio_sig_num;
> acb->aiocb.aio_sigevent.sigev_notify = SIGEV_SIGNAL;
> acb->aiocb.aio_buf = buf;
> +/* if nb_sectors < 0, -nb_sectors is a number of bytes */
> if (nb_sectors < 0)
> acb->aiocb.aio_nbytes = -nb_sectors;
> else
>
>
>
>
[Qemu-devel] qemu block-raw-posix.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Fabrice Bellard08/01/06 18:53:07 Modified files: . : block-raw-posix.c Log message: restore original values for ai.aio_threads and ai.aio_num CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/block-raw-posix.c?cvsroot=qemu&r1=1.3&r2=1.4
[Qemu-devel] QEMU version 0.9.1
Hi, QEMU version 0.9.1 is out ! You can get it from: http://bellard.org/qemu/download.html . Fabrice.
Re: [Qemu-devel] [PATCH 1/5] Fix i386 Host
Alexander Graf wrote: This patch is mostly a cleanup of Michael Matz's patch with the ideas that came last time included. I must say I don't like such patches because they are likely to break with every new GCC version. Moreover, I will commit in the next few days a new code generator in QEMU which will utimately solve the compilation problems. In its current form it still relies on "dyngen" so that legacy micro operations still work, but in the end dyngen will be completely suppressed. A side effect of these commits will be that only the x86 and x86_64 hosts will be supported during some time. Regards, Fabrice.
[Qemu-devel] qemu softmmu_header.h
CVSROOT:/sources/qemu Module name:qemu Changes by: Fabrice Bellard08/01/21 15:07:18 Modified files: . : softmmu_header.h Log message: fixed register constraint CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/softmmu_header.h?cvsroot=qemu&r1=1.18&r2=1.19
Re: [Qemu-devel] qemu softmmu_header.h
Johannes Schindelin wrote: Hi, On Mon, 21 Jan 2008, Fabrice Bellard wrote: CVSROOT:/sources/qemu Module name:qemu Changes by: Fabrice Bellard 08/01/21 15:07:18 Modified files: . : softmmu_header.h Log message: fixed register constraint CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/softmmu_header.h?cvsroot=qemu&r1=1.18&r2=1.19 As has been pointed out already, this breaks compilation _at least_ with gcc 3.4.2 on MinGW. If it does, it is a very weird gcc bug. The previous code was clearly incorrect. Fabrice.
Re: [Qemu-devel] [PATCH 0/5] SCSI passthrough cleanup
Two questions: - Why do you use AIO ? If the Linux sg device supports selects, then using the QEMU select() callback suffices. - Why do you use a block device ? Regards, Fabrice. Laurent Vivier wrote: > This series of patches makes some cleanups in SCSI passthrough and > add functionnalities. > > [PATCH 1/5] reverse scsi-generic > > Reverse previous implementation and restore block-raw-posix.c. > > [PATCH 2/5] Move AIO > > This patche moves raw AIO part from block-raw-posix.c to qemu-aio-raw.c. > > [PATCH 3/5] Add block SG interface > > This patch re-implement scsi-generic.c using a new block interface. > > [PATCH 4/5] DVD movie support > > This patch allows to read a protected/encrypted movie from a DVD. > > [PATCH 5/5] SCSI device DMA split > > This patch allows to split a READ or WRITE into several READ or WRITE. > > Laurent > > > > >
[Qemu-devel] qemu softmmu_template.h softmmu_header.h osdep....
CVSROOT:/sources/qemu Module name:qemu Changes by: Fabrice Bellard08/01/31 09:22:27 Modified files: . : softmmu_template.h softmmu_header.h osdep.h cpu-defs.h Log message: use simpler REGPARM convention - make CPUTLBEntry size a power of two CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/softmmu_template.h?cvsroot=qemu&r1=1.21&r2=1.22 http://cvs.savannah.gnu.org/viewcvs/qemu/softmmu_header.h?cvsroot=qemu&r1=1.19&r2=1.20 http://cvs.savannah.gnu.org/viewcvs/qemu/osdep.h?cvsroot=qemu&r1=1.13&r2=1.14 http://cvs.savannah.gnu.org/viewcvs/qemu/cpu-defs.h?cvsroot=qemu&r1=1.28&r2=1.29
[Qemu-devel] qemu i386-vl.ld
CVSROOT:/sources/qemu Module name:qemu Changes by: Fabrice Bellard08/01/31 10:43:14 Removed files: . : i386-vl.ld Log message: removed unused file CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/i386-vl.ld?cvsroot=qemu&r1=1.3&r2=0
[Qemu-devel] qemu Makefile Makefile.target configure
CVSROOT:/sources/qemu Module name:qemu Changes by: Fabrice Bellard08/01/31 11:32:10 Modified files: . : Makefile Makefile.target configure Log message: Makefile cleanup - more generic support of 32 bit compilation on x86_64 CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/Makefile?cvsroot=qemu&r1=1.143&r2=1.144 http://cvs.savannah.gnu.org/viewcvs/qemu/Makefile.target?cvsroot=qemu&r1=1.240&r2=1.241 http://cvs.savannah.gnu.org/viewcvs/qemu/configure?cvsroot=qemu&r1=1.182&r2=1.183
[Qemu-devel] qemu/tests test-i386.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Fabrice Bellard08/01/31 14:56:10 Modified files: tests : test-i386.c Log message: compilation fixes - added bswap - comments CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/tests/test-i386.c?cvsroot=qemu&r1=1.56&r2=1.57
[Qemu-devel] qemu/tests Makefile
CVSROOT:/sources/qemu Module name:qemu Changes by: Fabrice Bellard08/01/31 15:19:24 Modified files: tests : Makefile Log message: compilation fix CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/tests/Makefile?cvsroot=qemu&r1=1.44&r2=1.45
[Qemu-devel] qemu/tests test-i386-code16.S
CVSROOT:/sources/qemu Module name:qemu Changes by: Fabrice Bellard08/01/31 15:19:39 Modified files: tests : test-i386-code16.S Log message: suppressed warnings CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/tests/test-i386-code16.S?cvsroot=qemu&r1=1.5&r2=1.6
[Qemu-devel] qemu/tcg/x86_64
CVSROOT:/sources/qemu Module name:qemu Changes by: Fabrice Bellard08/02/01 10:03:48 New directory: tcg/x86_64 CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/tcg/x86_64/?cvsroot=qemu
[Qemu-devel] qemu/tcg LICENSE README TODO tcg-dyngen.c tcg-o...
CVSROOT:/sources/qemu Module name:qemu Changes by: Fabrice Bellard08/02/01 10:05:41 Added files: tcg: LICENSE README TODO tcg-dyngen.c tcg-op.h tcg-opc.h tcg-runtime.c tcg.c tcg.h tcg/i386 : tcg-target.c tcg-target.h tcg/x86_64 : tcg-target.c tcg-target.h Log message: TCG code generator CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/tcg/LICENSE?cvsroot=qemu&rev=1.1 http://cvs.savannah.gnu.org/viewcvs/qemu/tcg/README?cvsroot=qemu&rev=1.1 http://cvs.savannah.gnu.org/viewcvs/qemu/tcg/TODO?cvsroot=qemu&rev=1.1 http://cvs.savannah.gnu.org/viewcvs/qemu/tcg/tcg-dyngen.c?cvsroot=qemu&rev=1.1 http://cvs.savannah.gnu.org/viewcvs/qemu/tcg/tcg-op.h?cvsroot=qemu&rev=1.1 http://cvs.savannah.gnu.org/viewcvs/qemu/tcg/tcg-opc.h?cvsroot=qemu&rev=1.1 http://cvs.savannah.gnu.org/viewcvs/qemu/tcg/tcg-runtime.c?cvsroot=qemu&rev=1.1 http://cvs.savannah.gnu.org/viewcvs/qemu/tcg/tcg.c?cvsroot=qemu&rev=1.1 http://cvs.savannah.gnu.org/viewcvs/qemu/tcg/tcg.h?cvsroot=qemu&rev=1.1 http://cvs.savannah.gnu.org/viewcvs/qemu/tcg/i386/tcg-target.c?cvsroot=qemu&rev=1.1 http://cvs.savannah.gnu.org/viewcvs/qemu/tcg/i386/tcg-target.h?cvsroot=qemu&rev=1.1 http://cvs.savannah.gnu.org/viewcvs/qemu/tcg/x86_64/tcg-target.c?cvsroot=qemu&rev=1.1 http://cvs.savannah.gnu.org/viewcvs/qemu/tcg/x86_64/tcg-target.h?cvsroot=qemu&rev=1.1
[Qemu-devel] qemu/tcg
CVSROOT:/sources/qemu Module name:qemu Changes by: Fabrice Bellard08/02/01 10:03:35 New directory: tcg CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/tcg/?cvsroot=qemu
[Qemu-devel] Re: [PATCH 6/6] QEMU support for the Kernel Virtual Machine interface
Anthony Liguori wrote: This patch actually enables KVM support for QEMU. I apologize that it is so large but this was the only sane way to preserve bisectability. The goal of this patch is to add KVM support, but not to impact users when KVM isn't being used. It achieves this by using a kvm_enabled() macro that evaluates to (0) when KVM support is not enabled. An if (kvm_enabled()) is just as good as using an #ifdef since GCC will eliminate the dead code. This patches touches a lot of areas. For performance reasons, the guest CPU state is not kept in sync with CPUState. This requires an explicit synchronization whenever CPUState is required. KVM also uses it's own main loop as it runs each VCPU in it's own thread. Trapping VGA updates via MMIO is far too slow when running KVM so there is additional logic to allow VGA memory to be accessed as RAM. We use KVM's shadow page tables to keep track of which portions of RAM have been dirtied. KVM also supports an in-kernel APIC implementation as a performance enhancement. Finally, KVM supports APIC TPR patching. This allows TPR accesses (which are very frequently for Windows) to be patches into CALL instructions to the BIOS (for 32-bit guests). This results in a very sigificant performance improvement for Windows guests. While this patch is very large, the new files are only included when KVM support is compiled in. Every change to QEMU is wrapped in an if (kvm_enabled()) so the code disappears when KVM support is not compiled in. This is done to ensure no regressions are introduced to normal QEMU. Some questions: - QEMU already maintains modified page status for VGA memory (and kqemu for example fully supports that), so I don't see why KVM needs a new method. - Why is kvm_cpu_register_physical_memory() needed ? kqemu can work without it because there is a remapping between physical memory and RAM address. I suggest to add that feature in KVM or to modify cpu_register_physical_memory() to hide it. - If KVM implements its own CPU loop, why are there patches in libqemu.a (CPU core) ? Regards, Fabrice.
[Qemu-devel] qemu Makefile
CVSROOT:/sources/qemu Module name:qemu Changes by: Fabrice Bellard08/02/01 10:02:52 Modified files: . : Makefile Log message: typo CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/Makefile?cvsroot=qemu&r1=1.144&r2=1.145
[Qemu-devel] qemu TODO
CVSROOT:/sources/qemu Module name:qemu Changes by: Fabrice Bellard08/02/01 10:03:18 Modified files: . : TODO Log message: update CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/TODO?cvsroot=qemu&r1=1.40&r2=1.41
[Qemu-devel] qemu/tcg/i386
CVSROOT:/sources/qemu Module name:qemu Changes by: Fabrice Bellard08/02/01 10:03:47 New directory: tcg/i386 CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/tcg/i386/?cvsroot=qemu
[Qemu-devel] Re: [PATCH 1/6] Use correct types to enable > 2G support
Anthony Liguori wrote:
KVM supports more than 2GB of memory for x86_64 hosts. The following patch
fixes a number of type related issues where int's were being used when they
shouldn't have been. It also introduces CMOS support so the BIOS can build
the appropriate e820 tables.
> [...]
+/* above 4giga memory allocation */
+if (above_4g_mem_size > 0) {
+ram_addr = qemu_ram_alloc(above_4g_mem_size);
+cpu_register_physical_memory(0x1, above_4g_mem_size, ram_addr);
+}
+
Why do you need this ? All the RAM can be registered with a single call.
I fear you need to do that because of KVM RAM handling limitations.
Index: qemu/osdep.c
===
--- qemu.orig/osdep.c 2008-01-30 13:47:00.0 -0600
+++ qemu/osdep.c2008-01-30 13:47:31.0 -0600
@@ -113,7 +113,7 @@
int64_t free_space;
int ram_mb;
-extern int ram_size;
+extern int64_t ram_size;
free_space = (int64_t)stfs.f_bavail * stfs.f_bsize;
if ((ram_size + 8192 * 1024) >= free_space) {
ram_mb = (ram_size / (1024 * 1024));
@@ -202,7 +202,7 @@
#ifdef _BSD
return valloc(size);
#else
-return memalign(4096, size);
+return memalign(TARGET_PAGE_SIZE, size);
#endif
}
No fully correct because it is intended to be the host page size.
+extern int64_t ram_size;
I agree with the fact that ram_size should be 64 bit. Maybe each machine
could test the value and emit an error message if it is too big. Maybe
an uint64_t would be better though.
Fabrice.
[Qemu-devel] qemu LICENSE Makefile.target configure cpu-all....
CVSROOT:/sources/qemu Module name:qemu Changes by: Fabrice Bellard08/02/01 10:50:12 Modified files: . : LICENSE Makefile.target configure cpu-all.h cpu-defs.h cpu-exec.c dyngen.c exec-all.h exec.c translate-all.c target-alpha : op.c translate.c target-arm : op.c translate.c target-cris: op.c translate.c target-i386: exec.h helper.c op.c opreg_template.h translate.c target-m68k: op.c translate.c target-mips: op.c translate.c target-ppc : op.c translate.c target-sh4 : op.c translate.c target-sparc : op.c translate.c Added files: target-i386: helper.h Removed files: . : dyngen-op.h dyngen.h translate-op.c Log message: use the TCG code generator CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/LICENSE?cvsroot=qemu&r1=1.3&r2=1.4 http://cvs.savannah.gnu.org/viewcvs/qemu/Makefile.target?cvsroot=qemu&r1=1.241&r2=1.242 http://cvs.savannah.gnu.org/viewcvs/qemu/configure?cvsroot=qemu&r1=1.183&r2=1.184 http://cvs.savannah.gnu.org/viewcvs/qemu/cpu-all.h?cvsroot=qemu&r1=1.82&r2=1.83 http://cvs.savannah.gnu.org/viewcvs/qemu/cpu-defs.h?cvsroot=qemu&r1=1.29&r2=1.30 http://cvs.savannah.gnu.org/viewcvs/qemu/cpu-exec.c?cvsroot=qemu&r1=1.131&r2=1.132 http://cvs.savannah.gnu.org/viewcvs/qemu/dyngen.c?cvsroot=qemu&r1=1.59&r2=1.60 http://cvs.savannah.gnu.org/viewcvs/qemu/exec-all.h?cvsroot=qemu&r1=1.73&r2=1.74 http://cvs.savannah.gnu.org/viewcvs/qemu/exec.c?cvsroot=qemu&r1=1.122&r2=1.123 http://cvs.savannah.gnu.org/viewcvs/qemu/translate-all.c?cvsroot=qemu&r1=1.24&r2=1.25 http://cvs.savannah.gnu.org/viewcvs/qemu/dyngen-op.h?cvsroot=qemu&r1=1.1&r2=0 http://cvs.savannah.gnu.org/viewcvs/qemu/dyngen.h?cvsroot=qemu&r1=1.18&r2=0 http://cvs.savannah.gnu.org/viewcvs/qemu/translate-op.c?cvsroot=qemu&r1=1.4&r2=0 http://cvs.savannah.gnu.org/viewcvs/qemu/target-alpha/op.c?cvsroot=qemu&r1=1.5&r2=1.6 http://cvs.savannah.gnu.org/viewcvs/qemu/target-alpha/translate.c?cvsroot=qemu&r1=1.8&r2=1.9 http://cvs.savannah.gnu.org/viewcvs/qemu/target-arm/op.c?cvsroot=qemu&r1=1.28&r2=1.29 http://cvs.savannah.gnu.org/viewcvs/qemu/target-arm/translate.c?cvsroot=qemu&r1=1.59&r2=1.60 http://cvs.savannah.gnu.org/viewcvs/qemu/target-cris/op.c?cvsroot=qemu&r1=1.3&r2=1.4 http://cvs.savannah.gnu.org/viewcvs/qemu/target-cris/translate.c?cvsroot=qemu&r1=1.3&r2=1.4 http://cvs.savannah.gnu.org/viewcvs/qemu/target-i386/exec.h?cvsroot=qemu&r1=1.40&r2=1.41 http://cvs.savannah.gnu.org/viewcvs/qemu/target-i386/helper.c?cvsroot=qemu&r1=1.98&r2=1.99 http://cvs.savannah.gnu.org/viewcvs/qemu/target-i386/op.c?cvsroot=qemu&r1=1.52&r2=1.53 http://cvs.savannah.gnu.org/viewcvs/qemu/target-i386/opreg_template.h?cvsroot=qemu&r1=1.4&r2=1.5 http://cvs.savannah.gnu.org/viewcvs/qemu/target-i386/translate.c?cvsroot=qemu&r1=1.76&r2=1.77 http://cvs.savannah.gnu.org/viewcvs/qemu/target-i386/helper.h?cvsroot=qemu&rev=1.1 http://cvs.savannah.gnu.org/viewcvs/qemu/target-m68k/op.c?cvsroot=qemu&r1=1.14&r2=1.15 http://cvs.savannah.gnu.org/viewcvs/qemu/target-m68k/translate.c?cvsroot=qemu&r1=1.22&r2=1.23 http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/op.c?cvsroot=qemu&r1=1.90&r2=1.91 http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/translate.c?cvsroot=qemu&r1=1.120&r2=1.121 http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/op.c?cvsroot=qemu&r1=1.68&r2=1.69 http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/translate.c?cvsroot=qemu&r1=1.115&r2=1.116 http://cvs.savannah.gnu.org/viewcvs/qemu/target-sh4/op.c?cvsroot=qemu&r1=1.10&r2=1.11 http://cvs.savannah.gnu.org/viewcvs/qemu/target-sh4/translate.c?cvsroot=qemu&r1=1.21&r2=1.22 http://cvs.savannah.gnu.org/viewcvs/qemu/target-sparc/op.c?cvsroot=qemu&r1=1.46&r2=1.47 http://cvs.savannah.gnu.org/viewcvs/qemu/target-sparc/translate.c?cvsroot=qemu&r1=1.85&r2=1.86
[Qemu-devel] TCG
Hi, I added a new code generator (TCG) in QEMU. Read the file qemu/tcg/README to have technical information. A new code generator was needed in order to avoid problems with the various GCC versions and to get better performance. I made minimal modifications in each target so that they can still work by using TCG and legacy "dyngen" micro operations. More work will be needed to convert each target to TCG, but it can be done progressively. Only the x86 and x86_64 targets have been significantly modified to use TCG. TCG currently only supports x86 and x86_64 hosts. The support of other hosts is broken in QEMU. I don't consider it is a priority to support other hosts although TCG is generic enough to allow it. The performance should not change much at this point. On x86_64 hosts, the x86 and x86_64 targets are faster because of some assembly language optimizations. On x86 hosts, the x86_64 target is faster because TCG can do some optimizations related to the conversion from 64 to 32 bits. No performance change should be noticed on non x86 targets because they are not converted yet. Fabrice.
[Qemu-devel] qemu/tcg README
CVSROOT:/sources/qemu Module name:qemu Changes by: Fabrice Bellard08/02/01 13:01:47 Modified files: tcg: README Log message: typos CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/tcg/README?cvsroot=qemu&r1=1.1&r2=1.2
[Qemu-devel] Re: [PATCH 1/6] Use correct types to enable > 2G support
Paul Brook wrote: I agree with the fact that ram_size should be 64 bit. Maybe each machine could test the value and emit an error message if it is too big. Maybe an uint64_t would be better though. uint64_t is probably more reasonable. I wouldn't begin to know what the appropriate amount of ram was for each machine though so I'll let the appropriate people handle that :-) I'd say ram_addr_t is an appropriate type. Currently this is defined in cpu-defs.h. It should probably be moved elsewhere because in the current implementation it's really a host type. If we ever implement >2G ram on a 32-bit host this may need some rethinking. We can deal with that if/when it happens though. Requiring a 64-bit host for large quantities of ram seems an acceptable limitation (N.B. I'm only talking about ram size, not target physical address size). I agree. Fabrice.
[Qemu-devel] qemu cpu-all.h cpu-exec.c qemu-doc.texi vl.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Fabrice Bellard08/02/01 22:18:51 Modified files: . : cpu-all.h cpu-exec.c qemu-doc.texi vl.c Log message: reverted -translation option support CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/cpu-all.h?cvsroot=qemu&r1=1.83&r2=1.84 http://cvs.savannah.gnu.org/viewcvs/qemu/cpu-exec.c?cvsroot=qemu&r1=1.132&r2=1.133 http://cvs.savannah.gnu.org/viewcvs/qemu/qemu-doc.texi?cvsroot=qemu&r1=1.183&r2=1.184 http://cvs.savannah.gnu.org/viewcvs/qemu/vl.c?cvsroot=qemu&r1=1.401&r2=1.402
[Qemu-devel] qemu/tcg/x86_64 tcg-target.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Fabrice Bellard08/02/03 21:06:03 Modified files: tcg/x86_64 : tcg-target.c Log message: compare fix CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/tcg/x86_64/tcg-target.c?cvsroot=qemu&r1=1.1&r2=1.2
[Qemu-devel] qemu/tcg/i386 tcg-target.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Fabrice Bellard08/02/03 21:06:23 Modified files: tcg/i386 : tcg-target.c Log message: compare fix CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/tcg/i386/tcg-target.c?cvsroot=qemu&r1=1.1&r2=1.2
[Qemu-devel] qemu/tcg README tcg-op.h tcg-opc.h tcg.c tcg.h
CVSROOT:/sources/qemu Module name:qemu Changes by: Fabrice Bellard08/02/04 00:37:54 Modified files: tcg: README tcg-op.h tcg-opc.h tcg.c tcg.h Log message: fixed sign extensions - added explicit side effect op flag - added discard instruction CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/tcg/README?cvsroot=qemu&r1=1.2&r2=1.3 http://cvs.savannah.gnu.org/viewcvs/qemu/tcg/tcg-op.h?cvsroot=qemu&r1=1.2&r2=1.3 http://cvs.savannah.gnu.org/viewcvs/qemu/tcg/tcg-opc.h?cvsroot=qemu&r1=1.1&r2=1.2 http://cvs.savannah.gnu.org/viewcvs/qemu/tcg/tcg.c?cvsroot=qemu&r1=1.2&r2=1.3 http://cvs.savannah.gnu.org/viewcvs/qemu/tcg/tcg.h?cvsroot=qemu&r1=1.2&r2=1.3
[Qemu-devel] qemu/linux-user syscall.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Fabrice Bellard08/02/04 22:26:57 Modified files: linux-user : syscall.c Log message: lock_iovec() fix CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/syscall.c?cvsroot=qemu&r1=1.161&r2=1.162
[Qemu-devel] qemu/tcg tcg.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Fabrice Bellard08/02/04 22:03:16 Modified files: tcg: tcg.c Log message: win32: suppress alloca() warning CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/tcg/tcg.c?cvsroot=qemu&r1=1.3&r2=1.4
[Qemu-devel] qemu dyngen.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Fabrice Bellard08/02/04 22:00:42 Modified files: . : dyngen.c Log message: win32 fix CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/dyngen.c?cvsroot=qemu&r1=1.60&r2=1.61
Re: [Qemu-devel] [PATCH] OpenGL for OS X
Anthony Liguori wrote: Johannes Schindelin wrote: Hi, On Tue, 5 Feb 2008, Anthony Liguori wrote: I would really like to use OpenGL on non-Apple platforms. OpenGL gives much better scaling than SDL. Typically, and OpenGL app has very little platform specific code. It would be nice if we could use similar code here. But SDL runs on many more platforms than those which have OpenGL. So if at all, this should be optional, and not replace SDL. Absolutely. My thinking was just that if we're already going to have OpenGL code to support OS X (where SDL isn't an option), then we might as well make it so it's usable elsewhere. This is an SDL related issue (i.e. SDL may or may not use OpenGL to display graphics). Fixing SDL for Mac OS X would also be interesting. Regards, Fabrice.
[Qemu-devel] Re: [RESEND] TCG breakage if TARGET_LONG_BITS > HOST_LONG_BITS
Alexander Graf wrote: > This is a resend of a mail I sent to the list on 2008/02/06. I felt it > rather disturbing, yet normal that nobody cared about Mac OS X host > support, but this concerns all x86 host OSs, so I believe this deserves > some discussion. > > Hi, > > I've been trying to get the new TCG approach running on an i386 host. It > works when I use gcc3 (miraculously as I will explain later), but fails > on gcc4. > > On boot the very first instruction that gets issued is the ljmp to the > bios: > [...] > 1. Why is gcc3 generating code, that does not use ebx? > 2. Why does movi_i64 generate code that only accesses registers? I have > not been able to find any branch in the tcg code generator for movi_ixx > that generates movs to memory addresses. > > The whole issue could be easily fixed by using registers, but putting > the call into inline assembly, telling gcc that this call clobbers all > the registers. I do not know if this is the expected behavior though, so > I think I'd rather ask before doing any patches. The fact that it works in some cases is a miracle. The right solution is to use a global TB prologue and epilogue which saves and restores callee saved registers (it is in the tcg TODO list). A temporary solution before that would be to mark ebx, esi and edi as reserved registers if TARGET_LONG_BITS > HOST_LONG_BITS. Fabrice.
[Qemu-devel] Re: [PATCH, RFC, WIP] TCG for Qemu target Sparc32/64
Blue Swirl wrote: > The attached patch enables most TCG ops for Qemu Sparc32/64 target. > Sparc32 softmmu and linux-user are OK, but Sparc64 and Sparc32plus > targets do not work. > > Comments? > > It would be nice to get rid of T2 usage in std (also stda and > casa/casxa) but I don't know how to pass a 64-bit value from legacy op > to TCG stores and loads on a 32-bit target and host. [...] Also don't forget that T2 is used in CPU restore state to handle delay slots. This part of the SPARC target is tricky and should be simplified. Another point is that you should define TCG globals for each SPARC GPR. It was not done for i386 because I feared performance regressions when accessing to 16 bit or 8 bit sub-registers. On SPARC you do not have this issue. Regarding the generic "xxx_tl" defines, I did not move it into TCG because I wanted TCG to be target independent. Since it is no longer the case because of the target memory access instructions, I think it is a good idea now. But do not mix the target specific defines with target independent defines (in tcg-op.h there is a specific section for target specific defines). Regards, Fabrice.
[Qemu-devel] Re: [PATCH, RFC, WIP] TCG for Qemu target Sparc32/64
> [...] >> Another point is that you should define TCG globals for each SPARC GPR. >> It was not done for i386 because I feared performance regressions when >> accessing to 16 bit or 8 bit sub-registers. On SPARC you do not have >> this issue. > > Nice idea. Would this also work for windowed registers? Yes, provided you use a fixed register to store regwptr. Then you can define the windowed registers as globals using this register as base. The real problem is to save and restore this register in cpu_exec() and in all the places where the regwptr CPU state field is accessed directly. TCG will handle these problems generically soon, but before it does it you can implement it "by hand". Regards, Fabrice.
[Qemu-devel] Re: TCG on i386 can't generate qemu_st64 for 32-bit target
Blue Swirl wrote: > Hi, > > There is a problem with the Sparc32 target on i386 host. Store double > word op (std) cannot be generated and TCG just aborts. It looks like > the registers are so few on i386 that TCG can't find registers for the > qemu_st64 call. The problem does not appear on x86_64 host, or for > Sparc64 target (stx/ldx) on i386, or with 64-bit load (ldd) on Sparc32 > target. > > The attached patch would work around the problem, but I agree that > it's ugly and it would bring back one instance of T2 use. I also tried > preallocating a 64-bit register but that didn't help. > > I suppose instead the following piece (tcg/i386/tcg-target.c:737) > could be modified to lower the pressure for registers but I'm not that > familiar with x86 assembly. > [...] There are not enough free registers because of the legacy 3 cpu_T[n] fixed registers. Once you have no helpers using cpu_T[n] implicitely, it will be possible to allocate cpu_T[n] as normal temporaries and to free the associated fixed registers. Before that your solution is acceptable. Another hack would be to force the 'r_dword' variable to be stored in cpu_T[1] and cpu_T[2], but TCG gives no clean way to do it. Fabrice.
Re: [Qemu-devel] qemu block-qcow.c block-qcow2.c block-vmdk.c bl...
IMHO it would be much simpler to do all the tests in the block format handlers. Fabrice. Aurelien Jarno wrote: CVSROOT:/sources/qemu Module name:qemu Changes by: Aurelien Jarno 08/03/11 17:17:59 Modified files: . : block-qcow.c block-qcow2.c block-vmdk.c block.c block.h block_int.h Log message: Fix CVE-2008-0928 - insufficient block device address range checking Qemu 0.9.1 and earlier does not perform range checks for block device read or write requests, which allows guest host users with root privileges to access arbitrary memory and escape the virtual machine. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/block-qcow.c?cvsroot=qemu&r1=1.15&r2=1.16 http://cvs.savannah.gnu.org/viewcvs/qemu/block-qcow2.c?cvsroot=qemu&r1=1.10&r2=1.11 http://cvs.savannah.gnu.org/viewcvs/qemu/block-vmdk.c?cvsroot=qemu&r1=1.19&r2=1.20 http://cvs.savannah.gnu.org/viewcvs/qemu/block.c?cvsroot=qemu&r1=1.54&r2=1.55 http://cvs.savannah.gnu.org/viewcvs/qemu/block.h?cvsroot=qemu&r1=1.6&r2=1.7 http://cvs.savannah.gnu.org/viewcvs/qemu/block_int.h?cvsroot=qemu&r1=1.16&r2=1.17
Re: [Qemu-devel] qemu block-qcow.c block-qcow2.c block-vmdk.c bl...
Aurelien Jarno wrote:
> Fabrice Bellard a écrit :
>> IMHO it would be much simpler to do all the tests in the block format
>> handlers.
>>
>
> Do you mean move all the tests into block-{qcow,qcow2,vmdk}.c ?
I suggest reverting the patch and writing correct tests in
block-{qcow,qcow2,vmdk}.c. BTW, bs->total_sectors is not a good
indicator of the device size in case of removable devices for example.
Fabrice.
Re: [Qemu-devel] [PATCH] Modify qemu-img to mount locally disk image using NBD (v2)
Laurent Vivier wrote:
> This patch is a new version of qemu-img using NBD device to mount Qemu
> disk image.
>
> To not hang on UP system, it needs following patch:
> http://article.gmane.org/gmane.linux.drivers.nbd.general/42
> If you want to use loop to see partitions, you need this patch:
> http://article.gmane.org/gmane.linux.kernel/651269
> otherwise use kpartx (see kpartx package of your distro).
>
> This patch implements in qemu-img the client and the server of the nbd
> protocol.
> Moreover, to avoid to specify a port to use, it creates a UNIX socket instead
> of
> a INET socket.
>
> It adds two actions to qemu-img:
> - bind, to bind a disk image to a NBD device,
>
> qemu-img bind [-d] [-f fmt] device filename
>
> ('-d' to daemonize)
>
> - unbind, to unbind it.
>
> qemu-img unbind device
> [...]
Perhaps adding a new specialized tool would be better as there is no
direct relation with qemu-img.
Fabrice.
Re: [Qemu-devel] qemu/target-mips op_helper.c
IMHO, calling floatX_round_to_int before floatX_to_intY is not useful... Fabrice. Thiemo Seufer wrote: CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer07/06/27 19:01:46 Modified files: target-mips: op_helper.c Log message: Fix computation for ceil, floor and round instructions. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/op_helper.c?cvsroot=qemu&r1=1.54&r2=1.55
Re: [Qemu-devel] qemu/target-mips op_helper.c
floatX_to_intY should already do the rounding according to the current rounding direction. Fabrice. Thiemo Seufer wrote: Fabrice Bellard wrote: IMHO, calling floatX_round_to_int before floatX_to_intY is not useful... I don't understand. floatX_round_to_int does round/ceil/floor but keeps the floating point representation. floatX_to_intY converts the adjusted value to integer representation. Doing this in two steps may have its own problems like spurious inexact signalling, but at least the calculated values appear to be correct. Thiemo
Re: [Qemu-devel] 4G address space remapping on 64-bit host
Hi, In fact, running in 64 bit is not necessary : It is simpler and more efficient to use kqemu (or KVM) to handle the address space remapping. The trick is to run the translator in the upper part or lower part of the 32 bit address space and to protect it with segments. Even in 64 bit mode, using kqemu would be more efficient because it could handle scattered address spaces more efficiently than the host OS. Fabrice. Blue Swirl wrote: Hi, I had an idea of mapping the full 32-bit target virtual address space to a 4GB area on 64-bit hosts. Then the loads and stores to normal RAM (except page tables, code_mem_write etc) could be made much faster, falling back to softmmu for other pages. The idea has come up before, for example in this Fabrice's message: http://article.gmane.org/gmane.comp.emulators.qemu/685 But I'm not sure if this would be worth the effort, the speedup would depend on the frequency of the loads/stores and also translation time vs. translated code execution times. Does anyone have good statistics on those?
Re: [Qemu-devel] 4G address space remapping on 64-bit host
Blue Swirl wrote: On 6/29/07, Fabrice Bellard <[EMAIL PROTECTED]> wrote: In fact, running in 64 bit is not necessary : It is simpler and more efficient to use kqemu (or KVM) to handle the address space remapping. The trick is to run the translator in the upper part or lower part of the 32 bit address space and to protect it with segments. Would that be hard to implement for the kqemu case? What is your guesstimate on what kind of performance benefit would Sparc32 emulation get from that? The kqemu part could be quite simple. A new execution mode could be added so that: - shadow page table faults generate a specific signal in the user guest code. - A kqemu "syscall" callable from the user guest code could be used to do the equivalent of tlb_set_page(), tlb_flush_page() and tlb_flush(). Note that I don't think it is worth using Xen for that. Modifying kqemu (or even KVM) should be more flexible. With kqemu it could also work on FreeBSD, Solaris, Windows and Linux. The more complicated part is to split QEMU in two parts : one part containing the translator (and maybe some devices) would be executed as guest user code in kqemu. The other part would be executed as a regular process to handle what is left (graphic, disk access, etc). If TB where MMIO accesses are done are compiled specifically, I think it can be quite efficient. For the specific sparc32 case, I think that a better register window handling and a faster soft mmu code (using 4MB TLBs as it was proposed in a patch long ago) should already give an important speed boost (say a factor 1.5 to 2). The kqemu optimisation should give at least as much performance gain, depending on the ratio of instructions which do a memory access and on the number of TLB faults. Regards, Fabrice.
Re: [Qemu-devel] [PATCH] linux-user EFAULT implementation
Please update page_check_range() (and other related functions) to return -EFAULT instead of EFAULT in case of error. Moreover, I believe using similar functions as Linux for memory access (copyfromuser, copytouser, get_user, put_user) would be cleaner. Regards, Fabrice. Stuart Anderson wrote: Here is a refresh of the linux-user EFAULT patch vs todays cvs. This patch has now received a lot more runtime, and a couple of bug have been fixed that affected some of the socket APIs. The purpose of this patch is to detect bad pointers and return EFAULT instead of just crashing when the bad pointers are used by qemu. Stuart
Re: [Qemu-devel] [PATCH] linux-user EFAULT implementation
Stuart Anderson wrote: On Fri, 6 Jul 2007, Stuart Anderson wrote: So, the question is: Can I simplify this code to assume that guest and host addresses coexist and use the copy_*_user() or just the access_ok() interfaces? No. Ideally you should use the same conventions as the Linux kernel and assume that you cannot access the user data directly. To summarise: - access_ok() is needed before __copy_*_user and __[get|put]_user. - access_ok() is not needed before copy_[to|from]_user and [get|put]_user. - [get|put]_user do automatic endianness change. - Use tswapx and the other related functions to change the endianness before or after copy_*_user. - for specific cases requiring speed (e.g. buffers for read/write syscalls), specific tricks to avoid memory copies can be used with a lock/unlock style API. Attached is a diff [...] Please send a unified diff. For the time being, I would suggest to minimize the number of changes and just extend lock_user()/unlock_user() as you began to do to handle -EFAULT. The rest is mostly a question of cosmetics. Regards, Fabrice.
Re: [Qemu-devel] [PATCH] linux-user EFAULT implementation
Paul Brook wrote: (...] Using g2h directly is bad. g2h is an implementation detail of one particular memory model. The whole point of the lock_user abstraction (or a similar copy_from_user abstraction) is that almost none of the code cares how "user" memory is accessed. One of the long-term goals of this abstraction is to allow the softmmu code to be used with userspace emulation. In this case a region may be split across multiple discontiguous host pages. I confirm that I expected g2h() to be completely removed in case the Linux user access API is used. The reason I used a locking paradigm rather than a copying one is that it allows a zero-copy implementation in the common case. I've no strong objections to a copying interface, however it must be implementation agnostic. Since you agree for the copying interface, I suggest to convert all the code to it. The exact implementation of access_ok(), copy_to_user(), copy_from_user()... will be easily modifiable if one day softmmu user mode is needed. In the only specific case of potentially big unbounded memory areas (such as read/write buffers), a different API must be used where it is possible to get a pointer to user pages (e.g. ptr = lock_user_page(addr, rw_mode); if (!ptr) return -EFAULT; unlock_user_page(ptr)), so that no copy is performed while being able to handle any user page remapping. Regards, Fabrice.
Re: [Qemu-devel] Re: PATCH, RFC: Generic DMA framework
Paul Brook wrote: On Friday 24 August 2007, Blue Swirl wrote: I have now converted the ISA DMA devices (SB16, FDC), most PCI devices and targets. gdma.diff: Generic DMA pc_ppc_dma_to_gdma.diff: Convert x86 and PPC to GDMA pc_sb16_to_gdma.diff: Convert SB16 to GDMA pc_fdc_to_gdma.diff: FDC pc_dma_cleanup.diff: Remove unused functions sparc_gdma.diff: Convert Sparc32 to GDMA sparc32_dma_esp_le_to_gdma.diff: Convert ESP and Lance sun4c.diff: Preliminary Sun4c (Sparcstation-1) support pci_gdma.diff: Convert PCI devices and targets Any comments? The patches are a bit intrusive and I can't test the targets except that they compile. Shouldn't the PCI DMA object be a property of the PCI bus? ie. we don't want/need to pass it round as a separate parameter. It can be inferred form the device/bus. I agree. Moreover the DMA is bus specific so I don't see a need to add a generic DMA layer. Regards, Fabrice.
Re: [Qemu-devel] [PATCH][RFC] SVM support
This is a reworked version of the same patch, where I can now boot into a x86_64 Linux kernel. I rewrote all the access functions for the VMCB, so this time everything should work just fine on BE-machines. As suggested I moved the injection detection to translate.c, so the non-virtualized machine should be as fast as before (w/o svm support), while the virtual one got a speed boost from that as well. I removed the EIP hack and set EIP every time an interception occurs, so unlike the previous version this patch really should have no negative effect on speed any more. If any of the people on this list using SVM (kvm developers, maybe xen developers) could have a deep look into this I'd be really thankful. Some notes: - Saving and restoring CC_SRC and CC_DST is not correct as they do not belong to the real processor state. You must save and restore eflags correctly instead. - Avoid using macros when inline functions suffice. Regards, Fabrice.
Re: [Qemu-devel] Re: PATCH, RFC: Generic DMA framework
Paul Brook wrote: pci_gdma.diff: Convert PCI devices and targets Any comments? The patches are a bit intrusive and I can't test the targets except that they compile. Shouldn't the PCI DMA object be a property of the PCI bus? ie. we don't want/need to pass it round as a separate parameter. It can be inferred form the device/bus. I agree. Moreover the DMA is bus specific so I don't see a need to add a generic DMA layer. I can see use for a generic DMA interface. It has some nice possibilities for devices which can connect via a variety of busses and maybe for layering different busses within a system. However I don't know how well this will work in practice for the machines qemu currently emulates. I can see more uses for a simple bus interface which could be used at least for ISA devices. The API should include bus read/write functions (which can be used to implement DMA) and functions to allocate/free a memory region as we have for the CPU bus. Of course the same must be added for PCI buses so that the PCI memory area can be mapped at any position in the CPU address space. Fabrice.
Re: [Qemu-devel] CC_DST problem
Alexander Graf wrote: Hi, I'm still trying to implement SVM correctly and hit a serious problem. If I set CC_OP to EFLAGS / DYNAMIC after each instruction (so most conditional operations are based on EFLAGS) everything works as expected. If using CC_OP==CC_OP_EFLAGS only CC_SRC should be used and CC_DST is supposed to be completely ignored. So I set CC_DST to 0 (this happens when leaving and rejoining the virtual machine, so this is the real problem) and if I do that, I get funny segmentation faults in x86_64 guest userspace programs running in the virtual machine (this is exactly what I see in kvm with my current patchset as well), while 32 bit userspace programs simply hang. So I guess this is the real problem. Is there any logical reason CC_DST could be used with CC_OP==CC_OP_EFLAGS? Attached to this email you will find a small patch that triggers this problem. Thanks for any reply that could help on this, Alexander Graf If you play with the CC_OP logic, it is better to disable the eflags optimization code in the translator (optimize_flags() function). Regarding the implementation for SVM, you can look at how the CC are handled in SMM (do_smm_enter and helper_rsm). I see no particular problem here. I suggest to try to suppress the additions in the static translator state as I feel most of the SVM intercepts can be tested in helpers where speed is not critical. Regards, Fabrice.
Re: [Qemu-devel] Re: [PATCH] Patches from PyQemu project
Anthony Liguori wrote: On Tue, 2007-09-04 at 23:27 +0100, Thiemo Seufer wrote: Brian Johnson wrote: [snip] My initial thought is to make the libraries at the individual device level. It would be good to have a general mechanism for bus providers, interrupts, APICs, chipsets, etc. as well, so we could emulate fancier architectures than a simple PC (or simple Sparc/MIPS/ARM/etc. box.) For instance, I'd like to emulate multiple PCIe host bridges, each with an APIC and multiple cards, which might contain PCI-to-PCI bridges. And I'd like to emulate NUMA systems with many memory controllers and a complex memory map, with multiple sets of chipset registers. I don't expect qemu to do this off the shelf, Why not? I would like to see better abstracted and more capable device emulations in Qemu. but I'd like to avoid hardcoding PC assumptions into the device libraries, so I can code the fancy machines myself and use the I/O as-is. Then, what does a librar-ized Qemu device with its hardcoded PC assumptions help you? Let me give a very pragmatic answer. Right now, KVM has it's own main loop which uses a thread per-vcpu. Device IO is handled in the context of the VCPU that originated the IO. I think there's some desire to move to an N+1 threading model where the extra thread does things like VGA scanning, VNC, etc. Xen, on the other hand, uses a single thread for everything and doesn't attempt to model multiple VCPUs within the QEMU process. All IO is delivered via the same channel. QEMU is strictly used for devices. Merging either of these with QEMU's current model would be challenging, merging both would be extremely challenging b/c the two main loop models are mutually exclusive. However, there's no real trouble merging any of the device emulation back. KVM doesn't maintain any changes to things like device emulation (other than some KVM-specific APIC stuff). Xen, on the other hand, mostly has fixes for some of the devices that haven't been submitted back to QEMU. Other devices are completely unmodified but are severely lagging behind the QEMU versions. VirtualBox is way different than QEMU of course. A bunch of their device emulation is pretty close to QEMU though. I think device emulation is an independent enough problem that there's a good chance everyone can agree on a single implementation. While it's a little more work in QEMU to keep these things as libraries and maintain an interface, I suspect the benefits outweigh the extra cost in that it's much more likely we'll see more patches. There are useful bits of QEMU that could be widely consumed. Their nature is such that their interfaces are unlikely to change dramatically in the future. To me, this just screams "library" :-) I agree with the point that QEMU should be improved so that it is easier to reuse the device model. But I consider that the priority is not to export a library but to improve the existing QEMU C APIs. The goal should be that it is possible to emulate several different CPUs at once with several unrelated buses. Moreover the model should support deterministic simulation. Currently the PCI bus is the closest to what is needed, but even in it there are still some conceptual problems (see the DMA problems which were discussed before). Regarding the other projects, I see no technical reason why the KVM code cannot be merged. QEMU already contains the necessary support code for KQEMU and I see no conceptual difference with KVM. Adding a new main loop for KVM or a new KVM specific CPU is not something I am against. Regards, Fabrice.
Re: [Qemu-devel] qemu cpu-all.h cpu-exec.c exec.c target-i386/cp...
Hi, The code would be simpler if some intercept tests were done at runtime in the corresponding helpers (for crN, drN and MSR registers, I/Os). This is especially true when the existing helpers can return an exception at runtime. Complicating the translator to handle SVM is definitely not the way I would have handled it. For I/Os for example, there was already the necessary support to do runtime tests (see gen_check_io()). Adding one bit to return the prefix information is all what it needed. The current code is actually slower because new ops were added for each I/O instruction. Regards, Fabrice. Thiemo Seufer wrote: CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer07/09/23 15:28:04 Modified files: . : cpu-all.h cpu-exec.c exec.c target-i386: cpu.h exec.h helper.c helper2.c op.c translate.c Log message: SVM Support, by Alexander Graf. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/cpu-all.h?cvsroot=qemu&r1=1.75&r2=1.76 http://cvs.savannah.gnu.org/viewcvs/qemu/cpu-exec.c?cvsroot=qemu&r1=1.115&r2=1.116 http://cvs.savannah.gnu.org/viewcvs/qemu/exec.c?cvsroot=qemu&r1=1.105&r2=1.106 http://cvs.savannah.gnu.org/viewcvs/qemu/target-i386/cpu.h?cvsroot=qemu&r1=1.47&r2=1.48 http://cvs.savannah.gnu.org/viewcvs/qemu/target-i386/exec.h?cvsroot=qemu&r1=1.36&r2=1.37 http://cvs.savannah.gnu.org/viewcvs/qemu/target-i386/helper.c?cvsroot=qemu&r1=1.87&r2=1.88 http://cvs.savannah.gnu.org/viewcvs/qemu/target-i386/helper2.c?cvsroot=qemu&r1=1.51&r2=1.52 http://cvs.savannah.gnu.org/viewcvs/qemu/target-i386/op.c?cvsroot=qemu&r1=1.50&r2=1.51 http://cvs.savannah.gnu.org/viewcvs/qemu/target-i386/translate.c?cvsroot=qemu&r1=1.70&r2=1.71
Re: [Qemu-devel] qemu monitor.c
Hi, I don't think this is the right fix because the monitor expressions can be used for either virtual or physical addresses. I suggest using 64 bit integers for every target. Fabrice. Blue Swirl wrote: CVSROOT:/cvsroot/qemu Module name:qemu Changes by: Blue Swirl 07/09/24 18:39:04 Modified files: . : monitor.c Log message: Fix >4G physical memory dump for Sparc32 CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/monitor.c?cvsroot=qemu&r1=1.81&r2=1.82
Re: [Qemu-devel] qemu elf_ops.h
Try to avoid using target_phys_addr_t at this place as I don't want this code to be CPU dependent (think of a machine having several different CPUs !). Regards, Fabrice. Blue Swirl wrote: CVSROOT:/cvsroot/qemu Module name:qemu Changes by: Blue Swirl 07/09/24 18:41:27 Modified files: . : elf_ops.h Log message: Fix loading above 4G CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/elf_ops.h?cvsroot=qemu&r1=1.8&r2=1.9
Re: [Qemu-devel] [Bug][Patch] Cirrus-VGA for Malta
The problem must come from somewhere else. VGA (as any other device)
must not depend on the target CPU endianness (note that the endianness
tests in the memory handlers are only necessary because the bus API is
still incomplete).
Regards,
Fabrice.
Stefan Weil wrote:
Hello,
here is a patch which makes VGA usable for Malta MIPS32 in big endian
mode. I don't know whether other big endian emulations need a
patch for VGA, too.
Regards
Stefan
Index: hw/vga_template.h
===
RCS file: /sources/qemu/qemu/hw/vga_template.h,v
retrieving revision 1.13
diff -u -b -B -r1.13 vga_template.h
--- hw/vga_template.h 11 May 2006 21:54:44 - 1.13
+++ hw/vga_template.h 14 Jun 2007 20:10:25 -
@@ -327,6 +327,16 @@
palette = s1->last_palette;
width >>= 3;
for(x = 0; x < width; x++) {
+#if defined(TARGET_WORDS_BIGENDIAN)
+((PIXEL_TYPE *)d)[3] = palette[s[0]];
+((PIXEL_TYPE *)d)[2] = palette[s[1]];
+((PIXEL_TYPE *)d)[1] = palette[s[2]];
+((PIXEL_TYPE *)d)[0] = palette[s[3]];
+((PIXEL_TYPE *)d)[7] = palette[s[4]];
+((PIXEL_TYPE *)d)[6] = palette[s[5]];
+((PIXEL_TYPE *)d)[5] = palette[s[6]];
+((PIXEL_TYPE *)d)[4] = palette[s[7]];
+#else
((PIXEL_TYPE *)d)[0] = palette[s[0]];
((PIXEL_TYPE *)d)[1] = palette[s[1]];
((PIXEL_TYPE *)d)[2] = palette[s[2]];
@@ -335,6 +345,7 @@
((PIXEL_TYPE *)d)[5] = palette[s[5]];
((PIXEL_TYPE *)d)[6] = palette[s[6]];
((PIXEL_TYPE *)d)[7] = palette[s[7]];
+#endif
d += BPP * 8;
s += 8;
}
Re: [Qemu-devel] [Bug][Patch] Cirrus-VGA for Malta
I realize that the other pixel formats are buggy too, so at least your
patch is consistent with what is already coded !
I guess the problem is in the VGA memory handlers. Otherwise it means
that there is a (Cirrus)VGA configuration register to change the
endianness of the frame buffer. In such case, it must be emulated correctly.
Regards,
Fabrice.
Stefan Weil wrote:
Hello,
here is a patch which makes VGA usable for Malta MIPS32 in big endian
mode. I don't know whether other big endian emulations need a
patch for VGA, too.
Regards
Stefan
Index: hw/vga_template.h
===
RCS file: /sources/qemu/qemu/hw/vga_template.h,v
retrieving revision 1.13
diff -u -b -B -r1.13 vga_template.h
--- hw/vga_template.h 11 May 2006 21:54:44 - 1.13
+++ hw/vga_template.h 14 Jun 2007 20:10:25 -
@@ -327,6 +327,16 @@
palette = s1->last_palette;
width >>= 3;
for(x = 0; x < width; x++) {
+#if defined(TARGET_WORDS_BIGENDIAN)
+((PIXEL_TYPE *)d)[3] = palette[s[0]];
+((PIXEL_TYPE *)d)[2] = palette[s[1]];
+((PIXEL_TYPE *)d)[1] = palette[s[2]];
+((PIXEL_TYPE *)d)[0] = palette[s[3]];
+((PIXEL_TYPE *)d)[7] = palette[s[4]];
+((PIXEL_TYPE *)d)[6] = palette[s[5]];
+((PIXEL_TYPE *)d)[5] = palette[s[6]];
+((PIXEL_TYPE *)d)[4] = palette[s[7]];
+#else
((PIXEL_TYPE *)d)[0] = palette[s[0]];
((PIXEL_TYPE *)d)[1] = palette[s[1]];
((PIXEL_TYPE *)d)[2] = palette[s[2]];
@@ -335,6 +345,7 @@
((PIXEL_TYPE *)d)[5] = palette[s[5]];
((PIXEL_TYPE *)d)[6] = palette[s[6]];
((PIXEL_TYPE *)d)[7] = palette[s[7]];
+#endif
d += BPP * 8;
s += 8;
}
Re: [Qemu-devel] expose host CPU features to guests: Take 3
andrzej zaborowski wrote: Hi, On 24/09/2007, Dan Kenigsberg <[EMAIL PROTECTED]> wrote: As with previous "Takes" of this patch, its purpose is to expose host CPU features to guests. It proved rather helpful to KVM in various benchmarks, and it should similarly speed kqemu up. Note that it does not extend the set of emulated opcodes, only exposes what's supported by the host CPU. Another purpose for "Take 2" is to add the -cpu option to the x86 architecture, similarly to that of other architectures. -cpu 486, pentium, pentium2 and pentium3 are supported in addition to finer-grained features such as -cpu pentium,-mmx . As in Take 1, -cpu host exposes host features to guest. This patch exposes the requested CPU also right after RESET command, and not only in CPUID. Please let me know if you have more suggestions, Dan. >>[...] I haven't really read through the rest of your code but this piece appears to be outside any #ifdef/#endif so it will only build on x86. Regards A few remarks: 1) I cannot accept GPL code in target-i386, so the code from the Linux kernel must be removed or rewritten. 2) cpuid is already defined in kqemu.c, so it would be better to use it (I consider this is not a blocking point though). 3) For the future, I suggest that the function cpu_xxx_register() is removed and that the parameter xxx_def_t is added to cpu_xxx_init(). Rationale: I see no point in initializing a CPU without specifying its exact model and I am not sure that cpu_xxx_register() can be called once some code is executed. Regards, Fabrice.
Re: [kvm-devel] [Qemu-devel] expose host CPU features to guests: Take 3
Avi Kivity wrote: J. Mayer wrote: On Tue, 2007-09-25 at 12:40 +0200, Avi Kivity wrote: Avi Kivity wrote: I've got a remark about this: why this has to be added to the Qemu code ? Imho, all is needed is an implementation of the -cpu option for x86/x86_64 target. Then, an external tool (even a shell script) can be used to determine what is the host CPU if you want to select the exact same CPU to be emulated in Qemu. It seems to me that trying to do so is out of the scope of Qemu code and just add unneeded complexity. Indeed for regular qemu this is useless. But it is useful for kqemu (for which there is support in mainline qemu), and for kvm (which we hope to merge one day). Actually (as Izik Eidus reminds me), this isn't very useful for kqemu as it can't trap cpuid in all circumstances. So this is mainly useful for kvm. I hope it will be applied regardless of that, as there is agreement that kvm support should be merged. I'd much rather pull the feature from qemu rather than carry it as an additional patch. Still I don't understand why it's usefull to put it inside the emulator and why: # qemu -cpu `guess_host_cpu` would not do the work properly. Adding a specific case for '-cpu host' seems useless to me. And this way of doing potentially work for any family of emulated targets, without any modification in Qemu. If the string returned by 'guess_host_cpu' is not recognized for the specific target you used it with, Qemu just stops telling it cannot find this CPU model, no more, no less. It's a usability issue. I agree your suggestion would work, but I'd like the default for kvm to be using the host cpu features, whereas managed environments would specify some subset to enable live migration. The only case it could be interresting, imho, is if you do not allow the -cpu option in KVM case and force the cpu model instead using this function. This behavior does not seem to be great idea to me. I think we can move the host cpu checks to kvm-specific code, since it is not useful for kqemu. So, running qemu without any parameters would use host capabilities if kvm is available and the default qemu cpu if not. The -cpu option can be used to override this if necessary. Rectification: this is useful for kqemu too. I strongly suggest to look at kqemu.c:kqemu_update_cpuid() ! Moreover I believe that using the same CPU as host can be useful for pure emulation too, for example if code to do cache profiling is added. Regards, Fabrice.
Re: [Qemu-devel] [PATCH][MIPS] Fix [ls][wd][lr] instructions
Aurelien Jarno wrote:
Hi,
As written in the MIPS TODO file, the lwl, lwr, ldl, ldr, swl, swr,
sdl and sdr instructions are not correctly implemented. In case of
exception the BadVAddr register gets the aligned address instead of the
unaligned original address.
In addition to that, the store instructions are generating the wrong
exception, AdEl instead of AdEs, because the current implementation
first do a load.
The patch below fixes that by accessing the bytes one by one, starting
by the unaligned original address.
Bye,
Aurelien
[...]
BTW, you could simplify a lot the implementation :
switch (GET_LMASK(T0)) {
case 0:
T0 = (int32_t)tmp;
break;
case 1:
T0 = (int32_t)((tmp << 8) | (T1 & 0x00FF));
break;
case 2:
T0 = (int32_t)((tmp << 16) | (T1 & 0x));
break;
case 3:
T0 = (int32_t)((tmp << 24) | (T1 & 0x00FF));
break;
}
->
v = GET_LMASK(T0);
if (v == 0) {
T0 = tmp;
} else {
TO = (int32_t)((tmp << (8 * v)) | (T1 & ((1 << (v * 8)) - 1)));
}
Fabrice.
Re: [Qemu-devel] [PATCH][MIPS] Fix [ls][wd][lr] instructions
Aurelien Jarno wrote: Hi, As written in the MIPS TODO file, the lwl, lwr, ldl, ldr, swl, swr, sdl and sdr instructions are not correctly implemented. In case of exception the BadVAddr register gets the aligned address instead of the unaligned original address. In addition to that, the store instructions are generating the wrong exception, AdEl instead of AdEs, because the current implementation first do a load. The patch below fixes that by accessing the bytes one by one, starting by the unaligned original address. > [...] It would be a lot more efficient to add specific code in the MIPS exception handling. Fabrice.
Re: [Qemu-devel] qemu/pc-bios ppc_rom.bin
Blue Swirl wrote: On 10/1/07, Jocelyn Mayer <[EMAIL PROTECTED]> wrote: On Mon, 2007-10-01 at 17:55 +0300, Blue Swirl wrote: On 10/1/07, Andreas Färber <[EMAIL PROTECTED]> wrote: Am 01.10.2007 um 09:12 schrieb Bob Deblier: Ideally we should have an OpenBIOS compiled for QEMU/PPC. Is anyone working on this? I had looked into this recently but it turned out that PearPC and others using OpenBIOS/ppc use an ELF format OpenBIOS binary that is incompatible with QEMU, expecting some raw image. I have no idea how to go about this; the (working) sparc version uses some "weird" assembler initializations. ;-) You can use: objcopy -O binary in.elf out.bin Alternatively, Qemu could be enhanced to try loading ELF first and binary if that fails. This is even not an option. With "normal" full system emulation, Qemu boots like real hardware does. I don't know any CPU able to load ELF images. As the goal is to emulate real hardware, what is to be given is a ROM image, able to boot a real machine. The effect is exactly the same from the emulated CPU perspective. With ELF image we gain symbols in the out_asm dump. You can try to ehance the -kernel option to do weird hacks if you like but the CPU state at the start of a normal boot process should be as near as possible as a real CPU after a hard reset. Any other behavior is a bug to fix asap. Imho Qemu can be a very great development tool (and I already used it for this purpose), not just a geek toy, then hacks that do not reflect what real hardware does have to be avoided any time it's possible. Then, adding an ELF loader in the CPU initialisation code seems to be a nonsense. The goal to achieve, imho, is to be able to run real ROM images extracted from real machine, not to "extend" the CPU features with stuffs that has no reality (and are even not useful as long as no machine would never accept to boot on this "firmware"). Qemu is not limited to just hardware emulation. Please consider for example snapshot load/save support, built-in gdbstub and monitor. No real hardware has any of these, or perhaps you could do similar things with ICE or JTAG. Qemu is not also aimed for 100% accurate emulation of the hardware. There are no caches or cycle counters and hardware devices run unrealistically fast from CPU standpoint. Emulating performance counters or the errata the most CPUs have would be extremely difficult. I doubt Qemu CPU emulation can ever pass POST of real BIOSes. Real BIOSes are also closed source, proprietary binary blobs. Making open source BIOSes a viable alternative is in my opinion a much more important goal. I know at least one real PC BIOS which "almost" work in QEMU. "almost" because a few fixes are needed in the PIIX3 bridge and I never found the time to publish them. Another point was the timing accuracy which made the BIOS hang sometimes, but it can also be solved. [...] Fabrice.
Re: [Qemu-devel] RFC: fix run of 32 bits Linux executables on 64 bits targets
J. Mayer wrote: Following the patches done for elfload32, it appeared to me that there were still problems that would prevent 32 bits executables to run on 64 bits target in linux user mode emulation. > [...] Are you sure it is a good idea to try to add 32 bit executable support to a 64 bit target ? In the end you will need to write a 64 bit to 32 bit linux syscall converter which would mean duplicating all the linux-user code of the corresponding 32 bit target (think of ioctls with strutures, signals frames, etc...). Fabrice.
Re: [Qemu-devel] RFC: fix run of 32 bits Linux executables on 64 bits targets
Thiemo Seufer wrote: Fabrice Bellard wrote: J. Mayer wrote: Following the patches done for elfload32, it appeared to me that there were still problems that would prevent 32 bits executables to run on 64 bits target in linux user mode emulation. [...] Are you sure it is a good idea to try to add 32 bit executable support to a 64 bit target ? In the end you will need to write a 64 bit to 32 bit linux syscall converter which would mean duplicating all the linux-user code of the corresponding 32 bit target (think of ioctls with strutures, signals frames, etc...). I would think this feature will be limited to platforms which can handle 32bit and 64bit binaries with a single personality. I am not sure it is a common case ! However, I suggest to emulate a 32 bit user linux system with a 64 bit guest CPU running in 32 bit compatibily mode. It would be useful to test 64 bit CPUs in 32 bit compatibility mode. The only required modification in linux user is to rename target_ulong so that it can have a different size of the CPU word default size. Regards, Fabrice.
Re: [Qemu-devel] RFC: Code fetch optimisation
Blue Swirl wrote: On 10/12/07, J. Mayer <[EMAIL PROTECTED]> wrote: Here's a small patch that allow an optimisation for code fetch, at least for RISC CPU targets, as suggested by Fabrice Bellard. The main idea is that a translated block is never to span over a page boundary. As the tb_find_slow routine already gets the physical address of the page of code to be translated, the code translator could then fetch the code using raw host memory accesses instead of doing it through the softmmu routines. This patch could also be adapted to RISC CPU targets, with care for the last instruction of a page. For now, I did implement it for alpha, arm, mips, PowerPC and SH4. I don't actually know if the optimsation would bring a sensible speed gain or if it will be absolutelly marginal. Please comment. This will not work correctly for execution of MMIO registers, but maybe that won't work on real hardware either. Who cares. It can never happen because QEMU currently does not support it (see get_phys_addr_code()). I started to implement it but never really finished it (real hardware can do it so QEMU should support it). The idea consist in using a reserved ram page to store the code. Another point is that the TB must be discarded once executed as the MMIO data can change. Regards, Fabrice.
Re: [Qemu-devel] RFC: Code fetch optimisation
Blue Swirl wrote: On 10/12/07, J. Mayer <[EMAIL PROTECTED]> wrote: Here's a small patch that allow an optimisation for code fetch, at least for RISC CPU targets, as suggested by Fabrice Bellard. The main idea is that a translated block is never to span over a page boundary. As the tb_find_slow routine already gets the physical address of the page of code to be translated, the code translator could then fetch the code using raw host memory accesses instead of doing it through the softmmu routines. This patch could also be adapted to RISC CPU targets, with care for the last instruction of a page. For now, I did implement it for alpha, arm, mips, PowerPC and SH4. I don't actually know if the optimsation would bring a sensible speed gain or if it will be absolutelly marginal. Please comment. This will not work correctly for execution of MMIO registers, but maybe that won't work on real hardware either. Who cares. It can never happen because QEMU currently does not support it (see get_phys_addr_code()). I started to implement it but never really finished it (real hardware can do it so QEMU should support it). The idea consist in using a reserved ram page to store the code. Another point is that the TB must be discarded once executed as the MMIO data can change. Regards, Fabrice.
Re: [Qemu-devel] RFC: Code fetch optimisation
Paul Brook wrote: > [...] The code itself looks ok, though I'd be surprised if it made a significant difference. We're always going to hit the fast-path TLB lookup case anyway. It seems that the generated code for the code fetch is much more efficient than the one generated when we get when using the softmmu routines. But it's true we do not get any significant performance boost. As it was previously mentioned, the idea of the patch is more a 'don't do unneeded things during code translation' than a great performance improvment. OTOH it does make the the code more complicated. I'm agnostic about whether this patch should be applied. If it does not correct the existing x86 issues (no code segment limit tests and no explicit handling of code fetch exceptions in the translation phase in VLE case) I see no advantage in commiting it in its current form. Regards, Fabrice.
[Qemu-devel] Re: PATCH, RFC: Slirp improvements
> I tried harder to change the SLIRP queue stuff to something saner by > hiding the pointer access inside inlined functions. Still when I > changed the 32 bit pointers to native 64 bit (or moved the pointers > outside the packet), qemu crashes. Must be some devilishly hidden > access somewhere. I already fixed one, which involved recycling port > number fields for buffer pointers. IMHO there should be some kind of > corporeal punishments mandated by law for writing this kind of mess. > Maybe it would even be easier to create a new userland IP stack based > on Linux from scratch instead of fixing this. > > I think I'll just commit in the log part, unless there are objections. IMHO you should add a context in the 'struct socket' structure so that you can avoid adding a context in all the functions manipulating this structure. The same holds for mbuf. Regards, Fabrice.
Re: [Qemu-devel] qemu host-utils.c
I strongly suggest to reuse my code which was in target-i386/helper.c revision 1.80 which was far easier to validate. Moreover, integer divisions from target-i386/helper.c should be put in the same file. Regards, Fabrice. Thiemo Seufer wrote: CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer07/10/23 23:22:54 Modified files: . : host-utils.c Log message: Fix overflow when multiplying two large positive numbers. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/host-utils.c?cvsroot=qemu&r1=1.1&r2=1.2
Re: [Qemu-devel] qemu host-utils.c
Jocelyn Mayer wrote: On Wed, 2007-10-24 at 18:37 +0100, Thiemo Seufer wrote: J. Mayer wrote: On Wed, 2007-10-24 at 12:20 +0200, Fabrice Bellard wrote: I strongly suggest to reuse my code which was in target-i386/helper.c revision 1.80 which was far easier to validate. Moreover, integer divisions from target-i386/helper.c should be put in the same file. I fully agree with this. I still use the same code in the PowerPC op_helper.c file because I never conviced myself that the host_utils version was bug-free. I would likely switch to the common version if I could be sure it cannot lead to any regression. Like this? Questions/Comments I have: - Is the BSD-style copyright still ok for this version? This I cannot tell. Fabrice should say how he feels about it. 1 detail: I just copied Fabrice code from i386 target, then I don't own any copyright on it... BSD-style license is OK. [...] Fabrice.
Re: [Qemu-devel] How to split vl.h
Blue Swirl wrote: > Hi, > > With the automatic dependency rule installed, modifying vl.h causes > all files to be recompiled. This is of course the correct action, but > it's a major slowdown for development too. There must be an option in the Makefile to disable the automatic dependency check. > How should we split vl.h into smaller pieces? Give each device a > header file, like m48t59? What about other stuff exported from vl.c? The net result is that you will have dozens of header files with only one line in them as most devices only export one function. Regards, Fabrice.
Re: [Qemu-devel] Re: [PATCH] efault - add data type to put_user()/get_user()
I think that using host addresses in __put_user and __get_user is not logical. They should use target addresses as get_user and put_user. As Paul said, It is not worth mixing get/put/copy and lock/unlock functions. The ultimate goal of such cleanup is not only to generate -EFAULT correctly but also to be able to have arbitrary address space changes. In fact it would be good to be able to introduce an arbitrary address space change (such as a translation as Paul did) so that we can verify that all the Linux emulation stills works in this case. Regards, Fabrice. Thayne Harbaugh wrote: > On Wed, 2007-10-31 at 16:44 -0600, Thayne Harbaugh wrote: >> This patch updates get_user() and put_user() to take a third argument of >> data type. get_user() and put_user() use target address which are >> target_ulong and don't reflect the data type pointed to in target >> memory. >> >> Simply casting the target_ulong to a type before passing to >> get/put_user() is poor because target_ulong isn't always a simple cast >> to a host type (consider 32 bit on 64 bit where address are either >> extended or truncate). Also, simple casting of the argument to >> get/put_user() results in several warnings when target and long pointer >> sizes don't match. >> >> This patch has additional updates to fix places where get/put_user() are >> already used. > > This is an updated patch that doesn't conflict with the > abi_long/abi_ulong changes from a couple weeks ago.
Re: [Qemu-devel] [RFC] linux-user (mostly syscall.c)
Thayne Harbaugh wrote: > On Sat, 2007-11-03 at 13:52 +0100, J. Mayer wrote: >> On Sat, 2007-11-03 at 01:21 +, Thiemo Seufer wrote: >> [...] >> But it could be great to group the syscalls by >> categories, or so. For example, putting all POSIX compliant syscalls in >> a single file and using a syscall table could make quite easy to develop >> a BSD-user target (I did this in the past, not in Qemu though...). POSIX >> compliant interfaces can mostly be shared with Linux ones and a lot of >> other syscalls are common to the 3 BSD flavors (Net, Open and Free..). >> Being able to add a BSD target sharing the same code would be a proof >> the code is flexible and well organized; I guess large parts of the >> Darwin user target could also be merged with a FreeBSD user target... > > That's a reasonable strategy as well. I've looked through some of the > darwin code and have considered how common code could be merged. I am strongly against such merges. Different OS emulation must be handled in different directories (and maybe even in different projects) as they are likely to have subtle differences which makes impossible to test a modification made for one OS without testing all the other OSes. Regards, Fabrice.
Re: [Qemu-devel] [PATCH, RFC] Disable implicit self-modifying code support for RISC CPUs
Blue Swirl wrote: > Hi, > > RISC CPUs don't support self-modifying code unless the affected area > is flushed explicitly. This patch disables the extra effort for SMC. > The changes in this version would affect all CPUs except x86, but I'd > like to see if there are problems with some target, so that the > committed change can be limited. Without comments, I'll just disable > SMC for Sparc, as there are no problems. So please comment, especially > if you want to "opt in". > > For some reason, I can't disable all TB/TLB flushing, for example > there was already one line with TARGET_HAS_SMC || 1, but removing the > || 1 part causes crashing. Does anyone know why? With the current QEMU architecture, you cannot disable self-modifying code as you did. This is why I did not fully supported the TARGET_HAS_SMC flag. The problem is that the translator make the assumption that the RAM and the TB contents are consistent for example when handling exceptions. Suppressing this assumption is possible but requires more work. Regards, Fabrice.
Re: [Qemu-devel] [PATCH] Add TPM support
Thomas Bleher wrote: Thiemo Seufer told me that GPLv2 is fine for qemu, therefore I'd like to ask that this patch be included in qemu as I posted it (the second version with the clarified GPLv2 license). I prefer that a BSD style license is used, especially if the code just contains wrappers. Regards, Fabrice.
Re: [Qemu-devel] Re: [PATCH] efault - add data type to put_user()/get_user()
Thayne Harbaugh wrote:
> On Sat, 2007-11-03 at 20:05 +0100, Fabrice Bellard wrote:
>> I think that using host addresses in __put_user and __get_user is not
>> logical. They should use target addresses as get_user and put_user. As
>> Paul said, It is not worth mixing get/put/copy and lock/unlock functions.
>
> Please see the "RFC: x86_64 Best way to fix 'cast to pointer'" email for
> some discussion of get/put/copy and lock/unlock. {get,put}_user() is
> used for individual ints or other atomically writable types that are
> passed as pointers into a syscall. copy_{to,from}_user_() are
> used for structures that are passed to a syscall. lock/unlock() will be
> used internally in these because lock/unlock does address translation.
> lock/unlock() are still needed and are independent. __{get,put}_user()
> will operate internally in these functions on structure data members
> where lock/unlock() access_ok() have already been called.
I believed I was clear : once you keep lock/unlock, there is no point in
modifying the code to use put_user/get_user and copy[to,from]_user.
So either you keep the code as it is and extend lock and unlock to
return an error code or you suppress all lock/unlock to use a Linux like
API (i.e. put_user/get_user , copy[to,from]_user, access_ok,
__put_user/__get_user).
So for gettimeofday, if we exclude the fact that the conversion of
struct timeval will be factorized, you have either:
{
struct timeval tv;
ret = get_errno(gettimeofday(&tv, NULL));
if (!is_error(ret)) {
struct target_timeval *target_tv;
lock_user_struct(target_tv, arg1, 0);
target_tv->tv_sec = tswapl(tv->tv_sec);
target_tv->tv_usec = tswapl(tv->tv_usec);
if (unlock_user_struct(target_tv, arg1, 1)) {
ret = -TARGET_EFAULT;
goto fail;
}
}
}
Or
{
struct timeval tv;
ret = get_errno(gettimeofday(&tv, NULL));
if (!is_error(ret)) {
struct target_timeval target_tv;
target_tv.tv_sec = tswapl(tv->tv_sec);
target_tv.tv_usec = tswapl(tv->tv_usec);
if (copy_to_user(arg1, &target_tv, sizeof(target_tv)) {
ret = -TARGET_EFAULT;
goto fail;
}
}
}
Personally I prefer the Linux API style, but Paul's lock/unlock is also
perfectly logical. The advantage of keeping the Paul's API is that you
can minimize the number of changes.
Another point is that if you use the Linux API style, it is not needed
to change the API as you want to do. The only useful addition I see is
to add an automatic tswap in get/put/__get/__put user as it is done now.
Moreover, it may be questionnable to do the page right check in
access_ok(). The Linux kernel does not do it at that point : access_ok()
only verifies that the address is in the user address space.
> [...]
Fabrice.
Re: [Qemu-devel] Re: [PATCH] efault - add data type to put_user()/get_user()
Thayne Harbaugh wrote:
> On Mon, 2007-11-05 at 22:42 +0100, Fabrice Bellard wrote:
>> Thayne Harbaugh wrote:
>>> On Sat, 2007-11-03 at 20:05 +0100, Fabrice Bellard wrote:
>>>> I think that using host addresses in __put_user and __get_user is not
>>>> logical. They should use target addresses as get_user and put_user. As
>>>> Paul said, It is not worth mixing get/put/copy and lock/unlock functions.
>>> Please see the "RFC: x86_64 Best way to fix 'cast to pointer'" email for
>>> some discussion of get/put/copy and lock/unlock. {get,put}_user() is
>>> used for individual ints or other atomically writable types that are
>>> passed as pointers into a syscall. copy_{to,from}_user_() are
>>> used for structures that are passed to a syscall. lock/unlock() will be
>>> used internally in these because lock/unlock does address translation.
>>> lock/unlock() are still needed and are independent. __{get,put}_user()
>>> will operate internally in these functions on structure data members
>>> where lock/unlock() access_ok() have already been called.
>> I believed I was clear : once you keep lock/unlock, there is no point in
>> modifying the code to use put_user/get_user and copy[to,from]_user.
>
> without lock/unlock how do you propose that target/host address
> translation be performed? Are you suggesting a g2h() inside of
> copy_{to,from}_user()?
Yes.
Keep in mind that g2h() is only the simple case in case the target
address space is directly addressable. I don't want that the API makes
this supposition, so in the general case copy_[to,from]user are the only
method you have to exchange data with the user space.
>> So either you keep the code as it is and extend lock and unlock to
>> return an error code or you suppress all lock/unlock to use a Linux like
>> API (i.e. put_user/get_user , copy[to,from]_user, access_ok,
>> __put_user/__get_user).
>
> The error code because lock/unlock_user would then call access_ok()?
Of course.
>> So for gettimeofday, if we exclude the fact that the conversion of
>> struct timeval will be factorized, you have either:
>>
>> {
>> struct timeval tv;
>> ret = get_errno(gettimeofday(&tv, NULL));
>> if (!is_error(ret)) {
>> struct target_timeval *target_tv;
>>
>> lock_user_struct(target_tv, arg1, 0);
>> target_tv->tv_sec = tswapl(tv->tv_sec);
>> target_tv->tv_usec = tswapl(tv->tv_usec);
>> if (unlock_user_struct(target_tv, arg1, 1)) {
>> ret = -TARGET_EFAULT;
>> goto fail;
>> }
>> }
>> }
>>
>> Or
>>
>> {
>> struct timeval tv;
>> ret = get_errno(gettimeofday(&tv, NULL));
>> if (!is_error(ret)) {
>> struct target_timeval target_tv;
>>
>> target_tv.tv_sec = tswapl(tv->tv_sec);
>> target_tv.tv_usec = tswapl(tv->tv_usec);
>> if (copy_to_user(arg1, &target_tv, sizeof(target_tv)) {
>> ret = -TARGET_EFAULT;
>> goto fail;
>> }
>> }
>> }
>
> I don't see where the second one is handling target/host address
> translation.
copy_to_user() does it.
> A problem with both of the above examples is that they use tswapl().
> Without the proper type casting tswapl() doesn't do proper sign
> extension when dealing with 64bit/32bit host/target relationships. I've
> fixed more than one location where this has resulted in bugs.
This is an unrelated problem. If tswapl is not sufficient then another
function can be added.
> [...]
Regards,
Fabrice.
Re: [Qemu-devel] [PATCH] Add TPM support
Thomas Bleher wrote:
> * Fabrice Bellard <[EMAIL PROTECTED]> [2007-11-05 16:40]:
>> Thomas Bleher wrote:
>>> Thiemo Seufer told me that GPLv2 is fine for qemu, therefore I'd like to
>>> ask that this patch be included in qemu as I posted it (the second
>>> version with the clarified GPLv2 license).
>> I prefer that a BSD style license is used, especially if the code just
>> contains wrappers.
>
> Fine with me, too.
OK.
> +result = write(s->tpm_fd, s->send_data, s->send_data_index);
> +if (result < s->send_data_index) {
> +fprintf(stderr, "WARNING: Failed to write data to tpm!\n");
> +return ATML_STATUS_BUSY;
> +}
You should handle EINTR and EAGAIN.
> +s->send_data_index = 0;
> +s->recv_data_pos = 0;
> +s->recv_data_length = 0;
> +s->data_to_send = 0;
> +s->data_to_recv = 1;
> +}
> +if (s->data_to_recv) {
> +if (poll(&(s->tpm_poll), 1, 0) > 0) {
poll is not needed as read will block.
> +result = read(s->tpm_fd, s->recv_data, 2048);
> +if (result < 6) { // a minimal packet is 6 bytes long
> +fprintf(stderr, "WARNING: Not enough data from tpm!\n");
> +return ATML_STATUS_BUSY;
> +}
same comment as write().
> +res = connect(sock, (struct sockaddr*)&addr, sizeof(struct sockaddr_un));
> +if (res < 0)
> +return -1;
same comment for EINTR.
+/* should be called first, initializes all structures and connects to
the external emulator */
+void tpm_configure(const char* tpm_socket)
+{
Suppress this function (cf tpm_register).
> +/* split of from tpm_configure() so the configuration can be called earlier
> */
> +void tpm_register()
Ansi C requires void in parameters. Allocate the state and return it.
Suppress the global variable tpm_state. Pass the path to this function
and suppress the configure function. Add a global variable for the path
and register the device if it is not NULL.
Regards,
Fabrice.
Re: [Qemu-devel] RFC: x86_64 Best way to fix 'cast to pointer from integer of different size' problems?
Paul Brook wrote: > [...] > Personally I like the locking interface as it allows a zero-copy > implementation. However the kernel uses a copying interface, and my > understanding is that other qemu maintainers also prefer the copying > interface. At least I don't think it is critical performance wise, especially if the page flag checks are added ! Before you added the current zero copy interface, my plan was to use a zero copy interface just for big buffers such as the one for read/write. Another point is that the code from signal.c is not converted to the zero-copy interface and it is a significant source of complexity as there is a large amount of target specific code copied from the Linux kernel to generate the stack frame. Regards, Fabrice.
Re: [Qemu-devel] qemu qemu-doc.texi vl.c vl.h hw/mc146818rtc.c
Stefan Weil wrote: > Hi, > > the change from mc146818rtc.c might be needed for other timer > implementations, > too (because not all systems emulated by QEMU use mc146818rtc.c). > > A list of candidates is here (fgrep gmtime, fgrep gettime): > hw/m48t59.c:gmtime_r (&t, tm); > hw/omap.c:s->convert = rtc_utc ? gmtime_r : localtime_r; > hw/pl031.c:tm = gmtime(&ti); > hw/pxa2xx.c:tm = gmtime(&ti); > hw/etraxfs_timer.c: gettimeofday(&now, NULL); > > hw/omap.c needs additional changes for Windows, because gmtime_r > is missing there. > > Maybe all those locations should use a central function (to be written). Right. There should be at least a function which returns the "current time" with the rtc_utc flag handling. Fabrice.
Re: [Qemu-devel] RFC: x86_64 Best way to fix 'cast to pointer from integer of different size' problems?
Hi, Regarding the user memory access, here is my suggestion which should minimize the changes: - Keep __put_user() and __get_user() as you did. - Remove put_user(), get_user(), copy_from_user() and copy_to_user() - Modify the signal.c code so that it uses __put_user, __get_user and lock/unlock_user. - Modify lock_user() so that it automatically does access_ok() and returns NULL if access_ok() fails. - Test lock_user/lock_user_struct/... return value explicitely at every call. - 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. - Suppress or fix tput/tget macros so that they do access_ok(). Regards, Fabrice.
[Qemu-devel] qemu Makefile Makefile.target
CVSROOT:/sources/qemu Module name:qemu Changes by: Fabrice Bellard07/11/07 19:24:02 Modified files: . : Makefile Makefile.target Log message: compile common code once CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/Makefile?cvsroot=qemu&r1=1.127&r2=1.128 http://cvs.savannah.gnu.org/viewcvs/qemu/Makefile.target?cvsroot=qemu&r1=1.216&r2=1.217
[Qemu-devel] qemu configure
CVSROOT:/sources/qemu Module name:qemu Changes by: Fabrice Bellard07/11/07 19:25:15 Modified files: . : configure Log message: SDL and COCA are no longer target dependent - support for common code compilation CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/configure?cvsroot=qemu&r1=1.167&r2=1.168
[Qemu-devel] qemu vl.h
CVSROOT:/sources/qemu Module name:qemu Changes by: Fabrice Bellard07/11/07 19:26:23 Modified files: . : vl.h Log message: fixed QEMU_TOOL tests CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/vl.h?cvsroot=qemu&r1=1.288&r2=1.289
[Qemu-devel] qemu/audio audio.h
CVSROOT:/sources/qemu Module name:qemu Changes by: Fabrice Bellard07/11/07 19:26:55 Modified files: audio : audio.h Log message: use config-host.h instead of config.h CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/audio/audio.h?cvsroot=qemu&r1=1.9&r2=1.10
[Qemu-devel] qemu/slirp slirp.h
CVSROOT:/sources/qemu Module name:qemu Changes by: Fabrice Bellard07/11/07 19:27:18 Modified files: slirp : slirp.h Log message: use config-host.h instead of config.h CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/slirp/slirp.h?cvsroot=qemu&r1=1.13&r2=1.14
[Qemu-devel] Removal of some target CPU macros
I noticed that some target CPUs macros have been added while they do not seem necessary. I don't like that because it introduces more #ifdefs which prevent making a version supporting simultaneously all the CPUs. In particular I saw the following: - TARGET_MIPSN32 : it is always combined with TARGET_MIPS64 in target-mips/. If its only usage is to select a different Linux ABI, then I suggest keeping TARGET_MIPS64 and using another define to choose that. - TARGET_PPC64H, TARGET_PPCEMB : I see no reason why they cannot be handled dynamically as the other PowerPC CPU types, provided that TARGET_PPC64 is defined. Is it the long term plan ? Regards, Fabrice.
[Qemu-devel] qemu/hw pc.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Fabrice Bellard07/11/07 16:54:42 Modified files: hw : pc.c Log message: removed traces CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/hw/pc.c?cvsroot=qemu&r1=1.88&r2=1.89
[Qemu-devel] qemu qemu-doc.texi vl.c vl.h hw/mc146818rtc.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Fabrice Bellard07/11/07 16:24:34 Modified files: . : qemu-doc.texi vl.c vl.h hw : mc146818rtc.c Log message: added -startdate option CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/qemu-doc.texi?cvsroot=qemu&r1=1.163&r2=1.164 http://cvs.savannah.gnu.org/viewcvs/qemu/vl.c?cvsroot=qemu&r1=1.353&r2=1.354 http://cvs.savannah.gnu.org/viewcvs/qemu/vl.h?cvsroot=qemu&r1=1.287&r2=1.288 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/mc146818rtc.c?cvsroot=qemu&r1=1.12&r2=1.13
