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

Re: [Xen-devel] lock in vhpet



There have no problem with this patch, it works well. But it cannot fix the 
win8 issue. It seems there has some other issues with hpet. I will look into it.
Thanks for your quick patch.

best regards
yang


> -----Original Message-----
> From: Keir Fraser [mailto:keir.xen@xxxxxxxxx] On Behalf Of Keir Fraser
> Sent: Wednesday, April 18, 2012 5:31 PM
> To: Zhang, Yang Z; xen-devel@xxxxxxxxxxxxxxxxxxx
> Subject: Re: lock in vhpet
> 
> On 18/04/2012 10:14, "Keir Fraser" <keir@xxxxxxx> wrote:
> 
> > On 18/04/2012 09:29, "Keir Fraser" <keir@xxxxxxx> wrote:
> >
> >> On 18/04/2012 08:55, "Zhang, Yang Z" <yang.z.zhang@xxxxxxxxx> wrote:
> >>
> >>>> If the HPET accesses are atomic on bare metal, we have to maintain
> >>>> that, even if some guests have extra locking themselves. Also, in
> >>>> some cases Xen needs locking to correctly maintain its own internal
> >>>> state regardless of what an
> >>>> (untrusted) guest might do. So we cannot just get rid of the vhpet
> >>>> lock everywhere. It's definitely not correct to do so. Optimising
> >>>> the hpet read path however, sounds okay. I agree the lock may not
> >>>> be needed on that specific path.
> >>>
> >>> You are right.
> >>> For this case, since the main access of hpet is to read the main
> >>> counter, so I think the rwlock is a better choice.
> >>
> >> I'll see if I can make a patch...
> >
> > Please try the attached patch (build tested only).
> 
> Actually try this updated one. :-)
> 
> >  -- Keir
> >
> >>  -- Keir
> >>
> >>
> >


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


 


Rackspace

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