Re: [Qemu-devel] [PATCH v13 5/8] add a new qevent: QEVENT_GUEST_PANICKED

Re: [Qemu-devel] [PATCH v13 5/8] add a new qevent: QEVENT_GUEST_PANICKED

[Eric Blake]

[-- Attachment #1: Type: text/plain, Size: 428 bytes --]

On 02/28/2013 05:13 AM, Hu Tao wrote:
> This event will be emited when the guest is panicked.
> 
> Signed-off-by: Wen Congyang <wency@cn.fujitsu.com>
> ---
>  include/monitor/monitor.h | 1 +
>  monitor.c                 | 1 +
>  2 files changed, 2 insertions(+)

Missing documentation in QMP/qmp-events.txt

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 621 bytes --]

Re: [Qemu-devel] [PATCH v13 5/8] add a new qevent: QEVENT_GUEST_PANICKED

[Hu Tao]

On Fri, Mar 01, 2013 at 09:31:47AM -0700, Eric Blake wrote:
> On 02/28/2013 05:13 AM, Hu Tao wrote:
> > This event will be emited when the guest is panicked.
> > 
> > Signed-off-by: Wen Congyang <wency@cn.fujitsu.com>
> > ---
> >  include/monitor/monitor.h | 1 +
> >  monitor.c                 | 1 +
> >  2 files changed, 2 insertions(+)
> 
> Missing documentation in QMP/qmp-events.txt

Thanks, will add it.

Re: [Qemu-devel] [PATCH v13 5/8] add a new qevent: QEVENT_GUEST_PANICKED

[Paolo Bonzini]

Il 28/02/2013 13:13, Hu Tao ha scritto:
> This event will be emited when the guest is panicked.
> 
> Signed-off-by: Wen Congyang <wency@cn.fujitsu.com>
> ---
>  include/monitor/monitor.h | 1 +
>  monitor.c                 | 1 +
>  2 files changed, 2 insertions(+)
> 
> diff --git a/include/monitor/monitor.h b/include/monitor/monitor.h
> index 87fb49c..4006905 100644
> --- a/include/monitor/monitor.h
> +++ b/include/monitor/monitor.h
> @@ -45,6 +45,7 @@ typedef enum MonitorEvent {
>      QEVENT_WAKEUP,
>      QEVENT_BALLOON_CHANGE,
>      QEVENT_SPICE_MIGRATE_COMPLETED,
> +    QEVENT_GUEST_PANICKED,
>  
>      /* Add to 'monitor_event_names' array in monitor.c when
>       * defining new events here */
> diff --git a/monitor.c b/monitor.c
> index bf974b4..d65218d 100644
> --- a/monitor.c
> +++ b/monitor.c
> @@ -463,6 +463,7 @@ static const char *monitor_event_names[] = {
>      [QEVENT_WAKEUP] = "WAKEUP",
>      [QEVENT_BALLOON_CHANGE] = "BALLOON_CHANGE",
>      [QEVENT_SPICE_MIGRATE_COMPLETED] = "SPICE_MIGRATE_COMPLETED",
> +    [QEVENT_GUEST_PANICKED] = "GUEST_PANICKED",
>  };
>  QEMU_BUILD_BUG_ON(ARRAY_SIZE(monitor_event_names) != QEVENT_MAX)
>  
> 

Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>

Paolo

Re: [Qemu-devel] [PATCH v13 0/8] pv event interface between host and guest

[Gleb Natapov]

On Thu, Feb 28, 2013 at 08:13:10PM +0800, Hu Tao wrote:
> This series implements a new interface, kvm pv event, to notify host when
> some events happen in guest. Right now there is one supported event: guest
> panic.
> 
What other event do you have in mind? Is interface generic enough to
accommodate future, yet unknown, events. It allows to pass only one
integer specifying even type, what if additional info is needed? My be
stop pretending that device is generic and make it do once thing but do
it well? For generic even passing interface (whatever it may be needed
for) much more powerful virtio should be used.

On implementation itself I do not understand why is this kvm specific.
The only thing that makes it so is that you hook device initialization
into guest kvm initialization code, but this is obviously incorrect.
What stops QEMU tcg or Xen from reusing the same device for the same
purpose except the artificial limitation in a guest.

Reading data from a random ioports is not how you discover platform
devices in 21 century (and the data you read from unassigned port is not
guarantied to be zero, it may depend on QEMU version), you use ACPI for
that and Marcelo already pointed that to you. Having little knowledge of
ACPI (we all do) is not a good reason to not doing it. We probably need
to reserve QEMU specific ACPI Plug and Play hardware ID to define our own
devices. After that you will be able to create device with _HID(QEMU0001)
in DSDT that supplies address information (ioport to use) and capability
supported. Guest uses acpi_get_devices() to discover a platform device by
its name (QEMU0001).  Then you put the driver for the platform device
into drivers/platform/x86/ and QEMU/kvm/Xen all will be able to use it.

On QEMU side of things I cannot comment much on how QOMified the device
is (it should be), I hope other reviews will verify it, but I noticed
that device is only initialized for PIIX, what about Q35?

--
			Gleb.

Re: [Qemu-devel] [PATCH v13 0/8] pv event interface between host and guest

[Paolo Bonzini]

Il 03/03/2013 10:17, Gleb Natapov ha scritto:
> On Thu, Feb 28, 2013 at 08:13:10PM +0800, Hu Tao wrote:
>> This series implements a new interface, kvm pv event, to notify host when
>> some events happen in guest. Right now there is one supported event: guest
>> panic.
>>
> What other event do you have in mind? Is interface generic enough to
> accommodate future, yet unknown, events. It allows to pass only one
> integer specifying even type, what if additional info is needed? My be
> stop pretending that device is generic and make it do once thing but do
> it well? For generic even passing interface (whatever it may be needed
> for) much more powerful virtio should be used.
> 
> On implementation itself I do not understand why is this kvm specific.
> The only thing that makes it so is that you hook device initialization
> into guest kvm initialization code, but this is obviously incorrect.
> What stops QEMU tcg or Xen from reusing the same device for the same
> purpose except the artificial limitation in a guest.

Agreed.

> Reading data from a random ioports is not how you discover platform
> devices in 21 century (and the data you read from unassigned port is not
> guarantied to be zero, it may depend on QEMU version), you use ACPI for
> that and Marcelo already pointed that to you. Having little knowledge of
> ACPI (we all do) is not a good reason to not doing it. We probably need
> to reserve QEMU specific ACPI Plug and Play hardware ID to define our own
> devices. After that you will be able to create device with _HID(QEMU0001)
> in DSDT that supplies address information (ioport to use) and capability
> supported.

Please also document this HID in a new file in the QEMU docs/ directory.

> Guest uses acpi_get_devices() to discover a platform device by
> its name (QEMU0001).  Then you put the driver for the platform device
> into drivers/platform/x86/ and QEMU/kvm/Xen all will be able to use it.

Just to clarify it for Hu Tao, the read from a random ioport is how the
ACPI code will detect presence of the device.

Something like this should work (in SeaBIOS's src/acpi-dsdt-isa.dsl):

    Device(PEVT) {
        Name(_HID, EisaId("QEMU0001"))
        OperationRegion(PEOR, SystemIO, 0x505, 0x01)
        Field(PEOR, ByteAcc, NoLock, Preserve) {
            PEPT,   8,
        }

        Method(_STA, 0, NotSerialized) {
            Store(PEPT, Local0)
            If (LEqual(Local0, Zero)) {
                Return (0x00)
            } Else {
                Return (0x0F)
            }
        }

        Name(_CRS, ResourceTemplate() {
            IO(Decode16, 0x505, 0x505, 0x01, 0x01)
        })
    }

Please test this with a QEMU option like "-M pc-1.4".  The device should
_not_ be detected if you're doing it right.

> On QEMU side of things I cannot comment much on how QOMified the device
> is (it should be),

Please make the device target-independent.  It can be used on non-x86
architectures that have I/O ports.  You should make the port
configurable using a property (DEFINE_PROPERTY_INT16 or something like
that), with a default of 0x505.

All the panicked_action is not necessary in my opinion.  We have it for
watchdogs, but that's really a legacy thing.  Let libvirt do it, and
always make the guest panic perform the PANICKED_PAUSE action.

If you do it properly, a lot (really a lot) of code will go away.

> I hope other reviews will verify it, but I noticed
> that device is only initialized for PIIX, what about Q35?

Yup.

Paolo

Re: [Qemu-devel] [PATCH v13 0/8] pv event interface between host and guest

[Gleb Natapov]

On Mon, Mar 04, 2013 at 11:05:37AM +0100, Paolo Bonzini wrote:
> > Guest uses acpi_get_devices() to discover a platform device by
> > its name (QEMU0001).  Then you put the driver for the platform device
> > into drivers/platform/x86/ and QEMU/kvm/Xen all will be able to use it.
> 
> Just to clarify it for Hu Tao, the read from a random ioport is how the
> ACPI code will detect presence of the device.
> 
Actually no (at least in the long run, for the first version it may be
OK). Since we want to move DSDT generation into QEMU if device will not
be present QEMU will not generate corresponded Device() in DSDT, or it
will generate it with _STA() { Return (0x00)} hard coded. Seabios can do
the same if we will pass it info about device presence via fw_cfg. Not
sure Kevin will like it now when we plan to move DSDT into QEMU anyway :)

> Something like this should work (in SeaBIOS's src/acpi-dsdt-isa.dsl):
> 
>     Device(PEVT) {
>         Name(_HID, EisaId("QEMU0001"))
>         OperationRegion(PEOR, SystemIO, 0x505, 0x01)
>         Field(PEOR, ByteAcc, NoLock, Preserve) {
>             PEPT,   8,
>         }
> 
>         Method(_STA, 0, NotSerialized) {
>             Store(PEPT, Local0)
>             If (LEqual(Local0, Zero)) {
>                 Return (0x00)
>             } Else {
>                 Return (0x0F)
>             }
>         }
> 
>         Name(_CRS, ResourceTemplate() {
>             IO(Decode16, 0x505, 0x505, 0x01, 0x01)
>         })
>     }
> 
> Please test this with a QEMU option like "-M pc-1.4".  The device should
> _not_ be detected if you're doing it right.
> 

--
			Gleb.

Re: [Qemu-devel] [PATCH v13 0/8] pv event interface between host and guest

[Paolo Bonzini]

Il 04/03/2013 11:21, Gleb Natapov ha scritto:
>> > Just to clarify it for Hu Tao, the read from a random ioport is how the
>> > ACPI code will detect presence of the device.
>> > 
> Actually no (at least in the long run, for the first version it may be
> OK).

Agreed.

> Since we want to move DSDT generation into QEMU if device will not
> be present QEMU will not generate corresponded Device() in DSDT, or it
> will generate it with _STA() { Return (0x00)} hard coded.

Yes, this would be good.

> Seabios can do
> the same if we will pass it info about device presence via fw_cfg.

True, but I don't like this a lot.  I don't like splitting decisions
between SeaBIOS and the DSDT, you end up touching code all over the
place and writing ASL is simpler than patching---even with all the
machinery that we have.  It is also simpler to move ASL from SeaBIOS to
OVMF and/or viceversa.  I don't recall what was the opposition to a
fw_cfg driver directly in the DSDT, but I think this would be a good
usage for it.

Splitting it between QEMU and DSDT is a bit better, since you have to
touch QEMU anyway to implement the feature.

Anyhow, this does not apply to the next submission of this series.  I
think we can agree to the compromise of using ACPI but still read the
port in _STA.

Paolo

Re: [Qemu-devel] [PATCH v13 0/8] pv event interface between host and guest

[Gleb Natapov]

On Mon, Mar 04, 2013 at 11:28:05AM +0100, Paolo Bonzini wrote:
> Il 04/03/2013 11:21, Gleb Natapov ha scritto:
> >> > Just to clarify it for Hu Tao, the read from a random ioport is how the
> >> > ACPI code will detect presence of the device.
> >> > 
> > Actually no (at least in the long run, for the first version it may be
> > OK).
> 
> Agreed.
> 
> > Since we want to move DSDT generation into QEMU if device will not
> > be present QEMU will not generate corresponded Device() in DSDT, or it
> > will generate it with _STA() { Return (0x00)} hard coded.
> 
> Yes, this would be good.
> 
> > Seabios can do
> > the same if we will pass it info about device presence via fw_cfg.
> 
> True, but I don't like this a lot.  I don't like splitting decisions
> between SeaBIOS and the DSDT, you end up touching code all over the
> place and writing ASL is simpler than patching---even with all the
> machinery that we have.
That's the main argument in favor of moving DSDT into QEMU regardless
of this patch series, but as long as we have it in Seabios, have
infrastructure for patching and use it for many things already I do not
see why avoiding it.

>                          It is also simpler to move ASL from SeaBIOS to
> OVMF and/or viceversa.  I don't recall what was the opposition to a
> fw_cfg driver directly in the DSDT, but I think this would be a good
> usage for it.
> 
Basically fw_cfg was not designed with this in mind. It was really meant
to be simple interface for FW running one one CPU to use. You probably
may do locking with AML too to guaranty atomic access, but things get
complicated. Also may option that was added lately use file interface
(since this is what Kevin prefers) and manipulating strings in AML is
probably not what we want.

> Splitting it between QEMU and DSDT is a bit better, since you have to
> touch QEMU anyway to implement the feature.
> 
> Anyhow, this does not apply to the next submission of this series.  I
> think we can agree to the compromise of using ACPI but still read the
> port in _STA.
> 
If you want to make ioport configurable I do not see how can we avoid
patching.

--
			Gleb.

Re: [Qemu-devel] [PATCH v13 0/8] pv event interface between host and guest

[Paolo Bonzini]

Il 04/03/2013 11:43, Gleb Natapov ha scritto:
> > Anyhow, this does not apply to the next submission of this series.  I
> > think we can agree to the compromise of using ACPI but still read the
> > port in _STA.
> 
> If you want to make ioport configurable I do not see how can we avoid
> patching.

I want to make the ioport configurable in the device, but the PIIX and
ICH9 (which are what the DSDT is written for) will always use port 0x505.

You can configure a different iobase for your serial ports, the guest
can still use them but not discover them via ACPI.  This is the same thing.

Paolo

Re: [Qemu-devel] [PATCH v13 0/8] pv event interface between host and guest

[Gleb Natapov]

On Mon, Mar 04, 2013 at 11:49:07AM +0100, Paolo Bonzini wrote:
> Il 04/03/2013 11:43, Gleb Natapov ha scritto:
> > > Anyhow, this does not apply to the next submission of this series.  I
> > > think we can agree to the compromise of using ACPI but still read the
> > > port in _STA.
> > 
> > If you want to make ioport configurable I do not see how can we avoid
> > patching.
> 
> I want to make the ioport configurable in the device, but the PIIX and
> ICH9 (which are what the DSDT is written for) will always use port 0x505.
> 
But the device is not part of PIIX or ICH9. It is additional device that
may or may not be present depending on a command line. So what if
someone configures debugcon or debugexit to use this port? We can always
blame the users, but I fill that we are making unnecessary compromises.

> You can configure a different iobase for your serial ports, the guest
> can still use them but not discover them via ACPI.  This is the same thing.
> 
Probably we should patch DSDT too when it will be in QEMU :) of force
iobase to spec values if device is used as part of a chipset.

--
			Gleb.

Re: [Qemu-devel] [PATCH v13 0/8] pv event interface between host and guest

[Paolo Bonzini]

Il 04/03/2013 11:59, Gleb Natapov ha scritto:
> > I want to make the ioport configurable in the device, but the PIIX and
> > ICH9 (which are what the DSDT is written for) will always use port 0x505.
> 
> But the device is not part of PIIX or ICH9.

So is kvmclock, or kvmvapic.  I think it makes sense to add this device
to PIIX or ICH9 since it is an ISA device.

> It is additional device that
> may or may not be present depending on a command line. So what if
> someone configures debugcon or debugexit to use this port?

I haven't checked if debug{con,exit} will pass the _STA test, but if
they do, the user will get a Ctrl-A or respectively an exit of QEMU when
the guest panics.

What if someone configures debugcon on port 0x3f8?  Some guest will use
it, some will not.

> We can always
> blame the users, but I fill that we are making unnecessary compromises.

Once we choose an ISA device, where the user has full control of the
address space, we already know we'll have to accept compromises.  I
don't think this compromise is particularly bad: do discovery via ACPI
(nice), accept that the user can trick the AML (ugly).

Paolo

> > You can configure a different iobase for your serial ports, the guest
> > can still use them but not discover them via ACPI.  This is the same thing.
> 
> Probably we should patch DSDT too when it will be in QEMU :) of force
> iobase to spec values if device is used as part of a chipset.

Re: [Qemu-devel] [PATCH v13 0/8] pv event interface between host and guest

[Gleb Natapov]

On Mon, Mar 04, 2013 at 12:10:58PM +0100, Paolo Bonzini wrote:
> Il 04/03/2013 11:59, Gleb Natapov ha scritto:
> > > I want to make the ioport configurable in the device, but the PIIX and
> > > ICH9 (which are what the DSDT is written for) will always use port 0x505.
> > 
> > But the device is not part of PIIX or ICH9.
> 
> So is kvmclock, or kvmvapic.  I think it makes sense to add this device
> to PIIX or ICH9 since it is an ISA device.
> 
Those are CPU interfaces, not chipset. fw_cfg or our PIIX ACPI additions would
be better examples, but since they are always present and non configurable they
are in a different category.

> > It is additional device that
> > may or may not be present depending on a command line. So what if
> > someone configures debugcon or debugexit to use this port?
> 
> I haven't checked if debug{con,exit} will pass the _STA test, but if
> they do, the user will get a Ctrl-A or respectively an exit of QEMU when
> the guest panics.
> 
> What if someone configures debugcon on port 0x3f8?  Some guest will use
> it, some will not.
> 
Qemu should fail to start since conflict will be detected during
initialization.

> > We can always
> > blame the users, but I fill that we are making unnecessary compromises.
> 
> Once we choose an ISA device, where the user has full control of the
> address space, we already know we'll have to accept compromises.  I
> don't think this compromise is particularly bad: do discovery via ACPI
> (nice), accept that the user can trick the AML (ugly).
> 
Why would have we accept compromises, we may, but I disagree that it
is necessary? If user configures conflicting ports QEMU will detect
it during init, if configuration is correct DSDT should provide enough
information for guests to use configured devices.

--
			Gleb.

Re: [Qemu-devel] [PATCH v13 0/8] pv event interface between host and guest

[Paolo Bonzini]

Il 04/03/2013 12:20, Gleb Natapov ha scritto:
> On Mon, Mar 04, 2013 at 12:10:58PM +0100, Paolo Bonzini wrote:
>>> It is additional device that
>>> may or may not be present depending on a command line. So what if
>>> someone configures debugcon or debugexit to use this port?
>>
>> I haven't checked if debug{con,exit} will pass the _STA test, but if
>> they do, the user will get a Ctrl-A or respectively an exit of QEMU when
>> the guest panics.
>>
>> What if someone configures debugcon on port 0x3f8?  Some guest will use
>> it, some will not.
>>
> Qemu should fail to start since conflict will be detected during
> initialization.

Not if you _remove_ the serial port and place debugcon at 0x3f8.

Same here, you can remove the panic event port and add debugcon at
0x505.  That's the problematic case.  But if the user goes to that
length, I think we can honestly say we don't care.

Paolo

>>> We can always
>>> blame the users, but I fill that we are making unnecessary compromises.
>>
>> Once we choose an ISA device, where the user has full control of the
>> address space, we already know we'll have to accept compromises.  I
>> don't think this compromise is particularly bad: do discovery via ACPI
>> (nice), accept that the user can trick the AML (ugly).
>
> Why would have we accept compromises, we may, but I disagree that it
> is necessary? If user configures conflicting ports QEMU will detect
> it during init, if configuration is correct DSDT should provide enough
> information for guests to use configured devices.
> 
> --
> 			Gleb.
> 

Re: [Qemu-devel] [PATCH v13 0/8] pv event interface between host and guest

[Gleb Natapov]

On Mon, Mar 04, 2013 at 12:35:08PM +0100, Paolo Bonzini wrote:
> Il 04/03/2013 12:20, Gleb Natapov ha scritto:
> > On Mon, Mar 04, 2013 at 12:10:58PM +0100, Paolo Bonzini wrote:
> >>> It is additional device that
> >>> may or may not be present depending on a command line. So what if
> >>> someone configures debugcon or debugexit to use this port?
> >>
> >> I haven't checked if debug{con,exit} will pass the _STA test, but if
> >> they do, the user will get a Ctrl-A or respectively an exit of QEMU when
> >> the guest panics.
> >>
> >> What if someone configures debugcon on port 0x3f8?  Some guest will use
> >> it, some will not.
> >>
> > Qemu should fail to start since conflict will be detected during
> > initialization.
> 
> Not if you _remove_ the serial port and place debugcon at 0x3f8.
> 
That will no longer be PIIX chipset. And still, if user will not use
"buggy" guest that assumes that serial is at 0x3f8 or she configures
guest to not use serial, everything will be fine.

> Same here, you can remove the panic event port and add debugcon at
> 0x505.  That's the problematic case.  But if the user goes to that
> length, I think we can honestly say we don't care.
IMO there is a big difference between well know serial ISA ports and
PIO ports we allocate for our devices. Later have to be discoverable
without resorting to probing. On CPU level we do the same with CPUID
bits instead of relaying on MSRs #GP. On KVM API level we do the same
with capabilities instead of relying on ioctls returning errors. This
is not different.

--
			Gleb.

Re: [Qemu-devel] [PATCH v13 0/8] pv event interface between host and guest

[Paolo Bonzini]

Il 04/03/2013 12:52, Gleb Natapov ha scritto:
> > Same here, you can remove the panic event port and add debugcon at
> > 0x505.  That's the problematic case.  But if the user goes to that
> > length, I think we can honestly say we don't care.
>
> IMO there is a big difference between well know serial ISA ports and
> PIO ports we allocate for our devices. Later have to be discoverable
> without resorting to probing. On CPU level we do the same with CPUID
> bits instead of relaying on MSRs #GP. On KVM API level we do the same
> with capabilities instead of relying on ioctls returning errors. This
> is not different.

Ok, I see your point now.  Yes, this is a good reason why patching is
better in the long run.

Paolo

Re: [Qemu-devel] [PATCH v13 0/8] pv event interface between host and guest

[Hu Tao]

Hi,

On Mon, Mar 04, 2013 at 11:05:37AM +0100, Paolo Bonzini wrote:
> Il 03/03/2013 10:17, Gleb Natapov ha scritto:
> > On Thu, Feb 28, 2013 at 08:13:10PM +0800, Hu Tao wrote:
> >> This series implements a new interface, kvm pv event, to notify host when
> >> some events happen in guest. Right now there is one supported event: guest
> >> panic.
> >>
> > What other event do you have in mind? Is interface generic enough to
> > accommodate future, yet unknown, events. It allows to pass only one
> > integer specifying even type, what if additional info is needed? My be
> > stop pretending that device is generic and make it do once thing but do
> > it well? For generic even passing interface (whatever it may be needed
> > for) much more powerful virtio should be used.
> > 
> > On implementation itself I do not understand why is this kvm specific.
> > The only thing that makes it so is that you hook device initialization
> > into guest kvm initialization code, but this is obviously incorrect.
> > What stops QEMU tcg or Xen from reusing the same device for the same
> > purpose except the artificial limitation in a guest.
> 
> Agreed.
> 
> > Reading data from a random ioports is not how you discover platform
> > devices in 21 century (and the data you read from unassigned port is not
> > guarantied to be zero, it may depend on QEMU version), you use ACPI for
> > that and Marcelo already pointed that to you. Having little knowledge of
> > ACPI (we all do) is not a good reason to not doing it. We probably need
> > to reserve QEMU specific ACPI Plug and Play hardware ID to define our own
> > devices. After that you will be able to create device with _HID(QEMU0001)
> > in DSDT that supplies address information (ioport to use) and capability
> > supported.
> 
> Please also document this HID in a new file in the QEMU docs/ directory.
> 
> > Guest uses acpi_get_devices() to discover a platform device by
> > its name (QEMU0001).  Then you put the driver for the platform device
> > into drivers/platform/x86/ and QEMU/kvm/Xen all will be able to use it.
> 
> Just to clarify it for Hu Tao, the read from a random ioport is how the
> ACPI code will detect presence of the device.
> 
> Something like this should work (in SeaBIOS's src/acpi-dsdt-isa.dsl):
> 
>     Device(PEVT) {
>         Name(_HID, EisaId("QEMU0001"))
>         OperationRegion(PEOR, SystemIO, 0x505, 0x01)
>         Field(PEOR, ByteAcc, NoLock, Preserve) {
>             PEPT,   8,
>         }
> 
>         Method(_STA, 0, NotSerialized) {
>             Store(PEPT, Local0)
>             If (LEqual(Local0, Zero)) {
>                 Return (0x00)
>             } Else {
>                 Return (0x0F)
>             }
>         }

IIUC, here _STA reads from ioport 0x505, if the result is 0, then the
device is not present. Otherwise, the device is present. But as Gleb
said, ''the data you read from unassigned port is not guarantied to be
zero, it may depend on QEMU version''. What should I do to tell if the
device is present or not correctly?

> 
>         Name(_CRS, ResourceTemplate() {
>             IO(Decode16, 0x505, 0x505, 0x01, 0x01)
>         })
>     }
> 
> Please test this with a QEMU option like "-M pc-1.4".  The device should
> _not_ be detected if you're doing it right.

because there is no corresponding device driver?

> 
> > On QEMU side of things I cannot comment much on how QOMified the device
> > is (it should be),
> 
> Please make the device target-independent.  It can be used on non-x86
> architectures that have I/O ports.  You should make the port
> configurable using a property (DEFINE_PROPERTY_INT16 or something like
> that), with a default of 0x505.

OK.

> 
> All the panicked_action is not necessary in my opinion.  We have it for
> watchdogs, but that's really a legacy thing.  Let libvirt do it, and
> always make the guest panic perform the PANICKED_PAUSE action.

OK.

> 
> If you do it properly, a lot (really a lot) of code will go away.

Thanks!

> 
> > I hope other reviews will verify it, but I noticed
> > that device is only initialized for PIIX, what about Q35?
> 
> Yup.
> 
> Paolo

Re: [Qemu-devel] [PATCH v13 0/8] pv event interface between host and guest

[Paolo Bonzini]

Il 06/03/2013 09:56, Hu Tao ha scritto:
>> > 
>> > Something like this should work (in SeaBIOS's src/acpi-dsdt-isa.dsl):
>> > 
>> >     Device(PEVT) {
>> >         Name(_HID, EisaId("QEMU0001"))
>> >         OperationRegion(PEOR, SystemIO, 0x505, 0x01)
>> >         Field(PEOR, ByteAcc, NoLock, Preserve) {
>> >             PEPT,   8,
>> >         }
>> > 
>> >         Method(_STA, 0, NotSerialized) {
>> >             Store(PEPT, Local0)
>> >             If (LEqual(Local0, Zero)) {
>> >                 Return (0x00)
>> >             } Else {
>> >                 Return (0x0F)
>> >             }
>> >         }
> IIUC, here _STA reads from ioport 0x505, if the result is 0, then the
> device is not present. Otherwise, the device is present. But as Gleb
> said, ''the data you read from unassigned port is not guarantied to be
> zero, it may depend on QEMU version''. What should I do to tell if the
> device is present or not correctly?

The firmware is tied to the QEMU version, so you can rely on unassigned
ports returning zero.

Later we can change this to use fw-cfg.

Paolo

Re: [Qemu-devel] [PATCH v13 0/8] pv event interface between host and guest

[li guang]

在 2013-03-06三的 10:07 +0100，Paolo Bonzini写道：
> Il 06/03/2013 09:56, Hu Tao ha scritto:
> >> > 
> >> > Something like this should work (in SeaBIOS's src/acpi-dsdt-isa.dsl):
> >> > 
> >> >     Device(PEVT) {
> >> >         Name(_HID, EisaId("QEMU0001"))
> >> >         OperationRegion(PEOR, SystemIO, 0x505, 0x01)
> >> >         Field(PEOR, ByteAcc, NoLock, Preserve) {
> >> >             PEPT,   8,
> >> >         }
> >> > 
> >> >         Method(_STA, 0, NotSerialized) {
> >> >             Store(PEPT, Local0)
> >> >             If (LEqual(Local0, Zero)) {
> >> >                 Return (0x00)
> >> >             } Else {
> >> >                 Return (0x0F)
> >> >             }
> >> >         }
> > IIUC, here _STA reads from ioport 0x505, if the result is 0, then the
> > device is not present. Otherwise, the device is present. But as Gleb
> > said, ''the data you read from unassigned port is not guarantied to be
> > zero, it may depend on QEMU version''. What should I do to tell if the
> > device is present or not correctly?
> 
> The firmware is tied to the QEMU version, so you can rely on unassigned
> ports returning zero.
> 

but what if we happen to transfer data end by 0x0,
here, will this device(QEMU0001) disappear?
(by this asl code snippet, I think it will)
so, if we transfer data(not 0x0) device appear,
then, it will disappear(if come across 0x0),
can this happen?
or should we use another status io port e.g.
0x506 to handle this condition?

> Later we can change this to use fw-cfg.
> 
> Paolo
> 
> 

Re: [Qemu-devel] [PATCH v13 0/8] pv event interface between host and guest

[Gleb Natapov]

On Wed, Mar 06, 2013 at 10:07:31AM +0100, Paolo Bonzini wrote:
> Il 06/03/2013 09:56, Hu Tao ha scritto:
> >> > 
> >> > Something like this should work (in SeaBIOS's src/acpi-dsdt-isa.dsl):
> >> > 
> >> >     Device(PEVT) {
> >> >         Name(_HID, EisaId("QEMU0001"))
> >> >         OperationRegion(PEOR, SystemIO, 0x505, 0x01)
> >> >         Field(PEOR, ByteAcc, NoLock, Preserve) {
> >> >             PEPT,   8,
> >> >         }
> >> > 
> >> >         Method(_STA, 0, NotSerialized) {
> >> >             Store(PEPT, Local0)
> >> >             If (LEqual(Local0, Zero)) {
> >> >                 Return (0x00)
> >> >             } Else {
> >> >                 Return (0x0F)
> >> >             }
> >> >         }
> > IIUC, here _STA reads from ioport 0x505, if the result is 0, then the
> > device is not present. Otherwise, the device is present. But as Gleb
> > said, ''the data you read from unassigned port is not guarantied to be
> > zero, it may depend on QEMU version''. What should I do to tell if the
> > device is present or not correctly?
> 
> The firmware is tied to the QEMU version, so you can rely on unassigned
> ports returning zero.
> 
> Later we can change this to use fw-cfg.
> 
I thought we agreed to do it from the start :)

--
			Gleb.

Re: [Qemu-devel] [PATCH v13 0/8] pv event interface between host and guest

[Paolo Bonzini]

> On Wed, Mar 06, 2013 at 10:07:31AM +0100, Paolo Bonzini wrote:
> > Il 06/03/2013 09:56, Hu Tao ha scritto:
> > >> > 
> > >> > Something like this should work (in SeaBIOS's
> > >> > src/acpi-dsdt-isa.dsl):
> > >> > 
> > >> >     Device(PEVT) {
> > >> >         Name(_HID, EisaId("QEMU0001"))
> > >> >         OperationRegion(PEOR, SystemIO, 0x505, 0x01)
> > >> >         Field(PEOR, ByteAcc, NoLock, Preserve) {
> > >> >             PEPT,   8,
> > >> >         }
> > >> > 
> > >> >         Method(_STA, 0, NotSerialized) {
> > >> >             Store(PEPT, Local0)
> > >> >             If (LEqual(Local0, Zero)) {
> > >> >                 Return (0x00)
> > >> >             } Else {
> > >> >                 Return (0x0F)
> > >> >             }
> > >> >         }
> > > IIUC, here _STA reads from ioport 0x505, if the result is 0, then the
> > > device is not present. Otherwise, the device is present. But as Gleb
> > > said, ''the data you read from unassigned port is not guarantied to be
> > > zero, it may depend on QEMU version''. What should I do to tell if the
> > > device is present or not correctly?
> > 
> > The firmware is tied to the QEMU version, so you can rely on
> > unassigned ports returning zero.
> > 
> > Later we can change this to use fw-cfg.
> 
> I thought we agreed to do it from the start :)

Then Hu will need to patch the _STA method.

Paolo

Re: [Qemu-devel] [PATCH v13 0/8] pv event interface between host and guest

[Gleb Natapov]

On Wed, Mar 06, 2013 at 04:48:17AM -0500, Paolo Bonzini wrote:
> 
> > On Wed, Mar 06, 2013 at 10:07:31AM +0100, Paolo Bonzini wrote:
> > > Il 06/03/2013 09:56, Hu Tao ha scritto:
> > > >> > 
> > > >> > Something like this should work (in SeaBIOS's
> > > >> > src/acpi-dsdt-isa.dsl):
> > > >> > 
> > > >> >     Device(PEVT) {
> > > >> >         Name(_HID, EisaId("QEMU0001"))
> > > >> >         OperationRegion(PEOR, SystemIO, 0x505, 0x01)
> > > >> >         Field(PEOR, ByteAcc, NoLock, Preserve) {
> > > >> >             PEPT,   8,
> > > >> >         }
> > > >> > 
> > > >> >         Method(_STA, 0, NotSerialized) {
> > > >> >             Store(PEPT, Local0)
> > > >> >             If (LEqual(Local0, Zero)) {
> > > >> >                 Return (0x00)
> > > >> >             } Else {
> > > >> >                 Return (0x0F)
> > > >> >             }
> > > >> >         }
> > > > IIUC, here _STA reads from ioport 0x505, if the result is 0, then the
> > > > device is not present. Otherwise, the device is present. But as Gleb
> > > > said, ''the data you read from unassigned port is not guarantied to be
> > > > zero, it may depend on QEMU version''. What should I do to tell if the
> > > > device is present or not correctly?
> > > 
> > > The firmware is tied to the QEMU version, so you can rely on
> > > unassigned ports returning zero.
> > > 
> > > Later we can change this to use fw-cfg.
> > 
> > I thought we agreed to do it from the start :)
> 
> Then Hu will need to patch the _STA method.
> 
_STA and _CRS.

--
			Gleb.

Re: [Qemu-devel] [PATCH v13 0/8] pv event interface between host and guest

[Hu Tao]

On Sun, Mar 03, 2013 at 11:17:38AM +0200, Gleb Natapov wrote:
> On Thu, Feb 28, 2013 at 08:13:10PM +0800, Hu Tao wrote:
> > This series implements a new interface, kvm pv event, to notify host when
> > some events happen in guest. Right now there is one supported event: guest
> > panic.
> > 
> What other event do you have in mind? Is interface generic enough to
> accommodate future, yet unknown, events. It allows to pass only one
> integer specifying even type, what if additional info is needed? My be

guest crash, lockup, or warning.[1] But the first purpose is to do panic
notification(panic event). Since at the point the guest is panicked, I
think it's better to keep the interface as simple as possible.

[1] http://wiki.qemu.org/Features/PVCrashDetection

> stop pretending that device is generic and make it do once thing but do

you mean make the interface just do panic notification?

> it well? For generic even passing interface (whatever it may be needed
> for) much more powerful virtio should be used.
> 
> On implementation itself I do not understand why is this kvm specific.
> The only thing that makes it so is that you hook device initialization
> into guest kvm initialization code, but this is obviously incorrect.
> What stops QEMU tcg or Xen from reusing the same device for the same
> purpose except the artificial limitation in a guest.
> 
> Reading data from a random ioports is not how you discover platform
> devices in 21 century (and the data you read from unassigned port is not
> guarantied to be zero, it may depend on QEMU version), you use ACPI for
> that and Marcelo already pointed that to you. Having little knowledge of
> ACPI (we all do) is not a good reason to not doing it. We probably need
> to reserve QEMU specific ACPI Plug and Play hardware ID to define our own

Do we have to request the ID from some orgnazation?

> devices. After that you will be able to create device with _HID(QEMU0001)

QMU0001, I think. EISA ID requires it to have only 3 letters for PNP ID.

> in DSDT that supplies address information (ioport to use) and capability
> supported. Guest uses acpi_get_devices() to discover a platform device by
> its name (QEMU0001).  Then you put the driver for the platform device
> into drivers/platform/x86/ and QEMU/kvm/Xen all will be able to use it.

Thanks for the information!

> 
> On QEMU side of things I cannot comment much on how QOMified the device
> is (it should be), I hope other reviews will verify it, but I noticed
> that device is only initialized for PIIX, what about Q35?
> 
> --
> 			Gleb.

Re: [Qemu-devel] [PATCH v13 0/8] pv event interface between host and guest

[Gleb Natapov]

On Wed, Mar 06, 2013 at 04:46:58PM +0800, Hu Tao wrote:
> On Sun, Mar 03, 2013 at 11:17:38AM +0200, Gleb Natapov wrote:
> > On Thu, Feb 28, 2013 at 08:13:10PM +0800, Hu Tao wrote:
> > > This series implements a new interface, kvm pv event, to notify host when
> > > some events happen in guest. Right now there is one supported event: guest
> > > panic.
> > > 
> > What other event do you have in mind? Is interface generic enough to
> > accommodate future, yet unknown, events. It allows to pass only one
> > integer specifying even type, what if additional info is needed? My be
> 
> guest crash, lockup, or warning.[1] But the first purpose is to do panic
> notification(panic event). Since at the point the guest is panicked, I
> think it's better to keep the interface as simple as possible.
> 
> [1] http://wiki.qemu.org/Features/PVCrashDetection
> 
> > stop pretending that device is generic and make it do once thing but do
> 
> you mean make the interface just do panic notification?
> 
Yes.

> > it well? For generic even passing interface (whatever it may be needed
> > for) much more powerful virtio should be used.
> > 
> > On implementation itself I do not understand why is this kvm specific.
> > The only thing that makes it so is that you hook device initialization
> > into guest kvm initialization code, but this is obviously incorrect.
> > What stops QEMU tcg or Xen from reusing the same device for the same
> > purpose except the artificial limitation in a guest.
> > 
> > Reading data from a random ioports is not how you discover platform
> > devices in 21 century (and the data you read from unassigned port is not
> > guarantied to be zero, it may depend on QEMU version), you use ACPI for
> > that and Marcelo already pointed that to you. Having little knowledge of
> > ACPI (we all do) is not a good reason to not doing it. We probably need
> > to reserve QEMU specific ACPI Plug and Play hardware ID to define our own
> 
> Do we have to request the ID from some orgnazation?
> 
A Plug and Play ID or ACPI ID can be obtained by sending e-mail to pnpid@microsoft.com.

> > devices. After that you will be able to create device with _HID(QEMU0001)
> 
> QMU0001, I think. EISA ID requires it to have only 3 letters for PNP ID.
Right, but I am not sure we need EISA ID here. Why not ACPI ID like in
the example from the spec:

Name (_HID, "MSFT0003") // Vendor-defined device

--
			Gleb.

Re: [Qemu-devel] [PATCH v13 1/8] save/load cpu runstate

[Hu Tao]

On Thu, Feb 28, 2013 at 02:12:37PM -0700, Eric Blake wrote:
> On 02/28/2013 05:13 AM, Hu Tao wrote:
> > This patch enables preservation of cpu runstate during save/load vm.
> > So when a vm is restored from snapshot, the cpu runstate is restored,
> > too.
> 
> What happens if a management app wants to override the runstate when
> restoring the domain?  I can think of several useful scenarios:
> 
> 1. management app pauses the guest, then saves domain state and other
> things (management state, or disk clones), then resumes the guest.
> Later, the management wants to revert to the saved state, but have the
> guest running right away.  I guess here, knowing that the guest was
> saved in a paused state doesn't hurt, since the management app can
> resume it right away.
> 
> 2. management app saves domain state of a live guest, then copies that
> state elsewhere.  In its new location, the management app wants to
> investigate the state for forensic analysis - so even though the guest
> remembers that it was running, management wants to start it paused.
> Here, it is important that there must not be a window of time where the
> guest can run, otherwise, the results are not reproducible.

-S takes precedence in the case. But for in-migration, runstate is
loaded from src.

Re: [Qemu-devel] [PATCH v13 1/8] save/load cpu runstate

[Eric Blake]

[-- Attachment #1: Type: text/plain, Size: 1936 bytes --]

On 03/01/2013 12:36 AM, Hu Tao wrote:
> On Thu, Feb 28, 2013 at 02:12:37PM -0700, Eric Blake wrote:
>> On 02/28/2013 05:13 AM, Hu Tao wrote:
>>> This patch enables preservation of cpu runstate during save/load vm.
>>> So when a vm is restored from snapshot, the cpu runstate is restored,
>>> too.
>>
>> What happens if a management app wants to override the runstate when
>> restoring the domain?  I can think of several useful scenarios:
>>
>> 1. management app pauses the guest, then saves domain state and other
>> things (management state, or disk clones), then resumes the guest.
>> Later, the management wants to revert to the saved state, but have the
>> guest running right away.  I guess here, knowing that the guest was
>> saved in a paused state doesn't hurt, since the management app can
>> resume it right away.
>>
>> 2. management app saves domain state of a live guest, then copies that
>> state elsewhere.  In its new location, the management app wants to
>> investigate the state for forensic analysis - so even though the guest
>> remembers that it was running, management wants to start it paused.
>> Here, it is important that there must not be a window of time where the
>> guest can run, otherwise, the results are not reproducible.
> 
> -S takes precedence in the case. But for in-migration, runstate is
> loaded from src.

Given your answer, I think we're okay from the libvirt perspective.  My
biggest worry about a window where the guest runs unchecked is not a
problem, given that libvirt always uses -S on incoming migration.  In
turn, libvirt has its own mechanisms for tracking whether the outgoing
migration was started from a running state, along with API overrides to
let a user override whether libvirt will resume the guest on the
incoming migration side.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 621 bytes --]

Re: [Qemu-devel] [PATCH v13 1/8] save/load cpu runstate

[Paolo Bonzini]

Il 28/02/2013 13:13, Hu Tao ha scritto:
> This patch enables preservation of cpu runstate during save/load vm.
> So when a vm is restored from snapshot, the cpu runstate is restored,
> too.

I don't think this feature is worth breaking backwards migration
compatibility.  It is usually handled at a higher-level (management,
like libvirt).

Please make this a separate patch.

Paolo

> See following example:
> 
> # save two vms: one is running, the other is paused
> (qemu) info status
> VM status: running
> (qemu) savevm running
> (qemu) stop
> (qemu) info status
> VM status: paused
> (qemu) savevm paused
> 
> # restore the one running
> (qemu) info status
> VM status: paused
> (qemu) loadvm running
> (qemu) info status
> VM status: running
> 
> # restore the one paused
> (qemu) loadvm paused
> (qemu) info status
> VM status: paused
> (qemu) cont
> (qemu)info status
> VM status: running
> 
> Signed-off-by: Hu Tao <hutao@cn.fujitsu.com>
> ---
>  include/sysemu/sysemu.h |  2 ++
>  migration.c             |  6 +-----
>  monitor.c               |  5 ++---
>  savevm.c                |  1 +
>  vl.c                    | 34 ++++++++++++++++++++++++++++++++++
>  5 files changed, 40 insertions(+), 8 deletions(-)
> 
> diff --git a/include/sysemu/sysemu.h b/include/sysemu/sysemu.h
> index b19ec95..f121213 100644
> --- a/include/sysemu/sysemu.h
> +++ b/include/sysemu/sysemu.h
> @@ -19,6 +19,8 @@ extern uint8_t qemu_uuid[];
>  int qemu_uuid_parse(const char *str, uint8_t *uuid);
>  #define UUID_FMT "%02hhx%02hhx%02hhx%02hhx-%02hhx%02hhx-%02hhx%02hhx-%02hhx%02hhx-%02hhx%02hhx%02hhx%02hhx%02hhx%02hhx"
>  
> +void save_run_state(void);
> +void load_run_state(void);
>  bool runstate_check(RunState state);
>  void runstate_set(RunState new_state);
>  int runstate_is_running(void);
> diff --git a/migration.c b/migration.c
> index 11725ae..c29830e 100644
> --- a/migration.c
> +++ b/migration.c
> @@ -107,11 +107,7 @@ static void process_incoming_migration_co(void *opaque)
>      /* Make sure all file formats flush their mutable metadata */
>      bdrv_invalidate_cache_all();
>  
> -    if (autostart) {
> -        vm_start();
> -    } else {
> -        runstate_set(RUN_STATE_PAUSED);
> -    }
> +    load_run_state();
>  }
>  
>  void process_incoming_migration(QEMUFile *f)
> diff --git a/monitor.c b/monitor.c
> index 32a6e74..bf974b4 100644
> --- a/monitor.c
> +++ b/monitor.c
> @@ -2059,13 +2059,12 @@ void qmp_closefd(const char *fdname, Error **errp)
>  
>  static void do_loadvm(Monitor *mon, const QDict *qdict)
>  {
> -    int saved_vm_running  = runstate_is_running();
>      const char *name = qdict_get_str(qdict, "name");
>  
>      vm_stop(RUN_STATE_RESTORE_VM);
>  
> -    if (load_vmstate(name) == 0 && saved_vm_running) {
> -        vm_start();
> +    if (load_vmstate(name) == 0) {
> +        load_run_state();
>      }
>  }
>  
> diff --git a/savevm.c b/savevm.c
> index a8a53ef..aa631eb 100644
> --- a/savevm.c
> +++ b/savevm.c
> @@ -2143,6 +2143,7 @@ void do_savevm(Monitor *mon, const QDict *qdict)
>      }
>  
>      saved_vm_running = runstate_is_running();
> +    save_run_state();
>      vm_stop(RUN_STATE_SAVE_VM);
>  
>      memset(sn, 0, sizeof(*sn));
> diff --git a/vl.c b/vl.c
> index febd2ea..7991f2e 100644
> --- a/vl.c
> +++ b/vl.c
> @@ -523,6 +523,7 @@ static int default_driver_check(QemuOpts *opts, void *opaque)
>  /* QEMU state */
>  
>  static RunState current_run_state = RUN_STATE_PRELAUNCH;
> +static RunState saved_run_state = RUN_STATE_RUNNING;
>  
>  typedef struct {
>      RunState from;
> @@ -546,6 +547,7 @@ static const RunStateTransition runstate_transitions_def[] = {
>      { RUN_STATE_PAUSED, RUN_STATE_FINISH_MIGRATE },
>  
>      { RUN_STATE_POSTMIGRATE, RUN_STATE_RUNNING },
> +    { RUN_STATE_POSTMIGRATE, RUN_STATE_PAUSED },
>      { RUN_STATE_POSTMIGRATE, RUN_STATE_FINISH_MIGRATE },
>  
>      { RUN_STATE_PRELAUNCH, RUN_STATE_RUNNING },
> @@ -556,6 +558,7 @@ static const RunStateTransition runstate_transitions_def[] = {
>      { RUN_STATE_FINISH_MIGRATE, RUN_STATE_POSTMIGRATE },
>  
>      { RUN_STATE_RESTORE_VM, RUN_STATE_RUNNING },
> +    { RUN_STATE_RESTORE_VM, RUN_STATE_PAUSED },
>  
>      { RUN_STATE_RUNNING, RUN_STATE_DEBUG },
>      { RUN_STATE_RUNNING, RUN_STATE_INTERNAL_ERROR },
> @@ -585,11 +588,39 @@ static const RunStateTransition runstate_transitions_def[] = {
>  
>  static bool runstate_valid_transitions[RUN_STATE_MAX][RUN_STATE_MAX];
>  
> +void save_run_state(void)
> +{
> +    saved_run_state = current_run_state;
> +}
> +
> +void load_run_state(void)
> +{
> +    if (saved_run_state == RUN_STATE_RUNNING) {
> +        vm_start();
> +    } else if (!runstate_check(saved_run_state)) {
> +        runstate_set(saved_run_state);
> +    } else {
> +        ; /* leave unchanged */
> +    }
> +}
> +
>  bool runstate_check(RunState state)
>  {
>      return current_run_state == state;
>  }
>  
> +static void runstate_save(QEMUFile *f, void *opaque)
> +{
> +    qemu_put_byte(f, saved_run_state);
> +}
> +
> +static int runstate_load(QEMUFile *f, void *opaque, int version_id)
> +{
> +    saved_run_state = qemu_get_byte(f);
> +
> +    return 0;
> +}
> +
>  static void runstate_init(void)
>  {
>      const RunStateTransition *p;
> @@ -599,6 +630,9 @@ static void runstate_init(void)
>      for (p = &runstate_transitions_def[0]; p->from != RUN_STATE_MAX; p++) {
>          runstate_valid_transitions[p->from][p->to] = true;
>      }
> +
> +    register_savevm(NULL, "runstate", 0, 1,
> +                    runstate_save, runstate_load, NULL);
>  }
>  
>  /* This function will abort() on invalid state transitions */
> 

Re: [Qemu-devel] [PATCH v13 1/8] save/load cpu runstate

[Hu Tao]

On Mon, Mar 04, 2013 at 10:30:48AM +0100, Paolo Bonzini wrote:
> Il 28/02/2013 13:13, Hu Tao ha scritto:
> > This patch enables preservation of cpu runstate during save/load vm.
> > So when a vm is restored from snapshot, the cpu runstate is restored,
> > too.
> 
> I don't think this feature is worth breaking backwards migration
> compatibility.  It is usually handled at a higher-level (management,
> like libvirt).

If guest panic happens during migration, runstate will still be running
on destination host without this patch. But, it does be a problem to break
backwards migration compatibility.

> 
> Please make this a separate patch.

Sure.

> 
> Paolo
> 
> > See following example:
> > 
> > # save two vms: one is running, the other is paused
> > (qemu) info status
> > VM status: running
> > (qemu) savevm running
> > (qemu) stop
> > (qemu) info status
> > VM status: paused
> > (qemu) savevm paused
> > 
> > # restore the one running
> > (qemu) info status
> > VM status: paused
> > (qemu) loadvm running
> > (qemu) info status
> > VM status: running
> > 
> > # restore the one paused
> > (qemu) loadvm paused
> > (qemu) info status
> > VM status: paused
> > (qemu) cont
> > (qemu)info status
> > VM status: running
> > 
> > Signed-off-by: Hu Tao <hutao@cn.fujitsu.com>
> > ---
> >  include/sysemu/sysemu.h |  2 ++
> >  migration.c             |  6 +-----
> >  monitor.c               |  5 ++---
> >  savevm.c                |  1 +
> >  vl.c                    | 34 ++++++++++++++++++++++++++++++++++
> >  5 files changed, 40 insertions(+), 8 deletions(-)
> > 
> > diff --git a/include/sysemu/sysemu.h b/include/sysemu/sysemu.h
> > index b19ec95..f121213 100644
> > --- a/include/sysemu/sysemu.h
> > +++ b/include/sysemu/sysemu.h
> > @@ -19,6 +19,8 @@ extern uint8_t qemu_uuid[];
> >  int qemu_uuid_parse(const char *str, uint8_t *uuid);
> >  #define UUID_FMT "%02hhx%02hhx%02hhx%02hhx-%02hhx%02hhx-%02hhx%02hhx-%02hhx%02hhx-%02hhx%02hhx%02hhx%02hhx%02hhx%02hhx"
> >  
> > +void save_run_state(void);
> > +void load_run_state(void);
> >  bool runstate_check(RunState state);
> >  void runstate_set(RunState new_state);
> >  int runstate_is_running(void);
> > diff --git a/migration.c b/migration.c
> > index 11725ae..c29830e 100644
> > --- a/migration.c
> > +++ b/migration.c
> > @@ -107,11 +107,7 @@ static void process_incoming_migration_co(void *opaque)
> >      /* Make sure all file formats flush their mutable metadata */
> >      bdrv_invalidate_cache_all();
> >  
> > -    if (autostart) {
> > -        vm_start();
> > -    } else {
> > -        runstate_set(RUN_STATE_PAUSED);
> > -    }
> > +    load_run_state();
> >  }
> >  
> >  void process_incoming_migration(QEMUFile *f)
> > diff --git a/monitor.c b/monitor.c
> > index 32a6e74..bf974b4 100644
> > --- a/monitor.c
> > +++ b/monitor.c
> > @@ -2059,13 +2059,12 @@ void qmp_closefd(const char *fdname, Error **errp)
> >  
> >  static void do_loadvm(Monitor *mon, const QDict *qdict)
> >  {
> > -    int saved_vm_running  = runstate_is_running();
> >      const char *name = qdict_get_str(qdict, "name");
> >  
> >      vm_stop(RUN_STATE_RESTORE_VM);
> >  
> > -    if (load_vmstate(name) == 0 && saved_vm_running) {
> > -        vm_start();
> > +    if (load_vmstate(name) == 0) {
> > +        load_run_state();
> >      }
> >  }
> >  
> > diff --git a/savevm.c b/savevm.c
> > index a8a53ef..aa631eb 100644
> > --- a/savevm.c
> > +++ b/savevm.c
> > @@ -2143,6 +2143,7 @@ void do_savevm(Monitor *mon, const QDict *qdict)
> >      }
> >  
> >      saved_vm_running = runstate_is_running();
> > +    save_run_state();
> >      vm_stop(RUN_STATE_SAVE_VM);
> >  
> >      memset(sn, 0, sizeof(*sn));
> > diff --git a/vl.c b/vl.c
> > index febd2ea..7991f2e 100644
> > --- a/vl.c
> > +++ b/vl.c
> > @@ -523,6 +523,7 @@ static int default_driver_check(QemuOpts *opts, void *opaque)
> >  /* QEMU state */
> >  
> >  static RunState current_run_state = RUN_STATE_PRELAUNCH;
> > +static RunState saved_run_state = RUN_STATE_RUNNING;
> >  
> >  typedef struct {
> >      RunState from;
> > @@ -546,6 +547,7 @@ static const RunStateTransition runstate_transitions_def[] = {
> >      { RUN_STATE_PAUSED, RUN_STATE_FINISH_MIGRATE },
> >  
> >      { RUN_STATE_POSTMIGRATE, RUN_STATE_RUNNING },
> > +    { RUN_STATE_POSTMIGRATE, RUN_STATE_PAUSED },
> >      { RUN_STATE_POSTMIGRATE, RUN_STATE_FINISH_MIGRATE },
> >  
> >      { RUN_STATE_PRELAUNCH, RUN_STATE_RUNNING },
> > @@ -556,6 +558,7 @@ static const RunStateTransition runstate_transitions_def[] = {
> >      { RUN_STATE_FINISH_MIGRATE, RUN_STATE_POSTMIGRATE },
> >  
> >      { RUN_STATE_RESTORE_VM, RUN_STATE_RUNNING },
> > +    { RUN_STATE_RESTORE_VM, RUN_STATE_PAUSED },
> >  
> >      { RUN_STATE_RUNNING, RUN_STATE_DEBUG },
> >      { RUN_STATE_RUNNING, RUN_STATE_INTERNAL_ERROR },
> > @@ -585,11 +588,39 @@ static const RunStateTransition runstate_transitions_def[] = {
> >  
> >  static bool runstate_valid_transitions[RUN_STATE_MAX][RUN_STATE_MAX];
> >  
> > +void save_run_state(void)
> > +{
> > +    saved_run_state = current_run_state;
> > +}
> > +
> > +void load_run_state(void)
> > +{
> > +    if (saved_run_state == RUN_STATE_RUNNING) {
> > +        vm_start();
> > +    } else if (!runstate_check(saved_run_state)) {
> > +        runstate_set(saved_run_state);
> > +    } else {
> > +        ; /* leave unchanged */
> > +    }
> > +}
> > +
> >  bool runstate_check(RunState state)
> >  {
> >      return current_run_state == state;
> >  }
> >  
> > +static void runstate_save(QEMUFile *f, void *opaque)
> > +{
> > +    qemu_put_byte(f, saved_run_state);
> > +}
> > +
> > +static int runstate_load(QEMUFile *f, void *opaque, int version_id)
> > +{
> > +    saved_run_state = qemu_get_byte(f);
> > +
> > +    return 0;
> > +}
> > +
> >  static void runstate_init(void)
> >  {
> >      const RunStateTransition *p;
> > @@ -599,6 +630,9 @@ static void runstate_init(void)
> >      for (p = &runstate_transitions_def[0]; p->from != RUN_STATE_MAX; p++) {
> >          runstate_valid_transitions[p->from][p->to] = true;
> >      }
> > +
> > +    register_savevm(NULL, "runstate", 0, 1,
> > +                    runstate_save, runstate_load, NULL);
> >  }
> >  
> >  /* This function will abort() on invalid state transitions */
> > 

Re: [Qemu-devel] [PATCH v13 1/8] save/load cpu runstate

[Paolo Bonzini]

Il 05/03/2013 03:33, Hu Tao ha scritto:
> On Mon, Mar 04, 2013 at 10:30:48AM +0100, Paolo Bonzini wrote:
>> Il 28/02/2013 13:13, Hu Tao ha scritto:
>>> This patch enables preservation of cpu runstate during save/load vm.
>>> So when a vm is restored from snapshot, the cpu runstate is restored,
>>> too.
>>
>> I don't think this feature is worth breaking backwards migration
>> compatibility.  It is usually handled at a higher-level (management,
>> like libvirt).
> 
> If guest panic happens during migration, runstate will still be running
> on destination host without this patch. But, it does be a problem to break
> backwards migration compatibility.

Yes, but the source management (libvirt for example) will have the
occasion to observe the change and cancel the migration or forward the
information on the wire.  There are already similar reasons why libvirt
always starts guests with -S.

Paolo

Re: [Qemu-devel] [PATCH v13 2/8] start vm after resetting it

[Paolo Bonzini]

Il 28/02/2013 13:13, Hu Tao ha scritto:
> 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).

This is also debatable.  In particular, restarting an INTERNAL_ERROR
guest makes it harder to inspect the state at the time of the failure.

INTERNAL_ERROR should never happen, let's separate this patch too.

Paolo

Re: [Qemu-devel] [PATCH v13 2/8] start vm after resetting it

[Hu Tao]

On Mon, Mar 04, 2013 at 10:32:17AM +0100, Paolo Bonzini wrote:
> Il 28/02/2013 13:13, Hu Tao ha scritto:
> > 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).
> 
> This is also debatable.  In particular, restarting an INTERNAL_ERROR
> guest makes it harder to inspect the state at the time of the failure.
> 
> INTERNAL_ERROR should never happen, let's separate this patch too.

Sure.

> 
> Paolo

Re: [Qemu-devel] [PATCH v13 2/8] start vm after resetting it

[Hu Tao]

On Thu, Feb 28, 2013 at 02:23:42PM +0100, Jan Kiszka wrote:
> On 2013-02-28 13:13, 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).
> 
> I just wonder what will happen if I interrupted the guest via gdb and
> then issue "monitor system_reset", also via gdb - common pattern if you
> set a breakpoint on some BUG() or fault handler and then want to restart
> the guest. Will the guest continue then while gdb thinks it is still
> stopped? Likely, we do not differentiate between gdb-initiated stops and
> the rest. Could you clarify?

Guest won't continue unless issue gdb "continue". Anyway, I'll seperate
this patch, as Paolo requested.

Re: [Qemu-devel] [PATCH v13 4/8] add a new runstate: RUN_STATE_GUEST_PANICKED

[Paolo Bonzini]

Il 28/02/2013 13:13, Hu Tao ha scritto:
> The guest will be in this state when it is panicked.
> 
> Signed-off-by: Wen Congyang <wency@cn.fujitsu.com>
> Signed-off-by: Hu Tao <hutao@cn.fujitsu.com>
> ---
>  migration.c      |  1 +
>  qapi-schema.json |  6 +++++-
>  qmp.c            |  3 ++-
>  vl.c             | 11 ++++++++++-
>  4 files changed, 18 insertions(+), 3 deletions(-)
> 
> diff --git a/migration.c b/migration.c
> index c29830e..fa17b82 100644
> --- a/migration.c
> +++ b/migration.c
> @@ -698,6 +698,7 @@ static void *buffered_file_thread(void *opaque)
>                  int64_t start_time, end_time;
>  
>                  DPRINTF("done iterating\n");
> +                save_run_state();
>                  start_time = qemu_get_clock_ms(rt_clock);
>                  qemu_system_wakeup_request(QEMU_WAKEUP_REASON_OTHER);
>                  if (old_vm_running) {
> diff --git a/qapi-schema.json b/qapi-schema.json
> index 28b070f..8f1d138 100644
> --- a/qapi-schema.json
> +++ b/qapi-schema.json
> @@ -174,11 +174,15 @@
>  # @suspended: guest is suspended (ACPI S3)
>  #
>  # @watchdog: the watchdog action is configured to pause and has been triggered
> +#
> +# @guest-panicked: the panicked action is configured to pause and has been
> +# triggered.
>  ##
>  { 'enum': 'RunState',
>    'data': [ 'debug', 'inmigrate', 'internal-error', 'io-error', 'paused',
>              'postmigrate', 'prelaunch', 'finish-migrate', 'restore-vm',
> -            'running', 'save-vm', 'shutdown', 'suspended', 'watchdog' ] }
> +            'running', 'save-vm', 'shutdown', 'suspended', 'watchdog',
> +            'guest-panicked' ] }
>  
>  ##
>  # @SnapshotInfo
> diff --git a/qmp.c b/qmp.c
> index 5f1bed1..f5027f6 100644
> --- a/qmp.c
> +++ b/qmp.c
> @@ -150,7 +150,8 @@ void qmp_cont(Error **errp)
>      Error *local_err = NULL;
>  
>      if (runstate_check(RUN_STATE_INTERNAL_ERROR) ||
> -               runstate_check(RUN_STATE_SHUTDOWN)) {
> +            runstate_check(RUN_STATE_SHUTDOWN) ||
> +            runstate_check(RUN_STATE_GUEST_PANICKED)) {
>          error_set(errp, QERR_RESET_REQUIRED);
>          return;
>      } else if (runstate_check(RUN_STATE_SUSPENDED)) {
> diff --git a/vl.c b/vl.c
> index 3d08e1a..51d4922 100644
> --- a/vl.c
> +++ b/vl.c
> @@ -536,6 +536,7 @@ static const RunStateTransition runstate_transitions_def[] = {
>  
>      { RUN_STATE_INMIGRATE, RUN_STATE_RUNNING },
>      { RUN_STATE_INMIGRATE, RUN_STATE_PAUSED },
> +    { RUN_STATE_INMIGRATE, RUN_STATE_GUEST_PANICKED },

Is this a consequence of the first patch?

>      { RUN_STATE_INTERNAL_ERROR, RUN_STATE_RUNNING },
>      { RUN_STATE_INTERNAL_ERROR, RUN_STATE_FINISH_MIGRATE },
> @@ -549,6 +550,7 @@ static const RunStateTransition runstate_transitions_def[] = {
>      { RUN_STATE_POSTMIGRATE, RUN_STATE_RUNNING },
>      { RUN_STATE_POSTMIGRATE, RUN_STATE_PAUSED },
>      { RUN_STATE_POSTMIGRATE, RUN_STATE_FINISH_MIGRATE },
> +    { RUN_STATE_POSTMIGRATE, RUN_STATE_GUEST_PANICKED },

Impossible.  GUEST_PANICKED requires an instruction to be executed in
the guest, so it should first go to RUNNING.

>      { RUN_STATE_PRELAUNCH, RUN_STATE_RUNNING },
>      { RUN_STATE_PRELAUNCH, RUN_STATE_FINISH_MIGRATE },
> @@ -559,6 +561,7 @@ static const RunStateTransition runstate_transitions_def[] = {
>  
>      { RUN_STATE_RESTORE_VM, RUN_STATE_RUNNING },
>      { RUN_STATE_RESTORE_VM, RUN_STATE_PAUSED },
> +    { RUN_STATE_RESTORE_VM, RUN_STATE_GUEST_PANICKED },

Is it also for the first patch?

>      { RUN_STATE_RUNNING, RUN_STATE_DEBUG },
>      { RUN_STATE_RUNNING, RUN_STATE_INTERNAL_ERROR },
> @@ -569,6 +572,7 @@ static const RunStateTransition runstate_transitions_def[] = {
>      { RUN_STATE_RUNNING, RUN_STATE_SAVE_VM },
>      { RUN_STATE_RUNNING, RUN_STATE_SHUTDOWN },
>      { RUN_STATE_RUNNING, RUN_STATE_WATCHDOG },
> +    { RUN_STATE_RUNNING, RUN_STATE_GUEST_PANICKED },

This one is obviously ok.

>      { RUN_STATE_SAVE_VM, RUN_STATE_RUNNING },
>  
> @@ -583,6 +587,10 @@ static const RunStateTransition runstate_transitions_def[] = {
>      { RUN_STATE_WATCHDOG, RUN_STATE_RUNNING },
>      { RUN_STATE_WATCHDOG, RUN_STATE_FINISH_MIGRATE },
>  
> +    { RUN_STATE_GUEST_PANICKED, RUN_STATE_RUNNING },
> +    { RUN_STATE_GUEST_PANICKED, RUN_STATE_PAUSED },
> +    { RUN_STATE_GUEST_PANICKED, RUN_STATE_FINISH_MIGRATE },

Like SHUTDOWN, it should go first to PAUSED and then to RUNNING.  A
GUEST_PANICKED -> RUNNING transition is not possible.  You're seeing it
because you lack the addition of GUEST_PANICKED here:

        if (runstate_check(RUN_STATE_INTERNAL_ERROR) ||
            runstate_check(RUN_STATE_SHUTDOWN)) {
            runstate_set(RUN_STATE_PAUSED);
        }

I think you should first move the INTERNAL_ERROR || SHUTDOWN checks to a
separate function, so that you can then add GUEST_PANICKED.

Paolo

>      { RUN_STATE_MAX, RUN_STATE_MAX },
>  };
>  
> @@ -2001,7 +2009,8 @@ static bool main_loop_should_exit(void)
>          qemu_system_reset(VMRESET_REPORT);
>          resume_all_vcpus();
>          if (runstate_check(RUN_STATE_INTERNAL_ERROR) ||
> -            runstate_check(RUN_STATE_SHUTDOWN)) {
> +            runstate_check(RUN_STATE_SHUTDOWN) ||
> +            runstate_check(RUN_STATE_GUEST_PANICKED)) {
>              bdrv_iterate(iostatus_bdrv_it, NULL);
>              vm_start();
>          }
> 

Re: [Qemu-devel] [PATCH v13 4/8] add a new runstate: RUN_STATE_GUEST_PANICKED

[Hu Tao]

On Mon, Mar 04, 2013 at 10:40:15AM +0100, Paolo Bonzini wrote:
> Il 28/02/2013 13:13, Hu Tao ha scritto:
> > The guest will be in this state when it is panicked.
> > 
> > Signed-off-by: Wen Congyang <wency@cn.fujitsu.com>
> > Signed-off-by: Hu Tao <hutao@cn.fujitsu.com>
> > ---
> >  migration.c      |  1 +
> >  qapi-schema.json |  6 +++++-
> >  qmp.c            |  3 ++-
> >  vl.c             | 11 ++++++++++-
> >  4 files changed, 18 insertions(+), 3 deletions(-)
> > 
> > diff --git a/migration.c b/migration.c
> > index c29830e..fa17b82 100644
> > --- a/migration.c
> > +++ b/migration.c
> > @@ -698,6 +698,7 @@ static void *buffered_file_thread(void *opaque)
> >                  int64_t start_time, end_time;
> >  
> >                  DPRINTF("done iterating\n");
> > +                save_run_state();
> >                  start_time = qemu_get_clock_ms(rt_clock);
> >                  qemu_system_wakeup_request(QEMU_WAKEUP_REASON_OTHER);
> >                  if (old_vm_running) {
> > diff --git a/qapi-schema.json b/qapi-schema.json
> > index 28b070f..8f1d138 100644
> > --- a/qapi-schema.json
> > +++ b/qapi-schema.json
> > @@ -174,11 +174,15 @@
> >  # @suspended: guest is suspended (ACPI S3)
> >  #
> >  # @watchdog: the watchdog action is configured to pause and has been triggered
> > +#
> > +# @guest-panicked: the panicked action is configured to pause and has been
> > +# triggered.
> >  ##
> >  { 'enum': 'RunState',
> >    'data': [ 'debug', 'inmigrate', 'internal-error', 'io-error', 'paused',
> >              'postmigrate', 'prelaunch', 'finish-migrate', 'restore-vm',
> > -            'running', 'save-vm', 'shutdown', 'suspended', 'watchdog' ] }
> > +            'running', 'save-vm', 'shutdown', 'suspended', 'watchdog',
> > +            'guest-panicked' ] }
> >  
> >  ##
> >  # @SnapshotInfo
> > diff --git a/qmp.c b/qmp.c
> > index 5f1bed1..f5027f6 100644
> > --- a/qmp.c
> > +++ b/qmp.c
> > @@ -150,7 +150,8 @@ void qmp_cont(Error **errp)
> >      Error *local_err = NULL;
> >  
> >      if (runstate_check(RUN_STATE_INTERNAL_ERROR) ||
> > -               runstate_check(RUN_STATE_SHUTDOWN)) {
> > +            runstate_check(RUN_STATE_SHUTDOWN) ||
> > +            runstate_check(RUN_STATE_GUEST_PANICKED)) {
> >          error_set(errp, QERR_RESET_REQUIRED);
> >          return;
> >      } else if (runstate_check(RUN_STATE_SUSPENDED)) {
> > diff --git a/vl.c b/vl.c
> > index 3d08e1a..51d4922 100644
> > --- a/vl.c
> > +++ b/vl.c
> > @@ -536,6 +536,7 @@ static const RunStateTransition runstate_transitions_def[] = {
> >  
> >      { RUN_STATE_INMIGRATE, RUN_STATE_RUNNING },
> >      { RUN_STATE_INMIGRATE, RUN_STATE_PAUSED },
> > +    { RUN_STATE_INMIGRATE, RUN_STATE_GUEST_PANICKED },
> 
> Is this a consequence of the first patch?

Yes.

> 
> >      { RUN_STATE_INTERNAL_ERROR, RUN_STATE_RUNNING },
> >      { RUN_STATE_INTERNAL_ERROR, RUN_STATE_FINISH_MIGRATE },
> > @@ -549,6 +550,7 @@ static const RunStateTransition runstate_transitions_def[] = {
> >      { RUN_STATE_POSTMIGRATE, RUN_STATE_RUNNING },
> >      { RUN_STATE_POSTMIGRATE, RUN_STATE_PAUSED },
> >      { RUN_STATE_POSTMIGRATE, RUN_STATE_FINISH_MIGRATE },
> > +    { RUN_STATE_POSTMIGRATE, RUN_STATE_GUEST_PANICKED },
> 
> Impossible.  GUEST_PANICKED requires an instruction to be executed in
> the guest, so it should first go to RUNNING.
> 
> >      { RUN_STATE_PRELAUNCH, RUN_STATE_RUNNING },
> >      { RUN_STATE_PRELAUNCH, RUN_STATE_FINISH_MIGRATE },
> > @@ -559,6 +561,7 @@ static const RunStateTransition runstate_transitions_def[] = {
> >  
> >      { RUN_STATE_RESTORE_VM, RUN_STATE_RUNNING },
> >      { RUN_STATE_RESTORE_VM, RUN_STATE_PAUSED },
> > +    { RUN_STATE_RESTORE_VM, RUN_STATE_GUEST_PANICKED },
> 
> Is it also for the first patch?

Yes.

> 
> >      { RUN_STATE_RUNNING, RUN_STATE_DEBUG },
> >      { RUN_STATE_RUNNING, RUN_STATE_INTERNAL_ERROR },
> > @@ -569,6 +572,7 @@ static const RunStateTransition runstate_transitions_def[] = {
> >      { RUN_STATE_RUNNING, RUN_STATE_SAVE_VM },
> >      { RUN_STATE_RUNNING, RUN_STATE_SHUTDOWN },
> >      { RUN_STATE_RUNNING, RUN_STATE_WATCHDOG },
> > +    { RUN_STATE_RUNNING, RUN_STATE_GUEST_PANICKED },
> 
> This one is obviously ok.
> 
> >      { RUN_STATE_SAVE_VM, RUN_STATE_RUNNING },
> >  
> > @@ -583,6 +587,10 @@ static const RunStateTransition runstate_transitions_def[] = {
> >      { RUN_STATE_WATCHDOG, RUN_STATE_RUNNING },
> >      { RUN_STATE_WATCHDOG, RUN_STATE_FINISH_MIGRATE },
> >  
> > +    { RUN_STATE_GUEST_PANICKED, RUN_STATE_RUNNING },
> > +    { RUN_STATE_GUEST_PANICKED, RUN_STATE_PAUSED },
> > +    { RUN_STATE_GUEST_PANICKED, RUN_STATE_FINISH_MIGRATE },
> 
> Like SHUTDOWN, it should go first to PAUSED and then to RUNNING.  A
> GUEST_PANICKED -> RUNNING transition is not possible.  You're seeing it
> because you lack the addition of GUEST_PANICKED here:
> 
>         if (runstate_check(RUN_STATE_INTERNAL_ERROR) ||
>             runstate_check(RUN_STATE_SHUTDOWN)) {
>             runstate_set(RUN_STATE_PAUSED);
>         }
> 
> I think you should first move the INTERNAL_ERROR || SHUTDOWN checks to a
> separate function, so that you can then add GUEST_PANICKED.

Will 

         if (runstate_check(RUN_STATE_INTERNAL_ERROR) ||
             runstate_check(RUN_STATE_SHUTDOWN) ||
             runstate_check(RUN_STATE_GUEST_PANICKED)) {
             runstate_set(RUN_STATE_PAUSED);
         }

be OK? Or I must be misunderstanding you.

> 
> Paolo
> 
> >      { RUN_STATE_MAX, RUN_STATE_MAX },
> >  };
> >  
> > @@ -2001,7 +2009,8 @@ static bool main_loop_should_exit(void)
> >          qemu_system_reset(VMRESET_REPORT);
> >          resume_all_vcpus();
> >          if (runstate_check(RUN_STATE_INTERNAL_ERROR) ||
> > -            runstate_check(RUN_STATE_SHUTDOWN)) {
> > +            runstate_check(RUN_STATE_SHUTDOWN) ||
> > +            runstate_check(RUN_STATE_GUEST_PANICKED)) {
> >              bdrv_iterate(iostatus_bdrv_it, NULL);
> >              vm_start();
> >          }
> > 

Re: [Qemu-devel] [PATCH v13 4/8] add a new runstate: RUN_STATE_GUEST_PANICKED

[Paolo Bonzini]

Il 05/03/2013 04:17, Hu Tao ha scritto:
> Will 
> 
>          if (runstate_check(RUN_STATE_INTERNAL_ERROR) ||
>              runstate_check(RUN_STATE_SHUTDOWN) ||
>              runstate_check(RUN_STATE_GUEST_PANICKED)) {
>              runstate_set(RUN_STATE_PAUSED);
>          }
> 
> be OK? Or I must be misunderstanding you.
> 

Please move

       return (runstate_check(RUN_STATE_INTERNAL_ERROR) ||
               runstate_check(RUN_STATE_SHUTDOWN) ||
               runstate_check(RUN_STATE_GUEST_PANICKED));

to a separate function (runstate_needs_reset for example), so that you
can reuse it in the two or three places that need it.

Paolo

Re: [Qemu-devel] [PATCH v13 4/8] add a new runstate: RUN_STATE_GUEST_PANICKED

[Hu Tao]

On Tue, Mar 05, 2013 at 09:26:18AM +0100, Paolo Bonzini wrote:
> Il 05/03/2013 04:17, Hu Tao ha scritto:
> > Will 
> > 
> >          if (runstate_check(RUN_STATE_INTERNAL_ERROR) ||
> >              runstate_check(RUN_STATE_SHUTDOWN) ||
> >              runstate_check(RUN_STATE_GUEST_PANICKED)) {
> >              runstate_set(RUN_STATE_PAUSED);
> >          }
> > 
> > be OK? Or I must be misunderstanding you.
> > 
> 
> Please move
> 
>        return (runstate_check(RUN_STATE_INTERNAL_ERROR) ||
>                runstate_check(RUN_STATE_SHUTDOWN) ||
>                runstate_check(RUN_STATE_GUEST_PANICKED));
> 
> to a separate function (runstate_needs_reset for example), so that you
> can reuse it in the two or three places that need it.

See it now. Thanks!

Re: [Qemu-devel] [PATCH v13 7/8] allower the user to disable pv event support

[Paolo Bonzini]

Il 28/02/2013 13:13, Hu Tao ha scritto:
> Signed-off-by: Wen Congyang <wency@cn.fujitsu.com>
> Signed-off-by: Hu Tao <hutao@cn.fujitsu.com>
> ---
>  hw/pc_piix.c    | 9 ++++++++-
>  qemu-options.hx | 3 ++-
>  vl.c            | 4 ++++
>  3 files changed, 14 insertions(+), 2 deletions(-)

We cannot add -machine suboptions for everything we add to a random
machine type.  I think it's better to do one of the following:

1) not add it to the machine by default.  Let libvirt add it with -device.

2) add a property to the piix3 ISA bridges (in hw/piix_pci.c) to
enable/disable it.  It can be set with -global PIIX3.pv_event=on/off.

In the second case, if you set it to on by default, you will also need
to add the property in hw/pc.h, to disable the device in older machine
types for backwards-compatibility.

Paolo

> diff --git a/hw/pc_piix.c b/hw/pc_piix.c
> index 24a9bf3..82a421a 100644
> --- a/hw/pc_piix.c
> +++ b/hw/pc_piix.c
> @@ -44,6 +44,7 @@
>  #include "exec/memory.h"
>  #include "exec/address-spaces.h"
>  #include "cpu.h"
> +#include "qemu/config-file.h"
>  #ifdef CONFIG_XEN
>  #  include <xen/hvm/hvm_info_table.h>
>  #endif
> @@ -86,6 +87,8 @@ static void pc_init1(MemoryRegion *system_memory,
>      MemoryRegion *pci_memory;
>      MemoryRegion *rom_memory;
>      void *fw_cfg = NULL;
> +    QemuOptsList *list = qemu_find_opts("machine");
> +    bool enable_pv_event = false;
>  
>      pc_cpus_init(cpu_model);
>      pc_acpi_init("acpi-dsdt.aml");
> @@ -218,7 +221,11 @@ static void pc_init1(MemoryRegion *system_memory,
>          pc_pci_device_init(pci_bus);
>      }
>  
> -    if (kvm_enabled()) {
> +    if (list && !QTAILQ_EMPTY(&list->head)) {
> +        enable_pv_event = qemu_opt_get_bool(QTAILQ_FIRST(&list->head),
> +                                            "enable_pv_event", false);
> +    }
> +    if (kvm_enabled() && enable_pv_event) {
>          kvm_pv_event_init(isa_bus);
>      }
>  }
> diff --git a/qemu-options.hx b/qemu-options.hx
> index 797d992..1ad4041 100644
> --- a/qemu-options.hx
> +++ b/qemu-options.hx
> @@ -35,7 +35,8 @@ DEF("machine", HAS_ARG, QEMU_OPTION_machine, \
>      "                kernel_irqchip=on|off controls accelerated irqchip support\n"
>      "                kvm_shadow_mem=size of KVM shadow MMU\n"
>      "                dump-guest-core=on|off include guest memory in a core dump (default=on)\n"
> -    "                mem-merge=on|off controls memory merge support (default: on)\n",
> +    "                mem-merge=on|off controls memory merge support (default: on)\n"
> +    "                enable_pv_event=on|off controls pv event support (default: off)\n",
>      QEMU_ARCH_ALL)
>  STEXI
>  @item -machine [type=]@var{name}[,prop=@var{value}[,...]]
> diff --git a/vl.c b/vl.c
> index 51d4922..5b3a279 100644
> --- a/vl.c
> +++ b/vl.c
> @@ -427,6 +427,10 @@ static QemuOptsList qemu_machine_opts = {
>              .name = "usb",
>              .type = QEMU_OPT_BOOL,
>              .help = "Set on/off to enable/disable usb",
> +        }, {
> +            .name = "enable_pv_event",
> +            .type = QEMU_OPT_BOOL,
> +            .help = "handle pv event"
>          },
>          { /* End of list */ }
>      },
> 

Re: [Qemu-devel] [PATCH v13 6/8] introduce a new qom device to deal with panicked event

[Paolo Bonzini]

Il 28/02/2013 13:13, Hu Tao ha scritto:
> If the target is x86/x86_64, the guest's kernel will write 0x01 to the
> port KVM_PV_EVENT_PORT when it is panciked. This patch introduces a new
> qom device kvm_pv_ioport to listen this I/O port, and deal with panicked
> event according to panicked_action's value. The possible actions are:
> 1. emit QEVENT_GUEST_PANICKED only
> 2. emit QEVENT_GUEST_PANICKED and pause the guest
> 3. emit QEVENT_GUEST_PANICKED and poweroff the guest
> 4. emit QEVENT_GUEST_PANICKED and reset the guest
> 
> I/O ports does not work for some targets(for example: s390). And you
> can implement another qom device, and include it's code into pv_event.c
> for such target.
> 
> Note: if we emit QEVENT_GUEST_PANICKED only, and the management
> application does not receive this event(the management may not
> run when the event is emitted), the management won't know the
> guest is panicked.

There's nothing KVM-specific about this, no?

Let's call the device hw/pvevent.c, and the device isa-pvevent like
isa-debugcon and isa-debugexit.

Paolo

> Signed-off-by: Wen Congyang <wency@cn.fujitsu.com>
> Signed-off-by: Hu Tao <hutao@cn.fujitsu.com>
> ---
>  hw/kvm/Makefile.objs |   2 +-
>  hw/kvm/pv_event.c    | 198 +++++++++++++++++++++++++++++++++++++++++++++++++++
>  hw/pc_piix.c         |   5 ++
>  include/sysemu/kvm.h |   2 +
>  kvm-stub.c           |   4 ++
>  5 files changed, 210 insertions(+), 1 deletion(-)
>  create mode 100644 hw/kvm/pv_event.c
> 
> diff --git a/hw/kvm/Makefile.objs b/hw/kvm/Makefile.objs
> index f620d7f..cf93199 100644
> --- a/hw/kvm/Makefile.objs
> +++ b/hw/kvm/Makefile.objs
> @@ -1 +1 @@
> -obj-$(CONFIG_KVM) += clock.o apic.o i8259.o ioapic.o i8254.o pci-assign.o
> +obj-$(CONFIG_KVM) += clock.o apic.o i8259.o ioapic.o i8254.o pci-assign.o pv_event.o
> diff --git a/hw/kvm/pv_event.c b/hw/kvm/pv_event.c
> new file mode 100644
> index 0000000..5e68190
> --- /dev/null
> +++ b/hw/kvm/pv_event.c
> @@ -0,0 +1,198 @@
> +/*
> + * QEMU KVM support, paravirtual event device
> + *
> + * Copyright Fujitsu, Corp. 2012
> + *
> + * Authors:
> + *     Wen Congyang <wency@cn.fujitsu.com>
> + *
> + * This work is licensed under the terms of the GNU GPL, version 2 or later.
> + * See the COPYING file in the top-level directory.
> + *
> + */
> +
> +#include <linux/kvm_para.h>
> +#include <asm/kvm_para.h>
> +#include <qapi/qmp/qobject.h>
> +#include <qapi/qmp/qjson.h>
> +#include <monitor/monitor.h>
> +#include <sysemu/sysemu.h>
> +#include <sysemu/kvm.h>
> +
> +/* Possible values for action parameter. */
> +#define PANICKED_REPORT     1   /* emit QEVENT_GUEST_PANICKED only */
> +#define PANICKED_PAUSE      2   /* emit QEVENT_GUEST_PANICKED and pause VM */
> +#define PANICKED_POWEROFF   3   /* emit QEVENT_GUEST_PANICKED and quit VM */
> +#define PANICKED_RESET      4   /* emit QEVENT_GUEST_PANICKED and reset VM */
> +
> +#define PV_EVENT_DRIVER     "kvm_pv_event"
> +#define PV_IOPORT(obj)      OBJECT_CHECK(PVIOPortState, (obj), PV_EVENT_DRIVER)
> +
> +struct PVEventAction {
> +    char *panicked_action;
> +    int panicked_action_value;
> +};
> +
> +#define DEFINE_PV_EVENT_PROPERTIES(_state, _conf)   \
> +    DEFINE_PROP_STRING("panicked_action", _state, _conf.panicked_action)
> +
> +static void panicked_mon_event(const char *action)
> +{
> +    QObject *data;
> +
> +    data = qobject_from_jsonf("{ 'action': %s }", action);
> +    monitor_protocol_event(QEVENT_GUEST_PANICKED, data);
> +    qobject_decref(data);
> +}
> +
> +static void panicked_perform_action(uint32_t panicked_action)
> +{
> +    switch (panicked_action) {
> +    case PANICKED_REPORT:
> +        panicked_mon_event("report");
> +        break;
> +
> +    case PANICKED_PAUSE:
> +        panicked_mon_event("pause");
> +        vm_stop(RUN_STATE_GUEST_PANICKED);
> +        break;
> +
> +    case PANICKED_POWEROFF:
> +        panicked_mon_event("poweroff");
> +        qemu_system_shutdown_request();
> +        break;
> +
> +    case PANICKED_RESET:
> +        panicked_mon_event("reset");
> +        qemu_system_reset_request();
> +        break;
> +    }
> +}
> +
> +static uint64_t supported_event(void)
> +{
> +    return 1 << KVM_PV_FEATURE_PANICKED;
> +}
> +
> +static void handle_event(int event, struct PVEventAction *conf)
> +{
> +    if (event == KVM_PV_EVENT_PANICKED) {
> +        panicked_perform_action(conf->panicked_action_value);
> +    }
> +}
> +
> +static int pv_event_init(struct PVEventAction *conf)
> +{
> +    if (!conf->panicked_action) {
> +        conf->panicked_action_value = PANICKED_REPORT;
> +    } else if (strcasecmp(conf->panicked_action, "none") == 0) {
> +        conf->panicked_action_value = PANICKED_REPORT;
> +    } else if (strcasecmp(conf->panicked_action, "pause") == 0) {
> +        conf->panicked_action_value = PANICKED_PAUSE;
> +    } else if (strcasecmp(conf->panicked_action, "poweroff") == 0) {
> +        conf->panicked_action_value = PANICKED_POWEROFF;
> +    } else if (strcasecmp(conf->panicked_action, "reset") == 0) {
> +        conf->panicked_action_value = PANICKED_RESET;
> +    } else {
> +        return -1;
> +    }
> +
> +    return 0;
> +}
> +
> +#if defined(KVM_PV_EVENT_PORT)
> +
> +#include "hw/isa.h"
> +
> +typedef struct {
> +    ISADevice dev;
> +    struct PVEventAction conf;
> +    MemoryRegion ioport;
> +} PVIOPortState;
> +
> +static uint64_t pv_io_read(void *opaque, hwaddr addr, unsigned size)
> +{
> +    return supported_event();
> +}
> +
> +static void pv_io_write(void *opaque, hwaddr addr, uint64_t val,
> +                        unsigned size)
> +{
> +    PVIOPortState *s = opaque;
> +
> +    handle_event(val, &s->conf);
> +}
> +
> +static const MemoryRegionOps pv_io_ops = {
> +    .read = pv_io_read,
> +    .write = pv_io_write,
> +    .impl = {
> +        .min_access_size = 4,
> +        .max_access_size = 4,
> +    },
> +};
> +
> +static int pv_ioport_initfn(ISADevice *dev)
> +{
> +    PVIOPortState *s = PV_IOPORT(dev);
> +
> +    if (pv_event_init(&s->conf) < 0) {
> +        return -1;
> +    }
> +
> +    memory_region_init_io(&s->ioport, &pv_io_ops, s, "pv_event", 4);
> +    isa_register_ioport(dev, &s->ioport, KVM_PV_EVENT_PORT);
> +
> +    return 0;
> +}
> +
> +static Property pv_ioport_properties[] = {
> +    DEFINE_PV_EVENT_PROPERTIES(PVIOPortState, conf),
> +    DEFINE_PROP_END_OF_LIST(),
> +};
> +
> +static void pv_ioport_class_init(ObjectClass *klass, void *data)
> +{
> +    DeviceClass *dc = DEVICE_CLASS(klass);
> +    ISADeviceClass *ic = ISA_DEVICE_CLASS(klass);
> +
> +    ic->init = pv_ioport_initfn;
> +    dc->no_user = 1;
> +    dc->props = pv_ioport_properties;
> +}
> +
> +static TypeInfo pv_ioport_info = {
> +    .name          = PV_EVENT_DRIVER,
> +    .parent        = TYPE_ISA_DEVICE,
> +    .instance_size = sizeof(PVIOPortState),
> +    .class_init    = pv_ioport_class_init,
> +};
> +
> +static void pv_ioport_register_types(void)
> +{
> +    type_register_static(&pv_ioport_info);
> +}
> +
> +type_init(pv_ioport_register_types)
> +
> +void kvm_pv_event_init(void *opaque)
> +{
> +    ISABus *bus = opaque;
> +    ISADevice *dev;
> +
> +    dev = isa_create(bus, PV_EVENT_DRIVER);
> +    qdev_init_nofail(&dev->qdev);
> +}
> +
> +#else
> +
> +/*
> + * If you need a qom device to handle pv event, this device should
> + * be created and initialized in kvm_pv_event_init().
> + *
> + * The parameter opaque is the device's parent bus.
> + */
> +void kvm_pv_event_init(void *opaque)
> +{
> +}
> +#endif
> diff --git a/hw/pc_piix.c b/hw/pc_piix.c
> index aa9cc81..24a9bf3 100644
> --- a/hw/pc_piix.c
> +++ b/hw/pc_piix.c
> @@ -47,6 +47,7 @@
>  #ifdef CONFIG_XEN
>  #  include <xen/hvm/hvm_info_table.h>
>  #endif
> +#include <linux/kvm_para.h>
>  
>  #define MAX_IDE_BUS 2
>  
> @@ -216,6 +217,10 @@ static void pc_init1(MemoryRegion *system_memory,
>      if (pci_enabled) {
>          pc_pci_device_init(pci_bus);
>      }
> +
> +    if (kvm_enabled()) {
> +        kvm_pv_event_init(isa_bus);
> +    }
>  }
>  
>  static void pc_init_pci(QEMUMachineInitArgs *args)
> diff --git a/include/sysemu/kvm.h b/include/sysemu/kvm.h
> index f2d97b5..97d3daf 100644
> --- a/include/sysemu/kvm.h
> +++ b/include/sysemu/kvm.h
> @@ -296,4 +296,6 @@ int kvm_irqchip_add_irqfd_notifier(KVMState *s, EventNotifier *n, int virq);
>  int kvm_irqchip_remove_irqfd_notifier(KVMState *s, EventNotifier *n, int virq);
>  void kvm_pc_gsi_handler(void *opaque, int n, int level);
>  void kvm_pc_setup_irq_routing(bool pci_enabled);
> +
> +void kvm_pv_event_init(void *opaque);
>  #endif
> diff --git a/kvm-stub.c b/kvm-stub.c
> index 760aadc..f543fa2 100644
> --- a/kvm-stub.c
> +++ b/kvm-stub.c
> @@ -145,3 +145,7 @@ int kvm_irqchip_remove_irqfd_notifier(KVMState *s, EventNotifier *n, int virq)
>  {
>      return -ENOSYS;
>  }
> +
> +void kvm_pv_event_init(void *opaque)
> +{
> +}
> 

Re: [Qemu-devel] [PATCH v13 6/8] introduce a new qom device to deal with panicked event

[Christian Borntraeger]

On 28/02/13 13:13, Hu Tao wrote:
> If the target is x86/x86_64, the guest's kernel will write 0x01 to the
> port KVM_PV_EVENT_PORT when it is panciked. This patch introduces a new
> qom device kvm_pv_ioport to listen this I/O port, and deal with panicked
> event according to panicked_action's value. The possible actions are:
> 1. emit QEVENT_GUEST_PANICKED only
> 2. emit QEVENT_GUEST_PANICKED and pause the guest
> 3. emit QEVENT_GUEST_PANICKED and poweroff the guest
> 4. emit QEVENT_GUEST_PANICKED and reset the guest
> 
> I/O ports does not work for some targets(for example: s390). And you
> can implement another qom device, and include it's code into pv_event.c
> for such target.


Hmm, I am tempted to just reuse the disabled wait state on s390. This is
a state were all CPUs are disabled for interrupts and a wait PSW is loaded.
This is commonly used on all s390 operating systems as a state of attention
(some OSes even use the instruction address as a code). The Linux kernel
also uses disabled wait on Panic.

Right now we have some special handling on disabled wait:
- non-disabled wait (all cpus stopped): quit qemu
- disabled wait: put last cpu in halted state to allow a memory dump

So we could just use a simplified version

--- a/target-s390x/kvm.c
+++ b/target-s390x/kvm.c
@@ -759,6 +759,11 @@ static int handle_intercept(S390CPU *cpu)
                 is_special_wait_psw(cs)) {
                 qemu_system_shutdown_request();
             }
+            //disabled wait: we either
+            //do a
+            //monitor_protocol_event(QEVENT_GUEST_PANICKED, whatever);
+            //or
+            //or call into pvevent
             r = EXCP_HALTED;
             break;
         case ICPT_CPU_STOP:


I would prefer to just use the monitor_protocol_event, on the other hand
a call into pvent could make it configurable.

Christian

> 
> Note: if we emit QEVENT_GUEST_PANICKED only, and the management
> application does not receive this event(the management may not
> run when the event is emitted), the management won't know the
> guest is panicked.
> 
> Signed-off-by: Wen Congyang <wency@cn.fujitsu.com>
> Signed-off-by: Hu Tao <hutao@cn.fujitsu.com>
> ---
>  hw/kvm/Makefile.objs |   2 +-
>  hw/kvm/pv_event.c    | 198 +++++++++++++++++++++++++++++++++++++++++++++++++++
>  hw/pc_piix.c         |   5 ++
>  include/sysemu/kvm.h |   2 +
>  kvm-stub.c           |   4 ++
>  5 files changed, 210 insertions(+), 1 deletion(-)
>  create mode 100644 hw/kvm/pv_event.c
> 
> diff --git a/hw/kvm/Makefile.objs b/hw/kvm/Makefile.objs
> index f620d7f..cf93199 100644
> --- a/hw/kvm/Makefile.objs
> +++ b/hw/kvm/Makefile.objs
> @@ -1 +1 @@
> -obj-$(CONFIG_KVM) += clock.o apic.o i8259.o ioapic.o i8254.o pci-assign.o
> +obj-$(CONFIG_KVM) += clock.o apic.o i8259.o ioapic.o i8254.o pci-assign.o pv_event.o
> diff --git a/hw/kvm/pv_event.c b/hw/kvm/pv_event.c
> new file mode 100644
> index 0000000..5e68190
> --- /dev/null
> +++ b/hw/kvm/pv_event.c
> @@ -0,0 +1,198 @@
> +/*
> + * QEMU KVM support, paravirtual event device
> + *
> + * Copyright Fujitsu, Corp. 2012
> + *
> + * Authors:
> + *     Wen Congyang <wency@cn.fujitsu.com>
> + *
> + * This work is licensed under the terms of the GNU GPL, version 2 or later.
> + * See the COPYING file in the top-level directory.
> + *
> + */
> +
> +#include <linux/kvm_para.h>
> +#include <asm/kvm_para.h>
> +#include <qapi/qmp/qobject.h>
> +#include <qapi/qmp/qjson.h>
> +#include <monitor/monitor.h>
> +#include <sysemu/sysemu.h>
> +#include <sysemu/kvm.h>
> +
> +/* Possible values for action parameter. */
> +#define PANICKED_REPORT     1   /* emit QEVENT_GUEST_PANICKED only */
> +#define PANICKED_PAUSE      2   /* emit QEVENT_GUEST_PANICKED and pause VM */
> +#define PANICKED_POWEROFF   3   /* emit QEVENT_GUEST_PANICKED and quit VM */
> +#define PANICKED_RESET      4   /* emit QEVENT_GUEST_PANICKED and reset VM */
> +
> +#define PV_EVENT_DRIVER     "kvm_pv_event"
> +#define PV_IOPORT(obj)      OBJECT_CHECK(PVIOPortState, (obj), PV_EVENT_DRIVER)
> +
> +struct PVEventAction {
> +    char *panicked_action;
> +    int panicked_action_value;
> +};
> +
> +#define DEFINE_PV_EVENT_PROPERTIES(_state, _conf)   \
> +    DEFINE_PROP_STRING("panicked_action", _state, _conf.panicked_action)
> +
> +static void panicked_mon_event(const char *action)
> +{
> +    QObject *data;
> +
> +    data = qobject_from_jsonf("{ 'action': %s }", action);
> +    monitor_protocol_event(QEVENT_GUEST_PANICKED, data);
> +    qobject_decref(data);
> +}
> +
> +static void panicked_perform_action(uint32_t panicked_action)
> +{
> +    switch (panicked_action) {
> +    case PANICKED_REPORT:
> +        panicked_mon_event("report");
> +        break;
> +
> +    case PANICKED_PAUSE:
> +        panicked_mon_event("pause");
> +        vm_stop(RUN_STATE_GUEST_PANICKED);
> +        break;
> +
> +    case PANICKED_POWEROFF:
> +        panicked_mon_event("poweroff");
> +        qemu_system_shutdown_request();
> +        break;
> +
> +    case PANICKED_RESET:
> +        panicked_mon_event("reset");
> +        qemu_system_reset_request();
> +        break;
> +    }
> +}
> +
> +static uint64_t supported_event(void)
> +{
> +    return 1 << KVM_PV_FEATURE_PANICKED;
> +}
> +
> +static void handle_event(int event, struct PVEventAction *conf)
> +{
> +    if (event == KVM_PV_EVENT_PANICKED) {
> +        panicked_perform_action(conf->panicked_action_value);
> +    }
> +}
> +
> +static int pv_event_init(struct PVEventAction *conf)
> +{
> +    if (!conf->panicked_action) {
> +        conf->panicked_action_value = PANICKED_REPORT;
> +    } else if (strcasecmp(conf->panicked_action, "none") == 0) {
> +        conf->panicked_action_value = PANICKED_REPORT;
> +    } else if (strcasecmp(conf->panicked_action, "pause") == 0) {
> +        conf->panicked_action_value = PANICKED_PAUSE;
> +    } else if (strcasecmp(conf->panicked_action, "poweroff") == 0) {
> +        conf->panicked_action_value = PANICKED_POWEROFF;
> +    } else if (strcasecmp(conf->panicked_action, "reset") == 0) {
> +        conf->panicked_action_value = PANICKED_RESET;
> +    } else {
> +        return -1;
> +    }
> +
> +    return 0;
> +}
> +
> +#if defined(KVM_PV_EVENT_PORT)
> +
> +#include "hw/isa.h"
> +
> +typedef struct {
> +    ISADevice dev;
> +    struct PVEventAction conf;
> +    MemoryRegion ioport;
> +} PVIOPortState;
> +
> +static uint64_t pv_io_read(void *opaque, hwaddr addr, unsigned size)
> +{
> +    return supported_event();
> +}
> +
> +static void pv_io_write(void *opaque, hwaddr addr, uint64_t val,
> +                        unsigned size)
> +{
> +    PVIOPortState *s = opaque;
> +
> +    handle_event(val, &s->conf);
> +}
> +
> +static const MemoryRegionOps pv_io_ops = {
> +    .read = pv_io_read,
> +    .write = pv_io_write,
> +    .impl = {
> +        .min_access_size = 4,
> +        .max_access_size = 4,
> +    },
> +};
> +
> +static int pv_ioport_initfn(ISADevice *dev)
> +{
> +    PVIOPortState *s = PV_IOPORT(dev);
> +
> +    if (pv_event_init(&s->conf) < 0) {
> +        return -1;
> +    }
> +
> +    memory_region_init_io(&s->ioport, &pv_io_ops, s, "pv_event", 4);
> +    isa_register_ioport(dev, &s->ioport, KVM_PV_EVENT_PORT);
> +
> +    return 0;
> +}
> +
> +static Property pv_ioport_properties[] = {
> +    DEFINE_PV_EVENT_PROPERTIES(PVIOPortState, conf),
> +    DEFINE_PROP_END_OF_LIST(),
> +};
> +
> +static void pv_ioport_class_init(ObjectClass *klass, void *data)
> +{
> +    DeviceClass *dc = DEVICE_CLASS(klass);
> +    ISADeviceClass *ic = ISA_DEVICE_CLASS(klass);
> +
> +    ic->init = pv_ioport_initfn;
> +    dc->no_user = 1;
> +    dc->props = pv_ioport_properties;
> +}
> +
> +static TypeInfo pv_ioport_info = {
> +    .name          = PV_EVENT_DRIVER,
> +    .parent        = TYPE_ISA_DEVICE,
> +    .instance_size = sizeof(PVIOPortState),
> +    .class_init    = pv_ioport_class_init,
> +};
> +
> +static void pv_ioport_register_types(void)
> +{
> +    type_register_static(&pv_ioport_info);
> +}
> +
> +type_init(pv_ioport_register_types)
> +
> +void kvm_pv_event_init(void *opaque)
> +{
> +    ISABus *bus = opaque;
> +    ISADevice *dev;
> +
> +    dev = isa_create(bus, PV_EVENT_DRIVER);
> +    qdev_init_nofail(&dev->qdev);
> +}
> +
> +#else
> +
> +/*
> + * If you need a qom device to handle pv event, this device should
> + * be created and initialized in kvm_pv_event_init().
> + *
> + * The parameter opaque is the device's parent bus.
> + */
> +void kvm_pv_event_init(void *opaque)
> +{
> +}
> +#endif
> diff --git a/hw/pc_piix.c b/hw/pc_piix.c
> index aa9cc81..24a9bf3 100644
> --- a/hw/pc_piix.c
> +++ b/hw/pc_piix.c
> @@ -47,6 +47,7 @@
>  #ifdef CONFIG_XEN
>  #  include <xen/hvm/hvm_info_table.h>
>  #endif
> +#include <linux/kvm_para.h>
> 
>  #define MAX_IDE_BUS 2
> 
> @@ -216,6 +217,10 @@ static void pc_init1(MemoryRegion *system_memory,
>      if (pci_enabled) {
>          pc_pci_device_init(pci_bus);
>      }
> +
> +    if (kvm_enabled()) {
> +        kvm_pv_event_init(isa_bus);
> +    }
>  }
> 
>  static void pc_init_pci(QEMUMachineInitArgs *args)
> diff --git a/include/sysemu/kvm.h b/include/sysemu/kvm.h
> index f2d97b5..97d3daf 100644
> --- a/include/sysemu/kvm.h
> +++ b/include/sysemu/kvm.h
> @@ -296,4 +296,6 @@ int kvm_irqchip_add_irqfd_notifier(KVMState *s, EventNotifier *n, int virq);
>  int kvm_irqchip_remove_irqfd_notifier(KVMState *s, EventNotifier *n, int virq);
>  void kvm_pc_gsi_handler(void *opaque, int n, int level);
>  void kvm_pc_setup_irq_routing(bool pci_enabled);
> +
> +void kvm_pv_event_init(void *opaque);
>  #endif
> diff --git a/kvm-stub.c b/kvm-stub.c
> index 760aadc..f543fa2 100644
> --- a/kvm-stub.c
> +++ b/kvm-stub.c
> @@ -145,3 +145,7 @@ int kvm_irqchip_remove_irqfd_notifier(KVMState *s, EventNotifier *n, int virq)
>  {
>      return -ENOSYS;
>  }
> +
> +void kvm_pv_event_init(void *opaque)
> +{
> +}
> 

Re: [Qemu-devel] [PATCH v13 6/8] introduce a new qom device to deal with panicked event

[Paolo Bonzini]

Il 04/03/2013 11:10, Christian Borntraeger ha scritto:
> +            //disabled wait: we either
> +            //do a
> +            //monitor_protocol_event(QEVENT_GUEST_PANICKED, whatever);
> +            //or
> +            //or call into pvevent
>              r = EXCP_HALTED;
>              break;
>          case ICPT_CPU_STOP:
> 
> 
> I would prefer to just use the monitor_protocol_event, on the other hand
> a call into pvent could make it configurable.

I asked in my review to make pvevent not configurable,  So

   monitor_protocol_event(QEVENT_GUEST_PANICKED);
   vm_stop(RUNSTATE_GUEST_PANICKED);

would do I guess.

Feel free to submit a patch to qemu-devel.  Hu, please take any patch
that Christian submits and incorporate it in your series for future posting.

Paolo