All of lore.kernel.org
 help / color / mirror / Atom feed
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
To: David Vrabel <david.vrabel@citrix.com>, konrad.wilk@oracle.com
Cc: xen-devel@lists.xenproject.org, annie.li@oracle.com,
	linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH 1/4] xen/events: Clear cpu_evtchn_mask before resuming
Date: Tue, 28 Apr 2015 14:29:57 -0400	[thread overview]
Message-ID: <553FD1A5.60409@oracle.com> (raw)
In-Reply-To: <553FB540.4040707@citrix.com>

On 04/28/2015 12:28 PM, David Vrabel wrote:
> On 28/04/15 16:52, Boris Ostrovsky wrote:
>> When a guest is resumed, the hypervisor may change event channel
>> assignments. If this happens and the guest uses 2-level events it
>> is possible for the interrupt to be claimed by wrong VCPU since
>> cpu_evtchn_mask bits may be stale. This can happen even though
>> evtchn_2l_bind_to_cpu() attempts to clear old bits: irq_info that
>> is passed in is not necessarily the original one (from pre-migration
>> times) but instead is freshly allocated during resume and so any
>> information about which CPU the channel was bound to is lost.
>>
>> Thus we should clear the mask during resume.
>>
>> We also need to make sure that bits for xenstore and console channels
>> are set when these two subsystems are resumed. While rebind_evtchn_irq()
>> (which is invoked for both of them on a resume) calls irq_set_affinity(),
>> the latter will in fact postpone setting affinity until handling the
>> interrupt. But because cpu_evtchn_mask will have bits for these two cleared
>> we won't be able to take the interrupt.
>>
>> Setting IRQ_MOVE_PCNTXT flag for the two irqs avoids this problem by
>> allowing to set affinity immediately, which is safe for event-channel-based
>> interrupts.
> [...]
>> --- a/drivers/tty/hvc/hvc_xen.c
>> +++ b/drivers/tty/hvc/hvc_xen.c
>> @@ -533,6 +533,7 @@ static int __init xen_hvc_init(void)
>>   
>>   		info = vtermno_to_xencons(HVC_COOKIE);
>>   		info->irq = bind_evtchn_to_irq(info->evtchn);
>> +		irq_set_status_flags(info->irq, IRQ_MOVE_PCNTXT);
>>   	}
>>   	if (info->irq < 0)
>>   		info->irq = 0; /* NO_IRQ */
>> diff --git a/drivers/xen/events/events_2l.c b/drivers/xen/events/events_2l.c
>> index 5db43fc..7dd4631 100644
>> --- a/drivers/xen/events/events_2l.c
>> +++ b/drivers/xen/events/events_2l.c
>> @@ -345,6 +345,15 @@ irqreturn_t xen_debug_interrupt(int irq, void *dev_id)
>>   	return IRQ_HANDLED;
>>   }
>>   
>> +static void evtchn_2l_resume(void)
>> +{
>> +	int i;
>> +
>> +	for_each_online_cpu(i)
>> +		memset(per_cpu(cpu_evtchn_mask, i), 0, sizeof(xen_ulong_t) *
>> +				EVTCHN_2L_NR_CHANNELS/BITS_PER_EVTCHN_WORD);
>> +}
>> +
>>   static const struct evtchn_ops evtchn_ops_2l = {
>>   	.max_channels      = evtchn_2l_max_channels,
>>   	.nr_channels       = evtchn_2l_max_channels,
>> @@ -356,6 +365,7 @@ static const struct evtchn_ops evtchn_ops_2l = {
>>   	.mask              = evtchn_2l_mask,
>>   	.unmask            = evtchn_2l_unmask,
>>   	.handle_events     = evtchn_2l_handle_events,
>> +	.resume	           = evtchn_2l_resume,
>>   };
>>   
>>   void __init xen_evtchn_2l_init(void)
>> diff --git a/drivers/xen/xenbus/xenbus_comms.c b/drivers/xen/xenbus/xenbus_comms.c
>> index fdb0f33..30203d1 100644
>> --- a/drivers/xen/xenbus/xenbus_comms.c
>> +++ b/drivers/xen/xenbus/xenbus_comms.c
>> @@ -231,6 +231,7 @@ int xb_init_comms(void)
>>   		}
>>   
>>   		xenbus_irq = err;
>> +		irq_set_status_flags(xenbus_irq, IRQ_MOVE_PCNTXT);
> IRQ_MOVE_PCNTXT means "Interrupt can be migrated from process context"
> which doesn't really sound relevant to me here?
>
> Thomas Glexnier is really not happy with mis-use of IRQ APIs.

Yes, this is somewhat expanding definition of IRQ_MOVE_PCNTXT but then 
there are other devices that do the same (HPET, for one).

>
>  From the commit log the evtchn_2l_resume() fucntion that's added sounds
> like it fixes the problem on its own?

It in fact makes this problem worse since now that cpu_evtchn_mask is 
cleared during resume we cannot process the interrupt anymore in 
evtchn_2l_handle_events(): irqs have to be bound to a cpu in order for 
an interrupt to be processed.

We already have this issue even without clearing the mask if, say, 
xenstore channel changes or if it gets bound to cpu other than 0 before 
suspend. It's just that we rarely (if ever) see this happen.

We can explicitly call events_base.c:set_affinity_irq() from 
rebind_evtchn_irq() after irq_set_affinity() if we want to avoid using 
IRQ_MOVE_PCNTXT flag but that will also looks kind of strange.


-boris


  reply	other threads:[~2015-04-28 18:32 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-28 15:52 [PATCH 0/4] A few event channel-related fixes Boris Ostrovsky
2015-04-28 15:52 ` [PATCH 1/4] xen/events: Clear cpu_evtchn_mask before resuming Boris Ostrovsky
2015-04-28 16:28   ` David Vrabel
2015-04-28 16:28   ` [Xen-devel] " David Vrabel
2015-04-28 18:29     ` Boris Ostrovsky [this message]
2015-04-29 16:32       ` David Vrabel
2015-04-29 16:54         ` Boris Ostrovsky
2015-04-29 16:54         ` [Xen-devel] " Boris Ostrovsky
2015-04-29 17:59           ` David Vrabel
2015-04-29 17:59           ` [Xen-devel] " David Vrabel
2015-04-29 18:26             ` Boris Ostrovsky
2015-04-29 18:26             ` [Xen-devel] " Boris Ostrovsky
2015-04-29 16:32       ` David Vrabel
2015-04-28 18:29     ` Boris Ostrovsky
2015-04-28 15:52 ` Boris Ostrovsky
2015-04-28 15:52 ` [PATCH 2/4] xen/xenbus: Update xenbus event channel on resume Boris Ostrovsky
2015-04-28 15:52 ` Boris Ostrovsky
2015-04-28 16:32   ` [Xen-devel] " David Vrabel
2015-04-28 16:32   ` David Vrabel
2015-04-28 15:52 ` [PATCH 3/4] xen/console: Update console " Boris Ostrovsky
2015-04-28 15:52 ` Boris Ostrovsky
2015-04-28 16:33   ` David Vrabel
2015-04-28 16:33   ` [Xen-devel] " David Vrabel
2015-04-28 15:52 ` [PATCH 4/4] xen/events: Set irq_info->evtchn before binding the channel to CPU in __startup_pirq() Boris Ostrovsky
2015-04-28 15:52 ` Boris Ostrovsky
2015-04-28 16:34   ` David Vrabel
2015-04-28 16:34   ` [Xen-devel] " David Vrabel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=553FD1A5.60409@oracle.com \
    --to=boris.ostrovsky@oracle.com \
    --cc=annie.li@oracle.com \
    --cc=david.vrabel@citrix.com \
    --cc=konrad.wilk@oracle.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.