On 10/22/2012 04:00 PM, Gleb Natapov wrote:
> Yes, with frame buffer is seems to be the case. One can imagine ROMD
> device that is MMIO on write but still can be accessed for read from
> kernel, but it cannot be coalesced even if coalesced buffer is flushed
> on every exit.
You cannot enable coal
On 2012-10-22 16:00, Gleb Natapov wrote:
> On Mon, Oct 22, 2012 at 03:25:49PM +0200, Jan Kiszka wrote:
>> 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 wro
On Mon, Oct 22, 2012 at 03:25:49PM +0200, Jan Kiszka wrote:
> 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 ne
On 10/19/2012 09:37 AM, Xiao Guangrong wrote:
> After commit b3356bf0dbb349 (KVM: emulator: optimize "rep ins" handling),
> the pieces of io data can be collected and write them to the guest memory
> or MMIO together.
>
> Unfortunately, kvm splits the mmio access into 8 bytes and store them to
> v
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
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
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 t
On Mon, Oct 22, 2012 at 03:02:22PM +0200, Avi Kivity wrote:
> On 10/22/2012 03:01 PM, Gleb Natapov wrote:
>
> >> It's time where the guest cannot take interrupts, and time in a high
> >> priority guest thread that is spent processing low guest priority requests.
> >>
> > Proposed fix has exactly
On 10/22/2012 03:01 PM, Gleb Natapov wrote:
>> It's time where the guest cannot take interrupts, and time in a high
>> priority guest thread that is spent processing low guest priority requests.
>>
> Proposed fix has exactly same issue. Until all data is transfered to
> userspace no interrupt wil
On Mon, Oct 22, 2012 at 02:55:24PM +0200, Avi Kivity wrote:
> On 10/22/2012 02:53 PM, Gleb Natapov wrote:
> > On Mon, Oct 22, 2012 at 02:45:37PM +0200, Jan Kiszka wrote:
> >> On 2012-10-22 14:18, Avi Kivity wrote:
> >> > On 10/22/2012 01:45 PM, Jan Kiszka wrote:
> >> >
> >> >>> Indeed. git pull, r
On Mon, Oct 22, 2012 at 02:55:14PM +0200, Jan Kiszka wrote:
> On 2012-10-22 14:53, Gleb Natapov wrote:
> > On Mon, Oct 22, 2012 at 02:45:37PM +0200, Jan Kiszka wrote:
> >> On 2012-10-22 14:18, Avi Kivity wrote:
> >>> On 10/22/2012 01:45 PM, Jan Kiszka wrote:
> >>>
> > Indeed. git pull, recheck
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 i
On 10/22/2012 02:45 PM, Jan Kiszka wrote:
> On 2012-10-22 14:18, Avi Kivity wrote:
>> On 10/22/2012 01:45 PM, Jan Kiszka wrote:
>>
Indeed. git pull, recheck and call for kvm_flush_coalesced_mmio_buffer()
is gone. So this will break new userspace, not old. By global you mean
shared b
On 10/22/2012 02:53 PM, Gleb Natapov wrote:
> On Mon, Oct 22, 2012 at 02:45:37PM +0200, Jan Kiszka wrote:
>> On 2012-10-22 14:18, Avi Kivity wrote:
>> > On 10/22/2012 01:45 PM, Jan Kiszka wrote:
>> >
>> >>> Indeed. git pull, recheck and call for kvm_flush_coalesced_mmio_buffer()
>> >>> is gone. So
On 2012-10-22 14:53, Gleb Natapov wrote:
> On Mon, Oct 22, 2012 at 02:45:37PM +0200, Jan Kiszka wrote:
>> On 2012-10-22 14:18, Avi Kivity wrote:
>>> On 10/22/2012 01:45 PM, Jan Kiszka wrote:
>>>
> Indeed. git pull, recheck and call for kvm_flush_coalesced_mmio_buffer()
> is gone. So this wi
On Mon, Oct 22, 2012 at 02:45:37PM +0200, Jan Kiszka wrote:
> On 2012-10-22 14:18, Avi Kivity wrote:
> > On 10/22/2012 01:45 PM, Jan Kiszka wrote:
> >
> >>> Indeed. git pull, recheck and call for kvm_flush_coalesced_mmio_buffer()
> >>> is gone. So this will break new userspace, not old. By global
On 2012-10-22 14:18, Avi Kivity wrote:
> On 10/22/2012 01:45 PM, Jan Kiszka wrote:
>
>>> Indeed. git pull, recheck and call for kvm_flush_coalesced_mmio_buffer()
>>> is gone. So this will break new userspace, not old. By global you mean
>>> shared between devices (or memory regions)?
>>
>> Yes. We
On 10/22/2012 01:45 PM, Jan Kiszka wrote:
>> Indeed. git pull, recheck and call for kvm_flush_coalesced_mmio_buffer()
>> is gone. So this will break new userspace, not old. By global you mean
>> shared between devices (or memory regions)?
>
> Yes. We only have a single ring per VM, so we cannot f
On 2012-10-22 13:23, Gleb Natapov wrote:
> On Mon, Oct 22, 2012 at 07:09:38PM +0800, Xiao Guangrong wrote:
>> On 10/22/2012 05:16 PM, Gleb Natapov wrote:
>>> On Fri, Oct 19, 2012 at 03:37:32PM +0800, Xiao Guangrong wrote:
After commit b3356bf0dbb349 (KVM: emulator: optimize "rep ins" handling)
On 2012-10-22 13:43, Gleb Natapov wrote:
> On Mon, Oct 22, 2012 at 01:35:56PM +0200, Jan Kiszka wrote:
>> On 2012-10-22 13:23, Gleb Natapov wrote:
>>> On Mon, Oct 22, 2012 at 07:09:38PM +0800, Xiao Guangrong wrote:
On 10/22/2012 05:16 PM, Gleb Natapov wrote:
> On Fri, Oct 19, 2012 at 03:37
On Mon, Oct 22, 2012 at 01:35:56PM +0200, Jan Kiszka wrote:
> On 2012-10-22 13:23, Gleb Natapov wrote:
> > On Mon, Oct 22, 2012 at 07:09:38PM +0800, Xiao Guangrong wrote:
> >> On 10/22/2012 05:16 PM, Gleb Natapov wrote:
> >>> On Fri, Oct 19, 2012 at 03:37:32PM +0800, Xiao Guangrong wrote:
> Af
On Mon, Oct 22, 2012 at 07:09:38PM +0800, Xiao Guangrong wrote:
> On 10/22/2012 05:16 PM, Gleb Natapov wrote:
> > On Fri, Oct 19, 2012 at 03:37:32PM +0800, Xiao Guangrong wrote:
> >> After commit b3356bf0dbb349 (KVM: emulator: optimize "rep ins" handling),
> >> the pieces of io data can be collecte
On 10/22/2012 05:16 PM, Gleb Natapov wrote:
> On Fri, Oct 19, 2012 at 03:37:32PM +0800, Xiao Guangrong wrote:
>> After commit b3356bf0dbb349 (KVM: emulator: optimize "rep ins" handling),
>> the pieces of io data can be collected and write them to the guest memory
>> or MMIO together.
>>
>> Unfortun
On Fri, Oct 19, 2012 at 03:37:32PM +0800, Xiao Guangrong wrote:
> After commit b3356bf0dbb349 (KVM: emulator: optimize "rep ins" handling),
> the pieces of io data can be collected and write them to the guest memory
> or MMIO together.
>
> Unfortunately, kvm splits the mmio access into 8 bytes and
After commit b3356bf0dbb349 (KVM: emulator: optimize "rep ins" handling),
the pieces of io data can be collected and write them to the guest memory
or MMIO together.
Unfortunately, kvm splits the mmio access into 8 bytes and store them to
vcpu->mmio_fragments. If the guest uses "rep ins" to move l
25 matches
Mail list logo
