Re: [Xen-devel] Other PCI devices to mark mark as read-only for dom0

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 22/06/12 10:43, Jan Beulich wrote:
>>>> On 22.06.12 at 11:04, Andrew Cooper <andrew.cooper3@xxxxxxxxxx> wrote:
>> Following Jan's infrastructure to mark certain PCI devices as read only,
>> I think it wise to now consider what other PCI devices should really be
>> read only to dom0.
>>
>> My preliminary thoughts include:
>>
>> * PCI serial devices which Xen is configured to use
> But only if they're single-function.

Why only single function?  Should Xen not turn all the functions it is
using to read-only ?

>
>> * Chipset devices (AMD IOMMU covered by previous patch)
>> * Cpu information
> What are you thinking of here specifically.

See attached lspci from a new sandybridge machine we have gained.  Quite
a lot of that looks rather dangerous for dom0 to play around with.


>
>> Are there any others I have overlooked, or reasons that dom0 should be
>> able to write to these areas?
>>
>> On a related note, should there be a mechanism for dom0 to determine
>> which PCI configuration areas are read only to itself?
> Perhaps, but that's not the only thing to deal with here. As
> said previously, when we want to add devices with active BARs
> here (luckily Wei confirmed that AMD IOMMUs have none),
> Dom0 trying to re-configure them would get us into problems.
> The issue exists today, but could become worse when we
> disallow the updates (as that could lead to two devices sharing
> resources they shouldn't share, whereas today a device in use
> by Xen and getting re-assigned its resources would merely stop
> working).
>
> Jan
>

It is certainly not an easy problem, and perhaps I am needlessly
complicating the issue.

It occurs that we have 3 possible directions to fix this issue.

1) Continue the current method of fixing things up after they break,
which can cause a hassle for a user encountering the issue.
2) Mark as RO and provide an explicit hypercall interface to remap
BARs.  I don't know how well this would go with upstream Linux.
3) Extend current infrastructure to be able to tell when a write is
affecting the BARs and permit them.  This seems like the best option
going forward, but might be quite hard to implement.

I guess the real question is whether we should continue reactively
fixing problems, or start protectively fixing the root cause.  My gut
feeling is that we are going to start seeing more and more devices on
the PCI bus which Xen should be using, rather than dom0.

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com

Attachment: sandybridge-lspci-tv.log
Description: Text Data

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