Re: [Qemu-devel] [PATCH] SVM support
On Thu, 2007-09-13 at 17:27 +0200, Alexander Graf wrote:
Thiemo Seufer wrote:
Alexander Graf wrote:
Thanks to Michael Peter who tried the patch on an x86 host I found some
compilation problems.
This updated patch addresses these issues and thus should compile on
every platform for every target available.
[...]
Wow sorry about that, looks like I missed these.
Index: qemu-0.9.0.cvs/exec-all.h
===
--- qemu-0.9.0.cvs.orig/exec-all.h
+++ qemu-0.9.0.cvs/exec-all.h
@@ -166,6 +166,7 @@ static inline int tlb_set_page(CPUState
typedef struct TranslationBlock {
target_ulong pc; /* simulated PC corresponding to this block (EIP
+ CS base) */
target_ulong cs_base; /* CS base for this block */
+uint64_t intercept; /* SVM intercept vector */
unsigned int flags; /* flags defining in which context the code was
generated */
uint16_t size; /* size of target code for this block (1 =
size = TARGET_PAGE_SIZE) */
Index: qemu-0.9.0.cvs/cpu-all.h
===
--- qemu-0.9.0.cvs.orig/cpu-all.h
+++ qemu-0.9.0.cvs/cpu-all.h
@@ -715,6 +715,7 @@ extern int code_copy_enabled;
#define CPU_INTERRUPT_HALT 0x20 /* CPU halt wanted */
#define CPU_INTERRUPT_SMI0x40 /* (x86 only) SMI interrupt pending
*/
#define CPU_INTERRUPT_DEBUG 0x80 /* Debug event occured. */
+#define CPU_INTERRUPT_VIRQ 0x100 /* virtual interrupt pending. */
void cpu_interrupt(CPUState *s, int mask);
void cpu_reset_interrupt(CPUState *env, int mask);
Those two patches look ugly to me as target specific features should
never go in generic code or structures.
The CPU_INTERRUPT flags should just contain information about the
emulator behavior, thus CPU_INTERRUPT_TIMER, CPU_INTERRUPT_SMI are to be
removed. Target specific informations about the exception nature should
go in the CPUState structure... Then, adding a CPU_INTERRUPT_VIRQ seems
not a good idea at all: it's outside of the generic emulator scope and
pointless for most targets.
For the same reason, the intercept field in the TB structure seems not
acceptable, as TB specific target informations are already to be stored
in the flags field. As intercept seems only to be a bit field, it should
go, in a way or another, in tb flags. And as it seems that some
interceptions are related with functions implemented in helpers (not
micro-ops), you'd better check the interception in the helper at
runtime, which would add no visible overhead (as calling a helper is
slow compared to direct micro-ops execution), then you would not need to
store those infos in the TB structure. This may even make the emulation
run faster has you won't fill the TB cache with multiple translation of
the same code each time the env-intercept changes, thus have chance to
avoid many TB caches flushes.
Regards.
--
J. Mayer [EMAIL PROTECTED]
Never organized
Re: [Qemu-devel] qemu Changelog Makefile Makefile.target TODO ae...
On Sun, 2007-09-16 at 21:08 +, Thiemo Seufer wrote: CVSROOT: /sources/qemu Module name: qemu Changes by: Thiemo Seufer ths 07/09/16 21:08:06 Modified files: . : Changelog Makefile Makefile.target TODO aes.c alpha-dis.c arm-dis.c arm-semi.c block-bochs.c block-cloop.c block-cow.c block-dmg.c block-qcow.c block-qcow2.c block-raw.c block-vmdk.c block-vpc.c block-vvfat.c block.c block_int.h bswap.h cocoa.m configure console.c cpu-all.h cpu-defs.h cpu-exec.c cutils.c dis-asm.h disas.c dyngen-exec.h dyngen.c dyngen.h elf.h elf_ops.h exec-all.h exec.c gdbstub.c keymaps.c kqemu.c kqemu.h loader.c m68k-dis.c m68k-semi.c mips-dis.c monitor.c osdep.c ppc-dis.c qemu-doc.texi qemu-img.c qemu-img.texi qemu-tech.texi readline.c s390-dis.c sdl.c sh4-dis.c softmmu-semi.h softmmu_header.h softmmu_template.h sparc-dis.c tap-win32.c texi2pod.pl thunk.c thunk.h translate-all.c translate-op.c usb-linux.c vl.c vl.h vnc.c vnchextile.h darwin-user: syscall.c fpu: softfloat-native.c hw : acpi.c adb.c alpha_palcode.c an5206.c apb_pci.c apic.c arm_boot.c arm_gic.c arm_pic.c arm_pic.h arm_sysctl.c arm_timer.c cdrom.c cirrus_vga.c cirrus_vga_rop.h cirrus_vga_rop2.h cuda.c eepro100.c esp.c fdc.c grackle_pci.c gt64xxx.c heathrow_pic.c i2c.c i8254.c i8259.c ide.c integratorcp.c iommu.c irq.c isa_mmio.c jazz_led.c lsi53c895a.c m48t59.c mc146818rtc.c mcf5206.c mcf5208.c mcf_fec.c mcf_intc.c mcf_uart.c mips_malta.c mips_r4k.c nand.c ne2000.c omap.h omap_lcd_template.h openpic.c parallel.c pc.c pci.c pci_host.h pckbd.c pcnet.c pflash_cfi02.c piix_pci.c pl011.c pl050.c pl080.c pl110.c pl110_template.h pl181.c pl190.c ppc.c ppc405.h ppc405_boards.c ppc405_uc.c ppc_chrp.c ppc_prep.c prep_pci.c ps2.c ptimer.c pxa2xx_gpio.c pxa2xx_template.h realview.c rtl8139.c sd.c sd.h serial.c sh7750.c sh7750_regs.h shix.c slavio_intctl.c slavio_misc.c slavio_serial.c slavio_timer.c smbus.c smbus.h smbus_eeprom.c smc91c111.c sparc32_dma.c sun4m.c sun4u.c tcx.c unin_pci.c usb-hid.c usb-hub.c usb-msd.c usb-uhci.c usb-wacom.c usb.c usb.h versatile_pci.c versatilepb.c vga.c vga_int.h vga_template.h vmmouse.c keymaps: common de-ch et fr is modifiers nl sv linux-user : elfload.c flat.h flatload.c linuxload.c m68k-sim.c main.c mmap.c qemu.h signal.c syscall.c syscall_defs.h syscall_types.h vm86.c linux-user/alpha: syscall_nr.h linux-user/ppc : syscall.h linux-user/ppc64: syscall.h linux-user/sh4 : termbits.h linux-user/sparc: termbits.h linux-user/sparc64: termbits.h linux-user/x86_64: syscall_nr.h slirp : COPYRIGHT bootp.c cksum.c debug.c debug.h if.c if.h ip_icmp.c ip_input.c ip_output.c libslirp.h main.h mbuf.c mbuf.h misc.c misc.h sbuf.c sbuf.h slirp.c socket.c socket.h tcp_input.c tcp_output.c tcp_subr.c tcp_timer.c tftp.c tftp.h udp.c udp.h target-alpha : cpu.h exec.h helper.c op.c op_helper.c op_helper.h op_helper_mem.h op_mem.h op_template.h translate.c target-arm : cpu.h exec.h helper.c op.c op_helper.c op_iwmmxt.c op_template.h translate.c target-arm/nwfpe: double_cpdo.c extended_cpdo.c fpa11.c fpa11.h fpa11_cpdo.c fpa11_cpdt.c fpa11_cprt.c fpopcode.c fpopcode.h fpsr.h single_cpdo.c target-i386: cpu.h exec.h helper.c helper2.c op.c opreg_template.h ops_sse.h ops_template.h ops_template_mem.h translate-copy.c translate.c target-m68k: cpu.h exec.h helper.c op.c op_helper.c translate.c target-mips:
[Qemu-devel] qemu Changelog aes.c arm-dis.c arm-semi.c block...
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer ths 07/09/17 08:09:55 Modified files: . : Changelog aes.c arm-dis.c arm-semi.c block-bochs.c block-cloop.c block-cow.c block-dmg.c block-qcow.c block-qcow2.c block-raw.c block-vmdk.c block-vpc.c block-vvfat.c block.c block_int.h cocoa.m console.c cpu-exec.c dis-asm.h disas.c dyngen.c dyngen.h elf_ops.h exec-all.h exec.c gdbstub.c kqemu.c loader.c m68k-dis.c mips-dis.c monitor.c qemu-doc.texi qemu-img.c readline.c s390-dis.c sdl.c sh4-dis.c softmmu_template.h sparc-dis.c tap-win32.c thunk.c translate-all.c usb-linux.c vl.c vl.h vnc.c darwin-user: syscall.c hw : acpi.c adb.c alpha_palcode.c apic.c cdrom.c cirrus_vga.c cirrus_vga_rop2.h cuda.c esp.c grackle_pci.c gt64xxx.c heathrow_pic.c i8254.c i8259.c ide.c iommu.c m48t59.c mc146818rtc.c mips_malta.c ne2000.c openpic.c parallel.c pc.c pci.c pckbd.c pcnet.c pflash_cfi02.c pl011.c pl110.c pl181.c ppc.c ppc405_boards.c ppc405_uc.c ppc_chrp.c ps2.c rtl8139.c serial.c slavio_intctl.c slavio_serial.c slavio_timer.c smbus_eeprom.c smc91c111.c tcx.c usb-hid.c usb-hub.c usb-msd.c usb-uhci.c usb.h vga.c vga_int.h vga_template.h linux-user : elfload.c flat.h flatload.c linuxload.c main.c mmap.c signal.c syscall.c syscall_defs.h syscall_types.h vm86.c linux-user/alpha: syscall_nr.h slirp : bootp.c cksum.c debug.c if.c ip_icmp.c ip_output.c mbuf.c misc.c sbuf.c slirp.c socket.c socket.h tcp_input.c tcp_output.c tcp_subr.c tcp_timer.c tftp.c udp.c target-alpha : helper.c target-arm : cpu.h op.c translate.c target-arm/nwfpe: double_cpdo.c extended_cpdo.c fpa11.c fpa11.h fpa11_cpdo.c fpa11_cpdt.c fpa11_cprt.c fpopcode.c fpopcode.h single_cpdo.c target-i386: cpu.h exec.h helper.c helper2.c op.c ops_sse.h ops_template.h translate-copy.c translate.c target-m68k: cpu.h op.c translate.c target-mips: helper.c op_helper.c translate.c target-ppc : helper.c mfrom_table_gen.c op_helper.c translate.c translate_init.c target-sh4 : README.sh4 target-sparc : op.c op_helper.c tests : hello-arm.c linux-test.c qruncom.c runcom.c test-i386-code16.S test-i386-vm86.S test-i386.c Log message: find -type f | xargs sed -i 's/[\t ]*$//g' # Yes, again. Note the star in the regex. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/Changelog?cvsroot=qemur1=1.139r2=1.140 http://cvs.savannah.gnu.org/viewcvs/qemu/aes.c?cvsroot=qemur1=1.2r2=1.3 http://cvs.savannah.gnu.org/viewcvs/qemu/arm-dis.c?cvsroot=qemur1=1.4r2=1.5 http://cvs.savannah.gnu.org/viewcvs/qemu/arm-semi.c?cvsroot=qemur1=1.5r2=1.6 http://cvs.savannah.gnu.org/viewcvs/qemu/block-bochs.c?cvsroot=qemur1=1.4r2=1.5 http://cvs.savannah.gnu.org/viewcvs/qemu/block-cloop.c?cvsroot=qemur1=1.5r2=1.6 http://cvs.savannah.gnu.org/viewcvs/qemu/block-cow.c?cvsroot=qemur1=1.8r2=1.9 http://cvs.savannah.gnu.org/viewcvs/qemu/block-dmg.c?cvsroot=qemur1=1.6r2=1.7 http://cvs.savannah.gnu.org/viewcvs/qemu/block-qcow.c?cvsroot=qemur1=1.13r2=1.14 http://cvs.savannah.gnu.org/viewcvs/qemu/block-qcow2.c?cvsroot=qemur1=1.8r2=1.9 http://cvs.savannah.gnu.org/viewcvs/qemu/block-raw.c?cvsroot=qemur1=1.20r2=1.21 http://cvs.savannah.gnu.org/viewcvs/qemu/block-vmdk.c?cvsroot=qemur1=1.15r2=1.16 http://cvs.savannah.gnu.org/viewcvs/qemu/block-vpc.c?cvsroot=qemur1=1.5r2=1.6 http://cvs.savannah.gnu.org/viewcvs/qemu/block-vvfat.c?cvsroot=qemur1=1.9r2=1.10 http://cvs.savannah.gnu.org/viewcvs/qemu/block.c?cvsroot=qemur1=1.45r2=1.46 http://cvs.savannah.gnu.org/viewcvs/qemu/block_int.h?cvsroot=qemur1=1.12r2=1.13 http://cvs.savannah.gnu.org/viewcvs/qemu/cocoa.m?cvsroot=qemur1=1.12r2=1.13 http://cvs.savannah.gnu.org/viewcvs/qemu/console.c?cvsroot=qemur1=1.14r2=1.15 http://cvs.savannah.gnu.org/viewcvs/qemu/cpu-exec.c?cvsroot=qemur1=1.112r2=1.113 http://cvs.savannah.gnu.org/viewcvs/qemu/dis-asm.h?cvsroot=qemur1=1.15r2=1.16 http://cvs.savannah.gnu.org/viewcvs/qemu/disas.c?cvsroot=qemur1=1.41r2=1.42
[Qemu-devel] qemu hw/ppc405_uc.c hw/ppc_chrp.c hw/ppc_prep.c...
CVSROOT:/sources/qemu Module name:qemu Changes by: Jocelyn Mayer j_mayer 07/09/17 08:21:54 Modified files: hw : ppc405_uc.c ppc_chrp.c ppc_prep.c target-ppc : cpu.h exec.h helper.c op.c op_helper.c op_helper_mem.h op_mem.h op_template.h translate.c translate_init.c Log message: Coding style fixes in PowerPC related code (no functional change): - avoid useless blanks at EOL. - avoid tabs. - fix wrapping lines on 80 chars terminals. - add missing ';' at macros EOL to avoid confusing auto-identers. - fix identation. - Remove historical macros in micro-ops (PARAM, SPARAM, PPC_OP, regs) CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/hw/ppc405_uc.c?cvsroot=qemur1=1.6r2=1.7 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/ppc_chrp.c?cvsroot=qemur1=1.39r2=1.40 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/ppc_prep.c?cvsroot=qemur1=1.40r2=1.41 http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/cpu.h?cvsroot=qemur1=1.50r2=1.51 http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/exec.h?cvsroot=qemur1=1.23r2=1.24 http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/helper.c?cvsroot=qemur1=1.51r2=1.52 http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/op.c?cvsroot=qemur1=1.38r2=1.39 http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/op_helper.c?cvsroot=qemur1=1.35r2=1.36 http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/op_helper_mem.h?cvsroot=qemur1=1.9r2=1.10 http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/op_mem.h?cvsroot=qemur1=1.14r2=1.15 http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/op_template.h?cvsroot=qemur1=1.9r2=1.10 http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/translate.c?cvsroot=qemur1=1.62r2=1.63 http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/translate_init.c?cvsroot=qemur1=1.21r2=1.22
Re: [Qemu-devel] qemu Changelog aes.c arm-dis.c arm-semi.c block...
On 9/17/07, Thiemo Seufer [EMAIL PROTECTED] wrote: Log message: find -type f | xargs sed -i 's/[\t ]*$//g' # Yes, again. Note the star in the regex. so you're going to do this each time you receive a faulty patch ? I thought this kind of search and replace is more likely to happen when cleaning up just before release. is qemu-0.9.1 going to be reached anytime soon then ? ;-) -- Christian -- http://detaolb.sourceforge.net/, a linux distribution for Qemu with Git inside !
Re: [Qemu-devel] qemu Changelog Makefile Makefile.target TODO ae...
On 9/17/07, J. Mayer [EMAIL PROTECTED] wrote: Log message: find -type f | xargs sed -i 's/[\t ]$//g' # on most files Many thanks for generating hundreds of conflicts with a useless commit. Don't know what's wrong in your expression but it did not what you think it should (and you did not even check). DON'T DO THIS KIND OF COMMIT AGAIN, PLEASE. if we were using git (but you can do it locally anyway), you would not have these conflicts problems... git-apply indead has this feature about ignoring useless whitespaces... -- Christian -- http://detaolb.sourceforge.net/, a linux distribution for Qemu with Git inside !
Re: [Qemu-devel] Comment for Solaris fix for the HPTC
Andreas Schwab wrote: Your reference to ULONG_MAX is a red herring. ULONG_MAX is the limit for unsigned long, and ULONG_LONG_MAX is the limit for unsigned long long. If your compiler does not support the long long type then ULONG_LONG_MAX should not be defined either. Instead, vl.c should use UINT64_MAX. Looking at a (draft) c99 standard document, I don't find any references for an ULONG_LONG_MAX macro, anyway. The c99 limits.h header is supposed to define LLONG_MIN, LLONG_MAX and ULLONG_MAX for the long long and unsigned long long type limits...
Re: [Qemu-devel] qemu Changelog Makefile Makefile.target TODO ae...
Hi, On Mon, 17 Sep 2007, J. Mayer wrote: On Sun, 2007-09-16 at 21:08 +, Thiemo Seufer wrote: CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer ths 07/09/16 21:08:06 [lots of changes] Log message: find -type f | xargs sed -i 's/[\t ]$//g' # on most files Many thanks for generating hundreds of conflicts with a useless commit. It is a whitespace fix, designed to remove tabs and spaces from ends of lines, where they have no business of being. Yes, it is a style fix. But a fix nevertheless. And your conflicts are probably DUE TO AN INFERIOUR MERGE TOOL that _you_ use. Time to join the modern world? Ciao, Dscho
Re: [Qemu-devel] qemu Changelog Makefile Makefile.target TODO ae...
On Mon, 2007-09-17 at 10:27 +0200, Christian MICHON wrote: On 9/17/07, J. Mayer [EMAIL PROTECTED] wrote: Log message: find -type f | xargs sed -i 's/[\t ]$//g' # on most files Many thanks for generating hundreds of conflicts with a useless commit. Don't know what's wrong in your expression but it did not what you think it should (and you did not even check). DON'T DO THIS KIND OF COMMIT AGAIN, PLEASE. if we were using git (but you can do it locally anyway), you would not have these conflicts problems... Maybe... but Savannah uses a CVS frontend, as far as I know... git-apply indead has this feature about ignoring useless whitespaces... It does not seem a good idea that tools modify the code in our back. Better learn people (including me...) not to write/commit incorrect code... Should also learn people not to break other's code, but that seems far to difficult to understand Regards. -- J. Mayer [EMAIL PROTECTED] Never organized
[Qemu-devel] qemu/target-ppc op.c op_helper.c op_mem.h trans...
CVSROOT:/sources/qemu Module name:qemu Changes by: Jocelyn Mayer j_mayer 07/09/17 09:51:40 Modified files: target-ppc : op.c op_helper.c op_mem.h translate.c Log message: PowerPC flags update/use fixes: - fix confusion between overflow/summary overflow, as reported by S Bansal. - reset carry in addic. optimized case (as it was already done in addic). CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/op.c?cvsroot=qemur1=1.39r2=1.40 http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/op_helper.c?cvsroot=qemur1=1.36r2=1.37 http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/op_mem.h?cvsroot=qemur1=1.15r2=1.16 http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/translate.c?cvsroot=qemur1=1.63r2=1.64
Re: [Qemu-devel] [PATCH] SVM support
J. Mayer wrote:
On Thu, 2007-09-13 at 17:27 +0200, Alexander Graf wrote:
Thiemo Seufer wrote:
Alexander Graf wrote:
Thanks to Michael Peter who tried the patch on an x86 host I found some
compilation problems.
This updated patch addresses these issues and thus should compile on
every platform for every target available.
[...]
Wow sorry about that, looks like I missed these.
Index: qemu-0.9.0.cvs/exec-all.h
===
--- qemu-0.9.0.cvs.orig/exec-all.h
+++ qemu-0.9.0.cvs/exec-all.h
@@ -166,6 +166,7 @@ static inline int tlb_set_page(CPUState
typedef struct TranslationBlock {
target_ulong pc; /* simulated PC corresponding to this block (EIP
+ CS base) */
target_ulong cs_base; /* CS base for this block */
+uint64_t intercept; /* SVM intercept vector */
unsigned int flags; /* flags defining in which context the code was
generated */
uint16_t size; /* size of target code for this block (1 =
size = TARGET_PAGE_SIZE) */
Index: qemu-0.9.0.cvs/cpu-all.h
===
--- qemu-0.9.0.cvs.orig/cpu-all.h
+++ qemu-0.9.0.cvs/cpu-all.h
@@ -715,6 +715,7 @@ extern int code_copy_enabled;
#define CPU_INTERRUPT_HALT 0x20 /* CPU halt wanted */
#define CPU_INTERRUPT_SMI0x40 /* (x86 only) SMI interrupt pending
*/
#define CPU_INTERRUPT_DEBUG 0x80 /* Debug event occured. */
+#define CPU_INTERRUPT_VIRQ 0x100 /* virtual interrupt pending. */
void cpu_interrupt(CPUState *s, int mask);
void cpu_reset_interrupt(CPUState *env, int mask);
Those two patches look ugly to me as target specific features should
never go in generic code or structures.
The CPU_INTERRUPT flags should just contain information about the
emulator behavior, thus CPU_INTERRUPT_TIMER, CPU_INTERRUPT_SMI are to be
removed. Target specific informations about the exception nature should
go in the CPUState structure... Then, adding a CPU_INTERRUPT_VIRQ seems
not a good idea at all: it's outside of the generic emulator scope and
pointless for most targets.
I don't see any practical reason not to do it this way. We could define
a CPU_INTERRUPT_TARGET interrupt, that stores the information in a the
target specific CPUState, but this would hit performance (marginally
though) and does not improve the situation. I don't think that we should
should forcefully try to seperate targets where we are not even close to
running out of constants. If everyone on this list sees the situation as
Jocelyn does, I would be fine with writing a patch that puts target
specific interrupts to the specific targets.
For the same reason, the intercept field in the TB structure seems not
acceptable, as TB specific target informations are already to be stored
in the flags field. As intercept seems only to be a bit field, it should
go, in a way or another, in tb flags. And as it seems that some
TB flags is a 32-bit bitfield, where several bits are already used.
Currently SVM supports 45 intercepts and each combination can generate a
different TB, as we do not want to reduce performance for the
non-intercepted case. Think of the intercept field as flags2, that could
be used by other virtualization implementations on other architectures
too (though I do not know of any)
interceptions are related with functions implemented in helpers (not
micro-ops), you'd better check the interception in the helper at
runtime, which would add no visible overhead (as calling a helper is
slow compared to direct micro-ops execution), then you would not need to
store those infos in the TB structure. This may even make the emulation
This was the case in an earlier version of the patch. The current
implementation you see is an optimization to make it running faster, as
there is (nearly) no need for runtime detection.
run faster has you won't fill the TB cache with multiple translation of
the same code each time the env-intercept changes, thus have chance to
avoid many TB caches flushes.
This is actually intended, as I believe the emulated machine should run
as fast as before when not using any interceptions
Regards.
Regards,
Alex
Re: [Qemu-devel] qemu Changelog Makefile Makefile.target TODO ae...
DON'T DO THIS KIND OF COMMIT AGAIN, PLEASE. if we were using git (but you can do it locally anyway), you would not have these conflicts problems... Maybe... but Savannah uses a CVS frontend, as far as I know... Those are excuses. So is a you should have used X argument. It doesn't invalidate the point that the commit was disruptive, and merely acts as bait for the grand old version repository flamewar.* Like whitespace change is breaking your code. Really, I mean, come on. Who do think you are kidding? flamebaitPython programmers./flamebait ;) LionsPhil * See also, if they'd used Perl instead of find/xargs/sed
Re: [Qemu-devel] qemu Changelog Makefile Makefile.target TODO ae...
On 9/17/07, Philip Boulain [EMAIL PROTECTED] wrote: DON'T DO THIS KIND OF COMMIT AGAIN, PLEASE. if we were using git (but you can do it locally anyway), you would not have these conflicts problems... Maybe... but Savannah uses a CVS frontend, as far as I know... Those are excuses. So is a you should have used X argument. It doesn't invalidate the point that the commit was disruptive, and merely acts as bait for the grand old version repository flamewar.* since I mentionned you should have used Git, I'll repeat: this commit was not disruptive to any of the Git users, and will never be. Evolve, or prepare to be assimilated into the Collective... ;-) -- Christian -- http://detaolb.sourceforge.net/, a linux distribution for Qemu with Git inside !
Re: [Qemu-devel] qemu Changelog Makefile Makefile.target TODO ae...
J. Mayer wrote: On Sun, 2007-09-16 at 21:08 +, Thiemo Seufer wrote: CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer ths 07/09/16 21:08:06 Modified files: . : Changelog Makefile Makefile.target TODO aes.c alpha-dis.c arm-dis.c arm-semi.c block-bochs.c block-cloop.c block-cow.c block-dmg.c block-qcow.c block-qcow2.c block-raw.c block-vmdk.c block-vpc.c block-vvfat.c block.c block_int.h bswap.h cocoa.m configure console.c cpu-all.h cpu-defs.h cpu-exec.c cutils.c dis-asm.h disas.c dyngen-exec.h dyngen.c dyngen.h elf.h elf_ops.h exec-all.h exec.c gdbstub.c keymaps.c kqemu.c kqemu.h loader.c m68k-dis.c m68k-semi.c mips-dis.c monitor.c osdep.c ppc-dis.c qemu-doc.texi qemu-img.c qemu-img.texi qemu-tech.texi readline.c s390-dis.c sdl.c sh4-dis.c softmmu-semi.h softmmu_header.h softmmu_template.h sparc-dis.c tap-win32.c texi2pod.pl thunk.c thunk.h translate-all.c translate-op.c usb-linux.c vl.c vl.h vnc.c vnchextile.h darwin-user: syscall.c fpu: softfloat-native.c hw : acpi.c adb.c alpha_palcode.c an5206.c apb_pci.c apic.c arm_boot.c arm_gic.c arm_pic.c arm_pic.h arm_sysctl.c arm_timer.c cdrom.c cirrus_vga.c cirrus_vga_rop.h cirrus_vga_rop2.h cuda.c eepro100.c esp.c fdc.c grackle_pci.c gt64xxx.c heathrow_pic.c i2c.c i8254.c i8259.c ide.c integratorcp.c iommu.c irq.c isa_mmio.c jazz_led.c lsi53c895a.c m48t59.c mc146818rtc.c mcf5206.c mcf5208.c mcf_fec.c mcf_intc.c mcf_uart.c mips_malta.c mips_r4k.c nand.c ne2000.c omap.h omap_lcd_template.h openpic.c parallel.c pc.c pci.c pci_host.h pckbd.c pcnet.c pflash_cfi02.c piix_pci.c pl011.c pl050.c pl080.c pl110.c pl110_template.h pl181.c pl190.c ppc.c ppc405.h ppc405_boards.c ppc405_uc.c ppc_chrp.c ppc_prep.c prep_pci.c ps2.c ptimer.c pxa2xx_gpio.c pxa2xx_template.h realview.c rtl8139.c sd.c sd.h serial.c sh7750.c sh7750_regs.h shix.c slavio_intctl.c slavio_misc.c slavio_serial.c slavio_timer.c smbus.c smbus.h smbus_eeprom.c smc91c111.c sparc32_dma.c sun4m.c sun4u.c tcx.c unin_pci.c usb-hid.c usb-hub.c usb-msd.c usb-uhci.c usb-wacom.c usb.c usb.h versatile_pci.c versatilepb.c vga.c vga_int.h vga_template.h vmmouse.c keymaps: common de-ch et fr is modifiers nl sv linux-user : elfload.c flat.h flatload.c linuxload.c m68k-sim.c main.c mmap.c qemu.h signal.c syscall.c syscall_defs.h syscall_types.h vm86.c linux-user/alpha: syscall_nr.h linux-user/ppc : syscall.h linux-user/ppc64: syscall.h linux-user/sh4 : termbits.h linux-user/sparc: termbits.h linux-user/sparc64: termbits.h linux-user/x86_64: syscall_nr.h slirp : COPYRIGHT bootp.c cksum.c debug.c debug.h if.c if.h ip_icmp.c ip_input.c ip_output.c libslirp.h main.h mbuf.c mbuf.h misc.c misc.h sbuf.c sbuf.h slirp.c socket.c socket.h tcp_input.c tcp_output.c tcp_subr.c tcp_timer.c tftp.c tftp.h udp.c udp.h target-alpha : cpu.h exec.h helper.c op.c op_helper.c op_helper.h op_helper_mem.h op_mem.h op_template.h translate.c target-arm : cpu.h exec.h helper.c op.c op_helper.c op_iwmmxt.c op_template.h translate.c target-arm/nwfpe: double_cpdo.c extended_cpdo.c fpa11.c fpa11.h fpa11_cpdo.c fpa11_cpdt.c fpa11_cprt.c fpopcode.c fpopcode.h fpsr.h single_cpdo.c target-i386: cpu.h exec.h helper.c helper2.c op.c opreg_template.h ops_sse.h ops_template.h ops_template_mem.h translate-copy.c translate.c target-m68k: cpu.h exec.h helper.c op.c op_helper.c translate.c target-mips: exec.h fop_template.c helper.c op.c op_helper.c
Re: [Qemu-devel] qemu Changelog aes.c arm-dis.c arm-semi.c block...
Christian MICHON wrote: On 9/17/07, Thiemo Seufer [EMAIL PROTECTED] wrote: Log message: find -type f | xargs sed -i 's/[\t ]*$//g' # Yes, again. Note the star in the regex. so you're going to do this each time you receive a faulty patch ? I did so for some months now. I thought this kind of search and replace is more likely to happen when cleaning up just before release. It is supposed to happen only once. It was twice now, because I made a mistake. Thiemo
Re: [Qemu-devel] [PATCH] SVM support
On Mon, 2007-09-17 at 12:02 +0200, Alexander Graf wrote:
J. Mayer wrote:
On Thu, 2007-09-13 at 17:27 +0200, Alexander Graf wrote:
Thiemo Seufer wrote:
Alexander Graf wrote:
Thanks to Michael Peter who tried the patch on an x86 host I found some
compilation problems.
This updated patch addresses these issues and thus should compile on
every platform for every target available.
[...]
Wow sorry about that, looks like I missed these.
Index: qemu-0.9.0.cvs/exec-all.h
===
--- qemu-0.9.0.cvs.orig/exec-all.h
+++ qemu-0.9.0.cvs/exec-all.h
@@ -166,6 +166,7 @@ static inline int tlb_set_page(CPUState
typedef struct TranslationBlock {
target_ulong pc; /* simulated PC corresponding to this block (EIP
+ CS base) */
target_ulong cs_base; /* CS base for this block */
+uint64_t intercept; /* SVM intercept vector */
unsigned int flags; /* flags defining in which context the code was
generated */
uint16_t size; /* size of target code for this block (1 =
size = TARGET_PAGE_SIZE) */
Index: qemu-0.9.0.cvs/cpu-all.h
===
--- qemu-0.9.0.cvs.orig/cpu-all.h
+++ qemu-0.9.0.cvs/cpu-all.h
@@ -715,6 +715,7 @@ extern int code_copy_enabled;
#define CPU_INTERRUPT_HALT 0x20 /* CPU halt wanted */
#define CPU_INTERRUPT_SMI0x40 /* (x86 only) SMI interrupt pending
*/
#define CPU_INTERRUPT_DEBUG 0x80 /* Debug event occured. */
+#define CPU_INTERRUPT_VIRQ 0x100 /* virtual interrupt pending. */
void cpu_interrupt(CPUState *s, int mask);
void cpu_reset_interrupt(CPUState *env, int mask);
Those two patches look ugly to me as target specific features should
never go in generic code or structures.
The CPU_INTERRUPT flags should just contain information about the
emulator behavior, thus CPU_INTERRUPT_TIMER, CPU_INTERRUPT_SMI are to be
removed. Target specific informations about the exception nature should
go in the CPUState structure... Then, adding a CPU_INTERRUPT_VIRQ seems
not a good idea at all: it's outside of the generic emulator scope and
pointless for most targets.
I don't see any practical reason not to do it this way. We could define
a CPU_INTERRUPT_TARGET interrupt, that stores the information in a the
target specific CPUState, but this would hit performance (marginally
though) and does not improve the situation. I don't think that we should
should forcefully try to seperate targets where we are not even close to
running out of constants. If everyone on this list sees the situation as
Jocelyn does, I would be fine with writing a patch that puts target
specific interrupts to the specific targets.
I was to do the same to add some functionality to the PowerPC target,
long time ago, and Fabrice Bellard convinced me not to do and agreed it
has been a bad idea to add the target specific CPU_INTERRUPT_xxx flags.
Then I did manage the PowerPC target to use only generic
CPU_INTERRUPT_xxx and put all other target specific informations in the
CPUState structure. It absolutelly changes nothing in terms of
functionality nor performance. The only thing is that it makes the
generic parts simpler and could even allow the cpu_exec function to
contain almost no target specific code, which would really great imho.
For the same reason, the intercept field in the TB structure seems not
acceptable, as TB specific target informations are already to be stored
in the flags field. As intercept seems only to be a bit field, it should
go, in a way or another, in tb flags. And as it seems that some
TB flags is a 32-bit bitfield, where several bits are already used.
Currently SVM supports 45 intercepts and each combination can generate a
different TB, as we do not want to reduce performance for the
non-intercepted case. Think of the intercept field as flags2, that could
be used by other virtualization implementations on other architectures
too (though I do not know of any)
So, why not make it generic and extend the flag field to as many bits as
you need ? Intercept is x86 specific and has no meaning outside of this
scope. Having more bits for flags is generic and may be useful for some
other targets... The easy way is to convert flag to 64 bits, if you have
enough bits. Another way is to make it a table, but this may need
changes in all targets code...
interceptions are related with functions implemented in helpers (not
micro-ops), you'd better check the interception in the helper at
runtime, which would add no visible overhead (as calling a helper is
slow compared to direct micro-ops execution), then you would not need to
store those infos in the TB structure. This may even make the emulation
This was the case in an earlier version of the patch. The
Re: [Qemu-devel] qemu Changelog Makefile Makefile.target TODO ae...
In message: [EMAIL PROTECTED] Johannes Schindelin [EMAIL PROTECTED] writes: : Hi, : : On Mon, 17 Sep 2007, J. Mayer wrote: : : On Sun, 2007-09-16 at 21:08 +, Thiemo Seufer wrote: : CVSROOT: /sources/qemu : Module name: qemu : Changes by: Thiemo Seufer ths 07/09/16 21:08:06 : : [lots of changes] : : Log message: : find -type f | xargs sed -i 's/[\t ]$//g' # on most files : : Many thanks for generating hundreds of conflicts with a useless commit. : : It is a whitespace fix, designed to remove tabs and spaces from ends of : lines, where they have no business of being. : : Yes, it is a style fix. But a fix nevertheless. : : And your conflicts are probably DUE TO AN INFERIOUR MERGE TOOL that _you_ : use. Time to join the modern world? In reality, it best to never commit trailing white space in the first place. It only causes pain and misery. This being one flavor of that. Warner
[Qemu-devel] qemu/hw usb-hid.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Andrzej Zaborowski balrog 07/09/17 17:27:00 Modified files: hw : usb-hid.c Log message: Pass correct pointer to HID keyboard event handler, fixes regression from IDLE mode introduction. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/hw/usb-hid.c?cvsroot=qemur1=1.13r2=1.14
Re: [Qemu-devel] qemu vnc.c
[sorry, resending.. didn't make it to xen-devel] On Thu, 2007-13-09 at 12:41 +, Thiemo Seufer wrote: CVSROOT: /sources/qemu Module name: qemu Changes by: Thiemo Seufer ths 07/09/13 12:41:43 Modified files: . : vnc.c Log message: Fix infinite loop in VNC support, by Marc Bevand. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/vnc.c?cvsroot=qemur1=1.21r2=1.22 Hmm dang, http://xenbits.xensource.com/xen-unstable.hg?file/a00cc97b392a/tools/ioemu/patches/vnc-protocol-fixes changeset: 11622:ca3abb3804f4 user:Steven Smith [EMAIL PROTECTED] date:Tue Sep 26 16:46:47 2006 +0100 summary: [HVM][VNC] Make sure that qemu doesn't go into an infinite loop when :( Are there any plans from the Xen community to submit some of the patches I see there upstream? Of course I'd do it myself but I'm not qualified nor familiar with vnc's operation, just hate to see work duplicated. -- Matthew Kent [EMAIL PROTECTED] http://magoazul.com
Re: [Qemu-devel] qemu Changelog Makefile Makefile.target TODO ae...
Am 17.09.2007 um 14:18 schrieb Christian MICHON: On 9/17/07, Philip Boulain [EMAIL PROTECTED] wrote: DON'T DO THIS KIND OF COMMIT AGAIN, PLEASE. if we were using git (but you can do it locally anyway), you would not have these conflicts problems... Maybe... but Savannah uses a CVS frontend, as far as I know... Those are excuses. So is a you should have used X argument. It doesn't invalidate the point that the commit was disruptive, and merely acts as bait for the grand old version repository flamewar.* since I mentionned you should have used Git, I'll repeat: this commit was not disruptive to any of the Git users, and will never be. Evolve, or prepare to be assimilated into the Collective... Both the qemu.org and the Savannah project page only mention CVS. If there are better ways to get the code then inform your users how to use that. Writing only of CVS and then telling people they should have used git instead is pure nonsense. Face reality; this is not some science-fiction movie. Andreas
Re: [Qemu-devel] qemu Changelog Makefile Makefile.target TODO ae...
On 9/17/07, Andreas Färber [EMAIL PROTECTED] wrote: Am 17.09.2007 um 14:18 schrieb Christian MICHON: On 9/17/07, Philip Boulain [EMAIL PROTECTED] wrote: DON'T DO THIS KIND OF COMMIT AGAIN, PLEASE. if we were using git (but you can do it locally anyway), you would not have these conflicts problems... Maybe... but Savannah uses a CVS frontend, as far as I know... Those are excuses. So is a you should have used X argument. It doesn't invalidate the point that the commit was disruptive, and merely acts as bait for the grand old version repository flamewar.* since I mentionned you should have used Git, I'll repeat: this commit was not disruptive to any of the Git users, and will never be. Evolve, or prepare to be assimilated into the Collective... Both the qemu.org and the Savannah project page only mention CVS. If there are better ways to get the code then inform your users how to use that. http://brick.kernel.dk/git/?p=qemu.git;a=summary It's tracking QEMU CVS; you're right that it's not mentioned anywhere on the site (AFAICS). You can also DIY with git-cvsimport; see e.g. http://chneukirchen.org/blog/archive/2006/04/tracking-the-ruby-cvs-with-git.html Luca
[Qemu-devel] RFC: linux user problems
It seems to me that there are many problems in linux-user/syscall.c
- minor fixes, just to avoid compilation warnings:
do_socketcall should be inside a #ifdef TARGET_NR_socketcall block
do_ipc should be inside a #ifdef TARGET_NR_ipc block
- problems for 64 bits targets:
it seems that do_syscall and child functions should take target_long /
target_ulong arguments instead of long / unsigned long. This would make
a chance for 64 bits targets to be ran on 32 bits hosts (even if, yes,
there would also be other problems to fix elsewhere...).
- ipc specific problems:
some structure used for IPC definitions have been merged. They used to
be target specific and now are generic. But it seems to me that many
mistakes have been done here, while comparing with the PowerPC 64 target
definition, which has not been merged:
struct target_ipc_perm {
int __key;
unsigned short uid;
unsigned short gid;
unsigned short cuid;
unsigned short cgid;
unsigned short mode;
unsigned short seq;
};
in PowerPC 64 becomes:
struct target_ipc_perm
{
target_long __key;
target_ulong uid;
target_ulong gid;
target_ulong cuid;
target_ulong cgid;
unsigned short int mode;
unsigned short int __pad1;
unsigned short int __seq;
unsigned short int __pad2;
target_ulong __unused1;
target_ulong __unused2;
};
in generic code.
Problems are, imho:
int is not the same size than target_long on 64 bits targets.
unsigned short is never the same size than target_ulong (am I wrong ?)
there should be a target_short definition: are we sure short on the host
is always the same size than target_short ?
I also don't understand the padding logic here (does the original
target_ipc_perm structure relies on alignments generated by the
compiler ?).
I found the same kind of problems for the target_msqid_ds and
target_msgbuf structure.
I may be wrong, but it seems to me that those problems are not PowerPC
64 specific and that there are some serious bugs to be fixed here. Can
someone confirm this or tell me what I missed ?
Regards.
--
J. Mayer [EMAIL PROTECTED]
Never organized
Re: [Qemu-devel] qemu Changelog Makefile Makefile.target TODO ae...
On Mon, 2007-09-17 at 23:14 +0200, Luca wrote: On 9/17/07, Andreas Färber [EMAIL PROTECTED] wrote: Am 17.09.2007 um 14:18 schrieb Christian MICHON: On 9/17/07, Philip Boulain [EMAIL PROTECTED] wrote: DON'T DO THIS KIND OF COMMIT AGAIN, PLEASE. if we were using git (but you can do it locally anyway), you would not have these conflicts problems... Maybe... but Savannah uses a CVS frontend, as far as I know... Those are excuses. So is a you should have used X argument. It doesn't invalidate the point that the commit was disruptive, and merely acts as bait for the grand old version repository flamewar.* since I mentionned you should have used Git, I'll repeat: this commit was not disruptive to any of the Git users, and will never be. Evolve, or prepare to be assimilated into the Collective... Both the qemu.org and the Savannah project page only mention CVS. If there are better ways to get the code then inform your users how to use that. http://brick.kernel.dk/git/?p=qemu.git;a=summary It's tracking QEMU CVS; you're right that it's not mentioned anywhere on the site (AFAICS). You can also DIY with git-cvsimport; see e.g. http://chneukirchen.org/blog/archive/2006/04/tracking-the-ruby-cvs-with-git.html Another point is CVS is an industry standard. It has many drawbacks but is prooven to do its job as specified in a very reliable way. For now, not such a thing for git, afaik. If it ever become the new industry standard, after having prooven its reliability and long term stability, then you may be able to expect everyone to use it. Did anyone has done a long term comparison of CVS and git running on two copies of the same production repository and have made sure that any extraction at any time of any data (ie, checkout in the present and any date in the past, diffs, ...) of the two gives exactly the same result ? Please show me such studies and I may reconsider my position... If not, you can always use it, closing your eyes and praying for everything to be OK... Regards. -- J. Mayer [EMAIL PROTECTED] Never organized
Re: [Qemu-devel] qemu Changelog Makefile Makefile.target TODO ae...
On 9/17/07, Andreas Färber [EMAIL PROTECTED] wrote: Evolve, or prepare to be assimilated into the Collective... Both the qemu.org and the Savannah project page only mention CVS. If there are better ways to get the code then inform your users how to use that. Writing only of CVS and then telling people they should have used git instead is pure nonsense. it's been more than a year since I turned my back to CVS. I do not recall writing only of CVS. What I said was: if we were using Git, we would not face these merge conflicts. You can point to git copies of the CVS qemu repository, or perform yourself the import. You can even push your modification into the CVS vault using Git. If this is not clear to you, see this link: http://www.youtube.com/watch?v=4XpnKHJAok8 Sticking with CVS is pure nonsense. Period. Face reality; this is not some science-fiction movie. You should face reality. Linux kernel, Xorg, KDE and soon Gnome made the move over to Git. It was a sci-fi joke, by the way: I put a smiley behind it. Einsverstanden ? ;-) -- Christian -- http://detaolb.sourceforge.net/, a linux distribution for Qemu with Git inside !
[Qemu-devel] qemu vl.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Andrzej Zaborowski balrog 07/09/17 21:25:21 Modified files: . : vl.c Log message: Prevent segfaulting when -clock is specified multiple times. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/vl.c?cvsroot=qemur1=1.341r2=1.342
Re: [Qemu-devel] RFC: linux user problems
On Monday 17 September 2007, J. Mayer wrote: It seems to me that there are many problems in linux-user/syscall.c - problems for 64 bits targets: it seems that do_syscall and child functions should take target_long / target_ulong arguments instead of long / unsigned long. This would make a chance for 64 bits targets to be ran on 32 bits hosts (even if, yes, there would also be other problems to fix elsewhere...). IIRC most of code predates target_long. I'm surprised 64-bit targets work at all. there should be a target_short definition: are we sure short on the host is always the same size than target_short ? Short is the same 16-bit type on every host or target we're even vaguely likely to care about. I can only think of one system (a weird and fairly obscure DSP) where this is not true. You'd definitely not be running linux, and almost certainly not be running qemu on it. Paul
Re: [Qemu-devel] RFC: linux user problems
On Mon, 2007-09-17 at 23:10 +0100, Paul Brook wrote: On Monday 17 September 2007, J. Mayer wrote: It seems to me that there are many problems in linux-user/syscall.c - problems for 64 bits targets: it seems that do_syscall and child functions should take target_long / target_ulong arguments instead of long / unsigned long. This would make a chance for 64 bits targets to be ran on 32 bits hosts (even if, yes, there would also be other problems to fix elsewhere...). IIRC most of code predates target_long. I'm surprised 64-bit targets work at all. Well, in fact I already did this (mostly alpha emulation). But running on a 64 bits host platform, which may explain I've been able to start running anything !... I'd like to make this more reliable in order to test some PowerPC 64 code without the need of the full MMU emulation (which is not complete and far from being debugged...) and any firmware. there should be a target_short definition: are we sure short on the host is always the same size than target_short ? Short is the same 16-bit type on every host or target we're even vaguely likely to care about. I can only think of one system (a weird and fairly obscure DSP) where this is not true. You'd definitely not be running linux, and almost certainly not be running qemu on it. OK, so there's no issue with this. But there always seem to be an issue confusing short with long or target_long... I go on checking the syscall.c code, converting long to target_long when it seems correct and preparing remarks and/or questions for all other cases. Regards. -- J. Mayer [EMAIL PROTECTED] Never organized
Re: [Qemu-devel] qemu Changelog Makefile Makefile.target TODO ae...
Hi, On Mon, 17 Sep 2007, Andreas F?rber wrote: Both the qemu.org and the Savannah project page only mention CVS. If there are better ways to get the code then inform your users how to use that. What about graphical diff tools? Should you _not_ use them, because CVS has an in-built diff? Frankly, if even the most proficient committer of QEmu admits to use quilt, which is definitely not CVS, you should rethink what you just wrote. Sticking to a tried and proven standard is one thing. Sticking to an ancient standard that has proven to have severe shortcomings (so much so that the ATM most popular central SCM, Subversion, claims it is CVS done right; that alone should tell you something), when there are better alternatives around, which moreover have no problems talking back to CVS, is, well, not so clever. Note that I do not say you should use git. Just as I do not say you have to stick with CVS. Ciao, Dscho
Re: [Qemu-devel] qemu Changelog Makefile Makefile.target TODO ae...
J. Mayer [EMAIL PROTECTED] wrote: On Mon, 2007-09-17 at 23:14 +0200, Luca wrote: On 9/17/07, Andreas Färber [EMAIL PROTECTED] wrote: Am 17.09.2007 um 14:18 schrieb Christian MICHON: On 9/17/07, Philip Boulain [EMAIL PROTECTED] wrote: DON'T DO THIS KIND OF COMMIT AGAIN, PLEASE. if we were using git (but you can do it locally anyway), you would not have these conflicts problems... Maybe... but Savannah uses a CVS frontend, as far as I know... Those are excuses. So is a you should have used X argument. It doesn't invalidate the point that the commit was disruptive, and merely acts as bait for the grand old version repository flamewar.* since I mentionned you should have used Git, I'll repeat: this commit was not disruptive to any of the Git users, and will never be. Evolve, or prepare to be assimilated into the Collective... Both the qemu.org and the Savannah project page only mention CVS. If there are better ways to get the code then inform your users how to use that. http://brick.kernel.dk/git/?p=qemu.git;a=summary It's tracking QEMU CVS; you're right that it's not mentioned anywhere on the site (AFAICS). You can also DIY with git-cvsimport; see e.g. http://chneukirchen.org/blog/archive/2006/04/tracking-the-ruby-cvs-with-git.html Another point is CVS is an industry standard. It has many drawbacks but is prooven to do its job as specified in a very reliable way. For now, not such a thing for git, afaik. If it ever become the new industry standard, after having prooven its reliability and long term stability, then you may be able to expect everyone to use it. Did anyone has done a long term comparison of CVS and git running on two copies of the same production repository and have made sure that any extraction at any time of any data (ie, checkout in the present and any date in the past, diffs, ...) of the two gives exactly the same result ? Please show me such studies and I may reconsider my position... If not, you can always use it, closing your eyes and praying for everything to be OK... The wine folks have been using it for a while, (maybe a year?), and they are prolithic committers. I see approximately 20-30 patches a day, monday-friday.
Re: [Qemu-devel] [PATCH] SVM support
Jocelyn Mayer wrote:
On Mon, 2007-09-17 at 12:02 +0200, Alexander Graf wrote:
J. Mayer wrote:
On Thu, 2007-09-13 at 17:27 +0200, Alexander Graf wrote:
Thiemo Seufer wrote:
Alexander Graf wrote:
Thanks to Michael Peter who tried the patch on an x86 host I found some
compilation problems.
This updated patch addresses these issues and thus should compile on
every platform for every target available.
[...]
Wow sorry about that, looks like I missed these.
Index: qemu-0.9.0.cvs/exec-all.h
===
--- qemu-0.9.0.cvs.orig/exec-all.h
+++ qemu-0.9.0.cvs/exec-all.h
@@ -166,6 +166,7 @@ static inline int tlb_set_page(CPUState
typedef struct TranslationBlock {
target_ulong pc; /* simulated PC corresponding to this block (EIP
+ CS base) */
target_ulong cs_base; /* CS base for this block */
+uint64_t intercept; /* SVM intercept vector */
unsigned int flags; /* flags defining in which context the code was
generated */
uint16_t size; /* size of target code for this block (1 =
size = TARGET_PAGE_SIZE) */
Index: qemu-0.9.0.cvs/cpu-all.h
===
--- qemu-0.9.0.cvs.orig/cpu-all.h
+++ qemu-0.9.0.cvs/cpu-all.h
@@ -715,6 +715,7 @@ extern int code_copy_enabled;
#define CPU_INTERRUPT_HALT 0x20 /* CPU halt wanted */
#define CPU_INTERRUPT_SMI0x40 /* (x86 only) SMI interrupt pending
*/
#define CPU_INTERRUPT_DEBUG 0x80 /* Debug event occured. */
+#define CPU_INTERRUPT_VIRQ 0x100 /* virtual interrupt pending. */
void cpu_interrupt(CPUState *s, int mask);
void cpu_reset_interrupt(CPUState *env, int mask);
Those two patches look ugly to me as target specific features should
never go in generic code or structures.
The CPU_INTERRUPT flags should just contain information about the
emulator behavior, thus CPU_INTERRUPT_TIMER, CPU_INTERRUPT_SMI are to be
removed. Target specific informations about the exception nature should
go in the CPUState structure... Then, adding a CPU_INTERRUPT_VIRQ seems
not a good idea at all: it's outside of the generic emulator scope and
pointless for most targets.
I don't see any practical reason not to do it this way. We could define
a CPU_INTERRUPT_TARGET interrupt, that stores the information in a the
target specific CPUState, but this would hit performance (marginally
though) and does not improve the situation. I don't think that we should
should forcefully try to seperate targets where we are not even close to
running out of constants. If everyone on this list sees the situation as
Jocelyn does, I would be fine with writing a patch that puts target
specific interrupts to the specific targets.
I was to do the same to add some functionality to the PowerPC target,
long time ago, and Fabrice Bellard convinced me not to do and agreed it
has been a bad idea to add the target specific CPU_INTERRUPT_xxx flags.
Then I did manage the PowerPC target to use only generic
CPU_INTERRUPT_xxx and put all other target specific informations in the
CPUState structure. It absolutelly changes nothing in terms of
functionality nor performance. The only thing is that it makes the
generic parts simpler and could even allow the cpu_exec function to
contain almost no target specific code, which would really great imho.
I can give that a try :-). Sounds reasonable for me.
For the same reason, the intercept field in the TB structure seems not
acceptable, as TB specific target informations are already to be stored
in the flags field. As intercept seems only to be a bit field, it should
go, in a way or another, in tb flags. And as it seems that some
TB flags is a 32-bit bitfield, where several bits are already used.
Currently SVM supports 45 intercepts and each combination can generate a
different TB, as we do not want to reduce performance for the
non-intercepted case. Think of the intercept field as flags2, that could
be used by other virtualization implementations on other architectures
too (though I do not know of any)
So, why not make it generic and extend the flag field to as many bits as
you need ? Intercept is x86 specific and has no meaning outside of this
scope. Having more bits for flags is generic and may be useful for some
other targets... The easy way is to convert flag to 64 bits, if you have
enough bits. Another way is to make it a table, but this may need
changes in all targets code...
I think it might be quite a bad idea to extend flags until everything
fits in there. I'm planning on implementing VMX as well and there are
intercepts too so the meaning of the different fields change and I would
not want that happening with the normal flags vector. What
Re: [Qemu-devel] [PATCH] SVM support
Alexander Graf wrote: Jocelyn Mayer wrote: I don't see any practical reason not to do it this way. We could define a CPU_INTERRUPT_TARGET interrupt, that stores the information in a the target specific CPUState, but this would hit performance (marginally though) and does not improve the situation. I don't think that we should should forcefully try to seperate targets where we are not even close to running out of constants. If everyone on this list sees the situation as Jocelyn does, I would be fine with writing a patch that puts target specific interrupts to the specific targets. I was to do the same to add some functionality to the PowerPC target, long time ago, and Fabrice Bellard convinced me not to do and agreed it has been a bad idea to add the target specific CPU_INTERRUPT_xxx flags. Then I did manage the PowerPC target to use only generic CPU_INTERRUPT_xxx and put all other target specific informations in the CPUState structure. It absolutelly changes nothing in terms of functionality nor performance. The only thing is that it makes the generic parts simpler and could even allow the cpu_exec function to contain almost no target specific code, which would really great imho. I can give that a try :-). Sounds reasonable for me. Oh well I just thought about this a bit more and while stumbling across CPU_INTERRUPT_FIQ which does the same thing one major problem came to me on that one: Priority. Real interrupts have priority over virtual interrupts so the VIRQs have to be processed after HARD IRQs, whereas SMIs and NMIs have to be taken care of before the HARD IRQs. It simply wouldn't work out to generalize the IRQs, just as it would not work with the VIRQ, as it has to be handled as a real IRQ but without accessing the APIC which has to be done for HARD IRQs. I guess we're stuck with what's there now. Greetings, Alex
[Qemu-devel] QEMU - I/O document
Hi guys, I'm studying Virtual Machines, and I would like to read something about QEMU... Does anybody know a paper(s) that shows how I/O works in qemu (I have interest in how qemu emulate network interface). Thanks in advance... Att. Artur Baruchi
[Qemu-devel] [help] When T0 is updated to last exectued TB
Hi,
I am a newcomer to QEMU. I am trying to understand the QEMU code. I am a little
bit confused about the following code about chaining TBs with direct jump
(cpu-exec.c, line 611, I edited it to remove #ifdef to make it clear to
discussion):
if (T0 != 0 tb-page_addr[1] == -1 ) {
spin_lock(tb_lock);
tb_add_jump((TranslationBlock *)(long)(T0 ~3), T0 3,
tb);
spin_unlock(tb_lock);
}
Say, if I am compile an i386-softmmu target on i386 host, T0 is %ebx. From the
code, T0 should contain the point to the last executed translation block. I
checked many code but couldn't find where T0 is updated to the last executed
block. Is there anyone willing to give me a hint? Thanks
Pangy
Boardwalk for $500? In 2007? Ha! Play Monopoly Here and Now (it's updated for
today's economy) at Yahoo! Games.
http://get.games.yahoo.com/proddesc?gamekey=monopolyherenow
Re: [Qemu-devel] QEMU - I/O document
Artur Baruchi schreef: Hi guys, I'm studying Virtual Machines, and I would like to read something about QEMU... Does anybody know a paper(s) that shows how I/O works in qemu (I have interest in how qemu emulate network interface). Thanks in advance... Att. Artur Baruchi Don't exactly know if this is the documentation you are looking for but you can find some technical documentation here: http://fabrice.bellard.free.fr/qemu/user-doc.html Under the header Technical Documentation :P Good luck :)
