On Fri, Jan 11, 2019 at 03:48:19PM +0100, Fabiano Fidêncio wrote: > Add basic support for Guest Features such as: > - acpi If the guest supports PCI, then it supports ACPI too. If the guest does not support ACPI there is no harm in exposing ACPI anyway, as the guest will just ignore it. If this were not the case, the x86 architecture would have broken all existing guest OS when it added ACPI support. > - apic I don't think you can even turn this off for KVM. It was something you could toggle with Xen but I can't remember when/why you would want to turn it off. > - cpu-hotplug This one feels useful. A mgmt app probably doesn't want to go to trouble to offering to allocate extra CPUs if it is impossible for guest to use them. > - numa Guest NUMA topology should be exposed if the guest is spread across more than one host NUMA node. If the guest chooses to ignore that topology, or simply doesn't know about reading NUMA topology, the guest still works in exactly the same way it would work if we didn't exposing NUMA topology at all. IOW, I dont really see what purpose/benefit this is giving. Guest NUMA can be used regardless of guest OS support for it. > - pci-device-hotplug I'm not convinced about this. Hotplug is a core feature of PCI. IOW pretty much any OS that has PCI support, will have hotplug support, unless their PCI support was crude-work-in-prgress. But even if they have hotplug support it doesn't imply it is going to work, as there are many ways to break it. noacpi kernel command line, no acpi property in guest XML, no acpid daemon running in guest, guest not finished booting up, device plugged into the wrong PCI bus and probably more. If we do need something here, it feels like we should have a more generic "pci" feature to indicate whether PCI is supported or not. Perhaps also a PCI-X feature flag, though even then it should be possible for a PCI-only guest to run a PCI-X machine IIUC, it just won't take advantage of PCI-X features. IOW, 'cpu-hotplug' is the only one here I see a strong compelling reason to support. > > The Guest Features are, by default, inherited by systems which either > clone or derive-from another systems. > > This series adds the machinery needed for: > https://gitlab.com/libosinfo/osinfo-db/issues/12 > > - Changes since v1: > https://www.redhat.com/archives/libosinfo/2018-November/msg00250.html > This is a totally *new* implementation as the v1 as *really* > *overcomplicated* and was adding pieces that were not needed at all > (as FeatureLinks and all the code refactoring done to accomodate > that). Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| _______________________________________________ Libosinfo mailing list Libosinfo@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libosinfo
