* Re: [Qemu-devel] [PATCH v12 rebased] kvm: notify host when the guest is panicked [not found] ` <20130228085425.GA16362@localhost.localdomain> @ 2013-03-02 0:03 ` Marcelo Tosatti 2013-03-03 13:00 ` Gleb Natapov 0 siblings, 1 reply; 6+ messages in thread From: Marcelo Tosatti @ 2013-03-02 0:03 UTC (permalink / raw) To: Hu Tao Cc: Andrew Jones, Gleb Natapov, kvm list, Jan Kiszka, qemu-devel, linux-kernel@vger.kernel.org, Blue Swirl, Sasha Levin, Luiz Capitulino, KAMEZAWA Hiroyuki On Thu, Feb 28, 2013 at 04:54:25PM +0800, Hu Tao wrote: > > > diff --git a/arch/x86/include/uapi/asm/kvm_para.h b/arch/x86/include/uapi/asm/kvm_para.h > > > index 06fdbd9..c15ef33 100644 > > > --- a/arch/x86/include/uapi/asm/kvm_para.h > > > +++ b/arch/x86/include/uapi/asm/kvm_para.h > > > @@ -96,5 +96,7 @@ struct kvm_vcpu_pv_apf_data { > > > #define KVM_PV_EOI_ENABLED KVM_PV_EOI_MASK > > > #define KVM_PV_EOI_DISABLED 0x0 > > > > > > +#define KVM_PV_EVENT_PORT (0x505UL) > > > + > > > > No need for the ioport to be hard coded. What are the options to > > communicate an address to the guest? An MSR, via ACPI? > > I'm not quite understanding here. By 'address', you mean an ioport? > how to communicate an address? (I have little knowledge about ACPI) Yes, the ioport. The address of the ioport should not be fixed (for example future emulated board could use that fixed ioport address, 0x505UL). One option is to pass the address via an MSR. Yes, that is probably the best option because there is no dependency on ACPI. > > "pv-event" is a bad name for an interface which is specific to notify > > panic events. Please use pv-panic everywhere. > > panic event is one of the events supported. Can we keep the name? > > Call the initialization code from kvm_guest_init, only one function is > > necessary. > > At the point of kvm_guest_init, rqeust_region (called by > kvm_pv_event_init) will block, so the guest kernel won't up. Why does it block? > > > #define PANIC_TIMER_STEP 100 > > > #define PANIC_BLINK_SPD 18 > > > @@ -132,6 +133,9 @@ void panic(const char *fmt, ...) > > > if (!panic_blink) > > > panic_blink = no_blink; > > > > > > + if (kvm_pv_event_enabled()) > > > + panic_timeout = 0; > > > + > > > > What is the rationale behind this? > > This is a hack to disable reset_on_panic if user enables > pv-event. Condition it to kvm_pv_event_enabled() directly? ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Qemu-devel] [PATCH v12 rebased] kvm: notify host when the guest is panicked 2013-03-02 0:03 ` [Qemu-devel] [PATCH v12 rebased] kvm: notify host when the guest is panicked Marcelo Tosatti @ 2013-03-03 13:00 ` Gleb Natapov 2013-03-03 22:29 ` Marcelo Tosatti 0 siblings, 1 reply; 6+ messages in thread From: Gleb Natapov @ 2013-03-03 13:00 UTC (permalink / raw) To: Marcelo Tosatti Cc: Andrew Jones, kvm list, Hu Tao, qemu-devel, linux-kernel@vger.kernel.org, Blue Swirl, Sasha Levin, Jan Kiszka, Luiz Capitulino, KAMEZAWA Hiroyuki On Fri, Mar 01, 2013 at 09:03:12PM -0300, Marcelo Tosatti wrote: > On Thu, Feb 28, 2013 at 04:54:25PM +0800, Hu Tao wrote: > > > > diff --git a/arch/x86/include/uapi/asm/kvm_para.h b/arch/x86/include/uapi/asm/kvm_para.h > > > > index 06fdbd9..c15ef33 100644 > > > > --- a/arch/x86/include/uapi/asm/kvm_para.h > > > > +++ b/arch/x86/include/uapi/asm/kvm_para.h > > > > @@ -96,5 +96,7 @@ struct kvm_vcpu_pv_apf_data { > > > > #define KVM_PV_EOI_ENABLED KVM_PV_EOI_MASK > > > > #define KVM_PV_EOI_DISABLED 0x0 > > > > > > > > +#define KVM_PV_EVENT_PORT (0x505UL) > > > > + > > > > > > No need for the ioport to be hard coded. What are the options to > > > communicate an address to the guest? An MSR, via ACPI? > > > > I'm not quite understanding here. By 'address', you mean an ioport? > > how to communicate an address? (I have little knowledge about ACPI) > > Yes, the ioport. The address of the ioport should not be fixed (for > example future emulated board could use that fixed ioport address, > 0x505UL). > > One option is to pass the address via an MSR. Yes, that is probably the > best option because there is no dependency on ACPI. > Why dependency on ACPI is problematic? ACPI is the standard way on x86 to enumerate platform devices. Passing it through MSR makes this panic device CPU interface which it is not. And since relying on #GP to detect valid MSRs is not good interface we will have to guard it by cpuid bit. -- Gleb. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Qemu-devel] [PATCH v12 rebased] kvm: notify host when the guest is panicked 2013-03-03 13:00 ` Gleb Natapov @ 2013-03-03 22:29 ` Marcelo Tosatti 2013-03-04 17:49 ` Gleb Natapov 0 siblings, 1 reply; 6+ messages in thread From: Marcelo Tosatti @ 2013-03-03 22:29 UTC (permalink / raw) To: Gleb Natapov Cc: Andrew Jones, kvm list, Hu Tao, qemu-devel, linux-kernel@vger.kernel.org, Blue Swirl, Sasha Levin, Jan Kiszka, Luiz Capitulino, KAMEZAWA Hiroyuki On Sun, Mar 03, 2013 at 03:00:22PM +0200, Gleb Natapov wrote: > On Fri, Mar 01, 2013 at 09:03:12PM -0300, Marcelo Tosatti wrote: > > On Thu, Feb 28, 2013 at 04:54:25PM +0800, Hu Tao wrote: > > > > > diff --git a/arch/x86/include/uapi/asm/kvm_para.h b/arch/x86/include/uapi/asm/kvm_para.h > > > > > index 06fdbd9..c15ef33 100644 > > > > > --- a/arch/x86/include/uapi/asm/kvm_para.h > > > > > +++ b/arch/x86/include/uapi/asm/kvm_para.h > > > > > @@ -96,5 +96,7 @@ struct kvm_vcpu_pv_apf_data { > > > > > #define KVM_PV_EOI_ENABLED KVM_PV_EOI_MASK > > > > > #define KVM_PV_EOI_DISABLED 0x0 > > > > > > > > > > +#define KVM_PV_EVENT_PORT (0x505UL) > > > > > + > > > > > > > > No need for the ioport to be hard coded. What are the options to > > > > communicate an address to the guest? An MSR, via ACPI? > > > > > > I'm not quite understanding here. By 'address', you mean an ioport? > > > how to communicate an address? (I have little knowledge about ACPI) > > > > Yes, the ioport. The address of the ioport should not be fixed (for > > example future emulated board could use that fixed ioport address, > > 0x505UL). > > > > One option is to pass the address via an MSR. Yes, that is probably the > > best option because there is no dependency on ACPI. > > > Why dependency on ACPI is problematic? ACPI is the standard way on x86 > to enumerate platform devices. Passing it through MSR makes this panic > device CPU interface which it is not. And since relying on #GP to detect > valid MSRs is not good interface we will have to guard it by cpuid bit. > > -- > Gleb. KVM guest <-> KVM host interface is not dependent on ACPI, so far. Say, its possible to use a Linux guest without ACPI and have KVM paravirt fully functional. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Qemu-devel] [PATCH v12 rebased] kvm: notify host when the guest is panicked 2013-03-03 22:29 ` Marcelo Tosatti @ 2013-03-04 17:49 ` Gleb Natapov [not found] ` <20130304204348.GB20761@amt.cnet> 0 siblings, 1 reply; 6+ messages in thread From: Gleb Natapov @ 2013-03-04 17:49 UTC (permalink / raw) To: Marcelo Tosatti Cc: Andrew Jones, kvm list, Hu Tao, qemu-devel, linux-kernel@vger.kernel.org, Blue Swirl, Sasha Levin, Jan Kiszka, Luiz Capitulino, KAMEZAWA Hiroyuki On Sun, Mar 03, 2013 at 07:29:53PM -0300, Marcelo Tosatti wrote: > On Sun, Mar 03, 2013 at 03:00:22PM +0200, Gleb Natapov wrote: > > On Fri, Mar 01, 2013 at 09:03:12PM -0300, Marcelo Tosatti wrote: > > > On Thu, Feb 28, 2013 at 04:54:25PM +0800, Hu Tao wrote: > > > > > > diff --git a/arch/x86/include/uapi/asm/kvm_para.h b/arch/x86/include/uapi/asm/kvm_para.h > > > > > > index 06fdbd9..c15ef33 100644 > > > > > > --- a/arch/x86/include/uapi/asm/kvm_para.h > > > > > > +++ b/arch/x86/include/uapi/asm/kvm_para.h > > > > > > @@ -96,5 +96,7 @@ struct kvm_vcpu_pv_apf_data { > > > > > > #define KVM_PV_EOI_ENABLED KVM_PV_EOI_MASK > > > > > > #define KVM_PV_EOI_DISABLED 0x0 > > > > > > > > > > > > +#define KVM_PV_EVENT_PORT (0x505UL) > > > > > > + > > > > > > > > > > No need for the ioport to be hard coded. What are the options to > > > > > communicate an address to the guest? An MSR, via ACPI? > > > > > > > > I'm not quite understanding here. By 'address', you mean an ioport? > > > > how to communicate an address? (I have little knowledge about ACPI) > > > > > > Yes, the ioport. The address of the ioport should not be fixed (for > > > example future emulated board could use that fixed ioport address, > > > 0x505UL). > > > > > > One option is to pass the address via an MSR. Yes, that is probably the > > > best option because there is no dependency on ACPI. > > > > > Why dependency on ACPI is problematic? ACPI is the standard way on x86 > > to enumerate platform devices. Passing it through MSR makes this panic > > device CPU interface which it is not. And since relying on #GP to detect > > valid MSRs is not good interface we will have to guard it by cpuid bit. > > > > -- > > Gleb. > > KVM guest <-> KVM host interface is not dependent on ACPI, so far. Say, > its possible to use a Linux guest without ACPI and have KVM paravirt > fully functional. This is not KVM guest <-> KVM host interface though. This is yet another device. We could implement real impi device that have crash reporting capability, but decided to go with something simpler. Without ACPI guest will not be able to power down itself too, but this is not the reason for us to introduce non-ACPI interface for power down. -- Gleb. ^ permalink raw reply [flat|nested] 6+ messages in thread
[parent not found: <20130304204348.GB20761@amt.cnet>]
* Re: [Qemu-devel] [PATCH v12 rebased] kvm: notify host when the guest is panicked [not found] ` <20130304204348.GB20761@amt.cnet> @ 2013-03-05 7:05 ` Gleb Natapov 0 siblings, 0 replies; 6+ messages in thread From: Gleb Natapov @ 2013-03-05 7:05 UTC (permalink / raw) To: Marcelo Tosatti Cc: Andrew Jones, kvm list, Hu Tao, qemu-devel, linux-kernel@vger.kernel.org, Blue Swirl, Sasha Levin, Jan Kiszka, Luiz Capitulino, KAMEZAWA Hiroyuki On Mon, Mar 04, 2013 at 05:43:48PM -0300, Marcelo Tosatti wrote: > On Mon, Mar 04, 2013 at 07:49:13PM +0200, Gleb Natapov wrote: > > On Sun, Mar 03, 2013 at 07:29:53PM -0300, Marcelo Tosatti wrote: > > > On Sun, Mar 03, 2013 at 03:00:22PM +0200, Gleb Natapov wrote: > > > > On Fri, Mar 01, 2013 at 09:03:12PM -0300, Marcelo Tosatti wrote: > > > > > On Thu, Feb 28, 2013 at 04:54:25PM +0800, Hu Tao wrote: > > > > > > > > diff --git a/arch/x86/include/uapi/asm/kvm_para.h b/arch/x86/include/uapi/asm/kvm_para.h > > > > > > > > index 06fdbd9..c15ef33 100644 > > > > > > > > --- a/arch/x86/include/uapi/asm/kvm_para.h > > > > > > > > +++ b/arch/x86/include/uapi/asm/kvm_para.h > > > > > > > > @@ -96,5 +96,7 @@ struct kvm_vcpu_pv_apf_data { > > > > > > > > #define KVM_PV_EOI_ENABLED KVM_PV_EOI_MASK > > > > > > > > #define KVM_PV_EOI_DISABLED 0x0 > > > > > > > > > > > > > > > > +#define KVM_PV_EVENT_PORT (0x505UL) > > > > > > > > + > > > > > > > > > > > > > > No need for the ioport to be hard coded. What are the options to > > > > > > > communicate an address to the guest? An MSR, via ACPI? > > > > > > > > > > > > I'm not quite understanding here. By 'address', you mean an ioport? > > > > > > how to communicate an address? (I have little knowledge about ACPI) > > > > > > > > > > Yes, the ioport. The address of the ioport should not be fixed (for > > > > > example future emulated board could use that fixed ioport address, > > > > > 0x505UL). > > > > > > > > > > One option is to pass the address via an MSR. Yes, that is probably the > > > > > best option because there is no dependency on ACPI. > > > > > > > > > Why dependency on ACPI is problematic? ACPI is the standard way on x86 > > > > to enumerate platform devices. Passing it through MSR makes this panic > > > > device CPU interface which it is not. And since relying on #GP to detect > > > > valid MSRs is not good interface we will have to guard it by cpuid bit. > > > > > > > > -- > > > > Gleb. > > > > > > KVM guest <-> KVM host interface is not dependent on ACPI, so far. Say, > > > its possible to use a Linux guest without ACPI and have KVM paravirt > > > fully functional. > > This is not KVM guest <-> KVM host interface though. This is yet another > > device. We could implement real impi device that have crash reporting > > capability, but decided to go with something simpler. Without ACPI guest > > will not be able to power down itself too, but this is not the reason > > for us to introduce non-ACPI interface for power down. > > Sure (its more of an aesthetic/organizational point, i guess). > > Anyway, one problem with ACPI is whether its initialized early enough > (which is the whole point of PIO the x86 specific interface). ACPI is needed pretty early in the boot process. -- Gleb. ^ permalink raw reply [flat|nested] 6+ messages in thread
[parent not found: <19fae3171e31ae90c208895d90ad912291936794.1358920534.git.hutao@cn.fujitsu.com>]
[parent not found: <20130208015028.GC3364@amt.cnet>]
[parent not found: <20130220081348.GC23246@localhost.localdomain>]
* Re: [Qemu-devel] [PATCH v12 rebased 2/8] start vm after resetting it [not found] ` <20130220081348.GC23246@localhost.localdomain> @ 2013-03-02 0:07 ` Marcelo Tosatti 0 siblings, 0 replies; 6+ messages in thread From: Marcelo Tosatti @ 2013-03-02 0:07 UTC (permalink / raw) To: Hu Tao Cc: Andrew Jones, Gleb Natapov, kvm list, Jan Kiszka, qemu-devel, linux-kernel@vger.kernel.org, Blue Swirl, Sasha Levin, Luiz Capitulino, KAMEZAWA Hiroyuki On Wed, Feb 20, 2013 at 04:13:49PM +0800, Hu Tao wrote: > On Thu, Feb 07, 2013 at 11:50:28PM -0200, Marcelo Tosatti wrote: > > On Wed, Jan 23, 2013 at 03:19:23PM +0800, Hu Tao wrote: > > > From: Wen Congyang <wency@cn.fujitsu.com> > > > > > > The guest should run after resetting it, but it does not run if its > > > old state is RUN_STATE_INTERNAL_ERROR or RUN_STATE_PAUSED. > > > > > > We don't set runstate to RUN_STATE_PAUSED when resetting the guest, > > > so the runstate will be changed from RUN_STATE_INTERNAL_ERROR or > > > RUN_STATE_PAUSED to RUN_STATE_RUNNING(not RUN_STATE_PAUSED). > > > > It appears the last hunk will automatically reset state from > > RUN_STATE_INTERNAL_ERROR to RUN_STATE_RUNNING ? > > Yes. > > > > > I suppose the transition table allows, from RUN_STATE_INTERNAL_ERROR: > > > > <monitor> system_reset > > <monitor> cont > > > > To resume the machine? > > True. > > I think the purpose of this patch is to always reset and _run_ the guest > by `system_reset', avoiding an additional `cont' following `system_reset'. Unclear why its essential to the feature being proposed? ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2013-03-05 7:05 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <cover.1358920534.git.hutao@cn.fujitsu.com>
[not found] ` <1358925575-4505-1-git-send-email-hutao@cn.fujitsu.com>
[not found] ` <20130208013947.GA3364@amt.cnet>
[not found] ` <20130228085425.GA16362@localhost.localdomain>
2013-03-02 0:03 ` [Qemu-devel] [PATCH v12 rebased] kvm: notify host when the guest is panicked Marcelo Tosatti
2013-03-03 13:00 ` Gleb Natapov
2013-03-03 22:29 ` Marcelo Tosatti
2013-03-04 17:49 ` Gleb Natapov
[not found] ` <20130304204348.GB20761@amt.cnet>
2013-03-05 7:05 ` Gleb Natapov
[not found] ` <19fae3171e31ae90c208895d90ad912291936794.1358920534.git.hutao@cn.fujitsu.com>
[not found] ` <20130208015028.GC3364@amt.cnet>
[not found] ` <20130220081348.GC23246@localhost.localdomain>
2013-03-02 0:07 ` [Qemu-devel] [PATCH v12 rebased 2/8] start vm after resetting it Marcelo Tosatti
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).