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

Re: [Xen-devel] RE: Biweekly VMX status report. Xen: #20255 & Xen0:#b6ba0...



On 30/09/2009 10:08, "Tim Deegan" <Tim.Deegan@xxxxxxxxxxxxx> wrote:

>> So, we could 'fix' by giving ept_sync_domain() its own lock, but my
>> suspicion would be that any paths through the p2m code that are not holding
>> the p2m_lock probably need to be fixed. Adjusting p2m entries without the
>> lock held sounds racey to me.
> 
> The {set,clear}_mmio_p2m_entry functions that were added for Vt-D MMIO
> passthrough don't seem to do any locking.  (Actually, I don't see why
> the mmio passthrough needs its own interface to the p2m at all.)
> Untested but obvious fix attached.

I'd like Intel to test this before checkin, mainly to make sure it is
complete enough. I have a feeling the vmx_set_uc_mode() function may also
enter the p2m code without the hindrance of locking.

 -- 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®.