[PATCH] Support x-vga=on for PCI host passthrough devices

[Laine Stump]

On 10/7/20 5:44 PM, Steven Newbury wrote:
> On Wed, 2020-10-07 at 13:17 -0600, Alex Williamson wrote:
>> Are you aware that you can add arbitrary options to devices using the
>> <qemu:commandline> support in libvirt?  For example:
>>
>> <domain type='kvm' xmlns:qemu='
>> http://libvirt.org/schemas/domain/qemu/1.0'>
>>    ...
>>    <devices>
>>      ...
>>      <hostdev mode='subsystem' type='pci' managed='yes'>
>>        <source>
>>          <address domain='0x0000' bus='0x01' slot='0x00'
>> function='0x0'/>
>>        </source>
>>        <address type='pci' domain='0x0000' bus='0x01' slot='0x00'
>> function='0x0'/>
>>        <alias name='ua-geforce8800'/>
>>      </hostdev>
>>      ...
>>    </devices>
>>    <qemu:commandline>
>>      <qemu:arg value='-set'/>
>>      <qemu:arg value='device.ua-geforce8800.x-vga=on'/>
>>    </qemu:commandline>
>> </domain>
>>
>> This is generally how users make use of unsupportable or
>> not-yet-supported QEMU features while still using libvirt to manage
>> the
>> VM.
> I am aware of it, but I never managed to get virt-manager to accept
> arbitary command line arguments,


That should work with no problems, as long as you know where to put it.


If you go into the configuration for a guest (either during guest 
creation by clicking on "Customize configuration before install", or 
after creation by double clicking on the guest name then clicking on the 
"light bulb" icon at the upper left), click on "Overview" in the list on 
the left, then click on the "XML" tab above the right-hand side of the 
window (the default tab is "Details"), then you should be presented with 
the full XML for the guest. You'll need to do three things:


1) change the very top line of XML that currently says


    <domain type='kvm'>


to


   <domain xmlns:qemu="http://libvirt.org/schemas/domain/qemu/1.0" 
type="kvm">


2) In the middle of the XML, where you will find the <hostdev> element 
for your assigned GPU (similar to this example), add the line "<alias 
name="ua-video"/> as shown here:

   <hostdev mode="subsystem" type="pci" managed="no">
     <source>
       <address domain="0x0000" bus="0x05" slot="0x00" function="0x0"/>
     </source>
     <alias name="ua-video"/>
     <address type="pci" domain="0x0000" bus="0x05" slot="0x00" 
function="0x0" multifunction="on"/>
   </hostdev>

3) down at the bottom of the XML, just above the "</domain>" line, add this:

   <qemu:commandline>
     <qemu:arg value="-set"/>
     <qemu:arg value="device.ua-video.x-vga=on"/>
   </qemu:commandline>

Once you've made these 3 small changes, click on the "Apply" button.

>   but never persisted in trying to get
> it to work since it felt hackier than patching libvirt to accept the
> parameter.


It is *definitely* less hacky to use <qemu:commandline> than to carry 
your own local patch on top of the libvirt source, which would force you 
to always build your own libvirt binaries, and rebase your patch every 
time upstream libvirt changed code that touched the same place. Although 
<qemu:commandline> isn't "Supported" (Capital "S" - in the sense that a 
vendor providing paid technical support for a system using libvirt won't 
officially commit themselves to solving any problem you may have 
associated with use of <qemu:commandline>, and the options you provide 
there *could* disappear from qemu), it is "supported" (small "s" - in 
the sense that libvirt has no plans to remove <qemu:commandline>, and it 
is used by other people so if it becomes broken it will surely get fixed).


Using <qemu:commandline> will take 10 minutes of your time right now, 
and then you'll never have to think about it ever again (until/unless 
QEMU removes the x-vga option). Using your own custom build of libvirt 
that carries a locally written patch will continue to be a burden every 
time you upgrade libvirt until the end of time.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20201007/063f4e1b/attachment-0001.htm>