Xen devel - Jun 2012 - Other PCI devices to mark mark as read-only for dom0

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
* Chipset devices (AMD IOMMU covered by previous patch)
* Cpu information

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?

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

Friday, June 22, 2012, 11:04:24 AM, you 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
> * Chipset devices (AMD IOMMU covered by previous patch)
> * Cpu information
> Are there any others I have overlooked, or reasons that dom0 should be
> able to write to these areas?
Make devices specified for pci passthrough be really hidden and
"owned" by the hyperviso ?
     - which can in turn delegate ownership to a domain (including dom0)
     - If a domain is destroyed, the hypervisor resets the device and becomes
the owner again instead of dom0 ?

> On a related note, should there be a mechanism for dom0 to determine
> which PCI configuration areas are read only to itself?



-- 
Best regards,
 Sander                            mailto:linux@eikelenboom.it

>>> On 22.06.12 at 11:04, Andrew Cooper
<andrew.cooper3@citrix.com> 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.
> * Chipset devices (AMD IOMMU covered by previous patch)
> * Cpu information
What are you thinking of here specifically.
> 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

On 22/06/12 10:43, Jan Beulich wrote:
>>>> On 22.06.12 at 11:04, Andrew Cooper
<andrew.cooper3@citrix.com> 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





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

On 22/06/12 10:24, Sander Eikelenboom wrote:
>
>> Are there any others I have overlooked, or reasons that dom0 should be
>> able to write to these areas?
> Make devices specified for pci passthrough be really hidden and
"owned" by the hyperviso ?
>      - which can in turn delegate ownership to a domain (including dom0)
>      - If a domain is destroyed, the hypervisor resets the device and
becomes the owner again instead of dom0 ?
Why?

Currently this is covered by unbinding the dom0 driver and binding
pciback to the device.  Well behaved device drivers will not cause problems.

This way, the toolstack has control of which domains own what.

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

>>> On 22.06.12 at 12:08, Andrew Cooper
<andrew.cooper3@citrix.com> wrote:
> On 22/06/12 10:43, Jan Beulich wrote:
>>>>> On 22.06.12 at 11:04, Andrew Cooper
<andrew.cooper3@citrix.com> 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 ?
Because, just like for normal, non-PCI based serial ones, ports
that Xen doesn''t use should remain usable by Dom0. For
example, I have a PCI card with two serial and one parallel
ports, so with Xen using one serial port for itself, there''s no
reason not to allow Dom0 to use the other or the parallel one.
>>> * 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.
But that can''t be easily qualified into some rule, the more that
some of these - iirc - are needed e.g. by the EDAC drivers.

Jan

>>> On 22.06.12 at 12:08, Andrew Cooper
<andrew.cooper3@citrix.com> wrote:
> On 22/06/12 10:43, Jan Beulich wrote:
>> 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).
> 
> 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.
And what would the hypercall do? You don''t expect it to fix up
all the uses of the old address(es) to now use the new one(s),
do you? Leaving aside the difficulty in getting this right, in some
cases this might not even be possible in a seamless manner.
> 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.
Doing the mechanical trap-and-emulate part of this shouldn''t
be that hard, namely on top of that other patch I''m about to
commit.

But the thing is that this has the same problems as the hypercall
one above.
> I guess the real question is whether we should continue reactively
> fixing problems, or start protectively fixing the root cause.
I agree with this position from a theoretical standpoint.
>  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.
That would be bad - surfacing arbitrary devices on the PCI bus
is - in my opinion - rather questionable a design (which is also
why I consider this aspect of the AMD IOMMUs badly designed).

Jan

On 22/06/12 12:23, Jan Beulich wrote:
>>>> On 22.06.12 at 12:08, Andrew Cooper
<andrew.cooper3@citrix.com> wrote:
>> On 22/06/12 10:43, Jan Beulich wrote:
>>>>>> On 22.06.12 at 11:04, Andrew Cooper
<andrew.cooper3@citrix.com> 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 ?
> Because, just like for normal, non-PCI based serial ones, ports
> that Xen doesn''t use should remain usable by Dom0. For
> example, I have a PCI card with two serial and one parallel
> ports, so with Xen using one serial port for itself, there''s no
> reason not to allow Dom0 to use the other or the parallel one.
I apologize.  I originally used the term ''device'' when I
intended to use
''function'', so I think we are arguing for the same point.
>
>>>> * 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.
> But that can''t be easily qualified into some rule, the more that
> some of these - iirc - are needed e.g. by the EDAC drivers.
>
> Jan
>
Which is why I am asking here, to see if there are some rules which
could help.  I agree that it is a sticky situation.

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

>>> On 22.06.12 at 14:06, Andrew Cooper
<andrew.cooper3@citrix.com> wrote:
> On 22/06/12 12:23, Jan Beulich wrote:
>>>>> On 22.06.12 at 12:08, Andrew Cooper
<andrew.cooper3@citrix.com> wrote:
>>> On 22/06/12 10:43, Jan Beulich wrote:
>>>>>>> On 22.06.12 at 11:04, Andrew Cooper
<andrew.cooper3@citrix.com> 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 ?
>> Because, just like for normal, non-PCI based serial ones, ports
>> that Xen doesn''t use should remain usable by Dom0. For
>> example, I have a PCI card with two serial and one parallel
>> ports, so with Xen using one serial port for itself, there''s
no
>> reason not to allow Dom0 to use the other or the parallel one.
> 
> I apologize.  I originally used the term ''device'' when I
intended to use
> ''function'', so I think we are arguing for the same point.
And I understood you meaning so - from a PCI terminology pov.
Multi-function here, however, means multiple serial/parallel ports
within a single PCI function (PCI_CLASS_COMMUNICATION_MULTISERIAL
or PCI_CLASS_COMMUNICATION_OTHER). Hence we shouldn''t hide a
full S:B:D.F just because we use some portion of it.

Jan

On 22/06/12 12:30, Jan Beulich wrote:
>> 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.
> And what would the hypercall do? You don''t expect it to fix up
> all the uses of the old address(es) to now use the new one(s),
> do you? Leaving aside the difficulty in getting this right, in some
> cases this might not even be possible in a seamless manner.
>
>> 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.
> Doing the mechanical trap-and-emulate part of this shouldn''t
> be that hard, namely on top of that other patch I''m about to
> commit.
>
> But the thing is that this has the same problems as the hypercall
> one above.
Currently my understanding is that dom0 has fairly free reign on the PCI
devices, meaning that if it decides to remap BARs and ends up with
conflicts, we already have a problem, especially if its a PCI device
that Xen is trying to use.

As Xen avoids using PCI devices as much as possible, it should be easier
(but doubtfully ''easy'') to make Xen aware that PCI devices it
is using
may move from under its feet.  ( I am just throwing ideas out here - it
might be that this is a stupid idea. )
>
>> I guess the real question is whether we should continue reactively
>> fixing problems, or start protectively fixing the root cause.
> I agree with this position from a theoretical standpoint.
>
>>  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.
> That would be bad - surfacing arbitrary devices on the PCI bus
> is - in my opinion - rather questionable a design (which is also
> why I consider this aspect of the AMD IOMMUs badly designed).
>
> Jan
Agreed, but we now have a problem and need a solution.
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com

On 22/06/12 13:20, Jan Beulich wrote:
>>> Because, just like for normal, non-PCI based serial ones, ports
>>> that Xen doesn''t use should remain usable by Dom0. For
>>> example, I have a PCI card with two serial and one parallel
>>> ports, so with Xen using one serial port for itself,
there''s no
>>> reason not to allow Dom0 to use the other or the parallel one.
>> I apologize.  I originally used the term ''device''
when I intended to use
>> ''function'', so I think we are arguing for the same
point.
> And I understood you meaning so - from a PCI terminology pov.
> Multi-function here, however, means multiple serial/parallel ports
> within a single PCI function (PCI_CLASS_COMMUNICATION_MULTISERIAL
> or PCI_CLASS_COMMUNICATION_OTHER). Hence we shouldn''t hide a
> full S:B:D.F just because we use some portion of it.
>
> Jan
>
Ah right.  Yes.  Perhaps then a warning on the Xen console if Xen
encounters such a device.

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