Re: [Qemu-devel] qemu vl.c vl.h hw/an5206.c hw/etraxfs.c hw/inte...
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 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
Re: [Qemu-devel] [PATCH]bug fix for softmmu slow_st unaligned access
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...
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 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
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] qemu vl.c vl.h hw/an5206.c hw/etraxfs.c hw/inte...
On Wed, 2007-10-31 at 01:54 +, Andrzej Zaborowski wrote: > CVSROOT: /sources/qemu > Module name: qemu > Changes by: Andrzej Zaborowski 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] [PATCH]bug fix for softmmu slow_st unaligned access
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/target-i386 translate.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Andrzej Zaborowski 07/10/31 02:01:33 Modified files: target-i386: translate.c Log message: Correct the WBINVD intercept in SVM (Alexander Graf). CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/target-i386/translate.c?cvsroot=qemu&r1=1.72&r2=1.73
[Qemu-devel] qemu vnc.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Andrzej Zaborowski 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=qemu&r1=1.26&r2=1.27
[Qemu-devel] qemu vl.c vl.h hw/an5206.c hw/etraxfs.c hw/inte...
CVSROOT:/sources/qemu Module name:qemu Changes by: Andrzej Zaborowski 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=qemu&r1=1.352&r2=1.353 http://cvs.savannah.gnu.org/viewcvs/qemu/vl.h?cvsroot=qemu&r1=1.284&r2=1.285 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/an5206.c?cvsroot=qemu&r1=1.3&r2=1.4 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/etraxfs.c?cvsroot=qemu&r1=1.1&r2=1.2 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/integratorcp.c?cvsroot=qemu&r1=1.20&r2=1.21 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/mcf5208.c?cvsroot=qemu&r1=1.4&r2=1.5 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/mips_malta.c?cvsroot=qemu&r1=1.45&r2=1.46 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/mips_mipssim.c?cvsroot=qemu&r1=1.2&r2=1.3 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/mips_pica61.c?cvsroot=qemu&r1=1.9&r2=1.10 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/mips_r4k.c?cvsroot=qemu&r1=1.49&r2=1.50 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/palm.c?cvsroot=qemu&r1=1.7&r2=1.8 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/pc.c?cvsroot=qemu&r1=1.87&r2=1.88 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/ppc405_boards.c?cvsroot=qemu&r1=1.7&r2=1.8 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/ppc_chrp.c?cvsroot=qemu&r1=1.46&r2=1.47 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/ppc_oldworld.c?cvsroot=qemu&r1=1.2&r2=1.3 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/ppc_prep.c?cvsroot=qemu&r1=1.50&r2=1.51 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/r2d.c?cvsroot=qemu&r1=1.2&r2=1.3 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/realview.c?cvsroot=qemu&r1=1.11&r2=1.12 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/shix.c?cvsroot=qemu&r1=1.5&r2=1.6 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/spitz.c?cvsroot=qemu&r1=1.12&r2=1.13 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/sun4m.c?cvsroot=qemu&r1=1.56&r2=1.57 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/sun4u.c?cvsroot=qemu&r1=1.23&r2=1.24 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/versatilepb.c?cvsroot=qemu&r1=1.17&r2=1.18
[Qemu-devel] qemu qemu-img.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Andrzej Zaborowski 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=qemu&r1=1.22&r2=1.23
[Qemu-devel] qemu/hw usb-ohci.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Andrzej Zaborowski 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=qemu&r1=1.8&r2=1.9
[Qemu-devel] qemu configure
CVSROOT:/sources/qemu Module name:qemu Changes by: Andrzej Zaborowski 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=qemu&r1=1.165&r2=1.166
Re: [Qemu-devel] [PATCH] Arm MMU Fixes
Hi, On 15/10/2007, Matthew Warton <[EMAIL PROTECTED]> wrote: > The first is that Qemu would not enable changing of the pid register > on processors with an MMU. This is a legal operation, and one that > several parts of our kernel rely on. See (for example) the ARM920t > technical reference manual to verify that this register is available > on ARM processors with an MMU. I committed the change, but I'm wondering if it was originally a typo and the operation should instead be illegal on processors with an MPU (note that MPU != MMU), i.e. a spurious "!". Can somebody check this? Thanks, Andrew
[Qemu-devel] qemu/target-arm helper.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Andrzej Zaborowski 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=qemu&r1=1.23&r2=1.24
[Qemu-devel] qemu usb-linux.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Andrzej Zaborowski 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=qemu&r1=1.14&r2=1.15
Re: [Qemu-devel] [PATCH] Update i440FX/PIIX3 emulation
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.ch&forum_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 gdbstub.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Andrzej Zaborowski 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=qemu&r1=1.68&r2=1.69
[Qemu-devel] qemu/slirp misc.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer 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=qemu&r1=1.11&r2=1.12
[Qemu-devel] qemu console.c keymaps.c vl.h vnc.c vnc_keysym.h
CVSROOT:/sources/qemu Module name:qemu Changes by: Andrzej Zaborowski 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=qemu&r1=1.15&r2=1.16 http://cvs.savannah.gnu.org/viewcvs/qemu/keymaps.c?cvsroot=qemu&r1=1.3&r2=1.4 http://cvs.savannah.gnu.org/viewcvs/qemu/vl.h?cvsroot=qemu&r1=1.283&r2=1.284 http://cvs.savannah.gnu.org/viewcvs/qemu/vnc.c?cvsroot=qemu&r1=1.25&r2=1.26 http://cvs.savannah.gnu.org/viewcvs/qemu/vnc_keysym.h?cvsroot=qemu&r1=1.2&r2=1.3
[Qemu-devel] qemu/linux-user syscall.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Andrzej Zaborowski 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=qemu&r1=1.141&r2=1.142
Re: [Qemu-devel] Faster, generic IO/DMA model with vectored AIO?
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);
[Qemu-devel] qemu for windows and sparc-Linux
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
[Qemu-devel] [PATCH] SVM WBINVD intercept
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
