Re: [Autotest] [PATCH] Fix incorrect reference to client library directory
On Wed, Nov 11, 2009 at 7:02 PM, John Admanski wrote: > Okay. I mailed out a patch to do this. If this is causing problems you > can do a quick review and commit it. Reviewed and commited. Thanks John! > -- John > > On Wed, Nov 11, 2009 at 7:54 AM, John Admanski wrote: >> I'm going to mail out a patch later this afternoon that just strips >> out job.libdir entirely. >> >> -- John >> >> On Wed, Nov 11, 2009 at 7:35 AM, John Admanski wrote: >>> Maybe instead we should just drop libdir entirely. I don't see >>> anything that uses it. And if I was going to use that name, I can >>> think of more interesting things to do with it than to point it at the >>> common lib. >>> >>> -- John >>> >>> On Wed, Nov 11, 2009 at 3:30 AM, Lucas Meneghel Rodrigues >>> wrote: When checking for various client specific libraries, job code tries to reference client/lib directory, which does not exist. Fix the code to point at client/common_lib. This patch fixes autoserv and autotest regressions as of latest svn revision (3938). Signed-off-by: Lucas Meneghel Rodrigues --- client/common_lib/base_job.py | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/client/common_lib/base_job.py b/client/common_lib/base_job.py index 4ac65bc..50c925e 100644 --- a/client/common_lib/base_job.py +++ b/client/common_lib/base_job.py @@ -266,7 +266,7 @@ class base_job(object): # various client-specific directories self._bindir = readonly_dir(self.clientdir, 'bin') - self._libdir = readonly_dir(self.clientdir, 'lib') + self._libdir = readonly_dir(self.clientdir, 'common_lib') self._configdir = readonly_dir(self.clientdir, 'config') self._profdir = readonly_dir(self.clientdir, 'profilers') self._pkgdir = readwrite_dir(self.clientdir, 'packages') -- 1.6.2.5 ___ Autotest mailing list autot...@test.kernel.org http://test.kernel.org/cgi-bin/mailman/listinfo/autotest >>> >> > ___ > Autotest mailing list > autot...@test.kernel.org > http://test.kernel.org/cgi-bin/mailman/listinfo/autotest > -- Lucas -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[ANNOUNCE] kvm-kmod-2.6.31.6
This package contains the kvm external modules, using the sources from latest stable Linux release 2.6.31.6. It can be used to update the kernel-side support of kvm without upgrading the host kernel. Download is available at https://sourceforge.net/projects/kvm/files/kvm-kmod/2.6.31.6/kvm-kmod-2.6.31.6.tar.bz2/download KVM changes since kvm-kmod-2.6.31.5: - Prevent kvm_init from corrupting debugfs structures - Fix NULL pointer access due to race in in-kernel timer chips - Ignore reads from AMDs C1E enabled MSR - get_tss_base_addr() should return a gpa_t (fixes Windows2k3 issue with >4G RAM) kvm-kmod changes: - Avoid build breakage against Ubuntu Hardy - Add kernel version fence (prevents building against too old or too new kernels) Enjoy, Jan -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 0/2] Handle multiple exceptions (fixes Win2003 reboot by triple fault)
On Wed, Nov 11, 2009 at 05:29:47PM -0200, Marcelo Tosatti wrote:
> I suppose a complete fix would be to follow the "Conditions for
> Generating a Double Fault" with support for handling exceptions
> serially.
>
> But this works for me.
>
I prefer proper solution. Like one attached (this is combination of ths
patch by Eddie Dong and my fix):
Move Double-Fault generation logic out of page fault
exception generating function to cover more generic case.
Signed-off-by: Eddie Dong
Signed-off-by: Gleb Natapov
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 76c8375..88c4490 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -248,12 +248,61 @@ void kvm_set_apic_base(struct kvm_vcpu *vcpu, u64 data)
}
EXPORT_SYMBOL_GPL(kvm_set_apic_base);
+#define EXCPT_BENIGN 0
+#define EXCPT_CONTRIBUTORY 1
+#define EXCPT_PF 2
+
+static int exception_class(int vector)
+{
+ if (vector == 14)
+ return EXCPT_PF;
+ else if (vector == 0 || (vector >= 10 && vector <= 13))
+ return EXCPT_CONTRIBUTORY;
+ else
+ return EXCPT_BENIGN;
+}
+
+static void kvm_multiple_exception(struct kvm_vcpu *vcpu,
+ unsigned nr, bool has_error, u32 error_code)
+{
+ u32 prev_nr;
+ int class1, class2;
+
+ if (!vcpu->arch.exception.pending) {
+ queue:
+ vcpu->arch.exception.pending = true;
+ vcpu->arch.exception.has_error_code = has_error;
+ vcpu->arch.exception.nr = nr;
+ vcpu->arch.exception.error_code = error_code;
+ return;
+ }
+
+ /* to check exception */
+ prev_nr = vcpu->arch.exception.nr;
+ if (prev_nr == DF_VECTOR) {
+ /* triple fault -> shutdown */
+ set_bit(KVM_REQ_TRIPLE_FAULT, &vcpu->requests);
+ return;
+ }
+ class1 = exception_class(prev_nr);
+ class2 = exception_class(nr);
+ if ((class1 == EXCPT_CONTRIBUTORY && class2 == EXCPT_CONTRIBUTORY)
+ || (class1 == EXCPT_PF && class2 != EXCPT_BENIGN)) {
+ /* generate double fault per SDM Table 5-5 */
+ vcpu->arch.exception.pending = true;
+ vcpu->arch.exception.has_error_code = true;
+ vcpu->arch.exception.nr = DF_VECTOR;
+ vcpu->arch.exception.error_code = 0;
+ } else
+ /* replace previous exception with a new one in a hope
+ that instruction re-execution will regenerate lost
+ exception */
+ goto queue;
+}
+
void kvm_queue_exception(struct kvm_vcpu *vcpu, unsigned nr)
{
- WARN_ON(vcpu->arch.exception.pending);
- vcpu->arch.exception.pending = true;
- vcpu->arch.exception.has_error_code = false;
- vcpu->arch.exception.nr = nr;
+ kvm_multiple_exception(vcpu, nr, false, 0);
}
EXPORT_SYMBOL_GPL(kvm_queue_exception);
@@ -261,25 +310,6 @@ void kvm_inject_page_fault(struct kvm_vcpu *vcpu, unsigned
long addr,
u32 error_code)
{
++vcpu->stat.pf_guest;
-
- if (vcpu->arch.exception.pending) {
- switch(vcpu->arch.exception.nr) {
- case DF_VECTOR:
- /* triple fault -> shutdown */
- set_bit(KVM_REQ_TRIPLE_FAULT, &vcpu->requests);
- return;
- case PF_VECTOR:
- vcpu->arch.exception.nr = DF_VECTOR;
- vcpu->arch.exception.error_code = 0;
- return;
- default:
- /* replace previous exception with a new one in a hope
- that instruction re-execution will regenerate lost
- exception */
- vcpu->arch.exception.pending = false;
- break;
- }
- }
vcpu->arch.cr2 = addr;
kvm_queue_exception_e(vcpu, PF_VECTOR, error_code);
}
@@ -292,11 +322,7 @@ EXPORT_SYMBOL_GPL(kvm_inject_nmi);
void kvm_queue_exception_e(struct kvm_vcpu *vcpu, unsigned nr, u32 error_code)
{
- WARN_ON(vcpu->arch.exception.pending);
- vcpu->arch.exception.pending = true;
- vcpu->arch.exception.has_error_code = true;
- vcpu->arch.exception.nr = nr;
- vcpu->arch.exception.error_code = error_code;
+ kvm_multiple_exception(vcpu, nr, true, error_code);
}
EXPORT_SYMBOL_GPL(kvm_queue_exception_e);
--
Gleb.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 1/2] KVM: x86: handle double and triple faults for every exception
On Wed, Nov 11, 2009 at 05:29:48PM -0200, Marcelo Tosatti wrote:
> From: Joerg Roedel
>
> The current KVM x86 exception code handles double and triple faults only for
> page fault exceptions. This patch extends this detection for every exception
> that gets queued for the guest.
>
> Signed-off-by: Joerg Roedel
> CC: Jan Kiszka
>
> Index: kvm/arch/x86/kvm/x86.c
> ===
> --- kvm.orig/arch/x86/kvm/x86.c
> +++ kvm/arch/x86/kvm/x86.c
> @@ -170,9 +170,21 @@ void kvm_set_apic_base(struct kvm_vcpu *
> }
> EXPORT_SYMBOL_GPL(kvm_set_apic_base);
>
> +static void handle_multiple_faults(struct kvm_vcpu *vcpu)
> +{
> + if (vcpu->arch.exception.nr != DF_VECTOR) {
> + vcpu->arch.exception.nr = DF_VECTOR;
> + vcpu->arch.exception.error_code = 0;
> + } else
> + set_bit(KVM_REQ_TRIPLE_FAULT, &vcpu->requests);
> +}
> +
Making #DF from two bening exceptions is very wrong.
> void kvm_queue_exception(struct kvm_vcpu *vcpu, unsigned nr)
> {
> - WARN_ON(vcpu->arch.exception.pending);
> + if (vcpu->arch.exception.pending) {
> + handle_multiple_faults(vcpu);
> + return;
> + }
> vcpu->arch.exception.pending = true;
> vcpu->arch.exception.has_error_code = false;
> vcpu->arch.exception.nr = nr;
> @@ -184,24 +196,6 @@ void kvm_inject_page_fault(struct kvm_vc
> {
> ++vcpu->stat.pf_guest;
>
> - if (vcpu->arch.exception.pending) {
> - switch(vcpu->arch.exception.nr) {
> - case DF_VECTOR:
> - /* triple fault -> shutdown */
> - set_bit(KVM_REQ_TRIPLE_FAULT, &vcpu->requests);
> - return;
> - case PF_VECTOR:
> - vcpu->arch.exception.nr = DF_VECTOR;
> - vcpu->arch.exception.error_code = 0;
> - return;
> - default:
> - /* replace previous exception with a new one in a hope
> -that instruction re-execution will regenerate lost
> -exception */
> - vcpu->arch.exception.pending = false;
> - break;
When exceptions are handled serially previous exception have to be
replaced by new one. Think about #PF during #DE. #PF should be handled first
before #DE can proceed.
> - }
> - }
> vcpu->arch.cr2 = addr;
> kvm_queue_exception_e(vcpu, PF_VECTOR, error_code);
> }
> @@ -214,7 +208,10 @@ EXPORT_SYMBOL_GPL(kvm_inject_nmi);
>
> void kvm_queue_exception_e(struct kvm_vcpu *vcpu, unsigned nr, u32
> error_code)
> {
> - WARN_ON(vcpu->arch.exception.pending);
> + if (vcpu->arch.exception.pending) {
> + handle_multiple_faults(vcpu);
> + return;
> + }
> vcpu->arch.exception.pending = true;
> vcpu->arch.exception.has_error_code = true;
> vcpu->arch.exception.nr = nr;
>
> --
--
Gleb.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
qemu-kvm: Unsolicited boot from net
Hi Marcelo, since merge 2fb0744e0d qemu-kvm always tries to boot from network first when using default options. Upstream does not show this behavior. Jan -- Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 0/2] Handle multiple exceptions (fixes Win2003 reboot by triple fault)
Gleb Natapov wrote:
> On Wed, Nov 11, 2009 at 05:29:47PM -0200, Marcelo Tosatti wrote:
>> I suppose a complete fix would be to follow the "Conditions for
>> Generating a Double Fault" with support for handling exceptions
>> serially.
>>
>> But this works for me.
>>
> I prefer proper solution. Like one attached (this is combination of ths
> patch by Eddie Dong and my fix):
Nice, preferred here as well. I only have a minor comment below.
>
> Move Double-Fault generation logic out of page fault
> exception generating function to cover more generic case.
>
> Signed-off-by: Eddie Dong
> Signed-off-by: Gleb Natapov
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index 76c8375..88c4490 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -248,12 +248,61 @@ void kvm_set_apic_base(struct kvm_vcpu *vcpu, u64 data)
> }
> EXPORT_SYMBOL_GPL(kvm_set_apic_base);
>
> +#define EXCPT_BENIGN 0
> +#define EXCPT_CONTRIBUTORY 1
> +#define EXCPT_PF 2
> +
> +static int exception_class(int vector)
> +{
> + if (vector == 14)
> + return EXCPT_PF;
> + else if (vector == 0 || (vector >= 10 && vector <= 13))
xx_VECTOR?
> + return EXCPT_CONTRIBUTORY;
> + else
> + return EXCPT_BENIGN;
> +}
> +
> +static void kvm_multiple_exception(struct kvm_vcpu *vcpu,
> + unsigned nr, bool has_error, u32 error_code)
> +{
> + u32 prev_nr;
> + int class1, class2;
> +
> + if (!vcpu->arch.exception.pending) {
> + queue:
> + vcpu->arch.exception.pending = true;
> + vcpu->arch.exception.has_error_code = has_error;
> + vcpu->arch.exception.nr = nr;
> + vcpu->arch.exception.error_code = error_code;
> + return;
> + }
> +
> + /* to check exception */
> + prev_nr = vcpu->arch.exception.nr;
> + if (prev_nr == DF_VECTOR) {
> + /* triple fault -> shutdown */
> + set_bit(KVM_REQ_TRIPLE_FAULT, &vcpu->requests);
> + return;
> + }
> + class1 = exception_class(prev_nr);
> + class2 = exception_class(nr);
> + if ((class1 == EXCPT_CONTRIBUTORY && class2 == EXCPT_CONTRIBUTORY)
> + || (class1 == EXCPT_PF && class2 != EXCPT_BENIGN)) {
> + /* generate double fault per SDM Table 5-5 */
> + vcpu->arch.exception.pending = true;
> + vcpu->arch.exception.has_error_code = true;
> + vcpu->arch.exception.nr = DF_VECTOR;
> + vcpu->arch.exception.error_code = 0;
> + } else
> + /* replace previous exception with a new one in a hope
> +that instruction re-execution will regenerate lost
> +exception */
> + goto queue;
> +}
> +
> void kvm_queue_exception(struct kvm_vcpu *vcpu, unsigned nr)
> {
> - WARN_ON(vcpu->arch.exception.pending);
> - vcpu->arch.exception.pending = true;
> - vcpu->arch.exception.has_error_code = false;
> - vcpu->arch.exception.nr = nr;
> + kvm_multiple_exception(vcpu, nr, false, 0);
> }
> EXPORT_SYMBOL_GPL(kvm_queue_exception);
>
> @@ -261,25 +310,6 @@ void kvm_inject_page_fault(struct kvm_vcpu *vcpu,
> unsigned long addr,
> u32 error_code)
> {
> ++vcpu->stat.pf_guest;
> -
> - if (vcpu->arch.exception.pending) {
> - switch(vcpu->arch.exception.nr) {
> - case DF_VECTOR:
> - /* triple fault -> shutdown */
> - set_bit(KVM_REQ_TRIPLE_FAULT, &vcpu->requests);
> - return;
> - case PF_VECTOR:
> - vcpu->arch.exception.nr = DF_VECTOR;
> - vcpu->arch.exception.error_code = 0;
> - return;
> - default:
> - /* replace previous exception with a new one in a hope
> -that instruction re-execution will regenerate lost
> -exception */
> - vcpu->arch.exception.pending = false;
> - break;
> - }
> - }
> vcpu->arch.cr2 = addr;
> kvm_queue_exception_e(vcpu, PF_VECTOR, error_code);
> }
> @@ -292,11 +322,7 @@ EXPORT_SYMBOL_GPL(kvm_inject_nmi);
>
> void kvm_queue_exception_e(struct kvm_vcpu *vcpu, unsigned nr, u32
> error_code)
> {
> - WARN_ON(vcpu->arch.exception.pending);
> - vcpu->arch.exception.pending = true;
> - vcpu->arch.exception.has_error_code = true;
> - vcpu->arch.exception.nr = nr;
> - vcpu->arch.exception.error_code = error_code;
> + kvm_multiple_exception(vcpu, nr, true, error_code);
> }
> EXPORT_SYMBOL_GPL(kvm_queue_exception_e);
>
Jan
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 0/2] Handle multiple exceptions (fixes Win2003 reboot by triple fault)
On Thu, Nov 12, 2009 at 01:41:31PM +0100, Jan Kiszka wrote:
> Gleb Natapov wrote:
> > On Wed, Nov 11, 2009 at 05:29:47PM -0200, Marcelo Tosatti wrote:
> >> I suppose a complete fix would be to follow the "Conditions for
> >> Generating a Double Fault" with support for handling exceptions
> >> serially.
> >>
> >> But this works for me.
> >>
> > I prefer proper solution. Like one attached (this is combination of ths
> > patch by Eddie Dong and my fix):
>
> Nice, preferred here as well. I only have a minor comment below.
>
Move Double-Fault generation logic out of page fault
exception generating function to cover more generic case.
Signed-off-by: Eddie Dong
Signed-off-by: Gleb Natapov
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 76c8375..88c4490 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -248,12 +248,61 @@ void kvm_set_apic_base(struct kvm_vcpu *vcpu, u64 data)
}
EXPORT_SYMBOL_GPL(kvm_set_apic_base);
+#define EXCPT_BENIGN 0
+#define EXCPT_CONTRIBUTORY 1
+#define EXCPT_PF 2
+
+static int exception_class(int vector)
+{
+ if (vector == 14)
+ return EXCPT_PF;
+ else if (vector == DE_VECTOR || (vector >= TS_VECTOR && vector <=
GP_VECTOR))
+ return EXCPT_CONTRIBUTORY;
+ else
+ return EXCPT_BENIGN;
+}
+
+static void kvm_multiple_exception(struct kvm_vcpu *vcpu,
+ unsigned nr, bool has_error, u32 error_code)
+{
+ u32 prev_nr;
+ int class1, class2;
+
+ if (!vcpu->arch.exception.pending) {
+ queue:
+ vcpu->arch.exception.pending = true;
+ vcpu->arch.exception.has_error_code = has_error;
+ vcpu->arch.exception.nr = nr;
+ vcpu->arch.exception.error_code = error_code;
+ return;
+ }
+
+ /* to check exception */
+ prev_nr = vcpu->arch.exception.nr;
+ if (prev_nr == DF_VECTOR) {
+ /* triple fault -> shutdown */
+ set_bit(KVM_REQ_TRIPLE_FAULT, &vcpu->requests);
+ return;
+ }
+ class1 = exception_class(prev_nr);
+ class2 = exception_class(nr);
+ if ((class1 == EXCPT_CONTRIBUTORY && class2 == EXCPT_CONTRIBUTORY)
+ || (class1 == EXCPT_PF && class2 != EXCPT_BENIGN)) {
+ /* generate double fault per SDM Table 5-5 */
+ vcpu->arch.exception.pending = true;
+ vcpu->arch.exception.has_error_code = true;
+ vcpu->arch.exception.nr = DF_VECTOR;
+ vcpu->arch.exception.error_code = 0;
+ } else
+ /* replace previous exception with a new one in a hope
+ that instruction re-execution will regenerate lost
+ exception */
+ goto queue;
+}
+
void kvm_queue_exception(struct kvm_vcpu *vcpu, unsigned nr)
{
- WARN_ON(vcpu->arch.exception.pending);
- vcpu->arch.exception.pending = true;
- vcpu->arch.exception.has_error_code = false;
- vcpu->arch.exception.nr = nr;
+ kvm_multiple_exception(vcpu, nr, false, 0);
}
EXPORT_SYMBOL_GPL(kvm_queue_exception);
@@ -261,25 +310,6 @@ void kvm_inject_page_fault(struct kvm_vcpu *vcpu, unsigned
long addr,
u32 error_code)
{
++vcpu->stat.pf_guest;
-
- if (vcpu->arch.exception.pending) {
- switch(vcpu->arch.exception.nr) {
- case DF_VECTOR:
- /* triple fault -> shutdown */
- set_bit(KVM_REQ_TRIPLE_FAULT, &vcpu->requests);
- return;
- case PF_VECTOR:
- vcpu->arch.exception.nr = DF_VECTOR;
- vcpu->arch.exception.error_code = 0;
- return;
- default:
- /* replace previous exception with a new one in a hope
- that instruction re-execution will regenerate lost
- exception */
- vcpu->arch.exception.pending = false;
- break;
- }
- }
vcpu->arch.cr2 = addr;
kvm_queue_exception_e(vcpu, PF_VECTOR, error_code);
}
@@ -292,11 +322,7 @@ EXPORT_SYMBOL_GPL(kvm_inject_nmi);
void kvm_queue_exception_e(struct kvm_vcpu *vcpu, unsigned nr, u32 error_code)
{
- WARN_ON(vcpu->arch.exception.pending);
- vcpu->arch.exception.pending = true;
- vcpu->arch.exception.has_error_code = true;
- vcpu->arch.exception.nr = nr;
- vcpu->arch.exception.error_code = error_code;
+ kvm_multiple_exception(vcpu, nr, true, error_code);
}
EXPORT_SYMBOL_GPL(kvm_queue_exception_e);
--
Gleb.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 0/2] Handle multiple exceptions (fixes Win2003 reboot by triple fault)
On Thu, Nov 12, 2009 at 02:21:24PM +0200, Gleb Natapov wrote:
> On Wed, Nov 11, 2009 at 05:29:47PM -0200, Marcelo Tosatti wrote:
> > I suppose a complete fix would be to follow the "Conditions for
> > Generating a Double Fault" with support for handling exceptions
> > serially.
> >
> > But this works for me.
> >
> I prefer proper solution. Like one attached (this is combination of ths
> patch by Eddie Dong and my fix):
>
> Move Double-Fault generation logic out of page fault
> exception generating function to cover more generic case.
>
> Signed-off-by: Eddie Dong
> Signed-off-by: Gleb Natapov
Nice.
Tested-by: Marcelo Tosatti
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index 76c8375..88c4490 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -248,12 +248,61 @@ void kvm_set_apic_base(struct kvm_vcpu *vcpu, u64 data)
> }
> EXPORT_SYMBOL_GPL(kvm_set_apic_base);
>
> +#define EXCPT_BENIGN 0
> +#define EXCPT_CONTRIBUTORY 1
> +#define EXCPT_PF 2
> +
> +static int exception_class(int vector)
> +{
> + if (vector == 14)
> + return EXCPT_PF;
> + else if (vector == 0 || (vector >= 10 && vector <= 13))
> + return EXCPT_CONTRIBUTORY;
> + else
> + return EXCPT_BENIGN;
> +}
> +
> +static void kvm_multiple_exception(struct kvm_vcpu *vcpu,
> + unsigned nr, bool has_error, u32 error_code)
> +{
> + u32 prev_nr;
> + int class1, class2;
> +
> + if (!vcpu->arch.exception.pending) {
> + queue:
> + vcpu->arch.exception.pending = true;
> + vcpu->arch.exception.has_error_code = has_error;
> + vcpu->arch.exception.nr = nr;
> + vcpu->arch.exception.error_code = error_code;
> + return;
> + }
> +
> + /* to check exception */
> + prev_nr = vcpu->arch.exception.nr;
> + if (prev_nr == DF_VECTOR) {
> + /* triple fault -> shutdown */
> + set_bit(KVM_REQ_TRIPLE_FAULT, &vcpu->requests);
> + return;
> + }
> + class1 = exception_class(prev_nr);
> + class2 = exception_class(nr);
> + if ((class1 == EXCPT_CONTRIBUTORY && class2 == EXCPT_CONTRIBUTORY)
> + || (class1 == EXCPT_PF && class2 != EXCPT_BENIGN)) {
> + /* generate double fault per SDM Table 5-5 */
> + vcpu->arch.exception.pending = true;
> + vcpu->arch.exception.has_error_code = true;
> + vcpu->arch.exception.nr = DF_VECTOR;
> + vcpu->arch.exception.error_code = 0;
> + } else
> + /* replace previous exception with a new one in a hope
> +that instruction re-execution will regenerate lost
> +exception */
Out of curiosity, why not an exception queue?
> + goto queue;
This goto seems unnecessary.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: qemu-kvm: Unsolicited boot from net
On Thu, Nov 12, 2009 at 01:29:37PM +0100, Jan Kiszka wrote: > Hi Marcelo, > > since merge 2fb0744e0d qemu-kvm always tries to boot from network first > when using default options. Upstream does not show this behavior. Did you install the updated roms after this commit? commit ec9f735638b6380361387fb49060f6712cb27602 Author: Anthony Liguori Date: Fri Oct 30 16:44:26 2009 -0500 Update gpxe roms to have BANNER_TIMEOUT=0 Signed-off-by: Anthony Liguori -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: qemu-kvm: Unsolicited boot from net
Marcelo Tosatti wrote: > On Thu, Nov 12, 2009 at 01:29:37PM +0100, Jan Kiszka wrote: >> Hi Marcelo, >> >> since merge 2fb0744e0d qemu-kvm always tries to boot from network first >> when using default options. Upstream does not show this behavior. > > Did you install the updated roms after this commit? > > commit ec9f735638b6380361387fb49060f6712cb27602 > Author: Anthony Liguori > Date: Fri Oct 30 16:44:26 2009 -0500 > > Update gpxe roms to have BANNER_TIMEOUT=0 > > Signed-off-by: Anthony Liguori I ran a complete & fresh mkbuilddir-configure-make-install cycle to exclude this. Moreover, the above change is actually not related to triggering the netboot but to wait for potential input of the user. Looking closer: It's actually still pcbios that is used by my installation - shouldn't this be Seabios now? Jan -- Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] kvm-kmod: Document the build process (take 2)
A package without build instructions is like a kernel without a penguin. Signed-off-by: Wolfgang Mauerer --- README | 37 + 1 files changed, 37 insertions(+), 0 deletions(-) create mode 100644 README diff --git a/README b/README new file mode 100644 index 000..bef7586 --- /dev/null +++ b/README @@ -0,0 +1,37 @@ +Building the KVM kernel module is performed differently depending on whether +you are working from a clone of the git repository or from a source release. +Notice that two kernels are involved: One from which the KVM sources +are taken (kernel A), and one for which the module is built (kernel B). +For out-of-tree module builds, it is well possible that kernel A is more +recent than kernel B. + +- To build from a release (this is the default case), simply + use ./configure (possibly with any arguments that are required for + your setup, see ./configure --help) and make. The kernel specified + with --kerneldir refers to kernel B, that is, the kernel for which + the module is built. + +- Building from a cloned git repository (most likely useful for developers + only) requires a kernel tree with the main kvm sources (kernel A) that + is included as a submodule in the linux-2.6/ directory. By default, + the KVM development tree on git.kernel.org is used, but this can be + changed in the git configuration. + + Before the kvm module can be built, the linux submodule must be initialised + and populated. The required sequence of commands is + + git submodule init + git submodule update + ./configure + make sync + make + + Notice that you can also specify an existing Linux tree for the + synchronisation stage by using + + make sync LINUX=/path/to/kernel/A + + LINUX specifies the path to kernel A from which the KVM sources are taken. + The directory must point to a local git tree, not to a plain directory + containing the kernel sources. If LINUX is unset, the default value + is linux-2.6/, i.e., the git submodule. -- 1.6.4 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 0/2] Handle multiple exceptions (fixes Win2003 reboot by triple fault)
On Thu, Nov 12, 2009 at 02:07:09PM -0200, Marcelo Tosatti wrote:
> On Thu, Nov 12, 2009 at 02:21:24PM +0200, Gleb Natapov wrote:
> > On Wed, Nov 11, 2009 at 05:29:47PM -0200, Marcelo Tosatti wrote:
> > > I suppose a complete fix would be to follow the "Conditions for
> > > Generating a Double Fault" with support for handling exceptions
> > > serially.
> > >
> > > But this works for me.
> > >
> > I prefer proper solution. Like one attached (this is combination of ths
> > patch by Eddie Dong and my fix):
> >
> > Move Double-Fault generation logic out of page fault
> > exception generating function to cover more generic case.
> >
> > Signed-off-by: Eddie Dong
> > Signed-off-by: Gleb Natapov
>
> Nice.
>
> Tested-by: Marcelo Tosatti
>
> > diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> > index 76c8375..88c4490 100644
> > --- a/arch/x86/kvm/x86.c
> > +++ b/arch/x86/kvm/x86.c
> > @@ -248,12 +248,61 @@ void kvm_set_apic_base(struct kvm_vcpu *vcpu, u64
> > data)
> > }
> > EXPORT_SYMBOL_GPL(kvm_set_apic_base);
> >
> > +#define EXCPT_BENIGN 0
> > +#define EXCPT_CONTRIBUTORY 1
> > +#define EXCPT_PF 2
> > +
> > +static int exception_class(int vector)
> > +{
> > + if (vector == 14)
> > + return EXCPT_PF;
> > + else if (vector == 0 || (vector >= 10 && vector <= 13))
> > + return EXCPT_CONTRIBUTORY;
> > + else
> > + return EXCPT_BENIGN;
> > +}
> > +
> > +static void kvm_multiple_exception(struct kvm_vcpu *vcpu,
> > + unsigned nr, bool has_error, u32 error_code)
> > +{
> > + u32 prev_nr;
> > + int class1, class2;
> > +
> > + if (!vcpu->arch.exception.pending) {
> > + queue:
> > + vcpu->arch.exception.pending = true;
> > + vcpu->arch.exception.has_error_code = has_error;
> > + vcpu->arch.exception.nr = nr;
> > + vcpu->arch.exception.error_code = error_code;
> > + return;
> > + }
> > +
> > + /* to check exception */
> > + prev_nr = vcpu->arch.exception.nr;
> > + if (prev_nr == DF_VECTOR) {
> > + /* triple fault -> shutdown */
> > + set_bit(KVM_REQ_TRIPLE_FAULT, &vcpu->requests);
> > + return;
> > + }
> > + class1 = exception_class(prev_nr);
> > + class2 = exception_class(nr);
> > + if ((class1 == EXCPT_CONTRIBUTORY && class2 == EXCPT_CONTRIBUTORY)
> > + || (class1 == EXCPT_PF && class2 != EXCPT_BENIGN)) {
> > + /* generate double fault per SDM Table 5-5 */
> > + vcpu->arch.exception.pending = true;
> > + vcpu->arch.exception.has_error_code = true;
> > + vcpu->arch.exception.nr = DF_VECTOR;
> > + vcpu->arch.exception.error_code = 0;
>
> > + } else
> > + /* replace previous exception with a new one in a hope
> > + that instruction re-execution will regenerate lost
> > + exception */
>
> Out of curiosity, why not an exception queue?
>
It seems unnecessary. Lost exception will be regenerated after
instruction that caused it will be re-executed.
> > + goto queue;
>
> This goto seems unnecessary.
It is very important. It replaces previous exception with the new one.
This allows CPU to proceed in situation where exception injection causes
another exception serially. Think about #DE that causes #PF (because
stack is not mapped for instance). If we'll drop #PF and re-inject #DE it
will generate #PF once again. If we'll drop #DE and inject #PF then #PF
handler with hopefully fix #PF condition and #DE will be regenerated
when devision will be retried.
--
Gleb.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: qemu-kvm: Unsolicited boot from net
On Thu, Nov 12, 2009 at 06:29:16PM +0100, Jan Kiszka wrote: > Marcelo Tosatti wrote: > > On Thu, Nov 12, 2009 at 01:29:37PM +0100, Jan Kiszka wrote: > >> Hi Marcelo, > >> > >> since merge 2fb0744e0d qemu-kvm always tries to boot from network first > >> when using default options. Upstream does not show this behavior. > > > > Did you install the updated roms after this commit? > > > > commit ec9f735638b6380361387fb49060f6712cb27602 > > Author: Anthony Liguori > > Date: Fri Oct 30 16:44:26 2009 -0500 > > > > Update gpxe roms to have BANNER_TIMEOUT=0 > > > > Signed-off-by: Anthony Liguori > > I ran a complete & fresh mkbuilddir-configure-make-install cycle to > exclude this. Moreover, the above change is actually not related to > triggering the netboot but to wait for potential input of the user. Right. > Looking closer: It's actually still pcbios that is used by my > installation - shouldn't this be Seabios now? My understanding is that Seabios should get more testing with qemu-kvm (other than the cpu hotplug debate). Gleb/Avi would know for sure. Now whether pcbios option rom supports gpxe properly i don't know, maybe that is the root cause for the problem (yes, qemu-kvm loads gpxe and attempts to boot from the network first, the above commit only removes the annoying multi-second delay). CC'ing people with some clue. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: qemu-kvm: Unsolicited boot from net
Marcelo Tosatti wrote: Looking closer: It's actually still pcbios that is used by my installation - shouldn't this be Seabios now? My understanding is that Seabios should get more testing with qemu-kvm (other than the cpu hotplug debate). Gleb/Avi would know for sure. Now whether pcbios option rom supports gpxe properly i don't know, maybe that is the root cause for the problem (yes, qemu-kvm loads gpxe and attempts to boot from the network first, the above commit only removes the annoying multi-second delay). CC'ing people with some clue. Yup, that's the problem. gPXE doesn't think PCBIOS is a PnP bios because it isn't. Therefore it doesn't enable BEV and uses int19 instead. This isn't a problem with older QEMUs because we only loaded the option roms on demand. We now load them unconditionally. Of course, that meant -boot cdn never really worked correctly. The only easy solution is moving to SeaBIOS. I'm surprised qemu-kvm hasn't already made the move to be honest. -- Regards, Anthony Liguori -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] KVM Fault Tolerance: Kemari for KVM
On 11/09/2009 05:53 AM, Fernando Luis Vázquez Cao wrote: Hi all, It has been a while coming, but we have finally started work on Kemari's port to KVM. For those not familiar with it, Kemari provides the basic building block to create a virtualization-based fault tolerant machine: a virtual machine synchronization mechanism. Traditional high availability solutions can be classified in two groups: fault tolerant servers, and software clustering. Broadly speaking, fault tolerant servers protect us against hardware failures and, generally, rely on redundant hardware (often proprietary), and hardware failure detection to trigger fail-over. On the other hand, software clustering, as its name indicates, takes care of software failures and usually requires a standby server whose software configuration for the part we are trying to make fault tolerant must be identical to that of the active server. Both solutions may be applied to virtualized environments. Indeed, the current incarnation of Kemari (Xen-based) brings fault tolerant server-like capabilities to virtual machines and integration with existing HA stacks (Heartbeat, RHCS, etc) is under consideration. After some time in the drawing board we completed the basic design of Kemari for KVM, so we are sending an RFC at this point to get early feedback and, hopefully, get things right from the start. Those already familiar with Kemari and/or fault tolerance may want to skip the "Background" and go directly to the design and implementation bits. This is a pretty long write-up, but please bear with me. == Background == We started to play around with continuous virtual synchronization technology about 3 years ago. As development progressed and, most importantly, we got the first Xen-based working prototypes it became clear that we needed a proper name for our toy: Kemari. The goal of Kemari is to provide a fault tolerant platform for virtualization environments, so that in the event of a hardware failure the virtual machine fails over from compromised to properly operating hardware (a physical machine) in a way that is completely transparent to the guest operating system. Although hardware based fault tolerant servers and HA servers (software clustering) have been around for a (long) while, they typically require specifically designed hardware and/or modifications to applications. In contrast, by abstracting hardware using virtualization, Kemari can be used on off-the-shelf hardware and no application modifications are needed. After a period of in-house development the first version of Kemari for Xen was released in Nov 2008 as open source. However, by then it was already pretty clear that a KVM port would have several advantages. First, KVM is integrated into the Linux kernel, which means one gets support for a wide variety of hardware for free. Second, and in the same vein, KVM can also benefit from Linux' low latency networking capabilities including RDMA, which is of paramount importance for a extremely latency-sensitive functionality like Kemari. Last, but not the least, KVM and its community is growing rapidly, and there is increasing demand for Kemari-like functionality for KVM. Although the basic design principles will remain the same, our plan is to write Kemari for KVM from scratch, since there does not seem to be much opportunity for sharing between Xen and KVM. == Design outline == The basic premise of fault tolerant servers is that when things go awry with the hardware the running system should transparently continue execution on an alternate physical host. For this to be possible the state of the fallback host has to be identical to that of the primary. Kemari runs paired virtual machines in an active-passive configuration and achieves whole-system replication by continuously copying the state of the system (dirty pages and the state of the virtual devices) from the active node to the passive node. An interesting implication of this is that during normal operation only the active node is actually executing code. Another possible approach is to run a pair of systems in lock-step (à la VMware FT). Since both the primary and fallback virtual machines are active keeping them synchronized is a complex task, which usually involves carefully injecting external events into both virtual machines so that they result in identical states. The latter approach is extremely architecture specific and not SMP friendly. This spurred us to try the design that became Kemari, which we believe lends itself to further optimizations. == Implementation == The first step is to encapsulate the machine to be protected within a virtual machine. Then the live migration functionality is leveraged to keep the virtual machines synchronized. Whereas during live migration dirty pages can be sent asynchronously from the primary to the fallback server until the ratio of dirty pages is low enough to guarantee very short downtimes, when it comes to fault tolerance sol
Re: [patch] add some unlocks on error paths irq_comm.c
Dan,
This has already been fixed by commit
57225096e5888d84e84224bac13aae2aaed89280.
Thanks.
On Tue, Nov 10, 2009 at 10:57:09AM +0200, Dan Carpenter wrote:
> There were a couple unlocks missing. They were found by smatch static
> checker. Compile tested.
>
> regards,
> dan carpenter
>
> Signed-off-by: Dan Carpenter
>
> --- orig/virt/kvm/irq_comm.c 2009-11-08 19:00:50.0 +0200
> +++ devel/virt/kvm/irq_comm.c 2009-11-08 19:04:45.0 +0200
> @@ -209,6 +209,7 @@
> sizeof(kvm->arch.irq_sources_bitmap));
>
> if (irq_source_id >= sizeof(kvm->arch.irq_sources_bitmap)) {
> + mutex_unlock(&kvm->irq_lock);
> printk(KERN_WARNING "kvm: exhaust allocatable IRQ sources!\n");
> return -EFAULT;
> }
> @@ -229,6 +230,7 @@
> mutex_lock(&kvm->irq_lock);
> if (irq_source_id < 0 ||
> irq_source_id >= sizeof(kvm->arch.irq_sources_bitmap)) {
> + mutex_unlock(&kvm->irq_lock);
> printk(KERN_ERR "kvm: IRQ source ID out of range!\n");
> return;
> }
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] Don't sync mpstate to/from kernel when unneeded.
On Thu, Nov 12, 2009 at 12:33:07AM +0100, Jan Kiszka wrote:
> Gleb Natapov wrote:
> > mp_state, unlike other cpu state, can be changed not only from vcpu
> > context it belongs to, but by other vcpus too. That makes its loading
> > from kernel/saving back not safe if mp_state value is changed inside
> > kernel between load and save. For example vcpu 1 loads mp_sate into
> > user-space and the state is RUNNING, vcpu 0 sends INIT/SIPI to vcpu 1
> > so in-kernel mp_sate becomes SIPI, vcpu 1 save user-space copy into
> > kernel and calls vcpu_run(). SIPI sate is lost.
> >
> > The patch copies mp_sate into kernel only when it is knows that
> > int-kernel value is outdated. This happens on reset and vmload.
>
> Just stumbled over this commit as it breaks kvm-disabled builds
> (layering violations...). I guess we need this upstream too once the
> irqchips go in. Or do your patches, Glauber, already include this? If
> not, anyone already thought about how to move the kvm logic behind
> qemu's state sync curtain?
It does not, since upstream qemu still does not support smp.
I basically did not worried about it.
>
> Jan
>
> >
> > Signed-off-by: Gleb Natapov
> > ---
> > hw/apic.c |1 +
> > monitor.c |2 ++
> > qemu-kvm.c|9 -
> > qemu-kvm.h|1 -
> > target-i386/machine.c |3 +++
> > 5 files changed, 10 insertions(+), 6 deletions(-)
> >
> > diff --git a/hw/apic.c b/hw/apic.c
> > index 2952675..729 100644
> > --- a/hw/apic.c
> > +++ b/hw/apic.c
> > @@ -512,6 +512,7 @@ void apic_init_reset(CPUState *env)
> > if (kvm_enabled() && qemu_kvm_irqchip_in_kernel()) {
> > env->mp_state
> > = env->halted ? KVM_MP_STATE_UNINITIALIZED :
> > KVM_MP_STATE_RUNNABLE;
> > +kvm_load_mpstate(env);
> > }
> > #endif
> > }
> > diff --git a/monitor.c b/monitor.c
> > index 7f0f5a9..dd8f2ca 100644
> > --- a/monitor.c
> > +++ b/monitor.c
> > @@ -350,6 +350,7 @@ static CPUState *mon_get_cpu(void)
> > mon_set_cpu(0);
> > }
> > cpu_synchronize_state(cur_mon->mon_cpu);
> > +kvm_save_mpstate(cur_mon->mon_cpu);
> > return cur_mon->mon_cpu;
> > }
> >
> > @@ -377,6 +378,7 @@ static void do_info_cpus(Monitor *mon)
> >
> > for(env = first_cpu; env != NULL; env = env->next_cpu) {
> > cpu_synchronize_state(env);
> > +kvm_save_mpstate(env);
> > monitor_printf(mon, "%c CPU #%d:",
> > (env == mon->mon_cpu) ? '*' : ' ',
> > env->cpu_index);
> > diff --git a/qemu-kvm.c b/qemu-kvm.c
> > index a104ab8..267222d 100644
> > --- a/qemu-kvm.c
> > +++ b/qemu-kvm.c
> > @@ -1609,11 +1609,6 @@ static void on_vcpu(CPUState *env, void (*func)(void
> > *data), void *data)
> > void kvm_arch_get_registers(CPUState *env)
> > {
> > kvm_arch_save_regs(env);
> > - kvm_arch_save_mpstate(env);
> > -#ifdef KVM_CAP_MP_STATE
> > - if (kvm_irqchip_in_kernel(kvm_context))
> > - env->halted = (env->mp_state == KVM_MP_STATE_HALTED);
> > -#endif
> > }
> >
> > static void do_kvm_cpu_synchronize_state(void *_env)
> > @@ -1707,6 +1702,10 @@ static void kvm_do_save_mpstate(void *_env)
> > CPUState *env = _env;
> >
> > kvm_arch_save_mpstate(env);
> > +#ifdef KVM_CAP_MP_STATE
> > +if (kvm_irqchip_in_kernel(kvm_context))
> > +env->halted = (env->mp_state == KVM_MP_STATE_HALTED);
> > +#endif
> > }
> >
> > void kvm_save_mpstate(CPUState *env)
> > diff --git a/qemu-kvm.h b/qemu-kvm.h
> > index d6748c7..e2a87b8 100644
> > --- a/qemu-kvm.h
> > +++ b/qemu-kvm.h
> > @@ -1186,7 +1186,6 @@ void kvm_arch_get_registers(CPUState *env);
> > static inline void kvm_arch_put_registers(CPUState *env)
> > {
> > kvm_load_registers(env);
> > -kvm_load_mpstate(env);
> > }
> >
> > void kvm_cpu_synchronize_state(CPUState *env);
> > diff --git a/target-i386/machine.c b/target-i386/machine.c
> > index e640dad..16d9c57 100644
> > --- a/target-i386/machine.c
> > +++ b/target-i386/machine.c
> > @@ -324,6 +324,7 @@ static void cpu_pre_save(void *opaque)
> > int i, bit;
> >
> > cpu_synchronize_state(env);
> > +kvm_save_mpstate(env);
> >
> > /* FPU */
> > env->fpus_vmstate = (env->fpus & ~0x3800) | (env->fpstt & 0x7) << 11;
> > @@ -385,6 +386,8 @@ static int cpu_post_load(void *opaque, int version_id)
> > }
> >
> > tlb_flush(env, 1);
> > +kvm_load_mpstate(env);
> > +
> > return 0;
> > }
> >
>
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[ kvm-Bugs-2896992 ] Intel PCI NIC passthrough problem
Bugs item #2896992, was opened at 2009-11-13 05:58 Message generated for change (Tracker Item Submitted) made by You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=893831&aid=2896992&group_id=180599 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Sergey Cheperis () Assigned to: Nobody/Anonymous (nobody) Summary: Intel PCI NIC passthrough problem Initial Comment: Host: - CPU Core2Duo E6300, Intel q45 chipset, VT-d enabled - Ubuntu 9.10 x86_64, kernel 2.6.31.4 recompiled with CONFIG_DMAR=y and CONFIG_INTR_REMAP=y according to http://www.linux-kvm.org/page/How_to_assign_devices_with_VT-d_in_KVM - in-kernel kvm module - qemu-kvm commit c04b2aebf50c7d8cba883b86d1b872ccfc8f2249 - intel_iommu=igfx_off - Qemu command line: /usr/local/bin/qemu-system-x86_64 -m 512 -k en-us -drive if=ide,file=/dev/server2/ubuntu,boot=on -cdrom /home/install/Linux/i386/ubuntu-9.10-desktop-i386.iso -boot d -vga std -pcidevice host=01:00.0 -net none -vnc :15 -daemonize Guest OSes: - Ubuntu 9.10 live CD i386, Windows Server 2003 i386, Windows Server 2008 x86_64, MacOS X 10.5.x i386 The device on the host: 01:00.0 Ethernet controller: Intel Corporation 82540EM Gigabit Ethernet Controller (rev 02) Subsystem: Intel Corporation Device 002e Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- https://sourceforge.net/tracker/?func=detail&atid=893831&aid=2896992&group_id=180599 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[ kvm-Bugs-2896992 ] Intel PCI NIC passthrough problem
Bugs item #2896992, was opened at 2009-11-13 05:58 Message generated for change (Comment added) made by You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=893831&aid=2896992&group_id=180599 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Sergey Cheperis () Assigned to: Nobody/Anonymous (nobody) Summary: Intel PCI NIC passthrough problem Initial Comment: Host: - CPU Core2Duo E6300, Intel q45 chipset, VT-d enabled - Ubuntu 9.10 x86_64, kernel 2.6.31.4 recompiled with CONFIG_DMAR=y and CONFIG_INTR_REMAP=y according to http://www.linux-kvm.org/page/How_to_assign_devices_with_VT-d_in_KVM - in-kernel kvm module - qemu-kvm commit c04b2aebf50c7d8cba883b86d1b872ccfc8f2249 - intel_iommu=igfx_off - Qemu command line: /usr/local/bin/qemu-system-x86_64 -m 512 -k en-us -drive if=ide,file=/dev/server2/ubuntu,boot=on -cdrom /home/install/Linux/i386/ubuntu-9.10-desktop-i386.iso -boot d -vga std -pcidevice host=01:00.0 -net none -vnc :15 -daemonize Guest OSes: - Ubuntu 9.10 live CD i386, Windows Server 2003 i386, Windows Server 2008 x86_64, MacOS X 10.5.x i386 The device on the host: 01:00.0 Ethernet controller: Intel Corporation 82540EM Gigabit Ethernet Controller (rev 02) Subsystem: Intel Corporation Device 002e Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- Comment By: Sergey Cheperis () Date: 2009-11-13 05:59 Message: I should note that I also tried to pass through the built-in Intel Ethernet adapter of this board and got the same. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=893831&aid=2896992&group_id=180599 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/1] Fix unable to detect libpci
commit 75fe7882 "Test for libpci, not only for header" compile a libpci
test file. But the pciutils with defined PCI_COMPRESSED_IDS also need zlib
when compile, otherwise the compile would fail, and detection fail then
CC: Juan Quintela
Signed-off-by: Sheng Yang
---
configure |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/configure b/configure
index 9d3b840..5b08367 100755
--- a/configure
+++ b/configure
@@ -1477,8 +1477,8 @@ if test $kvm_cap_device_assignment = "yes" ; then
#endif
int main(void) { struct pci_access a; pci_init(&a); return 0; }
EOF
- if compile_prog "" "-lpci" ; then
-libs_softmmu="-lpci $libs_softmmu"
+ if compile_prog "" "-lpci -lz" ; then
+libs_softmmu="-lpci -lz $libs_softmmu"
else
echo
echo "Error: libpci check failed"
--
1.5.4.5
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/1] Fix null DESTDIR in depmod execution
commit 52ea5897fa9fdadf0cc1a5242a23ce3dab599769 "Use DESTDIR consitently on
installation" add -b ${DESTDIR} to depmod. But the DESTDIR is default NULL,
then depmod would report error.
Set DESTDIR=/ as default
Signed-off-by: Sheng Yang
---
Makefile |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Makefile b/Makefile
index f406e3d..33ddc81 100644
--- a/Makefile
+++ b/Makefile
@@ -7,7 +7,7 @@ NONARCH_CONFIG = $(filter-out $(ARCH_CONFIG),X86 IA64)
KVERREL = $(patsubst /lib/modules/%/build,%,$(KERNELDIR))
-DESTDIR=
+DESTDIR = /
MAKEFILE_PRE = $(ARCH_DIR)/Makefile.pre
--
1.5.4.5
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Add a qemu interface for sharing memory between guests.
Hi Cam, >>>Here are the two patches for KVM describing what I have done. I am >>>continuing to work on it and still mulling a move to virtio. These >>>don't apply against the current tree, but I can provide those patches >>>if you would like to see them. >>>http://patchwork.kernel.org/patch/38355/ >>>http://patchwork.kernel.org/patch/38347/ >>>We're you interested in using the shared memory for something in >>>particular or were you just looking for a to-do task to pick up? >>>Let me know if you have any questions, >>>Cheers, >>>Cam I just saw your the mail. I was just going through the To-Do task to pick up and work on a task. I was going through the paper presented by Francois Diakhate´on Inter-VM communications and tinkering with the code. Would be great if you could send me the patch for the running kernel. Thanks, Siva. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
