External/libvirt
1
0
Fork 0
mirror of https://gitlab.com/libvirt/libvirt.git synced 2024-11-09 15:00:07 +00:00
Code Issues Packages Projects Releases Wiki Activity
c1c4d0d5a5
libvirt/tests/qemuxml2xmloutdata/qemuxml2xmlout-q35.xml

59 lines
2.3 KiB
XML
Raw Normal View History

qemu: fix handling of default/implicit devices for q35 This patch adds in special handling for a few devices that need to be treated differently for q35 domains: usb - there is no implicit/default usb controller for the q35 machinetype. This is done because normally the default usb controller is added to a domain by just adding "-usb" to the qemu commandline, and it's assumed that this will add a single piix3 usb1 controller at slot 1 function 2. That's not what happens when the machinetype is q35, though. Instead, adding -usb to the commandline adds 3 usb (version 2) controllers to the domain at slot 0x1D.{1,2,7}. Rather than having <controller type='usb' index='0'/> translate into 3 separate devices on the PCI bus, it's cleaner to not automatically add a default usb device; one can always be added explicitly if desired. Or we may decide that on q35 machines, 3 usb controllers will be automatically added when none is given. But for this initial commit, at least we aren't locking ourselves into something we later won't want. video - qemu always initializes the primary video device immediately after any integrated devices for the machinetype. Unless instructed otherwise (by using "-device vga..." instead of "-vga" which libvirt uses in many cases to work around deficiencies and bugs in various qemu versions) qemu will always pick the first unused slot. In the case of the "pc" machinetype and its derivatives, this is always slot 2, but on q35 machinetypes, the first free slot is slot 1 (since the q35's integrated peripheral devices are placed in other slots, e.g. slot 0x1f). In order to make the PCI address of the video device predictable, that slot (1 or 2, depending on machinetype) is reserved even when no video device has been specified. sata - a q35 machine always has a sata controller implicitly added at slot 0x1F, function 2. There is no way to avoid this controller, so we always add it. Note that the xml2xml tests for the pcie-root and q35 cases were changed to use DO_TEST_DIFFERENT() so that we can check for the sata controller being automatically added. This is especially important because we can't check for it in the xml2argv output (it has no effect on that output since it's an implicit device). ide - q35 has no ide controllers. isa and smbus controllers - these two are always present in a q35 (at slot 0x1F functions 0 and 3) but we have no way of modelling them in our config. We do need to reserve those functions so that the user doesn't attempt to put anything else there though. (note that the "pc" machine type also has an ISA controller, which we also ignore).
2013-08-02 08:55:55 +00:00
<domain type='qemu'>
<name>q35-test</name>
<uuid>11dbdcdd-4c3b-482b-8903-9bdb8c0a2774</uuid>
<memory unit='KiB'>2097152</memory>
<currentMemory unit='KiB'>2097152</currentMemory>
<vcpu placement='static' cpuset='0-1'>2</vcpu>
<os>
<type arch='x86_64' machine='q35'>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/libexec/qemu-kvm</emulator>
qemu: enable using implicit sata controller in q35 machines q35 machines have an implicit ahci (sata) controller at 00:1F.2 which has no "id" associated with it. For this reason, we can't refer to it as "ahci0". Instead, we don't give an id on the commandline, which qemu interprets as "use the first ahci controller". We then need to specify the unit with "unit=%d" rather than adding it onto the bus arg.
2013-08-03 21:37:07 +00:00
<disk type='block' device='disk'>
<source dev='/dev/HostVG/QEMUGuest1'/>
<target dev='sda' bus='sata'/>
<address type='drive' controller='0' bus='0' target='0' unit='0'/>
</disk>
qemu: fix handling of default/implicit devices for q35 This patch adds in special handling for a few devices that need to be treated differently for q35 domains: usb - there is no implicit/default usb controller for the q35 machinetype. This is done because normally the default usb controller is added to a domain by just adding "-usb" to the qemu commandline, and it's assumed that this will add a single piix3 usb1 controller at slot 1 function 2. That's not what happens when the machinetype is q35, though. Instead, adding -usb to the commandline adds 3 usb (version 2) controllers to the domain at slot 0x1D.{1,2,7}. Rather than having <controller type='usb' index='0'/> translate into 3 separate devices on the PCI bus, it's cleaner to not automatically add a default usb device; one can always be added explicitly if desired. Or we may decide that on q35 machines, 3 usb controllers will be automatically added when none is given. But for this initial commit, at least we aren't locking ourselves into something we later won't want. video - qemu always initializes the primary video device immediately after any integrated devices for the machinetype. Unless instructed otherwise (by using "-device vga..." instead of "-vga" which libvirt uses in many cases to work around deficiencies and bugs in various qemu versions) qemu will always pick the first unused slot. In the case of the "pc" machinetype and its derivatives, this is always slot 2, but on q35 machinetypes, the first free slot is slot 1 (since the q35's integrated peripheral devices are placed in other slots, e.g. slot 0x1f). In order to make the PCI address of the video device predictable, that slot (1 or 2, depending on machinetype) is reserved even when no video device has been specified. sata - a q35 machine always has a sata controller implicitly added at slot 0x1F, function 2. There is no way to avoid this controller, so we always add it. Note that the xml2xml tests for the pcie-root and q35 cases were changed to use DO_TEST_DIFFERENT() so that we can check for the sata controller being automatically added. This is especially important because we can't check for it in the xml2argv output (it has no effect on that output since it's an implicit device). ide - q35 has no ide controllers. isa and smbus controllers - these two are always present in a q35 (at slot 0x1F functions 0 and 3) but we have no way of modelling them in our config. We do need to reserve those functions so that the user doesn't attempt to put anything else there though. (note that the "pc" machine type also has an ISA controller, which we also ignore).
2013-08-02 08:55:55 +00:00
<controller type='pci' index='0' model='pcie-root'/>
conf: add new <model> subelement with name attribute to <controller> This new subelement is used in PCI controllers: the toplevel *attribute* "model" of a controller denotes what kind of PCI controller is being described, e.g. a "dmi-to-pci-bridge", "pci-bridge", or "pci-root". But in the future there will be different implementations of some of those types of PCI controllers, which behave similarly from libvirt's point of view (and so should have the same model), but use a different device in qemu (and present themselves as a different piece of hardware in the guest). In an ideal world we (i.e. "I") would have thought of that back when the pci controllers were added, and used some sort of type/class/model notation (where class was used in the way we are now using model, and model was used for the actual manufacturer's model number of a particular family of PCI controller), but that opportunity is long past, so as an alternative, this patch allows selecting a particular implementation of a pci controller with the "name" attribute of the <model> subelement, e.g.: <controller type='pci' model='dmi-to-pci-bridge' index='1'> <model name='i82801b11-bridge'/> </controller> In this case, "dmi-to-pci-bridge" is the kind of controller (one that has a single PCIe port upstream, and 32 standard PCI ports downstream, which are not hotpluggable), and the qemu device to be used to implement this kind of controller is named "i82801b11-bridge". Implementing the above now will allow us in the future to add a new kind of dmi-to-pci-bridge that doesn't use qemu's i82801b11-bridge device, but instead uses something else (which doesn't yet exist, but qemu people have been discussing it), all without breaking existing configs. (note that for the existing "pci-bridge" type of PCI controller, both the model attribute and <model> name are 'pci-bridge'. This is just a coincidence, since it turns out that in this case the device name in qemu really is a generic 'pci-bridge' rather than being the name of some real-world chip)
2015-06-25 17:30:23 +00:00
<controller type='pci' index='1' model='dmi-to-pci-bridge'>
<model name='i82801b11-bridge'/>
tests: qemuxml2xml: assign device addresses We use the PreFormat callback for this. Many test cases need to be extended to pass in proper qemuCaps flags so AssignAddresses doesn't throw errors. One test case (pcie-root-port-too-many) is dropped, since it was meant only for checking an error condition in qemuxml2argv, and one we add in AssignAddresses it errors here too. Long term I think AssignAddresses should be handled in qemu's PostParse callback, but that's not entirely straightforward. Handling it here means we can get the test suite churn over with.
2016-01-27 21:03:52 +00:00
<address type='pci' domain='0x0000' bus='0x00' slot='0x1e' function='0x0'/>
conf: add new <model> subelement with name attribute to <controller> This new subelement is used in PCI controllers: the toplevel *attribute* "model" of a controller denotes what kind of PCI controller is being described, e.g. a "dmi-to-pci-bridge", "pci-bridge", or "pci-root". But in the future there will be different implementations of some of those types of PCI controllers, which behave similarly from libvirt's point of view (and so should have the same model), but use a different device in qemu (and present themselves as a different piece of hardware in the guest). In an ideal world we (i.e. "I") would have thought of that back when the pci controllers were added, and used some sort of type/class/model notation (where class was used in the way we are now using model, and model was used for the actual manufacturer's model number of a particular family of PCI controller), but that opportunity is long past, so as an alternative, this patch allows selecting a particular implementation of a pci controller with the "name" attribute of the <model> subelement, e.g.: <controller type='pci' model='dmi-to-pci-bridge' index='1'> <model name='i82801b11-bridge'/> </controller> In this case, "dmi-to-pci-bridge" is the kind of controller (one that has a single PCIe port upstream, and 32 standard PCI ports downstream, which are not hotpluggable), and the qemu device to be used to implement this kind of controller is named "i82801b11-bridge". Implementing the above now will allow us in the future to add a new kind of dmi-to-pci-bridge that doesn't use qemu's i82801b11-bridge device, but instead uses something else (which doesn't yet exist, but qemu people have been discussing it), all without breaking existing configs. (note that for the existing "pci-bridge" type of PCI controller, both the model attribute and <model> name are 'pci-bridge'. This is just a coincidence, since it turns out that in this case the device name in qemu really is a generic 'pci-bridge' rather than being the name of some real-world chip)
2015-06-25 17:30:23 +00:00
</controller>
<controller type='pci' index='2' model='pci-bridge'>
<model name='pci-bridge'/>
conf: add new <target> subelement with chassisNr attribute to <controller> There are some configuration options to some types of pci controllers that are currently automatically derived from other parts of the controller's configuration. For example, in qemu a pci-bridge controller has an option that is called "chassis_nr"; up until now libvirt has always set chassis_nr to the index of the pci-bridge. So this: <controller type='pci' model='pci-bridge' index='2'/> will always result in: -device pci-bridge,chassis_nr=2,... on the qemu commandline. In the future we may decide there is a better way to derive that option, but even in that case we will need for existing domains to retain the same chassis_nr they were using in the past - that is something that is visible to the guest so it is part of the guest ABI and changing it would lead to problems for migrating guests (or just guests with very picky OSes). The <target> subelement has been added as a place to put the new "chassisNr" attribute that will be filled in by libvirt when it auto-generates the chassisNr; it will be saved in the config, then reused any time the domain is started: <controller type='pci' model='pci-bridge' index='2'> <model type='pci-bridge'/> <target chassisNr='2'/> </controller> The one oddity of all this is that if the controller configuration is changed (for example to change the index or the pci address where the controller is plugged in), the items in <target> will *not* be re-generated, which might lead to conflict. I can't really see any way around this, but fortunately if there is a material conflict qemu will let us know and we will pass that on to the user.
2015-07-01 16:47:55 +00:00
<target chassisNr='56'/>
tests: qemuxml2xml: assign device addresses We use the PreFormat callback for this. Many test cases need to be extended to pass in proper qemuCaps flags so AssignAddresses doesn't throw errors. One test case (pcie-root-port-too-many) is dropped, since it was meant only for checking an error condition in qemuxml2argv, and one we add in AssignAddresses it errors here too. Long term I think AssignAddresses should be handled in qemu's PostParse callback, but that's not entirely straightforward. Handling it here means we can get the test suite churn over with.
2016-01-27 21:03:52 +00:00
<address type='pci' domain='0x0000' bus='0x01' slot='0x01' function='0x0'/>
</controller>
<controller type='usb' index='0' model='ich9-ehci1'>
<address type='pci' domain='0x0000' bus='0x00' slot='0x1d' function='0x7'/>
</controller>
<controller type='usb' index='0' model='ich9-uhci1'>
<master startport='0'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x1d' function='0x0' multifunction='on'/>
</controller>
<controller type='usb' index='0' model='ich9-uhci2'>
<master startport='2'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x1d' function='0x1'/>
</controller>
<controller type='usb' index='0' model='ich9-uhci3'>
<master startport='4'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x1d' function='0x2'/>
</controller>
<controller type='sata' index='0'>
<address type='pci' domain='0x0000' bus='0x00' slot='0x1f' function='0x2'/>
conf: add new <model> subelement with name attribute to <controller> This new subelement is used in PCI controllers: the toplevel *attribute* "model" of a controller denotes what kind of PCI controller is being described, e.g. a "dmi-to-pci-bridge", "pci-bridge", or "pci-root". But in the future there will be different implementations of some of those types of PCI controllers, which behave similarly from libvirt's point of view (and so should have the same model), but use a different device in qemu (and present themselves as a different piece of hardware in the guest). In an ideal world we (i.e. "I") would have thought of that back when the pci controllers were added, and used some sort of type/class/model notation (where class was used in the way we are now using model, and model was used for the actual manufacturer's model number of a particular family of PCI controller), but that opportunity is long past, so as an alternative, this patch allows selecting a particular implementation of a pci controller with the "name" attribute of the <model> subelement, e.g.: <controller type='pci' model='dmi-to-pci-bridge' index='1'> <model name='i82801b11-bridge'/> </controller> In this case, "dmi-to-pci-bridge" is the kind of controller (one that has a single PCIe port upstream, and 32 standard PCI ports downstream, which are not hotpluggable), and the qemu device to be used to implement this kind of controller is named "i82801b11-bridge". Implementing the above now will allow us in the future to add a new kind of dmi-to-pci-bridge that doesn't use qemu's i82801b11-bridge device, but instead uses something else (which doesn't yet exist, but qemu people have been discussing it), all without breaking existing configs. (note that for the existing "pci-bridge" type of PCI controller, both the model attribute and <model> name are 'pci-bridge'. This is just a coincidence, since it turns out that in this case the device name in qemu really is a generic 'pci-bridge' rather than being the name of some real-world chip)
2015-06-25 17:30:23 +00:00
</controller>
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 11:40:32 +00:00
<input type='mouse' bus='ps2'/>
<input type='keyboard' bus='ps2'/>
qemu: fix handling of default/implicit devices for q35 This patch adds in special handling for a few devices that need to be treated differently for q35 domains: usb - there is no implicit/default usb controller for the q35 machinetype. This is done because normally the default usb controller is added to a domain by just adding "-usb" to the qemu commandline, and it's assumed that this will add a single piix3 usb1 controller at slot 1 function 2. That's not what happens when the machinetype is q35, though. Instead, adding -usb to the commandline adds 3 usb (version 2) controllers to the domain at slot 0x1D.{1,2,7}. Rather than having <controller type='usb' index='0'/> translate into 3 separate devices on the PCI bus, it's cleaner to not automatically add a default usb device; one can always be added explicitly if desired. Or we may decide that on q35 machines, 3 usb controllers will be automatically added when none is given. But for this initial commit, at least we aren't locking ourselves into something we later won't want. video - qemu always initializes the primary video device immediately after any integrated devices for the machinetype. Unless instructed otherwise (by using "-device vga..." instead of "-vga" which libvirt uses in many cases to work around deficiencies and bugs in various qemu versions) qemu will always pick the first unused slot. In the case of the "pc" machinetype and its derivatives, this is always slot 2, but on q35 machinetypes, the first free slot is slot 1 (since the q35's integrated peripheral devices are placed in other slots, e.g. slot 0x1f). In order to make the PCI address of the video device predictable, that slot (1 or 2, depending on machinetype) is reserved even when no video device has been specified. sata - a q35 machine always has a sata controller implicitly added at slot 0x1F, function 2. There is no way to avoid this controller, so we always add it. Note that the xml2xml tests for the pcie-root and q35 cases were changed to use DO_TEST_DIFFERENT() so that we can check for the sata controller being automatically added. This is especially important because we can't check for it in the xml2argv output (it has no effect on that output since it's an implicit device). ide - q35 has no ide controllers. isa and smbus controllers - these two are always present in a q35 (at slot 0x1F functions 0 and 3) but we have no way of modelling them in our config. We do need to reserve those functions so that the user doesn't attempt to put anything else there though. (note that the "pc" machine type also has an ISA controller, which we also ignore).
2013-08-02 08:55:55 +00:00
<video>
qemu-command: introduce new vgamem attribute for QXL video device Add attribute to set vgamem_mb parameter of QXL device for QEMU. This value sets the size of VGA framebuffer for QXL device. Default value in QEMU is 8MB so reuse it also in libvirt to not break things. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1076098 Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
2014-11-20 18:52:00 +00:00
<model type='qxl' ram='65536' vram='32768' vgamem='8192' heads='1'/>
tests: qemuxml2xml: assign device addresses We use the PreFormat callback for this. Many test cases need to be extended to pass in proper qemuCaps flags so AssignAddresses doesn't throw errors. One test case (pcie-root-port-too-many) is dropped, since it was meant only for checking an error condition in qemuxml2argv, and one we add in AssignAddresses it errors here too. Long term I think AssignAddresses should be handled in qemu's PostParse callback, but that's not entirely straightforward. Handling it here means we can get the test suite churn over with.
2016-01-27 21:03:52 +00:00
<address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x0'/>
qemu: fix handling of default/implicit devices for q35 This patch adds in special handling for a few devices that need to be treated differently for q35 domains: usb - there is no implicit/default usb controller for the q35 machinetype. This is done because normally the default usb controller is added to a domain by just adding "-usb" to the qemu commandline, and it's assumed that this will add a single piix3 usb1 controller at slot 1 function 2. That's not what happens when the machinetype is q35, though. Instead, adding -usb to the commandline adds 3 usb (version 2) controllers to the domain at slot 0x1D.{1,2,7}. Rather than having <controller type='usb' index='0'/> translate into 3 separate devices on the PCI bus, it's cleaner to not automatically add a default usb device; one can always be added explicitly if desired. Or we may decide that on q35 machines, 3 usb controllers will be automatically added when none is given. But for this initial commit, at least we aren't locking ourselves into something we later won't want. video - qemu always initializes the primary video device immediately after any integrated devices for the machinetype. Unless instructed otherwise (by using "-device vga..." instead of "-vga" which libvirt uses in many cases to work around deficiencies and bugs in various qemu versions) qemu will always pick the first unused slot. In the case of the "pc" machinetype and its derivatives, this is always slot 2, but on q35 machinetypes, the first free slot is slot 1 (since the q35's integrated peripheral devices are placed in other slots, e.g. slot 0x1f). In order to make the PCI address of the video device predictable, that slot (1 or 2, depending on machinetype) is reserved even when no video device has been specified. sata - a q35 machine always has a sata controller implicitly added at slot 0x1F, function 2. There is no way to avoid this controller, so we always add it. Note that the xml2xml tests for the pcie-root and q35 cases were changed to use DO_TEST_DIFFERENT() so that we can check for the sata controller being automatically added. This is especially important because we can't check for it in the xml2argv output (it has no effect on that output since it's an implicit device). ide - q35 has no ide controllers. isa and smbus controllers - these two are always present in a q35 (at slot 0x1F functions 0 and 3) but we have no way of modelling them in our config. We do need to reserve those functions so that the user doesn't attempt to put anything else there though. (note that the "pc" machine type also has an ISA controller, which we also ignore).
2013-08-02 08:55:55 +00:00
</video>
<memballoon model='none'/>
</devices>
</domain>
Reference in New Issue Copy Permalink