Xen devel - Jul 2011 - [RFC] [PATCH] xen, vtd: Check ownership of a domain context using internal structures

Keir, Jan, et al:

Can you take a look at this patch to see if you think this is the
right way to solve this problem?

This particular patch is still being tested by the partner who saw the
problem; but a less safe change -- just returning "OK" if the pci
device didn''t exist -- did solve the problem.  It seemed like this
check was probably there for a reason, so I wanted to keep it in
place.  (Although the c/s in which this check was introduced,
18906:2941b1a9, only mentioned locking changes, not introduction of
new checks.)

Thanks,
 -George


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

And in a related note...

What is the implication of the "Devices on a bus behind a bridge look
like they''re coming from X:0.0" for passing virtual functions
through
to different VMs?  Will it simply not work (since the mapping of X:0.0
can''t be owned by both)?  Is there a way it can be made to work
without allowing the virtual function of one domain access to the
memory of the other domain?

 -George

On Wed, Jul 27, 2011 at 11:36 AM, George Dunlap
<George.Dunlap@eu.citrix.com> wrote:
> Keir, Jan, et al:
>
> Can you take a look at this patch to see if you think this is the
> right way to solve this problem?
>
> This particular patch is still being tested by the partner who saw the
> problem; but a less safe change -- just returning "OK" if the pci
> device didn''t exist -- did solve the problem.  It seemed like this
> check was probably there for a reason, so I wanted to keep it in
> place.  (Although the c/s in which this check was introduced,
> 18906:2941b1a9, only mentioned locking changes, not introduction of
> new checks.)
>
> Thanks,
>  -George
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

>>> On 27.07.11 at 12:36, George Dunlap
<George.Dunlap@eu.citrix.com> wrote:
> Keir, Jan, et al:
> 
> Can you take a look at this patch to see if you think this is the
> right way to solve this problem?
Makes sense, and looks reasonable to me (though I''m far from being
a passthrough expert).
> This particular patch is still being tested by the partner who saw the
> problem; but a less safe change -- just returning "OK" if the pci
> device didn''t exist -- did solve the problem.  It seemed like this
> check was probably there for a reason, so I wanted to keep it in
> place.  (Although the c/s in which this check was introduced,
> 18906:2941b1a9, only mentioned locking changes, not introduction of
> new checks.)
Yes, retaining the check is definitely needed.

Jan


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

>>> On 27.07.11 at 12:52, George Dunlap
<George.Dunlap@eu.citrix.com> wrote:
> And in a related note...
> 
> What is the implication of the "Devices on a bus behind a bridge look
> like they''re coming from X:0.0" for passing virtual functions
through
> to different VMs?  Will it simply not work (since the mapping of X:0.0
> can''t be owned by both)?  Is there a way it can be made to work
> without allowing the virtual function of one domain access to the
> memory of the other domain?
No, that can''t afaik - these devices are required to be PCIe, and the
issue here only applies to traditional PCI bridges (and I don''t think
PCIe
devices can sit behind one, or if they can, the code isn''t prepared to
deal with that anyway).

Jan


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

Thanks, Jan.

BTW Keir: this particular instance of the patch caused the customer''s
dom0 to crash on boot, so it''s not ready to be applied yet.  (Oh the
joys of fixing a bug for a system you don''t have on-site.) 
I''ll send
a new patch when I have one that works properly.

 -George

On Thu, Jul 28, 2011 at 6:48 PM, Jan Beulich <JBeulich@novell.com>
wrote:
>>>> On 27.07.11 at 12:36, George Dunlap
<George.Dunlap@eu.citrix.com> wrote:
>> Keir, Jan, et al:
>>
>> Can you take a look at this patch to see if you think this is the
>> right way to solve this problem?
>
> Makes sense, and looks reasonable to me (though I''m far from being
> a passthrough expert).
>
>> This particular patch is still being tested by the partner who saw the
>> problem; but a less safe change -- just returning "OK" if the
pci
>> device didn''t exist -- did solve the problem.  It seemed like
this
>> check was probably there for a reason, so I wanted to keep it in
>> place.  (Although the c/s in which this check was introduced,
>> 18906:2941b1a9, only mentioned locking changes, not introduction of
>> new checks.)
>
> Yes, retaining the check is definitely needed.
>
> Jan
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel