On Wed, Jun 22, 2011 at 21:48, Todd Deshane <todd.deshane@xxxxxxx> wrote:
> On Wed, Jun 22, 2011 at 1:20 PM, Alex Merritt <merritt.alex@xxxxxxxxx> wrote:
>> Hi,
>>
>> 2011/6/22 sploving <sploving1@xxxxxxx>:
>>>
>>>
>>>
>>> At 2011-06-21 12:17:56，"Alex Merritt" <merritt.alex@xxxxxxxxx> wrote:
>>>
>>>>Hello,
>>>>
>>>>I've been experimenting with VT-d supported PCI-passthrough in Xen for
>>>>HVM guests, and was wondering if it is possible to create an IOMMU
>>>>domain for Dom0 as well. I'm not sure if I'm asking the question
>>>>correctly, but to avoid changing a bare-metal driver for an I/O device
>>>>to translate system memory addresses used by a DMA engine, would I
>>>>instead be able to allow the IOMMU to transparently translate
>>>>addresses just like for guest VMs, but within Dom0?
>>> why put the IOMMU within Dom0? not in the driver domain?
>>
>> I'm using research code, which currently requires the management
>> extension and driver to exist within the same domain. IOMMUs are meant
>> for guest VMs as far as I can tell. They can be used as driver
>> domains, too, but (unless I'm mistaken) cannot use the management
>> interfaces available in Dom0.
>>
>
> To me, this research sounds similar to "InDriver: Using In-VM
> Isolation to Implement Drivers" that is going to be presented at the
> upcoming Xen Summit
>
> see: http://xen.org/community/xensummit.html
>
> I could be wrong about the relationship, but it does sound like
> similar concepts are being explored.
Hm, there doesn't seem to be a link describing the talk/work in more
detail. I'm attempting to just give the NVIDIA driver an IOMMU domain
in Dom0 for accessing the GPUs within a machine. There's been a lot of
frustration over the years trying to get CUDA to work on Dom0 as well
as 3D support. I'm attempting to determine if this is at all possible
using VT-d.
>
>
>> My driver domain is also Dom0 at the moment.
>>
>>> Some searching and
>>>>reading of the wiki pages on xen.org tells me the answer is "no". But
>>>>I cannot determine if this is purely because the implementation within
>>>>the VMM doesn't exist, or because it is that Dom0 is para-virtualized
>>>>and thus cannot use VT-d without VT-x. I'm suspecting it is not the
>>>>latter, as the VTdHowTo wiki page hints PV guests may use VT-d and the
>>>>Intel manual for VT-d describes OS developers may take advantage of
>>>>this extension.
>>>>
>>>>My immediate interest is more to see if it "can be done" via a hack or
>>>>something, not necessarily whether it would make sense
>>> for Xen to
>>>>support this in the future.
>>>>
>>> You should ask this question in xen-dev list.
>>
>> Okay, I'll do that. I'm new to these mailing lists, and wasn't sure
>> where to start. Thanks.
>>
>>>>I'm using Xen 4.1.1 and pv-ops linux (not upstream) 2.6.32.40 on an
>>>>Intel X5660 with a
>>> Tylersburg chipset.
>>>>
>>>>Thanks!
>>>>Alex
>>>>
>>>>_______________________________________________
>>>>Xen-users mailing list
>>>>Xen-users@xxxxxxxxxxxxxxxxxxx
>>>>http://lists.xensource.com/xen-users
>>
>> _______________________________________________
>> Xen-users mailing list
>> Xen-users@xxxxxxxxxxxxxxxxxxx
>> http://lists.xensource.com/xen-users
>>
>
>
>
> --
> Todd Deshane
> http://www.linkedin.com/in/deshantm
> http://www.xen.org/products/cloudxen.html
> http://runningxen.com/
>
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
|
Home