- 03 3月, 2012 1 次提交
-
-
由 Ansis Atteka 提交于
When a tap device for a domain is created and attached to a bridge, the first byte of the tap device MAC address is set to 0xFE, while the rest is set to match the MAC address that will be presented to the guest as its network device MAC address. Setting this high value in the tap's MAC address discourages the bridge from using the tap device's MAC address as the bridge's own MAC address (Linux bridges always take on the lowest numbered MAC address of all attached devices as their own). In one case within libvirt, a tap device is created and attached to the bridge with the intent that its MAC address be taken on by the bridge as its own (this is used to assure that the bridge has a fixed MAC address to prevent network outages created by the bridge MAC address "flapping" as guests are started and stopped). In this case, the first byte of the mac address is *not* altered to 0xFE. In the current code, callers to virNetDevTapCreateInBridgePort each make the MAC address modification themselves before calling, which leads to code duplication, and also prevents lower level functions from knowing the real MAC address being used by the guest. The problem here is that openvswitch bridges must be informed about this MAC address, or they will be unable to pass traffic to/from the guest. This patch centralizes the location of the MAC address "0xFE fixup" into virNetDevTapCreateInBridgePort(), meaning 1) callers of this function no longer need the extra strange bit of code, and 2) bitNetDevTapCreateBridgeInPort itself now is called with the guest's unaltered MAC address, and can pass it on, unmodified, to virNetDevOpenvswitchAddPort. There is no other behavioral change created by this patch.
-
- 02 3月, 2012 1 次提交
-
-
由 Eric Blake 提交于
No thanks to 64-bit windows, with 64-bit pid_t, we have to avoid constructs like 'int pid'. Our API in libvirt-qemu cannot be changed without breaking ABI; but then again, libvirt-qemu can only be used on systems that support UNIX sockets, which rules out Windows (even if qemu could be compiled there) - so for all points on the call chain that interact with this API decision, we require a different variable name to make it clear that we audited the use for safety. Adding a syntax-check rule only solves half the battle; anywhere that uses printf on a pid_t still needs to be converted, but that will be a separate patch. * cfg.mk (sc_correct_id_types): New syntax check. * src/libvirt-qemu.c (virDomainQemuAttach): Document why we didn't use pid_t for pid, and validate for overflow. * include/libvirt/libvirt-qemu.h (virDomainQemuAttach): Tweak name for syntax check. * src/vmware/vmware_conf.c (vmwareExtractPid): Likewise. * src/driver.h (virDrvDomainQemuAttach): Likewise. * tools/virsh.c (cmdQemuAttach): Likewise. * src/remote/qemu_protocol.x (qemu_domain_attach_args): Likewise. * src/qemu_protocol-structs (qemu_domain_attach_args): Likewise. * src/util/cgroup.c (virCgroupPidCode, virCgroupKillInternal): Likewise. * src/qemu/qemu_command.c(qemuParseProcFileStrings): Likewise. (qemuParseCommandLinePid): Use pid_t for pid. * daemon/libvirtd.c (daemonForkIntoBackground): Likewise. * src/conf/domain_conf.h (_virDomainObj): Likewise. * src/probes.d (rpc_socket_new): Likewise. * src/qemu/qemu_command.h (qemuParseCommandLinePid): Likewise. * src/qemu/qemu_driver.c (qemudGetProcessInfo, qemuDomainAttach): Likewise. * src/qemu/qemu_process.c (qemuProcessAttach): Likewise. * src/qemu/qemu_process.h (qemuProcessAttach): Likewise. * src/uml/uml_driver.c (umlGetProcessInfo): Likewise. * src/util/virnetdev.h (virNetDevSetNamespace): Likewise. * src/util/virnetdev.c (virNetDevSetNamespace): Likewise. * tests/testutils.c (virtTestCaptureProgramOutput): Likewise. * src/conf/storage_conf.h (_virStoragePerms): Use mode_t, uid_t, and gid_t rather than int. * src/security/security_dac.c (virSecurityDACSetOwnership): Likewise. * src/conf/storage_conf.c (virStorageDefParsePerms): Avoid compiler warning.
-
- 29 2月, 2012 1 次提交
-
-
由 Jiri Denemark 提交于
Bug introduced by commit eda0fc7a.
-
- 28 2月, 2012 3 次提交
-
-
由 Osier Yang 提交于
For any disk controller model which is not "lsilogic", the command line will be like: -drive file=/dev/sda,if=none,id=drive-scsi0-0-3-0,format=raw \ -device scsi-disk,bus=scsi0.0,channel=0,scsi-id=3,lun=0,i\ drive=drive-scsi0-0-3-0,id=scsi0-0-3-0 The relationship between the libvirt address attrs and the qdev properties are (controller model is not "lsilogic"; strings inside <> represent libvirt adress attrs): bus=scsi<controller>.0 channel=<bus> scsi-id=<target> lun=<unit> * src/qemu/qemu_command.h: (New param "virDomainDefPtr def" for function qemuBuildDriveDevStr; new param "virDomainDefPtr vmdef" for function qemuAssignDeviceDiskAlias. Both for virDomainDiskFindControllerModel's use). * src/qemu/qemu_command.c: - New param "virDomainDefPtr def" for qemuAssignDeviceDiskAliasCustom. For virDomainDiskFindControllerModel's use, if the disk bus is "scsi" and the controller model is not "lsilogic", "target" is one part of the alias name. - According change on qemuAssignDeviceDiskAlias and qemuBuildDriveDevStr * src/qemu/qemu_hotplug.c: - Changes to be consistent with declarations of qemuAssignDeviceDiskAlias qemuBuildDriveDevStr, and qemuBuildControllerDevStr. * tests/qemuxml2argvdata/qemuxml2argv-pseries-vio-user-assigned.args, tests/qemuxml2argvdata/qemuxml2argv-pseries-vio.args: Update the generated command line.
-
由 Paolo Bonzini 提交于
Adding a new model for virtio-scsi roughly follows the same scheme as the previous patch. Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
-
由 Paolo Bonzini 提交于
KVM will be able to use a PCI SCSI controller even on POWER. Let the user specify the vSCSI controller by other means than a default. After this patch, the QEMU driver will actually look at the model and reject anything but auto, lsilogic and ibmvscsi. Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com> Signed-off-by: NOsier Yang <jyang@redhat.com>
-
- 25 2月, 2012 1 次提交
-
-
由 Christophe Fergeau 提交于
It's possible to disable SPICE TLS in qemu.conf. When this happens, libvirt ignores any SPICE TLS port or x509 directory that may have been set when it builds the qemu command line to use. However, it's not ignoring the secure channels that may have been set and adds tls-channel arguments to qemu command line. Current qemu versions don't report an error when this happens, and try to use TLS for the specified channels. Before this patch <domain type='kvm'> <name>auto-tls-port</name> <memory>65536</memory> <os> <type arch='x86_64' machine='pc'>hvm</type> </os> <devices> <graphics type='spice' port='5900' tlsPort='-1' autoport='yes' listen='0' ke <listen type='address' address='0'/> <channel name='main' mode='secure'/> <channel name='inputs' mode='secure'/> </graphics> </devices> </domain> generates -spice port=5900,addr=0,disable-ticketing,tls-channel=main,tls-channel=inputs and starts QEMU. After this patch, an error is reported if a TLS port is set in the XML or if secure channels are specified but TLS is disabled in qemu.conf. This is the behaviour the oVirt people (where I spotted this issue) said they would expect. This fixes bug #790436
-
- 16 2月, 2012 3 次提交
-
-
由 Jiri Denemark 提交于
In case libvirtd cannot detect host CPU model (which may happen if it runs inside a virtual machine), the daemon is likely to segfault when starting a new qemu domain. It segfaults when domain XML asks for host (either model or passthrough) CPU or does not ask for any specific CPU model at all.
-
由 Ansis Atteka 提交于
This patch allows libvirt to add interfaces to already existing Open vSwitch bridges. The following syntax in domain XML file can be used: <interface type='bridge'> <mac address='52:54:00:d0:3f:f2'/> <source bridge='ovsbr'/> <virtualport type='openvswitch'> <parameters interfaceid='921a80cd-e6de-5a2e-db9c-ab27f15a6e1d'/> </virtualport> <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> </interface> or if libvirt should auto-generate the interfaceid use following syntax: <interface type='bridge'> <mac address='52:54:00:d0:3f:f2'/> <source bridge='ovsbr'/> <virtualport type='openvswitch'> </virtualport> <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> </interface> It is also possible to pass an optional profileid. To do that use following syntax: <interface type='bridge'> <source bridge='ovsbr'/> <mac address='00:55:1a:65:a2:8d'/> <virtualport type='openvswitch'> <parameters interfaceid='921a80cd-e6de-5a2e-db9c-ab27f15a6e1d' profileid='test-profile'/> </virtualport> </interface> To create Open vSwitch bridge install Open vSwitch and run the following command: ovs-vsctl add-br ovsbr
-
由 Laine Stump 提交于
An upcoming patch will add a <virtualport> element to interfaces of type='bridge', so it makes sense to give this function a more generic name.
-
- 13 2月, 2012 2 次提交
-
-
由 Daniel Veillard 提交于
This reverts commit 7b345b69. Conflicts: tests/qemuxml2argvdata/qemuxml2argv-disk-scsi-vscsi.xml
-
由 Daniel Veillard 提交于
This reverts commit c9abfadf. Conflicts: tests/qemuxml2argvdata/qemuxml2argv-disk-scsi-virtio-scsi.xml
-
- 10 2月, 2012 1 次提交
-
-
由 Marc-André Lureau 提交于
Some tools, such as virt-manager, prefers having the default USB controller explicit in the XML document. This patch makes sure there is one. With this patch, it is now possible to switch from USB1 to USB2 from the release 0.9.1 of virt-manager. Fix tests to pass with this change.
-
- 08 2月, 2012 1 次提交
-
-
由 Jiri Denemark 提交于
Reported by Alex Jia: ==21503== 112 (32 direct, 80 indirect) bytes in 1 blocks are definitely lost in loss record 37 of 40 ==21503== at 0x4A04A28: calloc (vg_replace_malloc.c:467) ==21503== by 0x4A8991: virAlloc (memory.c:101) ==21503== by 0x505A6C: x86DataCopy (cpu_x86.c:247) ==21503== by 0x507B34: x86Compute (cpu_x86.c:1225) ==21503== by 0x43103C: qemuBuildCommandLine (qemu_command.c:3561) ==21503== by 0x41C9F7: testCompareXMLToArgvHelper (qemuxml2argvtest.c:183) ==21503== by 0x41E10D: virtTestRun (testutils.c:141) ==21503== by 0x41B942: mymain (qemuxml2argvtest.c:705) ==21503== by 0x41D7E7: virtTestMain (testutils.c:696)
-
- 31 1月, 2012 3 次提交
-
-
由 Laine Stump 提交于
This patch addresses: https://bugzilla.redhat.com/show_bug.cgi?id=781562 Along with the "rombar" option that controls whether or not a boot rom is made visible to the guest, qemu also has a "romfile" option that allows specifying a binary file to present as the ROM BIOS of any emulated or passthrough PCI device. This patch adds support for specifying romfile to both passthrough PCI devices, and emulated network devices that attach to the guest's PCI bus (just about everything other than ne2k_isa). One example of the usefulness of this option is described in the bugzilla report: 82576 sriov network adapters don't provide a ROM BIOS for the cards virtual functions (VF), but an image of such a ROM is available, and with this ROM visible to the guest, it can PXE boot. In libvirt's xml, the new option is configured like this: <hostdev> ... <rom file='/etc/fake/boot.bin'/> ... </hostdev (similarly for <interface>).
-
由 Laine Stump 提交于
When support for the rombar option was added, it was only added for PCI passthrough devices, configured with <hostdev>. The same option is available for any network device that is attached to the guest's PCI bus. This patch allows setting rombar for any PCI network device type. After adding cases to test this to qemuxml2argv-hostdev-pci-rombar.*, I decided to rename those files (to qemuxml2argv-pci-rom.*) to more accurately reflect the additional tests, and also noticed that up to now we've only been performing a domainschematest for that case, so I added the "pci-rom" test to both qemuxml2argv and qemuxml2xml (and in the process found some bugs whose fixes I squashed into previous commits of this series).
-
由 Laine Stump 提交于
To help consolidate the commonality between virDomainHostdevDef and virDomainNetDef into as few members as possible (and because I think it makes sense), this patch moves the rombar and bootIndex members into the "info" member that is common to both (and to all the other structs that use them). It's a bit problematic that this gives rombar and bootIndex to many device types that don't use them, but this is already the case for the master and mastertype members of virDomainDeviceInfo, and is properly commented as such in the definition. Note that this opens the door to supporting rombar for other devices that are attached to the guest PCI bus - virtio-blk-pci, virtio-net-pci, various other network adapters - which which have that capability in qemu, but previously had no support in libvirt.
-
- 28 1月, 2012 1 次提交
-
-
由 Daniel P. Berrange 提交于
Rename virFormatMacAddr, virGenerateMacAddr and virParseMacAddr to virMacAddrFormat, virMacAddrGenerate and virMacAddrParse respectively
-
- 27 1月, 2012 5 次提交
-
-
由 Paolo Bonzini 提交于
QEMU supports a bunch of CPUID features that are tied to the kvm CPUID nodes rather than the processor's. They are "kvmclock", "kvm_nopiodelay", "kvm_mmu", "kvm_asyncpf". These are not known to libvirt and their CPUID leaf might move if (for example) the Hyper-V extensions are enabled. Hence their handling would anyway require some special-casing. However, among these the most useful is kvmclock; an additional "property" of this feature is that a <timer> element is a better model than a CPUID feature. Although, creating part of the -cpu command-line from something other than the <cpu> XML element introduces some ugliness. Reviewed-by: NJiri Denemark <jdenemar@redhat.com> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
-
由 Paolo Bonzini 提交于
Avoid creating an empty <cpu> element when the QEMU command-line simply specifies the default "-cpu qemu32" or "-cpu qemu64". This requires the previous patch, which lets us represent "-cpu qemu32" as <os arch='i686'> in the generated XML. Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
-
由 Paolo Bonzini 提交于
The qemu32 CPU model is chosen based on the <os arch=...> name when creating the QEMU command line for a 64-bit host. For the opposite transformation we can test the guest CPU model for the "lm" feature. If it is absent, def->os.arch needs to be corrected. Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
-
由 Paolo Bonzini 提交于
When running under KVM, the arch is usually set to i686 because the name of the emulator is not qemu-system-x86_64. Use the host arch instead. Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
-
由 Paolo Bonzini 提交于
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
-
- 25 1月, 2012 1 次提交
-
-
由 Jiri Denemark 提交于
Direct boot (using kernel, initrd, and command line) is used by virt-install/virt-manager for network install. While any bootindex has no direct effect since -kernel is always first, we need it as a hint for SeaBIOS to present disks in the same order as they will be presented during normal boot.
-
- 19 1月, 2012 1 次提交
-
-
由 Martin Kletzander 提交于
There was missing capability for blkiotune and thus specifying these settings caused libvirt to run qemu with invalid parameters and then reporting qemu error instead of the standard libvirt one. The support for blkiotune setting was added in upstream qemu repo under commit 0563e191516289c9d2f282a8c50f2eecef2fa773.
-
- 18 1月, 2012 2 次提交
-
-
由 Deepak C Shetty 提交于
This introduces new attribute wrpolicy with only supported value as immediate. This will be an optional attribute with no defaults. This helps specify whether to skip the host page cache. When wrpolicy is specified, meaning when wrpolicy=immediate a writeback is explicitly initiated for the dirty pages in the host page cache as part of the guest file write operation. Usage: <filesystem type='mount' accessmode='passthrough'> <driver type='path' wrpolicy='immediate'/> <source dir='/export/to/guest'/> <target dir='mount_tag'/> </filesystem> Currently this only works with type='mount' for the QEMU/KVM driver. Signed-off-by: NDeepak C Shetty <deepakcs@linux.vnet.ibm.com>
-
由 Jiri Denemark 提交于
In the past we didn't reserve 0:0:2.0 PCI address if there was no video device assigned to a domain, which made it impossible to add a video device later on. So we fixed it (commit v0.9.0-37-g7b2cac12) by always reserving that address. However, that breaks existing domains without video devices that already have another device assigned to the problematic address. This patch reserves address 0:0:2.0 only in case it was not explicitly assigned to another device, which means libvirt will try to keep this address free and will not automatically assign it new devices. But existing domains for which older libvirt already assigned the address to a non-video device will keep working as they used to work before 0.9.1. Moreover, users who want to create a domain without a video device and use its address for another device may do so by explicitly configuring the PCI address in domain XML.
-
- 17 1月, 2012 2 次提交
-
-
由 Jiri Denemark 提交于
This adds support for host-model and host-passthrough CPU modes to qemu driver. The host-passthrough mode is mapped to -cpu host.
-
由 Jiri Denemark 提交于
In case a hypervisor doesn't support the exact CPU model requested by a domain XML, we automatically fallback to a closest CPU model the hypervisor supports (and make sure we add/remove any additional features if needed). This patch adds 'fallback' attribute to model element, which can be used to disable this automatic fallback.
-
- 14 1月, 2012 3 次提交
-
-
由 Michael Ellerman 提交于
We can't call qemuCapsExtractVersionInfo() from test code, because it expects to be able to call the emulator, and for testing we have fake emulators that can't be executed. For that reason qemuxml2argvtest.c doesn't call qemuDomainAssignPCIAddresses(), instead it open codes its own version. That means we can't call qemuDomainAssignAddresses() from the test code, instead we need to manually call qemuDomainAssignSpaprVioAddresses(). Also add logic to cope with qemuDomainAssignSpaprVioAddresses() failing, so that we can write a test that checks for a known failure in there. Signed-off-by: NMichael Ellerman <michael@ellerman.id.au>
-
由 Paolo Bonzini 提交于
Adding a new model for virtio-scsi roughly follows the same scheme as the previous patch. Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
-
由 Paolo Bonzini 提交于
KVM will be able to use a PCI SCSI controller even on POWER. Let the user specify the vSCSI controller by other means than a default. After this patch, the QEMU driver will actually look at the model and reject anything but auto, lsilogic and ibmvscsi. Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
-
- 13 1月, 2012 1 次提交
-
-
由 Osier Yang 提交于
The new introduced optional attribute "copy_on_read</code> controls whether to copy read backing file into the image file. The value can be either "on" or "off". Copy-on-read avoids accessing the same backing file sectors repeatedly and is useful when the backing file is over a slow network. By default copy-on-read is off.
-
- 12 1月, 2012 1 次提交
-
-
由 Deepak C Shetty 提交于
QEMU does not support security_model for anything but 'path' fs driver type. Currently in libvirt, when security_model ( accessmode attribute) is not specified it auto-generates it irrespective of the fs driver type, which can result in a qemu error for drivers other than path. This patch ensures that the qemu cmdline is correctly generated by taking into account the fs driver type. Signed-off-by: NDeepak C Shetty <deepakcs@linux.vnet.ibm.com>
-
- 09 1月, 2012 1 次提交
-
-
由 Laine Stump 提交于
In the past, generic SCSI commands issued from a guest to a virtio disk were always passed through to the underlying disk by qemu, and the kernel would also pass them on. As a result of CVE-2011-4127 (see: http://seclists.org/oss-sec/2011/q4/536), qemu now honors its scsi=on|off device option for virtio-blk-pci (which enables/disables passthrough of generic SCSI commands), and the kernel will only allow the commands for physical devices (not for partitions or logical volumes). The default behavior of qemu is still to allow sending generic SCSI commands to physical disks that are presented to a guest as virtio-blk-pci devices, but libvirt prefers to disable those commands in the standard virtio block devices, enabling it only when specifically requested (hopefully indicating that the requester understands what they're asking for). For this purpose, a new libvirt disk device type (device='lun') has been created. device='lun' is identical to the default device='disk', except that: 1) It is only allowed if bus='virtio', type='block', and the qemu version is "new enough" to support it ("new enough" == qemu 0.11 or better), otherwise the domain will fail to start and a CONFIG_UNSUPPORTED error will be logged). 2) The option "scsi=on" will be added to the -device arg to allow SG_IO commands (if device !='lun', "scsi=off" will be added to the -device arg so that SG_IO commands are specifically forbidden). Guests which continue to use disk device='disk' (the default) will no longer be able to use SG_IO commands on the disk; those that have their disk device changed to device='lun' will still be able to use SG_IO commands. *docs/formatdomain.html.in - document the new device attribute value. *docs/schemas/domaincommon.rng - allow it in the RNG *tests/* - update the args of several existing tests to add scsi=off, and add one new test that will test scsi=on. *src/conf/domain_conf.c - update domain XML parser and formatter *src/qemu/qemu_(command|driver|hotplug).c - treat VIR_DOMAIN_DISK_DEVICE_LUN *almost* identically to VIR_DOMAIN_DISK_DEVICE_DISK, except as indicated above. Note that no support for this new device value was added to any hypervisor drivers other than qemu, because it's unclear what it might mean (if anything) to those drivers.
-
- 08 1月, 2012 1 次提交
-
-
由 Laine Stump 提交于
This fixes https://bugzilla.redhat.com/show_bug.cgi?id=638633 Although scripts are not used by interfaces of type other than "ethernet" in qemu, due to the fact that the parser stores the script name in a union that is only valid when type is ethernet or bridge, there is no way for anyone except the parser itself to catch the problem of specifying an interface script for an inappropriate interface type (by the time the parsed data gets back to the code that called the parser, all evidence that a script was specified is forgotten). Since the parser itself should be agnostic to which type of interface allows scripts (an example of why: a script specified for an interface of type bridge is valid for xen domains, but not for qemu domains), the solution here is to move the script out of the union(s) in the DomainNetDef, always populate it when specified (regardless of interface type), and let the driver decide whether or not it is appropriate. Currently the qemu, xen, libxml, and uml drivers recognize the script parameter and do something with it (the uml driver only to report that it isn't supported). Those drivers have been updated to log a CONFIG_UNSUPPORTED error when a script is specified for an interface type that's inappropriate for that particular hypervisor. (NB: There was earlier discussion of solving this problem by adding a VALIDATE flag to all libvirt APIs that accept XML, which would cause the XML to be validated against the RNG files. One statement during that discussion was that the RNG shouldn't contain hypervisor-specific things, though, and a proper solution to this problem would require that (again, because a script for an interface of type "bridge" is accepted by xen, but not by qemu).
-
- 06 1月, 2012 1 次提交
-
-
由 Alex Jia 提交于
Detected by valgrind. Leak introduced in commit 5745dc12. * src/qemu/qemu_command.c: fix memory leak on failure and successful path. * How to reproduce? % valgrind -v --leak-check=full ./qemuargv2xmltest * Actual result: ==2196== 80 bytes in 1 blocks are definitely lost in loss record 3 of 4 ==2196== at 0x4A05FDE: malloc (vg_replace_malloc.c:236) ==2196== by 0x39CF07F6E1: strdup (in /lib64/libc-2.12.so) ==2196== by 0x419823: qemuParseRBDString (qemu_command.c:1657) ==2196== by 0x4221ED: qemuParseCommandLine (qemu_command.c:5934) ==2196== by 0x422AFB: qemuParseCommandLineString (qemu_command.c:7561) ==2196== by 0x416864: testCompareXMLToArgvHelper (qemuargv2xmltest.c:48) ==2196== by 0x417DB1: virtTestRun (testutils.c:141) ==2196== by 0x415CAF: mymain (qemuargv2xmltest.c:175) ==2196== by 0x4174A7: virtTestMain (testutils.c:696) ==2196== by 0x39CF01ECDC: (below main) (in /lib64/libc-2.12.so) ==2196== ==2196== LEAK SUMMARY: ==2196== definitely lost: 80 bytes in 1 blocks Signed-off-by: NAlex Jia <ajia@redhat.com>
-
- 22 12月, 2011 1 次提交
-
-
由 Osier Yang 提交于
Upstream QEMU starts to support it from commit 2c74c2cb.
-
- 21 12月, 2011 2 次提交
-
-
由 Michael Ellerman 提交于
Add logic to assign addresses for devices with spapr-vio addresses. We also do validation of addresses specified by the user, ie. ensuring that there are not duplicate addresses on the bus. Signed-off-by: NMichael Ellerman <michael@ellerman.id.au>
-
由 Michael Ellerman 提交于
For QEMU PPC64 we have a machine type ("pseries") which has a virtual bus called "spapr-vio". We need to be able to create devices on this bus, and as such need a way to specify the address for those devices. This patch adds a new address type "spapr-vio", which achieves this. The addressing is specified with a "reg" property in the address definition. The reg is optional, if it is not specified QEMU will auto-assign an address for the device. Signed-off-by: NMichael Ellerman <michael@ellerman.id.au>
-