[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Xen-devel] [PATCH] bug-fixes to hvc-xen driver in v3.4 (and earlier).

Three of the patches could be squashed in one, but it makes more sense
to review them as three. These patches fix the case of an PVHVM
guest not being able to resume propely b/c of hitting:

 142         BUG_ON(info->type != IRQT_UNBOUND && info->type != type);

(in events.c) and also adds a WARN to catch situations like these.

The reason for this is that the Xen python toolstack does not
setup HVM_PARAM_CONSOLE_EVTCHN parameter, so we would use the
default value (0).. and ended up using the same IRQ line as the
xen-platform-pci driver. Huh? Note: the 'xl' toolstack _does_
set it.

The reason is that the when the xen-platform-pci starts, it requests
an PIRQ, and the info structure in events.c is filled as such:

 info->type = IRQT_PIRQ
 info->events = 0
 info->irq = 28
 evtchn_to_irq[0] = 28

And when xen_hvc_init is called during bootup, it figures out the
event from HVM_PARAM_CONSOLE_EVTCHN as zero, and plugs them in:

 532                 info->irq = bind_evtchn_to_irq(info->evtchn);

getting IRQ 28 as bind_evtchn_to_irq does a quick lookup:

 818         irq = evtchn_to_irq[evtchn];

and gives an already used IRQ line.

When we suspend the guest (xm save), then try to resume, we call
xen_console_resume, which does:

301         if (info != NULL && info->irq)
302                 rebind_evtchn_irq(info->evtchn, info->irq);

and that triggers the BUG_ON mentioned above (b/c the type
we want is IRQT_EVTCHN and the type info->type is IRQT_PIRQ).

 drivers/tty/hvc/hvc_xen.c |   24 +++++++++++-------------
 drivers/xen/events.c      |   11 +++++++++--
 2 files changed, 20 insertions(+), 15 deletions(-)

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.