We need to initialize legacy_address_space during ISA VGA setup so that
the chain-4 alias can be registered properly.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
This is based on the original fix by Hervé Poussineau: pc_memory_init
actually takes a memory region for mapping BIOS and extension ROMs. That
equals the PCI memory region if PCI is available, but must be system
memory in the ISA case.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
[Originally sent to qemu-kvm list, but I was redirected here]
The Capabilities Pointer is NULL, so this bit shouldn't be set. The state of
this bit doesn't appear to change any behavior on Linux/Windows versions we've
tested, but it does cause Windows' PCI/PCI Express Compliance Test to balk.
I happen to have a physical 82540EM controller, and it also sets the
Capabilities Bit, but it actually has items on the capabilities list to go
with it :)
Signed-off-by: dann frazier <dann.frazier@canonical.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Wire up the OMAP1 GPIO clock -- this fixes a hw_error() on startup
with OMAP1 based machines (sx1, cheetah).
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Convert the omap_intc devices to qdev. This includes adding
a 'revision' property which will be needed for omap3.
The bulk of this patch is the replacement of "s->irq[x][y]"
with "qdev_get_gpio_in(s->ih[x], y)" now that the interrupt
controller exposes its input lines as qdev gpio inputs.
The devices are named "omap-intc" and "omap2-intc", following
the filename and the OMAP2/3 hardware names, although some
internal functions are still named "omap_inth_*".
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Writing to IRQSTATUS should affect irqst, not irqen -- error
spotted by Andrzej Zaborowski.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Andrzej Zaborowski <andrew.zaborowski@intel.com>
Promote the remark about why we handle FIFOTHRESHOLDSTATUS the
way we do from the commit message of de8af7fe0 to a comment in
the code.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Andrzej Zaborowski <andrew.zaborowski@intel.com>
Add a new context flag PATHNAME_FSCONTEXT and indicate whether
the fs driver track fid using path names. Also add a private
pointer that help us to track fs driver specific values in there
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
This enables us to add handles to track fids later. The
V9fsPath added is similar to V9fsString except that the
size include the NULL byte also.
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
On rename we take the write lock and this ensure path
doesn't change as we operate on them.
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Implement an I/O space index-data register pair as defined by the AHCI
spec, including the corresponding SATA PCI capability and BAR.
This allows real-mode code to access the AHCI registers; real-mode
code cannot address the memory-mapped register space because it is
beyond the first megabyte.
Signed-off-by: Daniel Verkamp <daniel@drv.nu>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
It's a trivial wrapper for soc_dma_port_add_mem(), which makes
the memory API conversion more difficult because it takes a ram
addr_t. Drop.
Acked-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Avi Kivity <avi@redhat.com>
When assigning a 32-bit value to cmd->xfer (which is 64-bits)
it can be erroneously sign extended because the intermediate
32-bit computation is signed. Fix this by standardizing on
the ld*_be_p functions.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
I've found that FreeBSD AHCI driver doesn't work with AHCI hardware
emulation of QEMU 0.15.0. I believe the problem is on QEMU's side. As I
see, it clears port's Interrupt Enable register each time when reset of
any level happens. Is is reasonable for the global controller reset. It
is probably not good, but acceptable for FreeBSD driver for the port
hard reset. But it is IMO wrong for the device soft reset. None of real
hardware I know behaves that way.
Signed-off-by: Alexander Motin <mav@FreeBSD.org>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
It will not be needed for reads and writes if the HBA provides a sglist.
In addition, this lets scsi-disk refuse commands with an excessive
allocation length, as well as limit memory on usual well-behaved guests.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Also, consistently use qiov.size instead of iov.iov_len.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Support bridge filtering on top of the memory
API as suggested by Avi Kivity:
Create a memory region for the bridge's address space. This region is
not directly added to system_memory or its descendants. Devices under
the bridge see this region as its pci_address_space(). The region is
as large as the entire address space - it does not take into account
any windows.
For each of the three windows (pref, non-pref, vga), create an alias
with the appropriate start and size. Map the alias into the bridge's
parent's pci_address_space(), as subregions.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
The switch to the new memory API caused the following problem:
The pci device may call pci_register_bar() to use PCI bus's address
space. But we don't init PCI bus's address space if it is not bus
0. A crash was reported:
http://lists.gnu.org/archive/html/qemu-devel/2011-08/msg02243.html
More work will be needed to make bridge filtering work correctly
with the memory API.
Signed-off-by: Wen Congyang <wency@cn.fujitsu.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Fix up some erroneous comments in code:
interrupt pins are named A-D, the
interrupt pin register is always readonly
and isn't zeroed out on reset.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
eepro100 was the last user. Now pci_add_capability is powerful enough.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
I found no rationale for this in the logs, and it is quite bad because
it will make scsi-generic unsafe WRT power failures.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
