[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH 1/1] x86/AMD: Fix setup ssss:bb:dd:f for d0 failed

On 8/8/2013 1:38 AM, Jan Beulich wrote:
On 07.08.13 at 21:20, Suravee Suthikulanit <suravee.suthikulpanit@xxxxxxx> 
On 8/7/2013 10:42 AM, Jan Beulich wrote:
On 07.08.13 at 17:31, Suravee Suthikulanit <suravee.suthikulpanit@xxxxxxx> 
I am using the same logic here as in Intel's version in the
No, not really: That code establishes a mapping for the upstream
bridge of a legacy PCI device when handling that device. Your
proposed code doesn't afaics. (This I understand is because
bridges aren't expected to get assigned to guests, and hence
otherwise the mapping for the bridge would never get established
for a device behind it for other than Dom0.)
AFAICT from the domain_context_mapping() below, which get called when
the devices are assigned to domains

static int domain_context_mapping(
      struct domain *domain, u8 devfn, const struct pci_dev *pdev)
      struct acpi_drhd_unit *drhd;
      int ret = 0;
      u8 seg = pdev->seg, bus = pdev->bus, secbus;

      drhd = acpi_find_matched_drhd_unit(pdev);
      if ( !drhd )
          return -ENODEV;


      switch ( pdev->type )
      case DEV_TYPE_PCIe_BRIDGE:

These bridges are actually not mapped(i.e. skipped).  That is why I
think the logic above is supposed to be doing the same thing.
Just look a few lines down: There the bridges will get mappings
established when a device behind them gets mapped.

But since devices can't be behind host bridges, excluding those
_may_ still be appropriate/desirable. Still waiting for Xiantao to
voice his opinion...

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.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.