From: Peter Xu <peterx@redhat.com>
To: Prasad Singamsetty <prasad.singamsetty@oracle.com>
Cc: "Michael S. Tsirkin" <mst@redhat.com>,
ehabkost@redhat.com, konrad.wilk@oracle.com,
qemu-devel@nongnu.org, imammedo@redhat.com, pbonzini@redhat.com,
rth@twiddle.net
Subject: Re: [Qemu-devel] [PATCH v1 2/2] intel-iommu: Extend address width to 48 bits
Date: Fri, 1 Dec 2017 12:43:38 +0800 [thread overview]
Message-ID: <20171201044338.GB2712@xz-mi> (raw)
In-Reply-To: <fb9c086b-2b95-d09e-1c3f-d2274a347de6@oracle.com>
On Thu, Nov 30, 2017 at 11:12:48AM -0800, Prasad Singamsetty wrote:
>
>
> On 11/30/2017 10:56 AM, Michael S. Tsirkin wrote:
> > On Thu, Nov 30, 2017 at 10:33:50AM -0800, Prasad Singamsetty wrote:
> > >
> > >
> > > On 11/29/2017 7:25 PM, Peter Xu wrote:
> > > > On Wed, Nov 29, 2017 at 01:05:22PM -0800, Prasad Singamsetty wrote:
> > > > > Thanks Michael. Some comments below.
> > > > >
> > > > > On 11/28/2017 9:32 AM, Michael S. Tsirkin 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
> > > > > >
> > > > > > You can change the default, just make it 39 for existing machine types.
> > > > >
> > > > > I think introducing a new machine type is not appropriate as this
> > > > > is an implementation limitation for the existing machine type.
> > > > > Currently q35 is the only machine type that supports intel-iommu.
> > > > > And we want to retain the current default behavior for q35 to avoid
> > > > > any new issues with live migration.
> > > >
> > > > I guess "existing machine type" means e.g. pc-q35-2.11 and older ones,
> > > > rather than creating another machine type in parallel with q35. So we
> > > > can set 48 bits as default on upcoming pc-q35-2.12 machines, while
> > > > keep the 39 bits on the old ones.
> > > >
> > > > Please refer to include/hw/compat.h.
> > >
> > > Thanks Peter, for the clarification and pointer to this. I am still
> > > new to this but learning on how this works or how this is used in
> > > use cases like Live Migration.
You can refer to similar commit, like 048a2e8869.
But, I think I was wrong - you should better do the addition to
include/hw/i386/pc.h (see e.g. PC_COMPAT_2_10) rather than compat.h,
since Intel vIOMMU is only used for PC machines.
And... you may also need to create that PC_COMPAT_2_11 macro after
2.11 is released. For that you can refer to a6fd5b0e050a.
Anyway, I think this "set default" work can be postponed after recent
release, which can be a separate work besides current series.
> > >
> > > Are you suggesting that we change the default to 48 bits in the
> > > next release (2.12)?
> > >
> > > User need to specify an older machine type (pc-q35-2.11 or older)
> > > to get the old default value of 39 bits. This still requires the
> > > patch I proposed to support compatibility for older releases
> > > except the introduction of the new property (x-aw-bits).
> >
> > Yes. If you see a reason for users to limit it to 39 bits,
> > we can make it a supported property (not starting
> > with x-). If it's only for live migration, we can
> > use a non-supported property (with x-).
> I think it is only for Live Migration case, we need to
> support the old default value of 39 bits.
>
> Do you see any need to keep a non-supported property?
> It may be useful for developers.
IMHO if it's for developers x-* would be good enough. Thanks,
--
Peter Xu
next prev parent reply other threads:[~2017-12-01 16:32 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 [this message]
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
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=20171201044338.GB2712@xz-mi \
--to=peterx@redhat.com \
--cc=ehabkost@redhat.com \
--cc=imammedo@redhat.com \
--cc=konrad.wilk@oracle.com \
--cc=mst@redhat.com \
--cc=pbonzini@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).