xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
To: Meng Xu <xumengpanda@gmail.com>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Subject: Re: Question about sharing spinlock_t among VMs in Xen
Date: Mon, 13 Jun 2016 17:17:12 -0400	[thread overview]
Message-ID: <575F22D8.2010107@oracle.com> (raw)
In-Reply-To: <CAENZ-+nirrxqhSvQQ+MiD=xMy=g3kLEActr4+epANQQEqUni9w@mail.gmail.com>

On 06/13/2016 04:46 PM, Meng Xu wrote:
> On Mon, Jun 13, 2016 at 2:28 PM, Boris Ostrovsky
> <boris.ostrovsky@oracle.com> wrote:
>> On 06/13/2016 01:43 PM, Meng Xu wrote:
>>> Hi,
>>>
>>> I have a quick question about using the Linux spin_lock() in Xen
>>> environment to protect some host-wide shared (memory) resource among
>>> VMs.
>>>
>>> *** The question is as follows ***
>>> Suppose I have two Linux VMs sharing the same spinlock_t lock (through
>>> the sharing memory) on the same host. Suppose we have one process in
>>> each VM. Each process uses the linux function spin_lock(&lock) [1] to
>>> grab & release the lock.
>>> Will these two processes in the two VMs have race on the shared lock?
>> You can't do this: depending on which Linux version you use you will
>> find that kernel uses ticketlocks or qlocks locks which keep track of
>> who is holding the lock (obviously this information is internal to VM).
> Yes, we are using the ticketlocks. We expose this information to other
> VMs as well. That's why I'm guessing some data can be corrupted due to
> races among VMs that share the same ticketlock information.

I don't think it's a race that is the problem. It's that when holder
releases a lock it wants to kick the waiter. It can't kick CPU in
another guest and most likely kicks CPU from its own guest (because
that's where it assumes the waiter is).


-boris



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

  reply	other threads:[~2016-06-13 21:17 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-13 17:43 Question about sharing spinlock_t among VMs in Xen Meng Xu
2016-06-13 18:28 ` Boris Ostrovsky
2016-06-13 20:46   ` Meng Xu
2016-06-13 21:17     ` Boris Ostrovsky [this message]
2016-06-14  1:50       ` Meng Xu
2016-06-13 22:54 ` Andrew Cooper
2016-06-14  2:13   ` Meng Xu
2016-06-14 16:01     ` Andrew Cooper
2016-06-15 15:28       ` Meng Xu

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=575F22D8.2010107@oracle.com \
    --to=boris.ostrovsky@oracle.com \
    --cc=xen-devel@lists.xenproject.org \
    --cc=xumengpanda@gmail.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).