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:20:37 +0200 [thread overview]
Message-ID: <20130117172037.GB10107@redhat.com> (raw)
In-Reply-To: <1358442726.9252.5.camel@ul30vt.home>
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?
--
Gleb.
next prev parent reply other threads:[~2013-01-17 17:21 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 [this message]
2013-01-17 17:30 ` Alex Williamson
2013-01-17 17:58 ` Gleb Natapov
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=20130117172037.GB10107@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox