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

Re: [Xen-devel] [PATCH v2] xen/pvh: use a custom IO bitmap for PVH hardware domains



El 29/04/15 a les 15.44, Andrew Cooper ha escrit:
> On 29/04/15 12:05, Roger Pau Monnà wrote:
>> El 29/04/15 a les 2.38, Andrew Cooper ha escrit:
>>>
>>>> +
>>>> +    if ( is_pvh_domain(d) )
>>>> +    {
>>>> +        for ( i = 0; i < 0x10000; i++ )
>>>> +            /* NB: 0xcf8 has special treatment so we need to trap
>>>> it. */
>>> Why?  (and irrespective of my question, cf8 expects a 4 byte access, and
>>> surely cfc would need similar treatment?)
>> 0xcfc-0xcff is already added to ioports_deny_access in construct_dom0. I
>> have no idea why 0xcf8 needs this special treatment, but Linux PVH fails
>> to enumerate PCI devices if Xen is not set to trap accesses to 0xcf8
>> (FreeBSD seems to be fine, either with 0xcf8 trapped or not).
> 
> Sorry for the noise on v3.  I replied before seeing this reply.
> 
> cf8/cfc are used as an indirect pair for access to PCI config space. 
> They must be strictly be controlled by a single entity in a system, or
> dom0 and Xen can race and interfere with each other.  As a result,
> permissions for cf8/cfc must never be set in the IO bitmap.

Ack, that's why I decided to add 0xcf8-0xcfa to the list of blocked
ports in v3 after looking at guest_io_write/admin_io_ok.

> There are other indirect pairs which need similar treatment.

Yes, I see there is at least another similar case related to RTC. I will
look into cleaning admin_io_ok and guest_io_{write/read} in next version.

Thanks, Roger.

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