From mboxrd@z Thu Jan  1 00:00:00 1970
From: "Liu, Jinsong" <jinsong.liu@intel.com>
Subject: RE: [PATCH] Fix hvm vcpu hotplug bug
Date: Fri, 20 Aug 2010 11:29:05 +0800
Message-ID: <BC00F5384FCFC9499AF06F92E8B78A9E16509730BB@shsmsx502.ccr.corp.intel.com>
References: <BC00F5384FCFC9499AF06F92E8B78A9E0B0007FD20@shsmsx502.ccr.corp.intel.com>
	<19554.43920.11785.97567@mariner.uk.xensource.com>
	<BC00F5384FCFC9499AF06F92E8B78A9E164C8CB703@shsmsx502.ccr.corp.intel.com>
	<19563.58860.249044.209893@mariner.uk.xensource.com>
	<BC00F5384FCFC9499AF06F92E8B78A9E165097298D@shsmsx502.ccr.corp.intel.com>
	<19565.17092.616097.195948@mariner.uk.xensource.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Return-path: <xen-devel-bounces@lists.xensource.com>
In-Reply-To: <19565.17092.616097.195948@mariner.uk.xensource.com>
Content-Language: en-US
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: "Jiang, Yunhong" <yunhong.jiang@intel.com>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Li, Xin" <xin.li@intel.com>, Keir Fraser <Keir.Fraser@eu.citrix.com>
List-Id: xen-devel@lists.xenproject.org

Ian Jackson wrote:
> Liu, Jinsong writes ("RE: [Xen-devel] [PATCH] Fix hvm vcpu hotplug
> bug"):=20
>> Per my understanding, sci-gpe logic is like
>> [diagram]
>>=20
>> Currently qemu-xen didn't have 'gep event x OR gpe event y --> sci'
>> logic, it should add this logic level.
>=20
> Yes, thanks, I'd understood that.  But:
>=20
>> To clear the interrupt:
>> 1). gpe_sts x & gpe_en x --> low gpe event x
>=20
> I think you mean "gpe_sts goes low" ?  Since your diagram is in terms
> of levels and I guess "sts" is the actual interrupt source, and
> "sts_en" is the interrupt enable flag.

Yes.

>=20
> So in real hardware, what makes gpe_sts go low ?
>=20
> Ian.

ospm will do. Its sequence is (i.e. linux 2.6.32, ospm dispatch control met=
hod case)
1). clear pge_en x by writing '0' to the bit;
2). asynchronic call control method;
3). clear gpe_sts x by writing '1' to the bit;
4). re-enable gpe_en x by writing '1' to the bit;


Thanks,
Jinsong=