| |
|
 |
|
 |
|
|
|
| |
|
|
xen-users
Re: [Xen-users] IOMMU Domain for Dom0
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.
> 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