[Qemu-devel] [PATCH] SVM WBINVD intercept

2007-10-30 Thread Alexander Graf

Hi,

the WBINVD intercept was not triggered, as I accidently made it do an  
INVD intercept. This patch should fix it. I did not test-compile it  
though, so please check it first.


Thanks,

Alex

qemu.wbinvd.patch
Description: Binary data


[Qemu-devel] qemu for windows and sparc-Linux

2007-10-30 Thread ISHWAR RATTAN


Does the current version of qeumu-0.9.0+??
allow the serail port output of no-graphic
boot option to be visible in the qemu window as is
possible under Linux?

-ishwar





Re: [Qemu-devel] Faster, generic IO/DMA model with vectored AIO?

2007-10-30 Thread Blue Swirl
On 10/29/07, Blue Swirl [EMAIL PROTECTED] wrote:
 We could cache the resolved addresses to overcome the additional setup
 overhead. Each stage should install cache invalidation callbacks or a
 method to call for recalculation of the addresses. For example IOMMU
 or ESPDMA mappings change very often.

I meant to write don't change very often.

This version actually resolves the host memory address so that
scsi-disk could (with some additional plumbing) write directly to
final destination.

I think both pre- and postprocessing hooks may be needed, but those
are not implemented yet.

What about error handling? For example, first page is OK but second is
not. Truncate all further blocks and install a post-processing hook
that raises a bus error?

Example output:
esp
DMADriverAIOCB 0x27433f0
IO ranges:
base  len 0800
Prehooks:
Posthooks:
espdma
DMADriverAIOCB 0x27433f0
IO ranges:
base fe0a len 0800
Prehooks:
Posthooks:
iommu
DMADriverAIOCB 0x27433f0
IO ranges:
base 07fe100a len 0800
Prehooks:
Posthooks:
physical
DMADriverAIOCB 0x27433f0
IO ranges:
base 2b8e6f82200a len 0800
Prehooks:
Posthooks:
Index: qemu/vl.h
===
--- qemu.orig/vl.h	2007-10-29 16:59:37.0 +
+++ qemu/vl.h	2007-10-30 19:08:35.0 +
@@ -746,6 +746,109 @@
 
 #include hw/irq.h
 
+/* Generic DMA API */
+
+typedef void DMADriverCompletionFunc(void *opaque, int ret);
+
+typedef struct qemu_iolist {
+target_phys_addr_t iov_base;
+target_phys_addr_t iov_len;
+struct qemu_iolist *next;
+} qemu_iolist;
+
+typedef struct DMADriverAIOCB DMADriverAIOCB;
+
+typedef DMADriverAIOCB *
+DMATranslationHandler(void *opaque, DMADriverAIOCB *request, int is_write);
+
+typedef struct DMACompletionEntry {
+DMATranslationHandler *func;
+void *opaque;
+struct DMACompletionEntry *next;
+} DMACompletionEntry;
+
+struct DMADriverAIOCB {
+qemu_iolist *iolist;
+DMACompletionEntry *prehook;
+DMACompletionEntry *posthook;
+struct DMADriverAIOCB *next;
+};
+
+typedef struct qemu_bus {
+unsigned int bus_bits;
+DMATranslationHandler *north_handler;
+void *north_handler_opaque;
+DMATranslationHandler *south_handler;
+void *south_handler_opaque;
+} qemu_bus;
+
+static inline qemu_bus *
+bus_init(unsigned int bus_bits,
+ DMATranslationHandler north_handler,
+ void *north_handler_opaque,
+ DMATranslationHandler south_handler,
+ void *south_handler_opaque)
+{
+qemu_bus *bus;
+
+bus = qemu_mallocz(sizeof(qemu_bus));
+bus-bus_bits = bus_bits;
+bus-north_handler = north_handler;
+bus-north_handler_opaque = north_handler_opaque;
+bus-south_handler = south_handler;
+bus-south_handler_opaque = south_handler_opaque;
+return bus;
+}
+
+/* Direction CPU-bridge-device/memory */
+static inline DMADriverAIOCB *
+bus_translate_south(qemu_bus *bus, DMADriverAIOCB *request, int is_write)
+{
+return bus-south_handler(bus-south_handler_opaque, request, is_write);
+}
+
+/* From device towards CPU/memory (DMA) */
+static inline DMADriverAIOCB *
+bus_translate_north(qemu_bus *bus, DMADriverAIOCB *request, int is_write)
+{
+return bus-north_handler(bus-north_handler_opaque, request, is_write);
+}
+
+static inline DMADriverAIOCB *
+bus_build_aiocb(target_phys_addr_t addr, target_phys_addr_t len)
+{
+DMADriverAIOCB *d;
+
+d = qemu_mallocz(sizeof(DMADriverAIOCB));
+d-iolist = qemu_mallocz(sizeof(qemu_iolist));
+d-iolist-iov_base = addr;
+d-iolist-iov_len = len;
+return d;
+}
+
+#if 1 || DEBUG_GDMA
+static inline void
+bus_dump_aiocb(DMADriverAIOCB *d)
+{
+qemu_iolist *io;
+DMACompletionEntry *e;
+
+fprintf(stderr, DMADriverAIOCB %p\nIO ranges:\n, d);
+for (io = d-iolist; io != NULL; io = io-next) {
+fprintf(stderr, base  TARGET_FMT_plx  len  TARGET_FMT_plx \n,
+io-iov_base, io-iov_len);
+}
+fprintf(stderr, Prehooks:\n);
+for (e = d-prehook; e != NULL; e = e-next) {
+fprintf(stderr, func %p opaque %p\n, e-func, e-opaque);
+}
+fprintf(stderr, Posthooks:\n);
+for (e = d-posthook; e != NULL; e = e-next) {
+fprintf(stderr, func %p opaque %p\n, e-func, e-opaque);
+}
+}
+#endif
+
 /* ISA bus */
 
 extern target_phys_addr_t isa_mem_base;
@@ -1253,7 +1356,8 @@
 extern QEMUMachine ss5_machine, ss10_machine;
 
 /* iommu.c */
-void *iommu_init(target_phys_addr_t addr);
+void *iommu_init(target_phys_addr_t addr, qemu_bus *parent_bus,
+ qemu_bus **bus);
 void sparc_iommu_memory_rw(void *opaque, target_phys_addr_t addr,
  uint8_t *buf, int len, int is_write);
 static inline void sparc_iommu_memory_read(void *opaque,
@@ -1308,11 +1412,13 @@
 /* esp.c */
 void esp_scsi_attach(void *opaque, BlockDriverState *bd, int id);
 void *esp_init(BlockDriverState **bd, 

[Qemu-devel] qemu/linux-user syscall.c

2007-10-30 Thread Andrzej Zaborowski
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Andrzej Zaborowski balrog 07/10/30 21:06:14

Modified files:
linux-user : syscall.c 

Log message:
Do not make NETLINK socket connections possible (Alexander Graf).

CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/syscall.c?cvsroot=qemur1=1.141r2=1.142




[Qemu-devel] qemu console.c keymaps.c vl.h vnc.c vnc_keysym.h

2007-10-30 Thread Andrzej Zaborowski
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Andrzej Zaborowski balrog 07/10/30 22:38:53

Modified files:
.  : console.c keymaps.c vl.h vnc.c vnc_keysym.h 

Log message:
Miscellaneous VNC related fixes from Xen forwarded by Matthew Kent.

CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/console.c?cvsroot=qemur1=1.15r2=1.16
http://cvs.savannah.gnu.org/viewcvs/qemu/keymaps.c?cvsroot=qemur1=1.3r2=1.4
http://cvs.savannah.gnu.org/viewcvs/qemu/vl.h?cvsroot=qemur1=1.283r2=1.284
http://cvs.savannah.gnu.org/viewcvs/qemu/vnc.c?cvsroot=qemur1=1.25r2=1.26
http://cvs.savannah.gnu.org/viewcvs/qemu/vnc_keysym.h?cvsroot=qemur1=1.2r2=1.3




[Qemu-devel] qemu/slirp misc.c

2007-10-30 Thread Thiemo Seufer
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Thiemo Seufer ths 07/10/30 23:19:52

Modified files:
slirp  : misc.c 

Log message:
Declare function before use, reduces compiler warning noise.

CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/slirp/misc.c?cvsroot=qemur1=1.11r2=1.12




[Qemu-devel] qemu gdbstub.c

2007-10-30 Thread Andrzej Zaborowski
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Andrzej Zaborowski balrog 07/10/31 00:21:35

Modified files:
.  : gdbstub.c 

Log message:
x86_64 support in cpu_gdb_read_registers(), by Goran Weinholt.

CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/gdbstub.c?cvsroot=qemur1=1.68r2=1.69




Re: [Qemu-devel] [PATCH] Update i440FX/PIIX3 emulation

2007-10-30 Thread Michael Hanselmann
On Thu, Oct 25, 2007 at 12:42:22AM +0200, Michael Hanselmann wrote:
 The patch below updates the i440FX/PIIX3 emulation. It does:

I never got any reaction to that patch. Is it still awaiting review?

 This does not yet remove the workaround introduced by Igor Lvovsky's
 patch. However, I'm working on that since it, despite my earlier mail,
 seems to help with my ACPI shutdown problem.

So, I found the bug causing this behaviour. It turned out to be a
wrongly named variable in the ACPI DSDT from Bochs. See the patch for
Bochs below. I already sent it to the bochs-developers list[1].
qemu/pc-bios/bios.bin needs to be rebuilt from Bochs' code,
qemu/pc-bios/bios.diff and my patch.

The second patch below reverts the changes made by Igor Lvovsky. After
applying the patch to the BIOS, ACPI IRQs finally reach the system.

Finding this bug took me about the free time of four weeks. However, I
learned a lot about the internals of a PC. :-)

Thanks,
Michael

[1] 
http://sourceforge.net/mailarchive/forum.php?thread_name=20071031000835.GA20915%40hansmi.chforum_name=bochs-developers

---
Index: bios/acpi-dsdt.dsl
===
RCS file: /cvsroot/bochs/bochs/bios/acpi-dsdt.dsl,v
retrieving revision 1.1
diff -u -p -u -p -r1.1 acpi-dsdt.dsl
--- bios/acpi-dsdt.dsl  28 Sep 2006 18:56:20 -  1.1
+++ bios/acpi-dsdt.dsl  30 Oct 2007 23:52:22 -
@@ -369,7 +369,7 @@ DefinitionBlock (
 Method (_STA, 0, NotSerialized)
 {
 Store (0x0B, Local0)
-If (And (0x80, PRQ0, Local1))
+If (And (0x80, PRQ0, Local0))
 {
  Store (0x09, Local0)
 }
@@ -416,7 +416,7 @@ DefinitionBlock (
 Method (_STA, 0, NotSerialized)
 {
 Store (0x0B, Local0)
-If (And (0x80, PRQ1, Local1))
+If (And (0x80, PRQ1, Local0))
 {
  Store (0x09, Local0)
 }
@@ -463,7 +463,7 @@ DefinitionBlock (
 Method (_STA, 0, NotSerialized)
 {
 Store (0x0B, Local0)
-If (And (0x80, PRQ2, Local1))
+If (And (0x80, PRQ2, Local0))
 {
  Store (0x09, Local0)
 }
@@ -510,7 +510,7 @@ DefinitionBlock (
 Method (_STA, 0, NotSerialized)
 {
 Store (0x0B, Local0)
-If (And (0x80, PRQ3, Local1))
+If (And (0x80, PRQ3, Local0))
 {
  Store (0x09, Local0)
 }

---
diff --git a/hw/piix_pci.c b/hw/piix_pci.c
index 7c7d0f3..eabff8e 100644
--- a/hw/piix_pci.c
+++ b/hw/piix_pci.c
@@ -269,7 +269,6 @@ static void piix3_set_irq(qemu_irq *pic, int irq_num, int 
level)
 {
 int i, pic_irq, pic_level;
 
-piix3_dev-config[0x60 + irq_num] = ~0x80;
 pci_irq_levels[irq_num] = level;
 
 /* now we change the pic irq level according to the piix irq mappings */




[Qemu-devel] qemu usb-linux.c

2007-10-30 Thread Andrzej Zaborowski
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Andrzej Zaborowski balrog 07/10/31 00:27:50

Modified files:
.  : usb-linux.c 

Log message:
Use a O_NONBLOCK pipe for iso completion signals for thread-safety, by 
Arnon Gilboa.

CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/usb-linux.c?cvsroot=qemur1=1.14r2=1.15




[Qemu-devel] qemu/target-arm helper.c

2007-10-30 Thread Andrzej Zaborowski
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Andrzej Zaborowski balrog 07/10/31 00:47:13

Modified files:
target-arm : helper.c 

Log message:
Invalidate TLBs when domains are changed (Matthew Warton).
Legalise cp15 pid register writes (Matthew Warton).

CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/target-arm/helper.c?cvsroot=qemur1=1.23r2=1.24




[Qemu-devel] qemu qemu-img.c

2007-10-30 Thread Andrzej Zaborowski
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Andrzej Zaborowski balrog 07/10/31 01:11:44

Modified files:
.  : qemu-img.c 

Log message:
Support multipart images as input to qemu-img (Salvador Fandino).

CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/qemu-img.c?cvsroot=qemur1=1.22r2=1.23




[Qemu-devel] qemu configure

2007-10-30 Thread Andrzej Zaborowski
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Andrzej Zaborowski balrog 07/10/31 01:03:29

Modified files:
.  : configure 

Log message:
Add gcc-3.4.6 to the list of gcc3 versions (Carlo Marcelo Arenas Belon).
Add --disable-sdl to configure's help (Carlo Marcelo Arenas Belon).

CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/configure?cvsroot=qemur1=1.165r2=1.166




[Qemu-devel] qemu/hw usb-ohci.c

2007-10-30 Thread Andrzej Zaborowski
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Andrzej Zaborowski balrog 07/10/31 00:34:21

Modified files:
hw : usb-ohci.c 

Log message:
OHCI USB isochronous transfers support (Arnon Gilboa).

CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/hw/usb-ohci.c?cvsroot=qemur1=1.8r2=1.9




[Qemu-devel] qemu vnc.c

2007-10-30 Thread Andrzej Zaborowski
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Andrzej Zaborowski balrog 07/10/31 01:58:56

Modified files:
.  : vnc.c 

Log message:
Handle 3.7 VNC clients authentication correctly (Dan Kenigsberg).

CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/vnc.c?cvsroot=qemur1=1.26r2=1.27




Re: [Qemu-devel] [PATCH]bug fix for softmmu slow_st unaligned access

2007-10-30 Thread andrzej zaborowski
Hi,

On 28/10/2007, TeLeMan [EMAIL PROTECTED] wrote:
 For example, the memory address 0x10008000 is on an unwritable page.When the
 instruction add dword ptr [0x10007FFF],0x12345678 is executed,the OS will
 set 0x10008000 page be a writable page and re-execute this instruction. But
 softmmu has modifed the value of 0x10007FFF,so after re-executing this
 instruction, the final result is wrong(double-added on 0x10007FFF).
 Reversing the stored byte order can fix this bug.

I'm not sure I understand, but what happens if now the 10008000 page
is writable and 10007fff isn't, thus the OS needs to make it writable
and re-execute? I guess reversing the accesses order is not a
solution?

Regards,
Andrew




[Qemu-devel] qemu vl.c vl.h hw/an5206.c hw/etraxfs.c hw/inte...

2007-10-30 Thread Andrzej Zaborowski
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Andrzej Zaborowski balrog 07/10/31 01:54:05

Modified files:
.  : vl.c vl.h 
hw : an5206.c etraxfs.c integratorcp.c mcf5208.c 
 mips_malta.c mips_mipssim.c mips_pica61.c 
 mips_r4k.c palm.c pc.c ppc405_boards.c 
 ppc_chrp.c ppc_oldworld.c ppc_prep.c r2d.c 
 realview.c shix.c spitz.c sun4m.c sun4u.c 
 versatilepb.c 

Log message:
Set boot sequence from command line (Dan Kenigsberg).

CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/vl.c?cvsroot=qemur1=1.352r2=1.353
http://cvs.savannah.gnu.org/viewcvs/qemu/vl.h?cvsroot=qemur1=1.284r2=1.285
http://cvs.savannah.gnu.org/viewcvs/qemu/hw/an5206.c?cvsroot=qemur1=1.3r2=1.4
http://cvs.savannah.gnu.org/viewcvs/qemu/hw/etraxfs.c?cvsroot=qemur1=1.1r2=1.2
http://cvs.savannah.gnu.org/viewcvs/qemu/hw/integratorcp.c?cvsroot=qemur1=1.20r2=1.21
http://cvs.savannah.gnu.org/viewcvs/qemu/hw/mcf5208.c?cvsroot=qemur1=1.4r2=1.5
http://cvs.savannah.gnu.org/viewcvs/qemu/hw/mips_malta.c?cvsroot=qemur1=1.45r2=1.46
http://cvs.savannah.gnu.org/viewcvs/qemu/hw/mips_mipssim.c?cvsroot=qemur1=1.2r2=1.3
http://cvs.savannah.gnu.org/viewcvs/qemu/hw/mips_pica61.c?cvsroot=qemur1=1.9r2=1.10
http://cvs.savannah.gnu.org/viewcvs/qemu/hw/mips_r4k.c?cvsroot=qemur1=1.49r2=1.50
http://cvs.savannah.gnu.org/viewcvs/qemu/hw/palm.c?cvsroot=qemur1=1.7r2=1.8
http://cvs.savannah.gnu.org/viewcvs/qemu/hw/pc.c?cvsroot=qemur1=1.87r2=1.88
http://cvs.savannah.gnu.org/viewcvs/qemu/hw/ppc405_boards.c?cvsroot=qemur1=1.7r2=1.8
http://cvs.savannah.gnu.org/viewcvs/qemu/hw/ppc_chrp.c?cvsroot=qemur1=1.46r2=1.47
http://cvs.savannah.gnu.org/viewcvs/qemu/hw/ppc_oldworld.c?cvsroot=qemur1=1.2r2=1.3
http://cvs.savannah.gnu.org/viewcvs/qemu/hw/ppc_prep.c?cvsroot=qemur1=1.50r2=1.51
http://cvs.savannah.gnu.org/viewcvs/qemu/hw/r2d.c?cvsroot=qemur1=1.2r2=1.3
http://cvs.savannah.gnu.org/viewcvs/qemu/hw/realview.c?cvsroot=qemur1=1.11r2=1.12
http://cvs.savannah.gnu.org/viewcvs/qemu/hw/shix.c?cvsroot=qemur1=1.5r2=1.6
http://cvs.savannah.gnu.org/viewcvs/qemu/hw/spitz.c?cvsroot=qemur1=1.12r2=1.13
http://cvs.savannah.gnu.org/viewcvs/qemu/hw/sun4m.c?cvsroot=qemur1=1.56r2=1.57
http://cvs.savannah.gnu.org/viewcvs/qemu/hw/sun4u.c?cvsroot=qemur1=1.23r2=1.24
http://cvs.savannah.gnu.org/viewcvs/qemu/hw/versatilepb.c?cvsroot=qemur1=1.17r2=1.18




Re: [Qemu-devel] qemu vl.c vl.h hw/an5206.c hw/etraxfs.c hw/inte...

2007-10-30 Thread J. Mayer

On Wed, 2007-10-31 at 01:54 +, Andrzej Zaborowski wrote:
 CVSROOT:  /sources/qemu
 Module name:  qemu
 Changes by:   Andrzej Zaborowski balrog 07/10/31 01:54:05
 
 Modified files:
   .  : vl.c vl.h 
   hw : an5206.c etraxfs.c integratorcp.c mcf5208.c 
mips_malta.c mips_mipssim.c mips_pica61.c 
mips_r4k.c palm.c pc.c ppc405_boards.c 
ppc_chrp.c ppc_oldworld.c ppc_prep.c r2d.c 
realview.c shix.c spitz.c sun4m.c sun4u.c 
versatilepb.c 
 
 Log message:
   Set boot sequence from command line (Dan Kenigsberg).

There have been remarks about this patch that have not been addressed
(not even answered, in fact).  For example, the MAX_BOOT_DEVICES is set
to 3 when more than 3 boot devices are possible to select (see the
BOOTCHARS definition), which clearly shows the patch is not consistent.
Furthermore, the patch breaks the coding style in some files (at least
the ones I checked), which is weird.
Seems _very_ strange to see it commited, then.

-- 
J. Mayer [EMAIL PROTECTED]
Never organized





Re: [Qemu-devel] qemu vl.c vl.h hw/an5206.c hw/etraxfs.c hw/inte...

2007-10-30 Thread andrzej zaborowski
Hi,

On 31/10/2007, J. Mayer [EMAIL PROTECTED] wrote:

 On Wed, 2007-10-31 at 01:54 +, Andrzej Zaborowski wrote:
  CVSROOT:  /sources/qemu
  Module name:  qemu
  Changes by:   Andrzej Zaborowski balrog 07/10/31 01:54:05
 
  Modified files:
.  : vl.c vl.h
hw : an5206.c etraxfs.c integratorcp.c mcf5208.c
 mips_malta.c mips_mipssim.c mips_pica61.c
 mips_r4k.c palm.c pc.c ppc405_boards.c
 ppc_chrp.c ppc_oldworld.c ppc_prep.c r2d.c
 realview.c shix.c spitz.c sun4m.c sun4u.c
 versatilepb.c
 
  Log message:
Set boot sequence from command line (Dan Kenigsberg).

 There have been remarks about this patch that have not been addressed
 (not even answered, in fact).  For example, the MAX_BOOT_DEVICES is set
 to 3 when more than 3 boot devices are possible to select (see the
 BOOTCHARS definition), which clearly shows the patch is not consistent.

I double-checked to make sure all remarks made on qemu-devel were
addressed, but I may have missed something. It was explained that the
default bios supports only three boot devices, on a second thought I
see how this may affect people using a non-default bios, but I guess 3
boot devices is better than only one that was possible without this
patch.

Feel free to revert if you see any issues.

 Furthermore, the patch breaks the coding style in some files (at least
 the ones I checked), which is weird.

I also tried to make sure that the original style in every file was
retained (i.e. I wrapped lines crossing 80 chars), but again I may
have missed something.

Regards




Re: [Qemu-devel] PreP kernels boot using Qemu

2007-10-30 Thread Ed Swierk
On 10/28/07, Rob Landley [EMAIL PROTECTED] wrote:
 Hmmm...  All the kernels I've built for this project are static.  In theory I
 can add ne.irq=9 to the kernel command line, but in practice it doesn't
 seem to work.  Nor does ne.0.irq=9 or irq=9

 However, when I hardwire dev-irq=9; into the source code, it does seem to
 work.  (Or at least I can ping qemu's virtual gateway.)

 Off to read the kernel command line parsing logic...

It seems that the driver.parameter syntax works only for parameters
that the driver exports in /sys/module/driver/parameters. The ne
driver doesn't define parameters at all when not compiled as a module,
let alone export them via sysfs.

The attached patch is my feeble attempt to remedy the situation. With
the patch, adding ne.irq=9,10 to the kernel command line sets the
correct irqs for eth0 and eth1.

--Ed


linux-2.6.23-ne-module-params.patch
Description: Binary data


Re: [Qemu-devel] [PATCH]bug fix for softmmu slow_st unaligned access

2007-10-30 Thread TeLeMan



andrzej zaborowski wrote:
 
 Hi,
 
 On 28/10/2007, TeLeMan [EMAIL PROTECTED] wrote:
 For example, the memory address 0x10008000 is on an unwritable page.When
 the
 instruction add dword ptr [0x10007FFF],0x12345678 is executed,the OS
 will
 set 0x10008000 page be a writable page and re-execute this instruction.
 But
 softmmu has modifed the value of 0x10007FFF,so after re-executing this
 instruction, the final result is wrong(double-added on 0x10007FFF).
 Reversing the stored byte order can fix this bug.
 
 I'm not sure I understand, but what happens if now the 10008000 page
 is writable and 10007fff isn't, thus the OS needs to make it writable
 and re-execute? I guess reversing the accesses order is not a
 solution?
 
 Regards,
 Andrew
 
 

If the 0x10008000 page is writable and 0x10007FFF isn't, softmmu can raise
this exception before modifing 0x10007FFF-0x10008002 because softmmu checks
0x10007FFF at first. I don't know if reversing the order is an exact
solution,but its simple and working.

btw, I found this bug because I found the some windows dll reloc offset are
calculated incorrectly by the guest OS. If you need a sample, I can give it
to you.
-- 
View this message in context: 
http://www.nabble.com/-PATCH-bug-fix-for-softmmu-slow_st-unaligned-access-tf4705397.html#a13502111
Sent from the QEMU - Dev mailing list archive at Nabble.com.





Re: [Qemu-devel] qemu vl.c vl.h hw/an5206.c hw/etraxfs.c hw/inte...

2007-10-30 Thread J. Mayer

On Wed, 2007-10-31 at 03:35 +0100, andrzej zaborowski wrote:
 Hi,
 
 On 31/10/2007, J. Mayer [EMAIL PROTECTED] wrote:
 
  On Wed, 2007-10-31 at 01:54 +, Andrzej Zaborowski wrote:
   CVSROOT:  /sources/qemu
   Module name:  qemu
   Changes by:   Andrzej Zaborowski balrog 07/10/31 01:54:05
  
   Modified files:
 .  : vl.c vl.h
 hw : an5206.c etraxfs.c integratorcp.c mcf5208.c
  mips_malta.c mips_mipssim.c mips_pica61.c
  mips_r4k.c palm.c pc.c ppc405_boards.c
  ppc_chrp.c ppc_oldworld.c ppc_prep.c r2d.c
  realview.c shix.c spitz.c sun4m.c sun4u.c
  versatilepb.c
  
   Log message:
 Set boot sequence from command line (Dan Kenigsberg).
 
  There have been remarks about this patch that have not been addressed
  (not even answered, in fact).  For example, the MAX_BOOT_DEVICES is set
  to 3 when more than 3 boot devices are possible to select (see the
  BOOTCHARS definition), which clearly shows the patch is not consistent.
 
 I double-checked to make sure all remarks made on qemu-devel were
 addressed, but I may have missed something. It was explained that the
 default bios supports only three boot devices,

Then just take a look at the function boot_device2nibble in hw/pc.c. You
can see 4 possibilities implemented here. And I think I've never seen a
PC BIOS (on real machines, I mean) that don't allow more than 4 choices
in last 5 years (and maybe much more...)
The second point is that, as the legacy PC-BIOS is maybe the less
versatile architecture that can be, putting limitations to the emulation
model based on this spec seems to be a nonsense in Qemu, which is
supposed to emulate _a lot_ of different architectures. As a matter of
fact, a specific implementation (ie legacy PC target) should not lead to
have hardcoded limits that would affect all other emulated targets.

  on a second thought I
 see how this may affect people using a non-default bios, but I guess 3
 boot devices is better than only one that was possible without this
 patch.

For most emulation targets, there still is a limit to 1. And the global
limit to 3 is not even related to the PC spec, according to the code
commited in pc.c. Then, imho, it cannot be better as it's inconsistent
for the PC case and provides nothing in most cases.
What is the explanation of a global define to 1 for most target when you
cannot globally know how the information will be exploited ? It would
seem really more logical to allow the user to give all defined possible
boot devices to the -boot parameter, then it's up to the target
initialisation code or the BIOS (some target may use different BIOS with
different ABIs for different usages...) to determine if the information
can be used totally, partially or not at all. Let me give an example:
what is the meaning of the -boot parameter for embedded board that can
only boot from a flash device (see the ppc405_boards.c, for
example...) ? My answer is that the user can always give the -boot
parameter but it will just be ignored by the target specific code. And
the number of boot devices that may be usefull for a target is target or
BIOS dependant. It's not in any way CPU architecture dependant, then the
MAX_BOOT_DEVICES as it is implemented is false for the legacy PC
architecture and has no meaning for all other cases.

 Feel free to revert if you see any issues.

I don't think it breaks anything, then now that it's commited, it seems
more urgent to see the patch reworked to make it consistent and really
usable in all cases (PC is not the only Qemu target !) than to revert
and generate CVS noise...

  Furthermore, the patch breaks the coding style in some files (at least
  the ones I checked), which is weird.
 
 I also tried to make sure that the original style in every file was
 retained (i.e. I wrapped lines crossing 80 chars)

Apparently, not totally. (including 80 chars wrapping lines).

-- 
J. Mayer [EMAIL PROTECTED]
Never organized