From mboxrd@z Thu Jan 1 00:00:00 1970 From: Suravee Suthikulpanit Subject: Re: [PATCH 1/1] x86/AMD: Fix setup ssss:bb:dd:f for d0 failed Date: Fri, 30 Aug 2013 19:03:54 -0500 Message-ID: <522132EA.1090309@amd.com> References: <1375843208-3165-1-git-send-email-suravee.suthikulpanit@amd.com> <5202147D02000078000E9D00@nat28.tlf.novell.com> <5202685F.8090601@amd.com> <5202871902000078000EA01A@nat28.tlf.novell.com> <52029E12.20305@amd.com> <520358F502000078000EA1AA@nat28.tlf.novell.com> <521FF488.2030708@amd.com> <52206F5C02000078000EFA14@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8803767644311998355==" Return-path: Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1VFYfe-0008L5-3d for xen-devel@lists.xenproject.org; Sat, 31 Aug 2013 00:04:06 +0000 In-Reply-To: <52206F5C02000078000EFA14@nat28.tlf.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich Cc: xen-devel , xiantao.zhang@intel.com List-Id: xen-devel@lists.xenproject.org --===============8803767644311998355== Content-Type: multipart/alternative; boundary="------------080008070808090605070007" --------------080008070808090605070007 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit On 8/30/2013 3:09 AM, Jan Beulich wrote: >> Sorry for didn't get a chance to follow up with this sooner. Ok, I see >> >the code you mentioned. >> >However, if I understand this correctly, it is also mapping the bridge >> >to the domU >> >along with the end-device. This is not the same as what you mentioned >> >that the bridge should >> >be mapped to only Dom0. > I don't think I ever said this. Whether we're talking about DomU or > Dom0 here is irrelevant. I'm just pointing out that bridges do get > mappings established for them whenever a device behind them gets > mapped. > > Jan Ok, I think Iunderstand it a bit more now. I'll modify the code to skip only the hostbridge when they are not specifiedin the IVRS as it is not needed to be mapped to adomain. I'll send out the code shortly. However, I also found out that the current AMD IOMMU driver maps other type of bridges (i.e. DEV_TYPE_PCIe_BRIDGE, DEV_TYPE_PCIe2PCI_BRIDGE, and DEV_TYPE_LEGACY_PCI_BRIDGE) _only_ to Dom0, and they won't get reassignedwhen the end point devices downstreamare assignedto other domain. I don't think this is correct.I'll work on this and and send out a separate patch for this. Thank you, Suravee --------------080008070808090605070007 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit
On 8/30/2013 3:09 AM, Jan Beulich wrote:
Sorry for didn't get a chance to follow up with this sooner.  Ok, I see 
> the code you mentioned.
> However, if I understand this correctly, it is also mapping the bridge 
> to the domU
> along with the end-device.  This is not the same as what you mentioned 
> that the bridge should
> be mapped to only Dom0.

I don't think I ever said this. Whether we're talking about DomU or
Dom0 here is irrelevant. I'm just pointing out that bridges do get
mappings established for them whenever a device behind them gets
mapped.

Jan
Ok, I think I understand it a bit more now. I'll modify the code to skip only the host bridge when they are not
specified in the IVRS as it is not needed to be mapped to a domain.  I'll send out the code shortly.

However, I also found out that the current AMD IOMMU driver maps other type of bridges
(i.e. DEV_TYPE_PCIe_BRIDGE, DEV_TYPE_PCIe2PCI_BRIDGE, and DEV_TYPE_LEGACY_PCI_BRIDGE) _only_ to Dom0,
and they won't get reassigned when the end point devices downstream are assigned to other domain.
I don't think this is correct. I'll work on this and and send out a separate patch for this.

Thank you,

Suravee

--------------080008070808090605070007-- --===============8803767644311998355== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============8803767644311998355==--