From: Gleb Natapov <gleb@redhat.com>
To: Alex Williamson <alex.williamson@redhat.com>
Cc: Xiao Guangrong <xiaoguangrong@linux.vnet.ibm.com>,
Marcelo Tosatti <mtosatti@redhat.com>,
Takuya Yoshikawa <yoshikawa_takuya_b1@lab.ntt.co.jp>,
kvm@vger.kernel.org
Subject: Re: [PATCH 0/4] KVM: Clean up and optimize __kvm_set_memory_region() - part1
Date: Thu, 17 Jan 2013 19:58:59 +0200 [thread overview]
Message-ID: <20130117175859.GC10107@redhat.com> (raw)
In-Reply-To: <1358443805.9252.14.camel@ul30vt.home>
On Thu, Jan 17, 2013 at 10:30:05AM -0700, Alex Williamson wrote:
> On Thu, 2013-01-17 at 19:20 +0200, Gleb Natapov wrote:
> > On Thu, Jan 17, 2013 at 10:12:06AM -0700, Alex Williamson wrote:
> > > On Thu, 2013-01-17 at 09:29 +0200, Gleb Natapov wrote:
> > > > On Thu, Jan 17, 2013 at 11:20:43AM +0800, Xiao Guangrong wrote:
> > > > > On 01/17/2013 03:07 AM, Marcelo Tosatti wrote:
> > > > > > On Fri, Jan 11, 2013 at 06:25:18PM +0900, Takuya Yoshikawa wrote:
> > > > > >> Patches 1 to 3 are trivial.
> > > > > >>
> > > > > >> Patch 4 is the main cause of the increased lines, but I think the new
> > > > > >> code makes it easier to understand why each condition in
> > > > > >> __kvm_set_memory_region() is there.
> > > > > >>
> > > > > >> If you don't agree with patch 4, please consider taking the rest of the
> > > > > >> series at this time.
> > > > > >>
> > > > > >> Takuya Yoshikawa (4):
> > > > > >> KVM: set_memory_region: Don't jump to out_free unnecessarily
> > > > > >> KVM: set_memory_region: Don't check for overlaps unless we create or move a slot
> > > > > >> KVM: set_memory_region: Remove unnecessary variable memslot
> > > > > >> KVM: set_memory_region: Identify the requested change explicitly
> > > > > >>
> > > > > >> virt/kvm/kvm_main.c | 94 ++++++++++++++++++++++++++++++++-------------------
> > > > > >> 1 files changed, 59 insertions(+), 35 deletions(-)
> > > > > >>
> > > > > >> --
> > > > > >> 1.7.5.4
> > > > > >
> > > > > > Reviewed-by: Marcelo Tosatti <mtosatti@redhat.com>
> > > > > >
> > > > > > BTW, while at it, its probably worthwhile to restrict flags
> > > > > > modifications: change from flags = 0 to flags = read-only is
> > > > > > incomplete. Xiao, should it be allowed only during creation?
> > > > >
> > > > > Will Readonly memory be used for VM-mem-sharing in the future?
> > > > > I remember you mentioned about mem-sharing things before. ;)
> > > > >
> > > > > Actually, It is safe on KVM MMU because all the gfns in the slot
> > > > > can become readonly after calling __kvm_set_memory_region. It is
> > > > > unsafe on IOMMU, what need to be fixed is unmapping gfns on IOMMU
> > > > > when the flag is changed.
> > > >
> > > > Which means if we allow changing flags from 0 to read_only or back we
> > > > need to call kvm_iommu_map_pages() when flags change. BTW as far as I
> > > > see currently IOMMU maps everything as read/write not matter what flags
> > > > say. Looks like a bug. Alex?
> > >
> > > That's correct, legacy device assignment is always r/w. vfio handles
> > > this correctly. Thanks,
> > >
> > Does this mean that device can write into read only memory?
>
> For legacy assignment, I would expect yes. On bare metal, DMA from an
> I/O device can obviously circumvent processor based memory attributes,
> but here that might also include things like ROMs too. Thanks,
>
Why dropping IOMMU_WRITE from flags if slot is read only in
kvm_iommu_map_pages() will not work?
--
Gleb.
next prev parent reply other threads:[~2013-01-17 17:59 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-11 9:25 [PATCH 0/4] KVM: Clean up and optimize __kvm_set_memory_region() - part1 Takuya Yoshikawa
2013-01-11 9:26 ` [PATCH 1/4] KVM: set_memory_region: Don't jump to out_free unnecessarily Takuya Yoshikawa
2013-01-11 9:26 ` [PATCH 2/4] KVM: set_memory_region: Don't check for overlaps unless we create or move a slot Takuya Yoshikawa
2013-01-11 9:27 ` [PATCH 3/4] KVM: set_memory_region: Remove unnecessary variable memslot Takuya Yoshikawa
2013-01-11 9:28 ` [PATCH 4/4] KVM: set_memory_region: Identify the requested change explicitly Takuya Yoshikawa
2013-01-16 19:07 ` [PATCH 0/4] KVM: Clean up and optimize __kvm_set_memory_region() - part1 Marcelo Tosatti
2013-01-17 3:20 ` Xiao Guangrong
2013-01-17 7:29 ` Gleb Natapov
2013-01-17 17:12 ` Alex Williamson
2013-01-17 17:20 ` Gleb Natapov
2013-01-17 17:30 ` Alex Williamson
2013-01-17 17:58 ` Gleb Natapov [this message]
2013-01-17 18:25 ` Alex Williamson
2013-01-17 12:40 ` Marcelo Tosatti
2013-01-17 12:42 ` Gleb Natapov
2013-01-17 14:26 ` Takuya Yoshikawa
2013-01-17 16:35 ` Gleb Natapov
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=20130117175859.GC10107@redhat.com \
--to=gleb@redhat.com \
--cc=alex.williamson@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=mtosatti@redhat.com \
--cc=xiaoguangrong@linux.vnet.ibm.com \
--cc=yoshikawa_takuya_b1@lab.ntt.co.jp \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.