| Message ID | 20200804124417.27102-4-alex.bennee@linaro.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | put arm64 kvm_config on a diet | expand |
On 2020-08-04 13:44, Alex Bennée wrote: > The VIRTIO_PCI support is an idealised PCI bus, we don't need a bunch > of bloat for real world hardware for a VirtIO guest. Who says this guest will only have virtio devices? Or even, virtio devices without bugs? Given that said device can come from any VMM, I'm not sure this is the right thing to do. Thanks, M. > > Signed-off-by: Alex Bennée <alex.bennee@linaro.org> > --- > kernel/configs/kvm_guest.config | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/kernel/configs/kvm_guest.config > b/kernel/configs/kvm_guest.config > index 208481d91090..672863a2fdf1 100644 > --- a/kernel/configs/kvm_guest.config > +++ b/kernel/configs/kvm_guest.config > @@ -13,6 +13,7 @@ CONFIG_IP_PNP_DHCP=y > CONFIG_BINFMT_ELF=y > CONFIG_PCI=y > CONFIG_PCI_MSI=y > +CONFIG_PCI_QUIRKS=n > CONFIG_DEBUG_KERNEL=y > CONFIG_VIRTUALIZATION=y > CONFIG_HYPERVISOR_GUEST=y
Marc Zyngier <maz@kernel.org> writes: > On 2020-08-04 13:44, Alex Bennée wrote: >> The VIRTIO_PCI support is an idealised PCI bus, we don't need a bunch >> of bloat for real world hardware for a VirtIO guest. > > Who says this guest will only have virtio devices? This is true - although what is the point of kvm_guest.config? We certainly turn on a whole bunch of virt optimised pathways with PARAVIRT and HYPERVISOR_GUEST along with the rest of VirtIO. > Or even, virtio devices without bugs? Given that said device can > come from any VMM, I'm not sure this is the right thing to do. Perhaps this patch is one too far. I don't mind dropping it as long as I can still slim down the kernels I know don't need the extra bloat. > > Thanks, > > M. > >> >> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> >> --- >> kernel/configs/kvm_guest.config | 1 + >> 1 file changed, 1 insertion(+) >> >> diff --git a/kernel/configs/kvm_guest.config >> b/kernel/configs/kvm_guest.config >> index 208481d91090..672863a2fdf1 100644 >> --- a/kernel/configs/kvm_guest.config >> +++ b/kernel/configs/kvm_guest.config >> @@ -13,6 +13,7 @@ CONFIG_IP_PNP_DHCP=y >> CONFIG_BINFMT_ELF=y >> CONFIG_PCI=y >> CONFIG_PCI_MSI=y >> +CONFIG_PCI_QUIRKS=n >> CONFIG_DEBUG_KERNEL=y >> CONFIG_VIRTUALIZATION=y >> CONFIG_HYPERVISOR_GUEST=y
On 2020-08-04 15:44, Alex Bennée wrote: > Marc Zyngier <maz@kernel.org> writes: > >> On 2020-08-04 13:44, Alex Bennée wrote: >>> The VIRTIO_PCI support is an idealised PCI bus, we don't need a bunch >>> of bloat for real world hardware for a VirtIO guest. >> >> Who says this guest will only have virtio devices? > > This is true - although what is the point of kvm_guest.config? We > certainly turn on a whole bunch of virt optimised pathways with > PARAVIRT > and HYPERVISOR_GUEST along with the rest of VirtIO. Most of which actually qualifies as bloat itself as far as KVM/arm64 is concerned... M.
Marc Zyngier <maz@kernel.org> writes: > On 2020-08-04 15:44, Alex Bennée wrote: >> Marc Zyngier <maz@kernel.org> writes: >> >>> On 2020-08-04 13:44, Alex Bennée wrote: >>>> The VIRTIO_PCI support is an idealised PCI bus, we don't need a bunch >>>> of bloat for real world hardware for a VirtIO guest. >>> >>> Who says this guest will only have virtio devices? >> >> This is true - although what is the point of kvm_guest.config? We >> certainly turn on a whole bunch of virt optimised pathways with >> PARAVIRT >> and HYPERVISOR_GUEST along with the rest of VirtIO. > > Most of which actually qualifies as bloat itself as far as KVM/arm64 > is concerned... So here is the question - does the kernel care about having a blessed config for a minimal viable guest? They are certainly used in the cloud but I understand the kernel is trying to get away from having a zoo of configs. What is the actual point of kvm_guest.config? Just an easy enabling for developers? > > M.
On 2020-08-04 16:40, Alex Bennée wrote: > Marc Zyngier <maz@kernel.org> writes: > >> On 2020-08-04 15:44, Alex Bennée wrote: >>> Marc Zyngier <maz@kernel.org> writes: >>> >>>> On 2020-08-04 13:44, Alex Bennée wrote: >>>>> The VIRTIO_PCI support is an idealised PCI bus, we don't need a >>>>> bunch >>>>> of bloat for real world hardware for a VirtIO guest. >>>> >>>> Who says this guest will only have virtio devices? >>> >>> This is true - although what is the point of kvm_guest.config? We >>> certainly turn on a whole bunch of virt optimised pathways with >>> PARAVIRT >>> and HYPERVISOR_GUEST along with the rest of VirtIO. >> >> Most of which actually qualifies as bloat itself as far as KVM/arm64 >> is concerned... > > So here is the question - does the kernel care about having a blessed > config for a minimal viable guest? They are certainly used in the cloud > but I understand the kernel is trying to get away from having a zoo of > configs. What is the actual point of kvm_guest.config? Just an easy > enabling for developers? The cloud vendor I know certainly doesn't provide a "dumbed down" kernel configuration. What they run is either a distro kernel or something that fits their environment (which does include HW PCI devices, and hardly any virtio device). My take is that this kvm-special config isn't that useful in the real world, and I don't believe there is such thing as a "minimal viable guest" config, certainly not across architectures and VMMs. Hopefully it fits someone's development workflow, but that's probably it. M.
diff --git a/kernel/configs/kvm_guest.config b/kernel/configs/kvm_guest.config index 208481d91090..672863a2fdf1 100644 --- a/kernel/configs/kvm_guest.config +++ b/kernel/configs/kvm_guest.config @@ -13,6 +13,7 @@ CONFIG_IP_PNP_DHCP=y CONFIG_BINFMT_ELF=y CONFIG_PCI=y CONFIG_PCI_MSI=y +CONFIG_PCI_QUIRKS=n CONFIG_DEBUG_KERNEL=y CONFIG_VIRTUALIZATION=y CONFIG_HYPERVISOR_GUEST=y
The VIRTIO_PCI support is an idealised PCI bus, we don't need a bunch of bloat for real world hardware for a VirtIO guest. Signed-off-by: Alex Bennée <alex.bennee@linaro.org> --- kernel/configs/kvm_guest.config | 1 + 1 file changed, 1 insertion(+)