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

RE: [Xen-devel] RE: [VTD-NEO][patch 6/6] Intel VT-d/Neocleus 1:1 mreged code for PCI passthrough


  • To: "Keir Fraser" <Keir.Fraser@xxxxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • From: "Kay, Allen M" <allen.m.kay@xxxxxxxxx>
  • Date: Thu, 20 Sep 2007 07:38:14 -0700
  • Delivery-date: Thu, 20 Sep 2007 07:39:06 -0700
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: AcfvUQE/NSLHf0ZTRFaUb5meDjaqbALsHd9QABfyc/cAAerY8gAKUhMQ
  • Thread-topic: [Xen-devel] RE: [VTD-NEO][patch 6/6] Intel VT-d/Neocleus 1:1 mreged code for PCI passthrough

>On 20/9/07 09:35, "Keir Fraser" <Keir.Fraser@xxxxxxxxxxxx> wrote:
>
>>> dom0.patch: create vt-d 1:1 mapping for dom0; call 
>iommu_domain_init()
>>> in domain.c.
>> 
>> Do PV guests actually need per-domain iommu state? If they do, isn't
>> release_devices() the partnering destructor function, and so 
>should that not
>> be invoked from domain.c too?

The reason iommu_domain_init() initializes iommu domain strcture.
Device_release() frees various memory used by iommu domain structure +
it calls return_devices_to_dom0().  Return_devices_to_dom0() reassigns
devices back to dom0 in vt-d hw and moves the pdev's to dom0's
pdev_list.

Iommu_domain_init() needs to be called in domain.c because dom0 needs
it.  Device_release can potentially be called in domain.c also -
probably just need to add "if (d == dom0) return;" in
return_devices_to_dom0().

PV guest is not currently supported right now.  We had few pieces here
and there but I removed it from the submission until we do some tests.

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®.