KVM Archive on lore.kernel.org
 help / color / Atom feed
* [kvm-unit-tests PATCHv2] unittests.cfg: Increase timeout for apic test
@ 2020-10-13  9:12 Po-Hsu Lin
  2020-10-15 15:59 ` Vitaly Kuznetsov
  0 siblings, 1 reply; 12+ messages in thread
From: Po-Hsu Lin @ 2020-10-13  9:12 UTC (permalink / raw)
  To: kvm, pbonzini; +Cc: po-hsu.lin

We found that on Azure cloud hyperv instance Standard_D48_v3, it will
take about 45 seconds to run this apic test.

It takes even longer (about 150 seconds) to run inside a KVM instance
VM.Standard2.1 on Oracle cloud.

Bump the timeout threshold to give it a chance to finish.

Signed-off-by: Po-Hsu Lin <po-hsu.lin@canonical.com>
---
 x86/unittests.cfg | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/x86/unittests.cfg b/x86/unittests.cfg
index 872d679..c72a659 100644
--- a/x86/unittests.cfg
+++ b/x86/unittests.cfg
@@ -41,7 +41,7 @@ file = apic.flat
 smp = 2
 extra_params = -cpu qemu64,+x2apic,+tsc-deadline
 arch = x86_64
-timeout = 30
+timeout = 240
 
 [ioapic]
 file = ioapic.flat
-- 
2.25.1


^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [kvm-unit-tests PATCHv2] unittests.cfg: Increase timeout for apic test
  2020-10-13  9:12 [kvm-unit-tests PATCHv2] unittests.cfg: Increase timeout for apic test Po-Hsu Lin
@ 2020-10-15 15:59 ` Vitaly Kuznetsov
  2020-10-15 16:35   ` Sean Christopherson
  0 siblings, 1 reply; 12+ messages in thread
From: Vitaly Kuznetsov @ 2020-10-15 15:59 UTC (permalink / raw)
  To: Po-Hsu Lin; +Cc: po-hsu.lin, kvm, pbonzini

Po-Hsu Lin <po-hsu.lin@canonical.com> writes:

> We found that on Azure cloud hyperv instance Standard_D48_v3, it will
> take about 45 seconds to run this apic test.
>
> It takes even longer (about 150 seconds) to run inside a KVM instance
> VM.Standard2.1 on Oracle cloud.
>
> Bump the timeout threshold to give it a chance to finish.
>
> Signed-off-by: Po-Hsu Lin <po-hsu.lin@canonical.com>
> ---
>  x86/unittests.cfg | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/x86/unittests.cfg b/x86/unittests.cfg
> index 872d679..c72a659 100644
> --- a/x86/unittests.cfg
> +++ b/x86/unittests.cfg
> @@ -41,7 +41,7 @@ file = apic.flat
>  smp = 2
>  extra_params = -cpu qemu64,+x2apic,+tsc-deadline
>  arch = x86_64
> -timeout = 30
> +timeout = 240
>  
>  [ioapic]
>  file = ioapic.flat

AFAIR the default timeout for tests where timeout it not set explicitly
is 90s so don't you need to also modify it for other tests like
'apic-split', 'ioapic', 'ioapic-split', ... ?

I was thinking about introducing a 'timeout multiplier' or something to
run_tests.sh for running in slow (read: nested) environments, doing that
would allow us to keep reasonably small timeouts by default. This is
somewhat important as tests tend to hang and waiting for 4 minutes every
time is not great.

-- 
Vitaly


^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [kvm-unit-tests PATCHv2] unittests.cfg: Increase timeout for apic test
  2020-10-15 15:59 ` Vitaly Kuznetsov
@ 2020-10-15 16:35   ` Sean Christopherson
  2020-10-16 17:02     ` Paolo Bonzini
  2020-10-19 11:32     ` Vitaly Kuznetsov
  0 siblings, 2 replies; 12+ messages in thread
From: Sean Christopherson @ 2020-10-15 16:35 UTC (permalink / raw)
  To: Vitaly Kuznetsov; +Cc: Po-Hsu Lin, kvm, pbonzini

On Thu, Oct 15, 2020 at 05:59:52PM +0200, Vitaly Kuznetsov wrote:
> Po-Hsu Lin <po-hsu.lin@canonical.com> writes:
> 
> > We found that on Azure cloud hyperv instance Standard_D48_v3, it will
> > take about 45 seconds to run this apic test.
> >
> > It takes even longer (about 150 seconds) to run inside a KVM instance
> > VM.Standard2.1 on Oracle cloud.
> >
> > Bump the timeout threshold to give it a chance to finish.
> >
> > Signed-off-by: Po-Hsu Lin <po-hsu.lin@canonical.com>
> > ---
> >  x86/unittests.cfg | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/x86/unittests.cfg b/x86/unittests.cfg
> > index 872d679..c72a659 100644
> > --- a/x86/unittests.cfg
> > +++ b/x86/unittests.cfg
> > @@ -41,7 +41,7 @@ file = apic.flat
> >  smp = 2
> >  extra_params = -cpu qemu64,+x2apic,+tsc-deadline
> >  arch = x86_64
> > -timeout = 30
> > +timeout = 240
> >  
> >  [ioapic]
> >  file = ioapic.flat
> 
> AFAIR the default timeout for tests where timeout it not set explicitly
> is 90s so don't you need to also modify it for other tests like
> 'apic-split', 'ioapic', 'ioapic-split', ... ?
> 
> I was thinking about introducing a 'timeout multiplier' or something to
> run_tests.sh for running in slow (read: nested) environments, doing that
> would allow us to keep reasonably small timeouts by default. This is
> somewhat important as tests tend to hang and waiting for 4 minutes every
> time is not great.

I would much prefer to go in the other direction and make tests like APIC not
do so many loops (in a nested environment?).  The port80 test in particular is
an absolute waste of time.

E.g. does running 1M loops in test_multiple_nmi() really add value versus
say 10k or 100k loops?

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [kvm-unit-tests PATCHv2] unittests.cfg: Increase timeout for apic test
  2020-10-15 16:35   ` Sean Christopherson
@ 2020-10-16 17:02     ` Paolo Bonzini
  2020-10-16 17:40       ` Andrew Jones
  2020-10-19 11:32     ` Vitaly Kuznetsov
  1 sibling, 1 reply; 12+ messages in thread
From: Paolo Bonzini @ 2020-10-16 17:02 UTC (permalink / raw)
  To: Sean Christopherson, Vitaly Kuznetsov; +Cc: Po-Hsu Lin, kvm

On 15/10/20 18:35, Sean Christopherson wrote:
> The port80 test in particular is an absolute waste of time.
> 

True, OTOH it was meant as a benchmark.  I think we can just delete it
or move it to vmexit.

Paolo


^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [kvm-unit-tests PATCHv2] unittests.cfg: Increase timeout for apic test
  2020-10-16 17:02     ` Paolo Bonzini
@ 2020-10-16 17:40       ` Andrew Jones
  2020-10-20  5:53         ` Thomas Huth
  0 siblings, 1 reply; 12+ messages in thread
From: Andrew Jones @ 2020-10-16 17:40 UTC (permalink / raw)
  To: Paolo Bonzini; +Cc: Sean Christopherson, Vitaly Kuznetsov, Po-Hsu Lin, kvm

On Fri, Oct 16, 2020 at 07:02:57PM +0200, Paolo Bonzini wrote:
> On 15/10/20 18:35, Sean Christopherson wrote:
> > The port80 test in particular is an absolute waste of time.
> > 
> 
> True, OTOH it was meant as a benchmark.  I think we can just delete it
> or move it to vmexit.
>

If you want to keep the code, but only run it manually sometimes,
then you can mark the test as nodefault.

Thanks,
drew 


^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [kvm-unit-tests PATCHv2] unittests.cfg: Increase timeout for apic test
  2020-10-15 16:35   ` Sean Christopherson
  2020-10-16 17:02     ` Paolo Bonzini
@ 2020-10-19 11:32     ` Vitaly Kuznetsov
  2020-10-19 16:37       ` Christopherson, Sean J
  1 sibling, 1 reply; 12+ messages in thread
From: Vitaly Kuznetsov @ 2020-10-19 11:32 UTC (permalink / raw)
  To: Sean Christopherson; +Cc: Po-Hsu Lin, kvm, pbonzini

Sean Christopherson <sean.j.christopherson@intel.com> writes:

> On Thu, Oct 15, 2020 at 05:59:52PM +0200, Vitaly Kuznetsov wrote:
>> Po-Hsu Lin <po-hsu.lin@canonical.com> writes:
>> 
>> > We found that on Azure cloud hyperv instance Standard_D48_v3, it will
>> > take about 45 seconds to run this apic test.
>> >
>> > It takes even longer (about 150 seconds) to run inside a KVM instance
>> > VM.Standard2.1 on Oracle cloud.
>> >
>> > Bump the timeout threshold to give it a chance to finish.
>> >
>> > Signed-off-by: Po-Hsu Lin <po-hsu.lin@canonical.com>
>> > ---
>> >  x86/unittests.cfg | 2 +-
>> >  1 file changed, 1 insertion(+), 1 deletion(-)
>> >
>> > diff --git a/x86/unittests.cfg b/x86/unittests.cfg
>> > index 872d679..c72a659 100644
>> > --- a/x86/unittests.cfg
>> > +++ b/x86/unittests.cfg
>> > @@ -41,7 +41,7 @@ file = apic.flat
>> >  smp = 2
>> >  extra_params = -cpu qemu64,+x2apic,+tsc-deadline
>> >  arch = x86_64
>> > -timeout = 30
>> > +timeout = 240
>> >  
>> >  [ioapic]
>> >  file = ioapic.flat
>> 
>> AFAIR the default timeout for tests where timeout it not set explicitly
>> is 90s so don't you need to also modify it for other tests like
>> 'apic-split', 'ioapic', 'ioapic-split', ... ?
>> 
>> I was thinking about introducing a 'timeout multiplier' or something to
>> run_tests.sh for running in slow (read: nested) environments, doing that
>> would allow us to keep reasonably small timeouts by default. This is
>> somewhat important as tests tend to hang and waiting for 4 minutes every
>> time is not great.
>
> I would much prefer to go in the other direction and make tests like APIC not
> do so many loops (in a nested environment?). The port80 test in particular is
> an absolute waste of time.

I don't think these two suggestions are opposite. Yes, making tests run fast
is good, however, some of the tests are doomed to be slow. E.g. running
VMX testsuite while nested (leaving aside the question about who needs
three level nesting) is always going to be much slower than on bare metal.

>
> E.g. does running 1M loops in test_multiple_nmi() really add value versus
> say 10k or 100k loops?

Oddly enough, I vaguely remember this particular test hanging
*sometimes* after a few thousand loops but I don't remember any
details.

-- 
Vitaly


^ permalink raw reply	[flat|nested] 12+ messages in thread

* RE: [kvm-unit-tests PATCHv2] unittests.cfg: Increase timeout for apic test
  2020-10-19 11:32     ` Vitaly Kuznetsov
@ 2020-10-19 16:37       ` Christopherson, Sean J
  2020-10-19 16:52         ` Nadav Amit
  0 siblings, 1 reply; 12+ messages in thread
From: Christopherson, Sean J @ 2020-10-19 16:37 UTC (permalink / raw)
  To: Vitaly Kuznetsov; +Cc: Po-Hsu Lin, kvm, pbonzini

On Mon, Oct 19, 2020 at 01:32:00PM +0200, Vitaly Kuznetsov wrote:
> Sean Christopherson <sean.j.christopherson@intel.com> writes:
> >> > diff --git a/x86/unittests.cfg b/x86/unittests.cfg
> >> > index 872d679..c72a659 100644
> >> > --- a/x86/unittests.cfg
> >> > +++ b/x86/unittests.cfg
> >> > @@ -41,7 +41,7 @@ file = apic.flat
> >> >  smp = 2
> >> >  extra_params = -cpu qemu64,+x2apic,+tsc-deadline
> >> >  arch = x86_64
> >> > -timeout = 30
> >> > +timeout = 240
> >> >
> >> >  [ioapic]
> >> >  file = ioapic.flat
> >>
> >> AFAIR the default timeout for tests where timeout it not set explicitly
> >> is 90s so don't you need to also modify it for other tests like
> >> 'apic-split', 'ioapic', 'ioapic-split', ... ?
> >>
> >> I was thinking about introducing a 'timeout multiplier' or something to
> >> run_tests.sh for running in slow (read: nested) environments, doing that
> >> would allow us to keep reasonably small timeouts by default. This is
> >> somewhat important as tests tend to hang and waiting for 4 minutes every
> >> time is not great.
> >
> > I would much prefer to go in the other direction and make tests like APIC not
> > do so many loops (in a nested environment?). The port80 test in particular is
> > an absolute waste of time.
>
> I don't think these two suggestions are opposite. Yes, making tests run fast
> is good, however, some of the tests are doomed to be slow. E.g. running
> VMX testsuite while nested (leaving aside the question about who needs
> three level nesting) is always going to be much slower than on bare metal.

Ya, I was specifically referring to tests that arbitrarily choose a high loop
count, without any real/documented justification for running millions of loops.

> > E.g. does running 1M loops in test_multiple_nmi() really add value versus
> > say 10k or 100k loops?
>
> Oddly enough, I vaguely remember this particular test hanging
> *sometimes* after a few thousand loops but I don't remember any
> details.

Thousands still ain't millions :-D.

IMO, the unit tests should sit between a smoke test and a long running,
intensive stress test, i.e. the default config shouldn't be trying to find
literal one-in-a-million bugs on every run.

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [kvm-unit-tests PATCHv2] unittests.cfg: Increase timeout for apic test
  2020-10-19 16:37       ` Christopherson, Sean J
@ 2020-10-19 16:52         ` Nadav Amit
  2020-10-20  8:48           ` Paolo Bonzini
  0 siblings, 1 reply; 12+ messages in thread
From: Nadav Amit @ 2020-10-19 16:52 UTC (permalink / raw)
  To: Christopherson, Sean J; +Cc: Vitaly Kuznetsov, Po-Hsu Lin, kvm, pbonzini

> On Oct 19, 2020, at 9:37 AM, Christopherson, Sean J <sean.j.christopherson@intel.com> wrote:
> 
> On Mon, Oct 19, 2020 at 01:32:00PM +0200, Vitaly Kuznetsov wrote:
>> Sean Christopherson <sean.j.christopherson@intel.com> writes:
>>> E.g. does running 1M loops in test_multiple_nmi() really add value versus
>>> say 10k or 100k loops?
>> 
>> Oddly enough, I vaguely remember this particular test hanging
>> *sometimes* after a few thousand loops but I don't remember any
>> details.
> 
> Thousands still ain't millions :-D.
> 
> IMO, the unit tests should sit between a smoke test and a long running,
> intensive stress test, i.e. the default config shouldn't be trying to find
> literal one-in-a-million bugs on every run.

IIRC, this test failed on VMware, and according to our previous discussions,
does not follow the SDM as NMIs might be collapsed [1].

[1] https://marc.info/?l=kvm&m=145876994031502&w=2


^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [kvm-unit-tests PATCHv2] unittests.cfg: Increase timeout for apic test
  2020-10-16 17:40       ` Andrew Jones
@ 2020-10-20  5:53         ` Thomas Huth
  2020-10-20  8:49           ` Andrew Jones
  0 siblings, 1 reply; 12+ messages in thread
From: Thomas Huth @ 2020-10-20  5:53 UTC (permalink / raw)
  To: Andrew Jones, Paolo Bonzini
  Cc: Sean Christopherson, Vitaly Kuznetsov, Po-Hsu Lin, kvm

On 16/10/2020 19.40, Andrew Jones wrote:
> On Fri, Oct 16, 2020 at 07:02:57PM +0200, Paolo Bonzini wrote:
>> On 15/10/20 18:35, Sean Christopherson wrote:
>>> The port80 test in particular is an absolute waste of time.
>>>
>>
>> True, OTOH it was meant as a benchmark.  I think we can just delete it
>> or move it to vmexit.
>>
> 
> If you want to keep the code, but only run it manually sometimes,
> then you can mark the test as nodefault.

Please let's avoid that. Code that does not get run by default tends to
bitrot. I suggest to decrease the amount of loops by default, and if
somebody still wants to run this as a kind of benchmark, maybe the amount of
loops could be made configurable? (i.e. so that you could control it via an
argv[] parameter?)

 Thomas


^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [kvm-unit-tests PATCHv2] unittests.cfg: Increase timeout for apic test
  2020-10-19 16:52         ` Nadav Amit
@ 2020-10-20  8:48           ` Paolo Bonzini
  2020-10-20 15:05             ` Christopherson, Sean J
  0 siblings, 1 reply; 12+ messages in thread
From: Paolo Bonzini @ 2020-10-20  8:48 UTC (permalink / raw)
  To: Nadav Amit, Christopherson, Sean J; +Cc: Vitaly Kuznetsov, Po-Hsu Lin, kvm

On 19/10/20 18:52, Nadav Amit wrote:
> IIRC, this test failed on VMware, and according to our previous discussions,
> does not follow the SDM as NMIs might be collapsed [1].
> 
> [1] https://marc.info/?l=kvm&m=145876994031502&w=2

So should KVM be changed to always collapse NMIs, like this?

diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 105261402921..4032336ecba3 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -668,7 +668,7 @@ EXPORT_SYMBOL_GPL(kvm_inject_emulated_page_fault);

 void kvm_inject_nmi(struct kvm_vcpu *vcpu)
 {
-	atomic_inc(&vcpu->arch.nmi_queued);
+	atomic_set(&vcpu->arch.nmi_queued, 1);
 	kvm_make_request(KVM_REQ_NMI, vcpu);
 }
 EXPORT_SYMBOL_GPL(kvm_inject_nmi);
@@ -8304,18 +8304,7 @@ static void inject_pending_event(struct kvm_vcpu
*vcpu, bool *req_immediate_exit

 static void process_nmi(struct kvm_vcpu *vcpu)
 {
-	unsigned limit = 2;
-
-	/*
-	 * x86 is limited to one NMI running, and one NMI pending after it.
-	 * If an NMI is already in progress, limit further NMIs to just one.
-	 * Otherwise, allow two (and we'll inject the first one immediately).
-	 */
-	if (kvm_x86_ops.get_nmi_mask(vcpu) || vcpu->arch.nmi_injected)
-		limit = 1;
-
-	vcpu->arch.nmi_pending += atomic_xchg(&vcpu->arch.nmi_queued, 0);
-	vcpu->arch.nmi_pending = min(vcpu->arch.nmi_pending, limit);
+	vcpu->arch.nmi_pending |= atomic_xchg(&vcpu->arch.nmi_queued, 0);
 	kvm_make_request(KVM_REQ_EVENT, vcpu);
 }


Paolo


^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [kvm-unit-tests PATCHv2] unittests.cfg: Increase timeout for apic test
  2020-10-20  5:53         ` Thomas Huth
@ 2020-10-20  8:49           ` Andrew Jones
  0 siblings, 0 replies; 12+ messages in thread
From: Andrew Jones @ 2020-10-20  8:49 UTC (permalink / raw)
  To: Thomas Huth
  Cc: Paolo Bonzini, Sean Christopherson, Vitaly Kuznetsov, Po-Hsu Lin, kvm

On Tue, Oct 20, 2020 at 07:53:49AM +0200, Thomas Huth wrote:
> On 16/10/2020 19.40, Andrew Jones wrote:
> > On Fri, Oct 16, 2020 at 07:02:57PM +0200, Paolo Bonzini wrote:
> >> On 15/10/20 18:35, Sean Christopherson wrote:
> >>> The port80 test in particular is an absolute waste of time.
> >>>
> >>
> >> True, OTOH it was meant as a benchmark.  I think we can just delete it
> >> or move it to vmexit.
> >>
> > 
> > If you want to keep the code, but only run it manually sometimes,
> > then you can mark the test as nodefault.
> 
> Please let's avoid that. Code that does not get run by default tends to
> bitrot. I suggest to decrease the amount of loops by default, and if
> somebody still wants to run this as a kind of benchmark, maybe the amount of
> loops could be made configurable? (i.e. so that you could control it via an
> argv[] parameter?)
>

I think both make sense. Making the number of loops variable is a good
idea in order to keep the test running in CI in a reasonable amount of
time (the timeout can also be adjusted by the CI runner, of course). Also,
marking the test as nodefault makes sense if nobody really cares about
the output unless they're specifically doing some benchmarking. Nothing
stops travis or other CI from running nodefault tests, they just have to
be explicitly requested.

Thanks,
drew 


^ permalink raw reply	[flat|nested] 12+ messages in thread

* RE: [kvm-unit-tests PATCHv2] unittests.cfg: Increase timeout for apic test
  2020-10-20  8:48           ` Paolo Bonzini
@ 2020-10-20 15:05             ` Christopherson, Sean J
  0 siblings, 0 replies; 12+ messages in thread
From: Christopherson, Sean J @ 2020-10-20 15:05 UTC (permalink / raw)
  To: Paolo Bonzini, Nadav Amit; +Cc: Vitaly Kuznetsov, Po-Hsu Lin, kvm

On Tue, Oct 20, 2020 at 10:48:24AM +0200, Paolo Bonzini wrote:
> On 19/10/20 18:52, Nadav Amit wrote:
> > IIRC, this test failed on VMware, and according to our previous discussions,
> > does not follow the SDM as NMIs might be collapsed [1].
> >
> > [1] https://marc.info/?l=kvm&m=145876994031502&w=2
>
> So should KVM be changed to always collapse NMIs, like this?

No, Nadav's failure is not on bare metal.  The test passes on bare metal.

Quoting myself:

  Architecturally I don't think there are any guarantees regarding
  simultaneous NMIs, but practically speaking the probability of NMIs
  being collapsed (on hardware) when NMIs aren't blocked is nil.  So while
  it may be architecturally legal for a VMM to drop an NMI in this case,
  it's reasonable for software to expect two NMIs to be received.


[*] https://lkml.kernel.org/r/A7453828-BD8E-43F8-B140-6D660535B7F2@gmail.com

> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index 105261402921..4032336ecba3 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -668,7 +668,7 @@ EXPORT_SYMBOL_GPL(kvm_inject_emulated_page_fault);
>
>  void kvm_inject_nmi(struct kvm_vcpu *vcpu)
>  {
> -     atomic_inc(&vcpu->arch.nmi_queued);
> +     atomic_set(&vcpu->arch.nmi_queued, 1);
>       kvm_make_request(KVM_REQ_NMI, vcpu);
>  }
>  EXPORT_SYMBOL_GPL(kvm_inject_nmi);
> @@ -8304,18 +8304,7 @@ static void inject_pending_event(struct kvm_vcpu
> *vcpu, bool *req_immediate_exit
>
>  static void process_nmi(struct kvm_vcpu *vcpu)
>  {
> -     unsigned limit = 2;
> -
> -     /*
> -      * x86 is limited to one NMI running, and one NMI pending after it.
> -      * If an NMI is already in progress, limit further NMIs to just one.
> -      * Otherwise, allow two (and we'll inject the first one immediately).
> -      */
> -     if (kvm_x86_ops.get_nmi_mask(vcpu) || vcpu->arch.nmi_injected)
> -             limit = 1;
> -
> -     vcpu->arch.nmi_pending += atomic_xchg(&vcpu->arch.nmi_queued, 0);
> -     vcpu->arch.nmi_pending = min(vcpu->arch.nmi_pending, limit);
> +     vcpu->arch.nmi_pending |= atomic_xchg(&vcpu->arch.nmi_queued, 0);
>       kvm_make_request(KVM_REQ_EVENT, vcpu);
>  }

^ permalink raw reply	[flat|nested] 12+ messages in thread

end of thread, back to index

Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-10-13  9:12 [kvm-unit-tests PATCHv2] unittests.cfg: Increase timeout for apic test Po-Hsu Lin
2020-10-15 15:59 ` Vitaly Kuznetsov
2020-10-15 16:35   ` Sean Christopherson
2020-10-16 17:02     ` Paolo Bonzini
2020-10-16 17:40       ` Andrew Jones
2020-10-20  5:53         ` Thomas Huth
2020-10-20  8:49           ` Andrew Jones
2020-10-19 11:32     ` Vitaly Kuznetsov
2020-10-19 16:37       ` Christopherson, Sean J
2020-10-19 16:52         ` Nadav Amit
2020-10-20  8:48           ` Paolo Bonzini
2020-10-20 15:05             ` Christopherson, Sean J

KVM Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/kvm/0 kvm/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 kvm kvm/ https://lore.kernel.org/kvm \
		kvm@vger.kernel.org
	public-inbox-index kvm

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.kvm


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git