Re: [PATCH v3 0/6] PCI hostdev partial assignment support

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On 12/11/19 8:49 PM, Cole Robinson wrote:
On 11/26/19 8:33 AM, Daniel Henrique Barboza wrote:
changes from previous version [1]:
[...]

One comment

Daniel Henrique Barboza (6):
   Introducing new address type='unassigned' for PCI hostdevs
   qemu: handle unassigned PCI hostdevs in command line and alias

Is there a specific reason to skip alias assign, beside it not being
needed for the command line? If it doesn't hurt, maybe we just keep it.
I don't have a strong argument for it though. If no one says anything
I'll leave it as is


The reason why I was skipping aliases was cosmetic due to QEMU command line.
I find it a bit odd that, in a scenario with 4 functions where function 1 is
unassigned, QEMU cmd line would have hostdev0, hostdev2 and hostdev3, because
'hostdev1' alias got assigned to the unassigned function '1'

I don't have any strong feelings about this though. We can keep giving aliases
or all functions, regardless of whether they are being assigned to the
guest or not. Unit tests will need to be adjusted though.




   virhostdev.c: check all IOMMU devs in virHostdevPreparePCIDevices
   formatdomain.html.in: document <address type='unassigned'/>

For the first 4 I'll give it a few days and push on Friday if no one
complains.

For the last two:

   utils: PCI multifunction detection helpers
   domain_conf.c: don't allow function zero to be unassigned

The domain_conf.c additions should go into the
virDomainHostdevDefValidate. But this validation check seems to actually
read from host PCI space. I'm not sure if that's a good idea to do for
every XML parse? What's the failure scenario without this error message?
Does it fail in an obvious way? If so, maybe it's better to side step
the issue and just let it fail if it's a valid configuration.

This is a strange scenario TBH. I discussed it a bit with Alex Williamson in
the v2 of this series. At first there is nothing wrong with this, in fact
QEMU allows it. Problem is that Power guests handle this case in a "better" way
than x86 and others, making the non-zero function being visible and usable
by the guest without any extra kernel option (x86 needs pci_scan_all). It's
also hardware dependent - the BCM5719 network card I am using for testing
deals with this scenario, but there's no guarantee that other cards will.

To answer your question directly: this might not fail in an obvious way in
the guest, but it's not like this feature is a default PCI assignment
mode - the user have to deliberately unassigned the function 0 in the XML.
Granted, I am being conservative with this extra check - we can simply let
the user play with the configuration and, in case it blows up, the user
can simply add function 0 back to the guest. If this turns out to be a
"toxic" setup then I can go to QEMU and deal with it there - I mean, in the
end it's QEMU that allows this, so makes sense to handle the case down there.



Thanks,


DHB



Maybe laine knows better if there's precedent for similar checks at
Validate time

Thanks,
Cole


--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list




[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]

  Powered by Linux