All of lore.kernel.org
 help / color / mirror / Atom feed
From: Julien Grall <julien@xen.org>
To: "Bertrand Marquis" <Bertrand.Marquis@arm.com>,
	"Roger Pau Monné" <roger@xen.org>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Wei Liu <wl@xen.org>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	George Dunlap <george.dunlap@citrix.com>,
	Jan Beulich <jbeulich@suse.com>,
	xen-devel <xen-devel@lists.xenproject.org>, nd <nd@arm.com>,
	Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>
Subject: Re: [RFC PATCH 1/1] xen: Use a global mapping for runstate
Date: Thu, 28 May 2020 20:12:59 +0100	[thread overview]
Message-ID: <de72ffe2-34a9-0b65-8d66-3f1322258d0c@xen.org> (raw)
In-Reply-To: <B0CBD25E-49D8-4AE5-B424-83E9A05FBF58@arm.com>

Hi,

On 28/05/2020 18:19, Bertrand Marquis wrote:
>>> +
>>> +    return 0;
>>> +}
>>> +
>>> int domain_kill(struct domain *d)
>>> {
>>>      int rc = 0;
>>> @@ -727,7 +788,10 @@ int domain_kill(struct domain *d)
>>>          if ( cpupool_move_domain(d, cpupool0) )
>>>              return -ERESTART;
>>>          for_each_vcpu ( d, v )
>>> +        {
>>> +            unmap_runstate_area(v, 0);
>>
>> Why is it not appropriate here to hold the lock? It might not be
>> technically needed, but still should work?
> 
> In a killing scenario you might stop a core while it was rescheduling.
> Couldn’t a core be killed using a cross core interrupt ?

You can't stop a vCPU in the middle of the context switch. The vCPU can 
only be scheduled out at specific point in Xen.

> If this is the case then I would need to do masked interrupt locking sections to prevent that case ?

At the beginning of the function domain_kill() the domain will be paused 
(see domain_pause()). After this steps none of the vCPUs will be running 
or be scheduled.

You should technically use the lock everywhere to avoid static analyzer 
throwing a warning because you access variable with and without the 
lock. A comment would at least be useful in the code if we go ahead with 
this.

As an aside, I think you want the lock to always disable the interrupts 
otherwise check_lock() (this can be enabled with CONFIG_DEBUG_LOCKS only 
on x86 though) will shout at you because your lock can be taken in both 
IRQ-safe and IRQ-unsafe context.

Cheers,

-- 
Julien Grall


  reply	other threads:[~2020-05-28 19:13 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-28 15:25 [RFC PATCH 0/1] Runstate error with KPTI Bertrand Marquis
2020-05-28 15:25 ` [RFC PATCH 1/1] xen: Use a global mapping for runstate Bertrand Marquis
2020-05-28 16:53   ` Roger Pau Monné
2020-05-28 17:19     ` Bertrand Marquis
2020-05-28 19:12       ` Julien Grall [this message]
2020-05-29  8:15         ` Bertrand Marquis
2020-05-28 18:54   ` Julien Grall
2020-05-29  7:19     ` Roger Pau Monné
2020-05-29  8:24       ` Bertrand Marquis
2020-05-29  7:35     ` Jan Beulich
2020-05-29  8:32       ` Bertrand Marquis
2020-05-29  8:37         ` Jan Beulich
2020-05-29 13:26         ` Roger Pau Monné
2020-05-29 13:37           ` Julien Grall
2020-05-29 14:36             ` Roger Pau Monné
2020-05-29 10:59       ` Julien Grall
2020-05-29 13:09         ` Roger Pau Monné
2020-05-29  8:13     ` Bertrand Marquis
2020-05-29  8:45       ` Jan Beulich
2020-05-29  9:18         ` Bertrand Marquis
2020-05-29  9:27           ` Roger Pau Monné
2020-05-29 13:53             ` Bertrand Marquis
2020-05-29  9:31           ` Jan Beulich
2020-05-29 10:52           ` Julien Grall
2020-05-29  9:43       ` Julien Grall
2020-05-29 14:02         ` Bertrand Marquis
2020-05-29 14:15           ` Julien Grall
2020-05-29 14:21             ` Bertrand Marquis
2020-05-29  9:49       ` Hongyan Xia

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=de72ffe2-34a9-0b65-8d66-3f1322258d0c@xen.org \
    --to=julien@xen.org \
    --cc=Bertrand.Marquis@arm.com \
    --cc=Volodymyr_Babchuk@epam.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=george.dunlap@citrix.com \
    --cc=ian.jackson@eu.citrix.com \
    --cc=jbeulich@suse.com \
    --cc=nd@arm.com \
    --cc=roger@xen.org \
    --cc=sstabellini@kernel.org \
    --cc=wl@xen.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.