From: Xiao Guangrong <xiaoguangrong@linux.vnet.ibm.com>
To: Marcelo Tosatti <mtosatti@redhat.com>
Cc: Avi Kivity <avi@redhat.com>, LKML <linux-kernel@vger.kernel.org>,
KVM <kvm@vger.kernel.org>
Subject: Re: [PATCH 2/9] KVM: x86: simplify read_emulated
Date: Mon, 23 Jul 2012 12:23:11 +0800 [thread overview]
Message-ID: <500CD1AF.8050707@linux.vnet.ibm.com> (raw)
In-Reply-To: <20120720195203.GA25355@amt.cnet>
On 07/21/2012 03:52 AM, Marcelo Tosatti wrote:
> On Fri, Jul 20, 2012 at 09:15:44PM +0800, Xiao Guangrong wrote:
>> On 07/20/2012 06:58 PM, Marcelo Tosatti wrote:
>>> On Fri, Jul 20, 2012 at 10:17:36AM +0800, Xiao Guangrong wrote:
>>>> On 07/20/2012 07:58 AM, Marcelo Tosatti wrote:
>>>>
>>>>>> - }
>>>>>> + rc = ctxt->ops->read_emulated(ctxt, addr, mc->data + mc->end, size,
>>>>>> + &ctxt->exception);
>>>>>> + if (rc != X86EMUL_CONTINUE)
>>>>>> + return rc;
>>>>>> +
>>>>>> + mc->end += size;
>>>>>> +
>>>>>> +read_cached:
>>>>>> + memcpy(dest, mc->data + mc->pos, size);
>>>>>
>>>>> What prevents read_emulated(size > 8) call, with
>>>>> mc->pos == (mc->end - 8) now?
>>>>
>>>> Marcelo,
>>>>
>>>> The splitting has been done in emulator_read_write_onepage:
>>>>
>>>> while (bytes) {
>>>> unsigned now = min(bytes, 8U);
>>>>
>>>> frag = &vcpu->mmio_fragments[vcpu->mmio_nr_fragments++];
>>>> frag->gpa = gpa;
>>>> frag->data = val;
>>>> frag->len = now;
>>>> frag->write_readonly_mem = (ret == -EPERM);
>>>>
>>>> gpa += now;
>>>> val += now;
>>>> bytes -= now;
>>>> }
>>>>
>>>> So i think it is safe to remove the splitting in read_emulated.
>>>
>>> Yes, it is fine to remove it.
>>>
>>> But splitting in emulate.c prevented the case of _cache read_ with size
>>>> 8 beyond end of mc->data. Must handle that case in read_emulated.
>>>
>>> "What prevents read_emulated(size > 8) call, with mc->pos == (mc->end - 8) now?"
>>
>> You mean the mmio region is partly cached?
>>
>> I think it can not happen. Now, we pass the whole size to emulator_read_write_onepage(),
>> after it is finished, it saves the whole data into mc->data[], so, the cache-read
>> can always get the whole data from mc->data[].
>
> I mean that nothing prevents a caller from reading beyond the end of
> mc->data array (but then again this was the previous behavior).
1024 bytes should be enough for instructions, may be we can add a WARN_ON
to check buffer-overflow.
>
> ACK
>
Thank you, Marcelo!
next prev parent reply other threads:[~2012-07-23 4:23 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-17 13:50 [PATCH 1/9] KVM: x86: remvoe unnecessary mark_page_dirty Xiao Guangrong
2012-07-17 13:51 ` [PATCH 2/9] KVM: x86: simplify read_emulated Xiao Guangrong
2012-07-19 23:58 ` Marcelo Tosatti
2012-07-20 2:17 ` Xiao Guangrong
2012-07-20 10:58 ` Marcelo Tosatti
2012-07-20 13:15 ` Xiao Guangrong
2012-07-20 19:52 ` Marcelo Tosatti
2012-07-23 4:23 ` Xiao Guangrong [this message]
2012-07-17 13:52 ` [PATCH 3/9] KVM: x86: introduce set_mmio_exit_info Xiao Guangrong
2012-07-20 0:03 ` Marcelo Tosatti
2012-07-20 2:24 ` Xiao Guangrong
2012-07-17 13:52 ` [PATCH 4/9] KVM: MMU: track the refcount when unmap the page Xiao Guangrong
2012-07-20 0:09 ` Marcelo Tosatti
2012-07-17 13:53 ` [PATCH 5/9] KVM: MMU: fask check write-protect for direct mmu Xiao Guangrong
2012-07-20 0:39 ` Marcelo Tosatti
2012-07-20 2:34 ` Xiao Guangrong
2012-07-20 11:09 ` Marcelo Tosatti
2012-07-20 13:33 ` Xiao Guangrong
2012-07-20 3:45 ` Xiao Guangrong
2012-07-20 11:45 ` Marcelo Tosatti
2012-07-17 13:54 ` [PATCH 6/9] KVM: using get_fault_pfn to get the fault pfn Xiao Guangrong
2012-07-17 13:54 ` [PATCH 7/9] KVM: mark do not extern bad_pfn Xiao Guangrong
2012-07-17 13:55 ` [PATCH 8/9] KVM: remove is_error_hpa Xiao Guangrong
2012-07-17 13:56 ` [PATCH 9/9] KVM: remove the unused parameter of gfn_to_pfn_memslot Xiao Guangrong
2012-07-20 0:40 ` [PATCH 1/9] KVM: x86: remvoe unnecessary mark_page_dirty Marcelo Tosatti
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=500CD1AF.8050707@linux.vnet.ibm.com \
--to=xiaoguangrong@linux.vnet.ibm.com \
--cc=avi@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mtosatti@redhat.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 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.