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

[Xen-devel] RE: Resend: RE: enable_ats_device() call site


  • To: Jan Beulich <JBeulich@xxxxxxxxxx>
  • From: "Kay, Allen M" <allen.m.kay@xxxxxxxxx>
  • Date: Mon, 22 Aug 2011 15:01:29 -0700
  • Accept-language: en-US
  • Acceptlanguage: en-US
  • Cc: Xen Devel <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Mon, 22 Aug 2011 15:04:21 -0700
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: AcxeUdki2yWUrBygQZmG/6rNwXipRACxBs3Q
  • Thread-topic: Resend: RE: enable_ats_device() call site

>And why is it VT-d specific then? The problem to solve is that enabling
>may not happen when it is first attempted, in the case where Xen on its
>own can't be certain that using MMCFG is safe. Hence when the device
>gets reported by Dom0 (or when MMCFG gets enabled for the respective
>bus), another attempt needs to be made at enabling it. De-assigning and
>then re-assigning the device to Dom0 seems to be overkill to me.

The part that is VT-d specific is ATS capability reporting in ACPI DMAR
table for reporting ATS capability in root ports.  I not so clear on what
do you mean by making another attempt when initial ATS enabling attempt fails.
Do you have a patch to address this issue?

Allen

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

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