[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH for-2.9 v2 2/2] intel_iommu: provide "aw-bits" p
From: |
Peter Xu |
Subject: |
Re: [Qemu-devel] [PATCH for-2.9 v2 2/2] intel_iommu: provide "aw-bits" parameter |
Date: |
Wed, 14 Dec 2016 10:04:43 +0800 |
User-agent: |
Mutt/1.5.24 (2015-08-30) |
On Tue, Dec 13, 2016 at 06:40:28AM -0700, Alex Williamson wrote:
> On Tue, 13 Dec 2016 15:25:03 +0800
> Peter Xu <address@hidden> wrote:
>
> > Previously vt-d codes only supports 39 bits iova address width. This
> > patch provide a new parameter for Intel IOMMU to extend its address
> > width to 48 bits.
> >
> > After enabling larger address width (48), we should be able to map
> > larger iova addresses in the guest. To check whether 48 bits aw is
> > enabled, we can grep in the guest dmesg with line: "dmar: Host address
> > width 48".
> >
> > To keep compatibility with old QEMU and most hosts, default aw bits are
> > set to 39 bits.
>
> I really fail to see the benefit of this option. Clearly we always
> need to be able to support identity maps through the IOMMU, so the
> address width of the vIOMMU needs to support the maximum address of any
> memory or mmio range available to the VM. However if that's the case,
> then the address width of the vIOMMU should be automatically configured
> for the VM configuration. What's the benefit of creating yet another
> obscure device option rather than configuring this automatically. If
> the argument is to be able to test 48bit vIOMMU support, then we could
> simply prefix this option with 'x-' to indicate an experimental,
> unsupported option. Creating this option with the expectation that the
> user must specify this in order to potentially create a valid VT-d
> configuration for the VM doesn't make sense to me. Thanks,
I'll rename with "x-" prefix and repost. Thanks,
-- peterx