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.
---
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
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
For minimal you'd probably use yes n | ...
David Rientjes 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
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
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
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
We can put a config file upstream, too.
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
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
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
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
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
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
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
We can put a config file upstream, too.
Borislav Petkov b...@alien8.de 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
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
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
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
For minimal you'd probably use yes n | ...
David Rientjes rient...@google.com 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
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
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
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
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
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
* H. Peter Anvin wrote:
> On 05/02/2013 11:06 AM, David Rientjes wrote:
> >
> > Hi Peter,
> >
> > You'll also need http://marc.info/?l=linux-kernel=136744052328802 when
> > Borislav signs it off as it fixes one of the dependencies. Still waiting
> > on how X86_IO_APIC, X86_LOCAL_APIC, and
* H. Peter Anvin 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.
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
On 05/02/2013 11:06 AM, David Rientjes wrote:
>
> Hi Peter,
>
> You'll also need http://marc.info/?l=linux-kernel=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
On Thu, 2 May 2013, tip-bot for Borislav Petkov wrote:
> Commit-ID: 7e0320e733eec67e40d2b53e438d9971f079862d
> Gitweb: http://git.kernel.org/tip/7e0320e733eec67e40d2b53e438d9971f079862d
> Author: Borislav Petkov
> AuthorDate: Fri, 26 Apr 2013 11:51:40 +0200
> Committer: H. Peter Anvin
On 05/02/2013 12:06 AM, Ingo Molnar wrote:
>
> * H. Peter Anvin 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
Commit-ID: 7e0320e733eec67e40d2b53e438d9971f079862d
Gitweb: http://git.kernel.org/tip/7e0320e733eec67e40d2b53e438d9971f079862d
Author: Borislav Petkov
AuthorDate: Fri, 26 Apr 2013 11:51:40 +0200
Committer: H. Peter Anvin
CommitDate: Thu, 2 May 2013 10:13:07 -0700
x86/kconfig: Add a
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
* David Rientjes 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)
* H. Peter Anvin 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
* H. Peter Anvin h...@zytor.com 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
* David Rientjes rient...@google.com 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
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 b...@alien8.de
AuthorDate: Fri, 26 Apr 2013 11:51:40 +0200
Committer: H. Peter Anvin h...@linux.intel.com
CommitDate: Thu, 2 May 2013
On 05/02/2013 12:06 AM, Ingo Molnar wrote:
* H. Peter Anvin h...@zytor.com 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.
On Thu, 2 May 2013, tip-bot for Borislav Petkov wrote:
Commit-ID: 7e0320e733eec67e40d2b53e438d9971f079862d
Gitweb: http://git.kernel.org/tip/7e0320e733eec67e40d2b53e438d9971f079862d
Author: Borislav Petkov b...@alien8.de
AuthorDate: Fri, 26 Apr 2013 11:51:40 +0200
Committer: H.
On 05/02/2013 11:06 AM, David Rientjes wrote:
Hi Peter,
You'll also need http://marc.info/?l=linux-kernelm=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
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
* H. Peter Anvin h...@zytor.com 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.
* H. Peter Anvin h...@linux.intel.com wrote:
On 05/02/2013 11:06 AM, David Rientjes wrote:
Hi Peter,
You'll also need http://marc.info/?l=linux-kernelm=136744052328802 when
Borislav signs it off as it fixes one of the dependencies. Still waiting
on how X86_IO_APIC,
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.
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
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.
>
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
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
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
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
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
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
>
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
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
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
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
>
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
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
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:
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
>
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
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
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
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
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
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:
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
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
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
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
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
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
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
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
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
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
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
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.
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
Commit-ID: 83aee67833071c7b73a83f7803388f7a9e481908
Gitweb: http://git.kernel.org/tip/83aee67833071c7b73a83f7803388f7a9e481908
Author: Borislav Petkov
AuthorDate: Fri, 26 Apr 2013 11:51:40 +0200
Committer: Ingo Molnar
CommitDate: Tue, 30 Apr 2013 11:00:11 +0200
x86/kconfig: Add a
Commit-ID: 83aee67833071c7b73a83f7803388f7a9e481908
Gitweb: http://git.kernel.org/tip/83aee67833071c7b73a83f7803388f7a9e481908
Author: Borislav Petkov b...@alien8.de
AuthorDate: Fri, 26 Apr 2013 11:51:40 +0200
Committer: Ingo Molnar mi...@kernel.org
CommitDate: Tue, 30 Apr 2013 11:00:11
82 matches
Mail list logo
