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

Re: [Xen-devel] Re: A wrong assert in get_ioreq()?


  • To: "Keir Fraser" <keir@xxxxxxxxxxxxx>
  • From: "Paul Samon" <paul.samon@xxxxxxxxx>
  • Date: Thu, 5 Jul 2007 09:08:44 +0800
  • Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
  • Delivery-date: Wed, 04 Jul 2007 18:06:34 -0700
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=FxOMTbfjfsqA6SZsvLQ2KViMC/z+VVtLlou9BQvkYYvCucjnSW/smpKmU3hDjyLaFT5vYlIfS+NPuxsWvHziRTGc0cbjgG7UNsnwy8efXUG44C1GGS96N6qgzRAFLDPdPrcypdpE3O5ME9xLhe4FBTxpKlfLnOvBXk+O5LlFa7g=
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>

Yes, the lock is necessary (for hvm_vcpu_initialise()), but my question is: in the ASSERT of get_ioreq(), we shouldn't check if we have got the lock, and we don't have the lock in it (if I'm wrong, please point out where we get the lock), that is, in get_ioreq(), I think  spin_is_locked(&d-> arch.hvm_domain.ioreq.lock) always returns false.
 
-- Paul S.

 
On 7/4/07, Keir Fraser <keir@xxxxxxxxxxxxx> wrote:
The lock is taken in, for example, hvm_vcpu_initialise(), which calles get_ioreq(v) with v!=current. So the assertion is correct as-is.

 -- Keir
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

 


Rackspace

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