From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: Yang Z Zhang <yang.z.zhang@intel.com>,
andrew.cooper3@citrix.com,
"gordan@bobich.net" <gordan@bobich.net>,
Xen Devel <xen-devel@lists.xensource.com>
Subject: Re: Dealing with non-existent BDF devices in VT-d and in the hardware.
Date: Thu, 20 Mar 2014 15:44:03 -0400 [thread overview]
Message-ID: <20140320194403.GC2433@localhost.localdomain> (raw)
In-Reply-To: <532ACAA902000078001260C4@nat28.tlf.novell.com>
On Thu, Mar 20, 2014 at 10:02:01AM +0000, Jan Beulich wrote:
> >>> On 20.03.14 at 02:34, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> > On Mar 19, 2014 8:48 PM, "Zhang, Yang Z" <yang.z.zhang@intel.com> wrote:
> >> fake a device is a solution. But I am thinking (maybe I am wrong) why not
> > setup all VT-d entries under a bridge if passing a PCI device under a bridge.
> > Because when passing a PCI device under a bridge, all devices under bridge
> > should be assigned to the guest too. What current Xen dose is only set the
> > entry which has device, so why not extend it to setup all entries? In this
> > case, there is no user input is required.
> >
> > We are talking about two different things here.
>
> Not really.
>
> > To your idea of passing in all of the devices along that are under a bridge
> > (or at least check for that) is sensible. We can't just pass in it in without
> > checking that the devices have been deassigned from the dom0 device drivers.
>
> That's what xend is doing, but xl isn't.
>
> > But if they are all 'floating' and not being in use - sure (thought maybe
> > provide an option in the tool stack- we needn't to pass all of them if nobody
> > else is using them).
>
> Aiui he wasn't suggesting to pass them all to the guest, just to put all
> IDs in the IOMMU tables, such that no faults would arise if an ID other
> then the root-most PCI bridge's one or that of any _existing_ device.
Aha! Thank you explaining. That would certainly make it easier.
>
> > The original issue in this thread was - what if any option should we come up
> > to work around broken firmware that uses non-existent BDFs. Should it be some
> > boot up parameter or should we alter an hyper call to allow creation of
> > phantom devices under a bridge. Then later it can be assigned as part of a
> > group to a guest.
>
> With Yang's proposal - provided its security can be proven - you
> wouldn't need any command line override.
Right.
>
> Jan
>
next prev parent reply other threads:[~2014-03-20 19:44 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-20 1:34 Dealing with non-existent BDF devices in VT-d and in the hardware Konrad Rzeszutek Wilk
2014-03-20 10:02 ` Jan Beulich
2014-03-20 19:44 ` Konrad Rzeszutek Wilk [this message]
-- strict thread matches above, loose matches on Subject: below --
2014-03-11 17:30 Konrad Rzeszutek Wilk
2014-03-11 17:36 ` Andrew Cooper
2014-03-11 17:49 ` Konrad Rzeszutek Wilk
2014-03-14 2:18 ` Zhang, Yang Z
2014-03-14 17:51 ` Konrad Rzeszutek Wilk
2014-03-17 1:03 ` Zhang, Yang Z
2014-03-17 20:00 ` Konrad Rzeszutek Wilk
2014-03-19 0:32 ` Zhang, Yang Z
2014-03-19 12:57 ` Konrad Rzeszutek Wilk
2014-03-19 14:24 ` Jan Beulich
2014-03-20 0:48 ` Zhang, Yang Z
2014-03-20 7:14 ` Gordan Bobic
2014-03-20 10:04 ` Jan Beulich
2014-03-20 9:58 ` Jan Beulich
2014-03-24 2:37 ` Zhang, Yang Z
2014-03-24 7:25 ` Jan Beulich
2014-03-12 9:17 ` Jan Beulich
2014-03-12 14:22 ` Konrad Rzeszutek Wilk
2014-03-12 17:10 ` Gordan Bobic
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140320194403.GC2433@localhost.localdomain \
--to=konrad.wilk@oracle.com \
--cc=JBeulich@suse.com \
--cc=andrew.cooper3@citrix.com \
--cc=gordan@bobich.net \
--cc=xen-devel@lists.xensource.com \
--cc=yang.z.zhang@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.