From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "Zhang, Yang Z" <yang.z.zhang@intel.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
"gordan@bobich.net" <gordan@bobich.net>,
"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: Dealing with non-existent BDF devices in VT-d and in the hardware.
Date: Mon, 17 Mar 2014 16:00:20 -0400 [thread overview]
Message-ID: <20140317200020.GD16397@phenom.dumpdata.com> (raw)
In-Reply-To: <A9667DDFB95DB7438FA9D7D576C3D87E0AA1728D@SHSMSX104.ccr.corp.intel.com>
On Mon, Mar 17, 2014 at 01:03:00AM +0000, Zhang, Yang Z wrote:
> Konrad Rzeszutek Wilk wrote on 2014-03-15:
> >>
> >> What happens if you assign the devices under bus 09 to another guest?
> >
> > Hadn't tried that. I think it would all blow up as the the
> > non-existent bridge is now assigned to one guest and the phantom DMA
> > requests for the
> > 09 would show up under the 08 device. I think I would corrupt the
> > guest memory with random DMA writes.
> >
> >> Is it better to add Xen command line to add such devices to a group
> >> and
> > assign the whole group to a guest when trying to assign a device of
> > the group to guest?
> >
> > Or implement the group assigment in QEMU or libxl so that nobody tries
> > doing it.
>
> But I think user still need to tell which device is buggy manually and I don't think QEMU or libxl can do it.
I think there are two issues here:
a) Missing device assigments via groups. That should be done irregardless
if the device / hardware is buggy.
b) Buggy devices like the IDT bridge that I see. That is a seperate issue - and
we just discussion if we want to inject that in the VT-d (or AMD-VI) what
would be the mechanism to do that.
>
> Best regards,
> Yang
>
>
next prev parent reply other threads:[~2014-03-17 20:00 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-11 17:30 Dealing with non-existent BDF devices in VT-d and in the hardware 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 [this message]
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
-- strict thread matches above, loose matches on Subject: below --
2014-03-20 1:34 Konrad Rzeszutek Wilk
2014-03-20 10:02 ` Jan Beulich
2014-03-20 19:44 ` Konrad Rzeszutek Wilk
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=20140317200020.GD16397@phenom.dumpdata.com \
--to=konrad.wilk@oracle.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).