shaba/libvirt
1
0
Fork 0
mirror of https://gitlab.com/libvirt/libvirt.git synced 2024-12-26 03:21:44 +03:00
Code Releases Activity
e9a85a6e4f
libvirt/tests/qemuxml2argvdata/qemuxml2argv-pci-rom.xml

52 lines
1.6 KiB
XML
Raw Normal View History

qemu: add ability to set PCI device "rombar" on or off This patch was made in response to: https://bugzilla.redhat.com/show_bug.cgi?id=738095 In short, qemu's default for the rombar setting (which makes the firmware ROM of a PCI device visible/not on the guest) was previously 0 (not visible), but they recently changed the default to 1 (visible). Unfortunately, there are some PCI devices that fail in the guest when rombar is 1, so the setting must be exposed in libvirt to prevent a regression in behavior (it will still require explicitly setting <rom bar='off'/> in the guest XML). rombar is forced on/off by adding: <rom bar='on|off'/> inside a <hostdev> element that defines a PCI device. It is currently ignored for all other types of devices. At the moment there is no clean method to determine whether or not the rombar option is supported by QEMU - this patch uses the advice of a QEMU developer to assume support for qemu-0.12+. There is currently a patch in the works to put this information in the output of "qemu-kvm -device pci-assign,?", but of course if we switch to keying off that, we would lose support for setting rombar on all the versions of qemu between 0.12 and whatever version gets that patch.
2011-09-20 21:31:52 +04:00
<domain type='qemu'>
<name>QEMUGuest2</name>
<uuid>c7a5fdbd-edaf-9466-926a-d65c16db1809</uuid>
xml: output memory unit for clarity Make it obvious to 'dumpxml' readers what unit we are using, since our default of KiB for memory (1024) differs from qemu's default of MiB; and differs from our use of bytes for storage. Tests were updated via: $ find tests/*data tests/*out -name '*.xml' | \ xargs sed -i 's/<\(memory\|currentMemory\|hard_limit\|soft_limit\|min_guarantee\|swap_hard_limit\)>/<\1 unit='"'KiB'>/" $ find tests/*data tests/*out -name '*.xml' | \ xargs sed -i 's/<\(capacity\|allocation\|available\)>/<\1 unit='"'bytes'>/" followed by a few fixes for the stragglers. Note that with this patch, the RNG for <memory> still forbids validation of anything except unit='KiB', since the code silently ignores the attribute; a later patch will expand <memory> to allow scaled input in the code and update the RNG to match. * docs/schemas/basictypes.rng (unit): Add 'bytes'. (scaledInteger): New define. * docs/schemas/storagevol.rng (sizing): Use it. * docs/schemas/storagepool.rng (sizing): Likewise. * docs/schemas/domaincommon.rng (memoryKBElement): New define; use for memory elements. * src/conf/storage_conf.c (virStoragePoolDefFormat) (virStorageVolDefFormat): Likewise. * src/conf/domain_conf.h (_virDomainDef): Document unit used internally. * src/conf/storage_conf.h (_virStoragePoolDef, _virStorageVolDef): Likewise. * tests/*data/*.xml: Update all tests. * tests/*out/*.xml: Likewise. * tests/define-dev-segfault: Likewise. * tests/openvzutilstest.c (testReadNetworkConf): Likewise. * tests/qemuargv2xmltest.c (blankProblemElements): Likewise.
2012-02-23 04:48:38 +04:00
<memory unit='KiB'>219100</memory>
<currentMemory unit='KiB'>219100</currentMemory>
numad: Always output 'placement' of <vcpu> <vcpu> is not an optional node. The value for its 'placement' actually always defaults to 'static' in the underlying codes. (Even no 'cpuset' and 'placement' is specified, the domain process will be pinned to all the available pCPUs).
2012-05-08 20:04:36 +04:00
<vcpu placement='static'>1</vcpu>
qemu: add ability to set PCI device "rombar" on or off This patch was made in response to: https://bugzilla.redhat.com/show_bug.cgi?id=738095 In short, qemu's default for the rombar setting (which makes the firmware ROM of a PCI device visible/not on the guest) was previously 0 (not visible), but they recently changed the default to 1 (visible). Unfortunately, there are some PCI devices that fail in the guest when rombar is 1, so the setting must be exposed in libvirt to prevent a regression in behavior (it will still require explicitly setting <rom bar='off'/> in the guest XML). rombar is forced on/off by adding: <rom bar='on|off'/> inside a <hostdev> element that defines a PCI device. It is currently ignored for all other types of devices. At the moment there is no clean method to determine whether or not the rombar option is supported by QEMU - this patch uses the advice of a QEMU developer to assume support for qemu-0.12+. There is currently a patch in the works to put this information in the output of "qemu-kvm -device pci-assign,?", but of course if we switch to keying off that, we would lose support for setting rombar on all the versions of qemu between 0.12 and whatever version gets that patch.
2011-09-20 21:31:52 +04:00
<os>
<type arch='i686' machine='pc'>hvm</type>
<boot dev='hd'/>
</os>
<clock offset='utc'/>
<on_poweroff>destroy</on_poweroff>
<on_reboot>restart</on_reboot>
<on_crash>destroy</on_crash>
<devices>
<emulator>/usr/bin/qemu</emulator>
<disk type='block' device='disk'>
<source dev='/dev/HostVG/QEMUGuest2'/>
<target dev='hda' bus='ide'/>
conf: Introduce new attribute for device address format * src/conf/domain_conf.h: Add new member "target" to struct _virDomainDeviceDriveAddress. * src/conf/domain_conf.c: Parse and format "target" * Lots of tests (.xml) in tests/domainsnapshotxml2xmlout, tests/qemuxml2argvdata, tests/qemuxml2xmloutdata, and tests/vmx2xmldata/ are modified for newly introduced attribute "target" for address of "drive" type.
2012-02-27 14:19:54 +04:00
<address type='drive' controller='0' bus='0' target='0' unit='0'/>
qemu: add ability to set PCI device "rombar" on or off This patch was made in response to: https://bugzilla.redhat.com/show_bug.cgi?id=738095 In short, qemu's default for the rombar setting (which makes the firmware ROM of a PCI device visible/not on the guest) was previously 0 (not visible), but they recently changed the default to 1 (visible). Unfortunately, there are some PCI devices that fail in the guest when rombar is 1, so the setting must be exposed in libvirt to prevent a regression in behavior (it will still require explicitly setting <rom bar='off'/> in the guest XML). rombar is forced on/off by adding: <rom bar='on|off'/> inside a <hostdev> element that defines a PCI device. It is currently ignored for all other types of devices. At the moment there is no clean method to determine whether or not the rombar option is supported by QEMU - this patch uses the advice of a QEMU developer to assume support for qemu-0.12+. There is currently a patch in the works to put this information in the output of "qemu-kvm -device pci-assign,?", but of course if we switch to keying off that, we would lose support for setting rombar on all the versions of qemu between 0.12 and whatever version gets that patch.
2011-09-20 21:31:52 +04:00
</disk>
domain: add implicit USB controller 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.
2012-02-08 04:48:25 +04:00
<controller type='usb' index='0'/>
qemu: (and conf) support rombar for network devices 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).
2012-01-25 04:54:12 +04:00
<controller type='ide' index='0'/>
qemu: auto-add pci-root controller for pc machine types <controller type='pci' index='0' model='pci-root'/> is auto-added to pc* machine types. Without this controller PCI bus 0 is not available and no PCI addresses are assigned by default. Since older libvirt supported PCI bus 0 even without this controller, it is removed from the XML when migrating.
2013-04-22 16:16:13 +04:00
<controller type='pci' index='0' model='pci-root'/>
qemu: (and conf) support rombar for network devices 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).
2012-01-25 04:54:12 +04:00
<interface type='user'>
<mac address='52:54:00:24:a5:9f'/>
<model type='virtio'/>
<rom bar='on'/>
</interface>
<interface type='user'>
<mac address='52:54:00:24:a5:9e'/>
<model type='virtio'/>
qemu: add "romfile" support to specify device boot ROM 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>).
2012-01-25 20:20:49 +04:00
<rom file='/etc/fake/bootrom.bin'/>
qemu: (and conf) support rombar for network devices 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).
2012-01-25 04:54:12 +04:00
</interface>
device: cleanup input device code The current code was a little bit odd. At first we've removed all possible implicit input devices from domain definition to add them later back if there was any graphics device defined while parsing XML description. That's not all, while formating domain definition to XML description we at first ignore any input devices with bus different to USB and VIRTIO and few lines later we add implicit input devices to XML. This seems to me as a lot of code for nothing. This patch may look to be more complicated than original approach, but this is a preferred way to modify/add driver specific stuff only in those drivers and not deal with them in common parsing/formating functions. The update is to add those implicit input devices into config XML to follow the real HW configuration visible by guest OS. There was also inconsistence between our behavior and QEMU's in the way, that in QEMU there is no way how to disable those implicit input devices for x86 architecture and they are available always, even without graphics device. This applies also to XEN hypervisor. VZ driver already does its part by putting correct implicit devices into live XML. Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
2016-01-11 14:40:32 +03:00
<input type='mouse' bus='ps2'/>
<input type='keyboard' bus='ps2'/>
qemu: add ability to set PCI device "rombar" on or off This patch was made in response to: https://bugzilla.redhat.com/show_bug.cgi?id=738095 In short, qemu's default for the rombar setting (which makes the firmware ROM of a PCI device visible/not on the guest) was previously 0 (not visible), but they recently changed the default to 1 (visible). Unfortunately, there are some PCI devices that fail in the guest when rombar is 1, so the setting must be exposed in libvirt to prevent a regression in behavior (it will still require explicitly setting <rom bar='off'/> in the guest XML). rombar is forced on/off by adding: <rom bar='on|off'/> inside a <hostdev> element that defines a PCI device. It is currently ignored for all other types of devices. At the moment there is no clean method to determine whether or not the rombar option is supported by QEMU - this patch uses the advice of a QEMU developer to assume support for qemu-0.12+. There is currently a patch in the works to put this information in the output of "qemu-kvm -device pci-assign,?", but of course if we switch to keying off that, we would lose support for setting rombar on all the versions of qemu between 0.12 and whatever version gets that patch.
2011-09-20 21:31:52 +04:00
<hostdev mode='subsystem' type='pci' managed='yes'>
<source>
<address domain='0x0000' bus='0x06' slot='0x12' function='0x5'/>
</source>
<rom bar='off'/>
</hostdev>
qemu: (and conf) support rombar for network devices 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).
2012-01-25 04:54:12 +04:00
<hostdev mode='subsystem' type='pci' managed='yes'>
<source>
<address domain='0x0000' bus='0x06' slot='0x12' function='0x6'/>
</source>
qemu: add "romfile" support to specify device boot ROM 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>).
2012-01-25 20:20:49 +04:00
<rom bar='on' file='/etc/fake/bootrom.bin'/>
qemu: (and conf) support rombar for network devices 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).
2012-01-25 04:54:12 +04:00
</hostdev>
qemu: add ability to set PCI device "rombar" on or off This patch was made in response to: https://bugzilla.redhat.com/show_bug.cgi?id=738095 In short, qemu's default for the rombar setting (which makes the firmware ROM of a PCI device visible/not on the guest) was previously 0 (not visible), but they recently changed the default to 1 (visible). Unfortunately, there are some PCI devices that fail in the guest when rombar is 1, so the setting must be exposed in libvirt to prevent a regression in behavior (it will still require explicitly setting <rom bar='off'/> in the guest XML). rombar is forced on/off by adding: <rom bar='on|off'/> inside a <hostdev> element that defines a PCI device. It is currently ignored for all other types of devices. At the moment there is no clean method to determine whether or not the rombar option is supported by QEMU - this patch uses the advice of a QEMU developer to assume support for qemu-0.12+. There is currently a patch in the works to put this information in the output of "qemu-kvm -device pci-assign,?", but of course if we switch to keying off that, we would lose support for setting rombar on all the versions of qemu between 0.12 and whatever version gets that patch.
2011-09-20 21:31:52 +04:00
<memballoon model='virtio'/>
</devices>
</domain>
Copy Permalink