Since CPU loops are done as last step in kvm_{insert,remove}_breakpoint()
and kvm_remove_all_breakpoints(), we do not need to distinguish between
invoking CPU and iterated CPUs and can thereby free the identifier for
use as a global variable.
Acked-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Andreas Färber <afaerber@suse.de>
This includes some pci enhancements:
Better support for systems with multiple PCI root buses
FW cfg interface for more robust pci programming in BIOS
Minor fixes/cleanups for fw cfg and cross-version migration -
because of dependencies with other patches
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (GNU/Linux)
iQEcBAABAgAGBQJR2ctmAAoJECgfDbjSjVRpQpAH/Rk00yLrQ2R5ScNa8AL9LeaJ
gVFndBmmuRz4gdhyATx6lzR98ic32iTr0+YR5mL51btgmM5a0bEd/SIu34nXriWj
PsM0wdXfo/oEygdttxhvzJOH17tohRV9xg2WA2d8BEwDzrDyqoQ4J0VJlHlG7u3W
nq4KVDVUpLNQFKG8ZgJ2vW0WMw/mBSj2rluhQUALhcuvChphtvAFZ2rsSfJr6bzD
aBELrtIvfLvPGN/0WVeYs9qlp4EE03H3X6gN61QvV3/YElxubKUV5XyMDOX2dW3D
2j0NQi84LYHn0SFap2r/Kgm47/F6Q56SFk5lrgZrg60mhQTwocw7PfL8CGxjXRI=
=gxxc
-----END PGP SIGNATURE-----
Merge remote-tracking branch 'mst/tags/for_anthony' into staging
pci,misc enhancements
This includes some pci enhancements:
Better support for systems with multiple PCI root buses
FW cfg interface for more robust pci programming in BIOS
Minor fixes/cleanups for fw cfg and cross-version migration -
because of dependencies with other patches
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
# gpg: Signature made Sun 07 Jul 2013 03:11:18 PM CDT using RSA key ID D28D5469
# gpg: Can't check signature: public key not found
# By David Gibson (10) and others
# Via Michael S. Tsirkin
* mst/tags/for_anthony:
pci: Fold host_buses list into PCIHostState functionality
pci: Remove domain from PCIHostBus
pci: Simpler implementation of primary PCI bus
pci: Add root bus parameter to pci_nic_init()
pci: Add root bus argument to pci_get_bus_devfn()
pci: Replace pci_find_domain() with more general pci_root_bus_path()
pci: Use helper to find device's root bus in pci_find_domain()
pci: Abolish pci_find_root_bus()
pci: Move pci_read_devaddr to pci-hotplug-old.c
pci: Cleanup configuration for pci-hotplug.c
pvpanic: fix fwcfg for big endian hosts
pvpanic: initialization cleanup
MAINTAINERS: s/Marcelo/Paolo/
e1000: cleanup process_tx_desc
pc_piix: cleanup init compat handling
pc: pass PCI hole ranges to Guests
pci: store PCI hole ranges in guestinfo structure
range: add Range structure
Message-id: 1373228271-31223-1-git-send-email-mst@redhat.com
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
The host_buses list is an odd structure - a list of pointers to PCI root
buses existing in parallel to the normal qdev tree structure. This patch
removes it, instead putting the link pointers into the PCIHostState
structure, which have a 1:1 relationship to PCIHostBus structures anyway.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
At present, pci_nic_init() and pci_nic_init_nofail() assume that they will
only create a NIC under the primary PCI root. As we add support for
multiple PCI roots, that may no longer be the case. This patch adds a root
bus parameter to pci_nic_init() (and updates callers accordingly) to allow
the machine init code using it to specify the right PCI root for NICs
created by old-style -net nic parameters. NICs created new-style, with
-device can of course be put anywhere.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
pci_get_bus_devfn() interprets a full PCI address string to give a PCIBus *
and device/function number within that bus. Currently it assumes it is
working on an address under the primary PCI root bus. This patch extends
it to allow the caller to specify a root bus. This might seem a little odd
since the supplied address can (theoretically) include a PCI domain number.
However, attempting to use a non-zero domain number there is currently an
error, so that shouldn't really cause problems.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
pci_find_domain() is used in a number of places where we want an id for a
whole PCI domain (i.e. the subtree under a PCI root bus). The trouble is
that many platforms may support multiple independent host bridges with no
hardware supplied notion of domain number.
This patch, therefore, replaces calls to pci_find_domain() with calls to
a new pci_root_bus_path() returning a string. The new call is implemented
in terms of a new callback in the host bridge class, so it can be defined
in some way that's well defined for the platform. When no callback is
available we fall back on the qbus name.
Most current uses of pci_find_domain() are for error or informational
messages, so the change in identifiers should be harmless. The exception
is pci_get_dev_path(), whose results form part of migration streams. To
maintain compatibility with old migration streams, the PIIX PCI host is
altered to always supply "0000" for this path, which matches the old domain
number (since the code didn't actually support domains other than 0).
For the pseries (spapr) PCI bridge we use a different platform-unique
identifier (pseries machines can routinely have dozens of PCI host
bridges). Theoretically that breaks migration streams, but given that we
don't yet have migration support for pseries, it doesn't matter.
Any other machines that have working migration support including PCI
devices will need to be updated to maintain migration stream compatibility.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Currently pci_find_domain() performs two functions - it locates the PCI
root bus above the given bus, then looks up that root bus's domain number.
This patch adds a helper function to perform the first task, finding the
root bus for a given PCI device. This is then used in pci_find_domain().
This changes pci_find_domain()'s signature slightly, taking a PCIDevice
instead of a PCIBus - since all callers passed something of the form
dev->bus, this simplifies things slightly.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
pci_find_root_bus() takes a domain parameter. Currently PCI root buses
with domain other than 0 can't be created, so this is more or less a long
winded way of retrieving the main PCI root bus. Numbered domains don't
actually properly cover the (non x86) possibilities for multiple PCI root
buses, so this patch for now enforces the domain == 0 restriction in other
places to replace pci_find_root_bus() with an explicit
pci_find_primary_bus().
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
This same treatment previously done to phys_node_map and phys_sections
is now applied to the dispatch field of AddressSpace. Topology updates
use as->next_dispatch while accesses use as->dispatch.
Reviewed-by: Jan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
This will help having two copies of AddressSpaceDispatch during the
recreation of the radix tree (one being built, and one that is complete
and will be protected by RCU). We do not want to have to unregister and
re-register the listener.
Reviewed-by: Jan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
We're already using them in several places, but __sync builtins are just
too ugly to type, and do not provide seqcst load/store operations.
Reviewed-by: Richard Henderson <rth@twiddle.net>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
After the next patch it would not be used elsewhere anyway. Also,
the _nofail and the standard versions of this function return different
things, which is confusing. Removing the function from the public headers
limits the confusion.
Reviewed-by: Jan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Add ref/unref calls at the following places:
- places where memory regions are stashed by a listener and
used outside the BQL (including in Xen or KVM).
- memory_region_find callsites
- creation of aliases and containers (only the aliased/contained
region gets a reference to avoid loops)
- around calls to del_subregion/add_subregion, where the region
could disappear after the first call
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
This new API will avoid having too many memory_region_ref/unref
in paths that currently use memory_region_find.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Whenever memory regions are accessed outside the BQL, they need to be
preserved against hot-unplug. MemoryRegions actually do not have their
own reference count; they piggyback on a QOM object, their "owner".
The owner is set at creation time, and there is a function to retrieve
the owner.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
This decouples memory.h from ioport.h, concentrating all portio related
types in a single header.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
In case the latter may vanish one day, make sure the vmport read handler
type will remain unaffected. This is also conceptually cleaner.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Remove unused ioport_register and isa_unassign_ioport along with
everything that only those services used.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
The current ioport dispatcher is a complex beast, mostly due to the
need to deal with old portio interface users. But we can overcome it
without converting all portio users by embedding the required base
address of a MemoryRegionPortio access into that data structure. That
removes the need to have the additional MemoryRegionIORange structure
in the loop on every access.
To handle old portio memory ops, we simply install dispatching handlers
for portio memory regions when registering them with the memory core.
This removes the need for the old_portio field.
We can drop the additional aliasing of ioport regions and also the
special address space listener. cpu_in and cpu_out now simply call
address_space_read/write. And we can concentrate portio handling in a
single source file.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Open-code isa_is_ioport_assigned via a memory region lookup. As all IO
ports are now directly or indirectly registered via the memory API, this
becomes possible and will finally allow us to drop the ioport tables.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
pci_read_devaddr() is only used by the legacy functions for the old PCI
hotplug interface in pci-hotplug-old.c. So we move the function there,
and make it static.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Avoid use of static variables: PC systems
initialize pvpanic device through pvpanic_init,
so we can simply create the fw_cfg file at that point.
This also makes it possible to skip device
creation completely if fw_cfg is not there, e.g. for xen -
so the ports it reserves are not discoverable by guests.
Also, make pvpanic_init void since callers ignore return
status anyway.
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Paul Durrant <Paul.Durrant@citrix.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Guest currently has to jump through lots of hoops to guess the PCI hole
ranges. It's fragile, and makes us change BIOS each time we add a new
chipset. Let's report the window in a ROM file, to make BIOS do exactly
what QEMU intends.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Sometimes we need to pass ranges around, add a
handy structure for this purpose.
Note: memory.c defines its own concept of AddrRange structure for
working with 128 addresses. It's necessary there for doing range math.
This is not needed for most users: struct Range is
much simpler, and is only used for passing the range around.
Cc: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
For add, the carry only requires checking one of the arguments.
For sub and neg, we can similarly optimize computation of the
carry.
For ge, we can just do lexicographic order.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Support in fwcfg has been around for exposure of the clock-frequency
CPU property. OpenBIOS reads it, we just never exposed it.
Since Mac OS X is very picky about its clock frequency values, let's
just take a known good value and always expose that.
Reported-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Signed-off-by: Alexander Graf <agraf@suse.de>
RTAS is a hypervisor provided binary blob that a guest loads and
calls into to execute certain functions. It's similar to the
vsyscall page in Linux or the short lived VMCI paravirt interface
from VMware.
The QEMU implementation of the RTAS blob is simply a passthrough
that proxies all RTAS calls to the hypervisor via an hypercall.
While we pass a CPU argument for hypercall handling in QEMU, we
don't pass it for RTAS calls. Since some RTAs calls require
making hypercalls (normally RTAS is implemented as guest code) we
have nasty hacks to allow that.
Add a CPU argument to RTAS call handling so we can more easily
invoke hypercalls just as guest code would.
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
Introduce type constant and cast macro.
Signed-off-by: Andreas Färber <afaerber@suse.de>
Reviewed-by: Peter Crosthwaite <peter.crosthwaite@xilinx.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
Enables support for the in-kernel MPIC that thas been merged into the
KVM next branch. This includes irqfd/KVM_IRQ_LINE support from Alex
Graf (along with some other improvements).
Note from Alex regarding kvm_irqchip_create():
On x86, one would call kvm_irqchip_create() to initialize an
in-kernel interrupt controller. That function then goes ahead and
initializes global capability variables as well as the default irq
routing table.
On ppc, we can't call kvm_irqchip_create() because we can have
different types of interrupt controllers. So we want to do all the
things that function would do for us in the in-kernel device init
handler.
Signed-off-by: Scott Wood <scottwood@freescale.com>
[agraf: squash in kvm_irqchip_commit_routes patch, fix non-kvm build,
fix ppcemb]
Signed-off-by: Alexander Graf <agraf@suse.de>
The current logic updates KVM's view of our interrupt map every time we
change it. While this is nice and bullet proof, it slows things down
badly for me. QEMU spends about 3 seconds on every start telling KVM what
news it has on its routing maps.
Instead, let's just synchronize the whole irq routing map as a whole when
we're done constructing it. For things that change during runtime, we can
still update the routing table on demand.
Signed-off-by: Alexander Graf <agraf@suse.de>
On PPC, we can have different types of interrupt controllers, so we really
only know that we are going to use one when we created it.
Export kvm_init_irq_routing() to common code, so that we don't have to call
kvm_irqchip_create().
Signed-off-by: Alexander Graf <agraf@suse.de>
On PPC, we don't support MP state. So far it's not necessary and I'm
not convinced yet that we really need to support it ever.
However, the current idle logic in QEMU assumes that an in-kernel PIC
also means we support MP state. This assumption is not true anymore.
Let's split up the two cases into two different variables. That way
PPC can expose an in-kernel PIC, while not implementing MP state.
Signed-off-by: Alexander Graf <agraf@suse.de>
CC: Jan Kiszka <jan.kiszka@siemens.com>
# By Gerd Hoffmann (13) and Michael Tokarev (1)
# Via Michael Tokarev
* mjt/trivial-patches:
doc: we use seabios, not bochs bios
qemu-socket: don't leak opts on error
qemu-char: report udp backend errors
qemu-char: add -chardev mux support
qemu-char: minor mux chardev fixes
qemu-char: use ChardevBackendKind in CharDriver
qemu-char: don't leak opts on error
qemu-char: fix documentation for telnet+wait socket flags
qemu-char: print notification to stderr
qemu-char: use more specific error_setg_* variants
qemu-char: check optional fields using has_*
qemu-socket: catch monitor_get_fd failures
qemu-socket: drop pointless allocation
qemu-socket: zero-initialize SocketAddress
Message-id: 1372443465-22384-1-git-send-email-mjt@msgid.tls.msk.ru
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
.has_zero_init defaults to 1 for all formats and protocols.
this is a dangerous default since this means that all
new added drivers need to manually overwrite it to 0 if
they do not ensure that a device is zero initialized
after bdrv_create().
if a driver needs to explicitly set this value to
1 its easier to verify the correctness in the review process.
during review of the existing drivers it turned out
that ssh and gluster had a wrong default of 1.
both protocols support host_devices as backend
which are not by default zero initialized. this
wrong assumption will lead to possible corruption
if qemu-img convert is used to write to such a backend.
vpc and vmdk also defaulted to 1 altough they support
fixed respectively flat extends. this has to be addresses
in separate patches. both formats as well as the mentioned
ssh and gluster are turned to the default of 0 with this
patch for safety.
a similar problem with the wrong default existed for
iscsi most likely because the driver developer did
oversee the default value of 1.
Signed-off-by: Peter Lieven <pl@kamp.de>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Use it for all targets, but be careful not to pass invalid CPUState.
cpu_single_env can be NULL, e.g. on Xen.
Signed-off-by: Andreas Färber <afaerber@suse.de>