kernel/configs/kvm_guest.config | 2 ++ 1 file changed, 2 insertions(+)
This is used for VMs, so add it. It depends on FUSE_FS for the
implementation.
Signed-off-by: Brendan Jackman <jackmanb@google.com>
---
kernel/configs/kvm_guest.config | 2 ++
1 file changed, 2 insertions(+)
diff --git a/kernel/configs/kvm_guest.config b/kernel/configs/kvm_guest.config
index d0877063d925cd6db3136c9efd175669c1317131..86abe9de33bb2378ba0f7d46dbe4d84b49835506 100644
--- a/kernel/configs/kvm_guest.config
+++ b/kernel/configs/kvm_guest.config
@@ -33,3 +33,5 @@ CONFIG_SCSI_LOWLEVEL=y
CONFIG_SCSI_VIRTIO=y
CONFIG_VIRTIO_INPUT=y
CONFIG_DRM_VIRTIO_GPU=y
+CONFIG_FUSE_FS=y
+CONFIG_VIRTIO_FS=y
---
base-commit: eabcdba3ad4098460a376538df2ae36500223c1e
change-id: 20241220-kvm-config-virtiofs-64031a11144f
Best regards,
--
Brendan Jackman <jackmanb@google.com>
Am 20.12.24 um 15:07 schrieb Brendan Jackman: > This is used for VMs, so add it. It depends on FUSE_FS for the > implementation. > > Signed-off-by: Brendan Jackman <jackmanb@google.com> I think this makes sense given the usecases of make kvm_config. As of today we select 9pfs and virtiofs is clearly the better choice. Acked-by: Christian Borntraeger <borntraeger@linux.ibm.com> > --- > kernel/configs/kvm_guest.config | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/kernel/configs/kvm_guest.config b/kernel/configs/kvm_guest.config > index d0877063d925cd6db3136c9efd175669c1317131..86abe9de33bb2378ba0f7d46dbe4d84b49835506 100644 > --- a/kernel/configs/kvm_guest.config > +++ b/kernel/configs/kvm_guest.config > @@ -33,3 +33,5 @@ CONFIG_SCSI_LOWLEVEL=y > CONFIG_SCSI_VIRTIO=y > CONFIG_VIRTIO_INPUT=y > CONFIG_DRM_VIRTIO_GPU=y > +CONFIG_FUSE_FS=y > +CONFIG_VIRTIO_FS=y > > --- > base-commit: eabcdba3ad4098460a376538df2ae36500223c1e > change-id: 20241220-kvm-config-virtiofs-64031a11144f > > Best regards,
Hi Heiko/Vasily/Alexander, I don't see any obvious choice for a maintainer who would merge this. On Thu, 9 Jan 2025 at 13:46, Christian Borntraeger <borntraeger@linux.ibm.com> wrote: > Acked-by: Christian Borntraeger <borntraeger@linux.ibm.com> Given that Christian acked it, and it's pretty low-stakes and unlikely to conflict, would you perhaps take it through the S390 tree? Thanks, Brendan
On Thu, Jan 16, 2025 at 11:06:56AM +0100, Brendan Jackman wrote: > Hi Heiko/Vasily/Alexander, > > I don't see any obvious choice for a maintainer who would merge this. > > On Thu, 9 Jan 2025 at 13:46, Christian Borntraeger > <borntraeger@linux.ibm.com> wrote: > > Acked-by: Christian Borntraeger <borntraeger@linux.ibm.com> > > Given that Christian acked it, and it's pretty low-stakes and unlikely > to conflict, would you perhaps take it through the S390 tree? Given that this is kvm specific I would prefer if this goes via a kvm specific tree. E.g. kvm-s390 :) Which means Christian, Janosch, or Claudio should pick this up.
On Thu, Jan 16, 2025 at 11:27 AM Heiko Carstens <hca@linux.ibm.com> wrote: > On Thu, Jan 16, 2025 at 11:06:56AM +0100, Brendan Jackman wrote: > > Hi Heiko/Vasily/Alexander, > > > > I don't see any obvious choice for a maintainer who would merge this. > > > > On Thu, 9 Jan 2025 at 13:46, Christian Borntraeger > > <borntraeger@linux.ibm.com> wrote: > > > Acked-by: Christian Borntraeger <borntraeger@linux.ibm.com> > > > > Given that Christian acked it, and it's pretty low-stakes and unlikely > > to conflict, would you perhaps take it through the S390 tree? > > Given that this is kvm specific I would prefer if this goes via a kvm > specific tree. E.g. kvm-s390 :) Which means Christian, Janosch, or > Claudio should pick this up. I will apply it to the main KVM tree. Paolo
On Fri, 20 Dec 2024 at 15:07, Brendan Jackman <jackmanb@google.com> wrote: > > This is used for VMs, so add it. It depends on FUSE_FS for the > implementation. [Apologies for the duplicate mail, seems I accidentally switched HTML on in my GMail] Hi Paolo, happy new year. In the cold light of January I'm realising this is not really a "KVM change" so sending it to you was a bit of a random choice. But, it does say "KVM" in the name and nobody in particular seems to own it... so... what do you think?
© 2016 - 2025 Red Hat, Inc.