From: "Michael S. Tsirkin" <mst@redhat.com>
To: Yu Zhang <yu.c.zhang@linux.intel.com>
Cc: Eduardo Habkost <ehabkost@redhat.com>,
qemu-devel@nongnu.org, Peter Xu <peterx@redhat.com>,
Igor Mammedov <imammedo@redhat.com>,
Paolo Bonzini <pbonzini@redhat.com>,
Richard Henderson <rth@twiddle.net>
Subject: Re: [Qemu-devel] [PATCH v3 2/2] intel-iommu: extend VTD emulation to allow 57-bit IOVA address width.
Date: Tue, 25 Dec 2018 12:00:08 -0500 [thread overview]
Message-ID: <20181225115658-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <20181222004137.b7hj623kmzsq5ttv@linux.intel.com>
On Sat, Dec 22, 2018 at 08:41:37AM +0800, Yu Zhang wrote:
> On Fri, Dec 21, 2018 at 01:10:13PM -0500, Michael S. Tsirkin wrote:
> > On Sat, Dec 22, 2018 at 01:34:01AM +0800, Yu Zhang wrote:
> > > On Fri, Dec 21, 2018 at 12:15:26PM -0500, Michael S. Tsirkin wrote:
> > > > On Sat, Dec 22, 2018 at 12:19:20AM +0800, Yu Zhang wrote:
> > > > > > I'd like to avoid poking at the CPU from VTD code. That's all.
> > > > >
> > > > > OK. So for the short term,how about I remove the check of host cpu, and add a TODO
> > > > > in the comments in vtd_decide_config()?
> > > >
> > > > My question would be what happens on an incorrect use?
> > >
> > > I believe the vfio_dma_map will return failure for an incorrect use.
> > >
> > > > And how does user figure out which values to set?
> > >
> > > Well, for now I don't think user can figure out. E.g. if we expose a vIOMMU with
> > > 48-bit IOVA capability, yet host only supports 39-bit IOVA, vfio shall return failure,
> > > but the user does not know whose fault it is.
> > > >
> > > > > As to the check against hardware IOMMU, Peter once had a proposal in
> > > > > http://lists.nongnu.org/archive/html/qemu-devel/2018-11/msg02281.html
> > > > >
> > > > > Do you have any comment or suggestion on Peter's proposal?
> > > >
> > > > Sounds reasonable to me. Do we do it on vfio attach or unconditionally?
> > > >
> > >
> > > I guess on vfio attach? Will need more thinking in it.
> >
> >
> > Things like live migration (e.g. after hot removal of the vfio device)
> > are also concerns.
>
> Sorry, why live migration shall be a problem? I mean, if the DMA address
> width of vIOMMU does not match the host IOMMU's, we can just stop creating
> the VM, there's no live migration.
I don't see code like this though.
Also management needs to somehow be able to figure out that migration
will fail. It's not nice to transfer all memory and then have it fail
when viommu is migrated. So from that POV a flag is better. It can be
validated agains host capabilities.
We can still have something like aw=host just like cpu host.
> >
> > > >
> > > > > I still do not quite know
> > > > > how to do it for now...
> > > > >
> > > > > [...]
> > > > >
> > > > >
> > > > > B.R.
> > > > > Yu
> > > >
> > > >
> > > >
> > > > --
> > > > MST
> > >
> > > B.R.
> > > Yu
>
> B.R.
> Yu
next prev parent reply other threads:[~2018-12-25 17:00 UTC|newest]
Thread overview: 57+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-12 13:05 [Qemu-devel] [PATCH v3 0/2] intel-iommu: add support for 5-level virtual IOMMU Yu Zhang
2018-12-12 13:05 ` [Qemu-devel] [PATCH v3 1/2] intel-iommu: differentiate host address width from IOVA address width Yu Zhang
2018-12-17 13:17 ` Igor Mammedov
2018-12-18 9:27 ` Yu Zhang
2018-12-18 14:23 ` Michael S. Tsirkin
2018-12-18 14:55 ` Igor Mammedov
2018-12-18 14:58 ` Michael S. Tsirkin
2018-12-19 3:03 ` Yu Zhang
2018-12-19 3:12 ` Michael S. Tsirkin
2018-12-19 6:28 ` Yu Zhang
2018-12-19 15:30 ` Michael S. Tsirkin
2018-12-19 2:57 ` Yu Zhang
2018-12-19 10:40 ` Igor Mammedov
2018-12-19 16:47 ` Michael S. Tsirkin
2018-12-20 5:59 ` Yu Zhang
2018-12-20 21:18 ` Eduardo Habkost
2018-12-21 14:13 ` Igor Mammedov
2018-12-21 16:09 ` Yu Zhang
2018-12-21 17:04 ` Michael S. Tsirkin
2018-12-21 17:37 ` Yu Zhang
2018-12-21 19:02 ` Michael S. Tsirkin
2018-12-21 20:01 ` Eduardo Habkost
2018-12-22 1:11 ` Yu Zhang
2018-12-25 16:56 ` Michael S. Tsirkin
2018-12-26 5:30 ` Yu Zhang
2018-12-27 15:14 ` Eduardo Habkost
2018-12-28 2:32 ` Yu Zhang
2018-12-29 1:29 ` Eduardo Habkost
2019-01-15 7:13 ` Yu Zhang
2019-01-18 7:10 ` Yu Zhang
2018-12-27 14:54 ` Eduardo Habkost
2018-12-28 11:42 ` Igor Mammedov
2018-12-20 20:58 ` Eduardo Habkost
2018-12-12 13:05 ` [Qemu-devel] [PATCH v3 2/2] intel-iommu: extend VTD emulation to allow 57-bit " Yu Zhang
2018-12-17 13:29 ` Igor Mammedov
2018-12-18 9:47 ` Yu Zhang
2018-12-18 10:01 ` Yu Zhang
2018-12-18 12:43 ` Michael S. Tsirkin
2018-12-18 13:45 ` Yu Zhang
2018-12-18 14:49 ` Michael S. Tsirkin
2018-12-19 3:40 ` Yu Zhang
2018-12-19 4:35 ` Michael S. Tsirkin
2018-12-19 5:57 ` Yu Zhang
2018-12-19 15:23 ` Michael S. Tsirkin
2018-12-20 5:49 ` Yu Zhang
2018-12-20 18:28 ` Michael S. Tsirkin
2018-12-21 16:19 ` Yu Zhang
2018-12-21 17:15 ` Michael S. Tsirkin
2018-12-21 17:34 ` Yu Zhang
2018-12-21 18:10 ` Michael S. Tsirkin
2018-12-22 0:41 ` Yu Zhang
2018-12-25 17:00 ` Michael S. Tsirkin [this message]
2018-12-26 5:58 ` Yu Zhang
2018-12-25 1:59 ` Tian, Kevin
2018-12-14 9:17 ` [Qemu-devel] [PATCH v3 0/2] intel-iommu: add support for 5-level virtual IOMMU Yu Zhang
2019-01-15 4:02 ` Michael S. Tsirkin
2019-01-15 7:27 ` Yu Zhang
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=20181225115658-mutt-send-email-mst@kernel.org \
--to=mst@redhat.com \
--cc=ehabkost@redhat.com \
--cc=imammedo@redhat.com \
--cc=pbonzini@redhat.com \
--cc=peterx@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=rth@twiddle.net \
--cc=yu.c.zhang@linux.intel.com \
/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).