Re: [Xen-devel] lock in vhpet

["Zhang, Yang Z" <yang.z.zhang@xxxxxxxxx>]

> -----Original Message-----
> From: Andres Lagar-Cavilla [mailto:andres@xxxxxxxxxxxxxxxx]
> Sent: Friday, April 27, 2012 8:52 AM
> To: Zhang, Yang Z
> Cc: Tim Deegan; Keir Fraser; xen-devel@xxxxxxxxxxxxxxxxxxx; olaf@xxxxxxxxx;
> George.Dunlap@xxxxxxxxxxxxx
> Subject: RE: [Xen-devel] lock in vhpet
> 
> >> -----Original Message-----
> >> From: Tim Deegan [mailto:tim@xxxxxxx]
> >> Sent: Friday, April 27, 2012 5:26 AM
> >> To: Zhang, Yang Z
> >> Cc: andres@xxxxxxxxxxxxxxxx; Keir Fraser;
> >> xen-devel@xxxxxxxxxxxxxxxxxxx
> >> Subject: Re: [Xen-devel] lock in vhpet
> >>
> >> At 02:36 +0000 on 25 Apr (1335321409), Zhang, Yang Z wrote:
> >> > > > But actually, the first cs introduced this issue is 24770. When
> >> > > > win8 booting and if hpet is enabled, it will use hpet as the
> >> > > > time source and there have lots of hpet access and EPT
> >> > > > violation. In EPT violation handler, it call get_gfn_type_access to 
> >> > > > get
> the mfn.
> >> > > > The cs 24770 introduces the gfn_lock for p2m lookups, and then
> >> > > > the
> >> issue
> >> happens.
> >> > > > After I removed the gfn_lock, the issue goes. But in latest
> >> > > > xen, even I remove this lock, it still shows high cpu utilization.
> >> > >
> >> > > It would seem then that even the briefest lock-protected critical
> >> > > section would cause this? In the mmio case, the p2m lock taken in
> >> > > the hap fault handler is held during the actual lookup, and for a
> >> > > couple of branch instructions afterwards.
> >> > >
> >> > > In latest Xen, with lock removed for get_gfn, on which lock is
> >> > > time
> >> spent?
> >> > Still the p2m_lock.
> >>
> >> Can you please try the attached patch?  I think you'll need this one
> >> plus the ones that take the locks out of the hpet code.
> >>
> >> This patch makes the p2m lock into an rwlock and adjusts a number of
> >> the paths that don't update the p2m so they only take the read lock.
> >> It's a bit rough but I can boot 16-way win7 guest with it.
> 
> That is great news.
> 
> Tim, thanks for the amazing work. I'm poring over the patch presently, and 
> will
> shoot at it with everything I've got testing-wise.
> 
> I'm taking the liberty of pulling in Olaf (paging) and George (PoD) as the
> changeset affects those subsystems.

But win8 guest shows BSOD with 32 VCPUs. :(
The reason of BSOD is : SYSTEM_THREAD_EXCEPTION_NOT_HANDLED (ACPI.sys)


best regards
yang


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