From mboxrd@z Thu Jan  1 00:00:00 1970
From: Dario Faggioli <dario.faggioli@citrix.com>
Subject: Re: [PATCH 0/3] VMX: Properly handle pi descriptor and
 per-cpu blocking list
Date: Tue, 24 May 2016 16:46:34 +0200
Message-ID: <1464101194.21930.115.camel@citrix.com>
References: <1463734431-22353-1-git-send-email-feng.wu@intel.com>
 <573F02B102000078000ED304@prv-mh.provo.novell.com>
 <E959C4978C3B6342920538CF579893F0196E1F5D@SHSMSX104.ccr.corp.intel.com>
 <5742D6BB02000078000EDA57@prv-mh.provo.novell.com>
 <E959C4978C3B6342920538CF579893F0196EB419@SHSMSX103.ccr.corp.intel.com>
 <5742E0BE02000078000EDABD@prv-mh.provo.novell.com>
 <1464007152.21930.55.camel@citrix.com>
 <E959C4978C3B6342920538CF579893F0196ED481@SHSMSX103.ccr.corp.intel.com>
 <E959C4978C3B6342920538CF579893F0196ED828@SHSMSX103.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="===============3655357348831373942=="
Return-path: <xen-devel-bounces@lists.xen.org>
In-Reply-To: <E959C4978C3B6342920538CF579893F0196ED828@SHSMSX103.ccr.corp.intel.com>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xen.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xen.org>
To: "Wu, Feng" <feng.wu@intel.com>, Jan Beulich <JBeulich@suse.com>
Cc: "Tian, Kevin" <kevin.tian@intel.com>, "keir@xen.org" <keir@xen.org>, "george.dunlap@eu.citrix.com" <george.dunlap@eu.citrix.com>, "andrew.cooper3@citrix.com" <andrew.cooper3@citrix.com>, "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
List-Id: xen-devel@lists.xenproject.org

--===============3655357348831373942==
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="=-e4kQ7LPzAIK3/1L58z1L"

--=-e4kQ7LPzAIK3/1L58z1L
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, 2016-05-24 at 13:33 +0000, Wu, Feng wrote:
> > From: Wu, Feng
> > > From: Dario Faggioli [mailto:dario.faggioli@citrix.com]
> > >=C2=A0
> > > If a
> > > vCPU is blocker, there is nothing to do, and in fact, nothing
> > > happens
> > > (as vcpu_sleep_nosync() and vcpu_wake() are NOP in that case).
> > What do you mean by saying ' vcpu_sleep_nosync() and vcpu_wake()
> > are NOP '?
>
> I think I understand what you meant above now.
>=20
Right. In any case, see the email I've just sent, with a detailed
breakdown of the situation and of what actually happens.

> Do you think the following idea makes sense?
>=20
> When a pCPU is unplugged, we can just remove the vcpus on the
> associated per-cpu blocking list, then we can choose another online
> cpu, set the right NDST value, and put the vCPU the new per-cpu list?
>
Well, this does make sense to me, but the point is how you do that. I
mean, how do you get to execute some PI adjustment code, from cpu-
teardown code?

Right now, for what seemed to be necessary until now, we have the
arch_vcpu_block(). Do we need more? If yes where?

=46rom looking only at schedule.c, we already have arch_move_irqs(), can
we take advantage of it?

Regards,
Dario
--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


--=-e4kQ7LPzAIK3/1L58z1L
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAABCAAGBQJXRGlLAAoJEBZCeImluHPuh7MP/RaQVDLiW3mIcuGocc8M3yuR
/Qi6TsRo2Zswge0OlgH7Facqys8uNb7rbhrJWymdKGbjh+hJqGkbT+0hMDQs0VY0
wvsrzW1lVIxfEr5WZnUInMFWtDEaj8v70XjWiORxI30T1fu1pLdZaBobrPyjnAR2
VrmRGzWVXcKXdOapcVvaOnuiNKq4ByeSqVtvaVigJ1D6L+dATYVmMeFbIYUDY5au
G5ABev11+yXnEyFhr7ZykVZexU/E9K4OedxQiMFPBq4H/o0Prsb7XyFDBnc3hZKT
Y9fCISLiFtMmVGPYnX9jpN2vE5WiEUzjAmltfE/M5+cr4PqOhclr5JSSwb5/P3q1
fKZG4qC0oeX/P6LEts7JPftEr+D2ZNJKskd0Q9190keO4K7BFxBtbY1szmR0JLqd
5pGZacsekHQu5oMv0vCXwGtZZrwwrvyvw/Ct+88lXzdtCcfusf8YR8b5Jxk7AUIO
0Xn3cia/EwNeit5sTD4rb7u1LXsL0+V5MmowMtiBvqTpTcLFj7VfgShtnc7FdqQR
mCH+ZHmscTYmdypXMGuzv1mhlHQTo+0fYxYcgt0b41ZppeH0VHr9xnlT9dXswyHc
XvXHXPqa9ailWncoY3ka8gV+B4D8DZdwS6fu46Yws4dO1A4eUApLEdffUQ73PaT+
dIwTXAfUZ+g3dstdfK4Q
=Z/rU
-----END PGP SIGNATURE-----

--=-e4kQ7LPzAIK3/1L58z1L--


--===============3655357348831373942==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Disposition: inline

X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVs
IG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9y
Zy94ZW4tZGV2ZWwK

--===============3655357348831373942==--