On 31/10/13 15:30, Michael S. Tsirkin wrote:
On Thu, Oct 24, 2013 at 10:39:03AM +0800, Hu Tao wrote:
Hi All,
I know it's been a long time since this thread. But qemu 1.7 is
releasing, do you have any consensus on this?
Thanks.
I think the biggest issue is the new PANICKED state.
I
On Thu, Oct 24, 2013 at 10:39:03AM +0800, Hu Tao wrote:
Hi All,
I know it's been a long time since this thread. But qemu 1.7 is
releasing, do you have any consensus on this?
Thanks.
I think the biggest issue is the new PANICKED state.
Guests already have simple ways to halt the CPU,
and
On 10/31/2013 08:30 AM, Michael S. Tsirkin wrote:
On Thu, Oct 24, 2013 at 10:39:03AM +0800, Hu Tao wrote:
Hi All,
I know it's been a long time since this thread. But qemu 1.7 is
releasing, do you have any consensus on this?
Thanks.
I think the biggest issue is the new PANICKED state.
On Thu, Oct 31, 2013 at 3:32 PM, Eric Blake ebl...@redhat.com wrote:
On 10/31/2013 08:30 AM, Michael S. Tsirkin wrote:
On Thu, Oct 24, 2013 at 10:39:03AM +0800, Hu Tao wrote:
Hi All,
I know it's been a long time since this thread. But qemu 1.7 is
releasing, do you have any consensus on this?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Il 31/10/2013 15:32, Eric Blake ha scritto:
On 10/31/2013 08:30 AM, Michael S. Tsirkin wrote:
On Thu, Oct 24, 2013 at 10:39:03AM +0800, Hu Tao wrote:
Hi All,
I know it's been a long time since this thread. But qemu 1.7 is
releasing, do you have
On Thu, Oct 31, 2013 at 08:32:43AM -0600, Eric Blake wrote:
On 10/31/2013 08:30 AM, Michael S. Tsirkin wrote:
On Thu, Oct 24, 2013 at 10:39:03AM +0800, Hu Tao wrote:
Hi All,
I know it's been a long time since this thread. But qemu 1.7 is
releasing, do you have any consensus on this?
On 10/31/2013 08:47 AM, Michael S. Tsirkin wrote:
if (event PVPANIC_PANICKED) {
panicked_mon_event(pause);
-vm_stop(RUN_STATE_GUEST_PANICKED);
Don't you still need to halt the guest on a panic event, for management
to have a chance to choose what to do about the
On Thu, Oct 31, 2013 at 03:39:17PM +0100, Paolo Bonzini wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Il 31/10/2013 15:32, Eric Blake ha scritto:
On 10/31/2013 08:30 AM, Michael S. Tsirkin wrote:
On Thu, Oct 24, 2013 at 10:39:03AM +0800, Hu Tao wrote:
Hi All,
I know it's
Il 31/10/2013 15:52, Michael S. Tsirkin ha scritto:
Yes, it does.
What does it break exactly?
The point of a panicked event is to examine the guest at a particular
moment in time (e.g. host-initiated crash dump). If you let the guest
run, it may reboot and prevent you from getting a
On Thu, Oct 31, 2013 at 03:56:42PM +0100, Paolo Bonzini wrote:
Il 31/10/2013 15:52, Michael S. Tsirkin ha scritto:
Yes, it does.
What does it break exactly?
The point of a panicked event is to examine the guest at a particular
moment in time (e.g. host-initiated crash dump). If you let
On Thu, Oct 31, 2013 at 08:49:08AM -0600, Eric Blake wrote:
On 10/31/2013 08:47 AM, Michael S. Tsirkin wrote:
if (event PVPANIC_PANICKED) {
panicked_mon_event(pause);
-vm_stop(RUN_STATE_GUEST_PANICKED);
Don't you still need to halt the guest on a panic event,
Il 31/10/2013 16:09, Michael S. Tsirkin ha scritto:
On Thu, Oct 31, 2013 at 03:56:42PM +0100, Paolo Bonzini wrote:
Il 31/10/2013 15:52, Michael S. Tsirkin ha scritto:
Yes, it does.
What does it break exactly?
The point of a panicked event is to examine the guest at a particular
moment in
On Thu, Oct 31, 2013 at 04:26:13PM +0100, Paolo Bonzini wrote:
Il 31/10/2013 16:09, Michael S. Tsirkin ha scritto:
On Thu, Oct 31, 2013 at 03:56:42PM +0100, Paolo Bonzini wrote:
Il 31/10/2013 15:52, Michael S. Tsirkin ha scritto:
Yes, it does.
What does it break exactly?
The point of
On Thu, Oct 31, 2013 at 04:56:07PM +0100, Paolo Bonzini wrote:
Il 31/10/2013 16:45, Michael S. Tsirkin ha scritto:
On Thu, Oct 31, 2013 at 04:26:13PM +0100, Paolo Bonzini wrote:
Il 31/10/2013 16:09, Michael S. Tsirkin ha scritto:
On Thu, Oct 31, 2013 at 03:56:42PM +0100, Paolo Bonzini
Il 31/10/2013 17:14, Michael S. Tsirkin ha scritto:
PANICKED-DEBUG was added by commit bc7d0e667. That commit can be
reverted if the panicked state is removed from runstate_needs_reset.
Okay so let's drop the code duplication and explicitly make
them the same?
Signed-off-by: Michael S.
On Thu, Oct 31, 2013 at 05:17:24PM +0100, Paolo Bonzini wrote:
Il 31/10/2013 17:14, Michael S. Tsirkin ha scritto:
PANICKED-DEBUG was added by commit bc7d0e667. That commit can be
reverted if the panicked state is removed from runstate_needs_reset.
Okay so let's drop the code
On Thu, Oct 31, 2013 at 05:17:24PM +0100, Paolo Bonzini wrote:
Il 31/10/2013 17:14, Michael S. Tsirkin ha scritto:
PANICKED-DEBUG was added by commit bc7d0e667. That commit can be
reverted if the panicked state is removed from runstate_needs_reset.
Okay so let's drop the code
Il 31/10/2013 17:26, Michael S. Tsirkin ha scritto:
On Thu, Oct 31, 2013 at 05:17:24PM +0100, Paolo Bonzini wrote:
Il 31/10/2013 17:14, Michael S. Tsirkin ha scritto:
PANICKED-DEBUG was added by commit bc7d0e667. That commit can be
reverted if the panicked state is removed from
On Thu, Oct 31, 2013 at 05:38:40PM +0100, Paolo Bonzini wrote:
Il 31/10/2013 17:26, Michael S. Tsirkin ha scritto:
On Thu, Oct 31, 2013 at 05:17:24PM +0100, Paolo Bonzini wrote:
Il 31/10/2013 17:14, Michael S. Tsirkin ha scritto:
PANICKED-DEBUG was added by commit bc7d0e667. That commit
Il 31/10/2013 17:48, Michael S. Tsirkin ha scritto:
But code duplication is bad.
So should we make a table of IO_ERROR-like states to avoid code
duplication? You have to draw a line somewhere...
I think IO error for example
is broken in that you can't pause but can run then pause.
Seems
On Thu, Oct 31, 2013 at 05:52:11PM +0100, Paolo Bonzini wrote:
Il 31/10/2013 17:48, Michael S. Tsirkin ha scritto:
But code duplication is bad.
So should we make a table of IO_ERROR-like states to avoid code
duplication? You have to draw a line somewhere...
I think IO error for example
On Thu, Oct 31, 2013 at 05:38:40PM +0100, Paolo Bonzini wrote:
Il 31/10/2013 17:26, Michael S. Tsirkin ha scritto:
On Thu, Oct 31, 2013 at 05:17:24PM +0100, Paolo Bonzini wrote:
Il 31/10/2013 17:14, Michael S. Tsirkin ha scritto:
PANICKED-DEBUG was added by commit bc7d0e667. That commit
Il 31/10/2013 16:45, Michael S. Tsirkin ha scritto:
On Thu, Oct 31, 2013 at 04:26:13PM +0100, Paolo Bonzini wrote:
Il 31/10/2013 16:09, Michael S. Tsirkin ha scritto:
On Thu, Oct 31, 2013 at 03:56:42PM +0100, Paolo Bonzini wrote:
Il 31/10/2013 15:52, Michael S. Tsirkin ha scritto:
Yes, it
Il 31/10/2013 18:00, Michael S. Tsirkin ha scritto:
Interesting. Why do we have
-{ RUN_STATE_INTERNAL_ERROR, RUN_STATE_PAUSED },
then?
It's only for non-resumable states (such as pvpanic right now).
It's used here:
if (qemu_reset_requested()) {
pause_all_vcpus();
Il 31/10/2013 18:01, Michael S. Tsirkin ha scritto:
Yes, that's what my patch (posted the link before) does:
-{ RUN_STATE_GUEST_PANICKED, RUN_STATE_PAUSED },
+{ RUN_STATE_GUEST_PANICKED, RUN_STATE_RUNNING },
{ RUN_STATE_GUEST_PANICKED, RUN_STATE_FINISH_MIGRATE },
-{
On Thu, Oct 31, 2013 at 06:10:36PM +0100, Paolo Bonzini wrote:
Il 31/10/2013 18:01, Michael S. Tsirkin ha scritto:
Yes, that's what my patch (posted the link before) does:
-{ RUN_STATE_GUEST_PANICKED, RUN_STATE_PAUSED },
+{ RUN_STATE_GUEST_PANICKED, RUN_STATE_RUNNING },
Il 31/10/2013 18:18, Michael S. Tsirkin ha scritto:
On Thu, Oct 31, 2013 at 06:10:36PM +0100, Paolo Bonzini wrote:
Il 31/10/2013 18:01, Michael S. Tsirkin ha scritto:
Yes, that's what my patch (posted the link before) does:
-{ RUN_STATE_GUEST_PANICKED, RUN_STATE_PAUSED },
+{
Ping!
Hu Tao hu...@cn.fujitsu.com writes:
Hi All,
I know it's been a long time since this thread. But qemu 1.7 is
releasing, do you have any consensus on this?
Thanks.
Hi All,
I know it's been a long time since this thread. But qemu 1.7 is
releasing, do you have any consensus on this?
Thanks.
On Thu, Aug 22, 2013 at 03:09:06PM -0500, Anthony Liguori wrote:
Paolo Bonzini pbonz...@redhat.com writes:
Also, a virtio watchdog device makes little sense, IMHO. PV makes sense
if emulation has insufficient performance, excessive CPU usage, or
excessive complexity. We already have both
On Thu, Aug 22, 2013 at 01:25:32PM -0500, Anthony Liguori wrote:
I believe that the watchdogs we emulate today are not supported by a
majority of guests.
BTW this is not true. The two watchdog devices are supported
by all Linux guests.
Windows guests do not support them, but Windows lacks[1]
On 08/27/2013 11:06 AM, Richard W.M. Jones wrote:
On Thu, Aug 22, 2013 at 03:09:06PM -0500, Anthony Liguori wrote:
Paolo Bonzini pbonz...@redhat.com writes:
Also, a virtio watchdog device makes little sense, IMHO. PV makes sense
if emulation has insufficient performance, excessive CPU usage,
On Tue, Aug 27, 2013 at 04:08:12PM +0300, Ronen Hod wrote:
So the right solution is to send a heart-beat to a management
application (using qemu-ga or whatever), and let it decide how to
handle it.
Agreed. The qemu watchdog lets you do this already. You can (using
the qemu monitor, or
On Tue, Aug 27, 2013 at 8:20 AM, Richard W.M. Jones rjo...@redhat.com wrote:
On Tue, Aug 27, 2013 at 04:08:12PM +0300, Ronen Hod wrote:
So the right solution is to send a heart-beat to a management
application (using qemu-ga or whatever), and let it decide how to
handle it.
This is
On Tue, Aug 27, 2013 at 08:26:53AM -0500, Anthony Liguori wrote:
That's why I think having a virtio-ilo makes sense. This is not a
solved problem today.
What's the scope of virtio-ilo? If it's anything like a real ILO it's
going to do a lot of not-very-related things, such as:
-
Il 22/08/2013 22:39, Anthony Liguori ha scritto:
On Thu, Aug 22, 2013 at 3:36 PM, Laszlo Ersek ler...@redhat.com wrote:
On 08/22/13 22:09, Anthony Liguori wrote:
The difference is that ACPI or platform devices in general are
unexpected to be added. By definition it means that the motherboard
The thread from yesterday has died off (perhaps also because of
my inappropriate answer to Michael, for which I apologize to him
and everyone). I took some time to discuss the libvirt requirements
further with Daniel Berrange and Eric Blake on IRC. If anyone is
interested, I can give logs. This
Paolo Bonzini pbonz...@redhat.com writes:
The thread from yesterday has died off (perhaps also because of
my inappropriate answer to Michael, for which I apologize to him
and everyone). I took some time to discuss the libvirt requirements
further with Daniel Berrange and Eric Blake on IRC.
On 08/22/13 18:10, Paolo Bonzini wrote:
The thread from yesterday has died off (perhaps also because of
my inappropriate answer to Michael, for which I apologize to him
and everyone). I took some time to discuss the libvirt requirements
further with Daniel Berrange and Eric Blake on IRC. If
On 08/22/13 18:44, Anthony Liguori wrote:
pvpanic has been a failure. It's a poorly designed device with even
worse semantics.
I disagree somewhat.
Requiring a separate ioport is not ideal, I admit. Configuration over
ACPI is good OTOH (it seems to put standards to good use anyway).
Noone
Laszlo Ersek ler...@redhat.com writes:
On 08/22/13 18:44, Anthony Liguori wrote:
pvpanic has been a failure. It's a poorly designed device with even
worse semantics.
I disagree somewhat.
Requiring a separate ioport is not ideal, I admit. Configuration over
ACPI is good OTOH (it seems to
Laszlo Ersek ler...@redhat.com writes:
On 08/22/13 18:10, Paolo Bonzini wrote:
The thread from yesterday has died off (perhaps also because of
my inappropriate answer to Michael, for which I apologize to him
and everyone). I took some time to discuss the libvirt requirements
further with
Il 22/08/2013 19:53, Laszlo Ersek ha scritto:
We should just introduce a simple watchdog device based on virtio and
call it a day. Then it's cross platform, solves the guest enumeration
problem, and libvirt can detect the presence of the new device.
If the guest doesn't initialize the
Il 22/08/2013 19:15, Laszlo Ersek ha scritto:
2) On all versions, on_crash will only work if the element is there.
I like this, because, if on_crash doesn't work without panic_notifier
*at all*, then we can just drop panic_notifier, and make on_crash mean
(on_crash panic_notifier) in the
On 08/22/13 21:19, Paolo Bonzini wrote:
Il 22/08/2013 19:15, Laszlo Ersek ha scritto:
2) On all versions, on_crash will only work if the element is there.
I like this, because, if on_crash doesn't work without panic_notifier
*at all*, then we can just drop panic_notifier, and make on_crash
On 22/08/13 20:33, Anthony Liguori wrote:
Laszlo Ersek ler...@redhat.com writes:
On 08/22/13 18:10, Paolo Bonzini wrote:
The thread from yesterday has died off (perhaps also because of
my inappropriate answer to Michael, for which I apologize to him
and everyone). I took some time to
Paolo Bonzini pbonz...@redhat.com writes:
Il 22/08/2013 19:53, Laszlo Ersek ha scritto:
We should just introduce a simple watchdog device based on virtio and
call it a day. Then it's cross platform, solves the guest enumeration
problem, and libvirt can detect the presence of the new
On 08/22/13 22:09, Anthony Liguori wrote:
The difference is that ACPI or platform devices in general are
unexpected to be added. By definition it means that the motherboard has
most likely been changed.
You could encounter a new ACPI artifact after simply re-flashing your MB
with an updated
On Thu, Aug 22, 2013 at 3:36 PM, Laszlo Ersek ler...@redhat.com wrote:
On 08/22/13 22:09, Anthony Liguori wrote:
The difference is that ACPI or platform devices in general are
unexpected to be added. By definition it means that the motherboard has
most likely been changed.
You could
On 22 August 2013 21:09, Anthony Liguori anth...@codemonkey.ws wrote:
Paolo Bonzini pbonz...@redhat.com writes:
Not just that. Panic notifiers are called in a substantially unknown
environment, with locks taken or interrupts already set up.
If you make the panic notify a config space write,
50 matches
Mail list logo
