Right,
so I'm currently experimenting with my randconfig build scripts and
thought that maybe it would be a cool thing to not only do the random
builds only but also boot-test them in kvm. Which reminded me that we
have that KVMTOOL_TEST_ENABLE config option in the kvmtool with which we
can select all the stuff needed to boot the kernel in kvm.
So I copied it. I now have an all.config in the repo with
CONFIG_KVM_TEST_ENABLE=y in it so that the random builds can have the
required support.
So what do people think?
It is pretty helpful for such testing; AFAICT Fengguang is doing his
testing with kvm so he probably could use it too. And regardless, there
are more and more reasons to boot the kernel in kvm so having a single
option which selects the needed support makes more sense with time.
And I haven't picked up the 'make kvmconfig' functionality because it
is not strictly needed (yet) but it wouldn't hurt if we took it because
someone has a good reason for needing it.
Thanks.
--
>From efa9a7f7a460bc46d1dd37b691afa88070a34059 Mon Sep 17 00:00:00 2001
From: Borislav Petkov <[email protected]>
Date: Fri, 12 Apr 2013 20:01:47 +0200
Subject: [PATCH] x86: Add a Kconfig shortcut for a kvm-bootable kernel
This is pretty useful for the case where people want to boot the
resulting kernel in qemu/kvm. Instead of going and searching for each
required option through the Kconfig maze, this single option should
simply enable all stuff which is required to boot the resulting kernel
in the guest.
Originally-by: Pekka Enberg <[email protected]>
Originally-by: Sasha Levin <[email protected]>
Signed-off-by: Borislav Petkov <[email protected]>
Cc: Fengguang Wu <[email protected]>
---
arch/x86/Kconfig | 37 +++++++++++++++++++++++++++++++++++++
1 file changed, 37 insertions(+)
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 70c0f3da0476..3ca241172812 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -596,6 +596,43 @@ config SCHED_OMIT_FRAME_POINTER
If in doubt, say "Y".
+config KVM_TEST_ENABLE
+ bool "Enable options for a kernel suitable for testing in kvm"
+ select NET
+ select NETDEVICES
+ select PCI
+ select BLOCK
+ select BLK_DEV
+ select NETWORK_FILESYSTEMS
+ select INET
+ select EXPERIMENTAL
+ select TTY
+ select SERIAL_8250
+ select SERIAL_8250_CONSOLE
+ select IP_PNP
+ select IP_PNP_DHCP
+ select BINFMT_ELF
+ select PCI_MSI
+ select HAVE_ARCH_KGDB
+ select DEBUG_KERNEL
+ select KGDB
+ select KGDB_SERIAL_CONSOLE
+ select VIRTUALIZATION
+ select VIRTIO
+ select VIRTIO_RING
+ select VIRTIO_PCI
+ select VIRTIO_BLK
+ select VIRTIO_CONSOLE
+ select VIRTIO_NET
+ select 9P_FS
+ select NET_9P
+ select NET_9P_VIRTIO
+ ---help---
+ Select stuff which is required for booting the kernel as a guest
+ in qemu/kvm. This entails basic stuff like serial support, kgdb
+ 9p virtio and other basic functionality so that you can be able
+ to have serial output from the guest, networking, etc.
+
menuconfig PARAVIRT_GUEST
bool "Paravirtualized guest support"
---help---
--
1.8.2.135.g7b592fa
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
On 04/12/13 11:19, Borislav Petkov wrote:
> --
> From efa9a7f7a460bc46d1dd37b691afa88070a34059 Mon Sep 17 00:00:00 2001
> From: Borislav Petkov <[email protected]>
> Date: Fri, 12 Apr 2013 20:01:47 +0200
> Subject: [PATCH] x86: Add a Kconfig shortcut for a kvm-bootable kernel
>
> This is pretty useful for the case where people want to boot the
> resulting kernel in qemu/kvm. Instead of going and searching for each
> required option through the Kconfig maze, this single option should
> simply enable all stuff which is required to boot the resulting kernel
> in the guest.
>
> Originally-by: Pekka Enberg <[email protected]>
> Originally-by: Sasha Levin <[email protected]>
> Signed-off-by: Borislav Petkov <[email protected]>
> Cc: Fengguang Wu <[email protected]>
> ---
> arch/x86/Kconfig | 37 +++++++++++++++++++++++++++++++++++++
> 1 file changed, 37 insertions(+)
>
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index 70c0f3da0476..3ca241172812 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -596,6 +596,43 @@ config SCHED_OMIT_FRAME_POINTER
>
> If in doubt, say "Y".
>
> +config KVM_TEST_ENABLE
> + bool "Enable options for a kernel suitable for testing in kvm"
> + select NET
> + select NETDEVICES
> + select PCI
> + select BLOCK
> + select BLK_DEV
> + select NETWORK_FILESYSTEMS
> + select INET
> + select EXPERIMENTAL
> + select TTY
> + select SERIAL_8250
> + select SERIAL_8250_CONSOLE
> + select IP_PNP
> + select IP_PNP_DHCP
> + select BINFMT_ELF
> + select PCI_MSI
> + select HAVE_ARCH_KGDB
> + select DEBUG_KERNEL
> + select KGDB
> + select KGDB_SERIAL_CONSOLE
> + select VIRTUALIZATION
> + select VIRTIO
> + select VIRTIO_RING
> + select VIRTIO_PCI
> + select VIRTIO_BLK
> + select VIRTIO_CONSOLE
> + select VIRTIO_NET
> + select 9P_FS
> + select NET_9P
> + select NET_9P_VIRTIO
> + ---help---
> + Select stuff which is required for booting the kernel as a guest
> + in qemu/kvm. This entails basic stuff like serial support, kgdb
Use commas, please:
like serial support, kgdb,
9p, virtio, and other basic ...
> + 9p virtio and other basic functionality so that you can be able
> + to have serial output from the guest, networking, etc.
> +
> menuconfig PARAVIRT_GUEST
> bool "Paravirtualized guest support"
> ---help---
>
--
~Randy
Hello,
On 4/12/13 9:19 PM, Borislav Petkov wrote:
> so I'm currently experimenting with my randconfig build scripts and
> thought that maybe it would be a cool thing to not only do the random
> builds only but also boot-test them in kvm. Which reminded me that we
> have that KVMTOOL_TEST_ENABLE config option in the kvmtool with which we
> can select all the stuff needed to boot the kernel in kvm.
>
> So I copied it. I now have an all.config in the repo with
> CONFIG_KVM_TEST_ENABLE=y in it so that the random builds can have the
> required support.
>
> So what do people think?
>
> It is pretty helpful for such testing; AFAICT Fengguang is doing his
> testing with kvm so he probably could use it too. And regardless, there
> are more and more reasons to boot the kernel in kvm so having a single
> option which selects the needed support makes more sense with time.
>
> And I haven't picked up the 'make kvmconfig' functionality because it
> is not strictly needed (yet) but it wouldn't hurt if we took it because
> someone has a good reason for needing it.
I obviously support having something like this in mainline. I wonder
though if we could just call this "default standalone KVM guest config"
instead of emphasizing testing angle.
Pekka
On Sun, Apr 14, 2013 at 12:31:12PM +0300, Pekka Enberg wrote:
> I obviously support having something like this in mainline. I wonder
> though if we could just call this "default standalone KVM guest
> config" instead of emphasizing testing angle.
/me nods agreeingly...
And it should be unter HYPERVISOR_GUEST where the rest of this stuff
resides. Good point.
Thanks.
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
On Sun, Apr 14, 2013 at 01:03:20PM +0200, Borislav Petkov wrote:
> On Sun, Apr 14, 2013 at 12:31:12PM +0300, Pekka Enberg wrote:
> > I obviously support having something like this in mainline. I wonder
> > though if we could just call this "default standalone KVM guest
> > config" instead of emphasizing testing angle.
>
> /me nods agreeingly...
>
> And it should be unter HYPERVISOR_GUEST where the rest of this stuff
> resides. Good point.
Sanity check question:
Why not add the select stuff, i.e. this:
select NET
select NETDEVICES
select PCI
select BLOCK
select BLK_DEV
select NETWORK_FILESYSTEMS
select INET
select EXPERIMENTAL
select TTY
select SERIAL_8250
select SERIAL_8250_CONSOLE
select IP_PNP
select IP_PNP_DHCP
select BINFMT_ELF
select PCI_MSI
select HAVE_ARCH_KGDB
select DEBUG_KERNEL
select KGDB
select KGDB_SERIAL_CONSOLE
select VIRTUALIZATION
select VIRTIO
select VIRTIO_RING
select VIRTIO_PCI
select VIRTIO_BLK
select VIRTIO_CONSOLE
select VIRTIO_NET
select 9P_FS
select NET_9P
select NET_9P_VIRTIO
to the option below which we already have. It is in the same sense a KVM
guest support deal.
Hmm.
KVM people, any objections?
config KVM_GUEST
bool "KVM Guest support (including kvmclock)"
depends on PARAVIRT
select PARAVIRT_CLOCK
default y
---help---
This option enables various optimizations for running under the KVM
hypervisor. It includes a paravirtualized clock, so that instead
of relying on a PIT (or probably other) emulation by the
underlying device model, the host provides the guest with
timing infrastructure such as time of day, and system time
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
On 04/16/2013 12:18 PM, Borislav Petkov wrote:
> On Sun, Apr 14, 2013 at 01:03:20PM +0200, Borislav Petkov wrote:
>> On Sun, Apr 14, 2013 at 12:31:12PM +0300, Pekka Enberg wrote:
>>> I obviously support having something like this in mainline. I wonder
>>> though if we could just call this "default standalone KVM guest
>>> config" instead of emphasizing testing angle.
>>
>> /me nods agreeingly...
>>
>> And it should be unter HYPERVISOR_GUEST where the rest of this stuff
>> resides. Good point.
>
> Sanity check question:
>
> Why not add the select stuff, i.e. this:
>
> select NET
> select NETDEVICES
> select PCI
> select BLOCK
> select BLK_DEV
> select NETWORK_FILESYSTEMS
> select INET
> select EXPERIMENTAL
> select TTY
> select SERIAL_8250
> select SERIAL_8250_CONSOLE
> select IP_PNP
> select IP_PNP_DHCP
> select BINFMT_ELF
> select PCI_MSI
> select HAVE_ARCH_KGDB
> select DEBUG_KERNEL
> select KGDB
> select KGDB_SERIAL_CONSOLE
> select VIRTUALIZATION
> select VIRTIO
> select VIRTIO_RING
> select VIRTIO_PCI
> select VIRTIO_BLK
> select VIRTIO_CONSOLE
> select VIRTIO_NET
> select 9P_FS
> select NET_9P
> select NET_9P_VIRTIO
>
> to the option below which we already have. It is in the same sense a KVM
> guest support deal.
>
> Hmm.
>
> KVM people, any objections?
>
> config KVM_GUEST
> bool "KVM Guest support (including kvmclock)"
> depends on PARAVIRT
> select PARAVIRT_CLOCK
> default y
> ---help---
> This option enables various optimizations for running under the KVM
> hypervisor. It includes a paravirtualized clock, so that instead
> of relying on a PIT (or probably other) emulation by the
> underlying device model, the host provides the guest with
> timing infrastructure such as time of day, and system time
KVM guests don't need a serial device, KGDB, DEBUG_KERNEL or 9p in particular.
Thanks,
Sasha
On Tue, Apr 16, 2013 at 08:38:56PM -0400, Sasha Levin wrote:
> > select NET
> > select NETDEVICES
> > select PCI
> > select BLOCK
> > select BLK_DEV
> > select NETWORK_FILESYSTEMS
> > select INET
> > select EXPERIMENTAL
> > select TTY
> > select SERIAL_8250
> > select SERIAL_8250_CONSOLE
> > select IP_PNP
> > select IP_PNP_DHCP
> > select BINFMT_ELF
> > select PCI_MSI
> > select HAVE_ARCH_KGDB
> > select DEBUG_KERNEL
> > select KGDB
> > select KGDB_SERIAL_CONSOLE
> > select VIRTUALIZATION
> > select VIRTIO
> > select VIRTIO_RING
> > select VIRTIO_PCI
> > select VIRTIO_BLK
> > select VIRTIO_CONSOLE
> > select VIRTIO_NET
> > select 9P_FS
> > select NET_9P
> > select NET_9P_VIRTIO
> >
> > to the option below which we already have. It is in the same sense a KVM
> > guest support deal.
> >
> > Hmm.
> >
> > KVM people, any objections?
> >
> > config KVM_GUEST
> > bool "KVM Guest support (including kvmclock)"
> > depends on PARAVIRT
> > select PARAVIRT_CLOCK
> > default y
> > ---help---
> > This option enables various optimizations for running under the KVM
> > hypervisor. It includes a paravirtualized clock, so that instead
> > of relying on a PIT (or probably other) emulation by the
> > underlying device model, the host provides the guest with
> > timing infrastructure such as time of day, and system time
>
> KVM guests don't need a serial device, KGDB, DEBUG_KERNEL or 9p in particular.
Let's see:
* we need serial device for catching serial output on the host from the guest
kernel
* KGDB - I guess this was meant to jump into the debugger when the guest crashes
or so, we could drop it.
* DEBUG_KERNEL is also good for testing kernels
* 9p is needed for -virtfs folder sharing, AFAICT: http://wiki.qemu.org/Documentation/9psetup
So, I guess we can have another KVM_GUEST_KERNEL_TESTING option which
enables those additional, good for debugging options (except 9p - it
should be in the main thing) and which depends on KVM_GUEST. It would also
contain other DEBUG_* stuff.
Thanks.
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
On Tue, Apr 16, 2013 at 06:18:52PM +0200, Borislav Petkov wrote:
> On Sun, Apr 14, 2013 at 01:03:20PM +0200, Borislav Petkov wrote:
> > On Sun, Apr 14, 2013 at 12:31:12PM +0300, Pekka Enberg wrote:
> > > I obviously support having something like this in mainline. I wonder
> > > though if we could just call this "default standalone KVM guest
> > > config" instead of emphasizing testing angle.
> >
> > /me nods agreeingly...
> >
> > And it should be unter HYPERVISOR_GUEST where the rest of this stuff
> > resides. Good point.
>
> Sanity check question:
>
> Why not add the select stuff, i.e. this:
>
> select NET
> select NETDEVICES
> select PCI
> select BLOCK
> select BLK_DEV
> select NETWORK_FILESYSTEMS
> select INET
> select EXPERIMENTAL
> select TTY
> select SERIAL_8250
> select SERIAL_8250_CONSOLE
> select IP_PNP
> select IP_PNP_DHCP
> select BINFMT_ELF
> select PCI_MSI
> select HAVE_ARCH_KGDB
> select DEBUG_KERNEL
> select KGDB
> select KGDB_SERIAL_CONSOLE
> select VIRTUALIZATION
> select VIRTIO
> select VIRTIO_RING
> select VIRTIO_PCI
> select VIRTIO_BLK
> select VIRTIO_CONSOLE
> select VIRTIO_NET
> select 9P_FS
> select NET_9P
> select NET_9P_VIRTIO
>
> to the option below which we already have. It is in the same sense a KVM
> guest support deal.
>
> Hmm.
>
> KVM people, any objections?
None, but please don't mix it with 'KVM_GUEST' flag below.
Actually, what about adding kvm variants of the two files at
arch/x86/configs/ ?
> config KVM_GUEST
> bool "KVM Guest support (including kvmclock)"
> depends on PARAVIRT
> select PARAVIRT_CLOCK
> default y
> ---help---
> This option enables various optimizations for running under the KVM
> hypervisor. It includes a paravirtualized clock, so that instead
> of relying on a PIT (or probably other) emulation by the
> underlying device model, the host provides the guest with
> timing infrastructure such as time of day, and system time
On Wed, Apr 17, 2013 at 08:25:07PM -0300, Marcelo Tosatti wrote:
> On Tue, Apr 16, 2013 at 06:18:52PM +0200, Borislav Petkov wrote:
> > On Sun, Apr 14, 2013 at 01:03:20PM +0200, Borislav Petkov wrote:
> > > On Sun, Apr 14, 2013 at 12:31:12PM +0300, Pekka Enberg wrote:
> > > > I obviously support having something like this in mainline. I wonder
> > > > though if we could just call this "default standalone KVM guest
> > > > config" instead of emphasizing testing angle.
> > >
> > > /me nods agreeingly...
> > >
> > > And it should be unter HYPERVISOR_GUEST where the rest of this stuff
> > > resides. Good point.
> >
> > Sanity check question:
> >
> > Why not add the select stuff, i.e. this:
> >
> > select NET
> > select NETDEVICES
> > select PCI
> > select BLOCK
> > select BLK_DEV
> > select NETWORK_FILESYSTEMS
> > select INET
> > select EXPERIMENTAL
> > select TTY
> > select SERIAL_8250
> > select SERIAL_8250_CONSOLE
> > select IP_PNP
> > select IP_PNP_DHCP
> > select BINFMT_ELF
> > select PCI_MSI
> > select HAVE_ARCH_KGDB
> > select DEBUG_KERNEL
> > select KGDB
> > select KGDB_SERIAL_CONSOLE
> > select VIRTUALIZATION
> > select VIRTIO
> > select VIRTIO_RING
> > select VIRTIO_PCI
> > select VIRTIO_BLK
> > select VIRTIO_CONSOLE
> > select VIRTIO_NET
> > select 9P_FS
> > select NET_9P
> > select NET_9P_VIRTIO
> >
> > to the option below which we already have. It is in the same sense a KVM
> > guest support deal.
> >
> > Hmm.
> >
> > KVM people, any objections?
>
> None, but please don't mix it with 'KVM_GUEST' flag below.
>
> Actually, what about adding kvm variants of the two files at
> arch/x86/configs/ ?
two files?
>
> > config KVM_GUEST
> > bool "KVM Guest support (including kvmclock)"
> > depends on PARAVIRT
> > select PARAVIRT_CLOCK
> > default y
> > ---help---
> > This option enables various optimizations for running under the KVM
> > hypervisor. It includes a paravirtualized clock, so that instead
> > of relying on a PIT (or probably other) emulation by the
> > underlying device model, the host provides the guest with
> > timing infrastructure such as time of day, and system time
Hmm,
ok, maybe I wasn't clear enough. My proposal was to actually add all (or
maybe not *all* of them, but most) those selects above to the KVM_GUEST
config option. Because, you very probably want to select all that stuff
above anyway if you want to build a kvm guest kernel, no?
IOW, something which says "Enable KVM guest support" should enable all
the stuff needed for that.
Or do you want to keep the current CONFIG_KVM_GUEST separate for special
stuff?
And yes, Sasha's suggestion to have an additional
CONFIG_KVM_GUEST_KERNEL_TESTING or so option which enables debug
stuff for people who write patches for the kernel and want to quickly
smoke-test it in kvm.
Basically, I'm looking from the perspective of a kernel dev who would
like to make an optimal use of kvm for testing kernels.
Does that make more sense?
Thanks.
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
On Thu, Apr 18, 2013 at 11:46 AM, Borislav Petkov <[email protected]> wrote:
> ok, maybe I wasn't clear enough. My proposal was to actually add all (or
> maybe not *all* of them, but most) those selects above to the KVM_GUEST
> config option. Because, you very probably want to select all that stuff
> above anyway if you want to build a kvm guest kernel, no?
>
> IOW, something which says "Enable KVM guest support" should enable all
> the stuff needed for that.
"needed" yes,
"probably" no, as there's no way to disable them if they're selected
unconditionally.
Perhaps you can make the "probably" selects depend on !EXPERT to fix this?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
On Thu, Apr 18, 2013 at 11:55:33AM +0200, Geert Uytterhoeven wrote:
> On Thu, Apr 18, 2013 at 11:46 AM, Borislav Petkov <[email protected]> wrote:
> > ok, maybe I wasn't clear enough. My proposal was to actually add all (or
> > maybe not *all* of them, but most) those selects above to the KVM_GUEST
> > config option. Because, you very probably want to select all that stuff
> > above anyway if you want to build a kvm guest kernel, no?
> >
> > IOW, something which says "Enable KVM guest support" should enable all
> > the stuff needed for that.
>
> "needed" yes,
> "probably" no, as there's no way to disable them if they're selected
> unconditionally.
>
> Perhaps you can make the "probably" selects depend on !EXPERT to fix this?
Nah, I don't want to really involve EXPERT here. You could point,
though, which are the ones one probably won't select even though it
would be good to have them on and I could stick them in the second,
kernel testing option.
IOW, The way it currently shapes up is this:
* CONFIG_KVM_GUEST - maybe not change it at all, depending on what kvm
people want in the end.
* CONFIG_KVM_KERNEL_TESTING - all the things you would - probably or
really - need selected so that you don't go and hunt Kconfig options
just so the damn guest kernel boots. And not only that but also
convenience stuff like debugging options and such so that you have the
chance of getting some more info when the guest dies.
That second option is to be enabled when building the guest kernel only,
of course.
Better?
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
On Thu, Apr 18, 2013 at 11:46:29AM +0200, Borislav Petkov wrote:
> On Wed, Apr 17, 2013 at 08:25:07PM -0300, Marcelo Tosatti wrote:
> > On Tue, Apr 16, 2013 at 06:18:52PM +0200, Borislav Petkov wrote:
> > > On Sun, Apr 14, 2013 at 01:03:20PM +0200, Borislav Petkov wrote:
> > > > On Sun, Apr 14, 2013 at 12:31:12PM +0300, Pekka Enberg wrote:
> > > > > I obviously support having something like this in mainline. I wonder
> > > > > though if we could just call this "default standalone KVM guest
> > > > > config" instead of emphasizing testing angle.
> > > >
> > > > /me nods agreeingly...
> > > >
> > > > And it should be unter HYPERVISOR_GUEST where the rest of this stuff
> > > > resides. Good point.
> > >
> > > Sanity check question:
> > >
> > > Why not add the select stuff, i.e. this:
> > >
> > > select NET
> > > select NETDEVICES
> > > select PCI
> > > select BLOCK
> > > select BLK_DEV
> > > select NETWORK_FILESYSTEMS
> > > select INET
> > > select EXPERIMENTAL
> > > select TTY
> > > select SERIAL_8250
> > > select SERIAL_8250_CONSOLE
> > > select IP_PNP
> > > select IP_PNP_DHCP
> > > select BINFMT_ELF
> > > select PCI_MSI
> > > select HAVE_ARCH_KGDB
> > > select DEBUG_KERNEL
> > > select KGDB
> > > select KGDB_SERIAL_CONSOLE
> > > select VIRTUALIZATION
> > > select VIRTIO
> > > select VIRTIO_RING
> > > select VIRTIO_PCI
> > > select VIRTIO_BLK
> > > select VIRTIO_CONSOLE
> > > select VIRTIO_NET
> > > select 9P_FS
> > > select NET_9P
> > > select NET_9P_VIRTIO
> > >
> > > to the option below which we already have. It is in the same sense a KVM
> > > guest support deal.
> > >
> > > Hmm.
> > >
> > > KVM people, any objections?
> >
> > None, but please don't mix it with 'KVM_GUEST' flag below.
> >
> > Actually, what about adding kvm variants of the two files at
> > arch/x86/configs/ ?
>
> two files?
x86_64, x86_32.
> >
> > > config KVM_GUEST
> > > bool "KVM Guest support (including kvmclock)"
> > > depends on PARAVIRT
> > > select PARAVIRT_CLOCK
> > > default y
> > > ---help---
> > > This option enables various optimizations for running under the KVM
> > > hypervisor. It includes a paravirtualized clock, so that instead
> > > of relying on a PIT (or probably other) emulation by the
> > > underlying device model, the host provides the guest with
> > > timing infrastructure such as time of day, and system time
>
> Hmm,
>
> ok, maybe I wasn't clear enough. My proposal was to actually add all (or
> maybe not *all* of them, but most) those selects above to the KVM_GUEST
> config option. Because, you very probably want to select all that stuff
> above anyway if you want to build a kvm guest kernel, no?
Very probably but not certainly.
> IOW, something which says "Enable KVM guest support" should enable all
> the stuff needed for that.
I get your point, but thats up to the person selecting the options.
> Or do you want to keep the current CONFIG_KVM_GUEST separate for special
> stuff?
Yes.
> And yes, Sasha's suggestion to have an additional
> CONFIG_KVM_GUEST_KERNEL_TESTING or so option which enables debug
> stuff for people who write patches for the kernel and want to quickly
> smoke-test it in kvm.
Thats fine.
> Basically, I'm looking from the perspective of a kernel dev who would
> like to make an optimal use of kvm for testing kernels.
>
> Does that make more sense?
Understood (just don't mix it with the current CONFIG_KVM_GUEST option).
Even though can't see why those options can live in defconfig files as
suggested.
On Thu, Apr 18, 2013 at 10:36:31AM -0300, Marcelo Tosatti wrote:
> > IOW, something which says "Enable KVM guest support" should enable all
> > the stuff needed for that.
>
> I get your point, but thats up to the person selecting the options.
Ok.
> > Or do you want to keep the current CONFIG_KVM_GUEST separate for special
> > stuff?
>
> Yes.
Ok.
> > Basically, I'm looking from the perspective of a kernel dev who would
> > like to make an optimal use of kvm for testing kernels.
> >
> > Does that make more sense?
>
> Understood (just don't mix it with the current CONFIG_KVM_GUEST option).
Ok, got it - we want those additional options in another Kconfig option,
probably depending on KVM_GUEST.
> Even though can't see why those options can live in defconfig files as
> suggested.
Well, for one, some of the options are already in the defconfig files.
However, you want to have a single shortcut option which selects those
when building randconfigs and trying to boot them in kvm. I.e., you want
some basic functionality to be always present, even with randconfigs.
And you won't have that functionality enabled if you put them in a
defconfig, AFAICT.
Now, I do that already in my tests by having those and other options in
an all.config file in the kernel repo which gets parsed by Kconfig.
The reason for adding this to the kernel though was to save other people
the time of looking for all those options everytime but have one single
shortcut. Which can also be updated by kvm people whenever they feel
like new guest kernel functionality should be enabled.
If people still feel like this is not a good idea, I can drop it. But it
makes a bunch of sense to me, currently at least :).
Thanks.
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
From: Borislav Petkov <[email protected]>
Date: Tue, 16 Apr 2013 18:24:34 +0200
Subject: [PATCH -v2] x86: Add a Kconfig shortcut for kvm guest kernel
This is pretty useful for the case where people want to boot the
resulting kernel in qemu/kvm. Instead of going and searching for each
required option through the Kconfig maze, this single option should
simply enable everything required/good to have to boot the resulting
kernel in the guest.
Cc: Fengguang Wu <[email protected]>
Originally-by: Pekka Enberg <[email protected]>
Originally-by: Sasha Levin <[email protected]>
Signed-off-by: Borislav Petkov <[email protected]>
---
Here's v2 which should be addressing all review comments so far.
arch/x86/Kconfig | 38 ++++++++++++++++++++++++++++++++++++++
1 file changed, 38 insertions(+)
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 5651374d179f..76a95ffa959a 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -680,6 +680,44 @@ config KVM_GUEST
underlying device model, the host provides the guest with
timing infrastructure such as time of day, and system time
+config KVM_GUEST_COMMODITY_OPTIONS
+ bool "Enable commodity options for a standalone KVM guest"
+ depends on KVM_GUEST
+ select NET
+ select NETDEVICES
+ select BLOCK
+ select BLK_DEV
+ select NETWORK_FILESYSTEMS
+ select INET
+ select EXPERIMENTAL
+ select TTY
+ select SERIAL_8250
+ select SERIAL_8250_CONSOLE
+ select IP_PNP
+ select IP_PNP_DHCP
+ select BINFMT_ELF
+ select PCI_MSI
+ select HAVE_ARCH_KGDB
+ select DEBUG_KERNEL
+ select KGDB
+ select KGDB_SERIAL_CONSOLE
+ select VIRTUALIZATION
+ select VIRTIO
+ select VIRTIO_RING
+ select VIRTIO_PCI
+ select VIRTIO_BLK
+ select VIRTIO_CONSOLE
+ select VIRTIO_NET
+ select 9P_FS
+ select NET_9P
+ select NET_9P_VIRTIO
+ ---help---
+ Select guest kernel functionality which facilitates booting the
+ kernel as a guest in qemu/kvm. This entails basic stuff like
+ serial support, kgdb, virtio and other so that you can be able to
+ have commodity functionality like serial output from the guest,
+ networking, etc.
+
source "arch/x86/lguest/Kconfig"
config PARAVIRT_TIME_ACCOUNTING
--
1.8.2.135.g7b592fa
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
* Borislav Petkov <[email protected]> wrote:
> From: Borislav Petkov <[email protected]>
> Date: Tue, 16 Apr 2013 18:24:34 +0200
> Subject: [PATCH -v2] x86: Add a Kconfig shortcut for kvm guest kernel
>
> This is pretty useful for the case where people want to boot the
> resulting kernel in qemu/kvm. Instead of going and searching for each
> required option through the Kconfig maze, this single option should
> simply enable everything required/good to have to boot the resulting
> kernel in the guest.
Please mention:
' This patch is based on a similar utility patch of the external
lkvm tree. '
>
> Cc: Fengguang Wu <[email protected]>
> Originally-by: Pekka Enberg <[email protected]>
> Originally-by: Sasha Levin <[email protected]>
> Signed-off-by: Borislav Petkov <[email protected]>
> ---
>
>
> Here's v2 which should be addressing all review comments so far.
>
>
> arch/x86/Kconfig | 38 ++++++++++++++++++++++++++++++++++++++
> 1 file changed, 38 insertions(+)
>
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index 5651374d179f..76a95ffa959a 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -680,6 +680,44 @@ config KVM_GUEST
> underlying device model, the host provides the guest with
> timing infrastructure such as time of day, and system time
>
> +config KVM_GUEST_COMMODITY_OPTIONS
Call this KVM_GUEST_COMMON_OPTIONS?
> + bool "Enable commodity options for a standalone KVM guest"
> + depends on KVM_GUEST
> + select NET
> + select NETDEVICES
> + select BLOCK
> + select BLK_DEV
> + select NETWORK_FILESYSTEMS
> + select INET
> + select EXPERIMENTAL
> + select TTY
> + select SERIAL_8250
> + select SERIAL_8250_CONSOLE
> + select IP_PNP
> + select IP_PNP_DHCP
> + select BINFMT_ELF
> + select PCI_MSI
> + select HAVE_ARCH_KGDB
> + select DEBUG_KERNEL
> + select KGDB
> + select KGDB_SERIAL_CONSOLE
> + select VIRTUALIZATION
> + select VIRTIO
> + select VIRTIO_RING
> + select VIRTIO_PCI
> + select VIRTIO_BLK
> + select VIRTIO_CONSOLE
> + select VIRTIO_NET
> + select 9P_FS
> + select NET_9P
> + select NET_9P_VIRTIO
> + ---help---
> + Select guest kernel functionality which facilitates booting the
> + kernel as a guest in qemu/kvm. This entails basic stuff like
s/qemu/qemu or lkvm
> + serial support, kgdb, virtio and other so that you can be able to
> + have commodity functionality like serial output from the guest,
> + networking, etc.
And seemless host file system integration into guest context. (that is
what the 9P options are about)
Thanks,
Ingo
On Fri, Apr 26, 2013 at 08:42:50AM +0200, Ingo Molnar wrote:
>
> ... < take all review comments >
Here it is:
--
>From 56880e448600ca1504df8c68c59f31153f7b5b0f Mon Sep 17 00:00:00 2001
From: Borislav Petkov <[email protected]>
Date: Tue, 16 Apr 2013 18:24:34 +0200
Subject: [PATCH -v2.1] x86: Add a Kconfig shortcut for kvm guest kernel
This is pretty useful for the case where people want to boot the
resulting kernel in qemu/kvm or lkvm. Instead of going and searching for
each required option through the Kconfig maze, this single option should
simply enable everything required/good to have to boot the resulting
kernel in the guest.
Patch has been adapted from a version in the external lkvm tree.
Cc: Fengguang Wu <[email protected]>
Originally-by: Pekka Enberg <[email protected]>
Originally-by: Sasha Levin <[email protected]>
Signed-off-by: Borislav Petkov <[email protected]>
---
arch/x86/Kconfig | 39 +++++++++++++++++++++++++++++++++++++++
1 file changed, 39 insertions(+)
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 5651374d179f..432478a7b814 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -680,6 +680,45 @@ config KVM_GUEST
underlying device model, the host provides the guest with
timing infrastructure such as time of day, and system time
+config KVM_GUEST_COMMON_OPTIONS
+ bool "Enable commodity options for a standalone KVM guest"
+ depends on KVM_GUEST
+ select NET
+ select NETDEVICES
+ select BLOCK
+ select BLK_DEV
+ select NETWORK_FILESYSTEMS
+ select INET
+ select EXPERIMENTAL
+ select TTY
+ select SERIAL_8250
+ select SERIAL_8250_CONSOLE
+ select IP_PNP
+ select IP_PNP_DHCP
+ select BINFMT_ELF
+ select PCI_MSI
+ select HAVE_ARCH_KGDB
+ select DEBUG_KERNEL
+ select KGDB
+ select KGDB_SERIAL_CONSOLE
+ select VIRTUALIZATION
+ select VIRTIO
+ select VIRTIO_RING
+ select VIRTIO_PCI
+ select VIRTIO_BLK
+ select VIRTIO_CONSOLE
+ select VIRTIO_NET
+ select 9P_FS
+ select NET_9P
+ select NET_9P_VIRTIO
+ ---help---
+ Select guest kernel functionality which facilitates booting the
+ kernel as a guest in qemu or lkvm. This entails basic stuff like
+ serial support, kgdb, virtio and other so that you can be able to
+ have commodity functionality like serial output from the guest,
+ networking, seamless host file system integration into guest context
+ and other useful things.
+
source "arch/x86/lguest/Kconfig"
config PARAVIRT_TIME_ACCOUNTING
--
1.8.2.135.g7b592fa
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
Commit-ID: 83aee67833071c7b73a83f7803388f7a9e481908
Gitweb: http://git.kernel.org/tip/83aee67833071c7b73a83f7803388f7a9e481908
Author: Borislav Petkov <[email protected]>
AuthorDate: Fri, 26 Apr 2013 11:51:40 +0200
Committer: Ingo Molnar <[email protected]>
CommitDate: Tue, 30 Apr 2013 11:00:11 +0200
x86/kconfig: Add a Kconfig shortcut for building working KVM guest kernels
This is pretty useful for the case where people want to boot the
resulting kernel in qemu/kvm or lkvm. Instead of going and
searching for each required option through the Kconfig maze,
this single option should simply enable everything required/good
to have to boot the resulting kernel in the guest.
Patch has been adapted from a version in the external lkvm tree.
Originally-by: Pekka Enberg <[email protected]>
Originally-by: Sasha Levin <[email protected]>
Signed-off-by: Borislav Petkov <[email protected]>
Cc: Marcelo Tosatti <[email protected]>
Cc: Pekka Enberg <[email protected]>
Cc: Sasha Levin <[email protected]>
Cc: Fengguang Wu <[email protected]>
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Ingo Molnar <[email protected]>
---
arch/x86/Kconfig | 39 +++++++++++++++++++++++++++++++++++++++
1 file changed, 39 insertions(+)
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 15b5cef..1d053dc 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -633,6 +633,45 @@ config KVM_GUEST
underlying device model, the host provides the guest with
timing infrastructure such as time of day, and system time
+config KVM_GUEST_COMMON_OPTIONS
+ bool "Enable commodity options for a standalone KVM guest"
+ depends on KVM_GUEST
+ select NET
+ select NETDEVICES
+ select BLOCK
+ select BLK_DEV
+ select NETWORK_FILESYSTEMS
+ select INET
+ select EXPERIMENTAL
+ select TTY
+ select SERIAL_8250
+ select SERIAL_8250_CONSOLE
+ select IP_PNP
+ select IP_PNP_DHCP
+ select BINFMT_ELF
+ select PCI_MSI
+ select HAVE_ARCH_KGDB
+ select DEBUG_KERNEL
+ select KGDB
+ select KGDB_SERIAL_CONSOLE
+ select VIRTUALIZATION
+ select VIRTIO
+ select VIRTIO_RING
+ select VIRTIO_PCI
+ select VIRTIO_BLK
+ select VIRTIO_CONSOLE
+ select VIRTIO_NET
+ select 9P_FS
+ select NET_9P
+ select NET_9P_VIRTIO
+ ---help---
+ Select guest kernel functionality which facilitates booting the
+ kernel as a guest in qemu or lkvm. This entails basic stuff like
+ serial support, kgdb, virtio and other so that you can be able to
+ have commodity functionality like serial output from the guest,
+ networking, seamless host file system integration into guest context
+ and other useful things.
+
source "arch/x86/lguest/Kconfig"
config PARAVIRT
On Tue, 30 Apr 2013, tip-bot for Borislav Petkov wrote:
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index 15b5cef..1d053dc 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -633,6 +633,45 @@ config KVM_GUEST
> underlying device model, the host provides the guest with
> timing infrastructure such as time of day, and system time
>
> +config KVM_GUEST_COMMON_OPTIONS
> + bool "Enable commodity options for a standalone KVM guest"
> + depends on KVM_GUEST
> + select NET
> + select NETDEVICES
> + select BLOCK
> + select BLK_DEV
> + select NETWORK_FILESYSTEMS
> + select INET
> + select EXPERIMENTAL
> + select TTY
> + select SERIAL_8250
> + select SERIAL_8250_CONSOLE
> + select IP_PNP
> + select IP_PNP_DHCP
> + select BINFMT_ELF
> + select PCI_MSI
> + select HAVE_ARCH_KGDB
> + select DEBUG_KERNEL
> + select KGDB
> + select KGDB_SERIAL_CONSOLE
> + select VIRTUALIZATION
> + select VIRTIO
> + select VIRTIO_RING
> + select VIRTIO_PCI
> + select VIRTIO_BLK
> + select VIRTIO_CONSOLE
> + select VIRTIO_NET
> + select 9P_FS
> + select NET_9P
> + select NET_9P_VIRTIO
> + ---help---
> + Select guest kernel functionality which facilitates booting the
> + kernel as a guest in qemu or lkvm. This entails basic stuff like
> + serial support, kgdb, virtio and other so that you can be able to
> + have commodity functionality like serial output from the guest,
> + networking, seamless host file system integration into guest context
> + and other useful things.
> +
> source "arch/x86/lguest/Kconfig"
>
> config PARAVIRT
This causes
warning: (KVM_GUEST_COMMON_OPTIONS && AMD_IOMMU) selects PCI_MSI which has unmet direct dependencies (PCI && ARCH_SUPPORTS_MSI)
warning: (KVM_GUEST_COMMON_OPTIONS) selects VIRTIO_PCI which has unmet direct dependencies (PCI)
in linux-next which results in
drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c: In function ‘ixgbevf_request_msix_irqs’:
drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c:911:10: error: invalid use of undefined type ‘struct msix_entry’
drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c:911:52: error: dereferencing pointer to incomplete type
drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c:927:26: error: dereferencing pointer to incomplete type
drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c:937:2: error: invalid use of undefined type ‘struct msix_entry’
drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c:937:41: error: dereferencing pointer to incomplete type
drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c:950:3: error: invalid use of undefined type ‘struct msix_entry’
drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c:950:33: error: dereferencing pointer to incomplete type
drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c: In function ‘ixgbevf_free_irq’:
drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c:1007:2: error: invalid use of undefined type ‘struct msix_entry’
drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c:1007:32: error: dereferencing pointer to incomplete type
drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c:1016:3: error: invalid use of undefined type ‘struct msix_entry’
drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c:1016:33: error: dereferencing pointer to incomplete type
drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c: In function ‘ixgbevf_irq_disable’
drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c:1039:3: error: invalid use of undefined type ‘struct msix_entry’
drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c:1039:40: error: dereferencing pointer to incomplete type
drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c: In function ‘ixgbevf_acquire_msix_vectors’:
drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c:1767:3: error: implicit declaration of function ‘pci_enable_msix’ [-Werror=implicit-function-declaration]
drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c: In function ‘ixgbevf_set_interrupt_capability’:
drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c:1887:13: error: invalid application of ‘sizeof’ to incomplete type ‘struct msix_entry’
drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c:1894:3: error: invalid use of undefined type ‘struct msix_entry’
drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c:1894:24: error: dereferencing pointer to incomplete type
drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c: In function ‘ixgbevf_reset_interrupt_capability’:
drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c:1976:2: error: implicit declaration of function ‘pci_disable_msix’ [-Werror=implicit-function-declaration]
drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c: In function ‘ixgbevf_resume’:
drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c:3212:2: error: implicit declaration of function ‘pci_enable_device_mem’ [-Werror=implicit-function-declaration]
since KVM_GUEST_COMMON_OPTIONS selects PCI_MSI without selecting PCI.
If we select PCI in KVM_GUEST_COMMON_OPTIONS, we get:
arch/x86/Kconfig:651:error: recursive dependency detected!
arch/x86/Kconfig:651: symbol KVM_GUEST_COMMON_OPTIONS depends on HYPERVISOR_GUEST
arch/x86/Kconfig:597: symbol HYPERVISOR_GUEST is selected by X86_VSMP
arch/x86/Kconfig:388: symbol X86_VSMP depends on PCI
arch/x86/Kconfig:2042: symbol PCI is selected by KVM_GUEST_COMMON_OPTIONS
On Wed, May 01, 2013 at 12:53:03PM -0700, David Rientjes wrote:
> since KVM_GUEST_COMMON_OPTIONS selects PCI_MSI without selecting PCI.
>
> If we select PCI in KVM_GUEST_COMMON_OPTIONS, we get:
>
> arch/x86/Kconfig:651:error: recursive dependency detected!
> arch/x86/Kconfig:651: symbol KVM_GUEST_COMMON_OPTIONS depends on HYPERVISOR_GUEST
> arch/x86/Kconfig:597: symbol HYPERVISOR_GUEST is selected by X86_VSMP
> arch/x86/Kconfig:388: symbol X86_VSMP depends on PCI
> arch/x86/Kconfig:2042: symbol PCI is selected by KVM_GUEST_COMMON_OPTIONS
Well, this was the reason why I dropped CONFIG_PCI from
KVM_GUEST_COMMON_OPTIONS in the first place - to not have the circular
dependency splat above and assuming that people simply have CONFIG_PCI
enabled already.
Well, off the top of my head, we could do the following; I'd need to
hammer on it for a while though before it feels ok with all that Kconfig
jumble. Unless someone has a better idea, of course...
---
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index e8fff2f4ecb7..4f8ef85b0633 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -389,7 +389,8 @@ config X86_VSMP
bool "ScaleMP vSMP"
select HYPERVISOR_GUEST
select PARAVIRT
- depends on X86_64 && PCI
+ select PCI
+ depends on X86_64
depends on X86_EXTENDED_PLATFORM
depends on SMP
---help---
@@ -664,6 +665,7 @@ config KVM_GUEST_COMMON_OPTIONS
select IP_PNP
select IP_PNP_DHCP
select BINFMT_ELF
+ select PCI
select PCI_MSI
select HAVE_ARCH_KGDB
select DEBUG_KERNEL
--
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
On Wed, 1 May 2013, Borislav Petkov wrote:
> ---
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index e8fff2f4ecb7..4f8ef85b0633 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -389,7 +389,8 @@ config X86_VSMP
> bool "ScaleMP vSMP"
> select HYPERVISOR_GUEST
> select PARAVIRT
> - depends on X86_64 && PCI
> + select PCI
> + depends on X86_64
> depends on X86_EXTENDED_PLATFORM
> depends on SMP
> ---help---
> @@ -664,6 +665,7 @@ config KVM_GUEST_COMMON_OPTIONS
> select IP_PNP
> select IP_PNP_DHCP
> select BINFMT_ELF
> + select PCI
> select PCI_MSI
> select HAVE_ARCH_KGDB
> select DEBUG_KERNEL
With this applied, two other types of conflicting dependencies:
warning: (KVM_GUEST_COMMON_OPTIONS) selects VIRTIO_NET which has unmet direct dependencies (NETDEVICES && NET_CORE && VIRTIO)
and
warning: (KVM_GUEST_COMMON_OPTIONS && AMD_IOMMU) selects PCI_MSI which has unmet direct dependencies (PCI && ARCH_SUPPORTS_MSI)
On Wed, May 01, 2013 at 02:00:06PM -0700, David Rientjes wrote:
> With this applied, two other types of conflicting dependencies:
>
> warning: (KVM_GUEST_COMMON_OPTIONS) selects VIRTIO_NET which has unmet direct dependencies (NETDEVICES && NET_CORE && VIRTIO)
>
> and
>
> warning: (KVM_GUEST_COMMON_OPTIONS && AMD_IOMMU) selects PCI_MSI which has unmet direct dependencies (PCI && ARCH_SUPPORTS_MSI)
How do you trigger those? I don't see them here with this applied.
Thanks.
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
On Wed, 1 May 2013, Borislav Petkov wrote:
> > warning: (KVM_GUEST_COMMON_OPTIONS) selects VIRTIO_NET which has unmet direct dependencies (NETDEVICES && NET_CORE && VIRTIO)
> >
> > and
> >
> > warning: (KVM_GUEST_COMMON_OPTIONS && AMD_IOMMU) selects PCI_MSI which has unmet direct dependencies (PCI && ARCH_SUPPORTS_MSI)
>
> How do you trigger those? I don't see them here with this applied.
>
It's an allnoconfig with HYPERVISOR_GUEST, PARAVIRT, KVM_GUEST, and
KVM_GUEST_COMMON_OPTIONS enabled.
On Wed, May 01, 2013 at 02:30:05PM -0700, David Rientjes wrote:
> It's an allnoconfig with HYPERVISOR_GUEST, PARAVIRT, KVM_GUEST, and
> KVM_GUEST_COMMON_OPTIONS enabled.
Hmm:
$ make mrproper
CLEAN scripts/basic
CLEAN scripts/kconfig
CLEAN include/config
CLEAN .config
$ make allnoconfig
HOSTCC scripts/basic/fixdep
SHIPPED scripts/kconfig/zconf.tab.c
SHIPPED scripts/kconfig/zconf.lex.c
HOSTCC scripts/kconfig/conf.o
SHIPPED scripts/kconfig/zconf.hash.c
HOSTCC scripts/kconfig/zconf.tab.o
HOSTLD scripts/kconfig/conf
scripts/kconfig/conf --allnoconfig Kconfig
#
# configuration written to .config
#
$ make menuconfig <--- select the options you mention above
HOSTCC scripts/kconfig/mconf.o
HOSTCC scripts/kconfig/lxdialog/checklist.o
HOSTCC scripts/kconfig/lxdialog/inputbox.o
HOSTCC scripts/kconfig/lxdialog/menubox.o
HOSTCC scripts/kconfig/lxdialog/textbox.o
HOSTCC scripts/kconfig/lxdialog/util.o
HOSTCC scripts/kconfig/lxdialog/yesno.o
HOSTLD scripts/kconfig/mconf
scripts/kconfig/mconf Kconfig
configuration written to .config
*** End of the configuration.
*** Execute 'make' to start the build or try 'make help'.
Nada. No warnings.
However, it doesn't build:
arch/x86/built-in.o:(.data+0x2a0): undefined reference to `native_setup_msi_irqs'
arch/x86/built-in.o:(.data+0x2a8): undefined reference to `native_teardown_msi_irq'
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
On Wed, 1 May 2013, Borislav Petkov wrote:
> $ make allnoconfig
> HOSTCC scripts/basic/fixdep
> SHIPPED scripts/kconfig/zconf.tab.c
> SHIPPED scripts/kconfig/zconf.lex.c
> HOSTCC scripts/kconfig/conf.o
> SHIPPED scripts/kconfig/zconf.hash.c
> HOSTCC scripts/kconfig/zconf.tab.o
> HOSTLD scripts/kconfig/conf
> scripts/kconfig/conf --allnoconfig Kconfig
> #
> # configuration written to .config
> #
> $ make menuconfig <--- select the options you mention above
menuconfig is going to give you defaults that the newly-enabled options
allow to be configured without you knowing. It's better to just flip
these options my hand and use make oldconfig (or yes "n" | make
oldconfig) to disable everything else that is now configurable.
This is done because we're addressing unmet dependency problems, so we'll
want to disable as much as allowed. Those dependencies are usually signs
of real build errors (as they were for the PCI problem) since we're
enabling options that don't have their prerequisites.
Unfortunately, the way you're implementing KVM_GUEST_COMMON_OPTIONS will
typically result in this if the options you "select" get new dependencies
in the future. So you'll always be updating this option constantly with
these types of problems.
I've attached the config that emits both these warnings (copy it as
.config and use make oldconfig) on top of today's linux-next and your
suggested patch.
The errors are rather straightforward, though: we aren't depending or
selecting on CONFIG_NET_CORE and ARCH_SUPPORTS_MSI.
On Wed, May 01, 2013 at 03:09:13PM -0700, David Rientjes wrote:
> Unfortunately, the way you're implementing KVM_GUEST_COMMON_OPTIONS
> will typically result in this if the options you "select" get new
> dependencies in the future. So you'll always be updating this option
> constantly with these types of problems.
Ok, so let's step back a bit here: I've added this option with the idea
to have it as a shortcut so that you don't go search for every commodity
option when you want to boot the kernel as a kvm guest. Currently I have
it in all.config when doing randconfig builds here. While I'm doing the
randbuilds, why not boot it in kvm too while at it.
Now, I really fail to see what you describe above to be a fairly normal
use case. I'm sure you can take Kconfig and abuse it so that it screams
all kinds of errors and we know select is evil and Kconfig is not
perfect, etc, etc...
So I'm pretty sure we won't be able to plug all holes. However, let's
try to plug only those which hinder *real* usage instead of contrived
stuff.
So, let's start again: is this something real you're triggering
with some random testing you're doing or are you simply
abusing^Wexperimenting with Kconfig and staring at what breaks?
Thanks.
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
On Thu, 2 May 2013, Borislav Petkov wrote:
> Ok, so let's step back a bit here: I've added this option with the idea
> to have it as a shortcut so that you don't go search for every commodity
> option when you want to boot the kernel as a kvm guest. Currently I have
> it in all.config when doing randconfig builds here. While I'm doing the
> randbuilds, why not boot it in kvm too while at it.
>
If that shortcut is enabling options that fail to build, it may not be
considered so useful.
> So I'm pretty sure we won't be able to plug all holes. However, let's
> try to plug only those which hinder *real* usage instead of contrived
> stuff.
>
It's contrived to not have CONFIG_NET_CORE enabled?
And why are you enabling CONFIG_PCI_MSI for systems that don't have
ARCH_SUPPORTS_MSI? You need CONFIG_X86_LOCAL_APIC and CONFIG_X86_IO_APIC.
So let's take a step back from your step back: you want to have a shortcut
to build a guest. Great, so you're enabling options that such a kernel
needs. The problem is that you're neglecting options that those options
need. It means your patch is incomplete.
On Wed, May 01, 2013 at 03:37:28PM -0700, David Rientjes wrote:
> It means your patch is incomplete.
I'll gladly test and ack a patch which makes it complete.
Simple exercises in rhetoric about what does and what doesn't make sense
means a rat's ass to me. You need to show me a *real* use case which you
*actually* hit and this patch breaks it.
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
On 05/01/2013 04:02 PM, Borislav Petkov wrote:
> On Wed, May 01, 2013 at 03:37:28PM -0700, David Rientjes wrote:
>> It means your patch is incomplete.
>
> I'll gladly test and ack a patch which makes it complete.
>
> Simple exercises in rhetoric about what does and what doesn't make sense
> means a rat's ass to me. You need to show me a *real* use case which you
> *actually* hit and this patch breaks it.
>
The fundamental problem is that "select" is broken and doesn't track
dependencies of things selected.
-hpa
On Wed, May 01, 2013 at 04:04:12PM -0700, H. Peter Anvin wrote:
> The fundamental problem is that "select" is broken and doesn't track
> dependencies of things selected.
Yep, ancient history.
And yet, I'm using this option to do randconfig builds and then boot
them and I see almost no build breakages, at least none caused by this
Kconfig option.
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
On Thu, 2 May 2013, Borislav Petkov wrote:
> > It means your patch is incomplete.
>
> I'll gladly test and ack a patch which makes it complete.
>
> Simple exercises in rhetoric about what does and what doesn't make sense
> means a rat's ass to me. You need to show me a *real* use case which you
> *actually* hit and this patch breaks it.
>
What makes sense = a build that works.
You reported the breakage yourself:
arch/x86/built-in.o:(.data+0x2a0): undefined reference to `native_setup_msi_irqs'
arch/x86/built-in.o:(.data+0x2a8): undefined reference to `native_teardown_msi_irq'
That's because of this:
warning: (KVM_GUEST_COMMON_OPTIONS && AMD_IOMMU) selects PCI_MSI which has unmet direct dependencies (PCI && ARCH_SUPPORTS_MSI)
So you're missing CONFIG_X86_LOCAL_APIC and/or CONFIG_X86_IO_APIC, as
already stated. Those are strict requirements for your
CONFIG_KVM_GUEST_COMMON_OPTIONS to build. I suggest depending on them,
most configs already have them.
You'll probably also want to depend on NET_CORE since it requires that as
well.
That would probably make your patch complete. Ingo does a lot of
randconfig testing himself, so he'll probably run into these same issues,
I don't think the "aww, shucks, that config doesn't make sense, we can
allow the build to break" excuse will work too well.
On 05/01/2013 04:09 PM, Borislav Petkov wrote:
> On Wed, May 01, 2013 at 04:04:12PM -0700, H. Peter Anvin wrote:
>> The fundamental problem is that "select" is broken and doesn't track
>> dependencies of things selected.
>
> Yep, ancient history.
>
> And yet, I'm using this option to do randconfig builds and then boot
> them and I see almost no build breakages, at least none caused by this
> Kconfig option.
>
Stupid question: would a defconfig be a better option for this?
-hpa
On Fri, Apr 26, 2013 at 11:51:40AM +0200, Borislav Petkov wrote:
> On Fri, Apr 26, 2013 at 08:42:50AM +0200, Ingo Molnar wrote:
> >
> > ... < take all review comments >
>
> Here it is:
>
> --
> >From 56880e448600ca1504df8c68c59f31153f7b5b0f Mon Sep 17 00:00:00 2001
> From: Borislav Petkov <[email protected]>
> Date: Tue, 16 Apr 2013 18:24:34 +0200
> Subject: [PATCH -v2.1] x86: Add a Kconfig shortcut for kvm guest kernel
>
> This is pretty useful for the case where people want to boot the
> resulting kernel in qemu/kvm or lkvm. Instead of going and searching for
> each required option through the Kconfig maze, this single option should
> simply enable everything required/good to have to boot the resulting
> kernel in the guest.
>
> Patch has been adapted from a version in the external lkvm tree.
>
> Cc: Fengguang Wu <[email protected]>
> Originally-by: Pekka Enberg <[email protected]>
> Originally-by: Sasha Levin <[email protected]>
> Signed-off-by: Borislav Petkov <[email protected]>
> ---
> arch/x86/Kconfig | 39 +++++++++++++++++++++++++++++++++++++++
> 1 file changed, 39 insertions(+)
Applied, thanks.
On Wed, May 01, 2013 at 10:19:24AM -0300, Marcelo Tosatti wrote:
> Applied, thanks.
You shouldn't have - Ingo took it already.
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
On Wed, May 01, 2013 at 04:16:38PM -0700, H. Peter Anvin wrote:
> Stupid question: would a defconfig be a better option for this?
Yep, Marcelo suggested this already but you need to have this option
enabled (either in 'all.config' in the kernel directory or select it by
hand) when doing randconfigs and then booting them in kvm.
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
On Wed, May 01, 2013 at 04:16:40PM -0700, David Rientjes wrote:
> So you're missing CONFIG_X86_LOCAL_APIC and/or CONFIG_X86_IO_APIC,
> as already stated. Those are strict requirements for your
> CONFIG_KVM_GUEST_COMMON_OPTIONS to build. I suggest depending on them,
> most configs already have them.
>
> You'll probably also want to depend on NET_CORE since it requires that
> as well.
>
> That would probably make your patch complete.
See, we could've saved ourselves all the bullshit if you had started
with the above.
I'll add those to the lineup:
select PCI
select NET_CORE
select X86_IO_APIC
select X86_LOCAL_APIC
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
On Thu, 2 May 2013, Borislav Petkov wrote:
> See, we could've saved ourselves all the bullshit if you had started
> with the above.
>
I had thought
warning: (KVM_GUEST_COMMON_OPTIONS && AMD_IOMMU) selects PCI_MSI which has unmet direct dependencies (PCI && ARCH_SUPPORTS_MSI)
was obvious.
> I'll add those to the lineup:
>
> select PCI
> select NET_CORE
> select X86_IO_APIC
> select X86_LOCAL_APIC
>
No, you want to depend on X86_IO_APIC and X86_LOCAL_APIC, otherwise you'll
just face the same issue one level deeper.
* H. Peter Anvin <[email protected]> wrote:
> On 05/01/2013 04:02 PM, Borislav Petkov wrote:
> > On Wed, May 01, 2013 at 03:37:28PM -0700, David Rientjes wrote:
> >> It means your patch is incomplete.
> >
> > I'll gladly test and ack a patch which makes it complete.
> >
> > Simple exercises in rhetoric about what does and what doesn't make
> > sense means a rat's ass to me. You need to show me a *real* use case
> > which you *actually* hit and this patch breaks it.
>
> The fundamental problem is that "select" is broken and doesn't track
> dependencies of things selected.
The way I've been solving it in a similar usecase was to select the
required options - plus its dependencies, manually.
That should be possible here as well, driven by any weird randconfig build
failures that get found. Such a set of selects quickly converges.
Thanks,
Ingo
* David Rientjes <[email protected]> wrote:
> On Wed, 1 May 2013, Borislav Petkov wrote:
>
> > > warning: (KVM_GUEST_COMMON_OPTIONS) selects VIRTIO_NET which has unmet direct dependencies (NETDEVICES && NET_CORE && VIRTIO)
> > >
> > > and
> > >
> > > warning: (KVM_GUEST_COMMON_OPTIONS && AMD_IOMMU) selects PCI_MSI which has unmet direct dependencies (PCI && ARCH_SUPPORTS_MSI)
> >
> > How do you trigger those? I don't see them here with this applied.
> >
>
> It's an allnoconfig with HYPERVISOR_GUEST, PARAVIRT, KVM_GUEST, and
> KVM_GUEST_COMMON_OPTIONS enabled.
Please send a specific .config instead, with which you see warnings or
build failures.
Thanks,
Ingo
On Thu, 2 May 2013, Ingo Molnar wrote:
> > It's an allnoconfig with HYPERVISOR_GUEST, PARAVIRT, KVM_GUEST, and
> > KVM_GUEST_COMMON_OPTIONS enabled.
>
> Please send a specific .config instead, with which you see warnings or
> build failures.
>
Attached from my earlier email to Borislav on lkml.
Commit-ID: 7e0320e733eec67e40d2b53e438d9971f079862d
Gitweb: http://git.kernel.org/tip/7e0320e733eec67e40d2b53e438d9971f079862d
Author: Borislav Petkov <[email protected]>
AuthorDate: Fri, 26 Apr 2013 11:51:40 +0200
Committer: H. Peter Anvin <[email protected]>
CommitDate: Thu, 2 May 2013 10:13:07 -0700
x86/kconfig: Add a Kconfig shortcut for building working KVM guest kernels
This is pretty useful for the case where people want to boot the
resulting kernel in qemu/kvm or lkvm. Instead of going and
searching for each required option through the Kconfig maze,
this single option should simply enable everything required/good
to have to boot the resulting kernel in the guest.
Patch has been adapted from a version in the external lkvm tree.
[ hpa: rebased to resolve a merge conflict ]
Originally-by: Pekka Enberg <[email protected]>
Originally-by: Sasha Levin <[email protected]>
Signed-off-by: Borislav Petkov <[email protected]>
Cc: Marcelo Tosatti <[email protected]>
Cc: Pekka Enberg <[email protected]>
Cc: Sasha Levin <[email protected]>
Cc: Fengguang Wu <[email protected]>
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Ingo Molnar <[email protected]>
Signed-off-by: H. Peter Anvin <[email protected]>
---
arch/x86/Kconfig | 39 +++++++++++++++++++++++++++++++++++++++
1 file changed, 39 insertions(+)
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 5db2117..f724671f 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -649,6 +649,45 @@ config KVM_GUEST
underlying device model, the host provides the guest with
timing infrastructure such as time of day, and system time
+config KVM_GUEST_COMMON_OPTIONS
+ bool "Enable commodity options for a standalone KVM guest"
+ depends on KVM_GUEST
+ select NET
+ select NETDEVICES
+ select BLOCK
+ select BLK_DEV
+ select NETWORK_FILESYSTEMS
+ select INET
+ select EXPERIMENTAL
+ select TTY
+ select SERIAL_8250
+ select SERIAL_8250_CONSOLE
+ select IP_PNP
+ select IP_PNP_DHCP
+ select BINFMT_ELF
+ select PCI_MSI
+ select HAVE_ARCH_KGDB
+ select DEBUG_KERNEL
+ select KGDB
+ select KGDB_SERIAL_CONSOLE
+ select VIRTUALIZATION
+ select VIRTIO
+ select VIRTIO_RING
+ select VIRTIO_PCI
+ select VIRTIO_BLK
+ select VIRTIO_CONSOLE
+ select VIRTIO_NET
+ select 9P_FS
+ select NET_9P
+ select NET_9P_VIRTIO
+ ---help---
+ Select guest kernel functionality which facilitates booting the
+ kernel as a guest in qemu or lkvm. This entails basic stuff like
+ serial support, kgdb, virtio and other so that you can be able to
+ have commodity functionality like serial output from the guest,
+ networking, seamless host file system integration into guest context
+ and other useful things.
+
source "arch/x86/lguest/Kconfig"
config PARAVIRT_TIME_ACCOUNTING
On 05/02/2013 12:06 AM, Ingo Molnar wrote:
>
> * H. Peter Anvin <[email protected]> wrote:
>
>> On 05/01/2013 04:02 PM, Borislav Petkov wrote:
>>> On Wed, May 01, 2013 at 03:37:28PM -0700, David Rientjes wrote:
>>>> It means your patch is incomplete.
>>>
>>> I'll gladly test and ack a patch which makes it complete.
>>>
>>> Simple exercises in rhetoric about what does and what doesn't make
>>> sense means a rat's ass to me. You need to show me a *real* use case
>>> which you *actually* hit and this patch breaks it.
>>
>> The fundamental problem is that "select" is broken and doesn't track
>> dependencies of things selected.
>
> The way I've been solving it in a similar usecase was to select the
> required options - plus its dependencies, manually.
>
> That should be possible here as well, driven by any weird randconfig build
> failures that get found. Such a set of selects quickly converges.
>
The problem is that it is a moving target. We really need a
dependency-resolving version of select.
-hpa
On Thu, 2 May 2013, tip-bot for Borislav Petkov wrote:
> Commit-ID: 7e0320e733eec67e40d2b53e438d9971f079862d
> Gitweb: http://git.kernel.org/tip/7e0320e733eec67e40d2b53e438d9971f079862d
> Author: Borislav Petkov <[email protected]>
> AuthorDate: Fri, 26 Apr 2013 11:51:40 +0200
> Committer: H. Peter Anvin <[email protected]>
> CommitDate: Thu, 2 May 2013 10:13:07 -0700
>
> x86/kconfig: Add a Kconfig shortcut for building working KVM guest kernels
>
> This is pretty useful for the case where people want to boot the
> resulting kernel in qemu/kvm or lkvm. Instead of going and
> searching for each required option through the Kconfig maze,
> this single option should simply enable everything required/good
> to have to boot the resulting kernel in the guest.
>
> Patch has been adapted from a version in the external lkvm tree.
>
> [ hpa: rebased to resolve a merge conflict ]
>
> Originally-by: Pekka Enberg <[email protected]>
> Originally-by: Sasha Levin <[email protected]>
> Signed-off-by: Borislav Petkov <[email protected]>
> Cc: Marcelo Tosatti <[email protected]>
> Cc: Pekka Enberg <[email protected]>
> Cc: Sasha Levin <[email protected]>
> Cc: Fengguang Wu <[email protected]>
> Link: http://lkml.kernel.org/r/[email protected]
> Signed-off-by: Ingo Molnar <[email protected]>
> Signed-off-by: H. Peter Anvin <[email protected]>
Hi Peter,
You'll also need http://marc.info/?l=linux-kernel&m=136744052328802 when
Borislav signs it off as it fixes one of the dependencies. Still waiting
on how X86_IO_APIC, X86_LOCAL_APIC, and NET_CORE will be resolved.
On 05/02/2013 11:06 AM, David Rientjes wrote:
>
> Hi Peter,
>
> You'll also need http://marc.info/?l=linux-kernel&m=136744052328802 when
> Borislav signs it off as it fixes one of the dependencies. Still waiting
> on how X86_IO_APIC, X86_LOCAL_APIC, and NET_CORE will be resolved.
>
Hm.
Let's drop this one for right now. I need to queue up some actual
urgent fixes...
-hpa
On Thu, 2 May 2013, H. Peter Anvin wrote:
> Let's drop this one for right now. I need to queue up some actual
> urgent fixes...
>
Sounds good. I think what you eluded to earlier, a "select" that resolves
dependencies on the symbols it enables, would be the best way to implement
something like KVM_GUEST_COMMON_OPTIONS so that it doesn't pick up a
failure when an option it selects adds a new dependency. It would reduce
the size of this particular patch considerably and avoid constantly
updating its list.
* H. Peter Anvin <[email protected]> wrote:
> > That should be possible here as well, driven by any weird randconfig
> > build failures that get found. Such a set of selects quickly
> > converges.
>
> The problem is that it is a moving target. We really need a
> dependency-resolving version of select.
Dependencies are always a moving target - sometimes config names change,
new dependencies come in.
I've maintained a similar solution for years, and once the initial list of
selects has settled it's a low maintenance overhead thing.
Thanks,
Ingo
* H. Peter Anvin <[email protected]> wrote:
> On 05/02/2013 11:06 AM, David Rientjes wrote:
> >
> > Hi Peter,
> >
> > You'll also need http://marc.info/?l=linux-kernel&m=136744052328802 when
> > Borislav signs it off as it fixes one of the dependencies. Still waiting
> > on how X86_IO_APIC, X86_LOCAL_APIC, and NET_CORE will be resolved.
> >
>
> Hm.
Boris, mind posting a working version?
Thanks,
Ingo
On Thu, May 02, 2013 at 09:43:26PM +0200, Ingo Molnar wrote:
> Dependencies are always a moving target - sometimes config names
> change, new dependencies come in.
>
> I've maintained a similar solution for years, and once the initial
> list of selects has settled it's a low maintenance overhead thing.
Yeah, hpa's rebasing urgent anyway and he's taken it out so that I can
bake this a bit longer.
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
On Thu, May 02, 2013 at 09:45:56PM +0200, Ingo Molnar wrote:
> Boris, mind posting a working version?
Yeah, let's delay it for the next merge window - it looks like it needs
more experimenting and since it is not urgent enough...
FWIW, I did play a bit with it today and I ended up with the diff below
just to satisfy the CONFIG_PCI/MSI deps. However, if I want to shut them
all up, I need to pull in SMP, MODULE_UNLOAD, MODULE... and so on.
Which is kind of an overkill and I really don't want to do it.
I wonder if one can exclude options from randconfig until 'select' has
been taught to resolve dependencies...
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 9dae342fa6f6..4c826ea8dd29 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -390,9 +390,10 @@ config X86_VSMP
bool "ScaleMP vSMP"
select HYPERVISOR_GUEST
select PARAVIRT
- depends on X86_64 && PCI
+ select PCI
+ select SMP
+ depends on X86_64
depends on X86_EXTENDED_PLATFORM
- depends on SMP
---help---
Support for ScaleMP vSMP systems. Say 'Y' here if this kernel is
supposed to run on these EM64T-based machines. Only choose this option
@@ -685,6 +686,7 @@ config KVM_GUEST_COMMON_OPTIONS
bool "Enable commodity options for a standalone KVM guest"
depends on KVM_GUEST
select NET
+ select NET_CORE
select NETDEVICES
select BLOCK
select BLK_DEV
@@ -697,6 +699,12 @@ config KVM_GUEST_COMMON_OPTIONS
select IP_PNP
select IP_PNP_DHCP
select BINFMT_ELF
+# select SMP
+# select MODULE_UNLOAD
+ select X86_LOCAL_APIC
+ select X86_IO_APIC
+ select ARCH_SUPPORTS_MSI
+ select PCI
select PCI_MSI
select HAVE_ARCH_KGDB
select DEBUG_KERNEL
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
On Thu, May 02, 2013 at 10:07:03PM +0200, Borislav Petkov wrote:a
> I wonder if one can exclude options from randconfig until 'select' has
> been taught to resolve dependencies...
So I talked to Michal on IRC about the whole deal and the fact of the
matter is, unless someone steps up and rewrites the Kconfig solver so
that selects work as expected, this option would break whenever one
of those selected option's dependencies change or said option is made
configurable.
Which means, the next best thing would be to have a small file
somewhere, maybe in scripts/kconfig/ or so, called 'allrand.config' and
which has default settings for randconfig builds. It would have
# CONFIG_KVM_GUEST_COMMON_OPTIONS is not set
so that this option is always disabled in randconfigs.
Frankly, I much rather prefer this than going nuts and including every
possible dependency just so some obscure randconfigs don't break (that's
not the point of this option anyway); and then having to run around and
fix it once some of the selected option's dependencies change.
Opinions?
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
On 05/03/13 07:29, Borislav Petkov wrote:
> On Thu, May 02, 2013 at 10:07:03PM +0200, Borislav Petkov wrote:a
>> I wonder if one can exclude options from randconfig until 'select' has
>> been taught to resolve dependencies...
>
> So I talked to Michal on IRC about the whole deal and the fact of the
> matter is, unless someone steps up and rewrites the Kconfig solver so
> that selects work as expected, this option would break whenever one
> of those selected option's dependencies change or said option is made
> configurable.
>
> Which means, the next best thing would be to have a small file
> somewhere, maybe in scripts/kconfig/ or so, called 'allrand.config' and
> which has default settings for randconfig builds. It would have
>
> # CONFIG_KVM_GUEST_COMMON_OPTIONS is not set
>
> so that this option is always disabled in randconfigs.
>
> Frankly, I much rather prefer this than going nuts and including every
> possible dependency just so some obscure randconfigs don't break (that's
> not the point of this option anyway); and then having to run around and
> fix it once some of the selected option's dependencies change.
>
> Opinions?
Could you alternately have a kvm_guest.config that should always work
for you?
--
~Randy
On Fri, May 03, 2013 at 07:54:36AM -0700, Randy Dunlap wrote:
> Could you alternately have a kvm_guest.config that should always work
> for you?
I could, and I do. The idea, however, is to have this option upstream
so that people don't have to go search for every relevant option for
running the kernel a kvm guest.
Which reminds me: Pekka had a 'make kvmconfig' functionality in
the kvmtool too. Which, TBH, is even better than having a Kconfig
option with a bunch of selects. So, come to think of it, after all
the controversy with such an option, having a 'make kvmconfig' do
scripts/config -e <option> where <option> is in that list we select
would be much better.
This won't break randconfigs at all, btw. :-)
Michal?
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
We can put a config file upstream, too.
Borislav Petkov <[email protected]> wrote:
>On Fri, May 03, 2013 at 07:54:36AM -0700, Randy Dunlap wrote:
>> Could you alternately have a kvm_guest.config that should always work
>> for you?
>
>I could, and I do. The idea, however, is to have this option upstream
>so that people don't have to go search for every relevant option for
>running the kernel a kvm guest.
>
>Which reminds me: Pekka had a 'make kvmconfig' functionality in
>the kvmtool too. Which, TBH, is even better than having a Kconfig
>option with a bunch of selects. So, come to think of it, after all
>the controversy with such an option, having a 'make kvmconfig' do
>scripts/config -e <option> where <option> is in that list we select
>would be much better.
>
>This won't break randconfigs at all, btw. :-)
>
>Michal?
--
Sent from my mobile phone. Please excuse brevity and lack of formatting.
On 3.5.2013 17:08, Borislav Petkov wrote:
> On Fri, May 03, 2013 at 07:54:36AM -0700, Randy Dunlap wrote:
>> Could you alternately have a kvm_guest.config that should always work
>> for you?
>
> I could, and I do. The idea, however, is to have this option upstream
> so that people don't have to go search for every relevant option for
> running the kernel a kvm guest.
>
> Which reminds me: Pekka had a 'make kvmconfig' functionality in
> the kvmtool too. Which, TBH, is even better than having a Kconfig
> option with a bunch of selects. So, come to think of it, after all
> the controversy with such an option, having a 'make kvmconfig' do
> scripts/config -e <option> where <option> is in that list we select
> would be much better.
>
> This won't break randconfigs at all, btw. :-)
You still risk that you miss some new dependency, but for a normal
configs as a base, this won't be an issue in most cases. Whether this is
implemented as a series of scripts/config calls or if there is a
kvm_guest.config does not matter much, as long as randconfig does not
see it ;).
Michal
On Fri, May 03, 2013 at 05:10:15PM +0200, Michal Marek wrote:
> You still risk that you miss some new dependency, but for a normal
> configs as a base, this won't be an issue in most cases. Whether this is
> implemented as a series of scripts/config calls or if there is a
> kvm_guest.config does not matter much, as long as randconfig does not
> see it ;).
Yep, I think we can do something along the lines of what hpa suggested:
* put a kvm_guest.config in arch/x86/configs/
* teach scripts/config/ to parse it and do set_var() for each line in
there.
* yes "" | make oldconfig - because we want to use the current config
as a base.
I think this is the easiest and cleanest of them all.
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
On Fri, 3 May 2013, Borislav Petkov wrote:
> * yes "" | make oldconfig - because we want to use the current config
> as a base.
>
This will select options that you don't necessarily need but default to
enabled when they are selected from kvm_guest.config, so it will actually
include much more than what's needed for a kvm guest.
For minimal you'd probably use yes n | ...
David Rientjes <[email protected]> wrote:
>On Fri, 3 May 2013, Borislav Petkov wrote:
>
>> * yes "" | make oldconfig - because we want to use the current config
>> as a base.
>>
>
>This will select options that you don't necessarily need but default to
>
>enabled when they are selected from kvm_guest.config, so it will
>actually
>include much more than what's needed for a kvm guest.
--
Sent from my mobile phone. Please excuse brevity and lack of formatting.
On Fri, 3 May 2013, H. Peter Anvin wrote:
> For minimal you'd probably use yes n | ...
>
Works fine unless kvm_guest.config enables an option that requires a
numbered choice, such as CONFIG_EXPERT enabling the the ability to select
CONFIG_SLOB from the list of allocators. Instead of relying on yes(1),
I think you'll need to modify this custom script to explicitly disable
remaining options and select the default when there's a choice.
On 05/03/2013 10:19 AM, David Rientjes wrote:
>
> Works fine unless kvm_guest.config enables an option that requires a
> numbered choice, such as CONFIG_EXPERT enabling the the ability to select
> CONFIG_SLOB from the list of allocators. Instead of relying on yes(1),
> I think you'll need to modify this custom script to explicitly disable
> remaining options and select the default when there's a choice.
>
Actually it is called:
KCONFIG_ALLCONFIG=kvm_guest.config make allnoconfig
-hpa
On Fri, May 03, 2013 at 12:09:36PM -0700, H. Peter Anvin wrote:
> Actually it is called:
>
> KCONFIG_ALLCONFIG=kvm_guest.config make allnoconfig
I guess we can do something like this - it is kinda noisy currently and
requires a previously present .config in $objtree to work.
---
arch/x86/Makefile | 5 +++++
arch/x86/configs/kvm_guest.config | 28 ++++++++++++++++++++++++++++
2 files changed, 33 insertions(+)
create mode 100644 arch/x86/configs/kvm_guest.config
diff --git a/arch/x86/Makefile b/arch/x86/Makefile
index 5c477260294f..6f9c03ed999e 100644
--- a/arch/x86/Makefile
+++ b/arch/x86/Makefile
@@ -220,6 +220,11 @@ archclean:
$(Q)$(MAKE) $(clean)=$(boot)
$(Q)$(MAKE) $(clean)=arch/x86/tools
+kvmconfig:
+ $(if $(wildcard $(objtree)/.config),, $(error You need an existing .config for this target))
+ $(Q)$(CONFIG_SHELL) $(srctree)/scripts/kconfig/merge_config.sh -m -O $(objtree) $(objtree)/.config arch/x86/configs/kvm_guest.config
+ $(Q)yes "n" | $(MAKE) oldconfig
+
define archhelp
echo '* bzImage - Compressed kernel image (arch/x86/boot/bzImage)'
echo ' install - Install kernel using'
diff --git a/arch/x86/configs/kvm_guest.config b/arch/x86/configs/kvm_guest.config
new file mode 100644
index 000000000000..2ac38a390db3
--- /dev/null
+++ b/arch/x86/configs/kvm_guest.config
@@ -0,0 +1,28 @@
+CONFIG_NET=y
+CONFIG_NET_CORE=y
+CONFIG_NETDEVICES=y
+CONFIG_BLOCK=y
+CONFIG_BLK_DEV=y
+CONFIG_NETWORK_FILESYSTEMS=y
+CONFIG_INET=y
+CONFIG_TTY=y
+CONFIG_SERIAL_8250=y
+CONFIG_SERIAL_8250_CONSOLE=y
+CONFIG_IP_PNP=y
+CONFIG_IP_PNP_DHCP=y
+CONFIG_BINFMT_ELF=y
+CONFIG_PCI=y
+CONFIG_PCI_MSI=y
+CONFIG_HAVE_ARCH_KGDB=y
+CONFIG_DEBUG_KERNEL=y
+CONFIG_KGDB=y
+CONFIG_KGDB_SERIAL_CONSOLE=y
+CONFIG_VIRTUALIZATION=y
+CONFIG_VIRTIO=y
+CONFIG_VIRTIO_PCI=y
+CONFIG_VIRTIO_BLK=y
+CONFIG_VIRTIO_CONSOLE=y
+CONFIG_VIRTIO_NET=y
+CONFIG_9P_FS=y
+CONFIG_NET_9P=y
+CONFIG_NET_9P_VIRTIO=y
--
1.8.3.rc0
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
Add an config file snippet which enables additional options useful for
running the kernel in a kvm guest. When you execute 'make kvmconfig' it
merges those options with an already existing user config before you
build the kernel.
Based on an patch from the external lkvm tree.
Signed-off-by: Borislav Petkov <[email protected]>
---
So I've been running this for a while now and seems like the cleanest
solution to me ATM.
arch/x86/Makefile | 6 ++++++
arch/x86/configs/kvm_guest.config | 28 ++++++++++++++++++++++++++++
2 files changed, 34 insertions(+)
create mode 100644 arch/x86/configs/kvm_guest.config
diff --git a/arch/x86/Makefile b/arch/x86/Makefile
index 5c477260294f..91ee171f1cff 100644
--- a/arch/x86/Makefile
+++ b/arch/x86/Makefile
@@ -220,6 +220,11 @@ archclean:
$(Q)$(MAKE) $(clean)=$(boot)
$(Q)$(MAKE) $(clean)=arch/x86/tools
+kvmconfig:
+ $(if $(wildcard $(objtree)/.config),, $(error You need an existing .config for this target))
+ $(Q)$(CONFIG_SHELL) $(srctree)/scripts/kconfig/merge_config.sh -m -O $(objtree) $(objtree)/.config arch/x86/configs/kvm_guest.config
+ $(Q)yes "" | $(MAKE) oldconfig
+
define archhelp
echo '* bzImage - Compressed kernel image (arch/x86/boot/bzImage)'
echo ' install - Install kernel using'
@@ -233,4 +238,5 @@ define archhelp
echo ' bzdisk/fdimage*/isoimage also accept:'
echo ' FDARGS="..." arguments for the booted kernel'
echo ' FDINITRD=file initrd for the booted kernel'
+ echo ' kvmconfig - Enable additional options for guest kernel support'
endef
diff --git a/arch/x86/configs/kvm_guest.config b/arch/x86/configs/kvm_guest.config
new file mode 100644
index 000000000000..f9affcc3b9f1
--- /dev/null
+++ b/arch/x86/configs/kvm_guest.config
@@ -0,0 +1,28 @@
+CONFIG_NET=y
+CONFIG_NET_CORE=y
+CONFIG_NETDEVICES=y
+CONFIG_BLOCK=y
+CONFIG_BLK_DEV=y
+CONFIG_NETWORK_FILESYSTEMS=y
+CONFIG_INET=y
+CONFIG_TTY=y
+CONFIG_SERIAL_8250=y
+CONFIG_SERIAL_8250_CONSOLE=y
+CONFIG_IP_PNP=y
+CONFIG_IP_PNP_DHCP=y
+CONFIG_BINFMT_ELF=y
+CONFIG_PCI=y
+CONFIG_PCI_MSI=y
+CONFIG_DEBUG_KERNEL=y
+CONFIG_VIRTUALIZATION=y
+CONFIG_HYPERVISOR_GUEST=y
+CONFIG_PARAVIRT=y
+CONFIG_KVM_GUEST=y
+CONFIG_VIRTIO=y
+CONFIG_VIRTIO_PCI=y
+CONFIG_VIRTIO_BLK=y
+CONFIG_VIRTIO_CONSOLE=y
+CONFIG_VIRTIO_NET=y
+CONFIG_9P_FS=y
+CONFIG_NET_9P=y
+CONFIG_NET_9P_VIRTIO=y
--
1.8.3.rc0
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
On 5/22/13 5:46 PM, Borislav Petkov wrote:
> Add an config file snippet which enables additional options useful for
> running the kernel in a kvm guest. When you execute 'make kvmconfig' it
> merges those options with an already existing user config before you
> build the kernel.
>
> Based on an patch from the external lkvm tree.
>
> Signed-off-by: Borislav Petkov <[email protected]>
Acked-by: Pekka Enberg <[email protected]>
Commit-ID: 46ff53874bd935ab9955dee56d60212857e89bf3
Gitweb: http://git.kernel.org/tip/46ff53874bd935ab9955dee56d60212857e89bf3
Author: Borislav Petkov <[email protected]>
AuthorDate: Wed, 22 May 2013 16:46:39 +0200
Committer: Ingo Molnar <[email protected]>
CommitDate: Tue, 28 May 2013 12:11:32 +0200
x86, platform, kvm, kconfig: Turn existing .config's into KVM-capable configs
Add an config file snippet which enables additional options
useful for running the kernel in a kvm guest. When you execute
'make kvmconfig' it merges those options with an already
existing user config before you build the kernel.
Based on an patch from the external lkvm tree.
Signed-off-by: Borislav Petkov <[email protected]>
Acked-by: Pekka Enberg <[email protected]>
Cc: David Rientjes <[email protected]>
Cc: Michal Marek <[email protected]>
Cc: Randy Dunlap <[email protected]>
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Ingo Molnar <[email protected]>
---
arch/x86/Makefile | 6 ++++++
arch/x86/configs/kvm_guest.config | 28 ++++++++++++++++++++++++++++
2 files changed, 34 insertions(+)
diff --git a/arch/x86/Makefile b/arch/x86/Makefile
index 5c47726..91ee171 100644
--- a/arch/x86/Makefile
+++ b/arch/x86/Makefile
@@ -220,6 +220,11 @@ archclean:
$(Q)$(MAKE) $(clean)=$(boot)
$(Q)$(MAKE) $(clean)=arch/x86/tools
+kvmconfig:
+ $(if $(wildcard $(objtree)/.config),, $(error You need an existing .config for this target))
+ $(Q)$(CONFIG_SHELL) $(srctree)/scripts/kconfig/merge_config.sh -m -O $(objtree) $(objtree)/.config arch/x86/configs/kvm_guest.config
+ $(Q)yes "" | $(MAKE) oldconfig
+
define archhelp
echo '* bzImage - Compressed kernel image (arch/x86/boot/bzImage)'
echo ' install - Install kernel using'
@@ -233,4 +238,5 @@ define archhelp
echo ' bzdisk/fdimage*/isoimage also accept:'
echo ' FDARGS="..." arguments for the booted kernel'
echo ' FDINITRD=file initrd for the booted kernel'
+ echo ' kvmconfig - Enable additional options for guest kernel support'
endef
diff --git a/arch/x86/configs/kvm_guest.config b/arch/x86/configs/kvm_guest.config
new file mode 100644
index 0000000..f9affcc
--- /dev/null
+++ b/arch/x86/configs/kvm_guest.config
@@ -0,0 +1,28 @@
+CONFIG_NET=y
+CONFIG_NET_CORE=y
+CONFIG_NETDEVICES=y
+CONFIG_BLOCK=y
+CONFIG_BLK_DEV=y
+CONFIG_NETWORK_FILESYSTEMS=y
+CONFIG_INET=y
+CONFIG_TTY=y
+CONFIG_SERIAL_8250=y
+CONFIG_SERIAL_8250_CONSOLE=y
+CONFIG_IP_PNP=y
+CONFIG_IP_PNP_DHCP=y
+CONFIG_BINFMT_ELF=y
+CONFIG_PCI=y
+CONFIG_PCI_MSI=y
+CONFIG_DEBUG_KERNEL=y
+CONFIG_VIRTUALIZATION=y
+CONFIG_HYPERVISOR_GUEST=y
+CONFIG_PARAVIRT=y
+CONFIG_KVM_GUEST=y
+CONFIG_VIRTIO=y
+CONFIG_VIRTIO_PCI=y
+CONFIG_VIRTIO_BLK=y
+CONFIG_VIRTIO_CONSOLE=y
+CONFIG_VIRTIO_NET=y
+CONFIG_9P_FS=y
+CONFIG_NET_9P=y
+CONFIG_NET_9P_VIRTIO=y
From: Borislav Petkov <[email protected]>
... so as not to disable it with a file of the same name in the toplevel
build directory.
Signed-off-by: Borislav Petkov <[email protected]>
---
arch/x86/Makefile | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/x86/Makefile b/arch/x86/Makefile
index 91ee171f1cff..07639c656fcd 100644
--- a/arch/x86/Makefile
+++ b/arch/x86/Makefile
@@ -220,6 +220,7 @@ archclean:
$(Q)$(MAKE) $(clean)=$(boot)
$(Q)$(MAKE) $(clean)=arch/x86/tools
+PHONY += kvmconfig
kvmconfig:
$(if $(wildcard $(objtree)/.config),, $(error You need an existing .config for this target))
$(Q)$(CONFIG_SHELL) $(srctree)/scripts/kconfig/merge_config.sh -m -O $(objtree) $(objtree)/.config arch/x86/configs/kvm_guest.config
--
1.8.3
Commit-ID: fc58be7596b832ee9635b2f7090a589ac5cdb807
Gitweb: http://git.kernel.org/tip/fc58be7596b832ee9635b2f7090a589ac5cdb807
Author: Borislav Petkov <[email protected]>
AuthorDate: Fri, 21 Jun 2013 10:04:51 +0200
Committer: Ingo Molnar <[email protected]>
CommitDate: Sun, 23 Jun 2013 12:17:35 +0200
x86/platform: Add kvmconfig to the phony targets
... so as not to disable it with a file of the same name in the
toplevel build directory.
Signed-off-by: Borislav Petkov <[email protected]>
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Ingo Molnar <[email protected]>
---
arch/x86/Makefile | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/x86/Makefile b/arch/x86/Makefile
index 91ee171..07639c6 100644
--- a/arch/x86/Makefile
+++ b/arch/x86/Makefile
@@ -220,6 +220,7 @@ archclean:
$(Q)$(MAKE) $(clean)=$(boot)
$(Q)$(MAKE) $(clean)=arch/x86/tools
+PHONY += kvmconfig
kvmconfig:
$(if $(wildcard $(objtree)/.config),, $(error You need an existing .config for this target))
$(Q)$(CONFIG_SHELL) $(srctree)/scripts/kconfig/merge_config.sh -m -O $(objtree) $(objtree)/.config arch/x86/configs/kvm_guest.config