Re: [Xen-devel] [PATCH v3 2/2] VT-d: Fix vt-d flush timeout issue.

["Xu, Quan" <quan.xu@xxxxxxxxx>]

> On 15.12.2015 at 5:17pm, <JBeulich@xxxxxxxx> wrote:
> >>> On 15.12.15 at 09:15, <quan.xu@xxxxxxxxx> wrote:
> >> On 14.12.2015 at 5:28pm, <JBeulich@xxxxxxxx> wrote:
> >> >>> On 12.12.15 at 14:21, <quan.xu@xxxxxxxxx> wrote:


> >> > @@ -88,6 +89,16 @@ struct pci_dev {  #define for_each_pdev(domain,
> >> > pdev) \
> >> >      list_for_each_entry(pdev, &(domain->arch.pdev_list),
> >> > domain_list)
> >> >
> >> > +static inline void mark_pdev_unassignable(struct pci_dev *pdev) {
> >> > +    pdev->info.is_unassignable = 1; }
> >> > +
> >> > +static inline bool_t is_pdev_unassignable(const struct pci_dev
> >> > +*pdev) {
> >> > +    return pdev->info.is_unassignable; }
> >>
> >> Are you aware that we already have a mechanism to prevent assignment
> >> (via pci_{ro,hide}_device())? I think at the very least this check
> >> should
> > consider both
> >> variants. Whether fully using the existing mechanism for your purpose
> >> is feasible I can't immediately tell (since the ownership change may
> >> be problematic at the points where you want the flagging to happen).
> >
> > pci_{ro,hide}_device() is dangerous, and it makes xen crash when I tried it.
> > for this case, IMO I think a flag is a better solution.
> 
> I can't really judge on this without know details of the crash. As said, I'd 
> prefer
> to have just a single mechanism, and would accept a second one only with
> proper justification (i.e. more than "is dangerous" or "makes xen crash" - 
> after
> all that may also be a result of the functions not being used as necessary).
> 

Jan, one question, do pci_{ro,hide}_device() work to hide pci devices?

Quan






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