From: "Liu, Yi L" <yi.l.liu@linux.intel.com>
To: Peter Xu <peterx@redhat.com>
Cc: ehabkost@redhat.com, mst@redhat.com, konrad.wilk@oracle.com,
qemu-devel@nongnu.org, imammedo@redhat.com, pbonzini@redhat.com,
prasad.singamsetty@oracle.com, rth@twiddle.net
Subject: Re: [Qemu-devel] [PATCH v1 2/2] intel-iommu: Extend address width to 48 bits
Date: Thu, 30 Nov 2017 17:54:35 +0800 [thread overview]
Message-ID: <20171130095435.GC30936@sky-dev> (raw)
In-Reply-To: <20171130091155.GH22901@xz-mi>
On Thu, Nov 30, 2017 at 05:11:55PM +0800, Peter Xu wrote:
> On Thu, Nov 30, 2017 at 01:22:38PM +0800, Liu, Yi L wrote:
> > On Tue, Nov 14, 2017 at 06:13:50PM -0500, prasad.singamsetty@oracle.com wrote:
> > > From: Prasad Singamsetty <prasad.singamsetty@oracle.com>
> > >
> > > The current implementation of Intel IOMMU code only supports 39 bits
> > > iova address width. This patch provides a new parameter (x-aw-bits)
> > > for intel-iommu to extend its address width to 48 bits but keeping the
> > > default the same (39 bits). The reason for not changing the default
> > > is to avoid potential compatibility problems with live migration of
> > > intel-iommu enabled QEMU guest. The only valid values for 'x-aw-bits'
> > > parameter are 39 and 48.
> > >
> > > After enabling larger address width (48), we should be able to map
> > > larger iova addresses in the guest. For example, a QEMU guest that
> > > is configured with large memory ( >=1TB ). To check whether 48 bits
> >
> > I didn't quite get your point here. Address width limits the iova range,
> > but it doesn't limit the guest memory range. e.g. you can use 39 bit iova
> > address to access a guest physical address larger than (2^39 - 1) as long
> > as the guest 2nd level page table is well programmed. Only one exception,
> > if you requires a continuous iova range(e.g. 2^39), it would be an issue.
> > Not sure if this is the major motivation of your patch? However, I'm not
> > against extend the address width to be 48 bits. Just need to make it clear
> > here.
>
> One thing I can think of is the identity mapping. Say, when iommu=pt
> is set in guest, meanwhile when PT capability is not supported from
> hardware (here I mean, the emulated hardware, of course), guest kernel
> will create one identity mapping to emulate the PT mode.
True.
> Current linux kernel's identity mapping should be a static 48 bits
> mapping (it must cover the whole memory range of guest), so if we
I suppose guest memory range depends on the AW reported by CPUID? Not sure
if it is constantly 48 bits.
> provide a 39 bits vIOMMU to the guest, AFAIU we'll fail at device
> attaching to that identity domain of every single device that is
> protected by that 39 bits vIOMMU (kernel will find that domain gaw is
> bigger than vIOMMU supported gaw of that device).
Yeah, this is a good argue. As it is 1:1 mapping, the translated address
is limited all the same.
> I do see no good fix for that, except boost the supported gaw to
> bigger ones.
How about defaultly expose cap.PT bit? In that case, there will no 1:1
mapping in guest side. Translation is skipped. So the IOMMU AW won't
limit the addressing.
Regards,
Yi L
>
> Thanks,
>
> --
> Peter Xu
>
next prev parent reply other threads:[~2017-11-30 10:11 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-14 23:13 [Qemu-devel] [PATCH v1 0/2] intel-iommu: Extend address width to 48 bits prasad.singamsetty
2017-11-14 23:13 ` [Qemu-devel] [PATCH v1 1/2] intel-iommu: Redefine macros to enable supporting 48 bit address width prasad.singamsetty
2017-12-01 11:23 ` Liu, Yi L
2017-12-01 18:15 ` Prasad Singamsetty
2017-11-14 23:13 ` [Qemu-devel] [PATCH v1 2/2] intel-iommu: Extend address width to 48 bits prasad.singamsetty
2017-11-28 17:32 ` Michael S. Tsirkin
2017-11-29 21:05 ` Prasad Singamsetty
2017-11-30 3:25 ` Peter Xu
2017-11-30 18:33 ` Prasad Singamsetty
2017-11-30 18:56 ` Michael S. Tsirkin
2017-11-30 19:12 ` Prasad Singamsetty
2017-12-01 4:43 ` Peter Xu
2017-12-01 17:02 ` Prasad Singamsetty
2017-12-01 17:03 ` Michael S. Tsirkin
2017-12-04 4:07 ` Peter Xu
2017-11-30 5:22 ` Liu, Yi L
2017-11-30 9:11 ` Peter Xu
2017-11-30 9:54 ` Liu, Yi L [this message]
2017-11-30 11:58 ` Peter Xu
2017-12-01 11:29 ` Liu, Yi L
2018-01-11 0:05 ` Prasad Singamsetty
2018-01-11 2:46 ` Liu, Yi L
2018-01-11 16:19 ` Prasad Singamsetty
2017-11-15 7:40 ` [Qemu-devel] [PATCH v1 0/2] " Peter Xu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20171130095435.GC30936@sky-dev \
--to=yi.l.liu@linux.intel.com \
--cc=ehabkost@redhat.com \
--cc=imammedo@redhat.com \
--cc=konrad.wilk@oracle.com \
--cc=mst@redhat.com \
--cc=pbonzini@redhat.com \
--cc=peterx@redhat.com \
--cc=prasad.singamsetty@oracle.com \
--cc=qemu-devel@nongnu.org \
--cc=rth@twiddle.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).