All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Kiszka <jan.kiszka@siemens.com>
To: Gleb Natapov <gleb@redhat.com>
Cc: Avi Kivity <avi@redhat.com>,
	Xiao Guangrong <xiaoguangrong@linux.vnet.ibm.com>,
	Marcelo Tosatti <mtosatti@redhat.com>,
	LKML <linux-kernel@vger.kernel.org>, KVM <kvm@vger.kernel.org>
Subject: Re: [PATCH] KVM: x86: fix vcpu->mmio_fragments overflow
Date: Mon, 22 Oct 2012 15:25:49 +0200	[thread overview]
Message-ID: <5085495D.6060307@siemens.com> (raw)
In-Reply-To: <20121022130810.GW29310@redhat.com>

On 2012-10-22 15:08, Gleb Natapov wrote:
> On Mon, Oct 22, 2012 at 03:05:58PM +0200, Jan Kiszka wrote:
>> On 2012-10-22 14:58, Avi Kivity wrote:
>>> On 10/22/2012 02:55 PM, Jan Kiszka wrote:
>>>>> Since the userspace change is needed the idea is dead, but if we could
>>>>> implement it I do not see how it can hurt the latency if it would be the
>>>>> only mechanism to use coalesced mmio buffer. Checking that the ring buffer
>>>>> is empty is cheap and if it is not empty it means that kernel just saved
>>>>> you a lot of 8 bytes exists so even after iterating over all the entries there
>>>>> you still saved a lot of time.
>>>>
>>>> When taking an exit for A, I'm not interesting in flushing stuff for B
>>>> unless I have a dependency. Thus, buffers would have to be per device
>>>> before extending their use.
>>>
>>> Any mmio exit has to flush everything.  For example a DMA caused by an
>>> e1000 write has to see any writes to the framebuffer, in case the guest
>>> is transmitting its framebuffer to the outside world.
>>
>> We already flush when that crazy guest actually accesses the region, no
>> need to do this unconditionally.
>>
> What if framebuffer is accessed from inside the kernel? Is this case handled?

Unless I miss a case now, there is no direct access to the framebuffer
possible when we are also doing coalescing. Everything needs to go
through userspace.

Jan

-- 
Siemens AG, Corporate Technology, CT RTC ITP SDP-DE
Corporate Competence Center Embedded Linux

  reply	other threads:[~2012-10-22 13:25 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-10-19  7:37 [PATCH] KVM: x86: fix vcpu->mmio_fragments overflow Xiao Guangrong
2012-10-19  7:39 ` [PATCH] emulator test: add "rep ins" mmio access test Xiao Guangrong
2012-11-01  0:05   ` Marcelo Tosatti
2012-10-22  9:16 ` [PATCH] KVM: x86: fix vcpu->mmio_fragments overflow Gleb Natapov
2012-10-22 11:09   ` Xiao Guangrong
2012-10-22 11:23     ` Gleb Natapov
2012-10-22 11:35       ` Jan Kiszka
2012-10-22 11:43         ` Gleb Natapov
2012-10-22 11:45           ` Jan Kiszka
2012-10-22 12:18             ` Avi Kivity
2012-10-22 12:45               ` Jan Kiszka
2012-10-22 12:53                 ` Gleb Natapov
2012-10-22 12:55                   ` Jan Kiszka
2012-10-22 12:58                     ` Avi Kivity
2012-10-22 13:05                       ` Jan Kiszka
2012-10-22 13:08                         ` Gleb Natapov
2012-10-22 13:25                           ` Jan Kiszka [this message]
2012-10-22 14:00                             ` Gleb Natapov
2012-10-22 14:23                               ` Jan Kiszka
2012-10-22 15:36                               ` Avi Kivity
2012-10-22 12:58                     ` Gleb Natapov
2012-10-22 12:55                   ` Avi Kivity
2012-10-22 13:01                     ` Gleb Natapov
2012-10-22 13:02                       ` Avi Kivity
2012-10-22 13:05                         ` Gleb Natapov
2012-10-22 12:56                 ` Avi Kivity
2012-10-22 13:58 ` Avi Kivity

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=5085495D.6060307@siemens.com \
    --to=jan.kiszka@siemens.com \
    --cc=avi@redhat.com \
    --cc=gleb@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mtosatti@redhat.com \
    --cc=xiaoguangrong@linux.vnet.ibm.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.